Doug Robinson wrote on Wed, May 03, 2017 at 15:54:50 -0400: > Daniel: > > On Mon, May 1, 2017 at 2:05 PM, Daniel Shahaf <d...@daniel.shahaf.name> > wrote: > > > Doug Robinson wrote on Mon, May 01, 2017 at 14:20:16 +0000: > > > 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. > > > > For an AuthZ check the answer is either Yes or No, not "parser error", > right?
Wrong. An authz check can return an error. For example, `svnauthz accessof` has exit code 2 when the authz file fails to parse. > And it really can't be a "parser error" (invalidating the AuthZ file > entirely) since in some other revision that "file" could be > a "directory". So either the stanza gets skipped as "not applicable" > (and therefore not reserving the namespace) or it gets entered as if > the file were a directory and we're back to the behavior that I am > expecting. You are correct: it will not be a *parse* error since the grammar of authz files does not depend on the contents of the repository. That just means it will be a different kind of error — a semantic error — and will occur at authz query time, not at authz file load time. That would still break checkouts of /trunk, though, so it might be better to just default /trunk/iota to "No access" and log a warning to the server log. (Using, say, svn_repos_fs(repos)->warning().) > > > > 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. > > > > 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? Cheers, Daniel > As I said, I think the surprise, if any (none if we document it well) > will be very short-lived.
