Today I read a blog post written by Joel Spolsky where at the beginning he claims that distributed version control systems (DVCS) like Mercurial are just more complicated than centralised version control systems like Subversion.
I was relieved that this was not his last word about Mercurial. In fact, though at first glance it appears that Mercurial is not his favorite book, he is not too far away from writing his own book about Mercurial.
His article was highly amusing to me because he seems to have had almost exactly the same experience with Mercurial as I had when I first started to play with it. It was also highly informative to me because my subversion background wasn’t that strong.
In contrast to what one might expect from reading the first lines of his article, his opinion about DVCS (and Mercurial in special) is this:
This is too important to miss out on. This is possibly the biggest advance in software development technology in the ten years I’ve been writing articles here.
Or, to put it another way, I’d go back to C++ before I gave up on Mercurial.
This is probably the reason why he created HgInit, a site dedicated to Mercurial. I think it is easily the best Mercurial tutorial available. In his first chapter he dives into conceptual differences between Subversion and Mercurial. This chapter is a must-read for everyone who is used to Subversion and is happy about it, who is used to Subversion and is NOT happy about it (which is much more likely) or who is not used to Subversion at all. So … everyone. Show it to your grandma.
There are a few important points I would like to highlight for those among us who are not willing to even read a must-read:
Mercurial separates the act of committing new code from the act of inflicting it on everybody else.
With DVCS, you have your own local repository on your dev machine, which gives you the goodies of versioned code (oops, that last change was a bad idea, I want to roll back) without having to check it in to a central repository before it is stable. What good is a VCS if I have to work for days without checking in just because it would break a build or because it is still far too buggy? With Subversion, I have to work without Subversion (I know what this sounds like) for a critical amount of time.
Well, we could branch, couldn’t we? Sure you can, but You Will Wish You Hadn’t™.
When we have to merge, Subversion tries to look at both revisions—my modified code, and your modified code—and it tries to guess how to smash them together in one big unholy mess. It usually fails, producing pages and pages of “merge conflicts” that aren’t really conflicts, simply places where Subversion failed to figure out what we did.
By contrast, while we were working separately in Mercurial, Mercurial was busy keeping a series of changesets. And so, when we want to merge our code together, Mercurial actually has a whole lot more information: it knows what each of us changed and can reapply those changes, rather than just looking at the final product and trying to guess how to put it together.
When I was first working with Mercurial, I knew enough about Subversion to recall that merging is dangerous. A health-threatening hobby for bored folks with too much time, like one of my colleagues put it. I first thought he was referring to skydiving without parachute, but that wasn’t quite the case. Joel explains why I was surprised to see that Mercurial handles it painlessly, almost as if no merge happened at all, which sounded fishy to me, but it wasn’t, it just worked.
And this is where I stop writing and continue reading Joel’s tutorial.