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

[Matt Mackall]

On Wed, 2015-04-01 at 17:05 -0700, Gregory Szorc wrote:
> 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.

By "old clients" here, you mean "clients that have this changeset",
right? I'd rather you just bump the name to tags1 (or tags0 if this
isn't compatible with your end result).

It also might make sense to add the filenode cache first to have less
staging?

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

I bisect many times a week, so it matters to me at least.

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

Great.

-- 
Mathematics is the supreme nostalgia of our time.