我有一个很大的SVN存储库(约40k个版本)，其中一个特定的特性分支是很久以前(约15k)为当时的产品版本创建的。然而，其他事情占据了优先级，直到现在，它被推迟了几个版本。
随着时间的推移，分支与来自主干和其他子分支的合并保持同步，并且它仍然在当前状态下构建和运行良好。
然而，在这个分支和主干之间尝试switch会导致大量的delete-read操作(大概是因为从公共分支点开始，文件被添加到主干，然后添加的文件被合并到功能分支，所以现在它们被视为替换而不是修改)。虽然这在一个干净的树中本身没有直接的危害，但它确实浪费了时间和网络流量，并且如果切换到一个脏树，它会导致主要的冲突，而不是安静的合并。
因此，我想通过删除这个分支，从当前主干创建一个新的分支，然后合并来自前一个分支的所有"实际"更改来重新构建这个分支。(我们的想法是，这将简化未来的切换，并使它更容易看到真正的变化是什么。)
我能找到的关于这个主题的大多数建议只是简单地说到merge old-feature-branch，让合并跟踪照顾其余的。然而，我已经尝试过(通过TSVN的测试合并按钮，到目前为止)几次，并有一些较小的修订子集，但不可避免地，我似乎在各种各样的文件上得到了巨大的冲突，这些文件一开始就不应该被旧功能分支触及。
当我尝试一个真正的合并(从一个工作副本在新功能分支，svn merge svn://url/branches/old-feature-branch)，我得到这个错误:
svn: E160013: File not found: revision 38143, path '/branches/new-feature-branch'
好的，当然，新的功能分支直到38509才创建，所以它当时不存在。但我不知道它为什么会这么认为。那个特别的修订没有什么特别的，只是对主干的一个小改动，它应该已经在new-feature-branch的历史记录中，因此无论如何都不会合并。
是否有一个工具或程序，我可以遵循简化这一点，或者我只需要工作的方式通过所有的修订和手动冲突?我可以将历史"压缩"到单个提交或比最初提交到分支的更小的一系列提交中。
- 将
old-feature-branch合并到trunk和old-feature-branch合并到new-feature-branch的"合并地狱"将不差异很大-两次合并将从同一个(非常旧的)分支点开始，新功能分支路径甚至会长1个版本 - 对于SVN 1.6+(但我建议1.8+比1.6/merge更容易和更智能)，您可以尝试(但不要期望奇迹在任何情况下)在合并源中使用同时使用操作和peg-revision(使用
old-feature-branch的HEAD) - 对于任何一个巨大的合并，你可以得到树之间未合并的修订列表
svn mergeinfo --show-revs eligible ...和合并一步一步的风格(svn merge -c-每次合并的灾难更少) - 如果分支历史(
old-feature-branch)在new-feature-branch中不重要也不需要，你可以在新分支中替换内容- 将
old-feature-branch的HEAD导出到$SOMETHING - 从trunk的HEAD创建
new-feature-branch并签出 - 将
new-feature-branchWC的全部内容替换为$SOMETHING - 将这些"压缩"的变更历史作为
new-feature-branch的新版本提交 - 忘记
old-feature-branch的日常任务
- 将