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

Question

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

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

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

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 也会使用的带有农奴的重播实现。

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

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

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

如果 --incremental 被传递，转储的第一个修订版本将描述 仅在该版本中更改了路径；否则它将描述 截至该修订版的存储库中存在的每个路径。 （在任一 情况下，第二个和后续修订版（如果有）仅描述路径 在这些修订中发生了变化。）

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

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

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

但是当您可以使用 --incremental 时，所有这些似乎都需要大量工作。

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

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