鉴于大家对这块比较关心，我自己也在学习和整理之中。就把原来的帖子上的内容整理一下，同时更正和添加一些新的信息给大家。谢谢大家支持

ucm学习（1）
学习UCM要从基本的概念理解。其中最主要的几个基本概念是
pVOB库
component
activity
change set
baseline
stream（分为集成流和开发流等）
project

ucm学习1.1-component
先说一下base模式的开发吧，在base模式下，所有的文件在导入到vob库后，所有的文件都是一个独立的对象，打标签是对每个文件都打的，在选取文件版本的时候一般我们通过选取标签来选取版本的，但是对于UCM就不是这样的，ucm提出了一个comonent的概念，目的是把一组文件看成一个对象来管理。所以打基线（相当于base的打标签）是对comonent打的基线。例如在一个项目中，我们把不同模块的代码放在不同的文件夹中，我们可以把每个模块的文件夹划分成一个component。这样以后在管理项目模块基线时，只要维护该comonent的基线就行了。整个项目的基线就是由项目模块所有的comonent的基线构成
既然一个comonent是一组文件，那么它可以把一个普通的vob库构成component，也可以把一个VOB库的某个文件夹看做component，但是必须是vob库的一级目录
具体的构建方法我们可以在后续的内容中说明

ucm学习1.2-activity

本次我主要是想对activity做一个说明，UCM的开发模式在开发人员进行一项工作之前，例如checkout ，要和一个活动（activity）绑定，也就是明确你的目的，当然该活动记录着你这次操作对那些文件产生产生了新的版本，包含在一个活动的所有版本的变化我们称之为变更集（change set）。这样是不是对活动和变更集有了一个认识了？

ucm学习1.3-baseline
base模式下是通过打标签的方式产生一条基线，然后大家根据打的标签（也称基线）继续新的开发，我们所说的基线实际就是一个标签，但是在base下CC库没有基线的概念。只有在UCM下CC才有基线（baseline）的概念，baseline在UCM下的功能和BASE下的标签的功能基本上是一致的，基线有双重的身份（我个人认为），大家可以在下图我画的简略图中发现一条基线 从compoent的角度看它是属于某个comopent的基线，如果从流的角度看，基线是在某个流中产生的基线，我们有一点要记住，基线的产生是通过流创建的，但是我们从隶属的角度上看他是属于某个component的基线。

基线包含什么内容呢？基线包含活动activity,活动（activity）包含着变更集change set ,变更集包含着一个个版本变化。baseline通过这样的方式把一个个的版本变化包含进来。
当开发者在开发流上提交活动到集成流的时候，系统自动会开发者的开发流上打上基线，名字是以deliver开头的基线。先说这么多吧。

ucm学习1.4-stream
UCM提出了一个project和stream的概念，我们在上一帖子中提到component的概念，compoent是一组文件的一个集合，对应到具体的工作环境中就是一个软件项目的一个模块，一个项目可能有多个模块，项目就是把多个和项目有关的compoent组合在一起，就构成了一个项目，但是他还包含了其他另外的东西，例如stream。那么stream是一个什么样的概念呢？我们在具体的开发环境中，可能有多个小组对一个项目进行并行开发，为了不相互干扰，在一个项目的干流上（UCM称之为集成流）可以拉出很多的子流，这些子流根据不同的需要安排不同的人员在上面开发。（如此看来stream和base模式的branch作用一样的），每个子流开发到一定程度以后可以把子流上的开发成果提交到集成流上去，在集成流上集成管理员根据提交的内容进行编译，测试以后在集成流上打上基线（baseline），等所有的测试通过以后可以推荐基线，也就是要发出一个新的版本，这是开发人员只要在自己的开发流上更新自己的基线就可以过渡到新的版本上来了，也不用去编写config spec了。

ucm学习1.5-project

UCM学习1.5
现在大家对理解的怎么样了？这次我们打算聊聊pvob和项目project，pvob和一般的VOB是不太一样的，一般的VOB我们说主要是用来存放源代码的，但是PVOB一般不用来存放数据，是用来管理UCM中的项目信息的，他包含着PROJECT  COMPONENT,Baseline stream，activity等对象的信息。project是基于compoent创建出来的，一个项目project创建后就有一个集成流，类似我们的main分支，但是和分支是不同的两个概念，从集成流上可以产生出子流来，让某个开发者在子流上工作，开发到一定程度可以把它deliver到集成流上去。从而完成一次开发任务。

ucm中的project 是对comopnent的重新规划，可以实现代码的重用，因为项目中的component许多是公用的，根据项目的需要可以在创建项目的时候，选定我们需要的comopnent，也可以在选定的compoent中规定哪些compoent是可写的，哪些Component是只读的。同时我们还可以对project做一些策略，如deliver 策略 项目之间的dilever策略等等
UCM项目的创建可以是根据comopnent的某条基线创建，也可以是根据已有项目的某条基线创建。

[ 本帖最后由 zhangzhao 于 2008-5-9 16:34 编辑 ]

有关component   baseline   stream  和project之间的关系我们应该综合的去考虑，我只用一个简单的图形说明一下：

结构示意图
                                                             vob1                                vob2  
                                                          /    |     \                             /        \
   
                                               目录1     目录2      目录3          目录4        目录5
                                                   |          |              |                 |            |
           PVOB ------------------->comp1   comp2    comp3       comp4     comp5  
       /           \
project1        project2 ----------->|_____|_______|_________|______|_______无根构件NRcomp6
                      /          \               
               stream1        stream2
                |                        |   
                | -deliver-－－>  |


UCM学习1.4-复合基线
我重新整理了一下，本次主要想说一下复合基线，以project2项目为例说明，在项目project2中包含了5个compoent，在开发流stream1上假定有一个开发者对 目录1  目录2 目录4 的内容作了修改。在他deliver到集成流stream2以后，集成员在集成流stream2上打了基线，这时候comp1 comp2 comp4都有新的基线产生，集成员在推荐基线recommand的时候，需要分别从comp1 comp2 comp4中找到新产生的基线组成一条综合的项目基线给开发人员，如果compoent非常多的时候很不方便，很容易出错，因为开发人员可能不止一个。如果我们用一个专有的compoent来管理这些和项目有关的基线，该compoent不是用来存放代码的，只是为辅助项目管理，该compoent的每个基线包含了comp1 到comp5的一个基线，我们在推荐基线的时候只要推荐该compoent的一个基线就可以了，这就是复合基线。复合基线的构成：
首先创建一个无根的component，目前只能通过project expoler 或者是命令行产生，具体命令参考帮助。
再次编辑compoent之间的关系，因为component之间在编辑关系之前是相对独立的，只有编辑了关系以后才能用无根构件来管理其他的compoent的基线。一般我们不建议编辑有根组件的关系（如comp1 comp2等之间的关系）
设置项目project2的基础基线，取消冲突的基线。

[ 本帖最后由 zhangzhao 于 2008-5-9 15:34 编辑 ]

UCM对于项目的规划，和一般的base模式相比更趋向与项目管理，首先要对项目的结构代码有一个全面的认识，最好是和软件架构师沟通一下，了解一下软件的整体结构，可以决定软件代码存放在几个VOB中，然后决定每个目录所属的component，这样对于以后的项目管理会有好处，再者就是流的划分，在创建好Project以后就需要根据自己公司的情况划分流策略了，根据公司开发的模式一般分为面向版本发布的方式开发和面向工件的开发模式，但是很遗憾大多公司都是这两者的结合，所以开发的流策略也就比较复杂，如可以在开发流上拉出测试流，版本发布流，开发流等来满足不同的需求。

UCM项目的CC实施过程:
首先是创建PVOB
创建component（同时也创建了vob库，component是包含在vob中的，形象的说 component<=vob）
创建UCM project（系统自动的创建了集成流）
创建UCM Stream（根据项目的特点，创建不同功能的流，我们称之为开发流）
设置UCM 项目策略（包括deliver rebase 以及项目之间的策略）
设置UCM项目与CQ的集成
开发人员加入UCM project项目开始开发代码，diliver工作成果，到集成流
项目集成人员在集成流上打基线，验证，同时推荐基线
开发者rebase基线，提升自己工作视图的基线，开始继续开发

[ 本帖最后由 zhangzhao 于 2008-5-9 16:26 编辑 ]

学习配置管理还是很重要

总结的很好

支持老大~~

要学的东西还很多啊~·  ：）