StarTeam 视图/分支方法答案

【问题标题】：StarTeam view/branching approachStarTeam 视图/分支方法
【发布时间】：2025-12-22 18:25:06
【问题描述】：

我们正在寻找有关 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 月发布。

【问题讨论】：

我不知道您的问题，但 StarTeam 最佳实践指南有更新。它的日期为“2008 年 5 月”，由“Randy Guck”撰写。抱歉，我没有链接，只有其中的一些打印页面。

标签： version-control starteam

【解决方案1】：

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

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

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

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

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

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

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

【讨论】：

谢谢。所以你是说新版本的派生视图不会自动继承对默认视图所做的更改？如果您希望默认视图更改继承到您的派生视图，您可以在派生视图中逐个文件更改设置，以便这些单独的文件继承。对吗？
假设您正在开发一项将在 1 年内上线的大项目。还在研究 5 个将在明年上线的小项目。您不希望大项目代码与小项目一起使用，但希望小项目代码与大项目一起使用。如何处理？一开始可以做 5 个衍生 v，但似乎很痛苦。
我通常处理这个问题的方式是尽可能将大项目放在完全独立的代码模块中。我可能必须重构其他模块才能完成这项工作，但我小心翼翼地以非破坏性的方式进行。然后在准备好之前，我不会向最终用户公开新功能。
我明白了。使用您的方法，如果您更改派生 v 中文件上的配置以允许继承，因此在派生 v 中会获取默认 v 的更改，那么您是否可以再次更改该配置，所以这是唯一的更改文件被继承，未来的变化不会被继承？
是的，这行得通。只需将日期设置为您想要的任何版本。