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

Re: svn commit: r1614080 - in /subversion/branches/authzperf: BRANCH-README subversion/libsvn_repos/authz.c subversion/libsvn_subr/config.c subversion/libsvn_subr/config_impl.h

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 29 Jul 2014 09:32:41 -0400

On 07/29/2014 06:46 AM, Branko Čibej wrote:
> If we want to
> support wildcards, we /have/ to invent a different syntax for wildcard
> rules. My working proposal is to add a literal '*' before the leading
> slash in the path:
>
> [*/fspath-pattern]
> [repos:*/fspath-pattern]
>
> because neither of these syntaxes are currently valid. We can invent a
> different syntax, as long as it maintains that property; and we cannot
> replace the brackets around the rule with something else, without making
> very intrusive changes in the config parser code.

I like this. I would suggest using '*:' as your magic prefix, though.
That way, the '*' is less likely to be mistaken for part of the match
pattern itself.

  # Match 'private' directories withing the tags of all repositories.
  [*:/tags/*/private]

Also, in this mode, the match pattern needn't start with '/', right?

  # Match any item named "public" regardless of tree depth.
  [repos:*:*/public]

This leaves open the possibility of a future additional match mode for
regular expressions (using the '^:' magic prefix) should we seek to "go
there".

  # Match the trunk and branches subdirs and their children.
  [repos:^:^/(trunk|branches)(/.*|$)$]

> If we decide that the config parser is fair game (since I'm already
> changing it to optimize the construction of the in-memory authz
> representation), we could, for example, pick
>
> {/fspath-pattern}
> {repos:/fspath-pattern}

Ugh. I'd *really* prefer not to have to reimplement basic .INI parsing
for various extra-Subversion tools that read and write authz files, such
as ViewVC.
Received on 2014-07-29 15:33:15 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.