|
Size: 2016
Comment:
|
Size: 2844
Comment: minor English usage tweak
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| A ["Repository"] may have multiple ["Head"]s, which is useful in at least two cases: | A [:Repository:repository] may have '''multiple heads''', which is useful in at least two cases: |
| Line 3: | Line 3: |
| * As part of a ["Merge"] (generally temporary) | * As part of a [:Merge:merge] (generally temporary) |
| Line 6: | Line 6: |
| At any time, you can view the ["Head"](s) of a ["Repository"] with the command ''hg heads''. | At any time, you can view the head(s) of a repository with the command {{{hg heads}}}. |
| Line 8: | Line 8: |
| 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. | 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. |
| Line 10: | Line 10: |
==== 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 |
|
| Line 11: | Line 58: |
| ==== 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. |
CategoryHowTo |
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