On Wed, Jan 30, 2013 at 08:30:57AM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Jan 29, 2013 at 4:15 PM, Jeff King <peff@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html