ClearCase完全攻略（八）UCM实例：一些概念补充分析

终于搞定了一个UCM实例的配置

 

中途有个插曲，我操作过程中涉及到了两台服务器，然后我分别用系统本身的管理员账户administrator进行操作，

最后两边创建的东西不能够互通。最后才知道CC这玩意，对账户权限要求有点变态。最好使用域账户。

 

 

 

 先不在权限上面花过多时间。只要知道，以后用域账户就行了。

 

 其实刚才的例子中一共有几个问题：

1：CCCQ集成的策略，选项蛮多的，没有明白

2：UCM的stream里面的stream，child stream什么的，流嵌套流，平行级别流。没太明白

update：2010-07-08：

一个流是一个长期存在的Rational ClearCase对象。

一个用户确定哪些元素版本将出现在视图中的UCM对象（类似Base里面的config spec），以提供你去查看修改或者构建。
维护一组基线和活动的列表。

UCM中使用基线和活动来描述一个流的构造。（可不可以简单理解为流就是基线和活动打包而成的东西？）

当您创建一个流，初始化的构造和基线相同（也就是说，一个组件包含了每个元素的单个版本）。

当您修改流的构造，您分配的修改一个或多个活动。因此，一个流的构造是一个给定的基线及一个或多个活动。

所以rebase，deliver其实就是双方基线的交互，（默认是父子之间，不过平行流也可以的）

rebase的时候，A-B，A从B得到一个推荐基线，获取B的最新内容

deliver的时候，A-B，A把自己的基线给B，把A的最新内容给B

 

一个项目包括两种流：集成流，开发流

平行流有公共的上级流，管理上可以当分支来看，平行开发和管理代码，父子流，一般是把项目的稳定的版本放到父流上。如果做deliver默认是从子流到父流，rebase是相反的。平行流之间也可以进行代码沟通，相互之间也能deliver和rebase.父子的在管理上分得更清晰一些,不过父子有一个隐含基线的限制，造成不好用。所以两者互相有好坏。当然每个公司的开发流程不一样，这个还是要具体情况具体分析。

 

3：基线的种类和级别，没太明白

4：component和VOB关系，没太明白，

update：2010-07-08：component是逻辑的，VOB是物理的 。vob真实的存在，但是component是把vob划分成一个集合，或者多个集合。。。component是个物理资源的再整合，只能映射VOB本身或者VOB的第一级目录。

 

5：CC中的权限，没太明白

 

 其他一些收集到的文章，文章1，