Mercurial vs. Subversion, take 2

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.