【摘要】现在的软件项目开发中，必然涉及版本控制（Revision Control）工具。没有使用版本控制工具的开发工作，有人形容就如同生活在“黑暗时代”。版本控制工具是项目开发中必不可少的，以此进行的版本控制可以确保在软件项目开发中，不同的开发人员所涉及的同一文档都得到更新。

关于软件版本控制

如果在开发团队中没有使用版本控制，多个开发人员共同负责同一个软件文档的开发，每个人在各自的机器上有整个软件文档的备份，并对之实施编程开发，在分别完成各自任务之后，再通过文本比对工具将各自机器上的不同版本的程序整合到一台机器上。没有进行版本控制或者版本控制本身缺乏正确的流程管理，在软件开发过程中将会引入很多问题，如软件代码的一致性、软件内容的冗余、软件过程的事物性、软件开发过程中的并发性、软件源代码的安全性，以及软件的整合等问题。

版本控制的目的是实现开发团队并行开发、提高开发效率的基础。其目的在于对软件开发进程中文件或目录的发展过程提供有效的追踪手段，保证在需要时可回到旧的版本，避免文件的丢失、修改的丢失和相互覆盖，通过对版本库的访问控制避免未经授权的访问和修改，达到有效保护企业软件资产和知识产权的目的。

版本控制的功能在于跟踪记录整个软件的开发过程，包括软件本身和相关文档，以便对不同阶段的软件及相关文档进行表示并进行差别分析，对软件代码进行可撤消的修改，便于汇总不同开发人员所做的修改，辅助协调和管理软件开发团队。

Linux下的版本控制

版本控制在空间上可以保证完成集中统一管理，解决一致性和冗余问题。在开发工作中，开发人员在提交软件代码的时候一般采用服务器/客户端方式，尽管开发人员可以在自己的本地留有备份，但最终唯一有效的只有服务器端的程序代码；在时间上全程跟踪记录工具将会自动记录开发过程中的每个更改细节，和不同时期的不同版本。这在一定程度上可以解决冗余、事务性处理并发性问题。项目管理人员可以通过版本控制对团队中的不同人员，实施操作权限的控制。对于不同角色的开发人员，对软件的不同部分可以定义不同的访问权限。这在一定程度可以解决软件安全性问题。版本控制工具的使用，可以减轻开发人员的负担，节省时间，同时降低人为错误。

各“级别”的版本控制工具

“工欲善其事，必先利其器”。既然版本控制在软件项目开发中如此重要，那就有必要来仔细了解一下软件版本控制工具。

版本控制工具也有“级别”之分，其中有“元老级”的CCC（Change and Configuration Control）、RCS（Revision Control System）、SCCS（Source Code Control System），“新秀级”的Hansky Firefly ，“入门级”的Visual SourceSafe，“中坚级”的Clearcase，还有开源软件通用的版本控制工具CVS（Concurrent Versions System）和SVN（SubVersion）。CVS在一段时期内几乎成为版本控制工具的“代名词”，大概有着30多年的历史，而SVN是CVS的理想替代者，并出自同一人之手，被一些人誉为“迄今为止最好用的开源源码版本控制工具”。

CCC：Change and Configuration Control。在20世纪60年代末70年代初，软件配置管理的概念开始提出。20世纪七十年代初期加利福利亚大学的Leon Presser撰写了一篇论文，提出控制变更和配置的概念，之后在1975年，他成立了一家名为SoftTool的公司，开发了自己的配置管理工具CCC——这也是最早的配置管理工具之一。

RCS：Revision Control System。诞生于1980年，由WALTER.f.Tichy 于美国的在Indina州的 Purdue 大学开发，是基于单一文件的版本维护系统。

SCCS：Source Code Control System。SCCS是一种基本的程序源代码版本控制工具,它适用于任何正文文件的版本维护。SCCS基于单一文件的版本控制，通常它的软件储藏室和要维护的文件在同一目录下. SCCS 工作时,有一个专门的SCCS 格式的文件保留其源文件的编码版本,其记录了足够的信息来生成新的版本,并记录了谁对文件有修改权,拥有该版本的”锁”。

Hansky Firefly：作为H a n s k y 公司软件开发管理套件中重要一员的Firefly，可以轻松管理、维护整个企业的软件资产，包括程序代码和相关文档。Firefly是一个功能完善、运行速度极快的软件配置管理系统，可以支持不同的操作系统和多种集成开发环境，因此它能在整个企业中的不同团队，不同项目中得以应用。Firefly基于真正的客户机/服务器体系结构，不依赖于任何特殊的网络文件系统，可以平滑地运行在不同的LAN、WAN 环境中。它的安装配置过程简单易用，Firefly 可以自动、安全地保存代码的每一次变化内容，避免代码被无意中覆盖、修改。项目管理人员使用Firefly可以有效地组织开发力量进行并行开发和管理项目中各阶段点的各种资源，使得产品发布易于管理；并可以快速地回溯到任一历史版本。系统管理员使用Firefly的内置工具可以方便的进行存储库的备份和恢复，而不依赖于任何第三方工具。

Visual SourceSafe：微软的版本控制工具，仅支持Windows操作系统。虽然简单好用，但是仅适用于团队级开发，不能胜任企业级的开发工作。

Clearcase：IBM旗下Rational公司(2003年被IBM收购)的一款重量级的软件配置管理(SCM， Software Configuration Managemen)工具。与CVS和VSS不同，Clearcase涵盖的范围包括版本控制、建立管理、工作空间管理和过程控制。从最初的软件配置计划，到配置项的确立，从变更控制到版本控制，Clearcase贯穿于整个软件生命周期。 Clearcase支持现有的绝大多数操作系统，但它的安装、配置、使用相对较复杂，并且需要进行团队培训。

CVS：Concurrent Versions System。CVS 是有着三十年以上的时间的考验。CVS是开放源代码软件世界的一个伟大杰作，有人认为如今开源成功发展的幕后功臣之一当CVS莫属。Linux 的创始人 Linus 就把 Linux 的成功，归因于 CVS。由于CVS功能强大，跨平台，支持并发版本控制，而且免费，所以它在全球中小型软件企业中得到了广泛使用。CVS最大的遗憾就是缺少相应的技术支持，许多问题的解决需要自已寻找资料，甚至是研究源代码。CVS是一个典型的服务器/客户端软件，有UNIX版本的CVS 、Linux版本的CVS和WINDOWS版本的CVS。CVS支持远程管理，项目组分布开发时一般都采用CVS。

SVN：SubVersion。CVS纵然易用，但也有一些与生俱来的缺点，比如CVS不支持文件改名，只对文件控制版本而没有针对目录的管理，等等。之后CVS 的创始人之一在其现任公司的资助下开发了SubVersion，用以替代CVS。SubVersion 的设计目的就是针对CVS 的一些弱点进行改进。

SVN的版本控制流程

CVS纵然是一个老牌的工具产品，并也对开源事业有贡献，但CVS的命令行操作着实让一些使用者头疼。在对一个特定版本的文档Check in的时候，还要输入一长串的路径名、文件名。在操作易用性上与CVS形成对比的是微软家族的VSS。作为微软的产品，在图形界面化操作上自不用多言，但VSS只能适用于小团队的开发工作。VSS是很好的入门级工具，但它的一些功能也太过于“入门”，在验证密码、保存密码这些基本功能上处理的不尽人意。适用于大型软件开发的有“中坚级”的Clearcase，用它来管理一些小型的项目管理有些“大材小用”。Clearcase支持目录版本管理、异地团队开发、视图、多服务器等强大功能，所以一些大公司把它做为一、二级产品管理用，但同样它的价格也不菲。CVS是开源的，免费的，更何况它还有一个理想的替代者——SVN。SVN的设计专门针对CVS的问题作了改进,命令的设计更为合理,对二进制文档和目录这样的数据加强了控制能力,并且吸收了VSS的lock-modify-update(release)的模式和modify-merge模式的优点这两种方式在一定程度都支持并作了优化,没有提高使用的复杂度——这是难能可贵的。由于SVN的设计结构很好,所以很容易为它开发客户端,好像很快就有了tortoiseSVN,Eclipse插件等很多客户端,还有WEB模式的,可以远程管理,支持RSS更改订阅。

孰优孰劣？

现在又回到“开源软件 VS.商业软件”的老话题上了。先来看下CVS的基本工作模式：

CVS在服务器端维护代码文档库，不同的开发者在本地机器上建立对应代码树，并利用CVS保持本地代码文档同代码文档库的一致。当由于多个开发者对文件的同时修改造成本地与库中的代码文件冲突时，CVS报告并协助解决冲突代码的合并问题。普通开发者（非管理员）对CVS的使用流程如下所示：

Check out命令只需在开始建立本地代码树时使用一次，其后更新本地代码则使用update命令。update命令比较服务器和本地代码库的区别，并把本地代码树中过时的文件自动更新。当完成对代码的修改之后，在提交代码之前同样需要使用update命令，以获取他人并行修改的的代码。如果出现冲突（即对同一文件同时进行了修改），CVS将在本地代码中把两者都保留并标记出来，要求开发者处理冲突。在冲突不存在或已解决的情况下，使用commit命令将服务器代码更新为本地代码。CVS要求为更改提供注释，并自动为更新的文件处理版本编号。当软件需要正式发布时，使用export命令导出不包含CVS设置信息的源代码树。

即使不用拿CVS的升级版SVN，就算是拿没有目录版本控制功能的 CVS 来和商业的版本控制工具相比，我们也有充足的选择开源版本控制工具的理由：

服务器端是否和客户端一样看起来很美？

有一些商业软件的服务器端简直就像是一个垃圾场，用流水号命名的文件名，一个目录下动辄成千上万个文件。CVS以文件为核心，即面向文件的管理方式，项目文件可以方便地组合和移植。

服务器端是否在使用数据库来作版本控制的数据引擎？

为了支持目录的版本控制工具，大多数商业软件选择了一个最为简单和直接的解决方案——数据库，用数据库将文件名和版本库对应。但是引入数据库，服务器的稳定性、可维护性大大下降，成为管理员的噩梦。增量备份计划难以实现，不知道什么时候会出现数据库崩溃。

是否支持到其他版本控制系统的迁移？

对于商业软件，这个答案是否定的。如果允许将版本库导出到其他版本控制系统，简直就是将自己好不容易积累的客户拱手相让。

可否定制？是否可以对提交说明（Commit Log）进行检查？可否每一次的提交事件能够收到邮件通知？

CVS 的 CVSROOT 脚本扩展，以及 SVN 的 Hooks 钩子脚本，可以让用户充分发挥想像的空间。而商业版本控制工具，有此功能的寥寥。

客户端是如何状态保持的？

熟悉 CVS 和 SVN 的用户应该知道工作目录下的 CVS 和 .svn 隐含目录的作用，就是用于记录版本控制状态信息的。而很多商业软件并没有这个机制，而是靠服务器端来维护此记录：哪台主机、检出哪个版本的代码、存储到哪个目录。这么做的一个弊病就是工作目录不能自由在硬盘中移动，系统重装导致的状态丢失。｝

成本因素

一是软件采购成本。商业软件版本控制工具动辄十几万美金，而且是和用户数目挂钩的。

二是学习成本。商业软件版本控制工具的部署范围非常有限，不能保证新员工一定熟悉该系统，但是如果选择开源的版本控制工具，那么员工的培训费，可能就可以省下了。

客户确认软件中没有木马、间谍软件么？

客户肯定不会去购买你竞争对手开发的版本控制工具，那么您为什么还会相信其他闭源的版本控制工具呢？

小结

再优秀的版本控制工具都是软件项目开发中的一部份，况且，一个项目的完成并不只只涉及版本控制工具，还包括其他的一些工具。一个软件项目的开发成功需要涉及工具的使用，开发人员资源的管理等因素。但是，选择一款优秀的、适合开发团队和项目需求的版本控制工具能够提高开发工作效率和代码的优质性。对于版本控制工具的选择，秉持的一个原则是：“不选贵的，只选对的。”