[PATCH 2 of 2 mainline] format: introduce 'format.generaldelta=accept'

[Pierre-Yves David]

On 11/08/2015 11:19 AM, Gregory Szorc wrote:
> On Fri, Nov 6, 2015 at 7:47 AM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
> wrote:
>
>     # HG changeset patch
>     # User Pierre-Yves David <pierre-yves.david at fb.com
>     <mailto:pierre-yves.david at fb.com>>
>     # Date 1446479952 0
>     #      Mon Nov 02 15:59:12 2015 +0000
>     # Node ID 2176eee3dd6c33a51fab5cf4b4e0ac4fba034f12
>     # Parent  69c64edb25dd96a23564db5b23b8b432b343ec88
>     # EXP-Topic generaldelta
>     # Available At http://hg.netv6.net/marmoute-wip/mercurial/
>     #              hg pull http://hg.netv6.net/marmoute-wip/mercurial/
>     -r 2176eee3dd6c
>     format: introduce 'format.generaldelta=accept'
>
>     This value will make repository created as general delta by default
>     but will not
>     make Mercurial aggressively recompute delta for all incoming bundle.
>     Instead,
>     the delta contained in the bundle will be used. This will allow use
>     to start having
>     general delta repository created everywhere without triggering massive
>     re-computation cost for all new clients cloning from old server.
>
>
> I'll raise a similar objection that I raised IRL at the Sprint: I find
> overloading format.generaldelta to be both a bool and a special string
> value to be somewhat confusing. It feels like there are two separate
> intents we wish to communicate: a) create revlogs with generaldelta b)
> whether to force generaldelta on imported data. Shoehorning them into
> the same config doesn't tickle me the right way.

This is sensible concern but I'm not sure what is the best answer there. 
By chance, we have 2 months to go until the freeze so I'm sure "Someone 
who care enough about it" ;-) will figure out what we should do in that 
interval.

> I also think I brought this up at the sprint, but I had this idea of
> allowing additional controls for forcing generaldelta. e.g. if the
> incoming changegroup is only 20 changesets, it's probably fine to take
> the re-encode hit. But if it's 2000 changesets, then we may want to
> avoid re-encoding.

I'm open to improvement in that area, but done is better than perfect. 
I, personnaly, focussing on getting some form of generaldelta enabled by 
default. Anyone who want to push that further is welcome to do so.

I remember a couple of other point discussed that the sprint and I think 
we agree you would look at them by the freeze. So we have plently of 
time to adjust our approach here.

Cheers,

-- 
Pierre-Yves David