我们有一个庞大的庞大的Subversion存储库，包含60多个项目。 trunk，branches和tags目录位于存储库的根目录中。一些分支完成branches/project/branchName。其他人完成branches/BranchName/project。有很多事情。
有近200,000个修订，22Gb和60多个项目。
我想重新构建存储库，因此每个项目都有自己的存储库，并制定标准的分支策略。转储整个存储库大约需要7到8个小时，然后过滤掉我想要的是一个非常漫长的过程，因为我必须多次运行svndumpfilter。
我在想一个新策略。如果我查看单个项目中涉及的修订版，我们可能会讨论400个修订版。我知道我可以在一系列修订版上运行svnadmin dump。如果我只删除我感兴趣的项目的修订版怎么办？我可以为每个版本运行svnadmin dump。我认为这实际上可能更快。但是，这将如何影响到新存储库的负载？
是否存在仅仅转储我想要的修订版的问题？
答案 0 :(得分：1)
我想到的第一个问题是，您无法将新转储直接加载到新的存储库中，因为这些转储将缺少创建父文件夹的节点（ trunk / branches / 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标头，因为开发人员只需要该项目的一些共享文件并使用{{1命令。在这里，过滤的疯狂将开始。为了缓解这种情况，您可能会尝试使用svndumpfilterIN脚本处理这些转储，这将使用svn copy从实时存储库中删除丢失的文件。但请注意，它有自己的错误（请参阅我对这个问题的回答：SVNDumpFilter changing paths before adding them?）。
在第三个想法中，如果你想为每个项目单独存储，你可能还想将转储的项目重新定位到根文件夹，这就是事情变得非常混乱的地方。例如，我所知道的几乎所有工具都无法在转储中重新定位路径，例如Svn-DumpReloc，svndumpsanitizer（不确定svndumptool合并黑客）进程svnlook属性以及将导致转储导入失败。
所以，考虑到你的限制，我无法看到使用部分转储的解决方案，之后不需要手动修改repos和dump文件。