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%确定当前的复制是同步的仍是不一样步的）。
不管如何，如今回到最初的问题上去。

在我遇到这個错误信息的时候，我尝试了以下事情：
一、我检查了 svn status 的输出内容；
二、我尝试使用命令 svn update -r <rev> 检出壹個早期的版本；
三、我尝试了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 ，转载请注明原始出处。