Distributed SCM

I have been keenly following the rise of distributed version control systems (such as [[http://www.selenic.com/mercurial/wiki/index.cgi/Mercurial|mercurial]] and [[http://bazaar-ng.org|Bazaar-NG]]) over centralized version control systems such as [[http://www.nongnu.org/cvs/|CVS]] or [[http://subversion.tigris.org/|Subversion]] ((these days, the term SCM is used instead for version control systems)). Part of the interest is for pragmatic reasons — the distributed development model just //seems// right and I find myself using it more and more for my projects. Partly the interest is simply because I find the evolution of “best tools and best practices” of software development quite fascinating.

I won’t spend time belaboring over my experiences with the plethora of distributed SCMs out there for two reasons: there are just [[http://www.google.com/Top/Computers/Software/Configuration_Management/Tools/|too many]] of them to evaluate; and [[http://www.dwheeler.com/essays/scm.html|several]] others have [[http://better-scm.berlios.de/comparison/comparison.html|tried]] to do some evaluation.

To be honest, I’m slightly biased towards tools written in Python. For that reason, I have been tracking the development of the two most promising SCMs (IMHO) — Mercurial and Bazaar-NG. To be fair, I did give [[http://abridgegame.org/darcs/|Darcs]] a shot, but [[http://floatingsun.net/blog/2006/02/02/505/|never got too far]]. So these are the two that I’ll be focusing my attention on — this way I can avoid the trouble of going through other (perhaps better?) alternatives.

I have already had a fair amount of experience with Mercurial, since the [[http://www.cl.cam.ac.uk/Research/SRG/netos/xen/|Xen]] folks use it and I really, //really// like it so far. Its feature-ful, robust, mature and proven to work on a large project. On the other hand, I secretly wish that I was Bazaar-NG more instead. The good thing about Bazaar-NG is that its backed by [[http://www.canonical.com/|Canonical]] (the company behind [[http://www.ubuntu.com/|Ubuntu]]) and they have **really big** plans for it: eventually they [[http://bazaar.canonical.com/CanonicalBzrDogfooding|plan]] to use it for ALL the packages under Ubuntu, as well as for everything managed by Launchpad. However, Bazaar-NG is still in a fairly early stage of development, and not nearly as feature-ful, robust or fast as Mercurial. I don’t know of any really big projects currently using Bazaar-NG either. [[http://bazaar.canonical.com/WhoUsesBzr|It seems]] that Drupal is using Bazaar-NG?

As a simple example, I was able to clone the main Mercurial development branch in **less than a minute**. The same operation for Bazaar-NG (”bzr branch”) took **more than an hour** (its still going on as I type this). This is clearly unacceptable for any real use.

I am on the mailing lists for both the projects, and both projects are fairly active with a good developer community. I think Xen has contributed a lot to the adoption of Mercurial — I mean, it was always a good tool, but a lot of people came to know about it only after Xen decided to move from Bitkeeper to Mercurial (the kernel folks wrote their own thing instead — ”git/cogito”). I’m going to use Mercurial for most of my projects for now, but keep a keen eye on Bazaar-NG. I hope very soon the developers will start focusing on the speed of Bazaar-NG and not just the features.

**Update**: I’m disappointed, and aghast :-( After running for about an hour, my ”bzr branch http://bazaar-ng.org/bzr/bzr.dev” command failed with the following error:

bzr: ERROR: Error retrieving http://bazaar-ng.org/bzr/bzr.dev/.bzr/revision-store/mbp%40sourcefrog.net-20050829071309-2c62f851915b9825.sig.gz:

Anyone know whats going on here?

Leave a Reply