More playing with Mercurial...

I’ve spent some more time playing with Mercurial, and discovered a few things. First, renames actually track unlike Subversion, where updating my working copy may result in the old filename being updated, but the new won’t receive those changes. However, it does fail to create a conflict when two developers attempt to rename the file to different names. Secondly, cherry picking isn’t built in. You need to use the transplant extension to cherry pick revisions from one branch to the other. It’s not that it’s hard to use–actually, it’s rather easy. However, I’d expect merge to help me do this. Again, this may be a “mental model” problem… perhaps the best way to think about it is that “merge” is for joining branches, while transplant is about cherry-picking specific revisions. Finally, the lack of partial checkouts is killing me, along with every working copy containing the entire repository. For a couple of projects, we have some highly specialized tools, datasheets, data sets, and other files that take a considerable amount of space. For reasons that I have mentioned before (in Taking a look at Mercurial), I desire to keep everything in a single repository. The problem is that I now have hundreds of megabytes of files that I only need in one spot. NTFS is slow, so having all of these files there just makes things more painful than I care for it to be.

Mercurial has some really, really bright sides though. One of those is extensions. You can really do a lot with them, and I’m intrigued by that. I have visions of being able to do several local commits to Mercurial, and then having a Mercurial command to help me push them to Subversion–similar to SVK. At any rate, a really interesting extension for Mercurial is the Mercurial Queues extension. It looks wonderfully useful.

This experience with Mercurial has left me wondering why we’re working so hard in Subversion. I mean, Mark wrote most of Mercurial. It’s short, sweet, and to the point. It was also developed in far less time than Subversion, by a smaller group of people, and admittedly, solved some hard problems that we haven’t yet. Don’t get me wrong, Mark had the benefit of knowledge (distributed SCMs are more common these days, and he had the extra benefit of seeing how other projects have failed in some respects and succeeded in others). But seriously, there are other factors at play here. I see Mercurial as a wake up call. But that’s a post for another day.