ClearCase UCM-使用组件的最佳实践

我们正在将一个相当大的代码库从VSS迁移到Clearcase w\UCM，并正在考虑将源代码组织到单个项目中的一个或多个组件中。我们应该记住哪些最佳做法/潜在陷阱

---

源代码被组织为多个层（数据层、业务层、GUI层）。团队规模相当小，开发人员倾向于拥有代码库的某一层，我们预计由于并行开发工作会有相当多的分支

单个最危险的陷阱：

一旦定义了组件，就不能将元素移出该组件（可以将其复制并在其他位置重新创建，但会丢失其历史记录）

最有用的最佳实践：

充分理解UCM组件的本质：它是关于一致性的
组件是一组文件，其中：

• 作为一个整体发展
• 作为一个整体进行标记（基线化）
• 作为一个整体是分支的

如果您可以在不接触另一组文件的情况下进行演化，那么很可能您有两个组件

组件示例：

• 应用程序（或应用程序的自治部分）
• 技术图书馆
• 打包的文件集（用于发布）

应该指导您定义组件的一个文档是应用程序体系结构（它接受业务和功能规范，并将其投影到应用程序上，然后在技术级别指定并实施这些应用程序）

定义所有这些组件后，您有两种方法来管理它们：

• 系统方法（每个组件在UCM项目中都是可写的）：对于启动项目很有用，但对于遗留项目来说很麻烦：您不需要为每个组件设置基线，因为其中一个组件中有3个文件已更改

• 组件方法：一个或两个可写组件，其余仅作为不可修改组件存在。这是一种可扩展的方法，允许您使用“固定配置”（即“其他基线”）为每个要开发的组件定义一个项目表示编译所需的不可修改组件的固定状态。您可以在任何时候更改该配置，也就是说，您可以根据需要重新调整不可修改组件的基础基线。

您可以定义所需的任意多个项目和流，使您能够轻松地可视化项目

请记住：流表示开发工作
不要在资源（如

VonC\u Stream

）之后调用流，而是在该流中要执行的任务或任务集之后调用流（如

APP\u LCH\u R32\u Dev

：为第32版my APP Launcher开发）

---

注意：UCM只是ClearCase之上的一些元数据：即使一组文件被定义为UCM组件，也没有什么可以阻止您继续进行经典的非UCM分支、签出或签入（在非UCM视图中）

---

---

创建太多细粒度组件或组件之间存在太多依赖关系是否存在危险

是的，这就是为什么应用架构很重要。同样，一旦定义了组件，就不能在这些组件之间移动元素

有关组件的另一个详细信息是其布局：

myVob
  myComponent1
  myComponent2
  myComponent3

根组件始终位于Vob之下的第一级。
您也可以将组件定义为all Vob，但我不建议这样做（添加Vob会给您的Vob服务器带来压力。在现有Vob中添加目录不会产生任何成本）

这意味着，如果将某些技术库定义为组件，则不能作为：

myLibs
  Apache
    ant
    xalan
    xerces

但必须做到：

myLibs
  apapche_ant
  apache_xalan
  apache_xerces

---

最后警告：依赖关系（配置管理系统的真实标志）

UCM的一个主要优势（或者我当时认为是2003年）是依赖性。
如果

A

依赖于

B

，并且我将

A

放在我的项目中，它将自动在同一项目中包含

B

魔法

但是它坏了

• 首先，永远不要做基于根的依赖（基于根的组件是一组文件）。它将在第一次重叠时断裂：

这里有无根组件

ADep

和

BDep

（无根组件是聚合其他无根或基于根的组件的特殊组件）
您仍然有一个覆盖，但这次是在无根组件之间进行的。
这仍然会形成一个寄生虫基线（在

BDep

，称为

A2

），但至少你以后能够将

BDep2

重设为其他基线（

BDep3

，

BDep4

）

关于这一点，有更多的证据（在那之后，他们的文章证明他们的论点至少不是很好）

---

另请阅读

创建太多细粒度组件或组件之间存在太多依赖关系是否存在危险？刚刚完成了我的回答以回应您的评论。刚刚添加了关于组件依赖关系的寄生虫基线警告。 A1 B1 B2 ADep1 A1 BDep1 B1 BDep2 B2