Repository Architecture

翻译自：http://hginit.com/05.html

水银给了你相当大的建库自由度。由于合并是如此好用，你可以根据你的开发进度来维护一些特殊用途的仓库

我们的菜单已经变的相当漂亮了：

图1

我们来更加仔细地看一看变更集的序号：

图2

数字的第一部分，13，很短也很方便。它只有一个问题……它不可靠！

当团队里的人各自工作并且将其成果合并，那些短号是不同步的：

图3

因此，我没办法跟人们说：“好吧，咱们来将版本转移到变更集13上。”因为每个人的13有可能是不同的。这就是为什么那个疯狂的十六进制数存在的原因。

图4

这个十六进制数在所有的仓库中都是一致的并且永远不会改变。好了，现在我们可以给大家说，“现在让我们移动到变更集1b03ab783b17！但如果我们能给这个变更集一个名字岂不是更好吗？”

是的，你可以这么做。这叫tag。

图5

我们现在来看看log：

图6

注意到添加tag这个动作也形成了一个变更集，并且自动为我提交了。因此，我现在可以使用Version-1.0来表示1b03ab783b17。

接着开始开发Guac 2.0

图7

提交：

图8

“太咸了！”有顾客抱怨。

这时我们可以用hg up命令回到Version-1.0版本

图9

现在可以解决他的问题：

图10

并且：

图11

水银告诉我，我又创造了一个新的头。现在有两个头：2.0是我之前在上面工作的头，1.1是我刚刚提交的头。

图12

现在我可以把这个1.1版本给客户，然后回到version 2.0开始工作。

图13

现在只有一个问题……解决的太咸的问题没有放在2.0版本上。这该如何解决？

图14

图15

啊哦。我必须要合并标签。这是水银中的一个讨厌的问题。这个问题就在于在水银中，标签只是一个叫.hgtags的文件，并且也在版本控制的范围内。因此，你需要时不时地手动合并一下.hgtags这个文件。不管何时发生这个合并的动作，你要做的很简单……即总是保证每一行对应到一个版本就行了。

图16

刚刚所描述的是一种简单的，回到历史版本，修改，再合并到当前版本的一个方法。而事实上在软件工程中，这样的事几乎随时都在发生。因此，水银提供了一个更加强健的方式来解决这一问题。

因此，我现在要撤销1.0之后的所有工作，并且将仓库返回到刚刚创建完1.0版本的时候。这样，我就可以展示当工作在一个未来的版本时，如何修复客户的问题。

图17

想法是这样的：我们将创立两个仓库，一个叫做stable，而另一个叫做dev。

叫做stable的仓库装着我们给客户发布的最新的主版本。不论何时你需要修复一个紧急的bug，你就在stable里面做。

dev仓库用于下一个版本的开发。

当1.0版本固定之后，就可以将stable克隆到dev中。

图18

现在我就有两个相等的仓库了。

图19

由于一直到变更集14，这些仓库的历史都是一样的。因此水银会使用一个叫“硬链接”的技巧来避免在硬盘中存放两个拷贝。这使得hg clone操作非常快速而低耗，因而可以放心地在本地克隆许多仓库。

现在我们开始在dev这个仓库里面工作：

图20

并且在stable仓库中修改了盐的问题：

图21

将之标签为1.1

图22

现在呢，我们可以时不时地将stable中修改的问题拉到dev中：

图23

这是我们现在做的：

图24

如果你能理解上面的那张疯狂的图的话，那说明你水银已经掌握地不错了。要点就在于，stable仓库中只有bug的修复，而dev仓库中有新的代码并且会将bug的修复合并进去。

使用多个仓库的情景还有一些：

• 你可以建立一个团队的仓库，然后让一些人在此基础上开发一个新的功能。当它们结束工作，并且这个功能可以很好地运行之后，你可以将这个变更从团队仓库推送到主开发仓库，这时所有的人都能看到这个新功能。
• 你可以为测试人员建立一个QA的仓库，你可以把你需要测试的代码放到QA的仓库中去（而不是直接放到主仓库中去）。当测试通过之后，你可以将QA仓库里的东西推送到主开发仓库中去。通过这个方式，主仓库中的代码总是测试过的。
• 由于每个开发人员都有它们自己的仓库，因而你可以从你的朋友那儿clone一份过来做实验。这样就不会影响到整个团队。

在大而复杂的组织中，你可以自由结合这些技巧，从而创建一堆互相关联的仓库。每个功能都要经历测试和集成，它会被拉地越来越高直到最终你的新代码可以被放到主仓库中并且可以被客户得到。

图25

自测

以下是你读完这篇教程之后应该能掌握的：

1. 给版本打上版本号，并且能够回到这个版本
2. 用“stable”仓库和“dev”仓库来组织你的团队

好了，本教程已经到达尾声了。这个入门教程没有覆盖到水银的方方面面，不过好在已经有非常多的资源可以引领你更深入地了解水银。这里推荐一本覆盖面较为全面的书给大家。

译者行之写在最后：

有简友问水银与Git的区别。其实，两者都是分布式版本控制系统。应该说，大同小异而各有优势。不过，如果你是像我这么不Geek的程序员，懒得在命令行里面打命令的话，可以试试水银哦~总觉得Git是给人摆酷用的。要说简单方便，还是水银。

安装水银时可以直接安装tortoisehg。光从图形界面的使用舒适感来说，TortoiseHg确实要比TortoiseGit要好用一些。TortoiseHg的Workbench还是相当强大的。

图26

另外，水银开web服务也特别方便。特别适合局域网内的工作协同。

图27

你可以让任意一台联网的电脑在5秒钟之内开启服务，这样其他人就可以访问这台电脑上的仓库啦。

可能有人会问，既然TortoiseHg这么好用，直接教怎么用TortoiseHg就好啦，干吗给这么一堆命令行教程？

然而我想说的是，重要的是思想好吗？这篇教程的重点在于用水银希望的工作方式去思考。知道了这，你觉得还需要专门学TortoiseHg怎么用吗？

所以，这里就不展开介绍TortoiseHg了。只留下四个字，给大家点信心。就是TortoiseHg特别好用！

最后，我想给自己留一条后路。也就是想告诉大家，虽然我翻译这教程有顶水银损Git之嫌。但是，我最近也确实在尝试使用Git~毕竟人家有时候还是想装一下Geek的：）