Question

在我正在开展的项目中，我们正在使用SVN和'Stable Trunk'策略。这意味着，对于找到的每个错误，QA会打开bug ticket并将其分配给开发人员。然后，开发人员修复该错误并在分支中对其进行检查（关闭主干，我们将其称为bug branch），该分支将仅包含针对该特定bug ticket的修复< / p>

当我们决定发布时，对于我们要向客户发布的每个错误修复，开发人员会将几个bug branch的所有修补程序合并到trunk并继续执行正常的质量检查周期。

问题在于我们使用trunk作为CI作业的代码库（具体而言是Hudson），因此，对于bug branch的所有提交，它将错过每日当我们决定发布新版本的软件时，直到它合并到trunk。显然，这违背了CI的目的。

解决此问题的正确方法是什么？

Answer 1

正如您所注意到的，使用分支的一个目的是将特定代码波动与修复故障和功能开发隔离开来。 但是一旦功能或故障单完成，您应该将其合并。在Subversion中，分支更好地用于跟踪相关功能集（如发布版本），而不是单个功能。否则你很快就会收到无法管理的分支。

此外，为什么要延迟整合呢？您在发布之间等待的时间越长，您的隔离更改与此后进行的另一次更改发生冲突的可能性就越高，并且/或者在合并后再次导致系统进一步出现不稳定。

我首选的策略是做这样的事情：

    [begin work on 0.4 branch]
       |
       |
       v              
(*)---(*)-------(a)--(b)---(c)-- <-- Trunk is "unstable".
         \       |          |        Contains all commits.
    ver   \   [merge from trunk]     Developers commit to trunk.
<-- 0.3    \     v          v
            +---(a)--------(c)-- <-- Branch is "stable".
                                     Contains selected commits from trunk.
                                     Know beforehand what's going onto branch.

现在，一旦你准备发布了：

[trunk]
(*)---(*)---(*)----------------------------[development continues]--->


[0.4 branch]                        No further development on branch unless
(*)---(*)---(*)---[0.4-release]     spot fixes are needed. Then re-tag (0.4.1)
                          ^         and re-release.
                          |         
                          |
                       [make tag on branch; release from stable branch,
                        not unstable trunk]

我知道您询问了强制您的持续集成系统执行此操作的最佳方法。但我恭敬地建议，鉴于Hudson被认为是一个相对有能力的CI系统，你在将开发模型强加到其中时会遇到很多麻烦，这可能表明它不是一个适合CI的过程。首先。

我们的典型做法是每个项目有两个基本版本：一个针对主干，另一个针对当前版本分支。这样你知道：

正在正确整合的内容（trunk）
无论您的发布目标是什么，如果您现在停止工作，您仍然可以使用正确且有效的（仅仅功能不全）。

Answer 2

以下是我们的工作（受Henrik Kniberg的Version Control for Multiple Agile Teams启发）：

开发在开发分支中完成，功能在“完成”时被推送到主干
trunk是“完成”分支
在发布时，我们标记了主干
当出现缺陷时，我们会从标记
缺陷在发布分支中进行修补
补丁在发布后立即从发布分支合并到主干（将其包含在将来的版本中）

alt text

CI在所有分支（开发分支，主干，发布分支）上运行。

Answer 3

这听起来很痛苦而且过于复杂（从分支/合并的角度来看）。

我会在发布时分支并让开发人员检入主干。任何需要作为热修复程序出去的东西都可以与发布分支合并。

Answer 4

每夜合并到一个“不稳定的邪恶双胞胎”，将所有的虫子分支合并到邪恶的双胞胎中。

或者在每个bug分支上设置每晚构建（听起来像很多夜间构建）。

在我看来，这听起来像集中式源控制解决方案的大量分支。也许你需要在每个工作站上使用分布式版本控制系统和构建服务器，它似乎可以完成同样的事情（每个开发人员的隔离检查和开发人员检查的每日构建）

Answer 5

为什么不在错误修复之前尝试为该版本创建分支，而不是为您的错误修复创建分支，然后将修复应用到主干。

这样，如果您想为客户提供错误修复，请为他们提供主干版本。如果您不想给他们修复错误，可以在修复应用之前为他们提供分支版本。

通过这种方式，您可以让Hudson构建中继线，并且您的每晚构建将包含所有错误修复。

Answer 6

我回答了很多问题，这是IBM推荐使用ClearCase（UCM）的方式，我在现实世界中这样做：

 - Project
    |-  development mainline 
    |-  TAG: version-1.0 
         |- version-1.0-bugfix#123 
         |- version-1.0-bugfixes 
    |-  TAG: version-1.0-sp1 
         |- version-1.0-sp1-bugfix#234 
         |- version-1.0.sp1-bugfixes 
    |-  TAG: version-1.0-sp2

任何没有TAG前缀的东西都是分支。

在Subversion中与多个分支开发持续集成

6 个答案: