VisualSVN错误 - 修订文件缺少尾随换行符

Question

我们在Windows Server 2003上安装了VisualSVN Server 2.1.3，并且所有客户端计算机都使用TortoiseSVN客户端进行提交和其他svn操作。一切都很好，直到昨天。

昨天，我在晚上提交了修订号22181并离开了办公室，这是自昨天以来发生的最后一次提交。 当我今天尝试显示日志或尝试更新SVN时，我收到此错误：

Revision File Lacks Trailing Newline.

然后我开始研究并尝试了很多东西，包括下面的链接，当我输入错误描述时谷歌的第一个结果。

http://www.jamesstroud.com/jamess-miscellaneous-how-tos/os-x-admin/fix-svn-revision-file-lacks-trailing-newline

虽然这个链接说当svn提交大小超过4GB但是我做的最后一次提交几乎不是1MB时会发生这个错误。我仍然执行了帖子中提到的上述步骤，之后我能够显示登录到存储库，这是一个好兆头但是当我尝试提交文件时我又遇到了另一个错误：

Cannot move tempfile.2.tmp to txn-current : the disk structure is corrupted.

然后我恢复了上面的更改，因为我在开始时进行了备份并进行了更多研究，并按照上述说明，它让我知道问题出在我昨天提交的最后一次修订中。然后我尝试svnadmin.exe使用命令行并使用dump命令在修订版1-22180之间制作转储文件但是很惊讶地看到我的服务器被挂起了因为可能正在创建的转储大小超过了大小我保存转储文件的地方。转储后面的主题是转储所有修订，除了最后一次是22181，然后创建一个新的存储库并加载转储文件，这可能会解决问题。然后我读到如果我们在dump命令中指定特定的修订版，则它比整个数据库创建的转储占用更多的空间。但是如果转储整个数据库，那么如何从完整的转储文件中删除最后一个修订版？

如果你想知道svnadmin命令我跑了，那么这里是： svnadmin.exe dump –r 1-9 F:\svn-repo > C:\Tempdump.dmp

现在我发布此消息后尝试使用verify命令。

请帮助我解决这个问题，因为我现在很累，明天我们的工作人员将无法在没有svn操作的情况下工作，因为这很关键。我们的SVN存储库大小接近35GB，我想如果我必须使用dump命令，那么我将不得不附加一个USB硬盘以便将转储文件保存为服务器驱动器，其中最大空间是C盘，空间为48GB。

我不确定实际解决方案是什么。请帮助并感谢您阅读所有内容。

感谢

Answer 1

1. 存储库已损坏，您是否有要从中还原的备份？ 从备份中恢复存储库将是最佳解决方案。

   一般来说，运行svnadmin verify是有意义的 存储设备上的每个存储库都要检查它 腐败。请参阅svnadmin verify command-line reference。

   请注意，存储设备（HDD？）看起来已损坏 在你提交修订版22181的那天晚上，我强烈推荐 使用chkdsk工具检查错误，替换，如果 需要。请参阅chkdsk tool reference。

2. 预计由svnadmin dump生成的转储（使用默认值 settings）大于磁盘上的存储库。 如果要使修订版0-22180的转储量减少，请使用 “--deltas”选项。

   请参阅SVNBook | Repository data migration using svnadmin：

     

   默认情况下，转储文件将非常大 - 远大于   存储库本身。那是因为默认情况下每个版本都有   文件在转储文件中表示为全文。这是最快的   最简单的行为，如果您正在管理转储数据，那就太好了   直接进入其他一些过程（如压缩程序，   过滤程序或加载过程）。但是如果你正在创建转储   用于长期存储的文件，您可能希望节省磁盘空间   使用--deltas选项。有了这个选项，连续修改了   文件将作为压缩的二进制差异输出 - 就像文件一样   修订存储在存储库中。此选项较慢，但它   导致转储文件的大小与原始存储库的距离更近。

Answer 2

我发现此问题并非特定于Windows或Linux。这是我遇到此问题的背景。我的开发服务器上有一个旧的Linux发行版，并且多年没有更新，gentoo很难更新，因此我想确保在擦除服务器并重新安装之前可以将SVN存储库迁移到最新的SVN。 。较旧的SVN版本为1.8.11。新的SVN是最近的1.9.5。版本之间的差异是4年。

因此，我将介绍如何在Linux下解决此问题。

svnadmin dump <old repo path> > SVN-Repo.dump

然后，在创建SVN存储库之后，在安装了新SVN服务器的新服务器上：

mkdir -p <new repo path>
svnadmin create <new repo path>

然后设置所需的任何权限。

运行命令：

svnadmin load --force-uuid <new repo path> < SVN-Repo.dump

对我来说，解决了这个问题。

总而言之，我怀疑这些错误是由损坏的存储库引起的。我认为这些问题更有可能是由于svn不兼容而导致读取了旧SVN格式和新SVN格式的格式。

例如，如果我在旧版本上创建了一个新的SVN存储库，然后将其复制到新版本的SVN中，它将失败，并显示相同的错误。然而，它没有任何时间可以腐败。另外，对我来说，当我尝试在旧的SVN存储库文件上使用新的SVN时，它显示第二次提交（661）很好，而最后一次提交（662）已损坏。当我删除了最后的提交（662），然后再次尝试时，它表明新的最近的提交（661）已损坏，即使它说该提交以前很好。这些错误已在svnadmin verify中看到。在我看来，这是修订历史记录下方的页脚不可读，并且回购内容本身也不错。

当我们进行转储时，无论出于何种原因，页脚都不再引起任何问题。是因为它不存在，或者是更可靠地向后兼容，或者是因为它被忽略了。

因此，如果可能的话-不确定是否可以在Windows下执行此操作，但是我怀疑可以，将旧存储库的SVN转储，然后将转储导入新存储库。可能您的SVN已更新，并且导致了问题，就像我的问题一样？