下面是我们一个项目的发展计划，现在已经开始9.2的开发。同时9.0在维护,9.1也在开发。现在计划使用四个主流：main, 9.0, 9.1,9.2，每个开发人员（也是bug修复员）都建自己的开发流。 以后每增加一个版本，增加一个主流。如图循环。
我们希望达到的效果是这样：
1 版本间（9.0/ 9.1/ 9.2)相对独立，但前版本的bug 修复能应用到后版本中，这样开发人员只需要修改一次源代码，通过提交-变基，所有的版本都能得到bug修复。
2 前一版本没有后一版本增加的功能
3 后一版本包含前一版本开发完成的功能

请大家看看，这样设计有没有什么“后遗症”。谢谢各位！

R9-CMP.gif (25.54 KB)

用的是Base方式还是UCM方式？

个人认为没什么问题啊，就是版本间是否会存在归并冲突是需要考虑的，很理想的项目并行开发配置管理流程啊

谢谢二位回复。
是ucm的。
归并是不能避免的。

是否阶段一和阶段二的Main不是同一个流？

我觉得你的流策略没有问题，有问题的是UCM中Deliver与Rebase存在很多限制，有的限制可以避免，有的是UCM本身的设计限制，正常途径无法逾越。UCM并不像Base那样可以随意灵活。
你的流策略中，有一点我觉得需要考虑，我理解其实图中所画的每一条线都是一个集成流（开发流你没有画出），UCM规定集成流和集成流之间只能Deliver Baseline，不能以活动为单位Deliver。

谢谢二黑的回复，阶段一阶段二是同一个流。

为了验证这个策略，特意做了一个demo. 下图是一个文件按策略产生的版本树。

相关名称说明：
proj-demo_integration:  主集成流，相当于楼主贴中的main
proj-demo-r9_0: 次集成流，相当于楼主贴中的wxc2_9_0
proj-demo-r91: 次集成流，相当于楼主贴中的wxc2_9_1
proj-demo-r92: 次集成流，相当于楼主贴中的wxc2_9_2
cc59u01_xxxxxx:   用户cc59u01在各集成流中的开发流

试验的结论：
1 理论上没有任何问题
2 合并工作很多. 次集成流有修改后，越早集成越好。
3 针对“翎”同学的基线问题。  经证明，是没问题的。
4 针对“二黑”同学的deliver问题。经证明，UCM中集成流与集成流之间是可以通过活动提交的。见图中proj-demo-r9_0流中的版本6提交到proj-demo-r91流中时没有生成基线就提交的。
5 针对上面第四点，不建议这样做。 理由：因为用户cc59u01提交的活动在其父流中不生成基线的话（也就是没有新基线产生，也不会有新推荐基线产生），则此父流的其他用户没法rebase到cc59u01提交的变更。

谢谢大家参与讨论和回复。希望大家继续，共同进步。

vtree.gif (41.31 KB)

[ 本帖最后由 sheng2006 于 2008-4-18 14:04 编辑 ]

sheng2006老兄，你的描述很清楚，讨论起来很方便。

集成流与集成流之间只能Deliver Baseline，这的确是UCM的限定，我也实验了的确存在这种限定，我用的是Native ClearCase，不是CCRC。

你的实验结果可以，我怀疑proj-demo-r9_0和proj-demo-r91并不是真正的集成流，他们是同一个项目里的开发流，而视作“集成流”使用。另外，上面图中对应几个UCM的Project？是否你说的阶段一是一个项目，阶段而是一个项目。

[ 本帖最后由 二黑 于 2008-4-18 16:15 编辑 ]

to 二黑：
都是同一个项目来的。
从集成流创建的子流可能并不是CC中定义的集成流，只是我们按需要把这些子流认为是集成流而也。有空的时候再试试不同项目集成流间的提交问题。
我并没有说明我们使用的是CCRC，你是怎么看出来的？