[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: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Thu, 7 Aug 2014 12:30:01 +0400

On 2 August 2014 18:45, Branko Čibej <brane_at_wandisco.com> wrote:
> On 02.08.2014 15:20, Alan Barrett wrote:
> On Tue, 29 Jul 2014, C. Michael Pilato wrote:
> 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)(/.*|$)$]
> As a user, I'd prefer to see keywords rather than unusual characters to
> designate special syntax. For example, I would prefer
> [glob:/tags/*/private] and [regex:/tags/.*/private] to [*:/tags/*/private]
> and [^:/tags/.*/private].
> Quite understood. Unfortunately, the syntax you propose above cannot work;
> [thing:/path] is already a valid syntax, and if we did what you propose,
> we'd no longer be able to create rules for repositories named "glob" and
> "regex". Worse, this could change the meaning of existing authz files.
> We could do something like this, though:
> [:glob:/path]
> [:glob:repos:/path]
> In the old authz files, these rules would be invalid, because the repository
> name part (the substring up to the first colon) cannot be empty.
> Thoughts?
I don't like the proposed syntax, but I don't why. Probably because
many ':' is very confusing.

My thoughts on this topic:
1. Do we really need 'regex' pattern matching? Would not be this
overkill and performance killer?
2. Could be we make regex/glob/simple pattern matching per-file option?

I'd like to avoid complexities in authz files if possible.

Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2014-08-07 10:35:08 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.