Performance question on tags and named branches

[Alistair Bell]

Matt Mackall wrote:
> On Thu, 2009-10-15 at 19:17 -0400, Alistair Bell wrote:
>   
>> Which leads to the problem: my understanding is that any time tags are 
>> consulted, Mercurial builds a union of the .hgtags files at the head of 
>> every named branch. We currently have about 13,000 tags in our repo, and 
>> tag performance isn't a big deal right now -- but once we have over 100 
>> named branches, I'm guessing we might start hitting performance issues.
>>     
>
> Greg Ward, who also has a workflow with a preposterous number of
> branches, added tag caching to 1.3. With any luck, it'll make most of
> this cost vanish, though there are a few more optimization opportunities
> here.
>   
Great. That's just what I was looking for. (Shows how much attention I'm 
paying to the source...)
>> Am I worrying too much? Can Mercurial deal with (say) 20,000 tags in 200 
>> named branches? (Obviously most of the tags will be identical because 
>> they will come from a time before the branch diverged, but I assume that 
>> Mercurial will still need to consult every named branch to know that.) 
>> What is the procedure if different named branches have the same tag 
>> referring to different revisions? (For instance, if we have a 
>> PASSED_REGRESSION tag on the default branch that moves every time we 
>> pass regression, but of course that won't update a branch's tag file.)
>>     
>
> Tags are global, not local to named branches. So you'll need to add
> -<BRANCH> or something to them to localize them. Otherwise, there's a
> magical algorithm that decides which of many duplicate tags is the most
> authoritative that comes into play, which is probably not what you're
> looking for.
>
>   
Well, depending on the details of the magical algorithm, it probably 
will be what I'm looking for. I realize that tags are global -- I was 
just worrying about the fact that given Mercurial merges the tags from 
all the branches, there are going to be times when they conflict. If 
there is a sensible 'oh, this revision marked PASSED_REGRESSION is a 
descendant of that revision marked PASSED_REGRESSION, they probably 
moved the tag forward'-type algorithm, that solves my problem very 
neatly. (<fx: checks the source...>) Ah -- it does almost that: it looks 
at all the revisions that have been tagged with a particular tag and 
takes the latest one. In our case, our tag-merging script uniquifies 
tags in tag files, so if we undo that going forward, it'll work very neatly.

>> I don't particularly want to move to bookmarks, because half the point 
>> is being able to share tags automatically between users, but before I 
>> commit us to a named branch system, I want to see if anyone has looked 
>> at this in terms of performance.
>>     
>
> We've been planning to make bookmarks a first-class core feature with
> push/pull support, but we're not quite there yet.
>
>   
So forgive my ignorance, but what then would differentiate bookmarks 
from tags?

A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20091015/68d60544/attachment.htm