Doug Robinson wrote on Mon, May 01, 2017 at 14:20:16 +0000: > Daniel: > > On Mon, Apr 17, 2017 at 21:13 Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > > Stefan Fuhrmann wrote on Mon, Apr 17, 2017 at 22:22:33 +0200: > > > On 15.03.2017 10:55, Daniel Shahaf wrote: > > > >>From the 1.10 draft release notes: > > > > > > > >>All wildcards apply to full path segments only, i.e. * never matches > > > >>/, except for the case where /**/ matches zero or more path segments. > > > >>For example, /*/**/* will match any path which contains at least > > > >>2 segments and is equivalent to /**/*/* as well as /*/*/**. > > > >Are «/*/**/*» «/**/*/*» «/*/*/**» really equivalent? I would have > > > >expected the first two to match any node except / and /'s immediate > > > >children, but I wouldn't expect the third form to match /trunk/iota > > > >where iota is a file, since the pattern has a trailing slash after the > > > >non-optional second component. > > > How do you know that /trunk/iota is a file? > > > > I was reviewing the API docs as a black box, i.e., from a user > > (repository admin) perspective, not from an implementation perspective. > > > > From that perspective, I would say that having a [/trunk/iota/**] > > stanza to apply to a /trunk/iota file violates the principle of least > > surprise. > > > From a very critical point of view I agree. > > However, the point of wildcards is to easily reserve a complete namespace.
Sure, that's a valid use-case. I was envisioning that, if a [/trunk/iota/**] stanza were present, then an authz query for a /trunk/iota file would return either "No access" or a parse error. This would reserve the namespace, wouldn't it? Referring to your next paragraph, this logic would neither leak the contents of the file nor require multiple stanzas. > If we do not apply that stanza apply to the file means requiring 2 stanzas > to cover the space entirely. That's both expensive and brittle (2X stanzas > and requires remembering to treat them in pairs - both when adding and when > removing). > > And I think the "surprise" will be very short-lived if at all. > > From a cost/benefit standpoint I think it is extremely positive. Well, if a common task requires two stanzas, then _of course_ we'll find an easier way for users to spell it. For example, we could invent some new "reserve prefix" stanza syntax, or pass to svn_repos_authz_check_access() the svn_node_kind_t of the path it checks access to, or any number of other solutions. In short: there might well be a design that meets both of our criteria: principle of least surprise _and_ namespace reservation. Cheers, Daniel
