加载的 svn 存储库缺少最后几个修订版 - 我该如何解决这个问题？答案

【问题标题】：Loaded svn repository is missing last few revisions - how do I fix this?加载的 svn 存储库缺少最后几个修订版 - 我该如何解决这个问题？
【发布时间】：2010-01-12 20:10:12
【问题描述】：

我转储了我的存储库

svnadmin dump repos > repos.dump

然后我把它加载到新机器上

svnadmin load newrepos < repos.dump

完成后，新存储库缺少最后几百个修订版。

我可以检查 repos.dump 以查看它是否缺少修订版吗？我可以转储丢失的修订并将它们加载到新的存储库中吗？或者，我是否必须从头开始。

从头开始会很痛苦，因为存储库是 3GB，我必须以适中的低速通过 Internet 获取它！

编辑：已解决 - 操作员错误！

所以，我忘记了我已经迁移了一次存储库（从 account1 到 account2）并且我从未删除过 account1 存储库。我有一个 bash 功能可以快速 ssh 到我的远程帐户，它默认将我登录到 account1（我没有考虑过），因为我看到了存储库，我认为一切都很好，因此将转储发送到 account3（再次使用一个别名，这样我就没有注意到我在错误的帐户中）。

现在，我要在终端中将帐户的用户名设置为鲜红色，并且我正在缓存旧的存储库，而不是让它们到处乱放。而且，我正在删除我的个人资料黑客的默认用户方面。

但是，我能够使用--incremental 将缺失的修订版转移到新位置。所以，所有的建议仍然有帮助。

【问题讨论】：

您是否正在加载到一个完全干净的新存储库中？

标签： svn svnadmin

【解决方案1】：

我猜您的转储大于 4 GB（因为默认情况下转储不与增量一起保存，因此它们可能比存储库大得多），并且传输转储过程的某些步骤被截断为 4 GB，这是某些文件系统（也可能在某些协议中）的最大文件大小。根据您使用的文件传输方法，该过程的某些步骤也可能会将其截断为 2 GB。

您可以通过检查文件来检查；它应该有修订号，你可以看到它们有多高。

您可以使用svnadmin dump 的--incremental 选项生成增量转储，而不是重新开始整个过程，从您加载到新存储库中的最后一个良好修订开始。将增量转储加载到现有存储库中应该可以正常工作。你会做类似的事情

svnadmin dump --incremental -r 1234:HEAD > repos.2.dump
# Transfer to new system
svnadmin load < repos.2.dump

【讨论】：

+1 - 很好地抓住了 4Gb 文件大小。在转储命令上抛出--deltas 可能也是一个好主意。

【解决方案2】：

我可以检查 repos.dump 以查看它是否缺少修订版吗？

是的。有像

这样的行修订号：XYZ

在转储文件中。

我可以转储丢失的修订并将它们加载到新的存储库吗？

是的。您可以使用 svnadmin load 将修订提交到新的或现有的存储库。

【讨论】：

【解决方案3】：

要验证所有版本是否都在您的转储文件中，请使用 grep 查找“版本号”。您也可以在文本编辑器中打开文件以检查是否有任何明显的损坏，但 do not save it。

我发现svnadmin load 失败的主要原因是您尝试加载到已包含内容的存储库中。 load 命令将在获取转储文件之前检查以验证存储库是否处于预期状态。我过去在转储存储库时使用--incremental 标志解决了这个问题。

【讨论】：

【解决方案4】：

它应该在进行转储时将修订号写入命令行。这就是我得到的，即使像你一样重定向到一个文件。

您可以检查文件本身并查找 Revision-number: 以查看其中实际包含哪些修订。

【讨论】：

【解决方案5】：

就个人而言，我会再次转储它。我认为最可能的答案是您的原始转储未成功完成 - 转储运行后您是否在命令行中看到任何错误？如果您想检查转储本身，请查看以下内容以获得帮助：http://www.troyhunt.com/2009/12/black-art-of-splitting-subversion.html

您可以考虑的另一件事是将原始存储库转移到目标位置。您将复制数据的压缩版本，因此该过程将比复制转储更快（不确定您是否在传输前对其进行了压缩）。

【讨论】：