Tags in forests. My solution(s).

[Doug Philips]

On Friday, June 06, 2008, at 03:32PM, "Roman Kennke" indited:
>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.

I'm still confused... what "things" are at risk of merge conflicts here?
Are you saying that more than one automated process would be trying to create
"tags" with the same name? I had assumed from your post and comments that
each tag (of the 50) was unique...

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

Whoa, why would you have to pull anything anywhere?
Aren't the tags just meta-data that lives in your own separate meta-data repo?
Right now, if I read your post and previous messages correctly, you are making
the tags by fclone-ing into a single, well-known, centralized place.
If that place were instead a repo in which only the auto-builders commited
their tag updates, and from which everyone else (if they cared, and I'm not sure
from your description if anyone but you does care) could pull?

My primary assumption here is that each autobuilder has exclusive control over
its tag(s)... maybe that assumption isn't true?

    --Doug