Philip Martin > Branko Čibej <br...@wandisco.com> writes: > >> I also propose, in advance, that we include this change in 1.8. It >> should be relatively non-invasive as far as code is concerned, but of >> course we'll have to yell loudly in the release notes about the changed >> behaviour. > > I've raised http://subversion.tigris.org/issues/show_bug.cgi?id=4361 > and given it a 1.8.0 milestone.
I read the thread and the issue and am not clear exactly what the problem is. You wrote: > Consider an authz file: > [/] > pm = rw > PM = r > 123... We] store the exact case of th40>< [... We] store the exact case of the80 > [... We] store the exact case of the first key and that is what is > checked when querying: > $ svnauthz accessof authz.txt --username PM > no > $ svnauthz accessof authz.txt --username pm > r > > [...] the effective line is "pm = r" which is not something that > occurs in the file. So what exactly is broken, behaviour-wise? Is authorization done with case-insensitive username checking in the server, and the "svnauthz" tool is broken in that it fails to do case-insensitive matching of usernames? Or something else? I just want to make sure we're proposing this behaviour change in order to fix a regression since 1.7 or a serious bug. But if the bug is only in the "svnauthz" tool then I would suggest for 1.8 we should just fix that tool to match the way authz works now. You also wrote: > We made the section names, the [...] bits, case-sensitive: > http://subversion.tigris.org/issues/show_bug.cgi?id=3781 That (in other words, case sensitivity for the paths) was done in 1.7.0. - Julian
