SVN 客户端提示 Delta source ended unexpectedly 错误的解决方法

几天前，我开始将壹個 新的 Libcloud 网站迁移到我们的 Apache SVN 网站资源库的工作。
在这次迁移中，我进行了壹堆提交到SVN资源库的操作，这些提交操作是由新增（增加源代码，并且为新的网站生成静态文件）和删除（删除旧网站上的源代码和数据）组成。
在某些时候，我已经更新了网站内容，并且重新生成了网站，并且想再次提交更新过的文件。

当这些更新和删除操作在传输的时候，所有的壹切看上去都很好，但是就在服务器准备响应所有这些更新时，我接收到了如下的错误信息：

Transmitting file data ............svn: Commit failed (details follow):
svn: Delta source ended unexpectedly

我以前从来没有接到过这种错误信息，但是我猜测这個问题可能与壹些怪异的壹致性问题有关系，在此之前我增加新的网站文件和删除旧文件的时候有看到过这种问题。

当时我是这麽做的，我在提交和之后壹個大的提交之间运行了几次 svn update，尽管我觉得这不应该，但是我从服务器端接收到了旧的更新，因为本地资源库应该拥有所有的更新内容，并且表现出壹個最新的状态。
其中壹個我执行的提交操作很庞大，包含了大量的更新内容，所以我立即猜测到这可能与Apache GEO 负载均衡的 SVN 配置和壹些奇怪的复制/不同步的问题有关系。我等了好几分钟，然后再次运行 svn update 命令，这次问题似乎被解决了，我接收到了所有的更新内容，这些内容在壹致性问题出现之前就已经存在于本地了。看上去，我要麽再次重定向到相同的 SVN 服务器，要麽把现在所有的变化完全复制到另一台服务器上（非常需要，我不能够100%肯定当前的复制是同步的还是不同步的）。
无论如何，现在回到最初的问题上去。

在我遇到这個错误信息的时候，我尝试了如下事情：
1、我检查了 svn status 的输出内容；
2、我尝试使用命令 svn update -r <rev> 检出壹個早期的版本；
3、我尝试了clean checkout （使用命令 svn co <repo url> clean-checkout）；
没有壹個方法是奏效的。

svn status 只显示已经存在的文件的更新状态（M），而且这种更新不包含增加的新文件，在我重新添加了更新过的文件之后（是的，这些文件并不包含.svn 目录），我尝试了上述的方法2和方法3，但是我仍然在提交的时候接收到了相同的错误信息。
在这种情况下，我彻底没撤了，而且我不想把这個问题报告给还不存在的ASF基础架构团队，所以我开始尝试用 Google 来找到问题的解决方案。最后我无功而返，但是至少有壹個共识就是这似乎是由壹种壹致性问题引起的，它发生在本地 checkout 出来的版本和远程资源库之间，就像我前面所猜测的那样。
为了找出到底是哪個文件或者文件夹引起的这個问题，我写了壹小段脚本，用于将所有的文件壹個接壹個的提交。
这样做对于项目成员们而言没有任何价值，甚至可能让他们不高兴，因为这样做会导致100多条提交记录，而且每条提交记录都会生成壹個发送给commits@ 邮件列表的通知邮件。

#!/bin/bash

FILES=$(svn status generated/ | awk '{print $2}')

for file in ${FILES}; do
    svn commit ${file} -m "Regenerate website."
done

在这些提交操作中，除了三個文件提交失败以外，其它的都提交成功了。对于这三個叛逆的文件，服务器端返回了壹個错误信息说，这些文件不属于资源库的壹部分。这就是壹致性问题，因为 svn status 显示这些文件已经被更新过，并且没有新的内容引入。

为了解决这個问题，我尝试移除了这些文件（svn rm），把它们再重新加回来（svn add）最后提交更新。

# backup to-be removed files (exclude .svn directories)
svn rm generated/blog/tags/dir1
svn rm generated/blog/tags/dir2
svn rm generated/blog/tags/dir3
# re-added changed files back
svn add generated/blog/tags/*
svn commit -m "Regenerate website."

这次的做法解决了问题，在文件传输的过程中我没有再接收到任何错误信息。

我仍然不是很确信到底是什么导致了这個问题，因为这些文件在本地和远端状态上有明显的不壹致，但是我仍然很高兴解决了这個问题，我不需要再处理 SVN 了。
2014年01月01日最后更新：Justin 确认了 Apache SVN 配置使用了异步的复制方式，这解释了我前面遇到的第壹個问题。他同样提到，为了避免发生类似问题，我可以在使用 svn relocate 的时候明确的选择只使用 master 工作的方式。

英文原文出处：http://www.tomaz.me/2014/01/01/resolving-delta-source-ended-unexpectedly-svn-issue.html ，中文译文首发开源中国社区http://my.oschina.net/bairrfhoinn/blog/195733 ，转载请注明原始出处。