[PATCH 6 of 6] largefiles: modernize how capabilities are added to the wire protocol

[Yuya Nishihara]

On Sat, 06 Jan 2018 19:42:35 -0500, Matt Harbison wrote:
> On Sat, 06 Jan 2018 15:56:43 -0500, Matt Harbison <mharbison72 at gmail.com>  
> wrote:
> >> On Jan 6, 2018, at 3:09 PM, Augie Fackler <raf at durin42.com> wrote:
> >>> On Jan 5, 2018, at 1:19 AM, Yuya Nishihara <yuya at tcha.org> wrote:
> >>> On Tue, 02 Jan 2018 23:55:08 -0500, Matt Harbison wrote:
> >>>>> On Thu, 28 Dec 2017 08:04:01 -0500, Yuya Nishihara <yuya at tcha.org>  
> >>>>> wrote:
> >>>>>> On Wed, 27 Dec 2017 03:27:58 -0500, Matt Harbison wrote:
> >>>>>> # HG changeset patch
> >>>>>> # User Matt Harbison <matt_harbison at yahoo.com>
> >>>>>> # Date 1514349649 18000
> >>>>>> #      Tue Dec 26 23:40:49 2017 -0500
> >>>>>> # Node ID f2e5631c99e6e2c7e9bac058185c24dd73a04e98
> >>>>>> # Parent  25ecea2ec3d7844c9146bf878fc5093ab33b6e11
> >>>>>> largefiles: modernize how capabilities are added to the wire  
> >>>>>> protocol
> >>>>>
> >>>>> Looks good to me, so queued, thanks.
> >>>>
> >>>> Any thoughts on how the client can let the server know it has the
> >>>> extension loaded, so I can close off the last hole in this series?
> >>>
> >>> CC +indygreg, augie
> >>>
> >>> I think there were some discussion about advertising client's  
> >>> capability,
> >>> but I don't remember.
> >>
> >> OOC, why do we want the client to be advertising that it groks  
> >> largefiles to the server? I have a guess, but I’d like that explained  
> >> before I start trying to figure out what we need to support...
> >
> > I’m not in front of a computer right now, but see this.  I think it is  
> > related to choking on the external flag that it doesn’t understand  
> > without the extension.
> >
> > https://www.mercurial-scm.org/repo/hg-all/file/fa865878a849/tests/test-lfs-serve.t#l189
> 
> To put a little meat on this:
> 
> 1) A requirement should always be added when a commit adding lfs files  
> appears in a repo.  Otherwise cryptic errors occur.  Pulling from a remote  
> server is the last hole I'm aware of.
> 
> 2) The error referenced above is because client and server can't agree on  
> a common changegroup.  LFS forces only changegroup3.  See the error log at  
> the bottom of the test.  (Aside: you previously mentioned aiming to take  
> the experimental shrink wrap off LFS after the next cycle.  But IDK if we  
> want a non-experimental thing depending on something experimental, and IDK  
> how far from being finalize changegroup3 is.)

Isn't that a server issue which should fail gracefully if no common changegroup
version found?

> 3) If changegroup3 is manually enabled, then the server error no longer  
> happens on that clone, but rather the client blows up:
> 
>    $ hg clone -q http://localhost:$HGPORT $TESTTMP/client4_clone --config  
> experimental.changegroup3=True
>    transaction abort!
>    rollback completed
>    abort: missing processor for flag '0x2000'!
>    [255]

The error message can be made less cryptic as the core knows 0x2000 means
REVIDX_EXTSTORED.