SVN分支模型的任何缺点:分支 - > next-branch,放弃trunk？

Question

我们有一个发布模型,为了简单起见,我们会说每月1个.所以,我们通常会去:

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

我们正在考虑放弃主干,给出更像的模型:

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

我们永远不会合并回主干.虽然工作在Feb分支上进行,但任何紧急修复都发生在Jan分支上,并且合并到2月的代码库.

这似乎提供了很多好处,包括远远少于合并.有人发现明显的缺陷/缺点,理想情况是经验吗？

Answer 1

这似乎提供了充足的好处

看不到任何,但至少可以发现一个头痛

包括远,更少的合并

错误.两个工作流中的修补程序的前向移植具有相同的合并量

简历:

Subversion中的所有URL都具有相同的权限,使用路径/主干作为主线只是方便,您可以忽略.但是不要忘记侧边 - 而不是单独svn up使用比当前月份修改更早的版本svn switch & svn up(并在切换之前识别此版本的URL - 也将日志添加到列表中)