24
votes

Users attempting to check out files from a particular Subversion 1.4.x repository with Apache 2.2 on Windows 2003 have suddenly begun getting an error message in their log windows upon checkout with TortoiseSVN 1.4:

Error REPORT request failed on '/[path_to_repo]/!svn/vcc/default'
Error REPORT of '/[path_to_repo]/!svn/vcc/default': 200 OK (http://[server_name])

This started following an hd crash on the server and subsequent restore of about 10 subversion repositories. Only one repository is having this problem after an attempted working directory reconciliation. The repo owner reconcile their working directory with the repository by modifying/deleting the hidden .svn directories (though this was not advised).

I can't find anything on the Internets that represents my situation. The restored server is exactly as the original and no other repositories on this server are throwing errors. Any ideas on 1) what this error is and 2) how to fix it?

11
The issue might have been due to mismatched TortoiseSVN versions accessing a single working directory. TSVN warns (at least in the latest releases) that a working directory may not be accessed by differing versions of TSVN. I just became aware last week that this working directory is "shared" and we do have different versions of TSVN in production. I know... I know...John

11 Answers

7
votes

The incidence of the SVN error {REPORT of '/svn/xxxx/!svn/vcc/default': 200 OK} when attempting the Checkout or Update in SVN was eventually resolved on our site by restarting the SVN Server.

4
votes

Late answer but I hope it'll be useful.

I had this issue and it has nothing to do with the server but was caused by a strange operation on the client side (renaming a directory and not committing the the creation of the destination as far as I remember).

I first try to find out the faulty directory using the following one liner:

for fic in $(find . -type d | grep -v -e './target' -e '/.svn'); do echo $fic; svn up -N $fic; done

The -Nswitch prevent svn from recursing into subdirectories helping to pinepoint the faulty directory in my case ./src/main/resources/META-INF. Since I didn't have anything uncommitted in this directory I did remove it.

svn status indicates me that the directory was missing and a simple svn update brought it back to life and fixed my issue.

1
votes

I ran across this problem on SubClipse & Subversive on Eclipse and on TurtoiseSVN. I removed the local repository directory which did NOT resolve the problem. Finally we increased the HTTP timeout on the Apache server which resolved the issue.

1
votes

I was getting the following error during a checkout of my repo:

svn: E175002: REPORT of '/!svn/vcc/default': 200 OK

I'm serving repo as apache proxy through nginx. Looking at nginx error log, i see the following:

[crit] 25839#0: *37 open() "/var/lib/nginx/tmp/proxy/1/00/0000000001" failed (13:     Permission denied) while reading upstream, client: xx.xx.xx.xxx, server: my.domain.com, request: "REPORT /!svn/vcc/default HTTP/1.1", upstream: "http://127.0.0.1:8080/!svn/vcc/default"...

To finally fix the problem, I had to change the owner/group on my /var/lib/nginx folder and /var/lib/nginx/tmp folder to match what /var/lib/nginx/tmp/proxy was using. In my case I have a special "www" user used by apache and nginx. The group was "root".

1
votes

I had this problem too.

I found out by using TortoiseSVN, that when I update parts of the repository, most of them worked but one folder thrown the error. I went inside and updated portions and realized that one file was corrupted or something. It was a csv file. Its checksum was wrong and the encoding was weird. I deleted the file and replaced it with a working version of the file. The error disappeared.

0
votes

Did you change anything to your (hidden) .svn directory?

You can get the original copy back of the .svn directory or delete it. SVN can't handle this "difference" in versions. He thinks it is another version instead of the same with a different .svn directory.

0
votes

We had the same problem on a specific folder in our project. The following resolved the problem:

  1. backup the folder to external location
  2. Using repo-browser, deleted the folder from the svn.
  3. Deleted the physical folder from the computer.
  4. issue SVN update.
  5. It may cause a Tree conflict. - mark the conflict as being resolved.
  6. Make sure that the folder does not exists on the computer.
  7. restore the folder from backup, add and commit it.
0
votes

A fresh checkout solved the issue for me. In my case the issue was with a directory structure that was erroneously committed to the repo (e.g. "existingfolder\C:\inputpub\etc...") which caused strange issues after trying to delete out the dir and commit.

0
votes

Background : We use servers where SVN installed by different users.

So I tried the option of re-installing the SVN in the user who is currently using and it resolved the issues. (Windows. Also while installing first time, you can install with option for all users to use it).

0
votes

I just tried a couple more times, out of frustration more than anything else, and eventually it worked. Assume some bad network thing caused this.

0
votes

We don't encounter the error anymore after we tried clearing the saved authentication, delete all the contents of this folder AppData\Roaming\Subversion\auth\, then Re-login