Design of persistent tag cache

[Greg Ward]

On Sun, Jul 5, 2009 at 3:15 AM, Dirkjan Ochtman<dirkjan at ochtman.nl> wrote:
> I'm confused. First you say you save one line per head (<node> <rev>
> <tag-node>). Then you say you can't know if we're stripping? Seems to
> me that stripping will always result in losing or changing one of the
> heads.

The cache just stores the current heads.  So most commits will
"remove" a head.  A normal linear commit actually replaces one head
with another; a merge replaces two with one; and a strip replaces one
with none (assuming you strip a whole branch right back to its root).
Only a branching commit actually adds a head.

Validating the cache has to be fast, so I don't want to start walking
the graph to try to figure out if "head 029ab0f gone" was a normal
commit, a merge, or a strip.  All I have at hand is the list of heads
in the cache and the list of current repo heads.

Furthermore, in the case of a normal commit or a merge, it doesn't
really matter.  The tag info on the old head will still be present in
the head that replaced it.  Removed tags will still be removed because
of the way .hgtags is updated.  (I'm not positive that "hg rm .hgtags"
will work correctly though, and that's another issue that might be
improved by my more larger/more complex cache design.)

But if you strip a head, then the .hgtags info on that head is gone.
Any tags added (or removed) on the stripped branch are no longer
present (or are still present).  Retrieving tags from the cache must
reflect that, and I don't see how to do that without tracking the
.hgtags content from each head.  (Or at least from each head that
contributes a unique version of .hgtags.)

It's a solvable problem.  I'm just concerned that there might be a
simpler solution that I'm not seeing.

Greg