[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: authz changes between 1.9 and 1.10

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 25 Jul 2018 06:21:34 +0000

Philip Martin wrote on Tue, 24 Jul 2018 23:37 +0100:
> Branko Čibej <brane_at_apache.org> writes:
> > It describes designed behaviour. If we change it, we should do it
> > carefully, as I wrote above. Also I think it turns out that the authz
> > section in the release notes misses a behaviour change or two. It should
> > probably include the whole Inheritance and Disambiguation list, however
> > we end up changing it.
>
> The most important thing is to document the change in behaviour of the
> non-glob rules between 1.9 and 1.10.
>

+1; we should document any incompatible changes (regardless of whether
they were intentional or not).

> The problem I have is that I still don't know if the changes are
> intentional. Of these undocumented (in the release notes) changes there
> is one that appears to be intentional and two that could be accidental.
> At least the first, intentional, change produces a run-time error if it
> occurs, the other two just lead to different access being granted, one
> less access the other more access. Anyone using a non-trivial authz
> file in 1.9 has to be very careful upgrading to 1.10.
>

Sounds like we should encourage people to write unit tests for their
authz files. This would be fairly easy to implement using 'svnauthz
accessof'. We could ship something in tools/ that takes two
inputs, an authz file and a set of expectations, and validates the authz
file against the expectations.

> Is it worth me working on a fix? Can we declare 1.10.0 and 1.10.1 buggy
> and change the behaviour in future 1.10.x? Or are we stuck with 1.10
> being different from 1.9?

(I don't know.)
Received on 2018-07-25 08:21:46 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.