Tag caching, at last

[Dan Villiom Podlaski Christiansen]

2009/7/12 Greg Ward <greg-hg at gerg.ca>:
>> Imagine two layouts like this:
>>
>>     r1: A
>>      / \
>>   r2: B \
>>          \
>>        r3: C
>>
>>   r1: A
>>    / \
>>   / r2: D
>>  /
>> r3: C
>
> Not sure what you're trying to convey here.  Was that supposed to be
> two states of the same repo that could trip up tag caching?  Please,
> take your best shot and try to trip it up... but I don't understand
> this example.

Yes, they were meant to be two possible states of the same repository;
I'm fairly certain that you can't assume validity of the cache based
only on properties of ‘tip’. I'm a bit busy at the moment, so I'll
just mention some of the cases where I think problems could arise:

- Shared repositories. Is the tag cache shared too?
- Older clients: You cannot rely on intercepting either rollback or
strip, unless you can guarantee that the client performing them will
update the tag cache.
- Really weird behaviour on behalf of the user ;-)

It seems to me that the best way to check validity of the cache is to
check that all heads are unchanged. You could probably get by with
something more fancy, but I suspect it'd be quite hard to do…

For what it's worth, I did a quick benchmarking of localrepo.heads().
Using Python 2.6.1 on a 2GHz Core 2 Duo iMac with a test repository of
55,227 revisions and 101 heads, the results were:

% HGRCPATH=/dev/null python2.6 -m timeit -s 'from mercurial import
demandimport; demandimport.enable(); from mercurial import hg, ui; R =
hg.repository(ui.ui(), ".")' 'R.heads()'
10 loops, best of 3: 106 msec per loop

I don't know if that's too slow, but I also don't see how you can get
around doing a heads() :-/

-- 
Dan Villiom Podlaski Christiansen
danchr at gmail.com