On Wed, May 10, 2017 at 5:40 PM, Doug Robinson <doug.robin...@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 <jcor...@gmail.com> wrote: >> >> On Fri, May 5, 2017 at 12:49 AM, Doug Robinson >> <doug.robin...@wandisco.com> wrote: >> > >> > Johan: >> > >> > (sorry for the empty message - dwim failed) >> > >> > On Thu, May 4, 2017 at 7:26 AM, Johan Corveleyn <jcor...@gmail.com> wrote: >> >> >> >> On Thu, May 4, 2017 at 10:16 AM, Daniel Shahaf <d...@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
