Tags fix proposal
Michele Cella
michele.cella at gmail.com
Tue Jan 13 21:19:40 UTC 2009
Arne Babenhauserheide wrote:
>
> Personally I think that it's not really a problem of the underlying structure
> but rather of the way it is presented to the user.
>
> Let's look back at the actual problems:
>
>
> 1) "I clone up to a tag and the tag isn't included" -> just automatically add
> a local tag via
> $ hg tag -l TAGNAME
>
> The problem vanishes, since updating to the tag now points to the correct
> revision for the user (even if there previously was a different tag). Local
> clones even keep the local tag (I didn't expect that to just work - I thought
> I'd have to add the local tag again :) - do the tags just not get propagated
> over the wire?).
>
> But we get a new problem: Subsequent cloning from this repo can use the tag as
> target revision, but it will be lost if it isn't named explicitly when
> cloning, so I'm a bit wary that this might create unexpected errors, and I
> don't know if losing that information unexpectedly would be worse than the
> current situation.
>
> $ hg clone http://blah foo
> would lose the tag while
> $ hg clone -r tag http://blah foo
> would keep it.
>
> So there just might not be a usable solution which keeps tag history. If you
> clone up to a specific tag, you always lose the history of the tag - either
> you lose it directly when cloning, or you lose it later on.
>
> Maybe an option to retag would be useable: If I enable the option, hg clone
> gets the history to the tagged revision and then adds a standard tag revision
> as new tip revision. We still lose the tag history, but we keep the
> information where the tag points to. We also wouldn't need a change to wire
> wire protocol for this, since the client knows to which tag we want to clone
> and where it points (tip).
>
>
> 2) "We add different tags without synching first and then have to merge" ->
> Add a specialized merger for .hgtags file which only needs the user on real
> conflicts.
> -> http://article.gmane.org/gmane.comp.version-control.mercurial.general/10958
>
> It wasn't undisputed, but even a merger which only runs into bogus conflicts
> if a conflicting change involves changing a tag of the same name would solve
> most tag problems I assume.
>
> This partial problem hurts (me) the most. I never saw any other kind of tag
> merge conflict (with my limited experience). Two people changing tags at the
> same time happens far more seldom than adding different tags at different
> points in history and then having to merge.
>
> (Incidentally that's also the kind of merge I need for the groups extension,
> so my thoughts may be highly subjective)
>
>
> 3) Is there a problem I forgot? If so, please write it!
>
Regarding point 1) I'm the only one who doesn't see this as a problem?
what's the use case of cloning a repository up to a tag and expecting it
to be present? what if, for whatever reason, you want to clone up to
that tag just because you want to diverge from it and you *do* want the
tag changeset to not be there?
As Matt said I think that in the end the solution adopted by hg is the
best one between all the possible solutions.
Ciao
Michele
More information about the Mercurial
mailing list