Re: [PATCH 3/6] introduce pack metadata cache files

From: Jeff King <peff@peff.net>
Date: Jan 30, 2013, 06:50 UTC
Message-ID: <20130130065036.GB11147@sigill.intra.peff.net>
In-Reply-To: <CACsJy8Af9g9Tdqr0dXyucq-M2aP5U2HvX3ANSsabqtuX=w4Q0w@mail.gmail.com>

On Wed, Jan 30, 2013 at 08:30:57AM +0700, Nguyen Thai Ngoc Duy wrote:

Show 20 quoted lines

> On Tue, Jan 29, 2013 at 4:15 PM, Jeff King <peff@peff.net> wrote:
> > +static void write_meta_header(struct metapack_writer *mw, const char *id,
> > +                             uint32_t version)
> > +{
> > +       version = htonl(version);
> > +
> > +       sha1write(mw->out, "META", 4);
> > +       sha1write(mw->out, "\0\0\0\1", 4);
> > +       sha1write(mw->out, mw->pack->sha1, 20);
> > +       sha1write(mw->out, id, 4);
> > +       sha1write(mw->out, &version, 4);
> > +}
> 
> Because you go with all-commit-info-in-one-file, perhaps we should
> have an uint32_t bitmap to describe what info this cache contains?  So
> far we need 4 bits for date, tree, 1st and 2nd parents (yes, I still
> want to check if storing 1-parent commits only gains us anything on
> some other repos). When commit count comes, it can take the fifth bit.
> Reachability bitmap offsets can take the sixth bit, if we just append
> the bitmaps at the end of the same file.

I thought about having some programmatic self-describing header like that. But it makes the implementation much harder to verify, and it is not like there is much point in picking and choosing those bits. My plan was to do a combination of:

  1. Put truly optional bits into a separate metapack (e.g.,
     reachability bitmaps).

  2. When something becomes obviously obsolete (e.g., we move to
     generation numbers instead of timestamps in commits), bump the
     version number.

-Peff