3

我转储了我的存储库

svnadmin dump repos > repos.dump

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

svnadmin load newrepos < repos.dump

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

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

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

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

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

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

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

4

5 回答 5

4

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

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

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

svnadmin dump --incremental -r 1234:HEAD > repos.2.dump
# Transfer to new system
svnadmin load < repos.2.dump
于 2010-01-12T20:27:12.063 回答
1

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

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

于 2010-01-13T04:03:24.007 回答
1

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

是的。有类似的线条

修订号：XYZ

在转储文件中。

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

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

于 2010-01-12T20:22:24.370 回答
1

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

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

于 2010-01-12T20:26:32.830 回答
1

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

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

于 2010-01-12T20:27:10.540 回答