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

Matt Harbison mharbison72 at gmail.com
Sun Jan 7 13:18:24 EST 2018


On Sun, 07 Jan 2018 02:08:58 -0500, Matt Harbison <mharbison72 at gmail.com>  
wrote:

> On Sun, 07 Jan 2018 01:28:22 -0500, Yuya Nishihara <yuya at tcha.org> wrote:
>
>> 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:

>>> 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.
>
> I'd be fine with mentioning 'enable lfs' from here if we can sort out  
> the changegroup3 issue.  Are there any cache issues to worry about with  
> the rollback?  (I keep seeing that strip isn't cache friendly, so I  
> assume rollback isn't either, unless they are part of the transaction.   
> Presumably knowing capabilities up front would fail fast.)

On second thought, maybe not.  Existing clients won't be able to handle  
this.  Granted, they won't be able to do LFS period.  But largefiles is  
able to tell the client "please enable the largefiles extension" no matter  
the client version, which seems more user friendly.

I guess the amount of work determines whether or not it's worth it.  I  
assume some other extensions could use this too.  (e.g. does a clone of a  
sparse/narrow clone require sparse/narrow to be enabled?)


More information about the Mercurial-devel mailing list