Potential BC changes to sparse before freeze

Martin von Zweigbergk martinvonz at google.com
Tue Jul 11 16:17:42 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.

I think I'm against this. I think it's clearer that excludes trump
includes if they appear after. Of course, *I* can continue to write it
that way and we can let anyone choose their own order, so it won't
really make a difference to me. What's the reason you want to be able
to put excludes before includes?

Speaking of that, one change I'd like to make is so that an empty
sparse config matches nothing. Maybe that's already the case, but I
wouldn't be surprised if it matched everything.


More information about the Mercurial-devel mailing list