我们有一个庞大而草率的 Subversion 存储库，其中包含 60 多个项目。、trunk和目录位于存储库的根目录中branches。tags一些分支已经完成branches/project/branchName。别人都做完了branches/BranchName/project。有很多杂物。
有近 200,000 个修订版、22Gb 和 60 多个项目。
我想重组存储库，所以每个项目都有自己的存储库，并制定标准的分支策略。转储整个存储库大约需要 7 到 8 个小时，然后过滤掉我想要的内容是一个非常漫长的过程，因为我必须运行svndumpfilter多次。
我正在考虑一个新的策略。如果我查看单个项目中涉及的修订，我们可能会谈论 400 个修订。我知道我可以进行svnadmin dump一系列修订。如果我只转储我感兴趣的项目的修订版怎么办？我可以svnadmin dump为每个修订版运行。我认为这实际上可能会更快。但是，这将如何影响加载到新存储库中？
是否存在仅转储我想要的修订的问题？
我想到的第一个问题是您无法将新转储直接加载到新存储库中，因为这些转储将缺少创建父文件夹（trunk/branches/tags等）的节点，并且svnadmin load命令将因File not found错误而失败。因此，您必须事先创建它们，如下所示：svn mkdir http://server/svn/ProjectX/Trunk -m "Created Trunk"
再想一想，如果对您的项目的提交具有交叉引用，则可能存在各种其他问题。例如，您将 1000 到 1500 的修订版本转储为/branches/ProjectX/branch，但转储中的某些节点将包含Node-copyfrom-rev: 800和Node-copyfrom-path: /branches/ProjectY/branch标头，因为开发人员只是想要该项目中的一些共享文件并使用该svn copy命令。这里将开始疯狂的过滤。为了缓解这种情况，您可以尝试使用svndumpfilterIN脚本处理这些转储，该脚本将为您从实时 repo 中提取丢失的文件svnlook。但请注意，它有自己的错误（请参阅我对这个问题的回答：SVNDumpFilter changed paths before adding them?）。
第三个想法是，如果您想为每个项目单独存储库，您可能还希望将转储的项目重新定位到根文件夹，这就是事情变得非常混乱的地方。例如，我所知道的几乎没有一个工具能够在转储中重新定位路径，例如Svn-DumpReloc、svndumpsanitizer（不确定svndumptool与合并黑客）进程svn:mergeinfo属性，这将导致您的转储导入失败。
因此，鉴于您的限制，我看不到使用部分转储的解决方案，这不需要事后对存储库和转储文件进行一些手动修改。