Update link to "bzr shelve" example

diff --git a/content/bzr-shelve.md b/content/bzr-shelve.md
index 2b05b125151d5fc4817c6c360eb0d77f902df86e..05f3d8c3d3900f1b8281f5c87f37ee52e26203c6 100644 (file)
--- a/content/bzr-shelve.md
+++ b/content/bzr-shelve.md
@@ -13,14 +13,14 @@ bother with revision control if I'm just tweaking somebody else's Debian
 source package a bit (in which case I just use debdiff for paranoia).
 
 Using bzr at work, though, I think I just found my killer app in Michael
-Ellerman's [shelve](http://bazaar.canonical.com/BzrShelveExample) plugin.
-My working style generally involves alternating between doing lots and lots
-of stuff in the one working copy and (after testing) going through and
-committing it in logical chunks.  This is fine if everything's in separate
-files (most revision control systems let you commit just some files), but if
-several of the chunks are in the one file then I'm reduced to saving diffs
-and manually editing out the bits I don't want to commit yet, which is
-obviously pretty tedious and error-prone.
+Ellerman's [shelve](http://wiki.bazaar.canonical.com/BzrShelveExample)
+plugin.  My working style generally involves alternating between doing lots
+and lots of stuff in the one working copy and (after testing) going through
+and committing it in logical chunks.  This is fine if everything's in
+separate files (most revision control systems let you commit just some
+files), but if several of the chunks are in the one file then I'm reduced to
+saving diffs and manually editing out the bits I don't want to commit yet,
+which is obviously pretty tedious and error-prone.
 
 `bzr shelve` presents each diff hunk in your working copy to you in turn and
 asks you whether you want to keep it.  If you say no, that hunk gets