Killer apps: bzr shelve
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).
Using bzr at work, though, I think I just found my killer app in Michael Ellerman’s shelve 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
unapplied and goes into a “shelf”, where bzr unshelve 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.
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.