使用Subversion和促销模型

Question

目前我们使用Subversion进行源代码控制,但我们发布的所有合并工作都是手动完成的.我们每年发布几次,因此为每个版本创建一个分支.来自早期分支的所有工作必须使其成为后来的分支.后期分支机构的工作不得进入较早的分支机构(这在我们的合同中).我相信这被称为促销模式.

我认为下面的图表最能说明我们所需的工作流程,每当新版本开始工作时都会创建分支,并且从早期分支流向后来的分支.

|
1
|
|\
| \ 
| 2 
3 | 
|\| 
4 |
| |\
5 | \
| 6 |
| | 7
|\|\|
| |\|
8 9 |\
| | | \
|\| | 10
x |\| |
  | |\|
  | | | 

a b c d

• 尽管没有有意义的主干,这个模型是否可以顺利使用Subversion？
• 自动合并跟踪是否适用于从早期分支到后期分支的更新？
• 是否可以关闭/删除/忽略分支(在此示例中发布分支'a')而无需重新集成？
• 是否可以从每个发布分支创建功能分支,并合并这些跟踪工作？(他们将遵循推荐的创建/合并/重新整合模型.)

编辑 - 添加更多信息.

传统的不稳定中继线模型可能不适合的原因如下图所示.每个版本的功能不一定按发布顺序完成(某些客户可能很难确认要求).我们希望尽快将更改从早期分支传播到后一分支.

    a
    |
    1
    |
   b|\ a
    | \ 
    |  2
    3  |
    |  |
    4  |
  b/|c |
  / 5  |
 |  |  6
 7  |  |
 b  c  a

在这种情况下,我们希望在分支b中使用特征2(在分支a中完成),但由于这是子到父合并,因此Subversion不支持,因此必须手动完成.类似地,特征6必须手动合并两次.与自动跟踪的合并相比,我预计这是一个相对缓慢且容易出错的过程.

Answer 1

如果我了解您的情况，您的要求中没有任何内容会使事情变得像您看起来那样复杂。您还过于强调自动合并与手动合并的优点（稍后会详细介绍）。CVS 分支将是另一回事，但与 SVN 处理“分支”的方式不同（即，它没有）。

您可以拥有一条主要（不稳定或稳定）开发线，并为每个客户或版本（或两者）创建分支。当功能经过验证时，它们要么合并回主线，以便后续分支可以包含这些更改，要么您始终从父分支单向合并。没有什么需要您关闭分支，并且合并的自动化程度不亚于支持您的第一个（混乱的）图表（假设您有多个并发开发线）。

仅向前合并的要求听起来就像您只需要合并主线中的子集修订版、给定分支修订版之后的修订版。通过这种方式进行合并，您可以根据需要将任意分支的更改合并回主线（因为它们已与您的客户确认），并且可以放心地向前应用，因为只有经过验证的更改才会被应用。您可以设置自动合并来跟踪该副本修订（请参阅 --stop-on-copy 和基于范围的合并）。然后，发布分支会选取从给定点开始发生的一组已确认的更改。

SVN 不“跟踪合并”，就像它不支持分支一样（它不支持，它们只是轻量级副本）。您告诉它（或 svnmerge 告诉它）要合并的范围，它会应用这些更改。无论如何，您都可以获得合同要求支持的效果。

回答您提出的问题：

• 我认为你提出的模型不是很有效。相反，它增加了功能跟踪混乱的可能性，因为您可能必须扫描分支以查找更改并多次向前合并。而且，这无疑会让熟悉 SVN 和更传统的 SVN 组织结构的开发人员感到困惑。

• 当然。这也应该完全独立于您选择的结构。无论如何，您将需要/想要跟踪您的修订点（更糟糕的是可能通过一些简单的脚本编写）。

• 当然。分支机构在服务器端的 SVN 中实际上没有任何成本。如果您进行整个根结帐，客户端就会产生成本，但这通常是一件愚蠢的事情。同样，忽略/删除分支也没有问题。这只是对全局修订层次结构的另一个更改，就像任何其他复制/删除/重命名/等一样。

• 无论采用何种“分支”组织结构，这都应该有效。听起来好像对 SVN 中的“分支”的含义有一点误解。无论如何，您应该能够设置您想要的内容并相对轻松地执行“手动”合并，然后在几次客户更新后设置自动合并，以便您可以更好地理解合并步骤。

干杯!