how to fix the broken tagging system?

Sune Foldager cryo at cyanite.org
Sun Sep 28 14:52:59 CDT 2008


> the last few weeks the way how tagging works in hg was very  
> frustrating. [...]

I tend to agree..partially. In mercurial tags are intrinsic to the  
version graph, while they are bound to each repository in the other  
systems (at least git) instead, and the same with branches. With tags  
I definately like the repository-bound system better, although this of  
course requires a way of sharing and/or refering to other peoples tags.

With branches it's not so simple, as mercurials way of doing them has  
the advantage that you can see on a cset which branch it originates  
on, which is not possible with git-branches. On the other hand,  
mercurial branches has the unfortunate problem that you can't mark a  
branch point without actually committing, which might leave an  
unnecessary head in case the branch is never needed at that point, or  
should be forwarded to a later point in the graph.

We're planning on using mercurial at work for all our sources, which  
will end up in several repositories. We'll then write up some scripts  
to suger things up with multiple repos (the forest extension is not  
quite up for the job; among other things we have big overlap in the  
repo-sets we need to be able to work with). For this use, mercurials  
tags aren't great and the branches (_except_ for the trace it leaves  
in history) is worse. I am pretty sure we're gonna suger up our own  
tag system, using localtags and a separate repo to contain the cross- 
repo tags + some scripts to act as front end (setting and clearing  
local tags).

For branches I might do something similar, although it's not really  
easy. I still want my branches to be mercurial branches _when I  
actually start using them_, but not to do anything before that. The  
bookmarks extension has the same problem as local tags: no remote  
reference, tracking or propagation. It would be great to have both  
concepts in mercurial, letting the user use whatever suits him or her  
best.

Ok, best to end this rant while I still can. At any rate, I'd be happy  
to participate in development and design of such systems :-).

-- Sune.



More information about the Mercurial-devel mailing list