关于hg的使用

关于集中式和分布式的讨论

“分布式版本控制的问题是太容易创建分支了, 而分支是最容易出问题的”, 这个观点同样是错误的. Subversion 的分支容易出问题, 主要是因为 Subversion 没有提供足够多的信息来保证分支合并的正常工作. 对于 Mercurial, 分支合并是一件很轻松惬意的事, 所以创建分支是很稀松平常的, 而且无毒副作用.

新写好的代码总是充满了 bug. 你需要花些时间调试后才能保证它正常工作. 在此期间, 它可能会影响团队内其他开发人员的工作热情.

这是 Subversion 的传统做法:

在你 checkin 新的代码, 每个开发人员都获取这份新代码.
由于你新写的代码中存在 bug, 你会有如下选择.

你可以 checkin 有 bug 的代码, 然后把所有人搞疯, 或者
在做好充分调试前不要进行 checkin 操作

Subversion 总是给你出这样可恶的难题. 要么库里的代码满是 bug, 要么新写的代码都放在本地.

下面的图展示了 Subversion 是如何被使用的:

对于 Mercurial, 每个开发人员在自己 PC 上有自己的版本库:

只要你愿意, 你可以随时提交提交代码到你的私人版本库, 从版本控制中获益. 每当你的代码到达一定的逻辑点, 你都可以将代码提交.

等到代码比较稳定后, 你想让其他人使用你的新代码, 你可以将你所做的变更 push 到中央版本库. 其他人从中央版本库 pull 代码后, 就可以看到你的代码了.

提交新代码 和 影响他人工作的操作, Mercurial 将这两者分割成两个步骤.

这意味着你提交后 (hg com) 不会影响到其他人. 等到你完成一系列修改, 代码相对稳定后你可以将变更 push (hg push) 到中央版本控制库.

Subversion 采用 revisions (修订号) 的方式. 修订号看起来就像是某个时间点整个文件系统的一个快照.

Mercurial 则采用 changesets (变更集) 的方式. 变更集是版本与版本之间变更情况的简明列表.

由于 Mercurial 把所有事情都当作变更集 (changesets) 处理, 你可以借此来做一些有趣的事情. 你可以将它们 push 给你团队中的朋友试用, 而不是 push 到中央库摧残所有组员.

Subversion 的版本控制是基于 文件 的. 但是 Mercurial 的版本控制是作用于整个目录 – 包括所有的子目录.

在 Subversion 中你可以通过以下方法注意到这一点. 你在子文件夹进行 commit 操作的时候, 只会对当前目录和当前目录的所有子目录生效, 这样很可能导致你忘记提交其它目录的变更. 相反, Mercurial 的所有命令都是针对整个库的. 如果你的代码放在 c:/code, 不管你是在 c:/code 或是任何 c:/code 的子目录下执行 hg commit 命令, 效果都是一样的.

Mercurial 从零开始

大部分人在命令行下使用 Mercurial, 命令行在 Windows, Unix, 和 Mac 下都可以很好的工作. 执行 Mercurial 的命令是 hg.

单单输入 hg 不加任何选项, 会列出最常用的命令. 你也可以试试 hg help 来得到完整的命令列表.