Tags fix proposal

[Arne Babenhauserheide]

Am Dienstag 13 Januar 2009 18:45:54 schrieb Matt Mackall:
> I'm pretty sure that's not true in a broad sense and I'm quite certain
> it's not true in the narrow sense of remaining backward-compatible.
>
> As always, I'm willing to be proven wrong, but remember the latter sense
> is the only one that actually matters.

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! 


Both solutions don't need any change to the wire protocol. 


Best wishes, 
Arne
-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://selenic.com/pipermail/mercurial/attachments/20090113/968b4914/attachment.pgp