Best practices for tagging on branches
L. David Baron
dbaron at dbaron.org
Fri Apr 24 18:35:21 CDT 2009
While writing a somewhat hacky importer to import some rather ugly
svn repositories I had (which standard tools wouldn't deal with,
since I didn't follow the rules about /tags/ and /branches/
consistently), I realized that hg tagging on branches is somewhat
fragile. In particular, it's possible to have two repositories that
have the same set of changesets in which hg tags in the repository
have different meanings. This is the case because the meaning of hg
tags is determined from the .hgtags file on *all* heads of the
repository and the order of those heads in the repository, and the
order of heads between repositories can be different even if "hg
outgoing" and "hg incoming" say those repositories are the same.
It's not clear to me that hg could have avoided this issue easily.
But it seems that it is possible to describe best practices that can
prevent it from causing problems.
The best practice that comes to mind is that tags should not be
committed on branches that are not intended to be merged. (An
example of a branch that is not intended to be merged is a release
branch Mozilla uses. We create a named branch, commit the version
number change to it replacing "3.5b4pre" with "3.5b4", and then tag
the commit with the changed version number; see an example at
http://hg.mozilla.org/releases/mozilla-1.9.1/log/a476cb442514 .)
The current procedure Mozilla uses for this is essentially:
hg branch release-branch-name
[ modify version number and commit change to branch ]
hg tag release-name
hg ci -m"Tagged release-name."
Instead, it seems safer to avoid having multiple heads in the
history of the .hgtags file, by committing tags only to heads that
are intended to be merged, e.g:
hg branch release-branch-name
[ modify version number and commit change to branch ]
hg up -rdefault
hg tag -rrelease-branch-name release-name
hg ci -m"Tagged release-name."
Does this practice seem worth documenting? Does it have any
disadvantages that I'm not aware of?
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
More information about the Mercurial
mailing list