Question

我必须导入一个庞大的SVN存储库，我必须从一台服务器转移到另一台服务器。所以我从旧服务器导出它：

svnadmin dump . > archive.svn

并将其导入新的：

svnadmin load . < archive.svn

在导入过程中，我遇到了这个错误：

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

我该如何解决这个问题？我完全控制了两台服务器。

Answer 1

您有2个选项，修复源或禁用道具验证。

修复源（svn：log和svn：ignore）：

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 2

@ 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

将^M替换为[blank]非常重要，因为属性值的大小不得更改。

@ ventura10的注释仍然有效：

^ M是一个控制字符，表示十六进制的0D。为了得到它使用^ V ^ M. （对照V对照M）代替^ M（抑扬M或对照M）

很难相信将现有的存储库从svn 1.4升级到svn 1.7会使这个步骤变得简单，但是我找不到其他方法来摆脱自svn 1.6以来不再接受的回车。

Answer 3

您是否更改了服务器版本？这是1.6中的已知问题，从1.4或1.5开始会导致问题。

Subversion 1.6不再接受属性文件中的回车符（^ M）。您需要修复svn中的换行符：忽略文件，或者重新创建，如果这更容易。

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

Answer 4

通过一点体操，你可以使用svnsync解决这个问题，它可以修复EOL。假设您的存储库已转储到archive.svn。

首先创建存储库以加载repo，忽略EOL问题：

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

现在创建一个新的存储库以便复制到：

svnadmin create repo-fixed

svnsync需要一些预提交钩子，即使你不使用它，所以只需使用你的编辑器在repo-fixed/hooks/pre-revprop-change中创建一个空的：

#!/bin/sh
exit 0

初始化svnsync的目标存储库：

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

现在复制整个存储库：

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

呼！ svnsync甚至会给你带来好消息：NOTE: Normalized svn:* properties to LF line endings（为什么Subversion团队没有更新svnadmin进行同样的规范化对我来说是一个谜。）

完成后，转储新的存储库：

svnadmin dump repo-fixed > archive-fixed.svn

您现在拥有archive-fixed.svn，除了根据需要修复了EOL之外，它应与archive.svn相同。

（可选）您现在可以删除用于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。

（这篇帖子是我在网络上发现的众多片段和部分解决方案的高潮。感谢所有知道的人比我做的更多;我只是把它们放在一起。）

另见：

Answer 5

将1.6 repo升级到1.8时遇到此错误。我在网上发现了一些“修复”。

- bypass-prop-validation 对我没有吸引力，因为它推迟了问题，下次你需要恢复回购时，你会遇到同样的问题。

我找到了一个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

注意：

其中^ M是控制字符，表示十六进制的0D。要使用它 ^ V ^ M（对照V对照M）而不是^ M（抑扬M或对照M）

Answer 6

使用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 7

我刚刚修复了一个svn转储文件。它在属性中也有一个CRLF，这导致SVN边缘转储导入中的异常（它们有一个非常糟糕的导入例程）。然后我安装了＆＃34;用于测试的 svnserve ，这比预期的要容易得多（Windows操作系统的说明）：

下载并安装TortoiseSVN或其他包含svn命令行工具的软件。我已经安装了
启动cmd.exe，运行svnserve -d。这个cmd窗口现在很忙。
开始另一个cmd.exe创建一个回购：svnadmin create d:\svn_repos\test12
将转储加载到仓库：svnadmin load d:\svn_repos\test12 < d:\temp\svn\backup_test.dump

svnserve将为您提供失败的详细信息。

以下是你需要修理的东西（原件在左边，在右边修理）：

Answer 8

我使用了svnadmin load --normalize-props {myrepo} < {mydumpfile}，效果很好。

--normalize-props开关已添加到版本1.10中。有关详细信息，请参阅https://subversion.apache.org/docs/release-notes/1.10.html#normalize-props

为方便而复制-

用于svnadmin加载的新--normalize-props选项

新的--normalize-props选项已添加到svnadmin load命令。此选项可用于自动修复svn：log或svn：ignore等属性中的非LF行尾。这种无效的行尾被较旧的服务器接受，可以在较旧的存储库的存储库转储中找到，但被Subversion 1.6及更高版本拒绝。

使用--normalize-props调用svnadmin load将自动修复转储流中发现的所有无效属性行结尾，从而确保将适当的值加载到存储库中。

Answer 9

我的问题是提交的评论太大。

如何修复SVN导入行结尾错误？

9 个答案: