重新定义一个长期存在的Subversion分支

时间:2014-07-07 07:10:32

标签: svn version-control merge branch rebase

我有一个庞大的SVN存储库(约40k版本),其中很久以前(约15k)为当时版本的产品创建了一个特定的功能分支。然而,其他事情都是优先事项,直到现在才被推回几个版本。

随着时间的推移,分支机构与主干和其他子分支的合并保持最新,并且它仍然在当前状态下构建并运行良好。

然而,在此分支和主干之间尝试switch会导致大量删除读取操作(大概是因为自公共分支点以来,文件被添加到主干,然后添加被合并到功能分支,所以现在他们被视为替代而不是修改。虽然这在干净的树中本身并不直接有害,但如果使用脏树切换,它确实会浪费时间和网络流量并导致重大冲突,而不是安静的合并。

因此,我想通过删除它来重新定义这个分支,从当前主干创建一个全新的分支,然后合并所有"真正的"从上一个分支的变化。 (我们的想法是,这将简化未来的交换机,并让您更容易看到真正的变化。)

我能找到的关于这个主题的大多数建议只是简单地说merge old-feature-branch,让合并跟踪处理剩下的事情。但是我已经尝试过(通过TSVN&#39的测试合并按钮,到目前为止)几次并且有一些较小的修订子集,但不可避免地我似乎在所有类型的文件上都会发生大规模的冲突首先被旧功能分支所感动。

当我尝试使用真正的合并(来自新功能分支中的工作副本svn merge svn://url/branches/old-feature-branch)时,我收到此错误:

svn: E160013: File not found: revision 38143, path '/branches/new-feature-branch'

确定,新功能分支直到38509才创建,所以它不存在。但我不知道它为什么会这么想。这个特别的修改并不是什么特别的修改,只是对主干的一个小改动应该已经在新功能分支的历史中,因此无论如何都没有合并。

是否有我可以遵循的工具或程序可以简化此操作,或者我是否必须手动完成所有修订和冲突?我和#34;压缩"将历史记录转换为单个提交或比最初提交给分支的一系列提交。

1 个答案:

答案 0 :(得分:1)

  1. " Merge Hell"将old-feature-branch合并到trunkold-feature-branch合并到new-feature-branch大不相同 - 两个合并都将从相同(非常旧)的分支点开始,新功能分支路径甚至会延长1个版本
  2. 对于SVN 1.6+(但我建议使用1.8+并且比1.6 / merge更智能/更智能)你可以尝试(但不要指望奇迹在任何情况下)合并在合并源中使用操作和peg-revision (使用old-feature-branch的HEAD
  3. 对于任何巨型合并,您可以获取树svn mergeinfo --show-revs eligible ...之间的未合并修订列表,并逐步合并(svn merge -c - 每次合并时减少灾难)
  4. 如果分支历史记录(适用于old-feature-branch)并不重要且new-feature-branch中不需要,则只需替换新分支中的内容即可
    • old-feature-branch的HEAD导出到$ SOMETHING
    • 从主干的HEAD创建new-feature-branch并结帐
    • new-feature-branch WC的完全内容替换为$ SOMETHING
    • 承诺这个"压扁"作为new-feature-branch
    • 的新修订版的更改历史记录
    • 忘记关于old-feature-branch
    • 的每日任务