八一八cvs vss svn和git比较-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

八一八cvs vss svn和git比较

简介:

特征

CVS

Git

Mercurial

Subversion

是否原子提交

CVS: 没有. CVS提交不是原子的

Git: 是的提交都是原子的

Mercurial: 是的

 

Subversion: 提交都是原子的

文件和目录是否可以移动或重命名

CVS: 不是重命名不支持如果手动进行可能会损坏历史记录

Git: 支持重命名这是很实用的目的. git甚至能检测到重命名之后文件的改变尽管如此基于特殊的存储结构重命名不会被显示的记录, git能够推导出来(在实际使用中很容易做到)

Mercurial: 是的重命名是支持的

Subversion: 是的支持重命名

在移动或重命名之后智能合并

CVS: 不能重命名都不支持就不必说智能了

Git: 不支持细节在Git FAQGit有一个重命名的命令git mv, 但是这仅仅是为了便利效果和移掉某个文件增加另外一个文件没有任何区别”

Mercurial: 是的重命名之后智能合并是支持的. Mercurtial文档说:“如果我修改一个文件,而你重新命名了这个文件然后我们合并我们的变更那么我所做的修改就会被更新到根据旧文件名字而产生的新文件里(这可能就是你所期望的‘最简单的动作’但是不是所有版本控制系统都支持)

Subversion: 不支持svn help me“中提到“注意这个子命令相当于拷贝和删除.“并且可能有个bug

文件和目录拷贝

CVS: 不能拷贝不支持

Git: 不能拷贝不支持

Mercurtial: 是的支持拷贝

Subversion: 是的并且拷贝非常容易(O(1)). 包括产生分支

 

远程存储仓库的备份

CVS: 间接的可以使用John Polstra写的CVSup

Git: 是的git的内部特征

Mercurial: 是的

Subversion: 间接的可以使用Chia-liang KaoSVN::Mirror插件(好像是台湾人)Shlomi FishSVN-Pusher工具

是否传递变更到父仓库

CVS: 不会

 

Git: 是的(Linux内核开发过程经常使用这个特征)

Mercurtial: 是的

Subversion: 是的使用要么是Chia-Ling KaoSVN::Mirror脚本或者Shlomi Fishsvn-push工具

仓库权限

CVS: 很有限pre-commit hook scripts“能够被用来实现各种权限控制系统

Git: 请看和Git一起附带的contrib/hooks/update-paranoid. 看和svnperms类似的path_rules的代码

Mercutial: 是的它能够锁住仓库子目录或者使用hooks后的文件

Subversion: 是的基于HTTP权限的WebDAV-based模块能够支持基于目录级的仓库

变更集

CVS: 不是变更是基于文件的

Git: 是的是支持的创建他们很容易

Mercurial: 是的变更集是支持的

Subversion: 部分支持对于一次提交会隐式创建一个变更集

跟踪线性的文件历史

CVS: 是的. cvs annotate

Git: 是的.(git blame)

Mercurial: 是的(hg annotate)

Subversion: 是的(svn blame)

能够只在仓库的单目录下作用

CVS: 是的

Git: 不是尽管如此提交多少能被限制请看“Repository Permissions

Mercurial: 能够基于某树的某个子集进行提交也有局部检出的能力

Subversion: 是的

跟踪未提交的变化

CVS: 是的通过cvs diff

Git: 是的另外分支在git里非常智能在某些工作流里能够被当成是另外一个未提交代码的存储库请看“git stash“命令

Mercurial: 是的使用hg diff

Subversion: 是的使用svn diff

基于单个文件的提交信息

CVS: 不是提交信息是基于单次变化的

Git: 是的提交信息基于变更集

Mercurial: 不是

Subversion: 不是没有这个特征

文档

CVS: 非常棒有很多在线的tutorials和资源在线的书籍命令行客户端也支持一个在线的帮助系统

Git: 良好短的帮助比较简洁难懂. man页很有分量但容易误解有很多tutorial

Mercurial: 很好有基于公司的书籍和wiki. 每个命令都集成了帮助

Subversion: 很好有一些在线的书籍和一些在线的tutorials和资源并且书籍是以docbook/xml写的所以很容易变换成其他格式命令行同样提供了在线的帮助系统

配置是否轻松

CVS: 是个事实上的标准基于每个系统都有并且很容易配置

Git: 在现有平台上二进制可用需要C编译器和Perl. windows上需要cygwin. 并有一些Unix特征

Mercurial: 非常好几乎所有平台都有二进制包从源码编译需要python2.3以上并且需要C编译器

Subversion: Subversion服务器需要安装在apache2模块里(如果有人希望HTTP作为底层协议的话)或使用它自身的服务器客户端需要Subversion特征的逻辑还有WebDAV(针对HTTP). 安装组件很直接但是需要一些额外的工作(假定subversion在某些平台没有二进制包可用)

命令集

CVS: 包含了3个经常用到的命令的简单的命令集(cvs commit, cvs updatecvs checkout)和其它一些

Git: 命令集很丰富并且和CVS不兼容

Mercurial: 尝试模仿CVS交互方式但是偏离了基于不同的设计的意图

Subversion: CVS的命令集能够很容易被CVS用户使用

网络支持

CVS: . cvs在不同的场合使用不同的协议协议能够通过ssh链接的加密隧道进行

Git: 非常棒能够使用本地的git协议但也能在rsync, ssh, HTTPHTTPS上使用

Mercurial: 非常棒使用HTTPssh. 远程访问会非常安全在只读网络里不需要上锁

Subversion: 非常好. Subversion服务器支持WebDAV+DeltaV(基于HTTPHTTPS)作为底层协议或者它自身的协议同样能在ssh链接通道里使用.

可移植性

CVS: 客户端能在UNIX, WindowsMac OS上使用服务器端能在UNIX, 附有UNIX模拟层的Windows上使用

Git: 客户端运行在大多数的UNIX系统上但没有MS-Windows本地程序基于cygwin的系统看起来也能使用

Mercurial: 非常棒运行在基于所有能运行python的平台.仓库是兼容性的基于CPU结构和字节序的

Subversion: 非常好客户端和服务器端都能在UNIX, WindowsMac OS X上运行

web接口

CVS: 是的. CVSweb, ViewVC, ChorawwCVS

Git: 是的. Gitweb包含在发布包中

Mercurial: 是的. Web接口是内置组件

Subversion: 是的. ViewVC, SVN::Web, WebSVN, ViewSVN, mod_svn_view, Chora, Trac,SVN::RaWeb::Light,SVN Browser, Insurrectionperl_svn.另外, Subversionapache服务也提供了一个基础的web接口

图形用户界面

CVS: 非常好有很多图形界面可以用: WinCVS, Cervisia(对于KDE), TortoiseCVS(Windows浏览器插件)

Git: Gitk包含在发行版中. QqitGit-gui工具也可使用

Mercurial: 通过hgit扩展查看历史检入扩展(hgct)使得提交很容易一些第三方的IDEsGUI工具(eric3, meld)有一些集成的Mercurial支持

Subversion: 非常好有很多GUIs可用: RapidSVN(跨平台), TortoiseSVN(Windows浏览器插件), Jsvn(java), 大多数都还在开发中

综上所述:

1.CVS(Cocurrent Version System)并发版本系统

建立在RCS基础上,最流行的开放源代码版本控制系统

特点:
1),使用单一的主代码树,而不像RCS那样依赖多个目录.
2),最大优点在于多名开发人员可以同时对一个文件进行修改.允许合并.
这就"并发"开发.

2,SVN(SubVersion)

1)目录的版本控制
CVS 只能对文件进行版本控制,不能对目录进行版本控制.CVS 只能注意到,一个文件在一个位置被删除了,而在一个新位置创建了另外一个文件。由于它不会连接两个操作,因此也很容易使文件历史轨迹丢失

   SVN可以
2)原子性提交

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

Git 是用于 Linux 内核开发的版本控制工具。与常用的版本控制工具 CVS, Subversion 等不同,它采用了分布式版本库的方式,不必服务器端软件支持,使源代码的发布和交流极其方便。 Git 的速度很快,这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪(merge tracing)能力。

3,Git

Git 是用于 Linux 内核开发的版本控制工具。与常用的版本控制工具 CVS, Subversion 等不同,它采用了分布式版本库的方式,不必服务器端软件支持,使源代码的发布和交流极其方便。 Git 的速度很快,这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪(merge tracing)能力。

git更加适合分布式开发项目。而svn(当然全称是subversion)则更适合于集中式大型开发项目。也有在git之上再使用一层svn的做法。

4.mercurial

Mercurial 是一种轻量级分布式版本控制系统,采用 Python 语言实现,易于学习和使用,扩展性强。其是基于 GNU General Public License (GPL) 授权的开源项目。

 

这是,我对svn,git,mecurial,git一些总结

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章