version-control - StarTeam View /分支方法

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 一起工作的常识性配置管理解决方案。

谢谢。

更新:我发现了一个 ST best practices guide其中包含有关此问题的有用信息(请参阅第 5 章)。这些建议与 Craig 的 ST 用法一致(见下文)。请注意，本指南于 2003 年 12 月发布。

Answer 1

您可能不想听这个，但没有单一的最佳方法。话虽如此，我将告诉您我们的工作。

我们几乎在默认 View 中进行所有开发。当我们即将发布产品的一个版本时，我们希望开始处理下一个版本，无论何时，我们都会为要发布的版本创建一个派生 View 。派生 View 设置为在更改时分支。

我们在默认 View 中继续开发要发布的版本和下一个版本。当有错误修复或功能需要包含在要发布的版本中时，有两种可能性:

1. 该文件中唯一发生变化的是错误修复或我们希望在要发布的版本和下一个版本中使用的功能。
2. 对文件进行了更改，这些更改旨在包含在下一个版本中，但不会包含在要发布的版本中。

在 (1) 的情况下，我们进入派生 View ，右键单击文件，选择 Advanced->Behavior，然后更改 Configuration，使文件包含我们刚刚所做的更改。在 (2) 的情况下，我们将文件 checkin 默认 View (以便更改将包含在下一个版本中)和派生 View (以便更改将包含在要发布的版本中)，以及，当然，只包括这些更改)，导致它分支。

需要说明的是，我们几乎所有的工作都是在默认 View 中进行的。我们很少需要手动分支或更改派生 View 中文件的配置，因为在我们非常接近发布之前，我们根本不会创建派生 View 。

这与您建议为客户所做的并不太远，但重要的一点是在默认 View 中工作，避免必须向上或向下批量合并到派生 View 中。 StarTeam 的 View 比较/合并工具并不是那么好。 (我们使用的是 2005；此后可能有所改进。)