svn - 如何将一系列部分 svn 转储组合到一个存储库中？

Question

我正在尝试将远程 Subversion 存储库恢复到我的本地计算机上。我无法直接访问服务器来运行 shell 命令，但我对存储库本身拥有完整的 svn 权限。

由于某种我们尚未确定的问题，svnsync 和 svndump 以及我尝试过的任何其他东西在一次针对整个存储库运行时都不会成功。在操作期间的某个时候，它会失败并显示诸如“连接超时”或“无法访问 block ”或类似消息的消息。我们无法找到问题的根源，可能是服务器上的软件问题、损坏的存储库，或者可能只是网络连接不可靠。不管是什么问题，控制服务器的人帮助我们解决问题的速度都非常慢，所以我们正在努力解决这个问题。

我能够批量修改服务器转储。我运行了一系列类似于这些的命令来获得这样的部分转储:

svnrdump dump -r0:499 https://server/svn/respository > 0-499.dump
svnrdump dump -r500:999 https://server/svn/respository > 500-999.dump
svnrdump dump -r1000:1499 https://server/svn/respository > 1000-1499.dump

这让我解决了服务器问题。当转储超时或出现其他问题时，我只是重试该部分直到它起作用，或者使用较小的增量。现在我有许多转储文件，它们一起代表整个存储库。

我的问题是:如何将这些单独的转储合并到一个本地存储库中？

我试过使用一个空的本地存储库来执行此操作:

svnadmin load repository < 0-499.dump
svnadmin load repository < 500-999.dump

第一个命令有效，但第二个命令失败。错误消息表明它正在尝试添加一个已经存在的文件，但它放弃了。我发现我可以改为这样做:

svn mkdir batch1
svnadmin load --parent-dir "batch1" repository < 0-499.dump
svn mkdir batch2
svnadmin load --parent-dir "batch2" repository < 500-999.dump

这成功地将单独的修订批处理加载到存储库中的单独目录中，但我不确定如何/是否可以将它们重新组合到一个文件夹中。

我也知道我可以在创建转储时使用 --incremental 开关，但我不确定这是否是个好主意，因为我怀疑增量数据中可能存在一些损坏(我怀疑的原因之一这是因为在存储库上运行 svnsync 或 git svn clone 有时会因校验和不匹配而出错)

我能否以某种方式将我拥有的非增量顺序转储组合到一个统一的新存储库中？如果没有，考虑到 svnsync 和 svnrdump 在一次针对所有修订运行时从未成功，我应该使用什么其他方法来执行此操作？

Answer 1

您没有提及您使用的是哪个版本的 Subversion，但在 1.8.3 之前，svnsync 和使用 serf http 库时出现问题。高于 1.8.0 的 Subversion 版本总是使用 serf 作为 http/https。 1.5.0 - 1.7.x 可以根据构建时间和运行时配置选择使用它。我们所做的更改在 CHANGES 文件中显示为:

* svnsync: fix high memory usage when running over ra_serf (r1515249 et al)

我相信这个问题也会影响 svnrdump，因为修复是针对 svnrdump 也会使用的 serf 的重放实现。

这种高内存使用率通常会导致非常奇怪和随机的错误。在某些情况下，机器上的交换使用会导致超时和其他奇怪的错误。

所以首先尝试更新到 Subversion 1.8.4(当前较新的版本)，看看你现在是否可以转储整个 repo。

现在回到你原来的问题。为了做你应该做的事情，你真的应该在第一次转储后对转储使用 --incremental 。您的负载问题完全是因为在这些后来的转储中没有使用 --incremental 。根据 svnadmin help dump 的输出:

If --incremental is passed, the first revision dumped will describe only the paths changed in that revision; otherwise it will describe every path present in the repository as of that revision. (In either case, the second and subsequent revisions, if any, describe only paths changed in those revisions.)

由于您没有通过 --incremental，所以第一次修订包括完整的树而不仅仅是更改，因此当您尝试加载它时会发生冲突。

您对使用 svnsync 看到的校验和错误的担忧应该没有任何不同。 --incremental 仅更改您请求范围内第一个修订版的输出行为。事实上，使用 --incremental 可以让服务器做更少的工作并且不太可能遇到问题，因为提供完整的树可能需要它返回到它可能不需要的修订。

可能有一些方法可以解决未使用 --incremental 选项的问题，但您基本上必须删除每个转储的第一个修订版。将其转换回增量更改集，然后应用它。可能可以通过将它加载到一个 repo 中然后通过 wc checkout 导出树来做到这一点，检查它然后在事后修复修订 Prop (日志、作者、日期等)。

但是，当您可以使用 --incremental 时，所有这些工作似乎都非常繁重。

关于您提到的校验和错误。我有点想知道它们是否可能与我们最近注意到的 zlib 问题无关。您没有提到您使用的是什么平台，但 Windows 版本的 Subversion 通常是使用 zlib 的程序集优化版本构建的，而这些版本恰好是错误的。它们不应该被使用，但它们确实被使用了。您可以从this users@subversion.apache.org mailing list post中找到详细信息.

如果存储库损坏，那么您可能很难获得有用的转储。您可能需要跳过一些障碍或从存储库管理员那里获得帮助。