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