ChineseUnderstandingMercurial

Mercurial's decentralized development model can be confusing to new users. This page attempts to illustrate some of the basic concepts. See the Tutorial for step-by-step instructions.中文翻译

(Translations: Brazilian Portuguese, 中文（简体）, French, German, Italian, Japanese, Korean, Russian, Spanish, Thai )

What's in a Repository

Mercurial repositories 的 working directory （工作目录）内部包含了store:

store保存了项目完整的历史记录. 与传统的SCMs不同的是, where there's only one central copy of this history, every working directory is paired with a private copy of the history. This allows development to go on in parallel.

working directory记录的是项目文件在某个时间点的状态（比如上图中的rev 2）. Mercurial中的标签 和 ignored files 也被版本控制，所以他们也包括在上图中.

Mercurial中的每个版本和工作目录都有parent，比如上图中rev 2的parent是rev 1，而工作目录的parent是rev 2.

Committing Changes

When you commit, the state of the working directory relative to its parents is recorded as a new changeset (also called a new "revision"): 提交操作后，工作目录的　parents　就成了刚刚提交的新的 changeset (也称为新 "版本"):

上图中的re 4是rev 2的一个分支, 同时工作目录的版本也更新为rev 4. 现在rev 4是工作目录的parent.

Revisions, Changesets, Heads, and Tip

Mercurial groups related changes to multiple files into single atomic changesets, which are revisions of the whole project. These each get a sequential revision number. Because Mercurial allows distributed parallel development, these revision numbers may disagree between users. So Mercurial also assigns each revision a global changeset ID. Changeset IDs are 40-digit hexadecimal numbers, but they can be abbreviated to any unambiguous prefix, like "e38487".

Mercurial中多个文件的相关修改称为变更集, 每个revision对应一个变更集. 每个变更集会分配一个递增的整数 版本号. 在分布式开发过程中, 各个用户的版本号会产生冲突. 因此每个变更及也会被分配一个全局唯一的变更集ID. 变更集ID是四十位的16进制数字, 如果前缀相同，也可以省略前缀，简写成"e38487"的形式.

Branches and merges in the revision history can occur at any point. Each unmerged branch creates a new head of the revision history. 可以再任何时候进行分支和合并操作. 每个未合并的分支会创建一个新的head.

Here, revisions 5 and 6 are heads. Mercurial considers revision 6 to be the tip of the repository, the head with the highest revision number. 上图中的rev 5和rev 6是head. 版本号最大的head被称为tip, 如上图中的rev 6. rev 4有两个parent(rev 2 和rev 3)，它是个合并变更集.

Cloning, Making Changes, Merging, Pulling and Updating

Let's start with a user Alice, who has a repository that looks like:

Bob clones this repo, and ends up with a complete, independent, local copy of Alice's store and a clean checkout of the tipmost revision d in his working directory:

Bob can now work independently of Alice. He then commits two changes e and f:

Alice then makes her own change g in parallel, which causes her repository store to diverge from Bob's, thus creating a branch:

Bob then pulls Alice's repo to synchronize. This copies all of Alice's changes into Bob's repository store (here, it's just a single change g). Note that Bob's working directory is not changed by the pull:

Because Alice's g is the newest head in Bob's repository, it's now the tip.

Bob then does a merge, which combines the last change he was working on (f) with the tip in his repository. Now, his working directory has two parent revisions (f and g):

After examining the result of the merge in his working directory and making sure the merge is perfect, Bob commits the result and ends up with a new merge changeset h in his store:

Now if Alice pulls from Bob, she will get Bob's changes e, f, and h into her store:

Note that Alice's working directory was not changed by the pull. She has to do an update to synchronize her working directory to the merge changset h. This changes the parent changeset of her working directory to changeset h and updates the files in her working directory to revision h.

Now Alice and Bob are fully synchronized again.

A Decentralized System

Mercurial is a completely decentralized system, and thus has no internal notion of a central repository. Thus users are free to define their own topologies for sharing changes (see CommunicatingChanges):

Unlike a centralized version control system in which experimentation can be disastrous, with a DVCS like Mercurial, you just clone and experiment. If you like the results, push them back, otherwise wipe the cloned repository and try something else.

What Mercurial can't do

Many SVN/CVS users expect to host related projects together in one repository. This is really not what hg was made for, so you should try a different way of working. This especially means, that you cannot check out only one directory of a repository.

If you absolutely need to host multiple projects in a kind of meta-repository though, you could try the Subrepositories feature that was introduced with Mercurial 1.3 or the older ForestExtension.

For a hands-on introduction to using Mercurial, see the Tutorial.