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.
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?
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 :-).
If Daniel insists, I'm fine with using "/***" as well, if we want to
have this special "reserve namespace" meaning.
[1] Steps to reproduce with ant (you'll need ant and java):
* Create a file build.xml with this content:
[[[
<project name="test" default="test" basedir=".">
<target name="test">
<echo>Concatenating:</echo>
<concat>
<fileset dir="." includes="test/**,dir/**"/>
</concat>
</target>
</project>
]]]
* Create a file "test" with some content, and a directory "dir" with
another file with other content below it.
* Run "ant". You'll see that the content of "test" is not catted.
* If you change the includes pattern to "**/test/**,dir/**", the file
is effectively catted
--
Johan
Received on 2017-05-05 11:10:04 CEST