Tag caching, at last

Greg Ward greg at gerg.ca
Tue Jul 14 07:41:59 CDT 2009


On Mon, Jul 13, 2009 at 10:46 PM, Matt Mackall<mpm at selenic.com> wrote:
>> The final straw for me was tag rank.  If we only cache (say) the
>> output of "hg tags", then the info needed to compute tag rank is gone.
>>  The only place to find that info is in the .hgtags file on each head.
>>  So I think caching tag info only works if we cache the same info
>> that's in .hgtags on every head... in which case, why not just read
>> .hgtags directly, since we've already avoided the expensive part and
>> cached all those fnodes.
>
> Uh, why do we care about rank?

One of my abandoned implementations foundered on tag rank.  It's
because I was reading partial .hgtags content from the cache and full
info from the filelog.  You can probably see why this didn't work, but
it took me a while to get it.

(Aside: the only documentation of the "tag rank" concept appears to be
a cryptic comment in the code and a brief remark in a bug report.
Google for "mercurial tag rank" to see what I mean.  Personally, I now
understand the code, but not the rationale.  At the very least, a
longer comment in the code would be nice, or maybe a blurb in the wiki
somewhere.)

> - taking your fast solution
> - writing out cache of final tag to node mapping
> - if NOTHING has changed on read by (tip revision/hash match), return
> cached tag list

Got it.  Or at least I think I'm getting it.  Slowly.  Sorry if it
feels like you're stuck teaching the remedial class.  ;-)  I was
thinking that "if we cache .hgtags content, we have to use it even in
the fast case" ... but that will only work if we cache all the info in
every .hgtags rev.  And now I see that we can let fast be merely fast,
as long as we *have* an "instant" case.

I'll see what I can whip up!

Greg



More information about the Mercurial-devel mailing list