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

CVS,subversion,hg,git版本控制系统的选择之路
subversion,hg,git
对于软件开发者或者往大了说，有知识管理或者数据管理需要的数码人<[ifgtevml1]><![endif]>，是否使用版本控制系统，肯定已经不再是一个问题。
但是选用什么版本控制系统呢？这真是一个问题。我会告诉我的大部分客户，您可以仍旧选择Subversion作为主要的版本控制工具(CVS早已被我们淘汰了，见附：SVN和CVS的比较)，但是分布式版本控制系统，在特定场合诸如：异地协同开发、移动办公/开发、涉密项目的封闭式开发都有着各种不同的应用。
如果采用类似我们公司的开源开发模式或者是内部开源模式，那么Git可能是您的首选。
这篇博文以我们群英汇自己公司的版本库变迁历史，和网友共享…
Subversion
Subversion是群英汇支持的最重要的产品，我们服务的大多数客户，都或多或少的选择了我们的版本控制服务。群英汇为客户提供Subversion版本控制服务，从培训、应用部署、系统整合到售后服务、技术支持。
我们公司的部分项目使用了Subversion版本控制系统，如：
pySvnManager：HYPERLINK"http://sourceforge.net/projects/pysvnmanager/"托管在SourceForge上
FreeMind-MMX:HYPERLINK"http://sourceforge.net/projects/freemind-mmx/"托管在SourceForge上
WordPress的CoSign-SSO插件：HYPERLINK"http://wordpress.org/extend/plugins/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开源代码库:
HYPERLINK"http://bitbucket.org/ossxp_com/"http://bitbucket.org/ossxp_com/
Git
有了Hg，为什么还要用git？
和Subversion代码库同步的需要。
o虽然svn可以镜像远程代码库，但镜像库不能提交
oHg不支持分支，因此无法完全克隆一个Subversion代码库
oGit有着完备的分支支持，可以将远程svn库镜像为一个本地的git库，而且可以提交甚至远程提交
Git速度更快。如果你用过git和hg，你就会对我说的有所感觉：
oHg提交/克隆/push/pull，我经常对自己无所事事<[ifgtevml1]><![endif]>而感到恼怒，感觉就像傻子一样，完成了多少？1%还是99%？
oGit速度超快不说，整个过程有着详尽的提示，真是体贴备至。<[ifgtevml1]><![endif]>
Git＋Topgit很好的支持上下游的协同开发
oHg的MQ虽然很好，但是Git有Topgit，而且Git的rebase功能更成熟
oMQ可能更适合单人开发，但是没有办法对补丁之间建立依赖关系
oTopgit采用分支来管理补丁，而且可以在分支之间设置依赖，可以是代码更整洁