tags and multiple heads

[Henryk Gerlach]

Hi,

so I now updated http://www.selenic.com/mercurial/wiki/index.cgi/Tag to more reflect what happens if tags fork.
I still don't document properly how the "history" in .hgtags affects calculation of the winning tag.

I wonder if it's worth the effort to try to resolve a situation which does not have a resolution.

Wouldn't it be more easy (and then consistent over different repositories) to let the head with the latest 
timestamp+node_id win? Sure timestamps lie, but they shouldn't lie much, so that the tags of inactive heads should loose against those of active heads soon.

> > Plus it looks like it is not handeling the nullid-cancling(*) of tags
> appropriately, which IMHO causes
> > http://www.selenic.com/mercurial/bts/issue1102 (**)
> My eyes glazed over after about the first page of that bug report.
;) Yes. But the problem is real and reproduceable.
I boiled down http://www.selenic.com/mercurial/bts/file609/tagfail.txt for you:

hg init ytag1
cd ytag1
echo "This is foo.txt" > foo.txt
hg add foo.txt
hg ci -m "Added foo.txt"

hg tag tag1
echo "This is bar.txt" > bar.txt
hg add bar.txt
hg ci -m "Added bar.txt"

hg update -r 1
echo "This is baz.txt" > baz.txt
hg add baz.txt
hg ci -m "Added baz.txt"

hg tags
#    tip                                3:e18fbd590920
#    tag1                               0:f3befe58b334

hg tag --remove tag1
hg tags
#    tip                                4:8d7ded345cf9

hg update -C -r 2
hg tags
#    tip                                4:8d7ded345cf9


#This is bogus: We add a tag, but it does not show up
hg tag -r 0 tag1
hg tags
#    tip                                5:8b037275628c

Cheers,

   Henryk
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx