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.
--
Johan
Received on 2017-05-10 23:38:12 CEST