Tag caching, at last

Greg Ward greg at gerg.ca
Mon Jul 13 20:11:00 CDT 2009

On Mon, Jul 13, 2009 at 5:00 PM, Matt Mackall<mpm at selenic.com> wrote:
> Which is why I think strip and friends should simply shoot the cache for
> now, until we can figure out how to be more clever.

I'm worried about the effect that will have on MQ users.  If I'm
qpushing and qpopping on top of a 100-head repo, then I'm also going
to run "hg tip" quite frequently.  And if that takes 10 sec after a
qpop or qrefresh, that would suck.

Now, if "shoot the cache" really means "kindly inform the cache that
head X is being destroyed", that probably wouldn't be so bad.  But
that smacks of cleverness, and I'm getting very leery of clever tag

> Even though I've said I don't want version numbers and that it's ok in
> the future to just switch to a new format/filename, I -do- want to have
> the format more or less pinned down. Even if you don't actually -use-
> the tags you write out for now, I'd rather write them out so we don't
> have to burn a disk format when we do figure out how to use them. Does
> that make sense?

Makes total sense.  But I don't see how caching tags in the form of
"hg tags" output helps.  We've discussed strip/rollback to death, but
they are only part of the problem.

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.

So the only way I can think of that would actually work for caching
.hgtags content is a format something like:

  <headrev> <headnode> [<tagfnode>]
  [...repeat for every head, omitting <tagfnode> for tagless heads...]

  [...contents of .hgtags...]

  [...contents of .hgtags...]

...or some variation on that.  (E.g. a binary format might be faster
since we don't have to parse all those .hgtags representations.)

Anyways: I have a pretty good idea of how to make this all work even
with strip, rollback, and tag rank.  I'm willing to give it a shot if
you want to nail down the format now.  (Please let me know what you
think of a binary format: the pros and cons are fairly clear, but if
you're dead set against it I'll drop the idea.)  But I think writing
tag info to the cache without actually knowing if it will work is
wasted effort.  And I think it should be a distinct patch from the
basic head caching.  At least, I'll do it like that: if you want them
folded together, so be it.


More information about the Mercurial-devel mailing list