Mercurial Internal

最近在图灵社区上翻译了一篇mercurial架构的文章，顺便看了一下mercurial的代码和内部实现：http://www.ituring.com.cn/article/details/11708

我还没看AOSA这本书的git这一章。虽然平时git用的比较多，但是对git的内部实现还是认识的很模糊，没法和mercurial进行对比。就mercurial本身而言，除了在分支的实现上不如git之外，其他都非常好。mercurial一开始只能clone，这对于大型项目来说很坑爹。比如Firefox，开始克隆代码库之后程序员就可以去泡杯咖啡了。为了解决这个问题，mercurial后来加上了branch命令，可以原地切换分支。但是mercurial为了保持对svn和cvs用户的友好性，设计上还是希望在每个changeset之内记录分支名，不像git那么奔放，分支名就是个指针。

Mercurial的另一个特别之处在于每个changeset除了有一个hashid之外还有一个整数版本号。 虽然分布式版本控制系统中的版本历史是非线性的，但是这个整数版本号在任何一个mercurial版本库中都是线性的，只是顺序可能不同。这个数字版本号不仅使得mercurial对svn用户更友好，而且对于mercurial的内部实现很重要，它是mercurial快速读取版本历史的关键。

从社区的角度来说，Github完胜Bitbucket。我不知道为啥，可能是因为git比mercurial性能更好？或者Github更友好？我用python最多，所以也更偏爱mercurial。

Mercurial项目也有自己的性格，比如类名都是小写，变量名的单词之间不要下划线而是直接连起来写（比如loaddoc或者disabledext这样的函数名）。mercurial的代码中的注释真的多啊，不过注释多也不见得一定就是好事。给mercurial提交patch也是要带测试的，但是mecurial现在的测试已经太多了，跑起来要好久。我跑了一遍需要十多分钟。于是大家约定新的patch不再接受新的测试文件，但测试还是要，只是要塞在已有的某个测试脚本之中。囧！另外，虽然有个bugzilla来记录bug，但是所有的patch都要发到邮件列表里，有机器人会扫描新邮件，并根据邮件中的某些字样自动的在相应的bug中添加reference或者修改bug的状态。哎，真是奇怪的工作流程。