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

[Matt Harbison]

> On Jan 15, 2018, at 11:20 AM, Augie Fackler <raf at durin42.com> wrote:
> 
> 
>> 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 there are two cases here then. I wasn’t thinking of clone separately, but that does sound like an improvement.

The case I’m thinking of is an existing non-LFS repo, Alice enables the extension on the server and pushes LFS content. Somehow Bob needs to know when he pulls into his existing repo. It doesn’t sounds like a clone kludge helps with this?

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

Definitely gonna need someone with protocol knowledge to do that, and my priority before the freeze is landing the .hglfs file support. What sort of rules are in place for experimental stuff, the freeze, and obvious UX improvements like clear error messaging?  I thought some stuff was taken recently (maybe for terse status) that wouldn’t usually fly during a freeze.