|
Size: 12576
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|中文（简体）]], [[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 7: | Line 9: |
| == What's in a Repository == Mercurial [[Repository|repositories]] 的 [[WorkingDirectory|working directory]] （工作目录）内部包含了store: |
== 仓库(Repository)中有什么? == Mercurial [[Repository|仓库(Repository)]] 包含 [[WorkingDirectory|工作目录(Working Directory)]] 和版本仓库: |
| Line 34: | Line 36: |
| 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中的[[Tag|标签]] 和 [[.hgignore|ignored files]] 也被版本控制，所以他们也包括在上图中. Mercurial中的每个版本和工作目录都有parent，比如上图中rev 2的parent是rev 1，而工作目录的parent是rev 2. == 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]]"): [[Commit|提交]]操作后，工作目录的 [[Parent|parents]] 就成了刚刚提交的新的 [[ChangeSet|changeset]] (也称为新 "[[Revision|版本]]"): |
版本仓库^存在于.hg隐藏目录中^包含了'''完整'''的项目历史. 不同与其它配置管理系统,那些集中式版本管理系统,只有一个包含所有版本历史的中央仓库,而每人本地的工作目录则仅包含当前最新版本. 这将有利于开发者进行并行协作. 工作目录包含的是项目文件当供给编辑的在某个时间点的状态（比如上图中的rev 2）. Mercurial中的[[Tag|标签]] 和 [[.hgignore|忽略文件声明]] 也被版本控制，所以他们也包括在上图中. Mercurial中的每个版本都有其`父辈版本`，比如上图中rev 2的父辈是rev 1，而工作目录的父辈是rev 2. == 提交变更(Commit Changes) == [[Commit|提交(Commit)]]操作后，工作目录的 [[Parent|父辈版本]] 就成了刚刚提交的新 [[ChangeSet|变更集(Changeset)]] (也称为新 "[[Revision|版本(Revision)]]"): |
| Line 69: | Line 71: |
| 上图中的re 4是rev 2的一个'''[[Branch|分支]]''', 同时工作目录的版本也更新为rev 4. 现在rev 4是工作目录的'''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". Mercurial中多个文件的相关修改称为[[ChangeSet|变更集]], 每个revision对应一个变更集. 每个变更集会分配一个递增的整数 [[RevisionNumber|版本号]]. 在分布式开发过程中, 各个用户的版本号会产生冲突. 因此每个变更及也会被分配一个全局唯一的[[ChangeSetID|变更集ID]]. 变更集ID是四十位的16进制数字, 如果前缀相同，也可以省略前缀，简写成"e38487"的形式. |
上图中的`rev 4`是`rev 2`的一个'''[[Branch|分支]]''', 现在`rev 4`是工作目录的'''父辈'''. == 版本,变更集,头部,顶部 == Mercurial中多个文件的相关修改称为[[ChangeSet|变更集(ChangeSet)]], 每个`版本(Revision)`对应一个变更集. 每个变更集会分配一个递增的整数 [[RevisionNumber|版本号]]. 在分布式开发过程中, 各个用户的版本号会产生冲突. 因此每个变更及也会被分配一个全局唯一的[[ChangeSetID|变更集ID]]. 变更集ID是四十位的16进制数字, 也可以略写成足够明确的"e38487"形式. |
| Line 99: | 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. 可以再任何时候进行分支和[[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是head. 版本号最大的head被称为[[Tip|tip]], 如上图中的rev 6. rev 4有''两个''parent(rev 2 和rev 3)，它是个[[MergeChangeset|合并变更集]]. == Cloning, Making Changes, Merging, Pulling and Updating == 假设用户Alice有如下所示的repository: |
在版本历史的任何一点,都可以进行分支与[[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 114: | Line 114: |
| Bob [[Clone|拷贝]] 了这个repo, 得到了Alice的store的一个完整、独立的本地拷贝。本地拷贝进行签出操作，他的工作目录对应到tip版本. | Bob 在本地[[Clone|克隆(Clone)]]了这个仓库, 得到了Alice的版本仓库的一个完整、独立的本地副本. 并通过检出操作,获得了最新`顶部`版本. |
| Line 124: | Line 124: |
| Bob[[Commit|提交]]两个修改e和f: | Bob[[Commit|提交(Commit)]]两个修改`e`和`f` ^在他本地仓库^: |
| Line 136: | Line 136: |
| 同时，Alice提交了她的修改g, 因此她的repository与Bob的不同了, 也就是说，她创建了一个 [[Branch|分支]]: | 同时，Alice也修改她的版本`g`, 因此她的仓库与Bob的不同了, 也就是说，她创建了一个 [[Branch|分支(Branch)]]: |
| Line 147: | 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的repo同步到本地. 这个操作将Alice的所有修改集更新到Bob的repository store中 (这个例子中只有一个修改集g). 需要注意的是，这个操作并 '''没有''' 更改Bob的工作目录: | Bob使用[[Pull|pulls]]^拉^操作将Alice的仓库变更到本地. 这个操作将Alice的所有修改集更新到Bob的`版本仓库`中 (这个例子中只有一个修改集g). 需要注意的是，这个操作并 '''没有''' 更改Bob的工作目录: |
| Line 161: | Line 163: |
| Because Alice's '''g''' is the newest head in Bob's repository, it's now the '''tip'''. 因为Alice's '''g''' 版本是最新的head, 因此此版本也是 '''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): Bob随后进行了 [[Merge|合并]] 操作, 将其本地修改(f)与repository中的tip进行合并. 这时, 他的工作目录具有两个parent(f和g): |
因为Alice's '''g''' 版本是最新的`头部`, 因此此版本也是 '''tip'''^顶部^. Bob随后进行了 [[Merge|合并]] 操作, 将其本地修改(f)与仓库中的'''tip'''进行合并. 这时, 他的工作目录具有两个父辈(f和g): |
| Line 179: | 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: | 查看并确认操作合并成功后, Bob 提交合并结果，得到了一个新的 [[MergeChangeset|合并变更集]] `h`在他的本地仓库中: |
| Line 197: | Line 199: |
| Now if Alice '''pulls''' from Bob, she will get Bob's changes e, f, and h into her store: 现在，如果Alice '''pulls''' from Bob, 她会得到Bob的变更e, f和h: | 现在，如果Alice '''pulls''' 从 Bob的仓库, 她会得到Bob的变更 `e`, `f`和`h`: |
| Line 215: | 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 233: | 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): Mercurial是一个完全的分布式系统, 因此没有所谓的集中式repository概念. 这也意味着用户可以自由的定义协同工作的组织结构 (参阅 CommunicatingChanges): |
Alice和Bob完全同步了. == 分布式系统 == Mercurial是一个完全的分布式系统, 因此没有所谓的集中式仓库概念. 这也意味着用户可以自由的定义协同工作的组织结构 (参阅 [[CommunicatingChanges|变更传播]] ): |
| Line 255: | 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. 在一个集中式版本管理系统中提交实验性的修改可能会造成较大的负面影响, 但对于Mercurial之类的DVCS来说, 可以肆意的进行试验性操作， 大不了删除本地工作目录，因为在别的地方还有若干。 == 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. SVN/CVS用户会将多个相关的项目放在同一个repository里. This is really not what hg was made for, so you should try a different way of working. 也就是说，只能签出整个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. 如果确实想要将多个项目放在同一个repository中, 可以使用1.3版本中的[[subrepos|Subrepositories]] 功能或者更老版本的ForestExtension. 关于Mercurial的入门操作, 请参阅 [[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的入门操作, 请参阅 教程.