Tags in forests. My solution(s).

[Roman Kennke]

Hi there,

> >To make it short, my solution is to implement tags just like
> branches:
> >As simple (f)clones. To be honest, I think the hg tag command is not
> >very useful and seems like something that doesn't really fit. It
> should
> >probably be an extension, not a core command. At least, using clones
> >feels much more natural to HG and avoids many problems that I had
> with
> >hg tag. I think that this approach should be recommended over hg tag,
> or
> >do you generally disagree with that?
> 
> I'm a little bit curious about this, and in particular curious about
> the pitfalls of using snapshots.
> It seems that you've come to a conclusion that in order to tag a
> forest you have a tag tree of fclone'd forests?
> Doesn't that mean  you have a centralized single location for tags? I
> liked the snapshots idea because then the "tags" were as distributable
> as anything else. Perhaps I'm missing something? Could you explain the
> snapshots issues in more details?

Sure. A little background first. I have a central forest on a server, to
which the developers push their changes. I also have an autobuild
infrastructure of several machines, which pull from this central
repository and build the thing and set a tag when it's ok (actually, it
removes old ok tags and sets a new one). This is done for several target
architectures and configuration of the software, so I end up with around
50 different ok tags (one for each possible combination).

The problem with hg tag is that this creates a changeset, which then
needs to be pushed back to the central repository somehow (or could
possibly be handled in a repository private to the autobuild machinery,
but still, it would be a repository that is pushed to by all the
autobuild processes). If anything is pushed to the repository in the
meantime, this would require a merge, with a good chance to trigger a
manual merge, which is not possible in an automated process. I tried to
work around this using a special merge wrapper for .hgtags, but I don't
trust it to work reliable enough to be honest.

Using snapshots in their own repository, the situation is much better
than using hg tag with respect to automatic handling of everything. The
autobuild processes only have to push to this small repository that
holds the snapshots. There's still a good chance that things need to be
merged, but it is almost guaranteed that this can be done without manual
intervention. However, still one thing leaves a bad feeling for me in
this situation: 1. instead of pushing, I'd actually have to either pull
the changeset that adds the snapshot from another repository into the
master repo and merge, or add the snapshot directly to the master
repository. Either way, I'd have to perform multiple commands on the
master repository. Now imagine what happens when multiple autobuild
processes try to do this concurrently. Yes, I could implement some kind
of locking. Yes, I could implement a kind of service, that does all this
from only one process, but both of these solutions add more complexity
to the whole process, but I'd rather prefer to decrease complexity. And
this is exactly what the tagging-by-cloning approach does for me.

I've added this as comment to the original blog post. If you think it
makes sense, I could also add some information to the Wiki somewhere,
but I'd like to hear more of your opinion first.

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