StarTeam视图/分支方法

Question

我们正在寻找一些关于我们的StarTeam配置的建议。我们有一个由两个主要客户使用的项目。我们共享一个共同的代码库，但我们希望能够一次为一个客户进行开发。有人知道使用StarTeam是做这件事的最佳方法吗？

我想你会想做这样的事：

->Main branch (1.0)
-->Cust #1 Release (1.1)
-->Cust #2 Release (1.2)

随着1.1的完成，您将把这段代码合并到2.0中。1.2也一样。然后创建2.1或2.2。

这有道理吗？只需要寻找一些常见的配置管理解决方案，这些解决方案将适用于我们的场景，并且可以轻松地与StarTeam一起工作。

谢谢。

Update：我找到了一个ST 最佳做法指南，其中包含有关这个问题的有用信息(参见第5章)。这些建议与Craig的ST用法一致(见下文)。请注意，本指南已于2003年12月出版。

Answer 1

你可能不想听这个，但是没有一个最好的方法。话虽如此，我会告诉你我们要做什么。

几乎所有的开发都是在默认视图中进行的。当我们接近发布一个产品的一个版本，我们想要开始下一个版本时，无论何时，我们都会为将要发布的版本创建一个派生视图。派生视图设置为“更改时的分支”。

我们继续开发要发布的版本和默认视图中的下一个版本。当需要在要发布的版本中包含bug修复或特性时，有两种可能：

1. 在该文件中唯一改变的是bug修复或特性，我们希望在版本中发布和下一个版本。
2. 已对文件进行了更改，这些更改将包含在下一个版本中，但不包含在要发布的版本中。

在(1)的情况下，我们进入派生视图，右键单击该文件，选择Advanced->Behavior，并更改配置，使该文件包含我们刚才所做的更改。在(2)的情况下，我们将文件签入默认视图(以便更改将包含在下一个版本中)和派生视图中(以便将更改包含在要发布的版本中，当然只包括这些更改)，从而导致其分支。

说得很清楚，在默认视图中几乎完成了我们所有的工作。我们很少需要手动分支或更改派生视图中的文件配置，因为在非常接近发布之前，我们根本不创建派生视图。

这与您建议为客户做的事情相差不远，但重要的是要在默认视图中工作，并避免批量合并到派生视图中。StarTeam的观点比较/合并工具并没有那么好。(我们使用的是2005年；自那以后，情况可能有所改善。)