Tag caching, at last

Matt Mackall mpm at selenic.com
Tue Jul 14 09:45:35 CDT 2009

On Tue, 2009-07-14 at 08:41 -0400, Greg Ward wrote:
> 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.)

Yes, rank is a little magical, and I'd have to sit down with the code
for a while to remember all the details. It's best documented/justified
in the mailing list discussion where it appeared, which was a couple
years back now. The basic idea is to deal with conflicting series of
deletions and changes of a single tag on multiple heads - not something
most users will ever encounter.

> > - 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.  ;-)

No worries, my secret plan was to cultivate an expert in tagging.

http://selenic.com : development and support for Mercurial and Linux

More information about the Mercurial-devel mailing list