Mercurial思想研读系列文章——1. 初识Mercurial

    许久没有发博客了,最近的项目经过调研和代码安全性考虑准备使用Mercurial,从很多网站的调研数据来看Mercurial在Windows平台开发较Git性能上有非常大的优越性(这里主要指基于HTTP的传输发,非本地版本控制),基于python的Mercurial给跨平台和网络支持带来了很多便利,而Git比Mercurial有更多依赖Unix的基因。

    之前试着使用过Git和HG,但是都是为了看开源代码,现在看起来有种菜鸟没见过世面的感觉。今天再次使用了HG,看了一些中文的使用入门和介绍,对HG有了初步的认识。但是感觉对分布式版本控制的一些理念仍有些不明了,决定花点时间仔细研读一下。这里把看到一些关于思想比较有价值的东西在此分享。(需要注意的是有些Git的思想和Mercurial是不太相同,使用Git时不能完全照搬)

   

1. 从SVN到分布式版本管理工具

   所谓分布式,就是指没有一个所谓的集中的中心(central)库,这个库一般由svn server(svn),vss administrator(vss)控制,而Mercurial就没有这样的一个库,所以使用版本控制的时候甚至都不需要一个administrator和server,本地直接建库,直接就使用,任何一个库都可以作为中心库,每个库在Mercurial看来都是平等的。当然,实际使用的时候,可以人为的去指定一个中心库以作为发布,

    首先,分布式最大的好处就是离线工作,不仅意味着可以不联网就享受版本控制的好处,并且也意味着普通的提交速度也要快的多,而且,以此带来的巨大灵活性甚至能改变你的工作方式,因为以前集中式的版本控制系统,每次提交都会影响到他人,以至于不能提交未经测试的版本,而使用分布式的版本控制系统时,你可以随时随地的本地提交,安全的保护自己的工作成果,以防意外,也能随时随地的本地clone,本地分支,本地就是一套完整的版本控制系统!直到修改到最终版本,然后才push(相当于集中式版本控制的commit)到真正的一个公用库上去。(这是我对分布式的优势的第一印象,所以感觉特别同意这个观点)

    其次,对于个人开发者来说,带来了太多方便,自己一个人不必自己建立一个SVN服务器,抑或自己不断的保存副本完成比较畸形的版本控制。HG只需要加你了自己的本地库,哪天有了新的成员或组建了团队只需要share到服务器就OK了,这对于本地的个人开发者实在太便利了,迫不及待想把以前的项目都建立成本地库,以前这个过程中实在有太多的不便利。


2.  Mercurial的问题

    分布式的版本控制系统还是有一定缺陷的,比如权限控制的问题,这点可能因为Mercurial的用户群主要在于开源世界,开始没有太过重视,但随着Mercurial的迅速发展和强大的Google的支持这些问题越来做的越完善了。然后Mercurial相比Git还有个缺点,那就是分支的时候不能对单独的子目录进行,一次clone就是一个工程,这样希望在一个大工程中对一个小项目进行分支,会比较麻烦,这点也算是比较大的缺点了。

    但是,上述缺点都不是分布式版本控制固有的,仅仅是目前Mercurial的实现的问题,相对于带来的便利都不能算作问题。

        且这些问题都只是现在我看到的文章的介绍,是否现在很好的解决还需要进一步使用和发现。


3.  相对SVN和Git的两个区别(此部分在之后的深入阅读和理解后再说,这里仅仅记录)

-->Mercurial是基于changesets管理的版本控制系统与git基于内容管理(snapshot)管理的方式不同。在Mercurial中,一个系统就是通过一个一个changesets累加起来的。

-->Mercurial要求Commit必须填写message,没有的话是会终止提交的,这也体现了一种好的软件版本管理哲学,每次提交都强制性的要求有说明的。之前粤哥说过的IBM关于通过SVN的Log解决问题的例子一直铭记于心,之后每次提交填写清晰的Log也成了一种习惯,但是有时候如果你不是在公司很难完全要求别人也做同样的事情,所以这一点真的非常好。这一点都足以让我放弃SVN了。

猜你喜欢

转载自384444165.iteye.com/blog/1738251