Automatic tagging

[Matt Mackall]

On Tue, 2008-04-01 at 13:01 -0500, Steve Borho wrote:
> On Tue, 2008-04-01 at 19:43 +0200, Andreas Axelsson wrote:
> > > -----Original Message-----
> > > From: Andreas Axelsson [mailto:andreas.axelsson at gmail.com]
> > > Sent: den 1 april 2008 18:46
> > > To: 'Roman Kennke'; 'Mercurial'
> > > Subject: RE: Automatic tagging
> > > 
> > > > -----Original Message-----
> > > > From: mercurial-bounces at selenic.com [mailto:mercurial-
> > > > bounces at selenic.com] On Behalf Of Roman Kennke
> > > > Sent: den 1 april 2008 15:42
> > > > To: Mercurial
> > > > Subject: Automatic tagging
> > > >
> > > > Now, with Mercurial there is one problem. How can the autobuilder
> > > > automatically tag the repository in a reliable way? I mean, it can
> > > tag
> > > > its cloned copy. But the tag needs to be pushed to the master
> > > > repository. However, this will likely abort, and a merge will be
> > > > needed.
> > > 
> > > Would pushing a tag actually require any merging? And if it does,
> > > wouldn't it be the .hgtags file only anyway? That should be pretty easy
> > > to auto-merge, or am I missing something. Or do you submit changes from
> > > the autobuild?
> > > 
> > 
> > Forget what I said, I tried it and it requires merging. I've not use Hg enough it seems.
> 
> At least with 1.0, you can write a special merge wrapper specifically
> for .hgtags.  Such a script should probably get added to contrib/.  Any
> takers?

That may be a good idea.

But more generally, I think you'll find that having an automatic build
engine doing tagging is going to be painful. You'll end up with a commit
per build in your history with no good way of hiding it, long past when
that information is interesting. Add a merge onto that, and it'll get
really ugly.

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?

-- 
Mathematics is the supreme nostalgia of our time.