tags:

views:

2301

answers:

2

Guys,

Having an SVN issue here. Here's the scenario. I was checking out a repo (say foo) from SVN while doing some other commits / updates. My server died and I was left with an incomplete checkout. Fine. Problem is when I go back to access the foo repo, I am unable to. It just hangs forever.

So, I went to http://subversion.tigris.org/faq.html#bdb-recovery and ran the first command. I received an error so I ended up having to use db_recover and the command said it completed successfully.

Now when I try to access repo, I am getting:

svn: PROPFIND request failed on '/foo' svn: PROPFIND of '/foo': 500 Internal Server Error (https://svn.foobar.com)

Also, if I navigate to https://svn.foobar.com/foo I see: Could not open the requested SVN filesystem

Anyone have any thoughts?

Note: All other repos work. It is just this one.

A: 

did you try svnadmin verify?

can you do a checkout via file:// protocol or svn:// ?

Peter Parker
I did not try that command. I will put in a request for my sysadmin to execute it.I cannot checkout using either method.
frio80
This is definitively a task for your admin, as http error 500 shows that something on serverside is broken. Would be interesting to see what caused the problem!
Peter Parker
OK. Well we fixed it and found something strange. It was a permissions issue. We just needed to chown all files to the directory owner, run the svn recover we figured out how to break it. If we run svn using the file:/// access (eg svn st -uq file:///home/web/svn/repo...). This breaks our repo (PROPFIND errors occur) and we must use the fix I stated above.
frio80
I will try to replicate this.Which version of SVN / Apache / OS ?
Peter Parker
+1  A: 

Did you run 'svnadmin recover' as the user usually using the repository (e.g. apache account)?

If not the reason could be that some files are now owned by the user running 'svnadmin recover' leaving the apache account without rights to change the repository files.

Bert Huijben
In which case a simple chown apache.apache -R /path/to/reposshould rectify the problem...
stephendl