[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: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Fri, 1 Aug 2014 15:12:47 +0200

On Tue, Jul 29, 2014 at 5:55 PM, Branko Čibej <brane_at_wandisco.com> wrote:

> On 29.07.2014 15:55, Stefan Fuhrmann wrote:
>

[...]

> So, while you can without doubt parse the file streamily,
> you cannot begin to build a data model with authz
> semantics from it streamily. We can go down the path
> of inventing some intermediate model that performs
> slightly better than the current svn_config_t but that
> is a lot of coding simply to avoid a perfectly reasonable
> API bump.
>
>
> Actually, it's not as perfectly reasonable as all that. Consider:
>
> [foo]
> x = 1
>
> [bar]
> y = 2
>
> [foo]
> z = 3
>
> So ... in what order should these sections be enumerated?
>

The svn_config_t implementation transforms this into

[foo]
x=1
z=3

[bar]
y=2

and would enumerate them accordingly. And I agree that is not
particularly nice. But it is well-defined and the original ordering
was probably an artefact of some tool generating the file in the
first place - meaning that it's the tool's job to communicate the
semantics that the user intended. (assuming we encourage
users to sort their path rules.)

The precedence problem must be addressed by whatever data
model we chose. Consider:

[*/**/*a*]
...
[*/**/*b*]
...

I don't see any reasonable criterion, that the user could influence,
to decide which one of those two apply in case of conflict - other
than their declaration order.

Once the declaration order is available in the data model, we
can still decide when / to what extend to use this information.

-- Stefan^2.
Received on 2014-08-01 15:13: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.