Branko Čibej wrote on Mon, 30 Jul 2018 03:07 +0200:
> On 30.07.2018 02:38, Philip Martin wrote:
> > Branko Čibej <br...@apache.org> writes:
> >
> >> It's worth working on a fix, IMO. My suggestion would be:
> >>
> >> * Keep the single-rule behaviour as it turned up in 1.10, just
> >> document it. It's necessary for glob rules and making an exception
> >> for "old-style" rules will limit the ways we can improve the authz
> >> system in future. Also it'd make the next point quite a bit harder.
> > Agreed. It is a regression from 1.9 but it's a hard error so it will
> > not change behaviour silently.
> >
> >> * Change the ACE override/merge behaviour back to the 1.9 way, as
> >> there's no reason I can think of that it could be either.
> > I have a patch to do this. At present I am distinguishing between glob
> > and non-glob rules and only apply the 1.9 way to non-glob rules. This
> > means that a 1.9 authz file retains the 1.9 behaviour, and that the 1.10
> > glob rules retain the the 1.10 behaviour for anyone who has started
> > using them. But is also means glob and non-glob rules behave
> > differently.
> >
> > Is it better to preserve as much 1.10 behaviour as possible because
> > people may have started using it, or is is better to have consistency
> > between glob and non-glob rules?
>
> It's definitely better to have consistent behaviour across all rule
> types.
+1
> Otherwise there'll be no end of user questions about it ... and
> we'll keep second-guessing ourselves, too. Also imagine this:
>
> [:glob:/path]
> foo = rw
> foo = r
Here,
- The 1.9 behaviour is reasonable: it follows a simple rule (the same
one our CLI --option=argument parsing uses, and our
~/.subversion/config files parsing too, I believe), so an admin might
have reasonably assumed it to be intentional. It _is_ a feature of Subversion
that all ConfigParser-ish config files are parsed the same way, after all.
- 1.10 makes an incompatible change to the 1.9 semantics. The change
is undocumented in the release notes, so a 1.9 admin can't be
expected to be aware of the change, but _is_ documented in the design
wiki, so a 1.10 admin may have seen it in the design wiki and started
to rely on it.
We effectively made two contradictory compatibility promises; we can't
honour both of them. I think our only option is to make it a syntax error.
"In the face of ambiguity, refuse the temptation to guess."
Cheers,
Daniel
P.S. I _would_ have had this discussion during the design phase if I had
noticed the issue back then. Sorry to have missed it.
