3

当我尝试加载/恢复我的 SVN 存储库时，我收到错误消息：

svnadmin: svndiff 包含一个太大的窗口

我该如何解决这个问题？

4

2 回答 2

4

自从我今天遇到这个...

您的 svn 存储库中的 FSFS 数据库可能存在损坏的修订。

备份您的 SVN 存储库。

通过读取 ${REPO}/db/format 确定您的存储库是否已打包/分片

[root@chi2 db]# cat format
4
layout linear

如果您的 fsfs 数据库是“布局分片”，您需要从此处获取fsfs-reshard.py：http://ymartin59.free.fr/wordpress/wp-content/2010/07/fsfs-reshard.py

（这个版本适用于 1.6+ 更大的存储库，这个家伙的补丁还没有移植到 svn trunk）。

运行以下命令解压缩存储库：

./fsfs-reshard.py ${REPO} 0

运行验证：

svnadmin verify ${REPO}

* Verified revision 13689.
* Verified revision 13690.
* Verified revision 13691.
svnadmin: E185001: Svndiff contains a too-large window

错误的版本是版本 1 比上次验证的版本大，我们的错误版本是 13692。

从 Subversion 主干获取 fsfsverify.py。http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/fsfsverify.py

在您的错误版本上运行 fsfsverify.py。您可能需要运行 -f 选项两次或更多次。这会吐出大量数据，但最终它应该是干净的。

[root@chi2 archive]# ./fsfsverify.py -f ${REPO}/db/revs/13692
Copy 4640123 bytes from offset 1006867
Write 4640123 bytes at offset 1003542
Fixed? :-)  Re-run fsfsverify without the -f option
[root@chi2 archive]# ./fsfsverify.py ${REPO}/db/revs/13692

再次运行 svnadmin 验证。对任何进一步的错误修订重复上述过程。

拥有经过验证的存储库后，您可以通过运行重新打包

./fsfs-reshard.py ${REPO} 1000

再次运行 svnadmin verify！

您的 SVN 存储库应该没问题！

于 2013-07-24T19:16:32.737 回答
0

我已经找到了这个问题的原因，这可能反过来可以帮助您解决它——尽管这在很大程度上取决于您在存储库中拥有的文件类型。

SVN 中的文件按名称和文件哈希记录（我相信它们是 MD5 的）。如果您删除该文件，然后再次尝试上传相同的文件，SVN 会记住哈希值，并且不会创建新的基本 delta 文件，而是将其指向之前存在的修订版本。

在存储库生命中的某个时刻，您的文件已“中毒”。任何与文件的 MD5 匹配的文件（无论提交路径如何）都将导致 svndiff 进程失败（原因仍不完全清楚），因为 SVN 尝试使用旧的和损坏的修订版。如果您想“修复”问题，请在本地修改文件（如果是代码，请尝试添加空白注释），这将导致 MD5 更改。删除文件并提交新的“固定”版本后，服务应恢复正常。

现在，回到我的第一段——这个解决方案只适用于你可以改变的文件。例如，如果您有一个 100MB 的视频文件 - 那么您将需要以某种方式对其进行修改以更改哈希值。如果您使用的是可执行文件，情况会变得更糟，因为众所周知，这些文件很难在编译后进行修改。

我的建议如下：

  • 如果它是基于文本的文件，请尝试制造修饰机会（例如，空白注释、额外的换行符等）
  • 如果它是可执行二进制文件，请尝试重新编译它。
  • 对于所有其他二进制文件（图像、视频等），您需要巧妙地修改它。

我希望这会有所帮助，找到这个问题的根源真的很痛苦。

于 2011-04-20T15:48:46.553 回答