Design of persistent tag cache

Dmitriy Taychenachev dimichxp at
Mon Jul 6 10:18:48 CDT 2009

En lun, Jul 06 2009, Greg Ward skribis
> 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.)

Doesn't this rely on `append-only' nature of .hgtags? I think ignored
disappeared heads would make cache's contents completely invalid if
someone will edit .hgtags manually. While it is recommended to use 'hg
tag', it is not enforced.

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

I propose simple enhancement of current scheme - reference counting of
every tag. This means we need to add extra field, answering to the
question "how many unique .hgtag revisions has exactly this tag?". This
keeps cache validation fast and simple, and turns cache updating to
"increment counter of each tag in newly added .hgtags revisions,
decrement counter of each tag in .hgtags revisions going to be deleted
or not referenced by any head, if counter of some tag turns to zero, it
is deleted." This makes strip's cache update
O(deleted_heads+added_heads) instead of O(all_heads_after_strip).

More information about the Mercurial-devel mailing list