最近想用版本控制软件来保存汉化文件，但又觉得SVN太麻烦，于是想到了最近较为流行的分布式版本控制工具。

而Git和Mercurial（意思为水银的，于是经常缩写为Hg）自然是其中最为流行的工具。大名鼎鼎的Linux就用Git作源码管理，而Python和Firefox则采用Hg（你可以在这找到一堆）。

比较了一番后，最终我选择了后者。因为Git的优势主要在于分支，而汉化并不需要太多分支；而Git对Windows的支持似乎不如Mercurial，ssh也比http麻烦，比较难教汉化组成员们使用；此外还有个特别的原因：Hg主要是用Python实现的（小部分使用C实现）。

当然，Hg也有个很严重的缺点：不支持针对单个文件夹的分支。如果剧本翻译和改图要建立分支都必须复制整个仓库，而对翻译来说，图像文件并不是他需要的部分。

此外，Google还发了篇，说明为什么Google Code决定支持Hg，而不支持Git。

Git的优势：

 

• 客户端存储控制。可以删除任意的版本，而无需考虑该分支的后续版本，而Hg做不到。
• 无限的父结点数。Hg一次只能分成2个分支，合并N个分支要进行很多次操作。而Git没有限制。
• 支持rebase。它可以将当前版本移到最新的分支去。例如假设有个本地库在开发1.0的新特性，而基线已经升级到1.1了；一般情况下是需要合并到1.1去的，而rebase可以避免这种操作。

Hg的优势：

 

• 学习曲线。由于很多因素，Git比Hg的学习曲线更陡峭。
• 支持Windows。
• 维护。Git需要定期维护。
• 历史是不可侵犯的。Git很强大，可以干几乎任何事，因此也会丢失历史信息。

看起来Git在技术上是要强于Hg的，不过由于文件操作的实现依赖于操作系统，移植到Bigtable会存在麻烦；而且Hg有很好的基于HTTP的无状态pushing和pulling，容易与Google的构架整合（Google几乎所有的服务都基于HTTP）。

对于这点，Google还特意提供了测试数据，指出在使用HTTP时，Git比Hg慢1个数量级。（提到了2个数字，分别慢22倍和12倍。）

在继续介绍Hg之前，我先说下（DSCM, Distributed Software Configuration Management）。

之前曾用过一段时间的SVN，这也是集中式SCM中非常流行的工具。给我的印象是速度慢（因为每个文件都是单独下载，速度根本上不去），每个文件夹下面都有个影响心情的.svn文件夹。

而今天用了几个小时的Hg，明显感觉到了不同。

首先就是速度快，上传和下载都是打包并压缩的。我的一个20.7M的项目，上传上去只用了几分钟，占用4.3M的空间，不得不说压缩率很高。

其次就是仓库是分布的，可以在本地建立多个镜像，然后分别进行更改；提交也只提交到本地的镜像，并不影响主仓库；各个仓库还可以互相进行合并，最终达到多个版本的一致，再上传到主仓库。

这对汉化来说是非常方便的，因为翻译们可以建立自己的镜像，翻译完告知校译；校译们获取各个翻译的版本，进行合并，校译完再通知润色；润色则可以获取校译的版本，然后推送到主仓库。由于主仓库不需要多次更改，也就避免了在主仓库上建立多个分支，导致管理的混乱。

顺便列出我找到的几个可以用于免费托管代码的网站：

 

• ：这个网站非常出名，是用RoR建的，300MB的免费空间，支持Git，但不支持Hg（虽然有插件，但教别人用太麻烦），而且没有私有库。
• ：这个是用Django建的，可以建1个私有库，150MB的免费空间，支持Hg。
• ：只有（无限个）私有库，500MB的免费空间，支持SVN和Git，但只能有5个用户。闭源项目推荐，但显然不适合庞大的tomo汉化组。
• ：200MB的免费空间，支持SVN和Git，只能有1个库和2个用户。

最终我选择了最小的bitbucket，因为也差不多够用了。

（注：Google Code现已支持Hg，但只能托管源码，不能用于其他目的，所以我只能放弃。但如果你是开源软件开发，那么Google Code是最大方的，还可以发信申请扩大配额，只是偶尔会被GFW。）

接着就开始装软件了。习惯了SVN的乌龟，所以仍然选择了乌龟汞（）。

目前这个版本支持Windows XP、Vista和Windows 7，所以不担心兼容性。

安装很简单，装好后要重启（其实不重启也可以用）。

喜欢命令行的还可以在CMD里输入hg试试。