VSS、CVS、SVN和ClearCase等配置工具的评估和比较
VSS、CVS、SVN和ClearCase等软件测试 配置工具的评估和比较1概述
Visual SourceSafe：微软的版本控制工具，仅支持Windows操作系统。虽然简单好用，但是仅适用于团队级开发，不能胜任企业级的开发工作。
Clearcase：IBM旗下Rational公司(2003年被IBM收购)的一款重量级的软件配置管理(SCM， SoftwareConfiguration Managemen)工具。与CVS和VSS不同，Clearcase涵盖的范围包括版本控制、建立管理、工作空间管理和过程控制。从最初的软件配置计划，到配置项的确立，从变更控制到版本控制，Clearcase贯穿于整个软件生命周期。 Clearcase支持现有的绝大多数操作系统，但它的安装、配置、使用相对较复杂，并且需要进行团队培训。
CVS：Concurrent Versions System。CVS 是有着三十年以上的时间的考验。CVS是开放源代码软件世界的一个伟大杰作，由于CVS功能强大，跨平台，支持并发版本控制，而且免费，所以它在全球中小型软件企业中得到了广泛使用。CVS最大的遗憾就是缺少相应的技术支持，许多问题的解决需要自已寻找资料，甚至是研究源代码。CVS是一个典型的服务器/客户端软件，有UNIX版本的CVS 、Linux版本的CVS和WINDOWS版本的CVS。CVS支持远程管理，项目组分布开发时一般都采用CVS。
SVN：Subversion。采用了更先进的分支管理系统，它的设计目标就是取代CVS，CVS纵然易用，但也有一些与生俱来的缺点，比如CVS不支持文件改名，只对文件控制版本而没有针对目录的管理等。之后CVS 的创始人之一在其现任公司的资助下开发了SVN，用以针对CVS 的一些弱点进行改进。
2主要功能说明
CVS纵然是一个老牌的工具产品，并也对开源事业有贡献，但CVS的命令行操作着实让一些使用者头疼。在对一个特定版本的文档Check in的时候，需要输入一长串的路径名、文件名。在操作易用性上与CVS形成对比的是微软家族的VSS。作为微软的产品，在图形界面化操作上自不用多言，但VSS只能适用于小团队的开发工作。VSS是很好的入门级工具，但它的一些功能太过于―入门‖，在验证密码、保存密码这些基本功能上处理的不尽人意。适用于大型软件开发的有―中坚级‖的Clearcase，用它来管理一些小型的项目管理有些―大材小用‖。Clearcase支持目录版本管理、异地团队开发、视图、多服务器等强大功能，所以一些大公司把它做为一、二级产品管理用，但同样它的价格也不菲。CVS是开源的，免费的，更何况它还有一个理想的替代者——SVN。SVN的设计专门针对CVS的问题作了改进,命令的设计更为合理,对二进制文档和目录这样的数据加强了控制能力,并且吸收了VSS的lock-modify-update(release)的模式和modify-merge模式的优点这两种方式在一定程度都支持并作了优化,没有提高使用的复杂度。由于SVN的设计结构很好,所以很容易为它开发客户端,还有WEB模式的,可以远程管理,支持RSS更改订阅。 功能 名称
Internet网络和远程管理 并行开发
跨平台开发
操作的便利性
信息安全性 VSS
最新发布版本VSS8.0可支持此功能 最新发布版本VSS8.0支持此功能 仅支持Windows 操作系统
安装、配置、使用均较简单，很容易上手使用
安全性不高，基于文件系统共享实现对服务器的访问，需要共享存储目录，这样用户可以对VSS的文件夹执行删除操作。 CVS
支持，速度一般 支持
支持几乎所有的操作系统
安装、配置较复杂，但使用比较简单，只需对配置管理做简单培训即可
安全性高，CVS服务器有自己专用的数据库，文件存储并不采用 ―共享目录‖方式，所以不受限于局域网。 SVN
相比CVS，更加适合基于互联网协作开发的团队，速度也更快 相比CVS，能够保证所有的修改都入库生效 同上 同上 同上
ClearCase
速度最快，且不受网络连接带宽的限制、防火墙以及安全问题的影响。 支持
支持常见的平台
安装、配置、使用相对较复杂，需要进行团队培训
安全性不高，采用C/S模式，需要共享服务器上的存储目录以供客户端访问 2.1
Internet网络访问和远程管理
VSS、CVS和SVN都提供基于Web的界面，用户可以通过浏览器执行配置管理的相关操作，即通过这样的方法来实现对异地开发的支持。但是相对于CVS，SVN采用统一的二进制差异算法，所以消耗更少的网络带宽，因此更加适合基于互联网（或广域网）进行协作开发的地理上分布的团队，即版本服务器集中、单一；客户端可广泛分布。
其实上述实现方法有太多的局限性，例如网络（Internet）连接带宽的限制、防火墙以及安全问题等。真正意义上的异地开发支持，是指在不同的开发地点建立各自的存储库，通过工具提供同步功能自动或手动同步。这样做的好处是与网络无关，即便各个开发地点之间没有实时连通的网络，也可以通过E-Mail 附件等其它方式将同步包发给对方，实现手动的同步。而ClearCase就能实现这样的功能。
值得说明的是，在不同开发点建立各自存储库的方式，主要适用于两个或两个以上位于不同地点的开发团队协作开发的情况。如果仅是采用虚拟团队合作的方式，开发人员以个体的形式散落在不同地方，则更适合通过Internet 直接操作远程的配置管理服务器。 2.2
并行开发支持
在团队协作开发过程中，有两种主要的模式：集体代码权和个体代码权。采用集体代码权模式进行开发时，一段代码可能同时会被多个开发人员同时修改；而采用个体代码权模式进行开发时，每一段代码都始终被一个开发人员独享，别人需要修改时也要通过该开发人员完成。
而配置管理软件针对这一情况，也采用了不同的策略：Copy-Modify-Merge(拷贝、修改、合并)的并行开发模式、Check ut-Modify-Check in（签出、修改、签入）的独占开发模式。在并行开发模式下，开发人员可以并行开发、更改代码，并能够自动检测到代码冲突，并自动合并，或提示开发人员手动解决。 VSS最新发布版本8.0可支持并行开发模式，其它三种工具也都可支持。
CVS 采用线性、串行的批量提交，即依次地，一个接一个地执行提交，每成功提交一个文件，该文件的一个新的版本即被记录到版本库中，提交时用户提供的日志信息被重复地存储到每一个被修改的文件的版本历史中。但是当任何原因造成批量操作的中断时（典型原因包括：网络中断、客户端死机等），版本库往往处于一个不一致的状态：原本应该全部入库的文件只有一部分入库，很有可能版本库中的最新版本不能顺利编译，更为严重的是，随着其他的用户执行cvs update 操作，该不一致性将迅速在开发团队中扩散，从而严重影响团队的开发效率，并存在质量隐患。另外，假如该批量提交的中断没有被及时发现，开发团队往往要花更多的时间进行软件调试和排错。
SVN彻底消除了CVS的以上弊端。无论批量提交包含多少文件修改，只有当全部文件修改都成功入库，该提交才变得有效，才对其他用户可见；否则，无论任何原因造成中断，SVN 都会自动执行―回滚‖（rollback）操作。换一个说法，SVN保证所有的修改要么全部入库生效，要么一个也不入库，即对版本库不作任何的修改。这就是SVN 的原子性提交（atomic commit）。
ClearCase可以很容易的产生分支，也可以很容易的将不同分支进行合并。这样一来，即便某一部分的工作被冻结或加锁，开发者仍然可以继续自己的工作（如：在软件集成期）。在这种情况，开发者可以在分支上工作，ClearCase的自动化操作和图形归并工具可以很容易的重新集成新的工作。 2.3
跨平台开发支持
如果企业需要从事多个不同平台下的开发工作，就需要配置管理工具能够对跨平台开发提供支持，否则势必会给开发、测试、发布等各个环节带来不便，将使大量的时间被浪费于代码的手工上传、下载中。 VSS仅支持Windows操作系统。
CVS、SVN和ClearCase支持几乎所有的操作系统和平台。但是CVS和SVN的服务器端在Unix, Linux环境下运行会更稳定可靠。 2.4
开发操作使用的便利性VSS安装、配置、使用均较简单，很容易上手使用。
CVS和SVN安装、配置较复杂，但使用比较简单，只需对配置管理做简单培训即可。 ClearCase安装、配置、使用相对较复杂，需要进行团队培训，需投入成本大概四万元。 2.5
信息安全性VSS它是基于文件系统共享实现对服务器的访问，需要共享存储目录，这样用户可以对VSS的文件夹执行删除操作，安全性不高。
CVS和SVN服务器有自己专用的数据库，文件存储并不采用 ―共享目录‖方式，所以不受限于局域网。安全性较高。
ClearCase采用C/S模式，需要共享服务器上的存储目录以供客户端访问，安全性不高。 性能详述 3.1
VSS优点：操作简单，容易掌握；权限划分可到文件夹级，有Read、CheckOut&&CheckIn、Add/Rename/Delete、Destroy四种权限级别。
缺点：权限管理基于文件共享形式，只能从文件夹共享的权限设定对整个库文件夹的权限，而且必须要有可写权限；版本管理和分支管理只能靠人为的手工设置；版本发行时，只能手工挑选对应的版本文件进行发布。 最新版本VSS8.0主要增加了以下功能： Ø 支持并行开发 Ø
支持基于Internet的远程访问模式 Ø
分布式团队协作增强 3.2
CVSCVS 诞生于 1986 年，当时作为一组 shell脚本而出现；1989年3月，Brian Berlinor用C语言重新设计并编写了CVS的代码；1993年前后，Jim Kingdon最终将CVS设计成基于网络的平台，开发者们能从Internet任何地方获得程序源代码。截至目前最新版本是2004年12月13日发布的 功能介绍 Ø
代码统一管理，保存所有代码文件更改的历史记录。对代码进行集中统一管理，可以方便查看新增或删除的文件，能够跟踪所有代码改动痕迹。可以随意恢复到以前任意一个历史版本。并避免了因为版本不同引入的深层BUG。 Ø
完善的冲突解决方案，可以方便的解决文件冲突问题，而不需要借助其它的文件比较工具和手工的粘贴复制。 Ø
代码权限的管理，可以为不同的用户设置不同的权限。可以设置访问用户的密码、只读、修改等权限，而且通过CVS ROOT目录下的脚本，提供了相应功能扩充的接口，不但可以完成精细的权限控制，还能完成更加个性化的功能。 Ø
支持方便的版本发布和分支功能。CVS在服务器端维护代码文档库，不同的开发者在本地机器上建立对应代码树，并利用CVS保持本地代码文档同代码文档库的一致。当由于多个开发者对文件的同时修改造成本地与库中的代码文件冲突时，CVS报告并协助解决冲突代码的合并问题。普通开发者（非管理员）对CVS的使用流程。 3.3 SVN
SVN 是一个自由/开源版本控制系统，它管理文件和目录可以超越时间。一组文件存放在中心版本库，这个版本库很像一个普通的文件服务器，只是它可以记录每一次文件和目录的修改，这便使你可以取得数据以前的版本，从而可以检查所作的更改。从这个方面看，许多人把版本控制系统当作一种―时间机器‖。
SVN 可以通过网络访问它的版本库，从而使用户可以在不同的电脑上使用。一定程度上可以说，允许用户在各自的地方修改同一份数据是促进协作。由于所有的工作都有历史版本，你不必担心由于失去某个通道而影响质量，如果存在不正确的改变，只要取消改变。 SVN的历史：
早在2000 年，CollabNet,Inc. (http://www.collab.net/) 开始寻找CVS 替代产品的开发人员，CollabNet 提供了一个协作软件套件CEE (CollabNet EnterpriseEdition)，它的一个组件是版本控制系统。尽管CEE 在初始时使用CVS 作为其版本控制系统，但是CVS 的局限性在一开始就很明显，CollabNet 知道迟早要找到一个更好的替代品。遗憾的是，CVS成为了开源世界事实上的标准，因为没有更好的产品，至少是没有可以自由使用的。所以CollabNet 决定写一个新的版本控制系统，建立在CVS 思想之上的，但是修正其错误和不合理的特性。
2000 年2 月，他们联系OpenSource Development with CVS(Coriolis, 1999)的作者Karl Fogel，并且询问他是否希望为这个新项目工作，巧合的是，当时Karl 正在与朋友JimBlandy 讨论设计一个新的版本控制系统。在1995 年，他们两个曾经开办一个提供CVS支持的公司Cyclic Software，尽管他们最终卖掉了公司，但还是天天使用CVS 进行日常工作，在使用CVS 时的挫折最终促使他们认真地去考虑如何管理标记版本的数据，而且他们当时不仅仅提出了―SVN‖这个名字，并且做出了SVN 版本库的基础设计。所以当CollabNet 提出邀请的时候，Karl 马上同意为这个项目工作，同时Jim 也得到了他的雇主，RedHat 软件赞助他到这个项目并提供了一个宽松的时间。CollabNet 雇佣了Karl 和Ben Collins Sussman，详细的设计从三月开始，在Behlendorf 、CollabNet、Jason Robbins 和 Greg Stein（当时是一个独立开发者，活跃在WebDAV/DeltaV 系统规范阶段）的恰当激励的帮助下，SVN 很快吸引了许多活跃的开发者，结果是许多有CVS 经验的人们很乐于有机会为这个项目做些事情。
最初的设计小组固定在简单的目标上，他们不想在版本控制方法学中开垦处女地，他们只是希望修正CVS，他们决定SVN 匹配CVS 的特性，保留相同的开发模型，但不复制CVS 明显的缺陷。尽管它不需要成为CVS的继任者，它也应该与CVS 保持足够的相似性，使得CVS 用户可以轻松的做出转换。
经过14 个月的编码，2001 年8 月31 日，SVN 自己能够―成为服务‖了，开发者停止使用CVS 保存SVN 的代码，而使用SVN 本身。
当CollabNet 开始这个项目的时候，曾经资助了大量的工作（它为全职的SVN 开发者提供薪水），SVN 像许多开源项目一样，被一些激励知识界精英的宽松透明的规则支配着。CollabNet的版权许可证完全符合Debian的自由软件方针，也就是说，任何人可以自由的下载，修改和重新发布，不需要经过CollabNet 或其他人的允许。
SVN和CVS功能性对比： 一、SVN包含绝大部分CVS功能