Re: [PATCH 2/5] add object-cache infrastructure

From: Shawn Pearce <spearce@spearce.org>
Date: Jul 11, 2011, 16:58 UTC
Message-ID: <CAJo=hJvv7a_8FJfHERxdwvMLVkpun-u-hR+ds40JuVNn2Lyb7A@mail.gmail.com>
In-Reply-To: <20110711164635.GB29781@sigill.intra.peff.net>

On Mon, Jul 11, 2011 at 09:46, Jeff King <peff@peff.net> wrote:

Show 14 quoted lines

> On Mon, Jul 11, 2011 at 12:17:54PM -0400, Jeff King wrote:
>
>> +Storage
>> +-------
>> [...]
>> +The disk storage consists of a single file per cache, located in the
>> +`$GIT_DIR/cache` directory. Each file contains a list of rows ordered by
>> +sha1. Each row contains a binary sha1, followed by the fixed-size data
>> +mapped to that sha1.
>
> There's nothing else in the file, not even a header. I should probably
> add at least a version byte, in case we ever do want to change what goes
> into a cache (in which case we could just blow away what's there and
> regenerate).

Please do. We don't always need to invent a new version... but for a cache file its probably more common than the PACK network stream, or the pack-*.idx file. And its painful to shoehorn in a version change after the fact.

Show 14 quoted lines

> We could also have a "validity" field that must match for the cache to
> be valid. Junio mentioned earlier that you would want to regenerate a
> generations cache whenever grafts or replace objects changed. It
> wouldn't be hard to do something like:
>
>  validity = sha1(grafts + replace);
>  if (validity != cache_validity)
>    empty_disk_cache();
>
> And then it would just automatically work, without the user having to
> remember to clear the cache.  Calculating the validity would be cheap in
> the common case (you have no grafts or replace objects), and not much
> more expensive when you do have them (we have to read that data anyway
> to respect the replacements).

This is a pretty good idea too. Saves the hapless user from surprises when they forget the cache exists, but they changed grafts or replace data.

-- 
Shawn.