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 ，轉載請註明原始出處。