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

Branko Čibej wrote:
> Author: stefan2
>> Without support for wildcards or other patterns, the config struct
>> will only contain a single section for each path.  With wildcards,
>> there may be more than one.  All three of the follwing path rules
>> are equally applicable:
>>
>>   [/foo/*.doc]
>>   * = r
>>
>>   [/foo/bar.*]
>>   * = rw
>>
>>   [/foo/bar.doc]
>>   jrandom =
>>
>>  To make conflicts managable, always pick the last path rule.  That
>> means users should specify general rules first, followed by exceptions
>> and finally (and optionally) critical rules that deny certain access,
>> potentially globally.
>
> Are you saying that a wildcard path should match before a concrete
> path when it happens to appear later in the authz file? Perish the
> thought. Exact matches should always override fuzzy matches,
> anything else is not intuitive at all and we'll receive a ton of
> spurious bug reports about how authz files don't work.
>
> Precedence ordering is fine between identical exact matches or
> between equivalent wildcard matches for the same path, but not
> between these two categories.

I agree with the sentiment, but am not sure how to define such rules. What does "equivalent wildcard matches for the same path" mean? Do you mean to find a definition that will give the expected precedence between two wildcard patterns where one is intuitively more "exact" than the other, such as:

  /projects/*/include/*_private.h

and

  /projects/*/include/foo.h

?

- Julian
Received on 2014-07-29 09:50:37 CEST