Question

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

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

Answer 1

最危险的陷阱：

一旦定义了一个组件，你就无法将一个元素移到这个组件之外（你可以复制它并在其他地方重新创建它，但你会丢失它的历史）

最有用的最佳做法：

很好地理解UCM组件的本质：它是关于一致性。
组件是一组文件：

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

组件示例：

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

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

系统方法（每个组件都可以在UCM项目中写入）：对于启动项目很有用，但对于遗留项目很麻烦：您不需要在每个项目上都设置基线组件只是因为其中一个组件中有3个文件发生了变化。
组件方法：一个或两个可写组件，其余只作为不可修改的组件。这是一种可扩展的方法，允许您定义要开发的每个组件的一个项目，具有“固定配置”（即“其他基线”，表示您需要具有的不可修改组件的固定状态，以便编译你可以随时改变这种配置，即你可以随时改变不可修改组件的基础基线。

您可以定义所需的项目和流，让您轻松可视化merge workflow。

请记住：Stream代表开发工作 不要在资源（如VonC_stream）之后调用Stream，而是在该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覆盖{{} 1}}。只要您在B1（A）上设置基线，它就结束了。您将无法再更改B.由于重叠，A2寄生虫基线（称为A！？）将被放置在（不可修改的！）组件A2上。

    ADep1
      A1
      BDep1
        B1
    BDep2
        B2

这里有无根组件B和ADep（无根组件是聚合其他无根或基于组件的组件的特殊组件）
你仍然有一个覆盖，但这次是在无根组件之间这仍然会产生寄生虫基线（BDep，称为BDep），但至少您可以稍后将A2重新定位到其他基线（BDep2，{{ 1}} ...）

关于这个Incoherences and Inconsistencies of ClearCase UCM的更多内容，Rational counter-arguments here（之后就是他们的帖子，证明他们的论点至少可以说不是很好）。