我们正在将一个相当大的代码库从VSS迁移到带有UCM的Clearcase，并考虑在单个项目中将我们的源代码组织成一个或多个组件。我们应该注意哪些最佳实践和潜在的问题？源代码已经按层（数据层、业务层、GUI层）组织。团队规模较小，开发人员倾向于拥有代码库的某一层，并且我们预计由于并行开发工作而会出现相当数量的分支。
1个回答
7
最危险的问题：
一旦定义了一个组件，就不能将元素移动到该组件之外（可以复制它并在其他地方重新创建它，但会失去其历史记录）。
最有用的最佳实践：
充分理解UCM组件的本质：它关乎连贯性。
一个组件是一组文件，其中：
- 作为单个单位发展，
- 作为整体标记（基线），
- 作为整个分支。
如果您可以在不触及另一组文件的情况下进行演变，则很可能有两个组件。
组件示例：
- 应用程序（或应用程序的自主部分）
- 技术库
- 一组打包的文件（用于发布）
指导您定义组件的唯一文档是应用架构（它将业务和功能规范投射到应用程序上，然后在技术层面上进行规范和实现）。
当所有这些组件都定义好后，您有两种管理它们的方法：
系统方法（UCM项目中每个组件都是可写的）：适用于开始一个项目，但对于遗留项目来说很繁琐：您不需要在每个组件上放置基线，只因为其中3个文件已更改。
组件方法：一个或两个可写组件，其余仅作为不可修改组件存在。这是一种可扩展的方法，允许您定义每个组件开发的一个项目，并具有“固定配置”（即“其他基线”，表示您需要编译可修改组件所需的不可修改组件的固定状态。您可以随时更改此配置，也就是说，您可以重新设置不可修改组件的基础基线）。
您可以定义任意数量的项目和流，从而轻松可视化合并工作流程。
记住：一个 Stream 代表着一项开发任务。不要以资源（如 VonC_stream）命名 Stream，而是以需要在该 Stream 中完成的任务或任务集命名（例如 APP_LCH_R32_Dev：我的应用程序启动器第32个版本的开发）。注意：UCM只是在ClearCase之上的一些元数据：即使将文件组定义为UCM组件，也不会阻止您仍然进行经典的非UCM分支、检出或检入（在非UCM视图中）。
创建过多的细粒度组件或组件之间存在过多依赖关系是否存在危险？
是的，这就是应用程序架构的重要性所在。一旦定义了组件，就不能在这些组件之间移动元素。
关于组件还有另一个需要知道的细节，即它们的布局：
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基于B1的A1开始： B2覆盖了B1。一旦您在A上放置了一个基线（A2），就结束了。您将无法再更改B。由于重叠，将在（不可修改的！）组件B上放置一个A寄生基线（称为A2！？）。
- 始终在无根组件中包含依赖项
ADep1
A1
BDep1
B1
BDep2
B2
在这里，您有无根组件ADep和BDep（无根组件是一种特殊的组件，它聚合其他无根或基于根的组件）您仍然有一个重写，但这次是在无根组件之间。
那仍然会产生寄生基线（在
BDep上，称为A2），但至少您将能够将BDep2重新定位到其他基线中（BDep3，BDep4 ...）
更多关于此问题的信息ClearCase UCM的不连贯和不一致性,以及Rational反驳在这里（紧接着他们的帖子，证明他们的论点至少不是很好的）。
还要阅读如何利用Clearcase的功能
- VonC
1
创建过多的细粒度组件或组件之间存在过多的依赖关系是否存在风险？ - zac
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接