On 02.06.2017 00:11, Doug Robinson wrote:
>> * /trunk now uses are specialized parser for authz.
>> Some accidental features of the previously used
>> config parser are no longer available. In particular,
>> sections may no longer be repeated and there is
>> no support for value expansion.
>>
> Just checking: can there be 2 sections of:
>
> [/]
> * = r
>
> [/]
> accountA = rw
> accountB = rw
>
> Or is this now going to fail?
This is now going to fail. People would have to write:
[/]
* = r
accountA = rw
accountB = rw
The rationale for this restriction is this: if we allow the same section
to appear multiple times, it becomes too hard to determine in which
order the rules should be applied and which rules take precedence. This
was not such an issue before when a section name (path) was always an
exact match (although q.v. global vs. repository-specific rules, too).
With wildcards, it's much easier to write multiple sections that match
the same concrete path; so we must have a consistent way to determine
which rule actually applies.
Consider, supposing we allowed repeating sections:
[:glob:/foo/*]
$authenticated = r
[/foo/bar]
accountA = rw
[:glob:/foo/*]
accountA =
When we look at /foo/bar in a repository as accountA, what should
happen? Our current behavour is, IIRC, that the rule that was defined
last wins ... but which is last in this case? There are two possible
answers, which means there's too much room for confusion. Hence the
restriction.
> Can you say more about the "value expansion"?
In Subversion config files you can write something like this:
[DEFAULT]
foo = bar
[section]
option = %(foo)s
which will be equivalent to:
[section]
option = bar
In other words, we support variable expansion similar to Pyhon's
ConfigParser module. Because we used to have the same parser for authz
files as for config files, this misfeature was also supported in authz
files. The new parser does not support variable expansion.
-- Brane
Received on 2017-06-02 01:36:31 CEST