发新话题
打印

[讨论] UCM配置管理方案( 此文章被查看:9090次,被回复:73篇!! )

本主题被作者加入到个人文集中
谢谢zhangzhao,一个component只能对应一个folder,但该folder下可以包含n个folder,是这样吧?
另外,关于activity和change set,activity应该就是开发人员的一个操作吧,一个activity会对某些component产生影响,生成不同的版本,可以这样理解吗?
有两个问题:

1 这些所产生的不同的版本就是变更集吗?
2 对于那些没有发生变化的component,CC不做记录吗?

© 本文为 grace_hh 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员

TOP

还有个问题,关于14楼你的回复“...对于comonent和VOB库的关系,可以这样说,一个compoent可以是一个vob库,也可以是一个vob库的某一个目录...”。
也就是说,在UCM中,VOB是没什么实际作用的,我可以直接用Ccomponent,然后存储在PVOB中?

© 本文为 grace_hh 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员

TOP

回复 #22 grace_hh 的帖子

你的理解基本上是正确的,活动(activity)就是记录你当前操作(一般就是checkout),所产生的新的版本,对没有影响到的component是不会变化的,pvob是用于管理component project等对象的一个管理库,变更集产生的代码保存在相应component所对应的vob中,所以操作还是对VOB库中的对象操作的,只是我们不用去关心vob库,我们看到的是对component的操作,实质是写入到vob中去的结果。

© 本文为 zhangzhao 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员

TOP

大家现在可以回头看看我的第一楼的帖子,是否有所明白?
在其中我提到一个无根构件(noroot component),这是一种特殊化的构件(compoent),其实他是一种管理构件的构件,主要负责把多个component的基线组成一个大的基线,至于怎么用这方面的资料太少,因为不用这种构件,也可以用来管理项目,用这种构件可以更方便项目管理,主要体现在推荐基线,如果你的项目有5个compoent,在集成流上开发提交了很多成果以后,可能每个comonent都有新的基线产生,如果你要推荐一条项目基线,要选择每个构件的基线,如果采用无根构件以后,就可以用无根构件来管理这些所有项目有关的构件的基线,只要升级用无根构件的基线作为项目的基线,大家先理解这些,以后有机会在和大家聊这些内容

© 本文为 zhangzhao 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员

TOP

楼主继续啊。

好文章!理解了好多基本概念。

© 本文为 sheng2006 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员

TOP

谢谢大家对本帖的支持,我的目的是希望大家共同交流,把我知道的给大家讲出来,也希望大家能把自己的精彩的一些内容讲出来,大家共同讨论共同提高。希望大家能支持本帖,不要使它沉下!谢谢!有空我会发表一些东西的

© 本文为 zhangzhao 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员

TOP

此帖不错哟
楼主,再问一下,
如想采用UCM模式,那应如何策划,
需从哪些方面考虑部署

© 本文为 selina 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员
我选择,我喜欢

TOP

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

© 本文为 zhangzhao 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员

TOP

to zhangzhao

概念讲的很好,我只有一些不同的意见:
(我习惯用中文描述了,词汇对应:Component-组件;Baseline-基线;PVOB-项目库;VOB-代码库;Project-项目;Stream-流)

一、基线不是基于组件的,而是基于流的;基线和流的关系犹如工件和文件的关系,因为:
1、工件是文件的一个版本,一般用file.no形式描述。
2、工件是活动产生的结果,工件是不可编辑的(因为编辑也是活动,又产生新的工件,原有的工件没有变化)。
所以:
1、基线是流的一个版本,默认用stream+date的形式来描述。
2、基线是一组工件的集合,工件覆盖了流中所有的文件。

上面是不是还是有些糊涂?因为没有讨论组件、流、文件三者之间的关系。
1、组件是一组文件(目录)的集合;
2、流是组件的一个工作分支;
3、流中包含了组件中的所有文件;

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

© 本文为 grantlee 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员

TOP

谢谢你的回信,你的比喻很贴切,但是在理解上稍有偏差。
有关component   baseline   stream  和project之间的关系我们应该综合的去考虑,我只用一个简单的图形说明一下:
                                 

                          vob1                                vob2  
                                     /   |     \                           /        \
   
                               目录1     目录2      目录3          目录4        目录5
                                  |          |              |                 |            |
        PVOB ---->     comp1   comp2    comp3       comp4     comp5
      /           \
project1    project2
                      |        \               
         stream1      stream2
             |                        |   
             | -deliver--->  |

我们以上图为例,如果在项目2(project2)中包含了上面的五个component,假定stream2为集成流,那么我们通过stream2上打基线(full类型的基线),在所有有改动的component上都会打上个新的基线,那么这个基线在compoent的版本树中可以看的出来,所以说打基线是通过流上实现的,但是具体到基线是对component而言的,如果我们在流上说有一个基线最多只能是项目的基线,包含所有的component的一个基线。
先说这么多。我们有空再聊!

[ 本帖最后由 zhangzhao 于 2007-2-7 08:22 编辑 ]

© 本文为 zhangzhao 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员

TOP

发新话题