分布式版本控制系统Mercurial（一）：Mercurial基本功能介绍

版本控制系统（Version Control System / Revision Control System，或者叫做源码控制系统Source Control System，以下简称VCS），是软件开发人员最常用的工具之一，由于VCS是如此常用，所以花一些时间去了解它是有必要的。

 

• 分布式版本控制系统（Distributed Version Control System,DVCS），是相对于集中式版本控制系统（Centralized Version Control System，CVCS）而言的，比如，使用人数最多的SVN、VSS就是典型的CVCS。如果你曾经用过SVN或VSS，就可以很容易理解什么叫做“Centralized” 。CVCS，是指只有一份数据仓库存放在一台服务器上，所有客户端都连接到这台服务器以读写数据仓库的工作模型。而DVCS模型则不然，每一台终端都有一份完整的数据仓库，所有终端之间都是平等的，并不存在唯一的一台“服务器”。所有的终端之间，可以自由地交换数据。

DVCS可以很容易地模拟CVCS的工作方式，只要指定任意一台终端作为服务器，规定所有人都将更改推送到这台服务器，并且所有人也都从这台服务器获取更新即可。而与CVCS相比，DVCS则有以下优点：

a) 更加安全的代码管理。
在SVN中，每次提交都意味着正式的代码被更改，别人可以立即看到此次提交，并且可能直接影响到正在运行的系统（可能会有人立即将此更新拷贝到服务器），这导致一系列的问题。首先一个问题是，有人可能会无意中提交错误的、不可靠的代码。其次，这导致程序员不敢轻易签入更改，当程序进行一项耗时很久，大量修改的工作时，所有的修改都是没有经过VCS保护的，这是非常危险的，也不符合使用VCS的初衷。

而在DVCS中则不同，因为首先提交到自己本地仓库中，所以程序员可以尽量地向数据仓库提交更改，而不用担心这会影响到其他人或系统，这可以将程序员在开发过程中所产生的各个版本代码完善地保护起来，在周期较长的开发中，这一特点尤其显得重要。

 

虽然在SVN中有分支功能可以达到类似的目的，但是分支合并操作起来较为繁琐，而且非常容易发生冲突，结果就是很多应当使用分支的场合其实并没有使用分支。

b) 摆脱网络的束缚，随时进行完整的工作。
在SVN中，由于中央仓库只有一个，所以任何需要与仓库沟通的动作（例如查询历史版本，提交更改等等）必须首先联网，而在有些时候，这一束缚就显得不方便，而在DVCS中，则随时可以与数据仓库进行无缝的沟通，程序员可以向其中不停提交新的更改，或查询某个文件的历史版本，都可以在完全断网的情况下进行。

c) 更加智能的代码合并。
当两个人对同一份代码进行工作时，两个人的修改可能会产生冲突。然而，SVN当新的更改被提交时，SVN只能查看最终的版本，这导致SVN对某些差异很大的文件无法自动合并，而人工合并是很费时费力的。在Mercurial中，当两个不同的版本需要进行合并时，DVCS可以使用这个文件所有的修改历史来一步一步地还原整个修改的过程，这样一来，Mercurial的合并能力就远远地超过了SVN，所以在Mercurial中，极少会出现人工合并的问题。

d) 更快的反应速度. 由于各种日常操作都是在开发人员的本机进行的, 所以与任何的CVCS相比, DVCS的操作反应速度都将快很多倍.

另外，对于个人项目来说，尤其适合使用DVCS，因为DVCS天然地擅长管理本地的数据仓库，不像CVCS那样必须架设一个服务端，一个客户端。

 

因此总的来说，分布式结构的Mercurial具有SVN的所有优点，而又比SVN更加合理有效。

 

目前的DVCS最主要有Mercurial和Git两款软件，其中Git的原作者是Linus大神，用C语言编写，运行性能优于Mercurial（Mercurial是用Python写的，天生注定性能不可能比Git更快），但是Linus以及最初的开发团队并不打算开发Windows版本的Git，所以Git本身并不支持Windows，后来有了一个msysgit项目将Git移植到了windows平台，并且有了开发了一个TortoiseGit客户端，使得Git在windows下也变得容易使用了，但是在我使用的过程中，连续发生多次严重的故障，我怀疑其在windows下还不够成熟，因此采用与操作系统兼容完美的Mercurial。 Mercurial这个单词是水银的意思，所以Mercurial的命令名采用了水银的化学元素符号hg，这也是为什么它的图形终端叫做TortoiseHg，而不是TortoiseMercurial之类的。

 

这里（http://hgbook.red-bean.com/read/）有一份完整的Mercurial文档，详细描述了Mercurial的各种细节，不过鉴于其是英文的，我简单再罗列一下Mercurial的基本用法。

 

首先，下载并安装一个TortoiseHg with Mercurial(http://tortoisehg.bitbucket.org/), TortoiseHg是一个图形化的客户端，集成于Windows explorer，与TortoiseSVN是极为类似的。这个安装包同时集成了Mercurial的主程序，所以只要装这一个就够了。（Mercurial并不需要一个服务器端）

 

安装完成以后，打开Windows explorer， 在任意位置右击， 即可看到如下所示的TortoiseHg菜单：

 

这里需要先设置一下用户信息,因为Mercurial提交的时候需要知道用户名以便记录历史,所以必须首先配置用户名. 在上图菜单中点击Global Settings, 在弹出选项窗中的Commit子页中:

其中用户名的格式一般为"姓名<邮箱>" . 写完以后保存即可.

 

Clone命令用于从其它位置复制一个数据仓库，而Create repository here当然就是在当前文件夹创建仓库了，这里我们先创建一个仓库。

或者也可以不使用TortoiseHg的图形界面，直接用Mercurial命令创建。

Windows7有一个隐藏的右键菜单， 当住shift不放点右键时， 会发现右键菜单多了几项，其中就有一个是open command here， 这会打开一个cmd命令窗，路径就是当前文件夹，直接输入命令hg init， 即可完成数据仓库的创建。

（以前我也不喜欢用命令，但是使用Mercurial以后，我发现其实用命令并不麻烦，很多时候比TortoiseHg来得还要舒服一些）

 

创建数据仓库以后，再次右击， 会发现首先在一级右键菜单上增加了Hg Commit选项，而子项中则出现了一大排可用命令。这些暂时不用去理它。

随便新建一个文本文件，点击hg commit，输入一点注释（Mercurial强制要求每次commit必须写注释），点击提交即可。

注意左侧的文件列表， 必须先打上勾。因为是向Mercurial新增文件，所以必须先执行add命令， 然后才能commit，体现在这个图形界面上，就是先勾上左边，再点commit。

如果使用命令，则分别输入：

hg add

hg commit –m “some comment here”

第一行hg add会将所有新增的文件标记为需要Mercurial进行追踪管理，第二句则是向数据仓库提交修改。

 

这里需要注意的是Update命令。Mercurial的Update与SVN在实际效果上差异巨大。Update是用于使工作目录与本地数据仓库之间保持一致。所以，如果你是单人项目，总是在工作目录提交修改的话，它们肯定是完全一致的，Update命令将永远不必执行。（这大约也是为什么TortoiseHg把Update命令作为二级命令而不像Commit那样是一级菜单命令） 那么什么时候需要Update？先看一下push和pull。

 

假定我们刚才创建的仓库位于D:\repo1， 现在执行命令hg clone d:\repo1 d:\repo2， 或者在tortoisehg上点击clone执行相应操作（图形界面不再一一截图，很简单的操作），这样就创建了一个新的仓库repo2， 它与repo1是完全相同的。现在向repo1提交另外一些修改，显而易见的，repo2仍然停留在clone时的状态，repo1的最新修改repo2并不知道。 如果现在希望repo2也能更新到repo1的最新状态， 则有两种操作方式：

1. Push。 Push顾名思义，是推送的意思，就是从repo1中推送数据到repo2， repo2 不需要做任何动作。在repo1目录下执行命令hg push d:\repo2。 或者点击tortoisehg的Syncronize， 在同步窗口中点击push命令：

（这种操作我实在觉得还是命令方便一些。。。）

其中，push命令后面的路径并不是必须的。每个数据仓库可以有一个默认的远程仓库，如果在repo1中设置了默认远程仓库为repo2， 则只需要执行hg push 就可以了。当执行clone命令时，会自动把来源仓库设为默认远程仓库，所以在repo2中可以直接执行hg push或hg pull， 会自动到repo1中同步数据。

因为repo1并不知道repo2的存在， 所以如果需要手动设置默认远程仓库，如下这样操作：

点击右键—>TortoiseHg—>Repository settings,

点击Edit file, 如图所示, 修改default为需要指定的路径即可.

修改完成以后,即可直接执行hg push 而不用写成hg push d:\repo2了.

2. Pull. Pull是拉取的意思, 即被更新的仓库主动从远程仓库拉取数据. 在本例中, 到repo2的目录下执行hg pull即可. 因为repo2是从repo1  clone来的, 所以repo2已经自动把repo1设置默认远程仓库, 不需要再写hg pull d:\repo1了.

 

所以,无论是从repo1端push, 还是从repo2端pull, 都可以达到更新repo2数据仓库的目的.

 

然而需要注意的是, 无论是push还是pull, 都只更新数据仓库, 而不更新工作目录.

 

记住这一点非常重要, 否则可能经常会迷惑为什么与预期不符. push或pull之后, repo2的数据仓库与工作目录已经不符, 这时就需要在repo2目录下执行hg update命令, 即可将工作目录更新到与数据仓库一致.

 

当像SVN那样使用远程服务器作为主机时, 每次Pull后可以肯定是要执行update的, 这样两次操作显然带来不便, 在TortoiseHg中, 已经集成了这样的命令, 首先右键—>TortoiseHg—>Syncronize, 打开同步窗口,

点击Post Pull, 在弹出的小窗口中选择Update, 这样每次pull之后就会立即执行update了.

或者在项目的根目录下写一个批处理文件, 包括以下两行即可:

hg pull

hg update

以后每次需要获取更新时, 双击一下这个批处理即可, 我觉得还是命令方便……

 

以上简单罗列了Mercurial的基本用法, 对于查询历史修改等操作, TortoiseHg的菜单已经非常简单, 与SVN也没有什么差别, 自行点击看一下即可.

 

关于在两台电脑之间传递数据，Mercurial自带了一个简单的Serve命令，例如在d:\repo1目录下执行命令hg server， 会立即启动一个默认在8000端口监听的服务进程，这个命令会返回一个url地址，另一台电脑可以用hg clone <url> local-path 的形式复制本机的repo1仓库，但是这个serve命令显然只是一个非常简单的临时途径，如果要配置一台作为服务器的中央仓库，当然就不能仅仅使用serve命令了，而是应该使用IIS或其它web server，下一篇就介绍如何在IIS上架设一个Mercurial的Web Server,请参阅 分布式版本控制系统Mercurial（二）：web server的架设