svn 的非 LF 行结束问题 svn:ignore on dump load

Posted 2023-02-23

【中文标题】svn 的非 LF 行结束问题 svn:ignore on dump load

【英文标题】：Svn non-LF line ending problems with svn:ignore on dump load

【发布时间】：2012-07-24 19:57:31

【问题描述】：

我正在尝试使用转储文件将运行 svn 版本 1.2.3 的系统上的存储库（具有完整的历史记录）迁移到运行 1.7.1 的系统上。由于原始存储库是这么早的版本，因此不能直接使用svnrdump。我使用了svnadmin dump，然后将（8 GB）转储文件移动到了 1.7.1 系统。但是，当我从那里使用 svnrdump load 命令时，经过 231 次修订后，出现以下错误

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

我尝试从修订版 231 中删除 svn:ignore 属性，但无济于事，以及多个第三方应用程序，如 svn2svn（我们使用身份验证，所以没有骰子）。和svndumptool eolfix/svndumptool copy（显然只适用于.txt文件）。

最初我在 'svn:log' revprop 上进行了 11 次修订后遇到了类似的错误，我通过运行 dos2unix 修复了该错误（更糟糕的是），然后使用脚本/手动修复了 svnadmin dump 失败的每个文件在。

我对两个系统（unix，不确定是什么发行版）都具有 repos/root 访问权限的管理员访问权限。这是一个旧的，目前被认为是未使用的存储库，我们希望保存它以防万一某些项目再次需要。此外，使用svnadmin load 布局新存储库的方式非常复杂。 svn:ignore 错误有简单的修复方法吗？或者更简单的方法来移动整个东西？

谢谢

【问题讨论】：

你能从源代码编译颠覆吗？似乎有一种简单的方法可以修补“svnrdump load”代码，以便以与 svn:mergeinfo 相同的方式即时将 CRLF 转换为 LF。

编译颠覆当然是可能的，但相当困难。我整个上午都在尝试它，但收效甚微。此外，SVN 1.7.5 中的svnrdump，我可以访问但不包含存储库的另一台机器上的版本，应该具有将非 LF 结尾转换为 LF 的功能（至少，源中有 cmets代码），但似乎并非如此......

是的，如果你不知道一个秘密的方法，颠覆编译会变得复杂：vcs.atspace.co.uk/2012/06/29/… 我无法重现你的问题，无论我做什么，SVN 都会自动将 svn:ignore 转换为 LFs。但是你可以做的 --- 只需编辑 subversion/svnrdump/load_editor.c 的 'set_node_property' 函数来处理 svn:ignore 与在这个函数中处理 svn:mergeinfo 的方式完全相同（我的意思是 'svn_subst_translate_cstring2' 调用）。我相信这应该会有所帮助，尽管我没有尝试，因为我无法复制。

感谢您的帮助，我同意这确实是一个奇怪的问题。我也想知道为什么 SVN 不自动转换它，它就在源代码中，但它可能与旧版本有关。我已将 1.6.x 安装在不同的目录中，并试图查看通过较新版本转储文件是否会消除问题的原因，而不是事后修复它。我还将它们放入一个压缩包中，并可能在另一台机器上解压缩，转储，然后加载。我们拭目以待。再次感谢您的帮助，如果需要，我一定会尝试一下。

我在尝试使用svnadmin 的 v1.8.10 加载 repo 时遇到了同样的问题。实际上，转储是在同一台 PC 上使用相同的实用程序创建的——我只是从备份中恢复转储。我个人认为这是一个错误，因为创建的转储是一种“不可用”的方式。幸运的是，实用程序提供了一个“修复”：使用--bypass-prop-validation 选项，这对我有用。但同样，这种转换不能即时应用（例如，通过额外的--fix-crlf-prop-value）？因为现在在导入之后，我相信转储仍然会有那个“隐藏”的问题。

【参考方案1】：

您应该使用： svndumptool eolfix-prop svn:ignore

而不是： svndumptool eolfix