Automatic tagging

[Roman Kennke]

Hi,

> 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 see. I think I have to solve my problem differently then. It seems
like fsnap and fseed would be a solution (call fsnap to create a
snapshot on a good build, store that in the autobuilder database, and
use fseed to re-create a known good build).

/Roman

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