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

Augie Fackler raf at durin42.com
Mon Jan 15 11:20:20 EST 2018


> On Jan 7, 2018, at 1:18 PM, Matt Harbison <mharbison72 at gmail.com> wrote:
> 
> 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 think if we can come up with a kludge to enable lfs during clone, that’s the best choice. Otherwise you end up throwing away all the clone progress and force a re-clone after changesets and manifests were already transferred, which is a pretty lousy user experience.

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

Yeah, it does. I think there’s some amount of sanity here, we just need to reason carefully about it for security reasons. For now, I’d be totally fine with a whitelist of extensions to allow clone to force to on, and some bundle part to request that (or just automatically do it for lfs if we can figure out how without the overhead of an extra part.)

AF


More information about the Mercurial-devel mailing list