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