以下文章，仅是我个人使用的一些感受和总结，观点只代表本人。

Synergy/CM用了已经两年多的时间了，两年多的时间里，从陌生到熟悉，一些感悟和总结，把它贴出来，也算是对自己这两年的一个总结。
其实相对于Clear Case这是一个相对简单许多的配置管理工具。绝大部分的开发人员对这套工具的抱怨，我想是来自于它对传统观念的挑战，并且面对众多的实际使用中遇到的问题，拿不出一个实际的解决方案，只是停留在理论表面上。很多细节的问题，需要配置管理人员在实际工作过程中，不断的总结方法，提供给开发人员。
在印度和美国，Synergy/CM的受众比中国大陆要多很多。为什么？其他原因不做深究，但是有个比较客观的原因就是，项目不同。国外的项目大多不似我们所面对的这样复杂，他们只是单一的，即使是有分支，也是很干脆的反支。而我们所面对的项目呢，有分有合，错综复杂，还要求权限控制到位，还要满足来自各方各面的要求，因为在使用过程中，会越来越发现，这个工具有技术顾问口中的工具，实在是差别太大。下面的三大部分，我来客观的介绍一下我的感受。
第一部分，是如何理解它的一些概念。
先说task：
使用Synergy，首先要理解它那些区别于传统的概念。实际上，很多开发人员并不理解基于task在实际上，到底是个什么概念，故而在使用中，就当作一个“容器”，把自己今天要干的事，都给它塞进去，然后一次性完成。这样的做法当时是痛快，但是日后查询，修改就很麻烦了。为此，我所负责的项目都要求，由CR到TASK，再到CR，这样形成一个闭环。一个task，就是为了解决这个CR，不带CR的task，我不会拿去发布。强制开发人员理解task这个概念。同时，开发过程中一定要注意current task，选择正确的task为current task，current task不能为空，否则会遇到右键某些选项没有的情况。

再说baseline and release
另外一个让开发人员，甚至是初接触这个工具的配置工程师感到迷惑的是release和baseline的区别，乍一看，有什么区别，干嘛要分开呢。其实，它这个release和我们通常的release是不一样的，所以大家才会觉得理解上有一定困难。这个release就像定个调一样，后面的开发都向着这个方向前进，直到方向转变，到下一个release。而baseline，则是把我们动态的研发，在某一个需要记忆的点，凝结一下，做个标记，是个大大或小小的阶段性总结。
接着说说，instance
Synergy区别于其他配置管理工具的还有一个新东西，叫instance，众所周知Synergy确定一个唯一的object的方法是，name version type and instance，其中instance是非常重要的。很多file看上去一模一样，可是一看instance，你就会发现这是两个不一样的东西了。为了方便起见，建议大家在工作面板，把instance项点出来，省得去看properties了。另外，经常我们会看到，其实一些一样的文件，instance都不同，那是因为开发人员在添加文件时，没有去先检索一下，服务器上是否已经有现成的了，就去添加了。这个习惯还是要培养的。

接下来是对于开发人员：
对于开发人员来说，要开始工作，首先要创建自己的工作空间，创建空间的方法就是copy project，这个就不多说了。只是插一句，如果开发人员只是想取某一个版本看看，并不是要在服务器上生成版本，那就不要用copy project，而要用copy to file system，而copy to file system的时候，要注意不能有空格，否则会出错的。

我推荐给开发人员的使用流程为：
首先update，先把已经发布的项目组其他成员的工作成果，拿到本地。
创建task，创建属于自己的task，注意for release属性。
Check out，你会发现check out的文件会出现你的current task下
再次update，看是否服务器上已经有新的修改
如果有，那要看是否要合并一下，然后再次编译
最后在一次性 complete task，task所关联的文件会一次性complete。
对于已经完成的task，可以通过fix的方式进行修改，或通过exclude的方式进行隔离。当然以上方法有变通的，看开发人员爱好，也可以在workarea上修改，然后使用sync的方式进行上传，呵呵，其实我喜欢用sync，方便。

Synergy也提供了与其他一些小工具的融合，假如你不喜欢系统自带的工具的话。例如，如果你不喜欢自带的比较工具，可以去修改ccm.properties文件，做如下修改：
//windows.tool.compare.ascii = %ccm_compare
windows.tool.compare.ascii=d\:\\progra~1\\beyond~1\\bc2 "%file1" "%file2"
这只是举个例子，其他的类似了。

[ 本帖最后由 jane_zhang 于 2007-12-3 16:45 编辑 ]

删除。
开发人员可以删除一切working状态的project task file等等，但是要注意，删除task的时候，不要留下一些孤立的文件。因为Synergy/CM通过task组织工作，这些可怜的孤立文件，找不到组织了，只能搁置在服务器上，占空间浪费。如果误操作了倒也不怕，在找个task，把它们加进来就好了。

编译。
我前面有过一个操作技巧，就是属性中，选中时间那项。默认情况下Copy project的时候,获得的文件的修改时间是 文件在synergy中保存的修改时间. 为了使得文件的修改时间为copy project动作的时间或者update或者use version 动作的时间, 按照如图设置进行. 这样可以避免编译出错(GNU make会去找是否有 相对于最新一次编译的结果(*.obj) 的依赖文件(*.c, *.cpp)有修改, 有的话才会重新编译).
我不知道怎么把图贴上来，真是郁闷！太笨了。

开发人员在工作过程中，要养成良好的习惯，开始工作时要update，完成工作时要sync，工作过程中要尽量使用update，而非use version，当然如果已经深刻理解了其中含义，也可自己调节。

最关键的是对使用Synergy的配置管理工程师了，我觉得我们对这个工具的更深入理解，能够一定程度上帮助manager和项目团队。

对于SCM，我们要很熟悉Classic界面。我们运行命令，很多操作都在这里了。这里很重要的就是需要在另外一个classic界面来配置reconfigure template，开发人员要得到符合什么规则的内容，就需要在这里配置，当然前提是已经有了baseline，也就是有了基点，有了可供copy的baseline project。我们可以在这个配置空间里，给开发人员指定好用哪个baseline，用哪些task。这样开发人员才能理论上得到正确的东西。在这里一定要注意，对baseline的指定，要不就一条，用最新的，要每次创建完baseline都指定，那可要记住了，这直接影响到开发人员得到的内容。极有可能，有一天，你桌上电话此起彼伏的，因为大家copy project或者update之后，发现，得到的都是红色的！，要犯众怒的哦！

而讲到这里，我就不能不提Synergy/CM的另外一个特色，就是Folder的概念。所谓Folder，就从字面上理解好了，就是一个folder，用来放东西的，呵呵，用来放符合一定条件的一系列task集合的。很好的利用这些folder，对于我们开发工作还是很有帮助的。以下内容是我从印度老师那里学来的，一直在实际中应用，受益匪浅阿。没有征得他同意，不知道可不可以发出来。其精髓就是通过folder来组织task，按folder的类型来组织task，设定的各个folder之间存在内在联系。对于一个项目而言，只要找到这几个folder，就找到了所有的task，而且是各有区分。Build时候，创建baseline的时候，检索的时候，超级有用。老师说，这是他独创的，不是Telelogic教的，挺能耐吧。我曾经尝试做一些简化，可是实际检测后，发现他的已经是最精辟了，佩服！很长时间的实践，我发现，不要乱动Synergy自带的folder,你要是动了，会发现Synergy又生出来一个，这个重复的folder越来越多，麻烦。

多项目合作问题，困扰我很久了。

我们工作中，经常会遇到多项目合作的问题，一个是在同一库内，一个是不同库内。先说在同一个库里面的。项目间有两种方式，一个是copy task,这种适合于几个task的情况；而另外一种，就是项目间如何把一系列的改动融合到一起呢，这个也是印度老师教的，真是学了人家不少东西，该请人家吃一顿。就是通过检测冲突的方式，等把一个一个冲突解决了，自然也就合并了，简单吧，我咋就没想到呢。当时听他介绍的时候，我很开心了。而Synergy/CM对冲突这块，我觉得它需要把各种冲突如何生成做个更深入的介绍，目前情况下，它只提供了开关文件和各种冲突的提示解决方案，这里有待提高。我很想自如的控制它的冲突产生，但是苦于找不到进一步的指导，只是有了自己的一些理解，很想验证一下的。那不同的库之间，就用DCM了，我是用脚本实现每天几次的收发，用起来还不错的。

在一个权限问题，Synergy在这上面比较弱的。我使用的版本只能用group进行控制，而且当时我是用admin的角色进行的，后来被老师教育了，慎用admin。要结合project 和release来做，我记住了。
这个admin实在是功能强大，我有时候会用它干点不好的事情，没有办法啊。例如应大家要求，把一些已经integrate的文件和project给删除了。这里有个可以参考的，其实有些file没必要删除，把状态变成rejected，也是可以的。

作为scm，随着对工具的理解和更多的实际应用，其实可扩展的还是很多的，例如：
添加关键字，这个Telelogic文件有介绍的，不过64a的要注意，升级之后有变化的，我已经吃了这个亏了。
如何用命令行执行工作？
如何给开发人员查询时，提供custom？
如何增加新属性？
如何把属性变成必须填写？
如何把新增的字段，在两个界面都出现？
如何修改属性值？
如何改变version delimiter?
Migrate需要注意哪些？
怎样优化配置库？
怎样检测孤立文件?
服务down了，通过哪些步骤确认问题所在？怎样一步步检查？
数据库备份问题。
还有更多就是一些实际上用到的很多小问题了，列出来都不知道放哪里。但是manager和developer问起来，我们得知道问题在哪里。例如版本是怎么理解的，1.1.1.2.1什么意思，为什么有的是全数字，有的前面就有好多字母？

因为希望对自己的这么多积累做个总结，所以贴上来，是因为刚开始学习这个的时候，哪里都找不到资料，如何解决实际问题，根本找不到地方去查。

冲突定义是有一个文件的，自己可以改
系统默认的冲突好像挺多的，可以根据项目的实际需要，让系统提示出的冲突是我们项目中实际发生的冲突

文章精辟，语言通俗易懂，积极支持楼主继续发表自己的心得；
7楼好多topic, 楼主能举一些实例那是最好不过了，如：
“如何把新增的字段，在两个界面都出现？”

引用:

原帖由 howardling 于 2007-12-4 10:48 发表
冲突定义是有一个文件的，自己可以改
系统默认的冲突好像挺多的，可以根据项目的实际需要，让系统提示出的冲突是我们项目中实际发生的冲突

尝试过更改那个文件，但是在实际应用中，有些冲突的出现似乎并不应该出现的，出现了。而我的老师并不建议对冲突表建议更改。因此，我希望Telelogic能有相关的详尽讲解，很好的利用冲突能够解决实际工作中遇到的，较为头疼的多项目合并，非常实用。