我正在尝试将远程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在同时针对所有修订版运行时从未成功过？
答案 0 :(得分：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，因为修复程序是使用svnrdump也将使用的serf重播实现。
这种高内存使用率通常会导致非常奇怪和随机的错误。在某些情况下，机器上产生的交换使用会导致超时和其他奇怪的错误。
首先尝试更新到Subversion 1.8.4（当前的新版本），看看你现在是否无法转储整个仓库。
现在回到你原来的问题。为了做你应该做的事情，你真的应该在第一次转储后在转储上使用--incremental。您的加载问题完全是因为在以后的转储中没有使用--incremental。根据{{1}}的输出：
如果--incremental被传递，则转储的第一个修订版将描述 只有该版本中的路径发生了变化;否则它会描述 存储库中存在的每个路径。 （在任何一个 case，第二个及后续修订（如果有）仅描述路径 在这些修订中改变了。）
由于您没有传递svnadmin help dump第一个修订版包含完整的树而不仅仅是更改，因此当您尝试加载它时会发生冲突。
您对使用svnsync看到的校验和错误的担忧应该没有任何不同。 --incremental仅更改您请求范围内第一个修订版的输出行为。事实上，使用--incremental会使服务器减少工作量并且不太可能遇到问题，因为提供完整的树可能需要它返回到它可能不需要的修订版。
可能有一些方法可以解决缺少使用--incremental选项的问题，但您基本上必须删除每个转储的第一个修订版。将其转换回一组增量更改，然后应用它。可以通过将它加载到一个仓库中然后将树导出整个树的wc checkout，检入它然后在事后修复修订道具（日志，作者，日期等）来做到这一点。 / p>
但是当你可以使用--incremental时，所有这些似乎都是非常重要的工作。
关于您提到的校验和错误。我有点想知道它们是否与我们最近注意到的zlib问题无关。你没有提到你正在使用什么平台，但是Windows版本的Subversion通常是用一个碰巧错误的zlib的程序集优化版本构建的。不应该使用它们，但它们是。您可以从this users@subversion.apache.org mailing list post找到详细信息。
如果存在存储库损坏的情况，那么您可能很难获得有用的转储。您可能必须跳过一些箍或从存储库的管理员那里获得帮助。