是的，你说的是复合基线的问题，我说的只是考虑了简单基线。复合基线的概念要更加复杂一些，所以在这里就不讨论了。

grantlee：对CC的概念理解非常透彻，复写纸的比喻非常恰当。

我觉得你不妨就把复合基线的概念给大家解释一下，看看这次是不是有更精辟的解释。

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

上面的帖子位置有点乱，我重新整理了一下，本次主要想说一下复合基线，以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的基础基线，取消冲突的基线。
大家理解一下！！

我们有一个这样的项目，我打算只创建一个VOB，然后设置5个左右的component

但是我们实际会出现这种状况，分不同的客户，比如深圳、北京、东莞其实都是5个component，很大情况是某一个或几个component的代码要分支，对深圳和对北京是不同的代码，某一个文件的修改可能是共同拥有的，不是共同的文件的修改就只有一直分支下去，肯定就不可能deliver到集成流，然后在集成流上面打基线，实际情况应该只能直接把基线打在对应的开发流上面。

然后我想着发布的时候创建Base模式的视图，把对应的基线拿出来集成测试，如果没有问题就发布，有问题就让开发人员在UCM上面修改，改完了，再打集线，然后继续在Base下集成，测试、发布。

这样的情况，各位觉得怎么样设置UCM方案会要好一些？

[ 本帖最后由 晓筱 于 2007-2-2 17:32 编辑 ]

讨论的这么热烈

我来凑热闹：
base模式下，一个元素的版本有好多，1，2，3.。。6， 为了对好多个这样的元素进行标识，我们用label
UCM模式下，baseline的针对与component来说的，我们将一个component看做一个整体，其实这里的baseline可以看做上面base方式下的1,3,4等数字，在当个component的环境下当然够用。在多个componet的环境下呢，如何标识多个component的基线状态呢，就可以用-nroot创建没有任何元素的component了，这就是无根component了，这个componet里面仅用来存储composite baselines--复合基线，复合基线可以看做是上一段提到的base模式下的label，仅用来标识多个component的基线状态。常用来标识整个project的状态。
base搞清楚了，其实ucm不过是些抽象和提升而已，上面的component可以看做base模式下的当个元素。 baseline当作1，2，3 ，复合基线当作label。 stream不过是分支，推荐基线不过是个attribute

在某个开发流上apply label,然后import label as baseline for a component,那么获取相应版本就不需要base 视图来获取了，省去了编辑config spec的麻烦！
你认为呢？呵呵;
如果组装更大的component，那么引进无根组件，用无根组件的基线来获取相应版本.

首先需要分清UCM的所有概念有面向架构和面向开发组织两个方面。架构指component代表的客观事实，这与企业架构师相关，当然也可以根据具体设计和应用特点进行component封装；开发组织指项目、流的构造。在原帖问题中，最好使用复合基线（项目A、B、C均可采用复合基线）来进行跟踪，这样最上层的复合基线可以轻易发现下面哪个项目发生变化，进而下层复合基线的进一步比较可以发现哪个组件发生变化。

谢谢你发表自己的看法，大家对复合基线的理解可以参考我的图形和35楼的解说，可能会对UCM的复合基线有一个比较好的理解。希望大家能发表一下Project与project之间的操作，以及使用的情况，这也是我们进一步要讨论的内容。

是不是还没有说清楚？越来越糊涂了？^_^
将组件想象成一张纸，目录树和文件名就可以写在上面了，这个就是组件和文件（目录）的关系；
将这张纸复印一下，所有的目录和文件也有了，复印出来的流了；
反过来说原来的也是一张纸了，那么也是流了？
不错，原来的那张纸也是流，是主流（Main），一般都不用的。最后归结：组件原来是一沓复印出来的纸，只是每张纸上都可以再手工修改，最奇妙的是手工修改过的还可以复印到其他指定的纸上！哈哈，原来是复写纸。

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
你说的最初的那张纸，已经不单单是组件了，而是项目的集成流了，也就是你说的主流

首先创建一个无根的component，目前只能通过project expoler 或者是命令行产生，具体命令参考帮助。
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

能否具体说一下通过project explor如何创建无根component，是否就是在component右键选择new-component without a VOB？