A ["Repository"] may have multiple ["Head"]s, which is useful in at least two cases:

At any time, you can view the ["Head"](s) of a ["Repository"] with the command hg heads.

Not all ["SCM"] tools support ongoing MultipleHeads, since it is possible to achieve the same results with multiple repositories instead. However, especially if you are used to ["CVS"], MultipleHeads may be more familiar or convenient.

Merging

First, the ["ChangeSet"]s to be merged are ["Pull"]ed from the source ["Repository"] into the destination ["Repository"]. At that point, the original ["Tip"] is still a ["Head"], but the ["Tip"] of the source ["Repository"] is also a ["Head"]. Normally this case of MultipleHeads is only temporary, as the two ["Head"]s are usually joined back into one right away, by performing a ["Merge"].

Bugfix Versions

Let's compare a scenario with and without MultipleHeads. Imagine a project releases version 1.0, and then 2.0, and then discovers a critical bug in 1.0 that must be fixed. Current work on the upcoming 3.0 version is ongoing.

Without MultipleHeads, you would ["Clone"] the ["Repository"] each time you ["Tag"] a release. To work on version 1.1, you would ["Clone"] the 1.0 ["Repository"] and work on that, separately from the ["Repository"] you are using for current development. One drawback of this approach is that you can't directly access the 1.1 work while you are working on the current code.

With MultipleHeads, you can perform 1.1 work inside the current (pre-3.0) ["Repository"]. Just use ["Update"] to populate your WorkingDirectory with the contents of the 1.1 ["Tag"], make your changes, and ["Commit"]. To continue working on pre-3.0, just use ["Update"] again to reset your WorkingDirectory to that code base.

MultipleHeads allows a single ["Repository"] to contain the entire history of a project, including bugfix branches.

Named branches

If a branch descend from a tagged revision, the whole branch inherits the tag. Briefly, if you tag a commit "A", each descendant of A will inherit "A" as a "branch name" until it gets a different tag. Descendents of a merge receive the union of names from each side.

So you can do: 

$ hg heads -b
changeset:   1704:c2755eba8631
tag:         tip
branch:      0.8
user:        Johannes Stezenbach <js at linuxtv.org>
date:        Mon Feb  6 17:35:22 2006 -0600
summary:     display revision numbers

..and see that you've got one branch in your tree, descended from something tagged 0.8.

And you can check out that head with: 

$ hg co -b 0.8
Using head c2755eba8631 for branch 0.8