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

[Gregory Szorc]

On Tue, Mar 31, 2015 at 5:52 AM, Matt Mackall <mpm at selenic.com> wrote:

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

I'm not changing the format. I'm allowing old clients to recognize the new
format as a no-op. The split to per-filter files ensures that an old client
will never see new format.

This patch is really just insurance against per-filter files landing
multiple days or weeks before a format refactor. If things land at the same
time, the only compatibility concern we have is for bisecting. Although,
I'm not sure if that's worth solving.


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

I think this comment was left over from v1. The plan is to split into
per-filter cache files and not carry anything forward. It's just not worth
the effort.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150401/9641adeb/attachment.html>