几种常见版本控制系统的比较研究

刘祖发　钟湘琼　王湘

摘要：版本控制系统是软件开发企业的基础软件，是高质量开发软件的重要保障。经过多年的发展，已有多种版本控制系统面世，有不少产品至今还拥有大量的用户。文章从功能、架构、性能、成本等方面对当前常见的几种版本控制系统进行分析比较，为企业在选择适合自己的版本控制系统时，提供参考。

关键词：版本控制系统（VCS） ；CVS（Concurrent Version System） ；CC（ClearCase） ；SVN（SubVersion） ；Git；比较

中图分类号：TP311      文献标识码：A

文章编号：1009-3044（2023）01-0058-03

1 引言

版本控制系统（VCS） 是用于存储、追踪文件和目录及其修改历史的专用软件，可以标识不同阶段的文件，进行差异分析，也可将修改撤销，轻松地回退至过去某个版本状态[1]。在软件开发过程中，除了代码文件、源程序外，还会生成需求文件、设计文件、产品文档、用户手册等工件，这些工件随着项目的推进不断更新，形成种类繁多、更改频繁的工件库，面对这样一个复杂的工件库，如何对其进行有序管理、快捷查找、高效利用，成为制约软件开发质量的一个关键问题[2]。可以说，版本控制系统是软件开发企业的基础设施之一，是开展软件配置管理工作的基础（故版本控制系统通常也被称为配置管理工具），是软件开发者的必备工具。

自20世纪60年代末70年代初提出软件配置管理概念至今，许多软件公司、软件开发者先后开发出了RCS（Revision Control System） 、CVS（Concurrent Version System） 、VSS（Visual SourceSafe） 、CC（ClearCase） 、SVN（SubVersion） 、Mercurial、Git等版本控制系统。这些版本控制系统的系统架构、实现方式、性能、使用等方面各有优劣，有些系统虽然有几十年的历史，但仍在很多地方使用。

纵观版本控制系统的发展历程，可以把版本控制系统的历史划分为三代[3]。第一代版本控制系统被称为本地版本控制系统，通过加锁将并发执行转换成顺序执行， 一次只能有一个人处理文件，代表产品有RCS；第二代版本控制系统被称为集中式版本控制系统（Centralized Version Control Systems，CVCS） ，其对同步修改更加宽容，但有一个明显的限制，用户必须在提交之前将当前修订合并到他们的工作中，代表产品有CVS、VSS、SVN、CC；第三代版本控制系统被称为分布式版本控制系統（Distributed Version Control Systems，DVCS） ，其允许合并和提交分开，在每个使用者电脑上就有一个完整的数据仓库，没有网络依然可以使用，代表产品有Mercurial、Git。

本文将对常见的几款版本控制系统，从架构、性能、成本等方面进行分析比较。

2 CVS

CVS诞生于1986年，最初它是作为一组shell脚本出现，一直到2010年前后，它仍然被很多企业使用。CVS开创了第二代版本控制系统的历史，Linux的创始人Linus甚至把Linux的成功归于CVS。CVS是开源软件，可以免费获取使用。

CVS是采用非常典型的客户端/服务器架构模式，将文件集中存储于服务器，各用户把文件检出到本地，在本地修改后再提交至服务器。其支持并发版本控制，采用无限制的版本管理检出的模式，即当A用户检出一个文件时，B用户也可以检出该文件并修改每次可以修改提交多个文件，相比第一代每次只能由一个用户修改一个文件的版本控制系统，无疑极大地提高了软件开发效率。因为是用Java编写的，能够跨平台使用。

CVS的缺点在于，权限设置比较复杂，当软件规模扩大时，CVS不能有效地将开发者在不同的软件模块间隔离，无法满足大规模软件开发过程中对开发权限的精细管理。不能对目录进行版本记录，无法更改文件名称或移动文件。同时，它多采用命令行方式，学习曲线较高。因为CVS是开源软件，没有生产厂家为其提供技术的支持，使用过程中碰到问题，只能靠自己在网上查找解决。

3 SVN

为解决CVS的问题，CVS创始人之一开发了SVN，用以替代CVS，同样是开源软件。其使用了改进的“拷贝-修改-合并”功能，使得开发更加便利。采用角色访问控制策略，通过设计角色与用户组将用户与权限关联，实现对系统权限的精确设置[4]。SVN有一个中央版本库（Repositor） ，用于集中存放需要管理的文件，用户将所需的文件检出（Check out） 或更新（Update） 到本地，修改之后，再提交（Commit） 至中央版本库。工作原理示意图如图1所示。

相比于CVS，SVN具有如下特性[5]。

1） 对目录进行版本控制

CVS只能记录单个文件的修改历史，而SVN借助一个“虚拟”文件系统，可以记录整个目录树的修改，从而可以对文件和目录进行重命名或移动。

2） 原子化提交

SVN将用户对同一批次文件的修改记录作为一个整体，对于这一批修改，提交时，要么全部上传到中央版本库，要么都不上传。这样就避免了因网络问题等原因导致部分修改没有上传而使中央版本库与本地不一致的情况。

3） 可选的网络层

SVN对中央版本库的访问功能进行了抽象，使用HTTP的变种协议进行通信，便利SVN可以拥有服务器的一些特性，例如认证、授权、传输压缩等。支持多种访问方式，方便人们在SVN基础上开发其他功能。

4） 数据处理的一致性

SVN使用二进制文件差异算法来记录文件的变更，对文本文件和二进制文件使用相同的处理方式，而且这两种类型的文件都压缩存储在中央版本库中，在网络中只传输文件两个版本间的差异，可以大大减少对网络带宽的消耗，提升传输效率。

5） 创建分支和标签的效率高

SVN使用一种类似于硬链接的机制来创建分支和标签，不与工程的大小成比例增长，因此，SVN创建分支和标签时只需花很少且相对固定的时间，也减少了对存储空间的占用。

因以上的特性，SVN一出来就受到了大家的欢迎，哪怕在Git大行其道的今天，SVN仍占据不少市场空间。

4 CC

CC的全称是（ClearCase） ，最初是Rational公司的产品，后被IBM收购。它是公认的功能强大，价格昂贵的版本控制系统。CC支持跨平台使用，依托于操作系统的用户管理，可进行精确的权限管理。

主要功能有版本控制、工作空间管理、构建管理、过程控制。CC的版本存储系统库被称为VOB（Version Object Bases） ，用于存储文件及修改记录，CC称存储于其中的文件和目录为元素（Element） 。工作空间也被称为视图（view） ，CC提供了两种视图，即静态视图和动态视图。静态视频将元素下载到本地工作目录，动态视频通过虚拟文件系统提供对元素的存取操作，不需要将元素拷贝到本地[6]。与CVS/SVN不同的是，CC的服务器支持分布式应用，允许VOB和CC的服务器程序运行在不同的服务器上。如果结合ClearQuest等变更管理工具的使用，可以无缝完成绝大部分配置管理工作。因此，CC非常适合大型软件开发团队使用。典型的部署架构如图2所示。

CC的劣势在于，使用成本较高，除了软件本身和许可的费用外，不可避免地需要购买技术支持服务；学习成本很高，通常用户需要经过几天的专门培训后，才能正常使用CC，如果要成为一个合格的CC系统管理员，需要更多的培训时间。跟SVN相比，在CC中创建分支和标签需要花费较长的时间，而且随着软件规模的增长而增长。

5 Git

Git是一个分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目管理。Git是Linux创始人开发出来的开源软件，是当前最流行的版本控制系统。

对于SVN、CC等第二代集中式版本控制系统来说，因所有文件均保存在中心服务器，开发者必须连接到服务器才能将自己的修改提交，更重要的是，如果中心服务器发生文件丢失的故障，很难进行修复，此时将面临巨大的开发风险。而分布式版本控制系统则不存在这些问题。使用分布式版本控制系统的每个开发人员都拥有一个完整的版本库，不管是统一的服务器还是某个开发者终端出现故障，都可以用其他开发者的本地仓库快速恢复。

在Git中，没有中心服务器或中央版本库的概念，取而代之的是本地仓库（Local Repository） 和遠程仓库（Remote Repository） ，本地仓库即为开发者自己终端上的仓库，远程仓库可以是其他开发者的仓库，也可以是服务器上的仓库，开发者即可以将本地修改推送到服务器仓库，也可以直接推送给其他开发者，相反，既可以将服务器仓库的文件拉取到本地仓库，也可以将其他开发者仓库的文件拉取至本地仓库。当然，在实际使用时，可以指定一台服务器为“中心服务器”，开发者把自己的修改都推送至该服务器。操作示意图如图3所示。

在SVN或CC中，不存在私有分支。当需要开发一个新特性时，在SVN或CC中，必须在中央版本库（VOB服务器）中创建分支，此时既可能需要管理流程上的批准，也可能导致开发过程中的结果暴露给其他开发人员。而Git支持私有分支，开发人员可以在本地创建私有分支，由本人单独享有，在该分支上将新特性开发完并验证无误后再合并至主分支，共享给其他开发人员。

Git存储内容时使用SHA-1哈希算法，确保代码的完整性。与SVN不同，Git并不保存用户提交内容的差异，而是存储某个时间的快照，即为该数据的一个完整可用拷贝，这有助力快速恢复到某个历史版本。快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品[7]。同时，采用压缩技术，比SVN占用空间更小。

总体上，Git与第二代版本控制系统代表工具SVN对比如表1所示。

Git虽然功能强大、效率高、免费，但不如SVN容易上手，有一定的学习成本。同时，它本身不支持权限控制，无法控制开发人员对不同软件模块的访问，存在一定的风险。

6 结束语

通过以上分析对比，除第一代版本控制系统，第二代和第三代版本控制系统均有自己的优势和劣势，在同一代版本控制系统之间，也有各自的长处和短处。企业在先用版本控制系统时，并非最新的就是合适的，而要综合考虑自身的组织架构、网络环境及使用者的水平等，选择最适合自己的版本控制系统。

参考文献：

[1] 丁贤林.基于SVN的项目文档管理系统实现[D].成都：电子科技大学，2012.

[2] 戴楠，闫明星.用SVN实现软件的版本控制[J].电脑知识与技术，2009，5（16）：4289-4290，4293.

[3] Sink E.Version Control By Example[M].Pyrenean Gold Press，2011：1.

[4] 李艺.基于SVN的版本与权限管理系统的设计与开发[D].北京：北京工业大学，2016.

[5]TortoiseSVN中文文档[EB/OL].[2021-09-20].https：//tortoisesvn.net/docs/release/Tort-oiseSVN_zh_CN/index.html.

[6] 姜文，刘立康.基于SVN的软件配置管理和持续集成[J].电子设计工程，2016，24（2）：1-5.

[7] 罗力格，麦卡洛，王迪.Git版本控制管理[M].北京：人民邮电出版社，2015.

[8] 王真.版本控制工具在软件开发项目管理中的应用——以GIT为例[J].项目管理技术，2020，18（6）：131-134.

【通联编辑：谢媛媛】