Diff for "MultipleHeads"

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

• As part of a ["Merge"] (generally temporary)
• Bugfix versions (generally permanent)

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.