Why A New SCM?

Existing systems suffer from several problems:

• They handle branching poorly, which makes keeping in sync hard
• They're centralized, which makes them hard to access
• They're slow, which means they're often bypassed

Mercurial is:

• Designed around making branching easy
• Decentralized so that everyone can use it
• Fast ("your tea is still warm")

Why a decentralized system?

• Centralized systems present a serious bottleneck for large numbers of concurrent users
• Because there's only one center, parallel development must be serialized to commit
• People without write access to the central server can't record the history of their changes
• A decentralized system allows people to work independently (even offline), synchronizing when convenient.

The Mercurial basics

• working directories are coupled with a store
• the working directory contains a project's files at a given point in the history (eg rev 2), ready for editing
• the store is a complete compact copy of the project history

Making a commit

• the state of the working directory is recorded as a new revision relative to its base revision
• the working directory here was based on revision 2
• we committed a new revision 4 which is a branch off 2
• now the working directory is based on revision 4

Revisions, Changesets, Heads, and Tip

• Each revision is a project-wide snapshot called a changeset
• Changesets each get a local sequential revision number
• Each revision also has a global unique changeset ID
• Changeset IDs can usually be shortened "e38487"
• Branches and merges can occur at any point
• A branch with no children is called a head (like revs 5 and 6)
• The most recently changed branch is called the tip (like rev 6)

Cloning, Merging, and Pulling

Let's start with a user Alice, who has a store that looks like:

Bob clones this repo, and ends up with a complete copy of Alice's store (though his working directory is independent!):

Bob then commits a couple changes:

Alice then makes her own change in parallel:

Bob then pulls Alice's repo to synchronize. This copies all of Alice's changes into Bob's repo:

Bob then does a merge which combines the last change he was working on (f) with the tip, commits the result, and ends up with:

Now if Alice pulls from Bob, she will get Bob's changes e, f, and h, and they will be fully synchronized:

Multiple ways to share repositories

• built in web-server ("hg serve") allows browsing and pulling
• CGI interface allows publishing groups of repositories
• With SSL, authorized users can push changes to public servers
• SSH support allows pushing and pulling over ssh links
• Binary "bundles" allow compressed changesets to be exchanged as files via email, etc.
• NFS allows sharing repositories across a LAN
• Traditional text patches can be exported and imported

Using cheap branches to manage changes

• Creating a local clone of a repository is fast (uses hardlinks)
• To experiment with a change, make a local clone and commence hacking
• Share your clone with other users to test/review your change
• When you're satisified with your results, push your changes into your "main" branch
• If your experiment is a failure, simply delete your clone

New features can be added with extensions

• extensions can add project-specific commands or behaviors
• the gpg extension allows secure signing of changesets
• the mq extension allows manipulating a series of changes as a queue
• the forest extension can manage a group of projects as a unit

For more information

• The Mercurial wiki
• A basic tutorial
• An unofficial manual
• The main Mercurial repository