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.