版本控制是管理信息变更的一门艺术。Subversion版本控制工具早已经成为许多程序员的主要工具之一。但是版本控制软件的用途并不仅限于软件开发的领域。只要人们使用计算机来管理经常变更的信息，就需要使用版本控制工具。而这正是 Subversion 可以展示自己的地方。

下面我们来看一下版本控制:Subversion与CVS的对比：

一、Subversion包含绝大部分CVS功能

Subversion作为CVS的重写版和改进版，其目标就是作为一个更好的版本控制软件，取代目前流行的CVS。Subversion的主要开发人员都是业界知名的CVS专家。Subversion支持绝大部分的CVS功能/命令;Subversion的命令风格和界面也与CVS非常接近。当然，不同的地方正是对CVS的改进。　　

二、全局性的版本编号

一个新的版本，并得到一个自增量的版本号N+1，该版本号并不针对某个特定的文件，而是全局性的、针对整个版本库的。因此，我们可以将Subversion的版本库看作是一个文件系统或文件目录树的数组。从技术的角度来说，在Subversion中，“文件foo.c的第5版本”这个说法是错误的;正确的说法应该是：”文件foo.c在版本库被修改了5次，即执行5次commit后是什么样子?”。显然，在Subversion中，版本库被修改5次后foo.c的内容，和被修改了6次后foo.c的内容很可能完全一样，因为版本库的第6次修改很可能只修改了版本库的其他部分，而并没有对foo.c的进行修改。相反，在CVS中，文件foo.c的第1.1版本和第1.2版本总是不同的。

Subversion版本控制的全局性版本编号为Subversion带来了诸多的优势：如对目录或文件执行拷贝，无论涉及多少文件，ubversion不需要对单个文件依次执行拷贝命令，仅仅需要建立一个指向相应的全局版本号的一个指针即可。　　

三、目录的版本控制

CVS只能对文件进行版本控制，不能对目录进行版本控制，因此CVS没有任何关于文件“移动”(move)操作的概念。当人为进行文件移动操作时，CVS只能注意到，一个文件在一个位置被删除了，而在一个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。设置CVS存储库时，必须非常谨慎地为每个文件选择准确的位置，因为在设置之后，几乎就要一直使用这个位置了。

同样由于CVS不记录目录的版本历史，CVS不支持对文件的“重命名”(rename)，人为的对文件进行重命名会使得命名前后的文件失去历史联系，而记录历史本来是版本管理的主要目的。还有，CVS不支持对文件的“拷贝”(copy)，人为的拷贝对CVS而言，只能看到新的文件的增加，而不能记录拷贝源文件和目标文件之间的联系。

综上所述，缺乏对文件“移动”、“重命名”、“拷贝”的支持的根源在于CVS不能记录目录的版本历史，而这些操作在当前的软件开发过程中经常发生，这正是Subversion被开发并取代CVS的主要原因之一。

Subversion将目录作为一类特殊的文件来处理(事实上，从文件系统的角度来看，目录确实是一类特殊的文件，当目录中的子目录/文件被删除、重命名、或新的子目录/文件被创建时，目录的内容将发生改变)。因此，Subversion象记录普通文件的修改历史一样记录对目录的修改历史，当发生文件/目录的移动、重命名或拷贝操作时，Subversion能够准确记录操作前后的历史联系。同样，象对文件的不同历史版本进行比较一样，Subversion支持对目录的不同历史版本的比较，清晰展现目录的变化历史。　

四、原子性提交

从使用者的角度来看，CVS和Subversion版本控制都支持对多个文件修改的批量提交，但二者在实现方式上存在本质的区别。CVS采用线性、串行的批量提交，即依次地，一个接一个地执行提交，每成功提交一个文件，该文件的一个新的版本即被记录到版本库中，提交时用户提供的日志信息被重复地存储到每一个被修改的文件的版本历史中。

CVS串行批量提交模式的弊端在于-当任何原因造成批量操作的中断时(典型原因包括：网络中断、客户端死机等)，版本库往往处于一个不一致的状态：原本应该全部入库的文件只有一部分入库，很有可能版本库中的最新版本不能顺利编译，更为严重的是，随着其他的用户执行cvsupdate操作，该不一致性将迅速在开发团队中扩散，从而严重影响团队的开发效率，并存在质量隐患。另外，假如该批量提交的中断没有被及时发现，开发团队往往要花更多的时间进行软件调试和排错。

CVS即使在批量提交不发生中断时也会造成不一致：假设用户A启动一个需要较长时间才能完成的批量提交;与此同时，用户B执行cvsupdate操作。此时，用户B很有可能得到一个不一致的更新，即用户B通过“更新”操作，得到用户A的部分修改文件。

Subversion彻底消除了CVS的以上弊端。无论批量提交包含多少文件修改，只有当全部文件修改都成功入库，该提交才变得有效，才对其他用户可见;否则，无论任何原因造成中断，Subversion都会自动执行“回滚”(rollback)操作。换一个说法，Subversion保证所有的修改要么全部入库生效，要么一个也不入库，即对版本库不作任何的修改。这就是Subversion的原子性提交(atomiccommit)。

由于Subversion的原子性提交特性和全局版本编号方式，当提交成功完成时，一个唯一的、新的全局版本编号产生，而提交时用户提供的日志信息与该新的版本编号关联，只进行一次存储(区别于CVS的按文件重复存储)。

【编辑推荐】

1. 三大主流Subversion客户端初探
2. Windows下Subversion管理配置详细说明
3. 七步搞定Subversion服务器在Ubuntu下的配置
4. Subversion SVN协议解析远程整数溢出漏洞
5. CentOS系统中安装subversion并使用svn+ssh访问