Where should we put our tags?

wol simonh at symbian.org
Tue Jan 12 10:32:45 CST 2010


Hi

I'm working with Symbian (symbian.org) in the Integration team. We're using
Mercurial on a large scale, though we've not been going tha long, and we're
very generally happy with it.

The question we're currently considering is whether there's a better
strategy for tagging. At the moment we're tagging our releases with
something like PDK_3.0.b, and the tagging changesets are almost always the
direct children of the tagged changesets and on the same branch.

This means that:
* Many merges are only to merge in updates to the .hgtags file, which feels
redundant, but makes it possible to meaningfully use "default" to get the
latest code change
* If three releases use the same "real" content of a repository, they still
wind up using different revisions because of the update to .hgtags
* The graqphs can get really complicated

We're wondering whether going forward it would be a better idea to separate
all our tagging changesets from our tagged changesets, and put them all on
one branch (called "tags" for want of anything more exciting).

Where it's not too late, the first revision on the tags branch would be a
child of the null changeset, so we'd keep our tag meta-data away from our
code complately. We'd expect to create some hooks to keep them apart as
well.

(I think I recall reading somewhere that Mercurial itself might be changed
to work in such a way in future, but alas I don't remember where that was.)

Has anyone tried this and found it to be a great/terrible idea?

Thanks for your feedback,

Simon Howkins
-- 
Integration
Symbian
London
www.symbian.org
-- 
View this message in context: http://old.nabble.com/Where-should-we-put-our-tags--tp27130328p27130328.html
Sent from the Mercurial mailing list archive at Nabble.com.



More information about the Mercurial mailing list