Git vs. Mercurial vs. Subversion

转载 2012年03月30日 08:07:32

两类版本控制工具简单说明

这三种版本控制工具,我都有用过,目前项目中使用最多的是 Mercurial, 而一些自己的项目也分布在 GithubGit )或者 Bitb****etMercurial )上。

比较而言, Git 和 Mercurial 是一类版本控制工具,即分布式的版本控制工具, 而 Subversion 是集中式的版本控制工具,如果用一句话来概括二类的不同,则 为: 使用分布式版本控制工具检出的版本,包含完整的版本、历史等与代码 相关的信息,而集中式的版本控制工具检出的版本,通常只包含最新的一个版本 的代码 , 所以分布式版本控制工具能够极大地减少网络通信(如与服务器), 大大地提高效率。一个简单的例子例如要查看一个文件的log,用 Subversion 时就得和集中 的服务器通信来获得,获取的延时取决于网络通信等因素,而 Git 或者 Mercurial 则 只是一个本地的操作。

下面简单对比了下二类版本控制工具的优势:

  分布式版本控制工具 集中式版本控制工具
优点
  1. 减少网络通信
  2. 去中心化,提高可靠性
  3. 更利于分布式协作
  4. 生产率(productivity)相对较高
  1. 单次检出的成本低
  2. 较适合二进制文件(相比)
  3. 掌握的人更多
  4. 命令流程简单
  5. 相关配套软件成熟(如IDE集成)
缺点
  1. 首次检出代码时代价高
  2. 不适合二进制文件
  3. 掌握的人较少
  4. 命令流程相对复杂
  5. 相关配套软件不成熟
  1. 大量的网络通信
  2. 可靠性较低(信赖于中心结点)
  3. 不太利于分布式开发

三种常用版本控制工具的命令对比

据说,IT行业跳槽率是很高的一个行业,特别是开发人员,面对一个新的公司、新的同事、新的开发环境、 新的版本控制工具等的机率是很高的,而一个有较高素养的开发人员,应该对于主流的版本控制工具有一定 的了解,特别是对于常用的一些基本操作有能够较熟练的掌握。下面,我就简单总结下不同的操作目标下 三种不同工具的具体操作方式和命令。

  Subversion Mercurial Git
检出新的代码库 svn co repos_path wc hg clone repos_path wc git clone repos_path wc
更新已有的代码库 svn up hg pull -u git pull
查看本地的修改 svn st hg st git status
提交本地的修改
  1. svn add files
  2. svn ci -m “comments”
  1. hg add files
  2. hg ci -m “comments”
  3. hg push
1.git add files 2.git commit -m “comments” -a 3.git push
查看log svn log file hg log file git log file
恢复某个文件到某个版本 svn merge -c -REV file hg revert -rREV file git checkout REV file
恢复整个代码库到某个版本 svn up -rREV hg up -rREV git checkout REV
比较文件 svn diff -rREV:REV file hg diff -rREV:REV file git -rREV:REV file

当然上面只是最最基本的使用说明,不过大致已经涵盖了开发人员90%以上的日常操作,诸如branch,tag等应用, 你大体上可以通过”svn/hg/git help”来获得信息。

当然倘若你能够熟练地掌握其中之一,那也自成为你的瑞士军刀。

http://icatclaw.com/wp-content/uploads/2011/02/瑞士军刀图标下载145.png

关于二进制文件的版本控制

当然通常你会说没有这个必要来将二进制文件纳入到版本控制之中,我们大可选择ftp等覆盖方式来完成。 在实际的开发中,我们也有类似的方法,例如flash生成的二进制文件的swf和音乐文件mp3等,前者我们 还是使用 Mercurial 而后者我通常就使用 scp 等命令来完成了覆盖。

这时候,分布式版本控制工具的劣势就显现出来了,因为二进制文件每次更新基本上是一个完全新文件的更新, 而非增量,举个例子,假设一个分布式版本控制工具( Git /Mercurial)的代码库中只有一个10M的swf文件, 那么经过100个版本更新后,大小大致为10*100M=1G(大约,同样假设每次更新后的新文件大小也为10M)。如此一来, 当我们在服务器上部署时,首次的网络通信成本就非常巨大!记得在我们实际的一次项目经历中,一次更新了2个小时才 完成了更新。当然后续的更新相对成本较低。

同样的例子,如果改为使用 Subversion ,中心结点(服务器)上的代码库的大小大致也是1G左右,但是当我们部署时, 只需要大致10M左右的网络通信即可(取版本号为100的一次更新),所以成本则显得很低,后续的更新成本也相对较低。

当然,分布式版本控制工具下的代码库在线上时,如果需要恢复到某个特定版本,则无需网络通信即可完成,而集中式的 版本控制工具则成本相对较高。

总之,如果二进制文件的大小较小、版本更新频率较低,则选择二者差别不大,对于二进制文件较大、版本更新频率较多的 代码库,则选择集中式版本控制工具更为高效。

常用的代码hosting服务

这三类代码控制工具都有很好的第三方的hosting解决方案,下面只列举最常用的几个:

  1. Bitb****et (针对 Mercurial , 支持免费private repos)
  2. Google Code (针对 Subversion 和 Mercurial , 不支持免费private repos)
  3. Github (针对 Git , 不支持免费private repos)

现在应该说发展比较好的是 Github, 大家不妨可注册一个玩玩。

相关的链接

  1. git magic
  2. svn book
  3. mercurial guide
  4. git tag on SO (相关的对比和分析)

在Ubuntu上安装Mercurial的最新版本

如何在Ubuntu上安装Mercurial的最新版本 Mercurial是什么? Mercurial是与GIT相似的一个分布式版本控制系统,但使用方法上与Subversion(一个比较...
  • sean_cd
  • sean_cd
  • 2012年08月20日 19:28
  • 691

程序猿(媛)们注意啦!Git、SVN、Mercurial版本控制系统被爆远程命令执行漏洞

原文地址 近日,三款主流的源版本控制系统Git、Subversion (svn)、Mercurial,发布了更新补丁,修复了一个客户端代码执行漏洞。  恶意的攻击者可以向受害者发送一条精心...
  • yunqishequ1
  • yunqishequ1
  • 2017年08月14日 13:38
  • 323

Subversion 用户眼中的 Git

目录: Subversion 用户眼中的 Git (1): 集中式 vs 分布式 Subversion 用户眼中的 Git (2): 版本库, 工作区如影随形 Subversion 用户眼中的 ...
  • windone0109
  • windone0109
  • 2013年06月19日 16:09
  • 2995

【最优化方法】穷举法 vs. 爬山法 vs. 模拟退火算法 vs. 遗传算法 vs. 蚁群算法

优化算法入门系列文章目录(更新中):   1. 模拟退火算法   2. 遗传算法   一. 爬山算法 ( Hill Climbing )          介绍模拟退火前...
  • kuvinxu
  • kuvinxu
  • 2014年06月29日 08:46
  • 2283

堆溢出问题

以前没怎么弄过堆溢出问题,直到最近看见Google研究团队发布了关于dnsmasq的一系列问题 (需要翻墙)其中有两个CVE涉及到了Heap Overflow。其中的基础知识不再赘述,可以直接参考以下...
  • iextract
  • iextract
  • 2017年10月12日 18:12
  • 323

程序员成长笔记(二):SVN,Git,Mercurial

SVN: 概念:SVN是Subversion的简称,是一个开放源代码的版本控制系统,相较于RCS、CVS,它采用了分支管理系统,它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS迁移到Su...
  • u011104647
  • u011104647
  • 2016年01月11日 14:36
  • 594

Benchmark: PHP vs. Python vs. Perl vs. Ruby

Benchmark: PHP vs. Python vs. Perl vs. Ruby 转自:http://xodian.net/serendipity/index.php?/archive...
  • ghlfllz
  • ghlfllz
  • 2011年10月15日 16:34
  • 4745

faster-rcnn训练时出现error == cudaSuccess (30 vs. 0)

./experiments/scripts/faster_rcnn_alt_opt.sh 0 ZF pascal_voc   使用这条命令训练,出现下面这个错误 Check faile...
  • qq_26569761
  • qq_26569761
  • 2016年06月22日 21:39
  • 5222

Windows下编译CAFFE+CUDA, 运行时提示status == CUDNN_STATUS_SUCCESS错误

运行caffe训练时,提示如下错误: F0122 14:42:15.990329  3128 cudnn_conv_layer.cpp:53] Check failed: status == CUD...
  • eagelangel
  • eagelangel
  • 2016年01月22日 15:09
  • 16799

Check failed: status == CUBLAS_STATUS_SUCCESS (11 vs. 0) CUBLAS_STATUS_MAPPING_ERROR

caffe出现这个问题时,总让人摸不着头脑,不知从哪儿开始排查问题。     网上搜索资料,发现有人说是label做得不对,比如只有1没有0。但是这个是问题吗?就不能只有一个标签吗?     不过...
  • thesby
  • thesby
  • 2016年06月22日 14:41
  • 8196
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Git vs. Mercurial vs. Subversion
举报原因:
原因补充:

(最多只允许输入30个字)