3

我们正在寻找有关 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最佳实践指南，其中包含有关此问题的有用信息（请参阅第 5 章）。这些建议与 Craig 的 ST 用法一致（见下文）。请注意，本指南于 2003 年 12 月发布。

4

1 回答 1

4

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

我们在默认视图中进行几乎所有的开发。当我们即将发布产品的一个版本并开始着手开发下一个版本时，只要发生这种情况，我们就会为要发布的版本制作派生视图。派生视图设置为在更改时分支。

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

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

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

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

这与您建议为客户做的事情并不太远，但重要的一点是在默认视图中工作，避免不得不向上或向下批量合并到派生视图中。StarTeam 的视图比较/合并工具并不是那么好。（我们使用的是 2005 年；从那时起它可能有所改进。）

于 2009-02-11T22:31:18.193 回答