Potential BC changes to sparse before freeze

Martin von Zweigbergk martinvonz at google.com
Mon Jul 17 12:14:43 EDT 2017


On Mon, Jul 17, 2017 at 8:58 AM, Gregory Szorc <gregory.szorc at gmail.com> wrote:
>
>
>> On Jul 17, 2017, at 07:10, Augie Fackler <raf at durin42.com> wrote:
>>
>>> On Sat, Jul 15, 2017 at 03:15:08PM -0700, Sean Farley wrote:
>>>
>>> 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:
>>>>>
>>>> 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.
>>
>> We tried using straight filesets for narrowhg's include/exclude logic,
>> and it was thornier than we'd have liked. So far being a little more
>> restrictive has simplified both server implementations *and* not
>> caused any end-user problems.
>
> Would the concerns apply if the fileset were limited to basic operators (+ - & !) and pattern matching (glob and re)?

I think we can use the same syntax for sparse and narrow but have
different restrictions on allowed patterns. Narrow should probably not
support glob and re.

Concerns that narrowhg has that sparse doesn't:

* The required parent directories needs to be well-defined. The client
and server need to agree on what parent directories are needed. This
means that patterns like "**/*.c" will work for reducing number of
filelogs, but not manifest logs. That can still be useful, depending
on how many directories you have. Importantly, the server and client
also need to not change their opinion about what directories are
needed over time. Specifically, if a visitdir() is not currently
optimized for a certain pattern, it can never be in the future either
(if it was one of the patterns we supported with narrow). Therefore, I
think we should be careful to explicitly support a very limited subset
of patterns once we add support for narrow in core. Regular
expressions and globs should probably not be allowed.

* The patterns have to be consistent across all versions (narrowhg
doesn't support having a the manifest/file at a on revision and not at
another). If we want to read patterns from versioned files, we'd
probably want to union the includes and across all versions.

>
> That's a good point on server implementations: reinventing a query language parser is a bit of scope bloat.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list