10
votes

I had a perfectly working svn+apache install where I was using per directory access control to restrict access to various parts of the repository. In particular, no one had access to the top level in the repository [/]. People had access to folders like [/www] etc. I was specifying these permissions in a file (svn-access-file).

I had to move to a new machine. So I installed subversion-1.6.3 and httpd-2.2.11 on it, and modified the conf file to mimic the conf file on the old machine (and I copied the svn-access-file and the svn-auth-file). Then I took an svn dump and did a load to put stuff back in the new repository. Now I can check stuff out, modify stuff, and commit. However, as soon as I try to do an 'svn up' on an already checked out copy of some sub-folder [/www/people], I get the following error:

svn: Server sent unexpected return value (403 Forbidden) in response to OPTIONS request for 'https://[servername]/svn'

It seems the problem is that it is trying to access the top level directory [/] even though really it should only be trying to access [/www]. If I temporarily give the user access to [/], it works.

Can someone please tell me how to fix this? Everything worked on the old machine.

Thanks! Gaurav

2
What were the versions of subversion and apache on your previous installation? Did the suggestion below resolve your issue?RjOllos

2 Answers

10
votes

Turns out this is a long standing bug in the subversion client. Here's the bug report:

http://subversion.tigris.org/issues/show_bug.cgi?id=3242

It will probably get fixed in the next major release - 1.7 In the meantime, here's a hack workaround:

http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2357123

I copied the 'if' statement into the source code for mod_authz_svn.c and rebuilt svn and it works now :)

5
votes

Here is also workaround I've found in the bug discussion. If you have problems with updating local copy try to switch local copy to the same URL.