In Becoming a Craftsman, Rock Hymas writes about Mercurial vs. Subversion. It’s an excellent exposition of the tools and their underlying philosophies, and how his own development style changed from working on a Mercurial-based project. It’s slightly marred by his conclusion that using Mercurial makes you a better developer; he seems to believe it does this partly through its own weaknesses, which I find odd reasoning. But putting that aside, it’s an excellent read.
He tasks me for my July 2008 article on Mercurial vs. Subversion:
One counterpoint to the ease of branching is that it may isolate developers. John DeRosa registers his concern about this:
“Additionally, I think distributed SCMs like Mercurial have a not-yet-fully-appreciated problem in making it too easy to not [ever] check code back into the main pool. With a local repository, a developer can feel protected from accidents and continue working happily for quite a long time. And then, say a year down the road, he/she does a massive check-in and discovers an integration problem. Branches, or a local repository that is effectively a private branch, should be easy to make — but not too easy.”
Let me explain why I don’t buy it. First, “a year down the road”?! Seriously? It says something that you have to imagine a scenario so horrible and unlikely in order to envision easy branching as a bad thing. I think that the author likely didn’t realize how easy merging usually is with a DVCS like Mercurial. And he must have totally forgotten that this lone maverick developer could have been merging the main development line into her own repository every day or week. The right solution to this imagined (and barely imaginable) scenario is not to eliminate easy branching, since without it the lone developer will do the same thing, but be much more likely to lose her work because it won’t be stored in a repository. The right solution is to fix a broken culture that enables someone to go a full year with no accountability for their work.
I first thought to respond by suggesting he took my “year down the road” too literally. But I did choose that phrase, so I’ll live with the consequences. His criticism is correct.
If a developer really did keep code changes out of the main pool for a year, it would indicate a totally broken team culture. I was trying to make the point that a developer might feel comfortable not checking in code for longer than he should. But Rock would still be right. If a developer is running open loop, don’t look to the tools for the enabler. Look to team mismanagement.
In the end, Rock comes down in favor of Mercurial. As for me, I like Mercurial quite a bit. My July 2008 post was about the VCS for a Fisher Communications project. (Which has since been cancelled, along with my entire team, as Fisher decided to embrace the future by firing nearly all of its Web division.) The team would have been in one building with great bandwidth, and I was already familiar with setting up Subversion servers.
I’m now working on a small hyper-local news project, using Django. The code and wiki are hosted on Bitbucket, which uses Mercurial. Everything works fine and I’ve got no complaints about Mercurial. (I don’t care for Bitbucket’s wiki, however.)
Smart developers can be successful using Subversion or Mercurial. I appreciate Mercurial’s lightweight interactions and easy setup, and doing frequent check-ins to my local repository. OTOH, Subversion provides a central server’s authority, I type one less command to check in to the central server, and it’s been battle-tested a bit more. If I had to use one or the other for the rest of my life, I think I’d now pick Mercurial by a very slim margin. But I could use either one forever and be very successful and productive.
3 thoughts on “Mercurial vs. Subversion, take 2”
Bravo, John. I hope I am as magnanimous when making a self-correction. Also, with your follow up I would say you’ve found nuance. And as a former Microsoftie, I wouldn’t be sad to see your prediction about Ballmer come true.
A couple of tidbits –
1) did you know that you can use Mercurial to work with GitHub too? Not a very common scenario, but if you wanted to do that the GitHub folks have written a hg-git plugin thingy to allow you to check out and push back to Git repositories. Then again, it can just add a shitload of confusion to the mix.
2) what don’t you like about BitBucket’s wiki? What would you change? I’m curious for myself more than anything else – I’ve found that GitHub’s ability to recognize Markdown, Restructured Text, Textile, and other mechanisms and displays them in a rich format to be really freakin’ useful, and has negated a lot of the Wiki need for me (see http://github.com/ccgus/letters/blob/master/README-CONTRIB.markdown for an example)
I want to, and haven’t yet, written an article exactly like this on how to collaborate (common things you’ll want/need to do with step-by-step how to) for BitBucket.
I really like BitBucket, if nothing else than it’s focused on Mercurial (which I also like) and I want to see Jesper’s work continue to grow.
The Creole syntax was based on a careful analysis of existing wikis’, and lots of thought appears to have gone into it. Nonetheless, or maybe because of this, it feels like a camel, i.e., a horse designed by a committee. The way links and lists are handled feels odd. And it could be smarter about where it puts inter-line whitespace in the output.
Having said that, I’m fine with development wikis being “minimalistic” and favoring content over form. I can definitely live with Creole, but I think for example that Trac’s wiki syntax was a little more logical.
I would love to see you write article(s) about using the latest generations of online collaboration tools!