[PATCH 5 of 8] convert extension: Always add tags the same branch

[Brendan Cully]

On Monday, 02 July 2007 at 19:43, Emanuele Aina wrote:
> Brendan Cully preferì:
> 
> >> convert-repo uses to commit tags on the tip. This has 1 pro and 2 cons:
> >>  - it's cool to have tip (tag node) reflect the last real commit node
> >>    hg up -C gives exactly the same working dir
> >>  - the tags commit nodes are floating all around history w/o real logic
> >>    except the user started convert-repo at that precise time
> >>  - If we consider tags are not part of history but they live aside, it's
> >>    just better to really mean this by tagging always on the same branch
> >>    (unamed)
> >>
> >> The proposed solution is to have a fake '0' source changeset that always
> >> points to the last 'update tag' commit. This '0' source changeset is mapped
> >> to a real hg node in the map file, and can be used in a future run to
> >> keep track of this unamed head. The first 'tag' commit is parented
> >> to the first revision.
> > 
> > I don't love this approach. I'd rather have each tag put on the branch
> > to which it applies, so that a later clone -r branch will include the
> > tags that apply. I wrote some code to do this some time ago, but it
> > was before the tag ordering algorithm was fully defined, so it would
> > need updating.
> 
> My biggest concern is to have repeatable conversions: ideally if 
> developers A and B would convert something they should get the same 
> repo, so they can pull or push between each other.

The plan would be to put tags immediately after the revisions they
tag. Tag removal might be a problem, since some back ends don't
provide any kind of event for that. In this (relatively rare) case,
you could probably get repeatability through the new -r option to
convert.