Potential BC changes to sparse before freeze

Gregory Szorc gregory.szorc at gmail.com
Tue Jul 11 15:50:02 EDT 2017


On Tue, Jul 11, 2017 at 12:44 PM, Durham Goode <durham at fb.com> wrote:

>
>
> On 7/11/17 11:01 AM, Gregory Szorc wrote:
>
>> Durham, et al:
>>
>> 4.3 freeze is in a few days. While we have declared sparse as an
>> experimental feature and not subject to BC, shipping in 4.3 means
>> someone will inevitably use it and be impacted by future BC. (Probably
>> Mozilla for Firefox CI). I'd like to get in as much BC before 4.3 as
>> possible.
>>
>> Here are some changes I'm proposing. Are any of them too controversial?
>>
>> * Require a [section] in sparse config files. Right now, if there is no
>> section, entries go in [includes]. I think less magic is better. This
>> could break sparse profiles in old revisions in repos using sparse
>> today. Should be easy to monkeypatch over in an extension if you need
>> old behavior. Or we could add a function argument to control parsing
>> strictness.
>>
>
> +1. I don't think we rely on the old behavior anywhere.
>
> * Remove requirement that [excludes] come after [includes]. This seems
>> arbitrary. Requirement may stem from implicit default [includes]
>> section. I doubt this will cause real world bustage.
>>
>
> Sure, but the docs should be clear that order doesn't matter.
>
> * Add a repo requirement to use sparse and add the requirement when
>> sparse is activated on a repo. The way it is today, if you enable sparse
>> then use an old hg or an hg without sparse enabled, the sparse-less hg
>> sees an incomplete working directory and reports a bunch of missing
>> files. Not cool. It feels like we need to lock out clients that aren't
>> sparse aware from interacting with a working directory that has sparse
>> enabled.
>>
>
> As long as `hg sparse --reset` also remove that requirement.
>
> It'd be nice if the there was some documentation online or such that told
> old-hg users how to recover (remove sparse from .hg/requires && hg
> debugrebuilddirstate && hg revert --all)
>
> I'm also thinking about potentially massive changes to how sparse
>> configs work. Namely, I'd like to unify the file format with hgrc so we
>> don't have N+1 config file formats. That's obviously a massive BC break.
>> And I'm not sure we could land a refactor before the freeze. So we may
>> have to deal with the BC hit in the future.
>>
>
> I'd have to see more details on this.  My concern with hgrc files is that
> config keys can alias very easily, and the composing, multi-owner nature of
> sparse profiles could mean we'd hit this more frequently than with hgrcs.
>
>
> Again, I'm trying to walk a tight rope between what is best for
>> Mercurial and that doesn't inconvenience existing sparse users (notably
>> Facebook). I'll try to formulate any patches that make BC changes in
>> such a way that old behavior can be restored easily via an extension.
>>
>
Without typing up a formal proposal, I'd like to reuse the low-level config
parser - not the higher-level config layer baked into ui.py. I /think/ that
prevents things like aliases from creeping in. I'd also like to think about
how to use e.g. a .hgsparseprofiles file for centrally defining some
profiles. Right now you have to know the path to a profile in the repo.
This means repos can't do nice things like automatically advertise common
profiles for users to use. If you have a central file defining multiple
profiles, then you need sections. And all of a sudden a custom config
format and parser seems a bit redundant.

I'll try to come up with a more formal proposal...

Thanks for the feedback!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170711/710a188f/attachment.html>


More information about the Mercurial-devel mailing list