1 关于本文档
详细的描述在推行软件配置管理的可行性，以及各类软件配置工具的比较，结合本中心的实际特点，分析适合本中心使用的软件配置工具。
本文档由陆国暾撰写，要详尽了解相关软件配置工具的具体性能数据，请参阅该软件出品公司技术文档。
2 现状简述
现有的软件配置管理工具(SCM Tools)大致有如下几个品种：
(1) IBM—ClearCase (CC);
(2) Microsoft—Visual Source Safe (VSS);
(3) Borland—StarTeam (ST)
(4) Open Source--Concurrent Versions System (CVS);
(5) Hansky—Firefly;
该份可行性报告即为以上5种配置管理工具的评估报告，其侧重点针对本中心的实际情况，结合各个开发部门的操作系统，开发流程，项目规模，易用性，价格，与其他管理系统的良好的结合性等等方面来进行考虑。
进行软件配置管理的目的：
一、权限控制（Access Control）
权限控制对SCM工具来说至关重要。一方面，既然是团队开发，就可能需要限制某些成员的权限；特别是大项目往往牵扯到子项目外包，到最后联调阶段会涉及到很多不同的单位，更需要权限管理。另一方面，权限控制也减小了误操作的可能性，间接提高了SCM工具的可用性（Usability）。
现有的SCM工具，在权限控制方面差异很大，也说明了大家都在探索更有效的权限控制的方法。透过不同权限控制方法的差异，我们不难看到其共性：其核心概念是行为（Action）、行为主体、行为客体。
行为主体：即用户（User）。用户组（User Group）并不是行为主体，但它的引入大大方便了权限管理。
行为客体：即项目和项目成员（Member）。不管从SCM工具的开发者还是使用者的角度，项目和项目成员都是不同的行为客体。
行为：即由主体施加在客体之上的特定操作，签入和签出是再典型不过的例子。
三个核心概念搞清之后，就可以讨论权限的概念了。
权限是这样一个四元向量：(主体，客体，行为，布尔值)。即，“主体在客体上施加某种行为是否被获准”。
由此看来，权限控制的基本工作就是负责维护主体集合、客体集合、行为集合、权限向量集合。其中，行为集合是固定不变的（在SCM工具开发之时已确定），其它三种集合都是动态变化的。
二、版本控制（Version Control）
SCM工具记录项目和文件的修改轨迹，跟踪修改信息，使软件开发工作以基线（Baseline）渐进方式完成，从而避免了软件开发不受控制的局面，使开发状态变得有序。
SCM工具可以对同一文件的不同版本进行差异比较，可以恢复个别文件或整个项目的早期版本，使用户方便地得到升级和维护必需的程序和文档。
SCM工具内部对版本的标识，采用了版本号（Version Number）方式，但对用户提供了多种途径来标识版本，被广泛应用的有版本号、标签（Label）和时间戳（Time Stamp）。多样灵活的标识手段，为用户提供了方便。
三、增强的版本控制（Enhanced Version Control）
快照（Snapshot）和分支（
Branch）以基本的版本控制功能为基础，使版本控制的功能又更进一步增强。
快照是比版本高一级的概念，它是项目中多个文件各自的当前版本的集合。快照使恢复项目的早期版本变得方便，它还支持批量签入（Check in）、批量签出（Check out）和批量加标签（Label）等操作。总之，快照是版本控制的一种增强，使版本控制更加方便高效。
分支允许用户创建独立的开发路径，我们认为分支的典型用途有二。第一，分支和合并（Merge）一起，是支持并行开发（Concurrent Development）的有力支持。第二，分支支持多版本开发，这对发布后的维护尤其有用。比如客户报告有打印bug，小组可能从某个还未引入打印bug的项目版本引出一个分支，最终分布ā一个bug修订版。分支是版本控制的另一种增强。
版本控制和增强的版本控制是SCM工具其它功能的基础。
四、变更管理（Change Management）
SCM工具提供有效的问题跟踪（Defect Tracking）和系统变更请求（System Change Requests (SCRs)）管理。通过对软件生命周期各阶段所有的问题和变更请求进行跟踪记录，来支持团队成员报告（Report）、抓取（Capture）和跟踪（Track）与软件变更相关的问题，以此了解谁改变了什么，为什么改变。
变更管理有效地支持了不同开发人员之间，以及客户和开发人员之间的交流，避免了无序和各自为政的状态。
五、独立的工作空间（Independent Workspaces）
开发团队成员需要在开发项目上协同、并发地工作，这样可以大大提高软件开发的效率。沙箱（Sandbox）为并行开发提供了独立的工作空间，在有的SCM工具中也称为工作目录（Working Folder）。
使用沙箱（Sandbox），开发人员能够将所有必要的项目文件拷贝到私有的一个树型目录，修改在这些副本上进行。一旦对修改感到满意，就可以将修改合并（Merge）到开发主线（Main Line）上去；当然，如果该文件只有该成员一人修改，只需将修改过的文件签入（Check In）到主项目中即可。
“并发和共享是同一事物的不同方面”，并发的私有工作空间共享同一套主项目（Mater Project）文件，因此有必要让所有团队成员拥有得知项目当前状态的能力。SCM工具提供刷新（Refresh）操作，某位团队成员可以使其他团队成员在主项目文件上所做的变更，在自己沙箱的图形用户界面上反应出来。
六、报告（Report）
为保证项目按时完成，项目经理必须监控开发进程并对发生的问题迅速做出反应。报告功能使项目经理能够随时了解项目进展情况；通过图形化的报告，开发的瓶颈可以一目了然地被发现；标准的报告提供常用的项目信息，定制报告功能保证了拥有适合自己需求的信息。
七、过程自动化（Process Automation）
SCM工具使用事件触发机制（Event Trigger），即让一个事件触发另一个事件产生行为，来实现过程自动化。比如，让“增加项目成员”操作自动触发“产生功能描述表（Form）”操作，开发人员填制该文件的功能描述表，规范开发过程。
过程自动化不仅可以缩短复杂任务的时间，提高了生产率，而且还规范了团队开发的过程，减少了混乱。
八、管理项目的整个生命周期
从开发、测试、发布到发布后的维护，SCM工具的使命“始于项目开发之初，终于产品淘汰之时”。SCM工具应预先提供典型的开发模式的模板，以减少用户的劳动；另一方面，也应支持用户自定义生命周期模式，以适应特殊开发需要。
九、与主流开发环境的集成
将版本控制功能与主流集成开发环境（IDE）集成，极大地方便了软件开发过程。从集成开发环境的角度看，版本控制是其一项新功能；从SCM工具的角度看，集成开发环境充当了沙箱的角色。
3 产品比较
陆国暾根据本中心的具体情况，结合各个产品的特性和自身使用情况，特对个产品横向比较如下：
（红色代表经考察对于本中心特别重要的需求）
Firefly
ClearCase
CVS
StarTeam
VSS
体系结构和安全性
采用C/S模式，后台采用数据库存储，存储目录不用共享，对客户端不透明，客户端不可直接访问存储目录，安全性较好
采用C/S模式，需要共享服务器上的存储目录以供客户端访问，这将带来一定安全隐患，公司必须建立域。
采用C/S 模式，不需要共享服务器上的存储目录，安全性较好
基于文件系统，使用NFS/SMB，后台使用文件系统共享，需要共享存储目录，这将带来一定安全隐患
访问服务器增量存储
快速，只上下传文件的增量，包括文本格式和二进制格式
支持文本格式文件增量存储，以完全拷贝形式保存二进制文件（有争议，内部说法不一致）
支持文本格式文件增量存储，以完全拷贝形式保存二进制文件
慢，使用远程文件访问方式，不能实现增量传输。当在大项目中使用时问题尤为突出
本地操作
快速
快速
快速
快速
快速
与开发工具集成
与常见开发工具无缝集成
直接与资源管理器集成，十分易用
对开发工具集成性较差
与Borland开发工具集成较好
与Visual Studio开发工具包无缝连接，其它开发工具集成性差
异地开发支持
提供ServerSync 模块，通过自动或手动同步位于不同开发地点的存储库的方式，支持异地开发
提供MultiSite 模块，通过自动或手动同步位于不同开发地点的存储库的方式，支持异地开发
支持异地开发，但是支持程度不明
不支持
权限管理和备份
方便的管理界面，采用类似与NTFS的权限管理方法，可以针对项目、目录或文件设置用户和组的访问全权限，自带增量备份/恢复功能
方便的管理界面，权限可分组，主要由系统管理员进行管理，需要使用第三方备份工具，但是有一定的规则支持
权限可分组，主要由系统管理员进行管理，需要使用第三方备份工具
只有用户，没有组的概念，权限设置管理工作量巨大，且不方便，需要采用第三方备份工具
平台支持
平台移植性好，支持绝大多数硬件平台和操作系统
平台移植性好，支持绝大多数硬件平台和操作系统
平台移植性好，支持绝大多数硬件平台和操作系统
只支持Windows平台
系统资源
性能好，对服务器要求不高
服务器采用多进程机制，使用自带多版本文件系统MVFS，对性能有较大负面影响。做为一款企业级、全面的开发配置管理工具，适用于大型开发团队
较高的运行性能，适用于各种级别的开发团队
需要高端服务器，且对硬盘空间要求高，相对功能单一、简陋，适用于几个人的小型团队，在数据量不大的情况下，性能可以接受
原子事务处理
支持原子事务处理，保证数据的一致性
支持原子事务处理，保证数据的一致性
不支持
不支持
变更集及变更管理
支持变更集的概念，并且可以和Hansky的变更管理工具Butterfly完全集成
支持变更集的概念，并且可以和Rational的变更管理工具ClearQuest完全集成
不支持
不支持
命令行界面
提供所有功能的命令行操作，这是实现每天Build的基本条件
支持 Build管理，能够确认到每个版本build出来的文件是由哪些源代码生成的
支持命令行界面，但是不支持build管理
只能实现少数功能
脱机版本保存
可以保存脱机后文件修改的所有历史版本，并能上传回服务器
能脱机开发，只支持最后一个版本上传回服务器
能脱机开发，只支持最后一个版本上传回服务器
不支持
分支及并行开发
采用工作空间的方式，简便创建分支、标签，实现并行开发
采用工作空间的方式，简便创建无限分支、标签，实现并行开发
支持分支，支持并行开发，但是模式简单
支持分支，但分支层次有限，使用不便，不支持并行开发
文件的重命名和移动
完全支持，使用简便，且保存所有历史纪录
完全支持
不支持
难以保留历史记录
版本树浏览
图形化的版本树浏览窗口，用户可以直观地看到文件的版本历史，并进行版本比较
图形化的版本树浏览窗口，用户可以直观地看到文件的版本历史，并进行版本比较
不支持
不支持
Web界面访问
WEB用户界面，可以浏览工作空间的结构、历史，查看文件历史，进行文件比较等
可以浏览工作空间的结构、历史，查看文件历史，进行文件比较等
不支持
不支持
扩展性
能支持大规模开发
能支持大规模开发
能支持大规模开发
能支持大规模开发
无法支持大团队、大项目的开发
报告功能
提供配置报告及历史变更报告的自动生成功能，为CMM提供有力的支持
提供基本的简单报告，如需更详细正规的报告需要购买SODA
不支持
不支持
易用性
在提供全面配置管理功能的情况下，安装、配置、使用较为简单，包括安装、配置、培训在内的整个实施周期一般不会超过一个月。
安装、配置、使用相对较复杂，需要进行团队培训。所有的培训和服务都是收费的
安装、配置较复杂，但使用比较简单，只需对配置管理做简单培训即可
安装、配置、使用均较简单，很容易上手使用
本地化支持（中文）
支持（包括说明书以及培训，客户端支持中英切换）
不支持，但是有中文的培训
不支持
不支持
不支持
分支比较功能
支持到文件
支持到目录
不明
不支持
服务
已在中国成立分公司，全面拓展市场之中，在北京设有支持中心
国内市场拓展有限，因此服务支持会受到限制。现在中国用户的支持是由位于澳大利亚悉尼的支持中心联系
开源软件，没有任何服务和支持，用户的数据得不到任何保障
国内市场拓展更为有限，Borland服务支持较之IBM和Hansky稍逊一筹
做为微软的非核心产品，技术支持有限。在其网站上有提供一些常见问题，只有对正式购买的用户提供一定的技术支持
授权方式及其价格
并发授权，USD 2900.00/License（不包括服务器授权）
并发授权，RMB 58615.00/License（不包括服务器授权）
免费
暂未提供
免费（随Visual Studio授权）
以上为根据个人试用或者相关工程师售前咨询得来的结果，希望组织相关讨论来进一步了解公司现在以及将来的需求，有针对性地进行评估。
4 ClearCase
＊支持广泛的文件类型
ClearCase不仅可以对软件组件的版本进行维护和控制，也可以对一个非文本文件、目录的版本进行维护。用户可以定义自己的元件类型，也可以使用ClearCase中的预定义类型。在存储时，ClearCase可以利用增量算法将文本文件存储在一个特殊结构的文件容器中，或采用标准的压缩技术控制任何操作系统文件。（这比以往的存储形式节省了50％－70％的存储空间。）
＊在版本树中观察元件发展的过程
在ClearCase中，文件版本的组织体现在版本树结构中。每一个文件都可以通过checkout－edit－checkin的命令形成多个版本，还可以包含多层分支和子分支。
＊对目录和子目录进行版本控制
ClearCase可以对目录和子目录进行版本控制，允许开发者对其数据的组织发展过程进行追踪。目录版本对一些改变进行控制，如建立一个新文件、修改文件名、建立新的子目录或在目录间移动文件等。 ClearCase也支持对目录自动进行比较和归并的操作。
＊数据存储在一个可访问的版本对象库中（VOB）
ClearCase把所有版本控制的数据存放在一个永久、安全的存储区中，这个存储区被称为版本对象库（Version Object Bases），项目团队（或管理者）可以决定它们所需要的VOB数量，可以决定什么样的目录或文件需要被维护。VOB不仅是一个可连接的文件系统，而且也是网上的资源，主机可以连接任意个VOB。
ClearCase的操作（如检出、检入和版本归并）可以建立时间记录，这些记录被存储在VOB数据库中，主要描述该操作的属性，包括“谁做的、做什么、什么时候、在哪个地方及为什么”等等。
IBM(Rational)公司推出的软件配置管理工具ClearCase主要用于Windows和Unix开发环境。ClearCase提供了全面的配置管理功能——包括版本控制、工作空间管理、建立管理和过程控制，而且无需软件开发者改变他们现有的环境、工具和工作方式。ClearCase具有以下主要功能：
1．版本控制
＊版本间的透明访问
ClearCase提供了对版本进行透明访问的功能。通过VOB机制（包含文件或目录的多个版本），ClearCase可以让开发者和应用者以一种标准文件目录树的形式访问VOB。 ClearCase能与Windows资源管理器完美集成，使开发人员不必进入ClearCase界面就可直接完成相关操作。
＊从其他主机平台访问视图
在局域网中，未安装ClearCase的机器也可使用ClearCase所控制的数据。例如，一台ClearCase Unix主机通过一种特殊的视图输出VOB，网上其他主机则可通过NFS机制连接它，从而使开发人员能在未安装ClearCase的主机平台上读写视图。但是有一点必须注意，未安装ClearCase的主机必须重新注册或使用安装了ClearCase的Unix主机上的X－Windows系统进行检入、检出操作。
ClearCase的核心功能是版本控制，它是对软件开发进程中一个文件或一个目录发展过程进行追踪的手段。ClearCase可对所有文件系统对象（包括文件、目录和链接）进行版本控制，同时还提供了先进的版本分支和归并功能用于支持并行开发。因而，ClearCase提供的能力已远远超出资源控制的范围，它还可以帮助开发团队在开发软件时为其所处理的每一种信息类型建立一个安全可靠的版本历史记录。
2．工作空间管理
所谓空间管理，即保证开发人员拥有自己独立的工作环境，拥有自己的私人存储区，同时可以访问成员间的共享信息。ClearCase给每一位开发者提供了一致、灵活的可重用工作空间域。它采用名为View的新技术，通过设定不同的视图配置规格，帮助程序员选择特定任务的每一个文件或目录的适当版本，并显示它们。View使开发者能在资源代码共享和私有代码独立的不断变更中达到平衡。
3．建立管理
使用ClearCase，构造软件的处理过程可以和传统的方法兼容。对ClearCase控制的数据，你既可以使用自制脚本也可使用本机提供的make程序，但ClearCase的建立工具clearmake（支持Unix）和omake（支持NT）为构造提供了重要的特性：自动完成任务、保证重建的可靠性、存储时间和支持并行的分布式结构的建立。此外，ClearCase还可以自动追踪、建立产生永久性的资料清单。
4．过程控制
软件开发的策略和过程由于行业和开发队伍的不同而有很大差异，但是有一点是肯定的：即提高软件质量、缩短产品投放市场时间。ClearCase为团队通信、质量保证、变更管理提供了非常有效的过程控制和策略控制机制。这些过程和策略控制机制充分支持质量标准的实施与保证，如：SEI Capability Maturity Model 和ISO 9000。 ClearCase可以通过有效的设置监控开发过程，这体现在以下几方面：
＊为对象分配属性：例如，Codequality属性可有A、B、 C、D或F五个值。其强有力的查询工具允许用户查 找各种版本的文件。
＊超级链接：超级链接可追溯到所有的元素变量、特定 的版本（需求追踪也同样需要）、或者对象中的某一 部分。
＊历史记录：ClearCase自动记录下重要的状态信息， 当对象发生变更时，它会收集“谁、何时、为什么”、 用户注释、以及其他的重要数据。系统也会保留创建、 释放项目时的类似信息。
＊定义事件触发机制：事件预触发机制监视每一种特定 ClearCase操作或操作类的使用。触发可要求在执行 某个操作命令之前对它进行检查，并据此判断是继续 执行、还是取消操作。事件后触发机制好像一个监视 器，它会在某个命令执行后或给某个对象赋予属性后， 把这些动作通知给用户。
＊访问控制：控制数据读、写、执行权限；同时，它还对文 件系统之下的物理存储施加保护，有效地制止那些 试图逃避ClearCase破坏原始操作系统存储的小 动作。
＊查询功能：ClearCase中有一个 find（查询）命令，使得 开发能迅速获知当前项目的状态。
综上所述，ClearCase支持全面的软件配置管理功能，给那些经常跨越复杂环境（如Unix、Windows系统）进行复杂项目开发的团队带来巨大效益。此外，ClearCase也支持广泛的开发环境,它所拥有的特殊组件已成为当今软件开发人员工程人员和管理必备的工具。ClearCase的先进功能直接解决了原来开发团队所面临的一些难以处理的问题，并且通过资源重用帮助开发团队，使其开发的软件更加可靠。在当今日益激烈的市场竞争中，ClearCase作为规范的软件配置管理工具，能完全满足软件开发人员的需求，同时健全了软件开发的科学管理。
5 Visual Source Safe
微软的Visual SourceSafe(以下简称VSS)广泛应用于基于Windows环境的软件项目的版本控制，它具有以下的特点：
1、 功能实用
VSS提供了基本的版本控制功能, 包括协调多人同时存取同一个文件、跟踪文件的历史版本等基本功能。VSS也提供版本数据库的备份和恢复功能，可有效保证了版本数据的安全性，这些功能对于一般的项目开发已经足够了。
2、价格便宜
VSS是Microsoft Visual Studio开发产品家庭（一般从事软件开发的团体都会有该软件）中的一员，如果你现在已有Visual Studio 6 Enterprise Edition，或者Visual Studio .NET Enterprise Developer Edition，或者Visual Studio .NET Enterprise Architect Edition，都可以在上面找到VSS软件，由于Microsoft Visual Studio的价格较低（如Visual Studio .NET Enterprise Developer Edition，网上报价为US$ 1799），如果进行成本的摊分，VSS的实际成本可以说是微不足道，如果你无上述的Visual Studio软件，你也可单独购买VSS软件，网上的报价为US$ 549。
3、使用方便
VSS继承了微软所有产品的优点，提供了方便的图形化的集成的操作界面，用户可直观地进行文件的存取、历史版本浏览、文件比较等操作，并可直观地监控到各个文件的当前的状态和当前被哪些用户所占用等信息。用户基本上不需要培训，就可使用VSS。
4、Unix的支持：
由于VSS是微软公司被设计用作在WINDOWS操作系统环境下进行文件版本管理的软件,它所管理的文件只能是windows系统能控制的文件。如果要让VSS管理UNIX系统上的文件，必须通过一定的软件支持，令到UNIX文件和目录映射到WINDOWS系统上，变成WINDOWS系统可见和可控制的资源，这样，VSS才可能存取和管理这些文件。
5、VSS基本功能：
首先是项目的概念，所谓的项目是一组存在VSS中的文件（任何类型），可以在项目中或是项目之间进行文件的添加、删除、编辑和共享。一个项目与操作系统的文件夹有很多的相似之处，但它更好地支持文件合并、历史和版本控制。所有的文件存在VSS数据库的项目中，开发组成员不能在VSS中的主备份文件上工作（除了检查和版本比对等特殊情况外）而是VSS为每个成员在各自的工作目录下提供一个拷贝以供工作。尽管在没有工作目录的情况下也可以查看某个文件，但如要真正在VSS管理下工作，就必须要创建一个工作目录。 VSS能够维护一个文件的多个版本，包括一个从不同版本之间进行修改的记录。版本控制包括如下方面：
组内协调—在一般情况下，确保在任何时刻都只有一个成员对某个特定的文件进行修改，这样可以防止文件被其他成员的修改意外更新。当然，VSS管理员可以改变此缺省设置以允许对单个文件同时有多个Checkout，并且仍禁止对他人的修改进行覆盖。
版本跟踪—对老版本的源代码和其他文件进行归档和跟踪，而且这些版本能够被重新得到以便进行bug跟踪或其他目的。
跨平台开发—支持同一代码在跨多个开发平台时的版本控制。
重用或面向对象代码—跟踪哪些程序使用了哪些代码可被重用的模块。
版本控制的涵义在以后的章节中将会得到更进一步的论述。
我们已经知道，VSS 提供版本控制和历史服务，以保证一个文件的每个版本都是可恢复的。VSS用日期/时间戳来记录文件是何时被Checkout或是何时被修改的，它主要有三种方法来跟踪文件和项目的版本：
版本号：这是由VSS维护的内部数码，用户对它没有控制权。每个文件和项目的每个版本都有一个版本号，这些版本号总是一个整数且是递增的。
标签：这些是用户赋给某个项目或文件的某个版本的一个字符串，可以是任何格式的长度不超过31字符的字符串。
日期/时间戳：它给出了一个文件何时最后被修改的信息，或者是一个文件何时被Checkin。VSS同时支持12小时和24小时的时间格式。
工作目录是用户真正对项目文件进行调试修改的地方，当用户Checkout 或提取一个文件时，VSS将该项拷贝到用户的工作目录下，当用户修改了该文件并将其Checkin或提交时，VSS再将它从用户的工作目录拷回到VSS的数据库中。在用户作Checkout时，VSS将会自动管理他的工作目录，诸如创建必要的子目录。而且工作目录可以随时创建或修改。
6 StarTeam
为了使得在软件开发过程中对StarTeam的使用达到最佳效果，需要熟悉StarTeam术语。这些术语一开始看上去可能比较陌生，但很快你就会发现StarTeam模型要比上一代的SCM工具更适合你的商业实践。同时，StarTeam模型所具有的弹性可以让你通过一个单一的、紧密集成的系统实现最终管理你的所有信息资产，源代码和文档。
（一）StarTeam 库
StarTeam系统的中心是StarTeam库，它通过StarTeam Server维护。这个库是一个面向对象的数据存储库，支持对象版本化，链接和配置。任何对象，称为一个StarTeam项，存储在库中，具有它的历史记录，因此该项的前面的状态可以被检索并恢复。StarTeam项可以链接到库中的其他项，因此可以维护不同信息资产之间的关系，并将其用于你的工作过程之中。配置工作就是通过StarTeam提供的库服务执行多个项的创建、维护和恢复工作。
（二） C/S 体系结构
对StarTeam库的访问是通过StarTeam Server进行的，这意味着你的归档文件是完全收到保护的。其他某些产品如PVCS和SourceSafe需要以共享文件的方式才能实现归档库被相关人员访问到，这可能会使得这些归档和它们存储的信息资产同时也会受到计算机病毒的攻击或心怀不满的员工攻击。而使用StarTeam，访问这些归档库的唯一途径是StarTeam Server。所有的StarTeam客户端，不管它是StarTeamWindow GUI、命令行接口、IDE集成、StarDisk或者是使用StarTeam SDK建立的定制应用程序，与StarTeam Server 的通讯都是使用TCP/IP协议。StarTeam，作为Windows平台下的应用程序，也可以使用NetBEUI、 IPX/SPX 或命名管道协议。由于StarTeam已经为Internet使用作了优化，远程用户可以将数据以压缩和加密的方式来访问StarTeam 库。考察StarTeam 的C/S体系结构时的一个最后考虑是StarTeam可以让你选择使用何种数据库，你可以选择MSDE、Oracle、Microsoft SQLServer、Sybase SQL Server,、Informix和IBM DB2等等所有你的DBA所熟悉的工业标准的数据库。从一开始，你就可以挑选适合你的公司标准的数据库来管理你的信息资产。
图1 ： StarTeam 客户机/服务器体系结构
COM/Java
using the StarTeam SDK
StarTeam Client
StarDisk
StarTeam跨平台客户端
IDE - SCC Support
Custom Applications
WebEdition
StarTeam Server
StarTeam
Repository
PVCS Archive
SourceSafe
Archive
（三）面向项目
旧的SCM应用程序如PVCS和SourceSafe，是直接面向单个文件的的。它们称为面向文件的版本控制系统。添加到系统中的每个文件具有它的版本号，存储在一个特定的归档文件中，它们之间的一对一映射与构建应用时的文件放置的位置是无关的。某些产品，如PVCS，并不跟踪记录文件需要检出的目录，而这一信息对正确地重建历史配置文件是必须的。
StarTeam采用面向项目的方法。在这一方法中，源代码和文档文件只是作为组成整个项目的特定项类型。除了具有旧式产品所具有的面向文件的版本控制特性以外，StarTeam还支持对你的项目所需要的其他项进行版本控制，如变更请求、主题、任务、需求和存储这些项的文件夹结构。面向项目的系统还可以让用户根据他们的角色或项目的即时工作需要以不同的方式查看这些项。面向项目的方法是面向文件方法产品中实现特性的超集。
图2：StarTeam是一个面向项目的SCM工具
（四）项
StarTeam模型使用项，如文件、需求、变更请求、主题、任务和审计条目。大多数常用的项是可以版本化的，就是说，StarTeam存储了项的修订历史并允许你查看和比较不同修订的内容。
项也可以被分支，就是说，它们可以由其它项（那些项就成为了它们的祖先）派生出来。
项可能会有几个完全不同的修订历史，而这些修订历史具有共同的祖先。在文本文件情况下，分支项可以与派生出它的原始项进行合并。例如：为新操作系统开发的产品可以基于为第一个操作系统开发的文件为基础开始进行。
分支的概念在文档管理系统中并不多见。然而，这一能力对软件配置管理来说则是基础。开发员经常需要在保持原有开发路径的同时作出或大或小的变更。
StarTeam的协作性的框架体系结构支持多种类型的项，并可以根据客户的需要开发和添加更多的项。下表列出了StarTeam的当前版本所支持的项的类型：
表1：StarTeam 项类型
项类型
是否可版本化
是否可分支
文件
是
是
需求
是
否
变更请求
是
是
任务
是
否
主题
是
否
(五) 项目
StarTeam 使用项目、视图和文件夹来组织存储在StarTeam库中的项。一个StarTeam项目可以认为是紧密相关的视图的集合，每个视图代表一个来自库中的项的配置，可以支持在同一代码上的不同开发阶段。文件夹将项分为组，例如：你可能想要检出某个文件夹下的所有文件以工作于具有特定特性的产品上。对位于不同项目中的项并没有限制，只要项在同一个库中，它们就可以在任何视图间移动或共享，而不管项和视图是位于哪个项目中。
项目提供了一个组织的附加层次，它为视图提供了一个层次结构，同时也提供了在项目级分配访问权限的机会。项目如何使用取决于你。
你可能会为你公司生产的每个产品建立一个项目；或者取决于你构建产品的方式不同，你可能更愿意为产品的每个主要组件创建一个项目。为每个产品组件建立一个单独的项目提供了更多的弹性，因为这样一来每个组件可以被容易地标签化，分支化，并通过它自己的提升模型序列来运转。
（六） 视图
当你打开一个StarTeam项目时，你可以选择默认（或主）视图或者选择另外一个视图。项目的默认视图通常包含用于主要开发的配置。其他视图可以派生于这个视图，也就是说是以它为基础创建出来并具有不同的行为。被选中的视图代表了特定配置下的项的集合。
视图通常具有象下面这样的命名：基线、4.0 维护、4.0中国版、5.0 新开发。它们代表项的配置，对基于同一代码基础上的不同开发基线提供了支持。视图可以被比较和合并。例如：你可能想要将【4.0 维护】视图和【5.0 新开发】视图中的文件最终合并到视图【基线】中。
你可以通过创建和使用视图达到：
1、动态显示你的项目中的源代码和文档的变更。
这是项目中当从【View】菜单中选择【Select Configuration 】命令后当【Current Configuration】选项被选中时，默认（主）视图的典型使用。这一动态视图显示了所有项的变化，可以用于协同开发。
2、引用原始视图中的项的子集。
它们通常称为引用视图。新视图中所作的任何改变也会改变原始视图中的相同项。这是因为子视图包含对原始视图中的原始项的引用，并且当变更发生时不会产生分支行为。通常引用视图具有如下的命名：【开发视图】或【文档视图】，只显示合适的项给相应的人，如开发员或文档员。
3、只读、基于原始视图特定状态的视图。
这通常是为了方便的需要，以便产品发布中的项的修订可以容易地进行定位。例如：一个【4.1发布】视图可以用于在将来重建4.1版本的产品，或者是允许想要购买你的源代码的公司在签订一个临时协议后查看源代码。
4、允许在新视图中对项进行分支
这一视图可以用来修改特定视图状态下的项，而不会影响主开发。它通常通过创建和维护一个维护基线来完成。
视图的一个重要特性是你可以重新配置它，以显示视图在某个更早的时刻点、或特定的视图标签、或与视图相关联的提升状态时的项。使用视图菜单的【Select Configuration】命令回滚视图。回滚视图是只读的，显示项的精确状态，并且不再允许对它们作出改变。
提示：使用【View】菜单的【Select Configuration】命令可以定位截至特定时间检入的文件修订和变更请求的状态，以及需求、主题和任务。
（七）文件夹
每一个StarTeam视图包含一个文件夹层次，用来组织它的项。文件夹反映了视图代表的配置的逻辑组织结构。文件夹通常具有如下这样的命名：源代码、计划、用户手册。它们根据谁需要访问哪些项或者是文件之间的紧密相关性对项进行分组，而文件夹可以被组织为任何层次结构（通常遵循文件被检出时的工作文件夹的结构）。
文件夹在你需要创建共享项的不同配置时也是有用的。你可以在视图之间或视图内部共享文件夹、文件、变更请求、任务和主题，只要这些视图使用同一个服务器配置。文件夹被共享后，两个视图的用户就都可以访问它的内容了，包括子文件夹及其内容。
共享文件夹的设置是设置视图的一个重要部分。例如：假设公司的所有产品都不同程度的使用了公司的公共库，虽然这些库不是由某个产品的开发员来维护，但该产品是基于这个库中源代码的某个版本完成的，并且必须与之一起编译。因此，这些库文件夹应该被共享给该产品的视图。
使用【Ctrl+Drag】来共享文件夹或项从一个位置到另一个位置。通过共享，你创建了一个对原始文件夹或项的引用。除非被共享文件夹或项的行为被设置为【
branch on change】，所有对它的改变将同时修改原始文件夹或项。
被共享文件夹或项的配置（浮动、基于标签、某个提升状态或某个时刻点）初始在两个视图中是同一的。然而，它们可以被分别修改，这意味着共享项在每个视图中可能会有极大的差异，所以在这么作之前请确信对共享有深刻的理解。
被共享的文件夹或项将失去它们在先前视图中的所具有的任何标签。标签不能从一个视图移动到另一个视图。
（八）视图标签
StarTeam视图的另一个特性是视图标签。视图标签用来标识视图中包含项的特定修订的静态配置。当你创建视图标签时，它为视图保存了一个时间戳。视图标签为你保存了它创建时的动态视图的静态快照。
可以通过在标签面板中拖拽标签从项的一个修订到另一个修订来改变与视图标签相关联的项的修订。通常，一个视图标签会包含少量的标签变更，而大多数项修订是由它的时间戳所标识的。
提示：使用视图标签来指示开发里程碑，如每日构建。这可以让你在后来通过使用【View】菜单的【Select Configuration】命令或从命令行使用【CFGL（使用特定标签配置视图）】选项来返回到特定修订的精确配置。
（九）分支视图
软件开发中的一个常见操作是创建一个拥有基于先前状态配置的分支项的新的配置。它通常在用户希望执行对先前构建的系统的维护，但又不希望影响当前的开发时发生。StarTeam通过分支视图对这一活动进行支持。
通过从【View 】菜单中选择【New…】并选中【Permit Items To Branch Within This View】来创建分支视图。选择这一选项将使得新视图具有不同和独立的视图命名空间且新视图中的项能够被分支。你可以选择让每个项一旦发生改变就产生分支或者你可以推迟这一决定并有选择性地在新视图中选择要分支的项。
提示：StarTeam的面向项目的方法允许你你通过【
Branch on Change】选项决定整个配置的分支行为。与面向文件的系统不同，它需要你在每个你想要分支的文件上分别指出，而StarTeam允许你为特定的视图根据想要使用的行为或为该视图作出的工作流程来指出应该发生分支。
对StarTeam模型不熟悉的用户经常会困惑于老视图中的视图标签没有在新视图中发现的事实。这通常是因为他们熟悉面向文件的系统和修订标签的缘故，在这些系统中，修订标签在特定文件归档的所有分支中是同一的。而在象StarTeam的面向项目的系统中，每个配置空间，由一个允许分支的视图所代表，也必须具有一个唯一的视图标签命名空间。这是因为当你创建一个允许分支的新视图时，视图发生了分支。此外，每个视图仅呈现被该视图引用的项的分支历史，而不是该项的贯穿不同分支的整个历史。这使得新视图成为项的独立配置，因此，在原始视图中发现的视图标签不会存在于新视图中。
提示：你无须在每次你需要分支某个项时都创建一个新视图。通过将项从一个文件夹共享(Ctrl+Drag)到另一个文件夹，然后设置行为（Behavior）选项为【
Branch On Change】，你就实现了在同一个视图内创建了一个项的分支。这给了你一个在老的版本控制系统如SourceSafe中发现的相同的基于文件的分支能力。
图3：基于原始基线创建新视图
开发基线
合并 合并
Bug 修理
（十）合并视图
通常，你将来可能想要合并这些独立的分支项回到原始视图或合并到另一个视图。你可以合并不同视图中的项，或者甚至是来自同一视图不同文件夹下的项。StarTeam的视图比较/合并实用程序【Compare/Merge utility】负责执行对文件夹、文件、变更请求、任务和主题的完整比较。
提示：合并视图能力的具备可以使得你实现首先在维护视图中修改项，然后将它们合并到主开发视图中。由于变更请求也可以分支，你可以在维护视图中指示一个变更请求为【FIXED】，而在开发视图中仍然保持为【OPEN】状态。变更请求也可以被合并，因此在维护视图中发现的用来解决该请求的重要信息不会在合并时丢失。
（十一）链接
能链接任意项到任意其他项的能力是StarTeam的一个强大特性。这可以帮助我们记录项之间的关系，如需求文档（以文件的方式存储）、特定的变更描述(以变更请求的方式存储)、设计讨论（以主题的方式存储）和源代码变更（以文件的方式存储）。由于链接也能够被钉（或附着）在被链接项的特定版本上，因此你就具有了一个能提供完整跟踪性的环境。
提示：StarTeam所提供的链接项的能力可以帮助你通过CMM的审计。此外，StarTeam所提供的任务组件也为通过CMM审计提供了有力的支持。
（十二）文件状态
StarTeam更唯一的特性之一是文件信息的灵敏显示。【File Status】状态字段提供了存储在StarTeam库中的文件以及你的工作站上文件之间关系的信息。理解这些状态以及如何使用这些信息可以帮助你大大改进你的生产率。文件状态的值列出如下表所示：
表2:文件状态描述
文件状态
描述
Current
工作站上的文件与视图中的对应文件的顶端修订相同。
Out of
Date
工作站上文件与视图中的对应文件的旧修订相同。
Modified
自从从视图中检出以来，工作站文件已经被修改了，但在视图中没有发现此文件的更新的修订。
Merge
自从从视图中检出以来，工作站文件已经被修改了，并且在视图中存在有此文件的更新的修订。
Missing
工作站上没有发现视图中的此文件。
Not in
View
视图中没有发现工作站中的对应文件。
Unknown
此文件没有从这个视图中检出的记录，但是在视图中存在一个与对应工作文件夹下文件同名的文件。使用【Update Status】命令让StarTeam去将工作站上的文件与视图中的文件的某个版本匹配，并提供一个准确的状态。
当你更新文件的状态时，StarTeam比较工作文件与你检出的修订及和顶端（最近）修订(即三方比较)。 例如：文件列表可能说某个文件为【Current】状态，但可能已经有某个人检入了它的一个拷贝，因此你的真实状态应该为【Out Of Date】。
更新文件状态与更新文件是不一样的。例如：假设某个文件不在你的工作文件夹下，更新状态操作将会让你知道该文件的状态为【Missing】。它并不会为了使得状态不再为【Missing】而为你检出该文件。毕竟，你可能并不想该文件检出到你的硬盘上。通常来说，使用文件的状态来确定文件是否应该被检入、检出、加入或忽略。一旦你熟悉了文件的状态后，你就可以使用它来：
1、检入文件，如果它的状态为【Out Of Date】、【Missing】或【Merge】的话。
2、检出文件，如果它的状态为【Modified】或【Merge】。
3、将文件加入到StarTeam，如果它的状态为【Not In View】。
4、在检出期间，让你提前知道你需要合并工作站文件。
5、运行【Visual Diff】来比较状态为【Out Of Date】的工作文件与顶端修订。这可以让你在检出该顶端修订之前查看由其他团队成员对该文件所作的变更。
6、通过回滚到某个特定的视图标签来从某个更早的构建中检出所有的文件（使用【View－>Select Configuration…】，然后返回到当前配置，通过比较检出的文件与它们的顶端修订来查看自从该构建被创建以来所作的每个修改）。
7、通过增量回滚视图并查找状态为【Modified】的文件来找出引起大问题的小变更。使用【History】来确定文件是什么时候被改变的。
7 Concurrent Versions System
CVS主要有以下特点：
免费：由于是开源项目，自然免费；
跨平台：可在许多平台上使用；
支持并行开发：支持一个文件的树状版本树；
较高的安全性：可以支持只读用户，以及控制用户只能访问指定的目录；
支持版本标签：由于各个文件的版本不同，因此采用版本标签进行统一；
灵活的批量签出功能：支持按照版本标签、时间等签出代码；
以及其他基本的功能：
签入通告功能；
签出任意版本、版本比较等功能；
CVS与其他商业产品的对比：
优点在于：免费；功能可持续改进；效率高；C/S结构效率较高；安全性较高；具有版本标签功能。
缺点：不支持自动创建目录；对二进制文件支持较差。
8 FireFly
FireFly软件配置管理系统具备以下主要功能：
l 版本控制：跟踪每一个变更的创造者、时间和原因，从而加快问题和缺陷的确定，同时能够简单、明确地重现软件系统的任何一个历史版本。
l 并发开发支持：因开发和维护的原因，要求能够实现开发人员同时在同一个软件模块上工作，同时对同一个代码部分作不同的修改，即使是跨地域分布的开发团队也能互不干扰，协同工作，而又不失去控制。
l 项目分支管理：能够同时支持同一项目的多个版本的并行开发，同时在必要的时候可以将多个并行的版本进行合并。
l 与CRM（变更请求管理系统）集成：能够与DTS系统一起协同工作，协调工作流程。
l 支持多种平台：可以工作于现今流行的各种操作平台。
l 支持多种文档格式：不仅能够支持文本格式的文档，还可以支持二进制格式。
l 支持变更集：能够把一组关联的改动当作一个变更的集合来处理，而不是单单处理一个一个单独的改变。
l 支持原子级事务：能够把系统操作当作不可分割的动作来处理，保持系统的一致性。
l 支持Notification：支持在系统某个动作发生的同时（如检入和检出），可以触发用户自定义的一些动作（如以Email方式通知某人等）
l 支持异地开发：能够同步在物理上分布的两个SCM服务器的内容。
l 支持人员权限的设定：支持对开发相关人员的权限设定，使得所有的操作都处于系统的控制之下。
l 易于扩展，支持企业级应用：在开发规模扩大时仍能保持良好的性能，并且很容易随着开发规模的扩大进行相应的扩充。
l 易于使用：概念清晰，操作简便。
