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.
> The problem is that the authz callback does not provide
> enough context information to make that distinction.
> We might extend the interface in the future - allowing
> to restrict rules to exclusively match files or dirs only.
Are you referring to svn_repos_authz_check_access()? [which doesn't
have an svn_fs_t handle or the information to open one]
> But making that backward compatible adds quite a bit
> of complexity that I don't want to pile on there in 1.10.
I don't understand this sentence at all. Why do we need to be backwards
compatible (this is a new feature), and why is being back compat in
this case necessarily expensive?
Moreover, implementation considerations aside, there is still the
question of what the documentation should say about this situation.
Cheers,
Daniel
Received on 2017-04-18 03:13:55 CEST