我该如何解决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会给你详细的信息是什么失败。

而这里的你有什么修复（原上左，上修右侧）：