[PATCH 1 of 4 tags-cache-split] tags: make tags cache compatible with future split of filenode cache

[Matt Mackall]

On Sun, 2015-03-29 at 23:14 -0700, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc <gregory.szorc at gmail.com>
> # Date 1427258716 25200
> #      Tue Mar 24 21:45:16 2015 -0700
> # Node ID 31716032c6e7f8764a02b212dac872cc3436c052
> # Parent  2cb6b78cf818a082ee9a2518968f88c1819efed0
> tags: make tags cache compatible with future split of filenode cache
> 
> Upcoming patches will split the tags cache into separate, per
> filter files as well as split the .hgtags filenode cache into a
> standalone file. Doing this atomically in one commit would be a
> massive, difficult-to-comprehend patch.
> 
> This patch adds future-proofing to tags cache reading so this work
> can be split across multiple commits.

Our usual pattern for changing cache formats is:

- bump the name to something new
- delete the code for the old format

This has the benefit that old and new clients can interact with the same
repository without butting heads and (in this rare case) we don't need
to keep around any legacy code.

Alternately, add a wholly new cache on the side without touching the
existing one. This is what the revbranchcache did.

Since you're changing the format without changing the name, you've
killed people sharing repos on NFS and CIFS.

> With this patch applied, clients are able to recognize the planned
> future format of the tags cache with external .hgtags filenode data.
> When support for that cache lands, clients can read existing .hgtags
> filenode data from the prior tags cache files and then write out the
> new file format without having to recompute .hgtags filenodes. For
> users of large repositories, this will potentially save minutes of
> wall time.

Yeah, but don't we already have a bunch of recomputing that this is
fixing? I don't think eliminating this one-time cost is worth any extra
engineering.

-- 
Mathematics is the supreme nostalgia of our time.