Let's look into Mercurial

If you're at all interested in version control systems -- and any software developer not using one daily is a strange beast indeed -- you'll at least have become vaguely aware in the last few years of the growing maturity of the latest group of version control systems offering funky new stuff. These are the distributed version control systems (DVCS). There is more to them than just their headline attributes, being able to check history and do checkins while disconnected from a central server, but these are damn useful to start with.

When I first heard about DVCS, it wasn't immediately obvious to me (to put it mildly) how they would work. After years of using a centralised version control system, I had rough mental model of what went on. But how do you cope without the central server forcing ordering onto the changes?

Since then I've started using Mercurial1. Mercurial is a DVCS. It's one of three DVCSs that have gained significant popularity in the last few years, the other two being Git2 and Bazaar3. I switched a significant work project over to Mercurial (from Subversion) in mid-2007, because a customer site required on-site work but could not allow access back to the company VPN. I chose Mercurial for a variety of reasons which I won't bore you with here4.

What I want to do in this article is give you an insight into how a DVCS works. OK, so specifically I'm going to be talking about Mercurial, but Git and Bazaar attack the problem in a similar way. But first I'd better give you some idea of how you use Mercurial.


... Mercurial1
... Git2
... Bazaar3
... here4
OK, if you must know:

Jim Hague 2009-05-22