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

我们正在将相当大的代码库从VSS迁移到带有UCM的Clearcase，并且正在考虑将我们的源代码组织到一个项目中的一个或多个组件中。我们应该牢记哪些最佳实践/潜在陷阱？

源被组织为多个层(数据层，业务层，GUI层)。团队很小，开发人员倾向于拥有代码库的特定层，并且由于并行开发工作，我们预计会有大量分支。

最佳答案

最危险的陷阱:

定义组件后，您无法将元素移到该组件之外(可以复制该元素并在其他位置重新创建，但是您将失去其历史记录)

单个最有用的最佳实践:

很好地理解UCM组件的性质:它与相干有关。
组件是一组文件，其中:

演变为单个单元

被整体标记(基线)

是一个整体分支。

如果您可以在不接触另一组文件的情况下进行演化，则可能有两个部分。

组件示例:

应用程序(或应用程序的自治部分)

技术库

打包的文件集(用于发布)

指导您定义组件的一个文档是应用架构(它采用了业务和功能规范，并将它们投影到应用程序上，然后在技术级别进行指定并实现)。

定义所有这些组件后，您可以通过两种方法来管理它们:

系统方法(每个组件都可以在UCM项目中写入):对于启动项目很有用，但是对于旧项目却很麻烦:您无需为每个组件都设置基准，因为三个文件中的一个已更改了三个文件这些组件。

组件方法:一个或两个可写组件，其余仅作为不可修改的组件存在。这是一种可扩展的方法，允许您为每个要开发的组件定义一个项目，并使用“固定配置”(即“其他基准”)来表示编译该组件所需的不可修改组件的固定状态。您可以随时更改此配置，也就是可以随时更改不可修改组件的基础基准。

您可以定义所需的任意多个Projects和Streams，从而可以轻松可视化merge workflow。

请记住:Stream表示开发工作。
不要在资源(例如VonC_stream)之后调用Stream，而是在该流中要执行的一个任务或一组任务之后调用(如APP_LCH_R32_Dev:我的应用启动器第32版的开发)

注意:UCM只是ClearCase之上的一些元数据:即使将一组文件定义为UCM组件，也没有什么可以阻止您仍然进行经典的非UCM分支， checkout 或 checkin (在非UCM View 中)。

是的，这就是应用架构很重要的原因。同样，一旦定义了组件，就无法在这些组件之间移动元素。

有关组件的另一个详细信息是它们的布局:

myVob
  myComponent1
  myComponent2
  myComponent3

根组件始终位于Vob之下的第一级。
您也可以将组件定义为全部Vob，但我不建议这样做(在您的Vob服务器上添加Vob会带来压力。在现有Vob中添加目录不会花费任何费用)

这意味着，如果您将某些技术库定义为组件，则不能这样做:

myLibs
  Apache
    ant
    xalan
    xerces

但必须这样做:

myLibs
  apapche_ant
  apache_xalan
  apache_xerces

最终警告:依赖项(配置管理系统的真实标记)

UCM的主要优点之一(或者我当时以为是2003年)认为是依赖项。
如果A取决于B，并且我将A放在我的项目中，它将自动在同一项目中包括B。

魔法。

但是它坏了。

首先，永远不要做基于根的依赖(基于根的组件是一组文件)。它将在第一个重叠处中断:

A1
B1
B2

在这里，您需要B2来继续构建A，但是A从基于A1的B1开始:B2覆盖了B1。在A(A2)上设置基线后，它就结束了。您将无法再更改B。由于重叠，A寄生虫基线(称为A2!？)将被放置在(不可修改!)组件B上。

始终将您的依赖项包含在无根组件

中

ADep1
A1
BDep1
B1
BDep2
B2

在这里，您具有无根组件ADep和BDep(无根组件是一种特殊的组件，可聚合其他无根或基于根的组件)
您仍然有覆盖，但是这次是在无根组件之间。
那仍然会成为寄生虫基线(在BDep上，称为A2)，但是至少您以后可以将BDep2改成其他基线(BDep3，BDep4 ...)

关于这个Incoherences and Inconsistencies of ClearCase UCM的更多信息，以及Rational counter-arguments here(在他们的帖子发表之后，至少可以证明他们的论点不是很好)。

另请阅读How to Leverage Clearcase’s features

关于ClearCase UCM-使用组件的最佳实践，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1764329/