CVS SVN VSS对比整理

Java Web 专栏收录该内容
16 篇文章 0 订阅

原文地址:http://www.cnblogs.com/allenblogs/archive/2010/12/01/1893519.html

一、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 带来了诸多的优势:如对目录或文件执行拷贝,无论涉及多少文件,Subversion 不需要对单个文件依次执行拷贝命令,仅仅需要建立一个指向相应的全局版本号的一个指针即可。 

三、原子性提交 

从使用者的角度来看,CVS 和Subversion 都支持对多个文件修改的批量提交,但二者在实现方式上存在本质的区别。 

CVS 采用线性、串行的批量提交,即依次地,一个接一个地执行提交,每成功提交一个文件,该文件的一个新的版本即被记录到版本库中,提交时用户提供的日志信息被重复地存储到每一个被修改的文件的版本历史中。 

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

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

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

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


四、差异化的二进制文件处理 

由于历史原因,CVS 主要是为早期的程序员设计的,CVS 能够有效处理文本文件(或ASCII文件,源代码文件),可以对文本文件进行差异化的存储、新旧版本的比较,文件合并等;但对于二进制文件,CVS则明显 力不从心。在CVS 的版本库中,对于二进制文件的历史版本,CVS 唯一能做的就是对不同的版本进行独立的、冗余的存储,哪怕版本之间其实只存在微小的差异。举例而言,一个10M 的二进制文件(照片、图形文件、机械设计文件、电子设计文件)假如每周修改一次,无论每次修改的大小,一年下来,仅该文件就要消耗500M 以上的存储空间。而且,客户端每次获取该文件的新版本都要消耗10M 的网络流量。 

对于目前的开发团队,无论是软件开发,Web 站点的开发,手机等电子产品的研发,需要进行版本管理的不仅是源代码等文本文件,还需要管理需求文档、设计文档、测试文档、用户手册,图形图像文件,机械/电子设计文件等诸多的二进制文件,CVS 显然不是一个好的选择。 

与CVS 不同,Subversion 采用统一的二进制差异算法(binary differencing algorithm),即对文本文件和二进制文件采用相同的差异比较算法,并以相同的方式在版本库中进行存储:每次提交后版本库中只存储相对于先前版本的 差异,从而可以节省大量的存储空间。 

该二进制差异算法不仅应用在版本的存储上,更为重要的是,Subversion 对二进制文件与文本文件一视同仁,当客户端需要获取新的版本时(如执行svn update),在网络上只有版本的差异被传输,从而大大减少对网络带宽的消耗。更多细节参见"七、双向的差异化-压缩网络传输"。 

五、 双向的差异化-压缩网络传输 


如上所述,CVS 对二进制文件不能进行有效的差异化处理。对于文本文件,CVS 仅仅支持单向的差异化传输:从CVS 到客户端的传输是差异化的,即执行cvs update 时,只有差异的部分从服务器传输到客户端;而当执行cvs commit 时,无论代码变化多少,CVS 都需要从客户端向服务器完整传输被修改文件的全部内容,不能只传输差异。 

相反,无论是文本文件还是二进制文件,Subversion 都进行双向的差异化传输,并且差异化内容还要进行压缩/解压缩的过程:在服务器端获取差异显而易见,与CVS 类似;Subversion 在客户端获取差异的秘密在于 — Subversion 在客户端的工作拷贝中隐含了每个文件的一个"只读的、干净的"副本(该副本隐藏在隐含目录.svn 里,通常不可见,该副本还有更多的妙用,参见"十二、更多的本地/离线操作"),通过比较用户在客户端的修改和该隐含的副本,Subversion 获取需要真正传送到服务器的差异,并对差异进行压缩后才进行网络传输。 

对CVS 而言,操作的成本(网络带宽消耗是最大的操作成本)与被修改的文件的大小成比例,而与修改本身的大小无关;对Subversion 而言,操作成本只与修改本身的大小成比例,而与被修改的文件的大小无关。因此,与CVS 相比,Subversion 消耗更少的网络带宽(以客户端的存储空间换取更少的带宽消耗在目前的计算环境下应该是个相当不错的选择!)。Subversion 更加适合基于互联网(或广域网)进行协作开发的地理上分布的团队 — 版本服务器集中、单一;客户端广泛分布。 


六、 更多的本地/离线操作 

众所周知,CVS 客户端的工作拷贝中包含了一个隐含目录CVS,该目录中记录了客户端需要的一些管理信息;与此类似,Subversion 的客户端工作拷贝中也包含了一个隐含目录.svn,该目录中同样记录了客户端需要的一些管理信息,如版本库URL,当前访问版本号等。 

与CVS 不同的是,Subversion 的.svn 目录中还包含了工作拷贝中每一个文件的一个"只读的、干净的"副本。正是由于该副本的存在,使得Subversion 与CVS 相比,可以执行更多的本地/离线操作,即某些操作不需要访问版本库服务器,因此不需要存在从客户端到服务器的网络链接,当然也不消耗任何网络带宽,这进一 步增强了Subversion 对广域网的友好支持。 

Subversion 的以下命令可以进行离线操作: 

svn status - 显示工作拷贝上的本地修改概况; 

svn diff -显示工作拷贝上的本地修改细节,比较修改前后的内容; 

svn revert - 撤销工作拷贝上的本地修改; 

七、 对符号链接进行版本管理 


在Unix 文件系统中,符号链接(symbolic links,包括硬链接和软链接)是一种重要的文件系统元素。CVS 不能对符号链接进行版本管理;Subversion 则可以对符号链接进行版本管理。 

八、 元数据管理 

与CVS 相比,Subversion 增加了元数据(metadata)管理机制。即可以对版本库中的文件或目录附加任意的"属性"(property),并记录属性的变化历史,也就是对元数 据进行版本管理。一个Subversion 属性是一个"属性名称/属性值"的二元组,如"BugNumber= 100"就是一个属性,可以将该属性附加到版本N 上,以说明版本N 改正了编号为100的BUG。 

Subversion 元数据的目的是提供附件的信息以满足流程或过程自动化的需要,以增强Subversion 的管理能力和自动化程度。Subversion 自身就通过"属性"来存储一些特殊的信息。一个使用Subversion 元数据的例子:可以在一些批处理的脚本程序或Subversion的钩子程序(hooks)中创建、访问、修改"属性"元数据来满足流程自动化的要求。 

九、 VSS CVS 比较 

VSS适合小团队使用,基本的配置管理功能都有。VSS最大的特点就是部署比较简单,上手比较快。VSS最大的缺点就是安全性问题,目录共享、文件方式存储等。当然VSS还只能在Windows下使用。 

CVS了解过,应该说特点也很鲜明。首先CVS是开源软件,根据长期的流传,已经演变了很多版本,适合于不同的平台。因此,在CVS客户端上是多种多样的。其次,CVS的部署稍微复杂点,现对VSS来说,这是其一缺点。最后,CVS在配置管理的理念上,比VSS有所进步。 

十、 Vss与Svn 的对比
 

1. SVN支持重命名,这对 Java开发来说非常重要。 

为了得到更好的代码,开发中需要经常进行重构,重构就经常涉及到文件的重构名,而重命名中 VSS 中是不被支持的。 

2. 开发的时候不一定要锁定。 

一方面导致重构不方便,另一方面,不能离线开发,使用 SVN 就不同,可以带回家继续开发,回来后,提交就行了。 

3. 多平台。 
可以支持多个平台下的操作 


4. 更好的客户端支持。 
Eclipse 中的 VSS Plugin 不如它的 SVN Plugin 好用。一个在 Windows 下用的 SVN 客户端 TortoiseSVN 也比 VSS 的客户端好用(VSS 只有微软提供的一个 GUI 客户端)。 

5. 更好地与外围工具集成。 

各种各样的外围工具(主要是服务器端),满足多种需要。如果有需要,也可以自己写插件或管理脚本,开放的架构,允许我们这样做。 

6. 方便。 

一个例子:部署应用的时候,以前的做法是找出一个项目中修改过的文件,更新到服务器上去,现在可以在服务器上执行 svn export 命令,把代码库中的最新版本导出,完成部署(也可以替换回老版本)。 

7. 速度与稳定性看起来都不错。

学习它的管理、它的工作方式,是值得的。而 VSS 是一个已经被逐渐抛弃的软件。如果时间不是多得没处用,那么就把时间花在最值得花的东西上面。

 

最后再补充一点:

用户、权限管理

  cvs:管理员很难清楚的知道一个项目到底有多少个用户各用户的权限和密码是什么 只能用分组的方式管理用户而且密码和权限还是不清晰
  svn:查看、修改配置文件即可 

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 扫一扫,分享海报

©️2022 CSDN 皮肤主题:编程工作室 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值