分布式版本控制工具 Mercurial 使用

浏览仓库历史：log

这些输出行的含义是这样的。

• 每一段描述一个特定的改变集。一个或几个文件的改变集合在一起形成一个逻辑单元，称为改变集。

  • 在上面的例子中，我们可以看到该仓库 的历史包括了两个改变集。

• changeset 标识了一个 改变集.

  • 冒号前面的数字代表版本号; 它是一种标识改变集的本地缩写.只是在你的本地仓库中这个版本号才有意义.

  • 冒号后面的那个很长的十六进制串是 ChangeSetID; 它是标识改变集的全局唯一标识符, 在所有包含这个改变集的仓库中都相同. 如果你正在和其他人讨论某个改变集,请使用这个 ChangeSetID,而不是上面说的版本号.

• tag 是一个标签,可以理解成为一个改变集指定的名字.

  • 你可以给任何改变集指定一个或者多个标签. 实际上, 许多改变集都是没有标签的, 所以tag这一行很多时候都不存在.

  • 名叫tip 的特殊标签总是表示，它是仓库中最后一个改变集。 如果你创建另外的改变集（一会我们会看到），那么它将会变成 Tip。

• user 确定了谁创建了本改变集。这是一个无格式的字符串; 它通常包括电子邮件地址，个人姓名等。

• date 描述了改变集是什么时候创建的。这些时间是创建改变集的人所在区域的当地时间。

• summary 给出了改变集描述的首行。它是在创建改变集时进入的，它可以帮助创建者和其它人了解改变集的目的。

• parent 标志了改变集的父辈，当你从几个仓库合并而来的情况下，父辈有多个。

• • 大多数情况只有一个父辈，它比目前的改变集旧。这是在我们例子中使用的。

我们可以通过指定-v诊断输出选项来获得更多更详细的历史信息, 或者指定--debug选项来获得历史信息中的一切细节:

log -v

--v的输出比缺省输出要多。

• changeset 给出不缩略的改变集标号。

• files 列出在本改变集中文件的改变。

• description 包含了改变集的完整多行描述而不仅是头一行。

log --debug

--debug 给谓词输出添加了以下方面：

• file+ 列出了在此改变集中增加的文件。

• file- 列出了在此改变集中删除的文件。

• manifest 给这个改变集一个 Manifest 号。

• 两个 parent 域给这个改变集的两个父辈号码，1:0000000000000000000000000000000000000000 表示没有父改变集。

log 命令与 -r 选项一起使用可以查看特定改变集。

log 命令与 -p 选项一起可以显示和此改变集相关联的补丁。

log -r tip 来显示 tip 的信息，如最后的改变集。

提交更集：commit

创建一个变更集的动作称为提交它。我们用commit命令来执行提交。

万一我们希望放弃我们的变更并重新开始，我们可以用revert命令来恢复到我们没有更改的状态。

与别的仓库分享改变：

我们用 pull 命令，这个命令所有在别的仓库中有而在本仓库中没没有的 ChangeSet 从别的仓库 Pull 到本仓库。

不像其它普通的 Mercurial 命令，pull 有点罗嗦。在这点上 Pull 是成功的。

最近一行输出是重要的。在 Pull 后，缺省情况下 Mercurial 不更新工作目录。这意味着虽然Repository 现在有变更集， 但在工作目录中的 hello.c 文件仍然是Pull 之前老的内容。我们可以用以下Mercurial的提醒来 Update 这个文件 (也包括所有其它 Pull 时改变的文件）。

和别人分享改变：

我们提交(Commit)改变后， 我们可以导出(Export) 它到一个文件里，并把这个文件作为附件 email 给其它人。我们用 export 命令来 导出(Export) 改变。我们必需提供一个 Tag, 版本号或 变更集号 来告诉 Mercurial 有什么进入了 导出(Export)。

缺省情况下，导出(Export)只显示补丁，所以我们通常把输出重定向到一个文件中。这个文件是一个 UnifiedDiff 格式的补丁文件，这个文件还带了一些扩展的信息告诉 Mercurial 如何 导入(Import) 它.

当收件人收到我们的邮件，他们将保存附件并使用 import 命令来把变更集导入(Import)到他们的仓库中去。 (在0.7版本中， Mercurial 忽略了其中的一些信息，做导入(import)会引起一合并的问题。)

合并改变：merge

首先, 我们再次 Clone 仓库，我们必须创建合并的目标，然后 Commit 我们的变更. 这次, 我们在commit命令中使用-m 选项来节省时间, 以免我们又要进入编辑器。

合并有冲突的改变：

很平常的情况是两个人同时更改同一个文件的同一段代码，然后必须给出处理的方法。这称之为冲突；处理这类冲突称之为合并。

Mercurial 使用了三路合并。 这就意味着有三个文件来做合并，分别是：

• 本地文件（当前仓库）
• 其它文件（正在被合并的仓库）
• 基文件 (在分支分开前的最后一个版本）

另外，如果我们没有安装图形合并程序， 我们就会开启文本编辑器来访问需要合并的文件。用手工来做这些事情是非常容易出错并且繁琐的。 最好是退出编辑器并用hg rollback指令来清除［"Pull"]带来的改变，然后安装合并程序，再做一次。

[@more@]１，hg version 查看版本状态
２，配置用户名
ＵＮＩＸ　 　　　.hgrc　　in your home directory
ＷＩＮＤＯＷＳ　　　%USERPROFILE%Mercurial.ini　
[ui]
username = John Doe
３，创建库[.hg]
hg init
４，克隆库[.hg]
hg clone http://www.selenic.com/repo/hello my-hello
hg parents
５，添加文件
hg add *
６，形成一个版本
hg commit -m "adding initial version of hello.txt"
７,差异
hg diff
diff -r 82e55d328c8c hello.c
8,恢复
hg revert hello.c
==>
rm hello.c
mv hello.c.orig hello.c
hg st -> M hello.c
9，历史查看[changeset]
所有历史: 　　　　　hg log
所有详细历史查看:　　hg log -v
针对版本的查看:　　　hg log -r1
针对版本的查看和pathes: hg log -r1 -p
最新的版本：　 hg log -r tip
10,共享变更
查看不同的ｃｈａｎｇｅｓｅｔ　　　　hg -q tip
从新库带来变更 　　　hg pull 新库位置
（run 'hg update' to get a working copy)
$ hg pull ../my-hello-new-output
$ hg push ../my-hello-new-output
If both of these give a 'no changes found', that means the repositories are identical.
从新库带来变更 　　　hg pull 新库位置
(run 'hg heads' to see heads, 'hg merge' to merge)
hg heads
hg glog
hg update
abort: crosses branches (use 'hg merge' or 'hg update -C')
hg merge
merging hello.c
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
hg commit -m "Merged changes from my-hello-new-output"
hg annotate hello.c
use the annotate command to show changeset information per file line
hg resolve -m hello.c

１１，把变更共享给他人
hg export tip　[export just displays the patch, so usually we redirect the output to a file (or use option -o).]
This file is a patch file in unified diff format, with some extra information that tells Mercurial how to import it.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25556693/viewspace-1049634/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25556693/viewspace-1049634/