采用 SVN 分支模型的缺点：创建分支 -> 下一个分支，放弃主干？

Question

采用 SVN 分支模型的缺点：创建分支 -> 下一个分支，放弃主干？

3

我们有一个发布模型，简单来说，每月发布1次。因此，我们通常按照以下步骤进行：

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

我们正在考虑放弃主干，采用更类似的模型：

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

我们永远不会合并回主干(trunk)。在2月分支(Feb branch)上进行工作时，任何紧急修复都将在1月分支(Jan branch)上进行，并向下合并到2月的代码库。

这似乎提供了很多好处，包括极少的合并操作。有没有人从经验上发现明显的缺陷/不足之处呢？

- Brian

3个回答

1

看起来你分支太早了，试图放弃这个早期分支，但并不知道。

在正常的基于主干的工作流中，你会在"Jan"发布后立即分支。然后你继续在主干上工作，并在"Feb"发布时分支出"Feb"。换句话说：在主干模型中，你要推迟到发布点再进行分支。当你发现自己除了功能分支或热修复分支之外合并任何东西回到主干时，工作流就出问题了。在发布分支上计划大量工作是错误的。主干和功能分支是为日常工作而设计的；发布分支是为紧急情况而准备的。

你的新模型很好，但可以保留已经建立的命名约定：

 trunk
 trunk -> Jan   /* Release */
 trunk <- Jan   /* Hotfix */
 trunk -> Feb
 trunk -> Mar
 trunk -> Apr

请注意，这与无干线模型在拓扑上是等价的：

trunk                     Jan
 +----------- Jan          +------------   
 +------- Feb  |       Feb +--------   |
 +--- Mar  |   |       Mar +----   |   |
 |     |   |   |       Apr |   |   |   |
 |     |   |   |           |   |   |   |
trunk Mar Feb Jan         Apr Mar Feb Jan

然而，在无主干模型中，您不断地重命名垂直路径，在主干模型中这个路径被命名为“trunk”。由于大多数时间每个人都在主干上工作，像LazyBadger已经说过的那样，这种命名方式会让你在很多切换中遇到阻碍。

虽然 "svn switch" 的成本确实不高，但是忘记 "svn switch" 的成本却很高。在某个时候，当 "Apr" 是当前分支时，有人回来度假后意外地在 "Mar" 上工作。然后，您将不得不检测出这个问题（QA），将代码合并到 "Apr" 中并在 "Mar" 中恢复。当通常的工作在 "trunk" 上完成时，问题不会发生，因为 "trunk" 总是一个新工作的好起点。

- thiton

我明白你的意思了。与其在分支上工作，并将主干用作合并点，不如在主干上完成所有工作 - 并仅将诸如Jan、Feb等分支用于任何后续修复工作（如果不需要修复，则它们几乎只是标签）。这听起来是一种有效的方法，但从恶魔的角度来看，我认为它本质上并不比Jan分支->Feb分支->Mar分支等更好？ - Brian

欢迎讨论并点赞。顺便说一句，我很乐意就这个问题交换想法。 - Brian

@Brian：尽量少更改名称会更好。更新了答案以展示区别。 - thiton

0

回答自己的问题，为其他读者提供参考：在几个月和几个版本之后，这种方法运行良好；我们所期望的好处都实现了，没有出现任何不利因素。团队一致认为这是一个更好的模型。

- Brian

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Lazy Badger · Accepted Answer

这似乎提供了很多上升空间

看不到任何，但至少可以检测出一个头疼的问题

包括更少得多的合并

错了。在两个工作流程中，补丁的转发合并数量是相同的

简历：

Subversion中所有URLS具有平等的权利，使用主线路径/ trunk只是惯例，您可以忽略它。但不要忘记侧面影响 - 与其单个svn up到一些早于当前月份版本的回退，您将需要svn switch&svn up（在切换之前识别此版本的URL-也将其添加到日志列表中）。