我在想，当开发人员获得了一个task任务后，他并不知道在哪个branch，哪个label上开发，是不是有scm告诉他相应的config spec的内容。他才知道去co指定的label，branch进行开发？？

首先在SYNERGY里很少会谈到Branch这个概念，虽然SYNERGY完全支持Branch。SYNERGY里谈的最多的就是Task。Task代表了业务的逻辑变更。因此，开发人员应该最本质的要知道在我的开发项目里，我把那些Bug修改了，我增加了那些Enhancements。因此在SYNERGY能告诉开发人员，你当前项目的config spec里包含了那些Task。而至于这些task在那个分支上是无关重要的。如果确实想知道哪个Task属于主干项目还是分支项目，那么Task里的Release属性用来表明该Task是在那里被实现的。

TASK的属性里包括是针对哪个产品的哪个Release

Release是用来标识项目路线图的。它就是一个标签来贴在SYNERGY的对象上的，包括Task，源代码文件，项目，目录等。这样，当Task有了Release标签之后，就可以知道该Task是作用于那个阶段的项目了。

既然是标签，Release由Component Name+ Release Number组成。例如 Cube/1.0,Cube/1.0sp1,Cube/2.0 所以从Release的Compnent Name可以知道Task是针对那个产品。

从另外一个角度来看Release的话，Release就是里程碑点（milestone）

哦，Release标签也就是作为下一开发阶段的基础！

说到分支还是ｃｌｅａｒｃａｓｅ中表现的比较突出，在这里好像基本上用不上。这里我感觉从基线＋任务＝CC中的分支的概念。但是CC中的分支比较强调，一但分支太多给版本的形成的压力很大，因为存在各个分支上文件的归并，回归等等问题。可以近似的理解这里的分支跟CC中的很小的分支（CC中分支通常是一个连续的过程，但这里基本上ｔａｓｋ完成之后可以任务该分支结束了）　。
个人见解，因为之前我也是用CC的，对ｓｙｎｅｒｇｙ也是刚刚接触，理解不深，如果错了，还请各位大虾 而且经常会将CC　中的一些概念拿来与ｓｙｓｎｅｒｇｙ中的感念对比。这样也不太好。

从昨天telelogic的人说的，我理解为：
synergy:开发人员的view的取得是通过baseline+task；通过设置task的属性，来获得是哪个项目，哪个分支
clearcase:开发人员的view的取得是通过config spec设置的规则来获得哪个项目，哪个分支，

楼上的观点没有错，其实通过ｃｏｎｆｉｇ　ｓｐｅｃ来配置有些问题，向之前在用CC的时候我们要求有一个分支要求必须与生产一致。开发不能在此分支上做普通的项目开发，这时候需要每次根据新的发布的版本基线上拉出该分支，可能有的文件是从基线A出来的，有的文件是从下一个基线B出来的，而所有改动的文件都需要体现在这个分支上。并且我们要求该分支能够持续使用。这时候ｃｏｎｆｉｇ写起来有些麻烦，而且每次都得上完新的版本之后需要根据新的基线改写ｃｏｎｆｉｇ。

对，当我们的开发开始一个新bug的修改后，他需要到指定地点去获得新的config spec

楼上的对CC非常熟悉了。在这里我想再强调一点的是。SYNERGY几乎不强调分支这个概念，甚至在SYNERGY里技术资料里，也只有在讲到文件版本树的时候，才会有分支的。SYNERGY所强调的是，项目变更数据的获取是按照业务变更的原因获取的，在获取的时候SYNERGY不需要开发人员知道某个变更数据在那个项目里被实现，它需要开发人员按照一般找问题的方式（什么问题，被谁解决，在那个项目版本里，什么时候解决的，该Bug是否已经被解决等属性构成的查询）来变更数据获取到。然后，用获取到的变更数据更新自己的项目。
因此SYNERGY更是以自然工作方式来实现组织开发过程。