chiark / gitweb /
Killer apps: bzr shelve
authorcjwatson <>
Mon, 9 Jan 2006 16:47:43 +0000 (16:47 +0000)
committercjwatson <>
Mon, 9 Jan 2006 16:47:43 +0000 (16:47 +0000)
2006-01-09-bzr-shelve.txt [new file with mode: 0644]

diff --git a/2006-01-09-bzr-shelve.txt b/2006-01-09-bzr-shelve.txt
new file mode 100644 (file)
index 0000000..8788d66
--- /dev/null
@@ -0,0 +1,33 @@
+Killer apps: bzr shelve
+
+<p>Working on free software has made me fairly revision control
+system-agnostic; I can't afford to get too wedded to any one system because
+as soon as I do somebody will invent something new and I'll have to convert
+again, so I just work with whatever other people on the same project are
+using. Even CVS doesn't make a lot of difference to the way I work as long
+as I'm working online and have cvsps handy. And of course I usually don't
+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).</p>
+
+<p>Using bzr at work, though, I think I just found my killer app in Michael
+Ellerman's <a href="http://bazaar.canonical.com/BzrShelveExample">shelve</a>
+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.</p>
+
+<p><kbd>bzr shelve</kbd> 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 unapplied and goes into a "shelf", where <kbd>bzr unshelve</kbd> can
+later reapply it. In the meantime commits act as though the shelved hunks
+didn't exist. This doesn't help if you want to defer only one of two
+immediately adjacent changes that end up in the same hunk, of course, but it
+vastly reduces the scale of the problem.</p>
+
+<p>I suppose it would be easy enough to write a shelve-a-like for any other
+system; it's just that I haven't seen it for any other system yet. If
+working with systems that lack it really starts to annoy me, I may have to
+rip out the guts of shelve and figure out how to make it generic.</p>