ClearCase项目管理介绍
From:http://www.cnblogs.com/oscar_nju/archive/2008/03/11/1099773.html
1、 ClearCase 简介
ClearCase（以下简称CC）是一种配置管理工具，由 Rational公司开发，是开发小组用来跟踪、管理软件开发过程各个工件的配置管理系统， ClearCase可以协助开发组织更好地管理软件开发进程。
ClearCase可以和Rational公司的其他软件紧密结合，例如 UCM、ClearQuest等等。 ClearCase包括两套：ClearCase LT和 ClearCase (MultiSite) 。前者可以用于在同一个局域网的开发小组，适合于中小型开发组织；ClearCase (MultiSite) 则适应于分布于不同地理位置、不同局域网的开发小组，适合于大型的开发组织。
目前我们从网络上得到的ClearCase是LT版本，正好符合我们部门目前的团队开发环境。
2、 ClearCase 中的概念、术语
Ø Element
纳入配置管理的包括版本信息的对象，包括文件与目录。
Ø VOB
Version Object Base，存放Element以及其他CC配置信息的库。
Ø PVOB
Project VOB，用于存放UCM项目的VOB。一个UCM项目必须存放于一个PVOB中，而一个PVOB可以存放一个或者多个UCM项目。
Ø UCM
Unified Changed Management的缩写，统一变更管理模式。在CC中有两种项目管理的模式：Base ClearCase 和 UCM。在UCM模式下所有的Check Out、Check In、Add to Source Control等引起对象发生变化的操作必须关联到一个Activity，因此UCM模式通过Activity来管理和控制对象的版本更新。而Base ClearCase模式下，由于没有Activity的概念，上述操作都将直接定位到一个特定的对象。一般情况下我们可以使用CC的UCM模式达到项目管理的需求。
Ø Activity
Activity是ClearCase UCM模式中的一个概念。一个Activity包括一个标题和一个变更集(Change Set)，标题用于简要描述Activity，变更集集中跟踪与此Activity相关的所有Element的版本变更。
Ø Component
在一个UCM项目中由一些相关的文件或者目录组成的一个ClearCase对象。一个项目至少包含一个Component，而一个Component也可以由多个项目共享。
Ø Baseline
就个人理解，基线就是表示一个Component到达某个开发阶段的标识，这个标识包含了Component内部各个Element所处的特定版本。Project可以通过配置它所包含的所有Component的基线来标识它目前所处的开发阶段。
Ø VIEW
一个ClearCase对象，能够为用户提供完成项目修改工作的工作空间。VIEW从VOB中选择各个元素特定版本来形成一个工作空间，用户通过VIEW存取、修改其中的元素。有两种类型的视图：快照视图和动态视图。
1. 视图有两种类型：快照视图（snapshot view）及动态视图（dynamic view）。快照视图是将CC服务器中的视图内容拷贝到开发人员的机器中，开发人员需要经常与服务器同步以保持数据的一致性，快照视图的好处在于开发人员不必一直通过网络与CC服务器保持连接；动态视图则是动态的将 CC服务器中的内容同步到开发人员的机器中，这就要求开发人员一直保持与服务器的网络连接。一般来讲，由管理员决定选用哪种视图。
2. 开发人员的开发涉及到两个视图：开发视图和集成视图。如果用户的名字为pat，参与的项目叫做test，那么两个视图缺省的名字为pat_test和pat_test_integration。开发视图用于开发人员的开发过程，开发人员在开发视图中完成软件的开发、修改、提交等工作；集成视图的作用是存放开发人员完成的工作，使得开发人员可以通过该视图中的内容对其开发进行验证。目前对于开发视图和集成视图的区别和功能本人还有很多疑问。
Ø Stream
Stream记录了在Project中所有工作空间的活动历史，Stream同时也指定了某个时刻工作空间应该能够获取和使用的各个元素的版本。Stream分为Integration stream（集成流）和Development streams（开发流），一个UCM项目中只能有一个集成流，但可以包含多个开发流（项目组成员和开发流是一一对应的关系）。集成流记录了项目中公共的元素及其状态，而开发流记录了各个项目组成员私有的元素及其状态。
以下操作将修改一个Stream的配置：
n 在工作视图中进行“签入”操作，一个Stream可以对应多个视图
n Rebasing操作，它将用更新版本的元素更改Stream的配置
n Delivering操作，交付将当前流的修改反映到目标流中。就个人理解交互一般用于将开发流中的变更反映到集成流中以便所有项目组成员都能看到这些变更；
n Delivering baselines，交付基线，个人不是太明白。
Ø 对Activity、View，Stream的理解
View是CC中的工作平台，大部分的工作都是项目成员在其View中完成，这些工作有些反映成Activity，Stream记录了与他相关的View的所有工作历史。开发视图是开发流的工作平台，项目组的每个成员各自都有一个开发流，但可以有多个开发视图。开发人员在任意一个开发视图中的工作都将被该开发人员对应的开发流记录。集成视图是项目的集成流的工作平台，个人认为他是一种特殊的开发视图，因为任何一个项目成员在集成视图中的工作都将被项目的集成流记录，而集成流在一个UCM项目中只有一个。Rebasing操作和Delivering操作是两个相对的操作，Rebasing操作用于使得集成流中的配置反映到开发流中，而Delivering操作将开发人员的开发流中的配置反映到集成流中以便其他成员能够共享。下面的三个图示意了Activity、View，Stream之间的关系：
上图表明Stream是一个从上到下贯穿整个开发过程的一种历史记录，而View是对Stream的某个阶段（一般来说是最近的）的一个片段，在这一个片段中，项目组成员可以通过“签入”Activity来使得Stream变化。
上图表明每个项目组成员都拥有一个Stream，并且各自可以拥有不同的Activities。
上图表示项目组成员中通过Delivering操作将各自的Activities交付到集成流中，此时成员中各自的集成视图都能够看到这些Activities。
3、 ClearCase LT工作原理
上面提到过ClearCase LT管理项目有两种模式，其中UCM模式是更有效和便捷的方法，图：UCM管理模式流程概貌（参考《Software Configuration Management Strategies and IBM® Rational® ClearCase® Second Edition A Practical Introduction》“3.5. ClearCase UCM Process Overview”）说明了在一个开发团队中几个角色运用ClearCase UCM协作开发一个项目的流程。其中Architect、Configuration Manager、Project Manager、Developer、Integrator依次代表架构师、配置管理员、项目管理员、开发人员、集成人员。从图中我们可以了解，UCM模式下的项目开发是一个迭代的过程，主要工作集中在项目管理员、开发人员、集成人员，他们承担起项目开发、调试、集成等一系列工作。下面我们依次对管理员、开发人员、集成人员在UCM模式中的工作任务做一个简要的介绍。
图：UCM管理模式流程概貌
Ø Project Manager
依照图：UCM管理模式流程概貌对项目职责和工作的划分，项目管理员的职责包括：
1. 为项目创建或者设定Component
2. 创建UCM项目
3. 建立UCM项目管理的策略，包括对象的可访问性等
4. 计划和分配项目工作
5. 监视项目进展和状态
ClearCase的文档（参考“Workflows for Managing Projects with UCM”）中对项目管理员的职责有不同的划分，主要的区别在于“为项目创建或者设定Component”被认为是项目集成人员的工作，如下图所示：
Ø Developer
开发人员在项目建立之后就可以加入项目了，加入项目将会在UCM中创建各自的开发流以及开发视图，开发人员的主要职责包括：
1. 加入到项目
2. 根据项目管理员分配的工作对在各自的开发视图中对项目进行修改
3. 提交开发流中修改到集成流
4. 在集成人员提升项目的基线之后更新各自的开发流和开发视图，并进入到下一个迭代
ClearCase的文档（参考“Software Development with UCM”）中对开发人员的职责也有一个大同小异的描述，这一描述突出了Activities在UCM中的作用，如下图所示：
Ø Integrator
项目开发人员提交了新的修改之后，集成人员必须对这些修改进行集成和测试，当项目到达一个新的稳定的状态之后，集成人员还应当提升项目的基线以便开发人员统一在新的项目基线下继续开发。集成人员的主要工作包括：
1. 创建集成视图
2. 根据开发人员的修改创建新的基线
3. 集成和测试新的基线
4. 在新的基线到达一个稳定状态后将此基线提升为项目的标准基线，通知开发人员更新各自的开发流和开发视图，进入项目的下一个迭代
ClearCase的文档（参考“Workflows for Managing Projects with UCM”）中对集成人员的职责有不同的划分，主要的区别在于“为项目创建或者设定Component”被认为是项目集成人员的工作，如下图所示：
4、 软件开发部运用ClearCase的可行性
Ø 部门项目管理需求
1. 能够使得团队在项目版本控制上摆脱拷贝的原始手段
2. 能够使得团队协作能力得到提高，取代原有的发送邮件等协作方式
3. 使得项目管理员能够对每个成员的工作更好的分配和跟踪
Ø 项目管理需求与ClearCase的功能比较
1. ClearCase UCM模式下，项目中所有的资源都可以纳入到CC的版本控制中，并且能够通过CC了解其版本变更的所有历史。因此CC可以满足我们对项目管理的第一点需求；
2. ClearCase软件的模式是典型的C/S模式，项目开发人员通过创建各自的开发流和开发视图来进行开发，这使得开发人员可以独立的并行的进行工作。同时开发人员通过Deliver各自的工作可以将其修改共享给其他开发人员，而其他开发人员只需要对他们的开发视图进行更新即可得到这些更新。因此CC可以满足第二点需求。
3. CC能够对项目中的每一次变更都进行跟踪，并可以比较不同对象版本之间的差异，通过这些差异我们可以了解项目成员在某一时段内的工作成果。而每个开发人员各自的开发流完整的记录了所有的变更，也就是说记录了在这一项目中开发人员所做的所有工作。
Ø 使用ClearCase的障碍
ClearCase基本能够满足目前我们部门对项目管理的需求，但实际使用将可能遇到以下障碍：
1. 目前我们能够得到的ClearCase软件只能支持单人开发，其他解决办法个人觉得不太可行，这是部门使用CC的最大障碍；
2. ClearCase安装、配置、使用相对较复杂，需要进行团队培训，否则很难正确的高效的运用CC进行项目管理。另外由于第一点障碍的存在，个人在对ClearCase的了解和学习过程遇到很多无法回避的问题，同时也使得个人对CC中的很多概念没有切实的体验，比如项目管理员、集成人员和开发人员在使用CC进行工作的直观体验；
3. ClearCase目前没有中文版本，这可能初学者的使用带来一些困难
5、 项目管理软件简要比较
目前几款重要的项目管理软件除了Rational ClearCase还有Microsoft Visual Sourcesafe、CVS、SVN等。以上几款软件中，CVS和SVN在功能和使用上基本一致，也可以说SVN是从CVS发展而来的一个比CVS更新的版本，因此下面的比较CVS和SVN将都以SVN来代表。对于这些软件，个人都有过学习和使用的经验，相较而言，CC是了解得最少的一个，而SVN是使用时间最长的一个。下面就个人经验谈谈对几款软件的认识：
1. 从软件架构来看，CC和SVN是典型的C/S模式，而VSS则不是。因此CC和SVN都可以通过建立服务器来达到在局域网甚至internet进行项目管理的目的，而VSS只能在局域网中使用，并且VSS的数据库必须存放在一个共享的文件夹内，这给安全性带来隐患；
2. ClearCase的权限管理集成域控制机制，这既可以说是CC的一个优点也可以认为是CC的一个不方便之处；
3. 并行开发模式。项目管理的模式有Copy-Modify-Merge和Lock-Modify-Unlock两种。VSS支持Lock-Modify-Unlock模式，但在此模式下不支持并行开发，目前部门使用VSS采用的是这种模式。而VSS、CC和SVN都支持Copy-Modify-Merge模式。在Copy-Modify-Merge模式下，开发人员的协作将变得更加简单，各自的工作将不会受到其他人员的影响，只有在提交（注：这里的提交对VSS来说是Check in操作，但对CC来说既包括Check in操作也包括Deliver操作，且主要指Deliver操作，因为Check out和Check in在CC中主要发生在开发视图中，而开发视图一般不是并行的）修改的时候才可能需要处理版本上的冲突，而这种冲突可以很简单的通过好的文件结构来避免。比如Tom负责文件File1的更新，但File1依赖Kate负责的File2，由于File2的内部实现的复杂性，Tom不能直接使用File2进行测试File1的工作，那么Tom在开发的时候完全可以修改他的工作副本中的File2文件以保证File1的测试顺利进行，然后在他可以仅仅将File1的修改提交。CC有一个特别之处在于CC可以记录每个项目成员的所有工作，而VSS和SVN只能跟踪每个文件的每一次更新是由谁完成的，但不能集中的反映项目成员的所有工作。
4. 与开发环境的集成。VSS与开发环境集成较好，但是VSS有个缺点是VSS会修改sln和vsproj等文件来完成对项目文件的管理。CC在可以通过ClearCase Explorer来工作，也能够与Visual Studio集成，但他在可视化有一点缺陷，不能直观的反映出文件夹及其内容的状态。SVN的客户端是一个Windows Explorer的外壳程序，通过右键菜单便可以方便的完成项目的管理。SVN需要在每个工作副本下的文件夹添加一些隐藏的配置文件，但SVN提供从受控项目中获得干净的所有相关资源的命令。另外SVN对其控制的文件使用一套特别的图标来标识文件的工作副本目前与版本库的状态差异，这个人觉得是一个重要的优点。如下图：
5. 性能和易用性。VSS因为没有服务端，它对版本库的操作完全是对任一个VSS软件自由的，因此其性能不是太好，在数据量不大的情况下，可以接受。另外VSS版本库容易损坏，比如机器死机或者断电都可能造成版本库的某个部分不可用。CC服务器采用多线程机制，性能较好，但其安装、配置、使用相对较复杂，需要进行团队培训。SVN的服务端配置有一定难度，但其客户端使用简单直观。SVN的性能也较好。
6、 参考资料
Ø 《Software Configuration Management Strategies and IBM® Rational® ClearCase® Second Edition A Practical Introduction》By David E. Bellagio, Tom J. Milligan
Ø 《Rational ClearCase Online Help》
Ø 《Rational ClearCase LT 使用指南.pdf》
1、 ClearCase 简介
ClearCase（以下简称CC）是一种配置管理工具，由 Rational公司开发，是开发小组用来跟踪、管理软件开发过程各个工件的配置管理系统， ClearCase可以协助开发组织更好地管理软件开发进程。
ClearCase可以和Rational公司的其他软件紧密结合，例如 UCM、ClearQuest等等。 ClearCase包括两套：ClearCase LT和 ClearCase (MultiSite) 。前者可以用于在同一个局域网的开发小组，适合于中小型开发组织；ClearCase (MultiSite) 则适应于分布于不同地理位置、不同局域网的开发小组，适合于大型的开发组织。
目前我们从网络上得到的ClearCase是LT版本，正好符合我们部门目前的团队开发环境。
2、 ClearCase 中的概念、术语
Ø Element
纳入配置管理的包括版本信息的对象，包括文件与目录。
Ø VOB
Version Object Base，存放Element以及其他CC配置信息的库。
Ø PVOB
Project VOB，用于存放UCM项目的VOB。一个UCM项目必须存放于一个PVOB中，而一个PVOB可以存放一个或者多个UCM项目。
Ø UCM
Unified Changed Management的缩写，统一变更管理模式。在CC中有两种项目管理的模式：Base ClearCase 和 UCM。在UCM模式下所有的Check Out、Check In、Add to Source Control等引起对象发生变化的操作必须关联到一个Activity，因此UCM模式通过Activity来管理和控制对象的版本更新。而Base ClearCase模式下，由于没有Activity的概念，上述操作都将直接定位到一个特定的对象。一般情况下我们可以使用CC的UCM模式达到项目管理的需求。
Ø Activity
Activity是ClearCase UCM模式中的一个概念。一个Activity包括一个标题和一个变更集(Change Set)，标题用于简要描述Activity，变更集集中跟踪与此Activity相关的所有Element的版本变更。
Ø Component
在一个UCM项目中由一些相关的文件或者目录组成的一个ClearCase对象。一个项目至少包含一个Component，而一个Component也可以由多个项目共享。
Ø Baseline
就个人理解，基线就是表示一个Component到达某个开发阶段的标识，这个标识包含了Component内部各个Element所处的特定版本。Project可以通过配置它所包含的所有Component的基线来标识它目前所处的开发阶段。
Ø VIEW
一个ClearCase对象，能够为用户提供完成项目修改工作的工作空间。VIEW从VOB中选择各个元素特定版本来形成一个工作空间，用户通过VIEW存取、修改其中的元素。有两种类型的视图：快照视图和动态视图。
1. 视图有两种类型：快照视图（snapshot view）及动态视图（dynamic view）。快照视图是将CC服务器中的视图内容拷贝到开发人员的机器中，开发人员需要经常与服务器同步以保持数据的一致性，快照视图的好处在于开发人员不必一直通过网络与CC服务器保持连接；动态视图则是动态的将 CC服务器中的内容同步到开发人员的机器中，这就要求开发人员一直保持与服务器的网络连接。一般来讲，由管理员决定选用哪种视图。
2. 开发人员的开发涉及到两个视图：开发视图和集成视图。如果用户的名字为pat，参与的项目叫做test，那么两个视图缺省的名字为pat_test和pat_test_integration。开发视图用于开发人员的开发过程，开发人员在开发视图中完成软件的开发、修改、提交等工作；集成视图的作用是存放开发人员完成的工作，使得开发人员可以通过该视图中的内容对其开发进行验证。目前对于开发视图和集成视图的区别和功能本人还有很多疑问。
Ø Stream
Stream记录了在Project中所有工作空间的活动历史，Stream同时也指定了某个时刻工作空间应该能够获取和使用的各个元素的版本。Stream分为Integration stream（集成流）和Development streams（开发流），一个UCM项目中只能有一个集成流，但可以包含多个开发流（项目组成员和开发流是一一对应的关系）。集成流记录了项目中公共的元素及其状态，而开发流记录了各个项目组成员私有的元素及其状态。
以下操作将修改一个Stream的配置：
n 在工作视图中进行“签入”操作，一个Stream可以对应多个视图
n Rebasing操作，它将用更新版本的元素更改Stream的配置
n Delivering操作，交付将当前流的修改反映到目标流中。就个人理解交互一般用于将开发流中的变更反映到集成流中以便所有项目组成员都能看到这些变更；
n Delivering baselines，交付基线，个人不是太明白。
Ø 对Activity、View，Stream的理解
View是CC中的工作平台，大部分的工作都是项目成员在其View中完成，这些工作有些反映成Activity，Stream记录了与他相关的View的所有工作历史。开发视图是开发流的工作平台，项目组的每个成员各自都有一个开发流，但可以有多个开发视图。开发人员在任意一个开发视图中的工作都将被该开发人员对应的开发流记录。集成视图是项目的集成流的工作平台，个人认为他是一种特殊的开发视图，因为任何一个项目成员在集成视图中的工作都将被项目的集成流记录，而集成流在一个UCM项目中只有一个。Rebasing操作和Delivering操作是两个相对的操作，Rebasing操作用于使得集成流中的配置反映到开发流中，而Delivering操作将开发人员的开发流中的配置反映到集成流中以便其他成员能够共享。下面的三个图示意了Activity、View，Stream之间的关系：
上图表明Stream是一个从上到下贯穿整个开发过程的一种历史记录，而View是对Stream的某个阶段（一般来说是最近的）的一个片段，在这一个片段中，项目组成员可以通过“签入”Activity来使得Stream变化。
上图表明每个项目组成员都拥有一个Stream，并且各自可以拥有不同的Activities。
上图表示项目组成员中通过Delivering操作将各自的Activities交付到集成流中，此时成员中各自的集成视图都能够看到这些Activities。
3、 ClearCase LT工作原理
上面提到过ClearCase LT管理项目有两种模式，其中UCM模式是更有效和便捷的方法，图：UCM管理模式流程概貌（参考《Software Configuration Management Strategies and IBM® Rational® ClearCase® Second Edition A Practical Introduction》“3.5. ClearCase UCM Process Overview”）说明了在一个开发团队中几个角色运用ClearCase UCM协作开发一个项目的流程。其中Architect、Configuration Manager、Project Manager、Developer、Integrator依次代表架构师、配置管理员、项目管理员、开发人员、集成人员。从图中我们可以了解，UCM模式下的项目开发是一个迭代的过程，主要工作集中在项目管理员、开发人员、集成人员，他们承担起项目开发、调试、集成等一系列工作。下面我们依次对管理员、开发人员、集成人员在UCM模式中的工作任务做一个简要的介绍。
图：UCM管理模式流程概貌
Ø Project Manager
依照图：UCM管理模式流程概貌对项目职责和工作的划分，项目管理员的职责包括：
1. 为项目创建或者设定Component
2. 创建UCM项目
3. 建立UCM项目管理的策略，包括对象的可访问性等
4. 计划和分配项目工作
5. 监视项目进展和状态
ClearCase的文档（参考“Workflows for Managing Projects with UCM”）中对项目管理员的职责有不同的划分，主要的区别在于“为项目创建或者设定Component”被认为是项目集成人员的工作，如下图所示：
Ø Developer
开发人员在项目建立之后就可以加入项目了，加入项目将会在UCM中创建各自的开发流以及开发视图，开发人员的主要职责包括：
1. 加入到项目
2. 根据项目管理员分配的工作对在各自的开发视图中对项目进行修改
3. 提交开发流中修改到集成流
4. 在集成人员提升项目的基线之后更新各自的开发流和开发视图，并进入到下一个迭代
ClearCase的文档（参考“Software Development with UCM”）中对开发人员的职责也有一个大同小异的描述，这一描述突出了Activities在UCM中的作用，如下图所示：
Ø Integrator
项目开发人员提交了新的修改之后，集成人员必须对这些修改进行集成和测试，当项目到达一个新的稳定的状态之后，集成人员还应当提升项目的基线以便开发人员统一在新的项目基线下继续开发。集成人员的主要工作包括：
1. 创建集成视图
2. 根据开发人员的修改创建新的基线
3. 集成和测试新的基线
4. 在新的基线到达一个稳定状态后将此基线提升为项目的标准基线，通知开发人员更新各自的开发流和开发视图，进入项目的下一个迭代
ClearCase的文档（参考“Workflows for Managing Projects with UCM”）中对集成人员的职责有不同的划分，主要的区别在于“为项目创建或者设定Component”被认为是项目集成人员的工作，如下图所示：
4、 软件开发部运用ClearCase的可行性
Ø 部门项目管理需求
1. 能够使得团队在项目版本控制上摆脱拷贝的原始手段
2. 能够使得团队协作能力得到提高，取代原有的发送邮件等协作方式
3. 使得项目管理员能够对每个成员的工作更好的分配和跟踪
Ø 项目管理需求与ClearCase的功能比较
1. ClearCase UCM模式下，项目中所有的资源都可以纳入到CC的版本控制中，并且能够通过CC了解其版本变更的所有历史。因此CC可以满足我们对项目管理的第一点需求；
2. ClearCase软件的模式是典型的C/S模式，项目开发人员通过创建各自的开发流和开发视图来进行开发，这使得开发人员可以独立的并行的进行工作。同时开发人员通过Deliver各自的工作可以将其修改共享给其他开发人员，而其他开发人员只需要对他们的开发视图进行更新即可得到这些更新。因此CC可以满足第二点需求。
3. CC能够对项目中的每一次变更都进行跟踪，并可以比较不同对象版本之间的差异，通过这些差异我们可以了解项目成员在某一时段内的工作成果。而每个开发人员各自的开发流完整的记录了所有的变更，也就是说记录了在这一项目中开发人员所做的所有工作。
Ø 使用ClearCase的障碍
ClearCase基本能够满足目前我们部门对项目管理的需求，但实际使用将可能遇到以下障碍：
1. 目前我们能够得到的ClearCase软件只能支持单人开发，其他解决办法个人觉得不太可行，这是部门使用CC的最大障碍；
2. ClearCase安装、配置、使用相对较复杂，需要进行团队培训，否则很难正确的高效的运用CC进行项目管理。另外由于第一点障碍的存在，个人在对ClearCase的了解和学习过程遇到很多无法回避的问题，同时也使得个人对CC中的很多概念没有切实的体验，比如项目管理员、集成人员和开发人员在使用CC进行工作的直观体验；
3. ClearCase目前没有中文版本，这可能初学者的使用带来一些困难
5、 项目管理软件简要比较
目前几款重要的项目管理软件除了Rational ClearCase还有Microsoft Visual Sourcesafe、CVS、SVN等。以上几款软件中，CVS和SVN在功能和使用上基本一致，也可以说SVN是从CVS发展而来的一个比CVS更新的版本，因此下面的比较CVS和SVN将都以SVN来代表。对于这些软件，个人都有过学习和使用的经验，相较而言，CC是了解得最少的一个，而SVN是使用时间最长的一个。下面就个人经验谈谈对几款软件的认识：
1. 从软件架构来看，CC和SVN是典型的C/S模式，而VSS则不是。因此CC和SVN都可以通过建立服务器来达到在局域网甚至internet进行项目管理的目的，而VSS只能在局域网中使用，并且VSS的数据库必须存放在一个共享的文件夹内，这给安全性带来隐患；
2. ClearCase的权限管理集成域控制机制，这既可以说是CC的一个优点也可以认为是CC的一个不方便之处；
3. 并行开发模式。项目管理的模式有Copy-Modify-Merge和Lock-Modify-Unlock两种。VSS支持Lock-Modify-Unlock模式，但在此模式下不支持并行开发，目前部门使用VSS采用的是这种模式。而VSS、CC和SVN都支持Copy-Modify-Merge模式。在Copy-Modify-Merge模式下，开发人员的协作将变得更加简单，各自的工作将不会受到其他人员的影响，只有在提交（注：这里的提交对VSS来说是Check in操作，但对CC来说既包括Check in操作也包括Deliver操作，且主要指Deliver操作，因为Check out和Check in在CC中主要发生在开发视图中，而开发视图一般不是并行的）修改的时候才可能需要处理版本上的冲突，而这种冲突可以很简单的通过好的文件结构来避免。比如Tom负责文件File1的更新，但File1依赖Kate负责的File2，由于File2的内部实现的复杂性，Tom不能直接使用File2进行测试File1的工作，那么Tom在开发的时候完全可以修改他的工作副本中的File2文件以保证File1的测试顺利进行，然后在他可以仅仅将File1的修改提交。CC有一个特别之处在于CC可以记录每个项目成员的所有工作，而VSS和SVN只能跟踪每个文件的每一次更新是由谁完成的，但不能集中的反映项目成员的所有工作。
4. 与开发环境的集成。VSS与开发环境集成较好，但是VSS有个缺点是VSS会修改sln和vsproj等文件来完成对项目文件的管理。CC在可以通过ClearCase Explorer来工作，也能够与Visual Studio集成，但他在可视化有一点缺陷，不能直观的反映出文件夹及其内容的状态。SVN的客户端是一个Windows Explorer的外壳程序，通过右键菜单便可以方便的完成项目的管理。SVN需要在每个工作副本下的文件夹添加一些隐藏的配置文件，但SVN提供从受控项目中获得干净的所有相关资源的命令。另外SVN对其控制的文件使用一套特别的图标来标识文件的工作副本目前与版本库的状态差异，这个人觉得是一个重要的优点。如下图：
5. 性能和易用性。VSS因为没有服务端，它对版本库的操作完全是对任一个VSS软件自由的，因此其性能不是太好，在数据量不大的情况下，可以接受。另外VSS版本库容易损坏，比如机器死机或者断电都可能造成版本库的某个部分不可用。CC服务器采用多线程机制，性能较好，但其安装、配置、使用相对较复杂，需要进行团队培训。SVN的服务端配置有一定难度，但其客户端使用简单直观。SVN的性能也较好。
6、 参考资料
Ø 《Software Configuration Management Strategies and IBM® Rational® ClearCase® Second Edition A Practical Introduction》By David E. Bellagio, Tom J. Milligan
Ø 《Rational ClearCase Online Help》
Ø 《Rational ClearCase LT 使用指南.pdf》