|
Size: 10261
Comment:
|
← Revision 19 as of 2012-11-11 13:29:56 ⇥
Size: 10214
Comment: remove link to deleted page "SCM"
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| 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: [[BrazilianPortugueseUnderstandingMercurial|Brazilian Portuguese]], [[ChineseUnderstandingMercurial|Chinese]], [[FrenchUnderstandingMercurial|French]], [[GermanUnderstandingMercurial|German]], [[ItalianUnderstandingMercurial|Italian]], [[JapaneseUnderstandingMercurial|Japanese]], [[KoreanUnderstandingMercurial|Korean]], [[RussianUnderstandingMercurial|Russian]], [[SpanishUnderstandingMercurial|Spanish]], [[ThaiUnderstandingMercurial|Thai]] )'' |
#pragma section-numbers 2 = 理解 Mercurial = Mercurial 的分布式协同模式,对于新手而言是混乱的, 本文试图澄清一些基本概念,至于 hg 的使用,请参考:[[ChineseTutorial|教程]]. ''(Translations: [[ChineseUnderstandingMercurial|中文（简体）]], [[FrenchUnderstandingMercurial|French]], [[GermanUnderstandingMercurial|German]], [[ItalianUnderstandingMercurial|Italian]], [[JapaneseUnderstandingMercurial|Japanese]], [[KoreanUnderstandingMercurial|Korean]], [[RussianUnderstandingMercurial|Russian]], [[SpanishUnderstandingMercurial|Spanish]], [[ThaiUnderstandingMercurial|Thai]] )'' |
| Line 20: | Line 9: |
| == What's in a Repository == Mercurial [[Repository|repositories]] contain a [[WorkingDirectory|working directory]] coupled with a store: |
== 仓库(Repository)中有什么? == Mercurial [[Repository|仓库(Repository)]] 包含 [[WorkingDirectory|工作目录(Working Directory)]] 和版本仓库: |
| Line 48: | Line 36: |
The store contains the '''complete''' history of the project. Unlike traditional [[SCM|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. The working directory contains a copy of the project's files at a given point in time (eg rev 2), ready for editing. Because [[Tag|tags]] and [[.hgignore|ignored files]] are revision-controlled, they are also included. == Committing Changes == When you [[Commit|commit]], the state of the working directory relative to its [[Parent|parents]] is recorded as a new [[ChangeSet|changeset]] (also called a new "[[Revision|revision]]"): |
版本仓库^存在于.hg隐藏目录中^包含了'''完整'''的项目历史. 不同与其它配置管理系统,那些集中式版本管理系统,只有一个包含所有版本历史的中央仓库,而每人本地的工作目录则仅包含当前最新版本. 这将有利于开发者进行并行协作. 工作目录包含的是项目文件当供给编辑的在某个时间点的状态（比如上图中的rev 2）. Mercurial中的[[Tag|标签]] 和 [[.hgignore|忽略文件声明]] 也被版本控制，所以他们也包括在上图中. Mercurial中的每个版本都有其`父辈版本`，比如上图中rev 2的父辈是rev 1，而工作目录的父辈是rev 2. == 提交变更(Commit Changes) == [[Commit|提交(Commit)]]操作后，工作目录的 [[Parent|父辈版本]] 就成了刚刚提交的新 [[ChangeSet|变更集(Changeset)]] (也称为新 "[[Revision|版本(Revision)]]"): |
| Line 84: | Line 71: |
Note here that revision 4 is a '''[[Branch|branch]]''' of revision 2, which was the revision in the working directory. Now revision 4 is the working directory's '''parent'''. == Revisions, Changesets, Heads, and Tip == Mercurial groups related changes to multiple files into single atomic [[ChangeSet|changesets]], which are revisions of the whole project. These each get a sequential [[RevisionNumber|revision number]]. Because Mercurial allows distributed parallel development, these revision numbers may disagree between users. So Mercurial also assigns each revision a global [[ChangeSetID|changeset ID]]. Changeset IDs are 40-digit hexadecimal numbers, but they can be abbreviated to any unambiguous prefix, like "e38487". |
上图中的`rev 4`是`rev 2`的一个'''[[Branch|分支]]''', 现在`rev 4`是工作目录的'''父辈'''. == 版本,变更集,头部,顶部 == Mercurial中多个文件的相关修改称为[[ChangeSet|变更集(ChangeSet)]], 每个`版本(Revision)`对应一个变更集. 每个变更集会分配一个递增的整数 [[RevisionNumber|版本号]]. 在分布式开发过程中, 各个用户的版本号会产生冲突. 因此每个变更及也会被分配一个全局唯一的[[ChangeSetID|变更集ID]]. 变更集ID是四十位的16进制数字, 也可以略写成足够明确的"e38487"形式. |
| Line 115: | Line 99: |
Branches and [[Merge|merges]] in the revision history can occur at any point. Each unmerged branch creates a new [[Head|head]] of the revision history. Here, revisions 5 and 6 are heads. Mercurial considers revision 6 to be the [[Tip|tip]] of the repository, the head with the highest revision number. Revision 4 is a [[MergeChangeset|merge changeset]], as it has ''two'' parent changesets (revisions 2 and 3). == Cloning, Making Changes, Merging, Pulling and Updating == Let's start with a user Alice, who has a repository that looks like: |
在版本历史的任何一点,都可以进行分支与[[Merge|合并(Merge)]]. 而每一个未合并的分支,实际都创建了版本历史的一个新[[Head|头部(Head)]]. Here, revisions 5 and 6 are heads. Mercurial considers revision 6 to be the [[Tip|tip]] of the repository, the head with the highest revision number. 上图中的`rev 5`和`rev 6`都是头部. 版本号最大的头部被称为[[Tip|顶部]], 如上图中的`rev 6`. `rev 4`有'''两个'''父辈(`rev 2` 和`rev 3`)，它是个[[MergeChangeset|合并变更集]]. == 克隆,变更,合并,拉和更新 == 假设用户Alice有如下所示的仓库: |
| Line 132: | Line 114: |
Bob [[Clone|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 在本地[[Clone|克隆(Clone)]]了这个仓库, 得到了Alice的版本仓库的一个完整、独立的本地副本. 并通过检出操作,获得了最新`顶部`版本. |
| Line 144: | Line 124: |
Bob can now work independently of Alice. He then [[Commit|commits]] two changes e and f: |
Bob[[Commit|提交(Commit)]]两个修改`e`和`f` ^在他本地仓库^: |
| Line 157: | Line 136: |
Alice then makes her own change g in parallel, which causes her repository store to diverge from Bob's, thus creating a [[Branch|branch]]: |
同时，Alice也修改她的版本`g`, 因此她的仓库与Bob的不同了, 也就是说，她创建了一个 [[Branch|分支(Branch)]]: |
| Line 170: | Line 147: |
Bob then [[Pull|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: |
Bob使用[[Pull|pulls]]^拉^操作将Alice的仓库变更到本地. 这个操作将Alice的所有修改集更新到Bob的`版本仓库`中 (这个例子中只有一个修改集g). 需要注意的是，这个操作并 '''没有''' 更改Bob的工作目录: |
| Line 187: | Line 163: |
Because Alice's '''g''' is the newest head in Bob's repository, it's now the '''tip'''. Bob then does a [[Merge|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): |
因为Alice's '''g''' 版本是最新的`头部`, 因此此版本也是 '''tip'''^顶部^. Bob随后进行了 [[Merge|合并]] 操作, 将其本地修改(f)与仓库中的'''tip'''进行合并. 这时, 他的工作目录具有两个父辈(f和g): |
| Line 207: | Line 181: |
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 [[MergeChangeset|merge changeset]] h in his store: |
查看并确认操作合并成功后, Bob 提交合并结果，得到了一个新的 [[MergeChangeset|合并变更集]] `h`在他的本地仓库中: |
| Line 228: | Line 199: |
Now if Alice '''pulls''' from Bob, she will get Bob's changes e, f, and h into her store: |
现在，如果Alice '''pulls''' 从 Bob的仓库, 她会得到Bob的变更 `e`, `f`和`h`: |
| Line 247: | Line 217: |
Note that Alice's working directory was not changed by the pull. She has to do an [[Update|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. |
注意! 当前 Alice 的工作目录并没有因 pull^拉^操作而改变. 她必须使用 [[Update|更新(Update)]] 操作来同步版本仓库到合并变更集 `h`. 这将改变她版本仓库的父辈到`h`,并将工作目录中的文件更新成`h`版本的. |
| Line 268: | Line 235: |
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): |
Alice和Bob完全同步了. == 分布式系统 == Mercurial是一个完全的分布式系统, 因此没有所谓的集中式仓库概念. 这也意味着用户可以自由的定义协同工作的组织结构 (参阅 [[CommunicatingChanges|变更传播]] ): |
| Line 293: | Line 257: |
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 [[subrepos|Subrepositories]] feature that was introduced with Mercurial 1.3 or the older ForestExtension. For a hands-on introduction to using Mercurial, see the [[Tutorial]]. |
在一个集中式版本管理系统中提交实验性的修改可能会造成较大的负面影响, 但对于Mercurial之类的DVCS来说, 可以肆意的进行试验性操作， 大不了删除本地工作目录，因为在别的地方还有若干完整的。 == 什么是Mercurial不能作的 == SVN/CVS用户会将多个相关的项目放在同一个仓库里. 但是这真的不应该在Hg 中这么做,因为在Hg 中你只能检出整个仓库，而不是其中的某个目录. 如果确实想要将多个项目放在同一个仓库中, 可以使用1.3版本以后的[[ChineseSubrepository|子仓库]] 功能或者更老版本的 ForestExtension 将不同项目的仓库,嵌套成一个大仓库. 关于Mercurial的入门操作, 请参阅 [[ChineseTutorial|教程]]. ---- CategoryChinese CategoryChinese |
理解 Mercurial
Mercurial 的分布式协同模式,对于新手而言是混乱的, 本文试图澄清一些基本概念,至于 hg 的使用,请参考:教程.
(Translations: 中文（简体）, French, German, Italian, Japanese, Korean, Russian, Spanish, Thai )
1. 仓库(Repository)中有什么?
Mercurial 仓库(Repository) 包含 工作目录(Working Directory) 和版本仓库:
版本仓库存在于.hg隐藏目录中包含了完整的项目历史. 不同与其它配置管理系统,那些集中式版本管理系统,只有一个包含所有版本历史的中央仓库,而每人本地的工作目录则仅包含当前最新版本. 这将有利于开发者进行并行协作.
工作目录包含的是项目文件当供给编辑的在某个时间点的状态（比如上图中的rev 2）. Mercurial中的标签 和 忽略文件声明 也被版本控制，所以他们也包括在上图中.
Mercurial中的每个版本都有其父辈版本，比如上图中rev 2的父辈是rev 1，而工作目录的父辈是rev 2.
2. 提交变更(Commit Changes)
提交(Commit)操作后，工作目录的 父辈版本 就成了刚刚提交的新 变更集(Changeset) (也称为新 "版本(Revision)"):
上图中的rev 4是rev 2的一个分支, 现在rev 4是工作目录的父辈.
3. 版本,变更集,头部,顶部
Mercurial中多个文件的相关修改称为变更集(ChangeSet), 每个版本(Revision)对应一个变更集. 每个变更集会分配一个递增的整数 版本号. 在分布式开发过程中, 各个用户的版本号会产生冲突. 因此每个变更及也会被分配一个全局唯一的变更集ID. 变更集ID是四十位的16进制数字, 也可以略写成足够明确的"e38487"形式.
在版本历史的任何一点,都可以进行分支与合并(Merge). 而每一个未合并的分支,实际都创建了版本历史的一个新头部(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都是头部. 版本号最大的头部被称为顶部, 如上图中的rev 6. rev 4有两个父辈(rev 2 和rev 3)，它是个合并变更集.
4. 克隆,变更,合并,拉和更新
假设用户Alice有如下所示的仓库:
Bob 在本地克隆(Clone)了这个仓库, 得到了Alice的版本仓库的一个完整、独立的本地副本. 并通过检出操作,获得了最新顶部版本.
Bob提交(Commit)两个修改e和f 在他本地仓库:
同时，Alice也修改她的版本g, 因此她的仓库与Bob的不同了, 也就是说，她创建了一个 分支(Branch):
Bob使用pulls拉操作将Alice的仓库变更到本地. 这个操作将Alice的所有修改集更新到Bob的版本仓库中 (这个例子中只有一个修改集g).
需要注意的是，这个操作并 没有 更改Bob的工作目录:
因为Alice's g 版本是最新的头部, 因此此版本也是 tip顶部.
Bob随后进行了 合并 操作, 将其本地修改(f)与仓库中的tip进行合并. 这时, 他的工作目录具有两个父辈(f和g):
查看并确认操作合并成功后, Bob 提交合并结果，得到了一个新的 合并变更集 h在他的本地仓库中:
现在，如果Alice pulls 从 Bob的仓库, 她会得到Bob的变更 e, f和h:
注意! 当前 Alice 的工作目录并没有因 pull拉操作而改变. 她必须使用 更新(Update) 操作来同步版本仓库到合并变更集 h. 这将改变她版本仓库的父辈到h,并将工作目录中的文件更新成h版本的.
Alice和Bob完全同步了.
5. 分布式系统
Mercurial是一个完全的分布式系统, 因此没有所谓的集中式仓库概念. 这也意味着用户可以自由的定义协同工作的组织结构 (参阅 变更传播 ):
在一个集中式版本管理系统中提交实验性的修改可能会造成较大的负面影响, 但对于Mercurial之类的DVCS来说, 可以肆意的进行试验性操作， 大不了删除本地工作目录，因为在别的地方还有若干完整的。
6. 什么是Mercurial不能作的
SVN/CVS用户会将多个相关的项目放在同一个仓库里. 但是这真的不应该在Hg 中这么做,因为在Hg 中你只能检出整个仓库，而不是其中的某个目录.
如果确实想要将多个项目放在同一个仓库中, 可以使用1.3版本以后的子仓库 功能或者更老版本的 ForestExtension 将不同项目的仓库,嵌套成一个大仓库.
关于Mercurial的入门操作, 请参阅 教程.