Mercurial_ The Definitive Guide - Bryan O'Sullivan [57]
If you’re resolving a conflict in the .hgtags file during a merge, there’s one twist to modifying the .hgtags file: when Mercurial is parsing the tags in a repository, it never reads the working copy of the .hgtags file. Instead, it reads the most recently committed revision of the file.
An unfortunate consequence of this design is that you can’t actually verify that your merged .hgtags file is correct until after you’ve committed a change. So if you find yourself resolving a conflict on .hgtags during a merge, be sure to run hg tags after you commit. If it finds an error in the .hgtags file, it will report the location of the error, which you can then fix and commit. You should then run hg tags again, just to be sure that your fix is correct.
Tags and Cloning
You may have noticed that the hg clone command has a -r option that lets you clone an exact copy of the repository as of a particular changeset. The new clone will not contain any project history that comes after the revision you specified. This has an interaction with tags that can surprise the unwary.
Recall that a tag is stored as a revision to the .hgtags file. When you create a tag, the changeset in which it is recorded refers to an older changeset. When you run hg clone -r foo to clone a repository as of tag foo, the new clone will not contain any revision newer than the one the tag refers to, including the revision where the tag was created. The result is that you’ll get exactly the right subset of the project’s history in the new repository, but not the tag you might have expected.
When Permanent Tags Are Too Much
Since Mercurial’s tags are revision controlled and carried around with a project’s history, everyone you work with will see the tags you create. But giving names to revisions has uses beyond simply noting that revision 4237e45506ee is really v2.0.2. If you’re trying to track down a subtle bug, you might want a tag to remind you of something like “Anne saw the symptoms with this revision.”
For cases like this, what you might want to use are local tags. You can create a local tag with the -l option to the hg tag command. This will store the tag in a file called .hg/localtags. Unlike .hgtags, .hg/localtags is not revision controlled. Any tags you create using -l remain strictly local to the repository you’re currently working in.
The Flow of Changes: Big Picture Versus Little Picture
To return to the outline I sketched at the beginning of the chapter, let’s think about a project that has multiple concurrent pieces of work under development at once.
There might be a push for a new “main” release; a new minor bug fix release to the last main release; and an unexpected “hot fix” to an old release that is now in maintenance mode.
The usual way people refer to these different concurrent directions of development is as “branches.” However, we’ve already seen numerous times that Mercurial treats all of history as a series of branches and merges. Really, what we have here are two ideas that are peripherally related, but which happen to share a name.
“Big picture” branches represent the sweep of a project’s evolution; people give them names, and talk about them in conversation.
“Little picture” branches are artefacts of the day-to-day activity of developing and merging changes. They expose the narrative of how the code was developed.
Managing Big-Picture Branches in Repositories
The easiest way to isolate a big-picture branch in Mercurial is in a dedicated repository. If you have an existing shared repository—let’s call it myproject—that reaches a “1.0” milestone, you can start to prepare for future maintenance releases on top of version 1.0 by tagging the revision from which you prepared the 1.0 release.
$ cd myproject
$ hg tag v1.0
You can then clone a new shared myproject-1.0.1 repository as of that tag.
$ cd ..
$ hg clone myproject myproject-1.0.1
updating working directory