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.
-- 2.30.2