Automatic tagging

[Ezra.Smith at bentley.com]

It's necessary to create a changeset for tags, because tags truly are versioned data. I believe Mercurial is just smart enough to know it should always look at the tip revision of your .hgtags file.

I'm planning to do something similar with a repository-level configuration file. It's a convenient way to let each repository have some centralized config stuff without worrying about how to deliver that data to each clone.

-----Original Message-----
From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com] On Behalf Of Roman Kennke
Sent: Wednesday, April 02, 2008 7:15 AM
To: Matt Mackall
Cc: 'Mercurial'
Subject: RE: Automatic tagging

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


_______________________________________________
Mercurial mailing list
Mercurial at selenic.com
http://selenic.com/mailman/listinfo/mercurial