CVS, subversion, hg, git 版本控制系统的选择之路

转自:http://www.oschina.net/question/84514_9508

对于软件开发者或者往大了说，有知识管理或者数据管理需要的数码人 <[if gte vml 1]> ，是否使用版本控制系统，肯定已经不再是一个问题。

但是选用什么版本控制系统呢？这真是一个问题。我会告诉我的大部分客户，您可以仍旧选择Subversion作为主要的版本控制工具(CVS早已被我们淘汰了，见附：SVN和CVS的比较)，但是分布式版本控制系统，在特定场合诸如：异地协同开发、移动办公/开发、涉密项目的封闭式开发都有着各种不同的应用。

如果采用类似我们公司的开源开发模式或者是内部开源模式，那么 Git 可能是您的首选。

这篇博文以我们群英汇自己公司的版本库变迁历史，和网友共享…

Subversion

Subversion 是群英汇支持的最重要的产品，我们服务的大多数客户，都或多或少的选择了我们的版本控制服务。群英汇为客户提供Subversion版本控制服务，从培训、应用部署、系统整合到售后服务、技术支持。

我们公司的部分项目使用了Subversion版本控制系统，如：

· pySvnManager：托管在SourceForge上

· FreeMind-MMX: 托管在SourceForge上

· WordPress的CoSign-SSO插件：位于官方的Subversion库中

我们公司内部的开发在2007年以前，也主要使用Subversion，但是之后，我们的代码库逐渐的向分布式版本控制系统迁移：

· 先是Hg：Hg是水银的化学元素符号，全称为Mercurial。

· 后来是Git：Git 是 LinusTorvalds 继Linux后的又一个伟大发明，为全人类的另一个伟大贡献

Hg/Mercurial

Hg走入我们的视线，是因为我们研究的项目都一个一个脱离Subversion阵营，转向Hg，使用Hg作为各自项目的版本控制工具。其中一个我们主要研究的项目是：MoinMoin维基。

使用Hg后，困扰我的问题迎刃而解，就是：

· 我们的软件开发模式是基于成熟的开源软件进行定制。项目的原始代码库称为上游，我们自己的代码库称为下游；

· 使用Subersion，我们采用Subversion的Vendor分支（或称卖主分支）来管理我们的代码

· 一但上游软件软件出现新的版本，我们代码的迁移就成了最让人头痛的事情，可能好几天都不能搞定；

Hg可以很好的解决这个问题，原因在于：

· Hg是分布式版本控制工具，整个代码库都在本地，浏览变更历史速度超快，实际上是本地访问，不再受制于网络。这样我们就可以更快的建立和上游版本库的同步，尽早尽快的解决代码合并问题，而不是要等到新版本发布；

· Hg的最佳拍当MQ！简直就是为我们的开发模式所设计的。Subversoion的卖主分支和MQ相比就好像马车和火箭的对比。

· Hg简单，并且使用习惯和Subversion非常相似，这也是为什么我们公司的版本控制系统在转向 Git后，仍有部分项目在使用 Hg的原因

群英汇的Hg开源代码库:

· http://bitbucket.org/ossxp_com/

Git

有了Hg，为什么还要用git？

· 和Subversion代码库同步的需要。

o 虽然svn可以镜像远程代码库，但镜像库不能提交

o Hg不支持分支，因此无法完全克隆一个Subversion代码库

o Git有着完备的分支支持，可以将远程svn库镜像为一个本地的git库，而且可以提交甚至远程提交

· Git速度更快。如果你用过git和hg，你就会对我说的有所感觉：

o Hg提交/克隆/push/pull，我经常对自己无所事事 <[if gte vml 1]> 而感到恼怒，感觉就像傻子一样，完成了多少？1%还是99%？

o Git速度超快不说，整个过程有着详尽的提示，真是体贴备至。 <[if gte vml 1]>

· Git＋Topgit很好的支持上下游的协同开发

o Hg的MQ虽然很好，但是Git有Topgit，而且Git的rebase功能更成熟

o MQ可能更适合单人开发，但是没有办法对补丁之间建立依赖关系

o Topgit采用分支来管理补丁，而且可以在分支之间设置依赖，可以是代码更整洁

群英汇的开放Git代码库：

· 群英汇在github上的开源代码 (请使用 firefox浏览器)

· 我们自己网站上的gitweb演示：http://git.ossxp.com/

· 我们项目管理平台大多数项目也是和git版本整合：Redmine项目

---

参考阅读：

· Why Git is Better than X

· Version Control System Comparison

· Version control systems comparison

· CVS vs Starteam

分享文章	这篇文章由 蒋 鑫 于 2010年6月29日 - 12:00发表于http://www.ossxp.com/，分类于 Linux。您可以通过 RSS 2.0 来订阅对该条目的回复。 也可以发表评论或引用到你的网站。

附：SVN和CVS版本控制比较（淘汰CVS的理由）

SVN 和 CVS 同为开源的集中式版本控制工具。随着 CVS 的一天一天老去，越来越多的缺陷被暴露，SVN正是被设计用于替代 CVS 的。

§ 几个GB甚至十几个GB的 CVS 库的问题：

§ 分支代价大，创建一个里程碑需要的时间？

§ CVS创建里程碑/分支一直是这么慢么？

§ 目录和文件名的版本控制

§ 如何重命名的？以破坏历史为代价的重命名？

§ file base 的 VCS，不支持 transaction

§ 为什么tag在CVS那么重要？──file base

§ 认证方式单一，安全性差

§ 二进制文件支持脆弱，易破坏

§ 忘记 -kb ？

§ CVS代码维护停滞，停止演进。第三方支持工具少

两种集中式开源版本控制系统比较： Subversion 和 CVS 的比较

§

比较项目	CVS	SVN
权限控制	是否依赖系统帐号	依赖	不依赖
可否对分支授权	否	是
是否支持LDAP认证	否	是
图形化帐号管理	否	是(集中管理平台)
用户可否获取忘记口令，修改口令	否	是(集中管理平台)
目录，文件名变更	否	是
分支管理	创建分支时间	耗时*	快
分支可见、查询	难	易
二进制文件	二进制优化	否	是
二进制文件标识	手工	自动
二进制文件（图形文件）被破坏	易破坏	不易破坏
事物处理	量子提交	否	是
修改提交说明	单个文件	是
换行符	可否指定换行符类型	否	是
检查换行符设定，避免跨平台开发带来的混乱