On 05.05.2017 11:09, Johan Corveleyn wrote:
> On Fri, May 5, 2017 at 12:49 AM, Doug Robinson
> <doug.robinson_at_wandisco.com> wrote:
>> Johan:
>>
>> (sorry for the empty message - dwim failed)
>>
>> On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>>> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>>>> Doug Robinson wrote on Wed, May 03, 2017 at 15:54:50 -0400:
>>> ...
>>>>> Not seeing it - at least not yet. In Perl the RE needed to handle
>>>>> this would be one of the duals, e.g. "/trunk/iota(|/.*)" - the
>>>>> either/or with nothing on the left and "/.*" on the right. It really
>>>>> is a dual case. I know of no better syntax. Since we're working on
>>>>> this as a wildcard I don't see an alternative.
>>>> Off the top of my head, we could have [/trunk/iota/***] and
>>>> [/trunk/iota/**] with different meanings (the former applies to
>>>> a /trunk/iota file, the latter doesn't). Does anyone else (besides Doug
>>>> and I) have ideas here?
>>> Hmm, /*** doesn't look like something I'd remember easily, if I wanted
>>> to use that feature as an svn admin.
>>>
>>> I have only followed this discussion from a distance. If I understand
>>> correctly the remaining point is whether or not /iota/** would match
>>> with the file /iota or not. Speaking purely from my own intuition, I
>>> would say "no". I feel this pattern is intended to apply to the
>>> _subtree_ below iota, including iota itself (which is thus implied to
>>> be a directory, because we're talking about subtrees). In practice I
>>> think the admin configuring this rule will know whether iota is ever
>>> intended to be a file or a directory. A rule like that to me always
>>> implies that "the guy who configured it" expects iota to be a
>>> directory (why else would he put a "subtree rule" for it).
>>>
>>> TBH, I also don't really see the use case of "I want this rule to
>>> apply to the _namespace_ iota, i.e. to the file iota (if it's a file)
>>> and to directory iota and its subtree (if it's a directory)". In
>>> context, you always know whether it's meant to be a file or a
>>> directory.
>>
>> The use case is exactly that some administrator wants to reserve
>> the namespace. They do not want some sly person to create a file
>> where they will, at some point in the future, create a directory. It will
>> be sad that we can't have a simple way to make this reservation, but,
>> as I noted above, short of the current "[:glob:/iota/**]" doing the job it
>> will take 2 stanzas.
>>
>>> Maybe we should just follow what most other implementations do?
>>> I've done a quick check in Atlassian FishEye / Crucible (searching for
>>> files). There /iota/** does not match file /iota (but it does match
>>> directory /iota).
>>
>> The FishEye reference I found does not have a "**" operator - just a "*"
>> operator (https://confluence.atlassian.com/jiracoreserver073/search-syntax-for-text-fields-861257223.html).
>>
>> For all cases where a tool has a "*" operator this is semantically going
>> to "not match" this use case since the "*" operator that has been
>> implemented in SVN (at least so far) does not span past a single
>> directory entry.
> Ah. No, I'm referring to this syntax in FishEye:
> https://confluence.atlassian.com/fisheye/pattern-matching-guide-298976797.html
>
> Unfortunately the document does not specify the cases we're interested
> in here. But I've tested them on our own FishEye instance :-). In this
> case "/dir/**" does return /dir, but "/file/**" does not return /file.
> But okay, it's just one example.
>
> In the FishEye doc they say they're doing their pattern mathing "same
> as the pattern matching in Apache Ant". So I've checked ant as well.
> On this page:
>
> https://ant.apache.org/manual/dirtasks.html#patterns
>
> at the bottom of the table they say:
> **/test/** - Matches all files that have a test element in their
> path, including test as a filename.
>
> So I've done a little test in ant (see [1]): apparently "**/test/**"
> will match the file test, but "/test/**" doesn't! Weird. Apparently
> the same goes for FishEye, if I put "**/" at the beginning of the
> pattern, it does match the file.
Before we go too far down this rabbit hole of possible semantics, I'd
like to remind you that in Subversion's authz implementation, the path
matching happens before we know anything about the structure of the
repository. Specifically, we don't know if a particular name in the
pattern even exists in the repository and if it does, whether it's a
file or a directory.
So, any discussion about whether something should match a file or not is
nice in theory, but a waste of time in practice. IMO there is absolutely
no chance of the authz check actually looking at the repository to
determine what kind of object we're looking at: not only would this
require a significant change in the authz architecture, it would also
slow authz checks down to probably an order of magnitude worse than they
were _before_ the current rewrite. A non-starter.
It would be a lot better to discuss if the current behaviour is sensible
given what we know when the authz check occurs.
-- Brane
Received on 2017-05-05 11:22:19 CEST