Automatic tagging

[Roman Kennke]

One thing I don't understand is why tagging and the .hgtags file are
versioned and create a commit at all? In my understanding, tags are
meta-information of a repository, not versioned data. I mean, when I do
hg update 1, I can still do hg update much-later-tag. Why is it
necessary to create a changeset when creating a commit? This shouldn't
be necessary if I understand correctly. And more importantly, it
shouldn't be necessary to merge anything when pushing a tag. And even
more importantly, it should never be necessary to merge .hgtags
_manually_ when pushing the tag. It is not a good idea to let the user
fiddle with internal metadata in this way. I see that .hgtags is a
really simple textual file, but it can still be borked, nobody's
perfect, right?

> If the goal is just to publish a known-good build, why not simply have
> your build engine have a separate "builds" repo it pushes to whenever it
> succeeds?

Generally yes. But we have a lot of different configurations (we build
our software for many different target architectures), and we want to
publish known-good builds for each of them. Add to each target a couple
of different configurations, and you have something like 78 different
configurations, for all of which we currently have our autobuilder
infrastructure setup to build nightly, and set appropriate tags on
successful builds. Maintaining 78 additional repositories only to track
the good builds doesn't seem to be feasible, especially considering that
one repo alone is already huge (>500M).

Any more ideas?

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt