[PATCH 5 of 5 RFC] exchange: support phases discovery via public heads

[Martin von Zweigbergk]

The updates to the discovery protocol sound interesting even though I don't
know much about it. Worth taking about at the sprint? Or perhaps it will be
pretty clear after the Plan page is created...

On Sun, Feb 21, 2016, 01:22 Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 02/21/2016 01:12 AM, Gregory Szorc wrote:
> > On Sat, Feb 20, 2016 at 9:20 AM, Pierre-Yves David
> > <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
> > wrote:
> >
> >
> >
> >     On 02/16/2016 03:03 AM, Gregory Szorc wrote:
> >
> >         # HG changeset patch
> >         # User Gregory Szorc <gregory.szorc at gmail.com
> >         <mailto:gregory.szorc at gmail.com>>
> >         # Date 1455588068 28800
> >         #      Mon Feb 15 18:01:08 2016 -0800
> >         # Node ID d51ed0ddd05c3c716df5fbd2e811285bcac7366c
> >         # Parent  8b939990c70a4e545f18db3338f7798f09a94ada
> >         exchange: support phases discovery via public heads
> >
> >         Now that we can detect when the server supports exposing phases
> via
> >         public heads, we leverage this namespace as part of phases
> >         discovery.
> >
> >         On Mozilla's Try repository, the phases listkeys response drops
> from
> >         ~64k entries / 2.8 MB to < 1000 entries and < 65 kbytes.
> >
> >
> >     I think the discovery process need an overall rework, There is
> >     multiple types of data running there own discovery with a lot of
> >     overlap and race condition.
> >
> >     I would rather go in that direction instead. What do you think?
> >
> >
> > I agree that discovery needs an overhaul. I'm scared about how much work
> > that will be. I was kinda hoping to make incremental improvements to
> > phases (this series) and improve discovery in a few key scenarios (such
> > as a force push of a single head to a mega-headed repo and perhaps a
> > mode that does discovery without taking non-public changesets into
> > consideration).
>
> I think we can make small steps here. Changing the protocol to be
> extensible (sending multiple types of data per roundtrip) and then we
> can slowly extend the type of data we need.
>
> > Since you are the discovery guru, would you mind starting a *Plan wiki
> > page documenting the existing discovery deficiencies so I can start
> > brainstorming?
>
> Good idea, I'll try to get that rolling soon. Thanks for the nudge.
>
> --
> Pierre-Yves David
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160221/3e954c7d/attachment.html>