Automatic tagging

[Steve Borho]

On Wed, 2008-04-02 at 13:15 +0200, Roman Kennke wrote:
> 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?

This conversation shows up about once a month on the mailing list.  Many
people want .hgtags revisioned so that the history of tags is
recoverable.  They want to know when tags were moved, why they were
moved, and who moved them.

> > 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).

Less intrusively, the autobuild system could keep a local tags file up
to date with 'last-known-good' tags for each architecture.  The file
only needs one line per target.  It could then be served by http where a
script could fetch it and apply them to a user's ./hg/localtags file

-- 
Steve Borho (steve at borho.org)
http://www.borho.org/~steve/steve.asc
Key fingerprint = 2D08 E7CF B624 624C DE1F  E2E4 B0C2 5292 F2C6 2C8C