[PATCH 4 of 4] revlog: add an aggressivemergedelta option

[Matt Mackall]

On Mon, 2015-08-31 at 15:53 -0700, Durham Goode wrote:
> 
> On 8/31/15 3:48 PM, Matt Mackall wrote:
> > On Sun, 2015-08-30 at 15:09 -0700, Durham Goode wrote:
> >> # HG changeset patch
> >> # User Durham Goode <durham at fb.com>
> >> # Date 1440968612 25200
> >> #      Sun Aug 30 14:03:32 2015 -0700
> >> # Node ID ffaccbf9565ec5f73ded2ae3f9f611c943baad17
> >> # Parent  03338124de4c33848974b5a512d4e6ef71b4424b
> >> revlog: add an aggressivemergedelta option
> >>
> >> This adds an option for delta'ing against both p1 and p2 when applying merge
> >> revisions and picking whichever is smallest.
> > I've queued all four of these, thanks.
> >
> >> Some before and after stats on manifest.d size:
> >>
> >> internal large repo:
> >> before: 1.2 GB
> >> after: 930 MB
> >>
> >> mozilla-central:
> >> before: 261 MB
> >> after: 92 MB
> > This is big enough that I'd probably consider just enabling it all the
> > time. Two considerations here:
> >
> > - bandwidth is typically scarcer than CPU
> > - it's a one-time cost at commit, rather than an on-going cost
> >
> It's not actually a one-time cost though.  A user pulling the merge 
> commit will build a delta against p1 (hopefully the downloaded delta 
> provides this, so it's free), but then he will also compute the delta 
> for p2, which involves decompressing the manifest, etc.  So pulling N 
> merge commits will incur at least N extra manifest decompressions.

Ahh, right.

> We could probably make it smarter by saying 'if the server gave me a p1 
> delta, don't even bother with p2 unless we're going to result in a 
> fulltext'.

Or else we could say "I've observed the server pick the modern choice
instead of the old choice correctly, going to trust it for the rest of
the pull". Might be too complex.

-- 
Mathematics is the supreme nostalgia of our time.