我们正在寻找有关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月发布。
最佳答案
您可能不希望听到此消息，但是没有唯一的最佳方法。话虽如此，我会告诉你我们所做的。
我们几乎在默认视图中进行所有开发。当我们足够接近要发布产品的一个版本而要开始在下一个版本上工作时，只要碰巧出现，我们就会为要发布的版本创建派生视图。派生视图设置为在更改时分支。
我们将继续开发要发布的版本和默认视图中的下一个版本。当要发布的版本中需要包含错误修复或功能时，有两种可能性：
该文件中唯一发生变化的是我们要发布的版本和下一版本中的错误修复或功能。
对文件进行了更改，这些更改旨在包含在下一个版本中，但没有包含在要发布的版本中。
对于（1），我们进入派生视图，右键单击文件，选择Advanced-> Behavior，然后更改Configuration，以使文件包含我们刚刚进行的更改。对于（2），我们将文件检入默认视图（以便将更改包含在下一个版本中）和派生视图（以便将更改包含在要发布的版本中），以及，当然，仅包括这些更改），导致其分支。
需要明确的是，我们几乎在默认视图中完成了所有工作。我们很少需要手动分支或更改派生视图中文件的配置，因为在非常接近发布之前，我们根本不会创建派生视图。
这与您为客户提出的建议相差不远，但是重要的一点是要在默认视图中工作，并且避免必须向上或向下批量合并到派生视图中。 StarTeam的视图比较/合并工具并不是那么好。 （我们使用的是2005；此后可能有所改善。）