[PATCH 4 of 5] manifestv2: add support for reading new manifest format

[Gregory Szorc]

On Wed, Apr 1, 2015 at 7:27 PM, Mike Hommey <mh at glandium.org> wrote:

> On Wed, Apr 01, 2015 at 09:19:03PM -0500, Matt Mackall wrote:
> > On Thu, 2015-04-02 at 09:01 +0900, Mike Hommey wrote:
> > > On Wed, Apr 01, 2015 at 10:34:49AM -0700, Martin von Zweigbergk wrote:
> > > > # HG changeset patch
> > > > # User Martin von Zweigbergk <martinvonz at google.com>
> > > > # Date 1427520401 25200
> > > > #      Fri Mar 27 22:26:41 2015 -0700
> > > > # Node ID aca6ee57dddf4b39732833a2bb603dcd19148754
> > > > # Parent  7530c75651b04d04e0871c84dfda487b4e9e96b4
> > > > manifestv2: add support for reading new manifest format
> > > >
> > > > The new manifest format is designed to be smaller, in particular to
> > > > produce smaller deltas. It stores hashes in binary and puts the hash
> > > > on a new line (for smaller deltas). It also uses stem compression to
> > > > save space for long paths. The format has room for metadata, but
> > > > that's there only for future-proofing. The parser thus accepts any
> > > > metadata and throws it away. For more information, see
> > > > http://mercurial.selenic.com/wiki/ManifestV2Plan.
> > >
> > > I have several questions related to that document:
> > > - Since manifest creation is done when committing, what is the plan wrt
> > >   what should happen when a commit with manifestv2 is pushed (server
> may
> > >   not support them, or may not want them even if it does)
> >
> > Not fully decided. Possibly on-the-fly conversion.
>
> The sha1 for a manifestv2 would be the same as the corresponding
> (flattened) manifestv1? O_o
>

I think the point you are trying to make is there would be at least 2
SHA-1s for every changeset, depending on how manifests are computed. That
seems extremely confusing.

Another question: how can an existing repo seamlessly switch to the new
manifest format? Presumably we'll want to "upgrade" the Firefox repo to
both directory manifests and manifestv2 for performance benefits. But since
manifestv2 is a requires-time thing, that would mean rewriting the entire
manifest to v2. And that would change manifest SHA-1's which would
invalidate every existing changeset SHA-1. That's a non-starter for us
unless we can seamlessly handle requests for old changesets (hgweb URLs,
clients updating to old changesets for bisection, etc).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150401/b9790b3a/attachment-0001.html>