[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: wildcard authz docs question

From: Doug Robinson <doug.robinson_at_wandisco.com>
Date: Thu, 4 May 2017 18:49:17 -0400


(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 (

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.


T +1 925 396 1125
*E* doug.robinson_at_wandisco.com
World Leader in Active Data Replication™
*Find out more wandisco.com <http://wandisco.com/>*
If this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.
Received on 2017-05-05 00:49:30 CEST

This is an archived mail posted to the Subversion Dev mailing list.