Brane:
I just read through this thread. Your proposal makes a lot of sense.
To me, it's one of those things that should go into a new version (not a
patch).
And there should be a nit-picky script to point out "strange stuff" (like
the example
that Julian posed).
Cheers.
Doug
On Mon, Dec 3,
On 03.12.2018 16:07, Michael Pilato wrote:
> On 12/3/18 3:15 AM, Julian Foad wrote:
>> It makes me uncomfortable to depart from standard parsing. What if
>> users are relying on Python ConfigParser or other compatible parsing
>> as part of their Subversion authz infrastructure?
> We needn't keep
On 03.12.2018 11:42, Julian Foad wrote:
> Branko Čibej wrote:
>>> If we treat the authz format as its own format, that does make me wonder if
>>> there are any other limitations the current ConfigParser format is
>>> applying, that should also be lifted.
>>>
>>> For example, if "@harry" is
On 12/3/18 3:15 AM, Julian Foad wrote:
> It makes me uncomfortable to depart from standard parsing. What if
> users are relying on Python ConfigParser or other compatible parsing
> as part of their Subversion authz infrastructure?
We needn't keep this hypothetical. ViewVC is using (a slightly
Branko Čibej wrote:
>> If we treat the authz format as its own format, that does make me wonder if
>> there are any other limitations the current ConfigParser format is applying,
>> that should also be lifted.
>>
>> For example, if "@harry" is parsed as a reference to group name "harry",
>>
On 03.12.2018 10:39, Julian Foad wrote:
> Branko Čibej wrote:
>> I can't think of a solution that would not depart from ConfigParser
>> semantics in one way or another. As for "the system" ... well, the fact
>> that config and authz parsing shares common code is really just an
>> accident, and
Branko Čibej wrote:
> I can't think of a solution that would not depart from ConfigParser
> semantics in one way or another. As for "the system" ... well, the fact
> that config and authz parsing shares common code is really just an
> accident, and certainly an implementation detail.
OK, that's
On 03.12.2018 09:39, Stefan Sperling wrote:
> On Mon, Dec 03, 2018 at 09:30:53AM +0100, Stefan Sperling wrote:
>> On Mon, Dec 03, 2018 at 08:15:24AM +, Julian Foad wrote:
>>> Branko Čibej wrote:
The proposed change in the parser is only enabled for parsing authz and
global group
On 03.12.2018 09:15, Julian Foad wrote:
> Branko Čibej wrote:
>> https://issues.apache.org/jira/browse/SVN-4204
>> https://issues.apache.org/jira/browse/SVN-4795
>>
>> Even though apr_fnmatch(), which we use for matching glob patterns in
>> authz rules, supports character classes ([A-Z] etc.), we
On Mon, Dec 03, 2018 at 09:30:53AM +0100, Stefan Sperling wrote:
> On Mon, Dec 03, 2018 at 08:15:24AM +, Julian Foad wrote:
> > Branko Čibej wrote:
> > > The proposed change in the parser is only enabled for parsing authz and
> > > global group files, other Subversion configuration files will
On Mon, Dec 03, 2018 at 08:15:24AM +, Julian Foad wrote:
> Branko Čibej wrote:
> > The proposed change in the parser is only enabled for parsing authz and
> > global group files, other Subversion configuration files will use the
> > current semantics.
>
> These sorts of quirks tend to make a
Branko Čibej wrote:
> https://issues.apache.org/jira/browse/SVN-4204
> https://issues.apache.org/jira/browse/SVN-4795
>
> Even though apr_fnmatch(), which we use for matching glob patterns in
> authz rules, supports character classes ([A-Z] etc.), we can't use them
> in the glob rules because of
TL;DR:
https://issues.apache.org/jira/browse/SVN-4204
https://issues.apache.org/jira/browse/SVN-4795
The longer story:
Even though apr_fnmatch(), which we use for matching glob patterns in
authz rules, supports character classes ([A-Z] etc.), we can't use them
in the glob rules because of the
13 matches
Mail list logo
