[PATCH 2 of 2] setdiscovery: stop limiting the number of local head we initially send

[Martin von Zweigbergk]

On Wed, Apr 17, 2019 at 3:36 AM Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 4/17/19 5:59 AM, Martin von Zweigbergk wrote:
> >
> >
> > On Tue, Apr 16, 2019 at 11:41 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 octobus.net
> >     <mailto:pierre-yves.david at octobus.net>>
> >     # Date 1555428398 -7200
> >     #      Tue Apr 16 17:26:38 2019 +0200
> >     # Node ID ffaa98def33a903f132ec4177d36823a741b6ef6
> >     # Parent  017778a4463a8e6ecb4b17cacf46a3ab27bdb239
> >     # EXP-Topic discovery-speedup
> >     # Available At https://bitbucket.org/octobus/mercurial-devel/
> >     #              hg pull
> >     https://bitbucket.org/octobus/mercurial-devel/ -r ffaa98def33a
> >     setdiscovery: stop limiting the number of local head we initially
> send
> >
> >
> > I think I tried something like this before. I still have a commit in my
> > repo. I don't remember why I didn't send it. Perhaps the issue was that
> > the heads are sent in HTTP headers and we need to limit the size of
> > those to work with restrictive proxies and servers?
>
> My intuition is that we are going to it that limit later anyway (eg: in
> the getbundle common parameters).
>

IIRC, we split up the HgArgs header when it gets too big. I don't know
about the getbundle parameters.


>
> What is our way forward here?


Perhaps capability-guarded support for putting it in the request body? We
already have support for that with experimental.httppostargs. I don't know
if that also replaces GET requests by POST requests (and I don't know if
the server accepts either method), so perhaps we'll need another capability
here. Augie?

This provide a large boost that I would
> rather have in 5.0 core instead of having to patch it all around. Should

we hide the behavior behind a config as a start?
>

I'd be fine with making the limits that are currently 100 and 200 both
configurable (as experimental options).


>
> Cheers,
>
> --
> Pierre-Yves David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190417/c69afb7c/attachment.html>