Potential BC changes to sparse before freeze

[Sean Farley]

Gregory Szorc <gregory.szorc at gmail.com> writes:

> On Sat, Jul 15, 2017 at 1:28 PM, Sean Farley <sean at farley.io> wrote:
>
>>
>> Martin von Zweigbergk via Mercurial-devel <mercurial-devel at mercurial-
>> scm.org> writes:
>>
>> > 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?
>>
>> To me, at least as a non-sparse person, I would expect the behavior to
>> match what Mercurial does for includes/excludes in other places (e.g.
>> convert, filemaps, command-line order, etc.). No?
>>
>
> And I would argue these are all not optimal because they aren't filesets.
> Attempting to shoehorn queries into CLI arguments, config sections, etc
> inevitably leads to limitations because you can't express rich primitives
> that a query language allows you to. In theory, filesets is that query
> language.
>
> That being said, filesets aren't as polished as revsets and I don't think
> they are ready to be used in this capacity. For example, we likely wouldn't
> want to expose all the wdir related filesets to sparse/ignore processing.
>
> Also, attempting to use filesets when including other files containing
> patterns is wonky. The existing [include] [exclude] model where entries are
> unioned does get the job done. We could achieve something similar if we
> invented the concept of named queries and added a fileset function to
> evaluate a named query.
>
> It's worth noting that sparse profiles today can contain "set:" entries to
> yield the power of filesets (the matcher constructor automatically
> recognizes the type of pattern). What we can't do is change how [include]
> and [exclude] interact with each other.

Perhaps this is specialized / nuanced enough that I don't quite follow;
but that's fine. All I wanted to do is point out similar, existing
behavior. If that's already been considered and deemed not suitable,
then ok with me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170715/3bc68b5d/attachment.sig>