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了。