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

Matt Harbison mharbison72 at gmail.com
Sat Jan 6 19:42:35 EST 2018


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.)

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 check in the other direction is in fa865878a849, along with some  
comments on how largefiles already does this.  (Largefiles doesn't have  
these flags, so I think it is just to ensure the extension is loaded, so  
you don't see the standins.)


More information about the Mercurial-devel mailing list