tortoisesvn-错误报告请求在../../....上失败！svn/vcc/default

试图在Windows 2003上使用Apache 2.2从特定Subversion 1.4.x存储库中签出文件的用户在使用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])

这是在服务器发生hd崩溃并随后恢复大约10个subversion存储库之后开始的。在尝试工作目录协调后，只有一个存储库出现此问题。repo所有者通过修改/删除隐藏的.svn目录（尽管不建议这样做），将其工作目录与存储库进行协调

---

我在网上找不到任何能代表我的情况的东西。还原的服务器与原始服务器完全相同，并且此服务器上没有其他存储库抛出错误。关于1）此错误是什么以及2）如何修复它的任何想法？

当尝试在SVN中签出或更新时，SVN错误的发生率{REPORT of'/SVN/xxxx/！SVN/vcc/default'：200 OK}最终在我们的站点上通过重新启动SVN服务器得到解决

您是否更改了（隐藏的）.svn目录

---

您可以获取.svn目录的原始副本或将其删除。SVN无法处理版本中的这种“差异”。他认为这是另一个版本，而不是同一个版本，有一个不同的.svn目录。

迟来的答案，但我希望它会有用

我遇到了这个问题，它与服务器无关，而是由客户端的一个奇怪操作引起的（据我记忆所及，重命名目录并没有提交目标的创建）

我首先尝试使用以下一行代码查找故障目录：

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

-N

开关防止svn递归到子目录中，以帮助我指出故障目录

/src/main/resources/META-INF

。因为我在这个目录中没有任何未提交的内容，所以我确实删除了它

---

svn status

表示该目录已丢失，一次简单的

svn更新

使其恢复了活力并修复了我的问题。

我在Eclipse和TurtoiseSVN的SubClipse和Subversive上遇到了这个问题。我删除了无法解决问题的本地存储库目录。最后，我们增加了Apache服务器上的HTTP超时，从而解决了这个问题

我们在项目中的特定文件夹上遇到了相同的问题。 以下操作解决了该问题：

将文件夹备份到外部位置

使用repo浏览器从svn中删除该文件夹

已从计算机中删除物理文件夹

发布SVN更新

它可能会导致树冲突。-将冲突标记为已解决

确保该文件夹在计算机上不存在

从备份中还原文件夹，添加并提交它

---

一次新的结账为我解决了这个问题。在我的例子中，问题在于错误地提交到repo的目录结构（例如“existingfolder\C:\inputpub\etc…”），这在尝试删除目录并提交后导致了奇怪的问题。

我在签出repo时遇到以下错误：

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

我通过nginx将repo作为apache代理服务。查看nginx错误日志，我看到以下内容：

[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"...

---

为了最终解决这个问题，我必须更改/var/lib/nginx文件夹和/var/lib/nginx/tmp文件夹上的所有者/组，以匹配/var/lib/nginx/tmp/proxy使用的内容。在我的例子中，apache和nginx使用了一个特殊的“www”用户。小组是“根”。

我也有这个问题

我通过使用TortoiseSVN发现，当我更新存储库的部分时，大部分都正常工作，但有一个文件夹抛出了错误。我进入并更新了部分内容，发现一个文件损坏了。这是一个csv文件。它的校验和是错误的，编码也很奇怪。我删除了该文件，并将其替换为该文件的工作版本。错误消失。

背景： 我们使用由不同用户安装SVN的服务器

---

因此，我尝试在当前使用的用户中重新安装SVN，解决了问题。（Windows。在第一次安装时，您可以使用选项进行安装，供所有用户使用）。

我只是尝试了几次，最主要的是出于失望，最终它成功了。假设是网络故障造成的。

在尝试清除保存的身份验证后，我们不再遇到错误，删除此文件夹的所有内容

AppData\Roaming\Subversion\auth\

，然后重新登录

问题可能是由于访问单个工作目录的不匹配的TortoiseSVN版本造成的。TSVN警告（至少在最新版本中）不同版本的TSVN可能无法访问工作目录。我上周才意识到这个工作目录是“共享”的，我们在生产中有不同版本的TSVN。我知道。。。我知道…太棒了！非常有用！救了我一天！谢谢@加布佐，你确定你的命令是正确的吗？当我尝试同样的方法时，我得到：

fic在这个时候是出乎意料的。

@vikram我很肯定这一点。但是，这是一个bash命令，因此在csh、tcsh中可能会失败，在sh或ksh中也可能会失败。不知道它是否应该在zsh上工作。