SVN与CVS的区别精辟讲解大全-git与svn的区别与优点

本文向大家介绍一下SVN与CVS的区别，大家应该知道SVN与CVS都是版本控制软件，那么他们之间有什么区别呢？通过本文的学习相信你会找到答案。

全局性的版本编号

通过全局性的版本编号看SVN与CVS的区别：一个新的版本，并得到一个自增量的版本号N+1，该版本号并不针对某个特定的文件，而是全局性的、针对整个版本库的。因此，我们可以将Subversion的版本库看作是一个文件系统或文件目录树的数组。Subversion的全局性版本编号为Subversion带来了诸多的优势：如对目录或文件执行拷贝，无论涉及多少文件，Subversion不需要对单个文件依次执行拷贝命令，仅仅需要建立一个指向相应的全局版本号的一个指针即可。

目录的版本控制

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

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

原子性提交

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

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

差异化的二进制文件处理

通过差异化的二进制文件处理看SVN与CVS的区别：由于历史原因，CVS主要是为早期的程序员设计的，CVS能够有效处理文本文件（或ASCII文件，源代码文件），可以对文本文件进行差异化的存储、新旧版本的比较，文件合并等；但对于二进制文件，CVS则明显力不从心。

与CVS不同，Subversion采用统一的二进制差异算法（binarydifferencingalgorithm），即对文本文件和二进制文件采用相同的差异比较算法，并以相同的方式在版本库中进行存储：每次提交后版本库中只存储相对于先前版本的差异，从而可以节省大量的存储空间。该二进制差异算法不仅应用在版本的存储上，更为重要的是，Subversion对二进制文件与文本文件一视同仁，当客户端需要获取新的版本时（如执行svnupdate），在网络上只有版本的差异被传输，从而大大减少对网络带宽的消耗。更多细节参见“七、双向的差异化－压缩网络传输”。

【编辑推荐】