SVN 与 CVS 的比较
1.全局性的版本编号
一个新的版本，并得到一个自增量的版本号 N+1，该版本号并不针对某个
特 定 的 文 件 ， 而 是 全 局 性 的 、 针 对 整 个 版 本 库 的 。 因 此 ， 我 们 可 以 将
Subversion 的版本库看作是一个文件系统或文件目录树的数组。Subversion
的全局性版本编号为 Subversion 带来了诸多的优势：如对目录或文件执行拷
贝，无论涉及多少文件，Subversion 不需要对单个文件依次执行拷贝命令，
仅仅需要建立一个指向相应的全局版本号的一个指针即可。
2.目录的版本控制
CVS 只能对文件进行版本控制，不能对目录进行版本控制，因此 CVS 没
有任何关于文件“移动”（move） 操作的概念。当人为进行文件移动操作时，
CVS 只能注意到，一个文件在一个位置被删除了，而在一个新位置创建了另外
一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。设
置 CVS 存储库时，必须非常谨慎地为每个文件选择准确的位置，因为在设置
之后，几乎就要一直使用这个位置了。
Subversion 将目录作为一类特殊的文件来处理,因此，Subversion 像记
录普通文件的修改历史一样记录对目录的修改历史，当发生文件 /目录的移动、
重命名或拷贝操作时，Subversion 能够准确记录操作前后的历史联系。同样，
象对文件的不同历史版本进行比较一样，Subversion 支持对目录的不同历史
版本的比较，清晰展现目录的变化历史。
3.原子性提交
从使用者的角度来看，CVS 和 Subversion 都支持对多个文件修改的批量
提交，但二者在实现方式上存在本质的区别。
CVS 采用线性、串行的批量提交，即依次地，一个接一个地执行提交，每
成功提交一个文件，该文件的一个新的版本即被记录到版本库中，提交时用户
提供的日志信息被重复地存储到每一个被修改的文件的版本历史中。
CVS 串行批量提交模式的弊端在于 － 当任何原因造成批量操作的中断时
（典型原因包括：网络中断、客户端死机等），版本库往往处于一个不一致的
评论0
最新资源