我正在尝试将远程 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一次对所有修订版运行时从未成功，我应该使用什么其他方法来执行此操作？
你没有提到你正在使用的 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（当前较新的版本），看看现在是否无法转储整个存储库。
现在回到你最初的问题。 为了做你应该做的事情，你真的应该在第一次转储后在转储上使用--incremental。 负载问题完全是因为在这些以后的转储中缺少使用--incremental。 根据svnadmin help dump的输出：
如果传递了 --增量，则转储的第一个修订版将描述 仅在该修订中更改了路径;否则它将描述 截至该修订版时存储库中存在的每个路径。 （在任一 案例中，第二次和后续修订（如果有）仅描述路径 在这些修订中进行了更改。
由于您没有通过--incremental因此第一次修订版包括完整的树，而不仅仅是更改，因此当您尝试加载它时会发生冲突。
您对使用 svnsync 看到的校验和错误的担忧应该没有任何不同。 --incremental仅更改您请求的范围内第一个修订版的输出行为。 事实上，使用 --incremental 会使服务器减少工作量，并且不太可能遇到问题，因为提供完整的树可能需要它返回到它可能不需要的修订版。
可能有办法解决缺少使用 --incremental 选项的问题，但您基本上必须删除每个转储的第一个修订版。 将其转换回一组增量更改，然后应用它。 也许可以通过将其加载到存储库中，然后在整个树的 wc 检出处导出树，将其签入，然后在事后修复修订道具（日志、作者、日期等）来做到这一点。
但是，当您可以使用--incremental时，所有这些似乎
关于您提到的校验和错误。 我有点想知道它们是否可能与我们最近注意到的 zlib 问题无关。 你没有提到你在哪个平台上，但Windows版本的Subversion通常是用zlib的汇编优化版本构建的，而zlib恰好是有缺陷的。 它们不应该被使用，但它们是。 您可以从此 users@subversion.apache.org 邮件列表帖子中找到详细信息。
如果存在存储库损坏的任何情况，那么您可能很难获得有用的转储。 您可能需要跳过一些障碍或从存储库管理员那里获得帮助。