I found your site and read a few of your other posts. Keep up the good work. I just added your RSS feed to my Google News Reader. Looking forward to reading more from you down the road!

Doug:
>>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.