On Wed, May 10, 2017 at 11:37 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Wed, May 10, 2017 at 5:40 PM, Doug Robinson
> <doug.robinson_at_wandisco.com> wrote:
>>
>> Johan:
>>
>> Sorry for my sporadic replies... bin a bit hectic here.
>>
>> Reply buried deep below.
>>
>> On Fri, May 5, 2017 at 5:09 AM, Johan Corveleyn <jcorvel_at_gmail.com> 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.
>>>
>>> Now, getting back to your use case: "reserving a namespace for future
>>> use" (i.e. for now we don't know whether "iota" will ever be a file or
>>> a directory, but in any case we don't want anyone to put anything
>>> there). To me it sounds like a very special use case. It seems to be
>>> something specific for authorization syntaxes, but much less
>>> applicable to searching existing filesystems (like glob patterns for
>>> shells or tools like FishEye). So maybe it's not such a good idea to
>>> look at those tools for inspiration anyway :-).
>>>
>>> Doug: do you think this is a common use case? Do other authorization
>>> systems offer this functionality in an easily configurable manner? I
>>> accept this is a valid use case, but it's not one that I would think
>>> of using (wearing my hat of svn admin) -- I focus on authorization of
>>> the existing files / directories.
>>
>>
>> It's a very common use case. Think of it in terms of allocating all release
>> branches to the release team. Or all Quality Assurance tags to the QA team.
>
> OK
>
>>>
>>> Come to think of it: if reserving a namespace for future use, and
>>> "/iota" doesn't exist yet, can't you just block the name "/iota"
>>> without glob pattern? It doesn't exist anyway, so if you'd like to
>>> create some subtree under it, you first have to create /iota, right?
>>
>>
>> There's 2 problems with this:
>>
>> 1. You're not trying to block the name "/iota", you're giving out privs to the
>> right team for creating (and nobody else).
>>
>> 2. The "**" operator is very special in that it does a "direct match" of all
>> at or below. That "direct match", in terms of wildcards, means that there
>> is no "recursing upwards" to find a parent rule. It's matched immediately.
>>
>> Consider multiple repositories in an organization (perhaps they have code
>> that cannot go to vendors with which they share some repos so they cannot
>> keep all of their projects within a single repo - or similar use case). A global
>> policy would have identical rules for all repositories. They can't know when
>> or if some subset of the repositories have the specific artifact or not.
>> It would be nice/handy/convenient if a single rule could do the reservation
>> rather than a pair.
>
> Okay, thanks for clarifying. It's all starting to make sense to me now :-).
>
> So the "reserve namespace" usecase is common and important, and it
> sounds very sensible to want to do this with a single rule. And the
> "**" matching is better at doing this than the "/iota" rule. Got it.
>
>>> Now, in the end, I don't want this issue to be blocked forever :-). I
>>> think in practice the confusion will be minimal, because either the
>>> administrator knows what kind of item "iota" is (a file or a
>>> directory), or the item doesn't exist yet and he'll be doing the
>>> "reserve namespace" use case. So for me it's fine if "/iota/**"
>>> effectively matches both the "directory iota and its subtree" and "the
>>> file iota". As long as it's documented that way then :-).
>>
>>
>> My document does that since that is the way that the branched
>> implementation for SVN 1.8 and 1.9 works today.
>
> Great.
>
>>> If Daniel insists, I'm fine with using "/***" as well, if we want to
>>> have this special "reserve namespace" meaning.
>>
>>
>> If so then we'll need to make sure to document the required changes to
>> our user's who are using the feature now. It's not a big deal but will be
>> critical when our users upgrade to SVN 1.10. So I'll continue to watch
>> this space carefully.
>
> As Daniel said, he doesn't insist :-) ... I misinterpreted that. And
> given that "/**" is already in use by your users as well as others
> that have already used the branched implementation
> (branches/authzperf), I see no reason to make things more difficult
> for little to no gain. So let's leave things like that.
>
> Thanks for your patience in discussing this.
On rereading this ... didn't want to give the impression that I'm
concluding this discussion on my own.
The above is just my opinion.
--
Johan
Received on 2017-05-11 08:04:20 CEST