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

Question

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

源被组织成层(数据层,业务层,GUI层).团队相当小,开发人员倾向于拥有代码库的某一层,并且由于并行开发工作,我们预计会有相当多的分支.

Answer 1

单一最危险的陷阱:

定义组件后,您无法将元素移动到此组件之外(您可以复制它并在其他地方重新创建它,但您将丢失其历史记录)

单个最有用的最佳实践:

很好地理解UCM组件的本质:它是关于一致性的.
组件是一组文件,其中:

如果您可以在不触及另一组文件的情况下进行演变,则可能有两个组件.

组件示例:

应该指导您定义组件的一个文档是Applicative Architecture(它采用业务和功能规范并将它们投影到应用程序上,然后在技术层面指定并实现).

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

系统方法(每个组件在UCM项目中都是可写的):对于启动项目很有用,但对于遗留项目很麻烦:您不需要在每个组件上放置基线,因为3个文件在其中一个组件中已更改.
组件方法:一个或两个可写组件,其余只作为不可修改的组件.这是一种可扩展的方法,允许您定义要开发的每个组件的一个项目,具有"固定配置"(即"其他基线",表示您需要具有的不可修改组件的固定状态,以便编译您可以随时更改此配置,也就是说,您可以随时根据需要更改不可修改组件的基础基线.

您可以定义所需的项目和流,从而可以轻松地显示合并工作流.

请记住:Stream代表开发工作.
不要叫流的资源(如后VonC_stream),但任务后,或(如在设定的任务在流做的APP_LCH_R32_Dev:开发我的应用程序启动的第32版本)

注意:UCM只是ClearCase之上的一些元数据:即使一组文件被定义为UCM组件,也没有什么能阻止你仍然制作经典的非UCM分支,签出或签到(在非UCM视图中).

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

是的,这就是Applicative Architecture很重要的原因.同样,一旦定义了组件,就无法在这些组件之间移动元素.

了解组件的另一个细节是它们的布局:

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...)

更多关于ClearCase UCM的这种不一致和不一致的问题,在这里有理性的反驳(之后就是他们的帖子,证明他们的论点至少可以说不是很好).