3

我正在尝试将远程 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在一次针对所有修订版运行时从未成功？

4

1 回答 1

4

您没有提及您使用的是哪个版本的 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，因为修复是针对使用 serf 的重播实现svnrdump。

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

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

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

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

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

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

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

但是，当您可以使用--incremental.

关于您提到的校验和错误。我有点想知道它们是否可能与我们最近注意到的 zlib 问题无关。你没有提到你在哪个平台上，但是 Windows 版本的 Subversion 通常是用一个程序集优化版本的 zlib 构建的，这恰好是错误的。它们不应该被使用，但它们是。您可以从此users@subversion.apache.org 邮件列表帖子中找到详细信息。

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

于 2013-11-11T01:27:29.053 回答