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.s_at_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
Received on 2017-05-01 20:06:04 CEST