> On Jan 15, 2018, at 12:21 PM, Matt Harbison <mharbiso...@gmail.com> wrote: > >> >> On Jan 15, 2018, at 11:20 AM, Augie Fackler <r...@durin42.com> wrote: >> >> >>> On Jan 7, 2018, at 1:18 PM, Matt Harbison <mharbiso...@gmail.com> wrote: >>> >>> On Sun, 07 Jan 2018 02:08:58 -0500, Matt Harbison <mharbiso...@gmail.com> >>> wrote: >>> >>>>> On Sun, 07 Jan 2018 01:28:22 -0500, Yuya Nishihara <y...@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 <mharbiso...@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.
We’re generally more relaxed for things that only matter for experimental code, and UX improvements can happen if they’re important enough. Ugh, I forgot the freeze. We might need to do this UX improvement in the next cycle as part of making lfs not experimental... _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
