I’m sure most of you are familier with CVS and Subversion (a compelling replacement for CVS), the latter being a version control system I’ve had some great experiences with. Both CVS and Subversion are Centralised SCM’s (Source Control Management), today I encountered Mercurial which is a Distributed SCM.
To get our terms straight, let me just explain the differences between a Centralised CSM and a Distributed CSM.
- A centralised CSM will store all of it’s metadata into a single authorative database which isn’t replicated (besides perhaps backups).
- A distributed CSM is designed so that each repository is loosely coupled to an unlimited number of others. Every repository contains a complete set of metadata describing one or more projects, these repositories can be located anywhere.
According to the developers, “Mercurial is a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects.”. I was quite supprised at the number of projects already using Mercurial even though I had never heard of it yet.
Linus Torvalds had some very nice comments on the use of a Distributed SCM over a Central SCM.
The differences of a Distributed SCM in regards to a Central CSM:
- Every developer works their own local repository
- Repositories can be cloned by anyone, as many times as one would want
- You decide what the ‘central’ repository is, or even if there is one
- Anyone can create their own branch (Bazaar development model)
- Repositories are merged based on a web of trust (i.e. quality of changes, historical merit, etcetera)
- Network connection is not required for most operations
This has the following advantages:
- As you don’t need a network connection for most operations, meaning:
- Work productively offline
- Most operations are quite faster as there is no network involved
- One can participate in a project, without requiring permission from the project ‘authorities’ (Having your code merged into the project itself is a different story :))
- Private projects are easier to work on, you use revision control even if you don’t want to publish yet (The private aspect Linus mentioned)
- And perhaps the most important: You don’t have to rely on a single physical machine, there is no central machine so you can continue to keep working!
Disadvantages
- a person could end up as a central point of control, rather then a server. This could become the new single point of failure
- Developers need more knowledge of the infrastructure [of DCSM], in order to understand how to use it.
- Will often cause many merge conflicts to be resolved by hand
So, to conclude my story, I believe that a Distributed CSM can be very handy to work with, even though I’m greatly used to using Subversion for my projects.
I’ll install Mercurial later on to do some experimenting with its capabilities and to see how it works for someone thats heavily used to Subversion.
To be continued!
References:
Wikipedia on Distributed Revision Control
Distributed rivision control with Mercurial
The Mercurial website







O comments at "Mercurial, Distributed revision control"
Comment Now!