svn - SVN 分支模型 : branch -> next-branch, 放弃主干有什么缺点吗？

Question

我们有一个发布模型，为简单起见，我们假设每月 1 次。所以，我们通常会去:

Jan -> trunk
       trunk -> Feb
       trunk <- Feb
Mar <- trunk 
Mar -> trunk
       etc

我们正在考虑放弃主干，给出一个更像这样的模型:

trunk -> Jan
  Jan -> Feb
  Feb -> Mar
  Mar -> Apr
  etc

我们永远不会合并回主干。虽然工作在 Feb 分支上进行，但所有紧急修复都在 Jan 分支上进行，并合并到 Feb 的代码库中。

这似乎提供了很多好处，包括少得多的合并。有没有人发现明显的缺陷/缺点，最好是根据经验？

Answer 1

This seems to offer plenty upside

看不到任何，但至少可以察觉到一处头痛

including far, far fewer merges

错了。两个工作流中补丁的前向移植具有相同数量的合并

简历:

Subversion中的所有URL都是平等的，使用路径/trunk作为主线只是约定俗成，你可以忽略。但是不要忘记 sidebacks - 而不是单个 svn up 到一些比当前月份更早的修订版，你将有 svn switch & svn up (并标识此修订版的 URL切换前 - 也将日志添加到列表中)