[PATCH STABLE] revlog: add an experimental option to mitigated delta issues (issue5480)

[Augie Fackler]

On Sat, Jul 01, 2017 at 03:40:18PM -0700, Sean Farley wrote:
>
> Gregory Szorc <gregory.szorc at gmail.com> writes:
>
> > On Fri, Jun 30, 2017 at 4:43 PM, Sean Farley <sean at farley.io> wrote:
> >
> >>
> >> Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:
> >>
> >> > On 06/27/2017 01:16 PM, Pierre-Yves David wrote:
> >> >> # HG changeset patch
> >> >> # User Pierre-Yves David <pierre-yves.david at octobus.net>
> >> >> # Date 1498218574 -7200
> >> >> #      Fri Jun 23 13:49:34 2017 +0200
> >> >> # Branch stable
> >> >> # Node ID 33998dea4a10b09502bf458e458daca273a3f29a
> >> >> # Parent  231690dba9b4d31b5ad2c93284e454135f2763ca
> >> >> # EXP-Topic manifest
> >> >> # Available At https://www.mercurial-scm.org/
> >> repo/users/marmoute/mercurial/
> >> >> #              hg pull https://www.mercurial-scm.org/
> >> repo/users/marmoute/mercurial/ -r 33998dea4a10
> >> >> revlog: add an experimental option to mitigated delta issues (issue5480)
> >> >
> >> > Any news on this? 4.2.2 is tomorrow and I think it is really important
> >> > to have it available for all people. This issue is really serious.
> >> >
> >> > (small extra number: the config shrink the pypy repo manifest by an
> >> > extra half compared to just using aggressivemergedeltas (50MB → 25MB))
> >>
> >> I agree that this makes some repos basically unusable (which we've seen
> >> here sometimes). Since it's behind a flag, I'll go ahead and queue this
> >> for stable in a bit. If someone else in crew disagrees, we can dequeue
> >> it.
> >>
> >> Queued (for the patchwork bot)
> >>
> >
> > I don't believe this patch is appropriate for stable because it is a new
> > feature. Introducing excessively long delta chain segments will result in
> > high memory usage and clients doing uncompressed clones will inherit that
> > excessive memory usage. I'd rather we land this on default along with a
> > refactor to revlog reading so we don't incur excessive read I/O for long
> > spans. I'd also prefer to stick the option directly in [format] and mark it
> > as experimental via a comment. That's what we do for all the other revlog
> > options in _applyopenerreqs().
>
> That's fair. I was on the fence about this anyways. Though, I did like
> that _something_ would make these repos usable. I just noticed that the
> commit has been marked public; don't know how strongly you feel about
> this so up to you on how to proceed.

I agree this is unsuitable for stable. How do we want to proceed?

(I'll hold the 4.2.2 release until we get consensus here.)