Mecurial is an open source, cross platform distributed version control system. It is fast, powerful and scalable while still being easy to use. This article is an introductory guide to installing Mercurial and getting up and running.

Basic Concepts

If you are familiar with distributed version control systems, you may want to skip to the next page. However, if you are used to centralised version control systems (CVCS) such as Subversion and Visual Source Safe, distributed version control systems (DVCS) can be conceptually tricky to begin with.

Rather than checking in and out from a single central repository, many repositories are created and changes moved between them. There is no official 'master' repository: it is simply the repository that the team has decided holds the master copy of the files.

Another notable difference is that Subversion tracks revisions to a file, whereas Mercurial and other DVCSs track changes. This is important when it comes to branching and merging, because it means Mercurial has a lot more information about the changes that were made and can merge more easily.

The main advantages of using a DVCS are:

  • extreme flexibility
  • good support for branching and merging
  • it's easy to manage concurrent development
  • local changes are version controlled
  • it's easy to promote changes between branches and versions

There are many different models for using a DVCS, from a single developer to a large, distributed team. To get a better understanding, lets have a look at a couple of example usage scenarios.


First, lets look at a simple CVCS:

There is one repository and the developers check files in and out. They work on local, non-version controlled copies of the files. Depending on the system, concurrent development is either not supported or a little tricky to manage.

A DVCS can be set up in a similar fashion, but will maintain version control and more easily allow concurrent development:

Each developer will create a local branch by cloning the master respository. The developer can then make changes and regularly commit to their local repository without fear of breaking the build. When the changes are complete, the developer will pull the latest changes down from the master respository and merge them with their changes. Then they will push their local changes, including the commit history, to the master. Because they have just resolved any merge conflicts locally, the push will not result in any conflicts.

The beauty of a DVCS is that it can be set up in almost any way you can imagine. Lets look at this more complex example:

Here we have two master repositories - one for the current release that is out with clients and one for the next release. The Stable repository is a clone of VNext at a particular point. In this scenario, Steve acts as a gatekeeper for the VNext repository. Anna and Paul make clones of VNext, make their changes, then tell Steve when they're ready. Steve pulls the changes from Anna's and Paul's repositories and if he's happy, pushes them into the master VNext.

Paul is working on bugfixes for the Stable release. To promote them into VNext, Paul pulls and merges changes from his stable repository into his VNext repository at which point they become part of the normal flow.

It's easy to imagine a raft of other more complex scenarios: developers cloning their repositories to their laptops to work disconnected; multiple repositories for different feature sets, each with its own gatekeeper; accepting bugfixes from clients and partners etc.


This remainder of this article covers:

  1. Installation, Configuration and Essential Commands
  2. A Practical Example of Using Hg with BitBucket
  3. Using Mercurial with FinalBuilder and Further Reading


Pages: 1 of 4 Next Page
Actions: E-mail | Permalink |