VSS、CVS、SVN和ClearCase等配置工具的评估和比较

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功能 SVN 作为CVS 的重写版和改进版，其目标就是作为一个更好的版本控制软件，取代目前流行的CVS。SVN 的主要开发人员都是业界知名的CVS 专家。SVN支持绝大部分的CVS 功能/命令；SVN 的命令风格和界面也与CVS 非常接近。当然，不同的地方正是对CVS 的改进。 二、全局性的版本编号 一个新的版本，并得到一个自增量的版本号N+1，该版本号并不针对某个特定的文件，而是全局性的、针对整个版本库的。因此，我们可以将SVN 的版本库看作是一个文件系统或文件目录树的数组。 从技术的角度来说，在SVN 中，“文件foo.c 的第5 版本”这个说法是错误的；正确的说法应该是：”文件foo.c 在版本库被修改了5 次，即执行5 次commit 后是什么样子？”。显然，在SVN 中，版本库被修改5 次后foo.c 的内容，和被修改了6 次后foo.c 的内容很可能完全一样，因为版本库的第6 次修改很可能只修改了版本库的其他部分，而并没有对foo.c 的进行修改。相反，在CVS 中，文件foo.c 的第1.1 版本和第1.2 版本总是不同的。 SVN 的全局性版本编号为SVN 带来了诸多的优势：如对目录或文件执行拷贝，无论涉及多少文件，SVN 不需要对单个文件依次执行拷贝命令，仅仅需要建立一个指向相应的全局版本号的一个指针即可。 三、目录的版本控制 CVS 只能对文件进行版本控制，不能对目录进行版本控制，因此CVS 没有任何关于文件“移动”（move） 操作的概念。当人为进行文件移动操作时，CVS 只能注意到，一个文件在一个位置被删除了，而在一个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。设置 CVS 存储库时，必须非常谨慎地为每个文件选择准确的位置，因为在设置之后，几乎就要一直使用这个位置了。 同样由于CVS 不记录目录的版本历史，CVS 不支持对文件的“重命名”（rename），人为的对文件进行重命名会使得命名前后的文件失去历史联系，而记录历史本来是版本管理的主要目的。 还有，CVS 不支持对文件的“拷贝”（copy），人为的拷贝对CVS 而言，只能看到新的文件的增加，而不能记录拷贝源文件和目标文件之间的联系。 综上所述，缺乏对文件“移动”、“重命名”、“拷贝”的支持的根源在于CVS 不能记录目录的版本历史，而这些操作在当前的软件开发过程中经常发生，这正是SVN被开发并取代CVS 的主要原因之一。 SVN 将目录作为一类特殊的文件来处理（事实上，从文件系统的角度来看，目录确实是一类特殊的文件，当目录中的子目录/文件被删除、重命名、或新的子目录/文件被创建时，目录的内容将发生改变）。因此，SVN 象记录普通文件的修改历史一样记录对目录的修改历史，当发生文件/目录的移动、重命名或拷贝操作时，SVN 能够准确记录操作前后的历史联系。同样，象对文件的不同历史版本进行比较一样，SVN支持对目录的不同历史版本的比较，清晰展现目录的变化历史。 四、原子性提交 从使用者的角度来看，CVS 和SVN 都支持对多个文件修改的批量提交，但二者在实现方式上存在本质的区别。 CVS 采用线性、串行的批量提交，即依次地，一个接一个地执行提交，每成功提交一个文件，该文件的一个新的版本即被记录到版本库中，提交时用户提供的日志信息被重复地存储到每一个被修改的文件的版本历史中。 CVS 串行批量提交模式的弊端在于 － 当任何原因造成批量操作的中断时（典型原因包括：网络中断、客户端死机等），版本库往往处于一个不一致的状态：原本应该全部入库的文件只有一部分入库，很有可能版本库中的最新版本不能顺利编译，更为严重的是，随着其他的用户执行cvs update 操作，该不一致性将迅速在开发团队中扩散，从而严重影响团队的开发效率，并存在质量隐患。另外，假如该批量提交的中断没有被及时发现，开发团队往往要花更多的时间进行软件调试和排错。 CVS 即使在批量提交不发生中断时也会造成不一致：假设用户A 启动一个需要较长时间才能完成的批量提交；与此同时，用户B 执行cvs update 操作。此时，用户B 很有可能得到一个不一致的更新，即用户B 通过“更新”操作，得到用户A 的部分修改文件。 SVN 彻底消除了CVS 的以上弊端。无论批量提交包含多少文件修改，只有当全部文件修改都成功入库，该提交才变得有效，才对其他用户可见；否则，无论任何原因造成中断，SVN 都会自动执行“回滚”（rollback）操作。换一个说法，SVN 保证所有的修改要么全部入库生效，要么一个也不入库，即对版本库不作任何的修改。这就是SVN 的原子性提交（atomic commit）。 由于SVN 的原子性提交特性和全局版本编号方式，当提交成功完成时，一个唯一的、新的全局版本编号产生，而提交时用户提供的日志信息与该新的版本编号关联，只进行一次存储（区别于CVS 的按文件重复存储）。 五、支持变更集概念 由于SVN 的所有提交是原子性的，每次成功提交形成的唯一的全局版本号对应此次批量提交的所有文件修改，也就是说，一个SVN 版本号其实对应了一个逻辑上的变更集（change set），该变更集可能对应于对一个BUG 的修复，或者对应于对一个已有功能的改进，或者对应于一个新功能的实现。可以说，变更集是一个软件开发活动的逻辑结果，该变更集可以通过其对应的版本号在软件开发的其他过程中（如软件合并/集成过程，软件发布管理，变更管理系统，缺陷追踪系统）被引用。因此，SVN 将版本管理从单纯的、单个的文件修改的层次通过逻辑上的抽象，上升到更便于理解和交流的开发活动的层次。 六、差异化的二进制文件处理 由于历史原因，CVS 主要是为早期的程序员设计的，CVS 能够有效处理文本文件（或ASCII文件，源代码文件），可以对文本文件进行差异化的存储、新旧版本的比较，文件合并等；但对于二进制文件，CVS 则明显力不从心。在CVS 的版本库中，对于二进制文件的历史版本，CVS 唯一能做的就是对不同的版本进行独立的、冗余的存储，哪怕版本之间其实只存在微小的差异。举例而言，一个10M 的二进制文件（照片、图形文件、机械设计文件、电子设计文件）假如每周修改一次，无论每次修改的大小，一年下来，仅该文件就要消耗500M 以上的存储空间。而且，客户端每次获取该文件的新版本都要消耗10M 的网络流量。 对于目前的开发团队，无论是软件开发，Web 站点的开发，手机等电子产品的研发，需要进行版本管理的不仅是源代码等文本文件，还需要管理需求文档、设计文档、测试文档、用户手册，图形图像文件，机械/电子设计文件等诸多的二进制文件，CVS 显然不是一个好的选择。 与CVS 不同，SVN 采用统一的二进制差异算法（binary differencing algorithm），即对文本文件和二进制文件采用相同的差异比较算法，并以相同的方式在版本库中进行存储：每次提交后版本库中只存储相对于先前版本的差异，从而可以节省大量的存储空间。 该二进制差异算法不仅应用在版本的存储上，更为重要的是，SVN 对二进制文件与文本文件一视同仁，当客户端需要获取新的版本时（如执行svn update），在网络上只有版本的差异被传输，从而大大减少对网络带宽的消耗。更多细节参见“七、双向的差异化－压缩网络传输”。 七、 双向的差异化－压缩网络传输 如上所述，CVS 对二进制文件不能进行有效的差异化处理。对于文本文件，CVS 仅仅支持单向的差异化传输：从CVS 服务器到客户端的传输是差异化的，即执行cvs update 时，只有差异的部分从服务器传输到客户端；而当执行cvs commit 时，无论代码变化多少，CVS 都需要从客户端向服务器完整传输被修改文件的全部内容，不能只传输差异。 相反，无论是文本文件还是二进制文件，SVN 都进行双向的差异化传输，并且差异化内容还要进行压缩/解压缩的过程：在服务器端获取差异显而易见，与CVS 类似；SVN 在客户端获取差异的秘密在于— SVN 在客户端的工作拷贝中隐含了每个文件的一个“只读的、干净的”副本（该副本隐藏在隐含目录.svn 里，通常不可见，该副本还有更多的妙用，参见“十二、更多的本地/离线操作”），通过比较用户在客户端的修改和该隐含的副本，SVN 获取需要真正传送到服务器的差异，并对差异进行压缩后才进行网络传输。 对CVS 而言，操作的成本（网络带宽消耗是最大的操作成本）与被修改的文件的大小成比例，而与修改本身的大小无关；对SVN 而言，操作成本只与修改本身的大小成比例，而与被修改的文件的大小无关。因此，与CVS 相比，SVN 消耗更少的网络带宽（以客户端的存储空间换取更少的带宽消耗在目前的计算环境下应该是个相当不错的选择！）。SVN 更加适合基于互联网（或广域网）进行协作开发的地理上分布的团队—版本服务器集中、单一；客户端广泛分布。

八、高效、快捷创建分支和基线 CVS 和SVN 都支持分支（branch）和基线（tag），通过分支与合并，可以有效支持大项目的并行开发模式；通过基线管理，可以准确标识一组文件的版本，有效进行软件发布管理和必要时的历史回溯。 但CVS 和SVN 在实现分支和基线的方式上存在很大的不同。CVS 在创建分支的时候，需要对所有进行分支的文件进行依次的操作，因此分支的建立成本（主要是建立分支所需的时间，或消耗的计算资源）与参与分支的文件数量成比例，项目越大，版本库越大，文件越多，分支的建立成本越高；基线（tag）的建立与此类似。 SVN 的分支和基线是通过执行“拷贝”来建立的：回想一下在没有引入版本管理工具的时候我们是如何进行所谓的“分支”和“基线”管理的？答案显然是“拷贝” — 我们通过“拷贝”或“备份”来建立基线；同样，为支持多个开发人员可以同时进行开发，我们为每个开发人员创建一份“拷贝”。由此看来，SVN 通过“拷贝”来建立分支和基线显得非常自然，有点“返朴归真”的意思。 由于SVN 的全局版本号特性，SVN 中分支或基线的创建过程，或SVN中的“拷贝”过程，真正的操作是在版本库中创建一个到某一全局版本号的指针（pointer），不再需要针对众多的单个文件依次执行操作。因此，该操作的成本为一个很小的常数，与项目大小，版本库大小，文件数目的多少无关；并且，分支或基线的建立不需要进行版本的冗余存储，新建立的分支或基线基本不占用版本库空间，分支的后续存储空间的开销也只与修改的大小有关。 九、集成Apache Web Server，提供更多的特性 SVN 通过与Apache Web Server 的集成，可以提供基于http/https 协议的版本库访问机制，从而支持SVN 跨越防火墙的安全访问。除此以外，SVN 还可以利用更多的Apache 特性，包括但不限于：Apache 丰富的用户认证机制（包括通过LDAP服务器如Windows Active Directory 服务器的用户认证），基于目录路径的精细粒度的访问控制，对传输的网络流量进行压缩/解压缩，浏览版本库目录结构等等。 十、支持WebDAV WebDAV（Web-based Distributed Authoring and Versioning）是一种基于 HTTP 1.1 协议的通信协议.它扩展了HTTP 1.1，在GET、POST、HEAD 等几个HTTP 标准方法以外添加了一些新的方法，使应用程序可直接对Web Server 直接读写，并支持写文件锁定(Locking)及解锁(Unlock)，还可以支持文件的版本控制。 Microsoft windows2000/XP 及IE, Office 还有Adobe/MicroMedia 的DW 等都支持WebDAV，这又大大增强了Web 应用的价值，以及效能。对于需要大量发布内容的用户而言，应用WebDAV 可以降低对CMS 系统的依赖，而且能够更自由的进行创作。上传、下载变得轻松自如。 SVN 通过与Apache Web Server 的集成，支持WebDAV 协议，使得业务用户（business users）或非技术用户在不安装任何版本管理客户端的情况下轻松访问SVN 版本库，不改变业务用户已有使用习惯，支持分布的业务用户对文档的评审、修改并实现版本控制，真正将软件开发的生命周期从开发/技术团队扩展到项目的全部干系人（stakeholder），避免通过电子邮件传递文档的混乱与无序、通过Windows 操作系统共享造成的安全漏洞、病毒攻击、历史版本被覆盖或丢失、审计困难等诸多典型问题。 十一、更好的冲突标识与处理 CVS 和SVN 都支持通过分支与合并进行并行开发，并可以自动检测到合并时的冲突（conflicts），并在合并结果中以<<<<<< … >>>>>>标识合并的冲突部分。 在CVS 中，经常会出现由于用户的疏忽（如，没有注意到冲突，或没有完全处理好冲突）而将仍然带有<<<<<< … >>>>>>冲突标识符号的文件直接进行提交（commit），从而在版本库中产生垃圾版本。 SVN 有效解决了CVS 的以上问题：SVN 记录并保持文件的冲突状态，只有当用户明确执行svn resolved 命令后，该冲突状态标识才被复位，该文件才能被提交，从而大大减少了将仍然带有<<<<<< … >>>>>>冲突标识符号的文件直接进行提交的可能性。 十二、 更多的本地/离线操作 众所周知，CVS 客户端的工作拷贝中包含了一个隐含目录CVS，该目录中记录了客户端需要的一些管理信息；与此类似，SVN 的客户端工作拷贝中也包含了一个隐含目录.svn，该目录中同样记录了客户端需要的一些管理信息，如版本库URL，当前访问版本号等。 与CVS 不同的是，SVN 的.svn 目录中还包含了工作拷贝中每一个文件的一个“只读的、干净的”副本。正是由于该副本的存在，使得SVN 与CVS 相比，可以执行更多的本地/离线操作，即某些操作不需要访问版本库服务器，因此不需要存在从客户端到服务器的网络链接，当然也不消耗任何网络带宽，这进一步增强了SVN 对广域网的友好支持。 SVN 的以下命令可以进行离线操作： svn status － 显示工作拷贝上的本地修改概况； svn diff －显示工作拷贝上的本地修改细节，比较修改前后的内容； svn revert － 撤销工作拷贝上的本地修改； 十三、 对符号链接进行版本管理 在Unix 文件系统中，符号链接（symbolic links，包括硬链接和软链接）是一种重要的文件系统元素。CVS 不能对符号链接进行版本管理；SVN 则可以对符号链接进行版本管理。 十四、 元数据管理 与CVS 相比，SVN 增加了元数据（metadata）管理机制。即可以对版本库中的文件或目录附加任意的“属性”（property），并记录属性的变化历史，也就是对元数据进行版本管理。一个SVN 属性是一个“属性名称/属性值”的二元组，如“BugNumber= 100”就是一个属性，可以将该属性附加到版本N 上，以说明版本N 改正了编号为100的BUG。 SVN 元数据的目的是提供附件的信息以满足流程或过程自动化的需要，以增强SVN 的管理能力和自动化程度。SVN 自身就通过“属性”来存储一些特殊的信息。一个使用SVN 元数据的例子：可以在一些批处理的脚本程序或SVN的钩子程序（hooks）中创建、访问、修改“属性”元数据来满足流程自动化的要求。 非功能性对比：性能、可用性、可扩展性： 一、层次化的体系架构 尽管CVS 是开放源代码的，但同样由于历史的原因，即使是CVS 的主要开发和维护人员也认为目前CVS 的代码很难进行后续的维护和扩展，而这正是SVN 被重写的主要原因之一。     SVN 具备设计良好的三层体系架构 － 版本库层（Repository Layer），版本库访问层（Repository Access Layer），和客户端层（Client Layer）。 SVN 在层与层之间定义了明确的接口，使之具备更好的扩展性。 SVN 的体系架构如下图所示： 二、可选的后台版本库实现 CVS 的版本库以普通的文件系统方式实现；SVN 的版本库支持两种实现方式：以嵌入式的数据库BerkeleyDB 实现，或，采用特定格式的普通文件系统FSFS 方式实现。二者在可扩展性、性能、备份/恢复等方面各有特色，用户可以根据自身的实际需求进行灵活的选择。 三、更好的性能和可用性 由于CVS 主要针对文本文件的版本处理而设计，CVS 在处理大文件时存在性能和可用性问题 － CVS 在执行提交时需要向服务器传输整个文件的内容。一方面，处理文件的大小受制与客户端可用内存的多少；另一方面，大文件的处理将占用服务器的绝大部分资源，可能导致服务器性能严重下降，使得其他用户无法访问和工作，甚至出现服务器宕机。 SVN 从设计上根本杜绝了CVS 的上述问题。SVN 能够处理任意大小的文件，包括比可用内存还大的文件，并且无论是在客户端还是在服务器端，SVN 始终只需要一个相对小、相对固定的内存开销 － SVN 能够进行双向的差异化/压缩的网络传输，而且无论差异的大小，SVN 始终以大小固定的管道方式或流模式（stream）执行网络传输。事实上，由于客户端参与了差异的计算，SVN 让大量的客户端一起分担服务器的处理负荷，从而从整体上提高了SVN 的性能和可用性。 四、可解析、格式规范的输出 从用户的角度来看，命令行方式下的SVN 的风格与CVS 的风格非常类似，但SVN 还是做了重大的改进：SVN 命令行方式下的输出经过了“认真、仔细”的设计，使得其输出不仅便于“人”的阅读和理解，同样便于程序脚本的自动化解析，或者说，适合“机器”的阅读和理解。因此，在SVN 下编写批量的自动化脚本程序更加容易，脚本工作更加可靠。 五、更好的本地化、国际化支持 SVN 从一开始就充分考虑到本地化（ Localization ， L10N ） 、国际化（Internationalization， I18N）方面的需求，无论是对多字节文件，多字节文件名的版本管理，还是客户端工具的用户界面/输出提示信息本地化等，SVN 都比CVS 做得更好。 六、丰富的可选组件 ·SVN 有大量的客户端工具和服务器工具可供选择，主流的SVN 客户端有： ·SVN 命令行客户端 － 支持各种操作系统平台 ·TortoiseSVN – Windows 下与资源管理器紧密集成的图形界面客户端 ·Subclipse – SVN 的Eclipse 插件 七、支持从CVS到SVN的版本库迁移 由于SVN 与CVS 的诸多共性和历史渊源，现有的CVS 版本库可以很方便地转换成（或迁移到）SVN 版本库格式，使得在保留原来的CVS 历史版本信息的同时在SVN 下继续使用。现成的转换工具有：cvs2svn，该转换工具由SVN 的核心开发团队开发和维护。 3.4 ClearCase优点：功能强大，版本管理和分支管理完全自动化。 　　缺点：权限管理只能是基于Windows的用户安全权限管理。 随着软件团队人员的增加，软件版本不断变化，时间的紧缺，多种平台的复杂环境，使得 ClearCase所拥有的特殊组件已成为当今软件开发人员（工程人员和管理者）所必须的工具。分布式操作使得基于Client/Server的运算结构跨越于网上客户机和服务器，ClearCase的先进功能直接解决了原来开发团队所面临的难以处理的问题。 软件开发所面临的问题包括：对当前多种产品的开发和维护，保证产品版本的精确，重建先前发布的产品，加强开发政策的统一和对特殊版本需求的处理。通过解决这些问题，ClearCase用资源重用的方法帮助开发团队使他们所有的软件建立得更加可靠。 Rational公司的ClearCase是软件配置领域的先导，它主要基于Windows和UNIX的开发环境。它提供了全面的配置管理──包括版本控制、工作空间管理、建立管理和过程控制，而且无须软件开发者改变他们现有的环境、工具和工作方式。　 ClearCase的核心功能是版本控制，它是对在软件开发进程中一个文件或一个目录发展过程进行追踪的手段。ClearCase对所有文件系统对象（包括文件、目录和链接）增强了版本控制系统功能。可定版本的文件包括源代码、可执行文件、位图文件、需求文档、设计说明、测试计划、和一些ASCII和非ASCII文件。目录的版本记录了整个组织基础资源的发展状况，包括源文件的建立、重新命名、重新构造和删除操作等。 这种版本控制系统提供了先进的版本分支和归并功能用于支持并行开发。 3.4.1 控制任何文件的版本 ClearCase可以对每一个软件组件或元件的版本进行维护和控制。ClearCase也可以维护一个非文本文件、目录和工具的版本。正如：它可以管理库文件、编译器、需求文档、 测试包和数据库而不仅仅是源代码。 ClearCase的元件类型可以管理版本内容。用户可以定义自己的元件类型，也可以使用ClearCase中的预定义类型：文本文件、压缩文本文件、文件、压缩文件和二进制增量文件。 ClearCase可以利用增量算法将文本文件存储在一个特殊结构的文件容器中。ClearCase采用标准的压缩技术和增量算法存储一个压缩文本文件。（这比以往的存储形式节省了50%―70%的存储空间。） 　　这种元件类型文件和压缩文件可以被用于控制任何操作系统文件──比如，可执行程序、程序资源库、结构数据库和结构文档文件。二进制增量文件类型可以随时被用于二进制文件格式。 3.4.2 在版本树中组织元件发展的过程　　在ClearCase中，元件版本的组织体现在版本树结构中。一个版本书的结构可以按目录结构定制， 还可以包含多层分支和子分支。 　　在一个典型的开发环境中，很多元件的版本树结构最初仅包含一个分支，即， 元件的版本排列在同一条线型队列中。随着时间的发展，当用户做一些错误修复、代码的组织、一些实验性修改或指定平台的开发时，它们可以给一些相关元件定义子分支，从而脱离主干进行开发。ClearCase可以支持多级的分支操作，还可以给版本或分支命名。 对目录和子目录进行版本控制 ClearCase可以对目录和子目录进行版本控制，允许开发者对他们数据的组织发展过程进行追踪。目录版本对一些改变进行控制，如：建立一个新文件、修改文件名、 建立新的子目录或在目录间移动文件等。 ClearCase也支持对目录自动进行比较和归并的操作。 存储数据在一个可访问的版本对象类中（VOBS） ClearCase把所有版本控制的数据存放在一个永久、安全的存储区中，这个存储区被称为版本对象类（Version Object Bases），项目团队（或管理者）可以决定它们所需要的VOBs的数量，可以决定什么样的目录或文件需要被维护。VOBs不仅是一个可连接的文件系统而且也是网上的资源──主机可以连接任何数量的VOBs. ClearCase VOBs的组成模式跟UNIX、Windows NT的文件系统和分布式的数据库系统非常类似。ClearCase采用Raima数据管理机制区维护VOB数据库。当在ClearCase中连接和访问时，VOB象一个标准的软件作为目录树的形式出现在客户面前，包含标准的文件对象：目录、文件、符号链接和硬链接。但事实上，文件系统已经有广泛的版本控制组件：它包含目录元素、目录元素版本、文件元素、文件元素版本、VOB动态链接和VOB硬链接。开发者也可以查看和这些文件系统对象相关的数据。这些数据包括事件记录，建立审核以及用户定义的项如：版本标签和属性。 3.4.3 使用常见的检出/编辑/检入范例 ClearCase的命令可以控制元素的变化，确保存储区有序的繁衍并使数据损坏的程度达到最小。ClearCase采用一种检出/编辑后检入的范例，类似于传统的版本控制工具如：RCS和SCCS。ClearCase除了可以进行检出、检入以及非检出操作外，它还可以通过命令设置另外的操作，如：删除版本、建立/删除分枝、可按时间顺序排列或结构排列顺序列出版本历史、比较版本间的差异，并且可以归并并行开发的版本。 　　当开始对于一个指定的文件进行工作时，该文件具有只读属性──这意味着它不能被编辑或删除。而检出操作可以对该文件的最近版本形成一个可编辑的拷贝。它无须将文件拷贝到另一区域工作。检出的注释可以被提供。当编辑完成后，该文件被检入，于是在版本树中形成一个新的版本并且将可编辑的拷贝删除。为了检验文件的变化，在检入过程中可以填入注释信息。文件一旦被检入，即刻回复到只读状态成为共享数据，可被所有成员使用。 ClearCase支持两种检出，保留以及非保留。保留检出可以保证版本历史形成的正确范围，并且同时只允许一个人做保留检出的操作。非保留检出无须保证建立一个成功的版本，如果多个用户同时对同一元素执行非保留检出，也企图进行检入操作，那么第一个检入操作被允许，而其他用户必须通过归并操作合并它们的结果。 丰富的注释信息和版本数据的报表 ClearCase存储了和文件系统对象相关又截然不同的信息类。这些信息实际上并不包含在对象中，它是一些额外数据。这些数据可以由ClearCase产生，也可以由用户自己定义。在VOB数据库中存储了所有的数据。 ClearCase产生的这种数据信息提供了可靠的、面向文件系统的版本注释信息。比如：这些数据可以验证在某一时刻，元素A建立了一个新的版本。用户定义的数据可以用来表达额外的功能──比如：该文件的版本曾被用于构造应用系统的4.31版。 ClearCase的操作（如：检出、检入、和版本归并）可以建立时间记录，记录数据包含这些操作信息。这些记录被存储在VOB数据库中，主要描述了该操作的属性"谁做的、做什么、什么时候、在哪个地方及为什么"，比如：敲入命令的人员的ID号，操作的种类，操作的时间，主机名称及用户填入的描述。可以通过"lshistory"的命令显示存储在VOB中的事件记录，并且可以通过历史信息浏览器提供的图形接口观察VOB中的事件记录。 　　用户可以针对多种目的定义数据，包含分支的名称、版本标签、元素任一版本的注释信息。 ClearCase数据的另一种应用是形成注释的文本文件。注释命令可以通过行显示的形式列出任何一个版本文本文件的内容，这使得我们可以更容易的看到什么时候在不同的地方做了添加或删除的操作。 ClearCase也可以针对文件系统对象建立客户报表。而报表的种类可以由用户自己定制输出格式。 3.4.4 通过分支功能支持并行开发 ClearCase支持并行（同时）开发，每一个元素都可以沿着不同的分枝同时发展，即新的版本加到独立的分支上。ClearCase可以很容易的产生分支，也可以很容易的将不同分支进行合并。这样一来，即便某一部分的工作被冻结或加锁，开发者仍然可以继续自己的工作（如：在软件集成期）。在这种情况，开发者可以在分支上工作，我们知道， ClearCase的自动化操作和图形归并工具可以让我们很容易的重新集成新的工作。 　　并行开发是非常重要的，因为： 　　（1）它允许不同的项目在同一时间使用同一资源树。 　　（2）它将目前不可和其他人员共享的修改成果进行隔离。 　　（3）它将绝对不可和其他人员共享的修改成果进行隔离（如：已发布版本中的错误修复）。 　　（4）它使得在软件集成期间开发工作无需停止，程序员可以先在分枝上开发，以后再集成。 　　为了支持并行开发，ClearCase允许进行分支建立，追踪分支的使用，文件比较，自动归并功能。 3.4.5 自动的比较和版本间的归并　　并行开发的特点是对同一元素的不同版本进行定期比较，也需要对版本间内容进行归并。在ClearCase中，对于元素或文本文件进行比较和归并的操作有两种：基于字符型和图形界面型。其中，diff命令执行多文件比较，不执行归并。而归并命令可以处理32个"成员"，并把它们生成一个独立的文件。 ClearCase可以自动辨认归并选项并实现归并。ClearCase也可以对需要归并的项目元素进行定位。如果所有的"成员"（归并元素）是同一元素的版本，系统会自动确定基础"成员"，通常是最低版本。此外，ClearCase会记录基础版本和某一归并元素版本间的差异。如果，所有的"成员"间差异互不相同，ClearCase会自动建立归并版本。如果两个或多个归并"成员"文件内容部分不同，归并功能会提示开发者选择归并内容。ClearCase也可以实现反向归并――从主分支向子分支归并。 ClearCase的加归并功能可以在归并其它分支时选择指定的版本（那些在分支上自始至终进行变化的版本）。负归并操作可以删除部分版本差异，从而形成一个新的版本，该版本除了那些被删除的变更外包含所有的改变。