Diff for "MultipleHeads"

A [:Repository:repository] may have multiple heads, which is useful in at least two cases:

• As part of a [:Merge: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 multiple heads, since it is possible to achieve the same results with multiple repositories instead. However, especially if you are used to ["CVS"], multiple heads may be more familiar or convenient.

Merging

First, the [:ChangeSet:changesets] to be merged are [:Pull:pulled] from the source repository into the destination repository. At that point, the original [:Tip:tip] is still a [:Head:head], but the tip of the source repository is also a head. Normally this case of multiple heads is only temporary, as the two heads are usually joined back into one right away, by performing a merge.

Bugfix Versions

Let's compare a scenario with and without multiple heads. 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 multiple heads, you would [:Clone:clone] the repository each time you [:Tag: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 multiple heads, you can perform 1.1 work inside the current (pre-3.0) repository. Just use ["Update"] to populate your [:WorkingDirectory:working directory] with the contents of the 1.1 tag, make your changes, and [:Commit:commit]. To continue working on pre-3.0, just use update again to reset your working directory to that code base.

Multiple heads allows a single repository to contain the entire history of a project, including bugfix branches.

Named branches

If a [:Branch:branch] descends 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

See also: NamedBranches

CategoryHowTo