Andy Levy wrote on Tue, Apr 26, 2011 at 06:26:47 -0400: > On Fri, Apr 22, 2011 at 11:04, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > Andy Levy wrote on Fri, Apr 22, 2011 at 10:56:14 -0400: > >> But our authz file is written as [Code:/path] and when committing, we > >> get 403 Forbidden errors because no rules match - the user is > >> committing to code and the rule checks for Code, case-sensitive. > >> > >> It's an easy enough fix on the client side, but it is an annoyance. > > > > I'm willing to accept that as a bug report, by the way. The > > before-the-colon section is defined as 'the basename of the repository > > directory', so it seems logical to me that it would be case-sensitive if > > the repository is on a case-insensitive filesystem (regardless of OS). > > I've read this a half-dozen times and I'm still missing something, I'm > just not understanding it. >
Consider this setup: % svnadmin create /path/to/foo % svn mkdir -mm file:///path/to/foo/bar % svn mkdir -mm file:///path/to/foo/BAR % cat <<EOF > /path/to/authz-file [FOO:/bar] * = r root = rw EOF % On a case-sensitive filesystem, the [FOO:/bar] clause refers to a repository called 'FOO', which, in general, is not the same as 'foo'. On a case-insensitive filesystem, ./foo and ./FOO refer to the same object, therefore --- I argued --- it makes sense to respect both [foo:/bar] and [FOO:/bar] entries in the authz file when a request to a repository named *either* 'foo' or 'FOO' is seen. The paths within the repository (such as '/bar') are always case-sensitive. (Using terminology from trunk's svn_dirent_uri.h, in the authz file entry [FOO:/bar], 'FOO' is a dirent and 'bar' is an fspath.) Is that clearer? > I'd be hesitant to submit as a proper bug report as we're running > 1.5.x in production and I haven't tested with a current release. I > won't be able to put any time into testing against 1.6x. for another 3 > weeks due to a project. Unless my previous email is documentation > enough to go on. > > > Is it httpd-specific, or does it also happen with svnserve? > > We've never run svnserve, so I couldn't say. Okay, thanks.
