我該如何解決SVN導入行結束符錯誤？

Question

我必須導入一個龐大的SVN倉庫，我必須從一臺服務器轉移到另一臺服務器。所以，我從舊服務器中導出它：

svnadmin dump . > archive.svn 

和進口它的新的：

svnadmin load . < archive.svn 

在導入過程中間，我得到這個錯誤：

Cannot accept non-LF line endings in 'svn:ignore' property 

我怎樣才能解決這個問題？我完全控制了兩臺服務器。

Answer 1

您是否更改了服務器版本？這是1.6中的一個已知問題，從1.4或1.5開始會導致問題。

Subversion 1.6不再接受屬性文件中的回車符（^ M）。您需要修復svn：ignore文件中的換行符，或者重新創建，如果更簡單。

或者，您可以去Subversion 1.7或使用uberSVN。

Answer 2

你有2個選擇，修復源代碼或禁用道具驗證。

修復源（SVN：日誌和svn：忽略）：

sed -e '/^svn:log$/,/^K/s/^M/ /' -e '/^svn:ignore$/,/^PROPS-END$/ s/^M/\n/' archive.svn > repaired-archive.svn 

svnadmin load . < repaired-archive.svn 

凡^M是控制字符，這意味着0D十六進制。爲了得到它使用^ V^M（控制器v沒控制M），而不是^ M（抑揚M或控制M）

禁用道具驗證：

svnadmin load --bypass-prop-validation . < archive.svn 

Answer 3

我就遇到了這個錯誤升級時1.6回購1.8。我在網上發現了一些「修復」。

- 旁路 - 道具驗證沒有吸引我，因爲它推遲了這個問題，下次你需要恢復回購時，你將會遇到同樣的問題。

我發現了一個bash腳本來循環修改獲取註釋並重新設置它們，但這不起作用。

Ventura10解決方案的改進完成了這項工作。因爲轉儲的大小我結束了使用單一命令來刪除不需要的字符，而恢復轉儲

sed -e '/^svn:log$/,/^K/s/^M/ /' -e '/^svn:ignore$/,/^PROPS-END$/ s/^M/\n/' /path/to/svn.dump | svnadmin load /path/to/repo 

注：

Where ^M is a control character, that means 0D in hex. To get it use ^V^M (control V control M) instead ^M (circumflex M or control M)

Answer 4

@ ventura10的回答的第一個選項聽起來不錯但沒有爲我工作。在加載轉儲時，sed命令在屬性部分之外更改了某些版本化內容，導致md5不匹配。

因爲我的存儲庫沒有二進制內容的屬性，所以我更改了sed命令來更正所有屬性，而不僅僅是svn:log和svn:ignore。我也確信沒有版本文件包含以Prop-content-length:開頭的行。否則，我會在加載轉儲時出現錯誤。

sed -e '/^Prop-content-length: /,/^PROPS-END$/ s/^M/ /' svn.dump > svn.dump.repaired 

它與[blank]更換^M是很重要的，因爲屬性值的大小不能改變。

音符@ ventura10仍然是有效的：

^M is a control character, that means 0D in hex. To get it use ^V^M (control V control M) instead ^M (circumflex M or control M)

很難相信，升級現有的存儲庫從SVN 1.4使用svn 1.7使得這一步nessecary，但我發現沒有其他辦法擺脫自svn 1.6以來不再被接受的回報。

Answer 5

使用svndumptool：

svndumptool.py eolfix-prop svn:ignore svn.dump svn.dump.repaired 

@tangens解決方案的工作太適合我，但我得到一個額外的空格字符作爲替換回車符的它並不完美。然而，我確實測試了svn：ignore仍然適用於這個額外的空間，但我沒有測試其他的SVN屬性。

使用svndumptool的缺點是它一次只能在一個svn屬性上工作，如果你的轉儲文件很大，這是非常耗時的。

---

有些發現

你可能是爲什麼@tangens沒空字符替換^ M好奇。如果你試圖用空字符替換它，你就會得到這個錯誤：

svnadmin: E140001: Dumpstream data appears to be malformed 

轉儲文件存儲Prop-content-length屬性，它會針對該財產的實際內容的內容相匹配。將^ M替換爲空字符會減少屬性內容的長度，從而導致錯誤。

svndumptool將分別更改Prop-content-length和Content-length。

Answer 6

有了一點體操，你可以使用svnsync來解決這個問題，它可以修復EOL。假設您的存儲庫被轉儲到archive.svn。

首先創建存儲庫加載回購回來了，忽略了EOL問題：

svnadmin create repo 
svnadmin load repo < archive.svn --bypass-prop-validation 

現在創建一個新的存儲庫複製到：

svnadmin create repo-fixed 

svnsync需要一些pre-commit鉤子，即使您不使用它，只需使用您的編輯器在repo-fixed/hooks/pre-revprop-change中創建一個空格：

#!/bin/sh 
exit 0 

初始化目的地信息庫svnsync：

svnsync sync file:///path/to/repo-fixed 

呼：

svnsync init file:///path/to/repo-fixed file:///path/to/repo 

現在整個倉庫的副本！ svnsync甚至會給你一個好消息：（爲什麼Subversion的團隊沒有更新svnadmin做同樣的正常化是一個謎給我）NOTE: Normalized svn:* properties to LF line endings

一旦這樣做了，自卸車新的存儲庫：

svnadmin dump repo-fixed > archive-fixed.svn 

您現在有archive-fixed.svn，應該與archive.svn相同，但EOL已根據需要進行了修正。

（可選）現在，您可以刪除用於svnsync臨時存儲庫：

rm -rf repo-fixed 

更新如果您加載此新轉儲事實證明，你的Subversion客戶端會得到一個錯誤：Repository UUID does not match expected UUID 。您必須使用svnadmin setuuid ...至change the UUID ID to what it used to be。

（這篇文章是片段和局部多種解決方案，我發現網絡上的高潮感謝所有誰知道比我多的人，我只是把它一起。）

參見：

• Copying subversion repositories with history using svnsync
• https://stackoverflow.com/a/28472420/421049
• https://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt

Answer 7

我剛剛成功修復了一個svn轉儲文件。它在屬性中也有一個CRLF，導致SVN Edge轉儲導入異常（它們有一個非常糟糕的導入例程）。然後我「裝」測試svnserve的，這比預期的（針對Windows操作系統的指令）要容易得多：

1. 下載並安裝TortoiseSVN或包含SVN命令行工具的其他軟件。我已經安裝了它
2. 開始cmd.exe，運行svnserve -d。這個cmd窗口現在很忙。
3. 再掀cmd.exe創建一個回購協議：svnadmin create d:\svn_repos\test12
4. 負載突降到回購：svnadmin load d:\svn_repos\test12 < d:\temp\svn\backup_test.dump

的svnserve會給你詳細的信息是什麼失敗。

而這裏的你有什麼修復（原上左，上修右側）：