|
Size: 11053
Comment: testing dot chinese
|
Size: 10053
Comment: finished chinese version
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 9: | Line 9: |
| ''(Translations: [[BrazilianPortugueseUnderstandingMercurial|Brazilian Portuguese]], [[ChineseUnderstandingMercurial|中文（简体）]], [[FrenchUnderstandingMercurial|French]], [[GermanUnderstandingMercurial|German]], [[ItalianUnderstandingMercurial|Italian]], [[JapaneseUnderstandingMercurial|Japanese]], [[KoreanUnderstandingMercurial|Korean]], [[RussianUnderstandingMercurial|Russian]], [[SpanishUnderstandingMercurial|Spanish]], [[ThaiUnderstandingMercurial|Thai]] )'' | ''(Translations: [[ChineseUnderstandingMercurial|中文（简体）]], [[FrenchUnderstandingMercurial|French]], [[GermanUnderstandingMercurial|German]], [[ItalianUnderstandingMercurial|Italian]], [[JapaneseUnderstandingMercurial|Japanese]], [[KoreanUnderstandingMercurial|Korean]], [[RussianUnderstandingMercurial|Russian]], [[SpanishUnderstandingMercurial|Spanish]], [[ThaiUnderstandingMercurial|Thai]] )'' |
| Line 15: | Line 15: |
| Mercurial [[Repository|仓库]] 包含 [[WorkingDirectory|工作索引]] 组成的仓库: | Mercurial [[Repository|仓库]] 包含 [[WorkingDirectory|工作目录]] 和版本仓库: |
| Line 23: | Line 23: |
| label="工作索引"; | label="Working Directory"; |
| Line 41: | Line 41: |
| The store contains the '''complete''' history of the project. Unlike traditional [[SCM|SCMs]], where there's only one central copy of this history, == What's in a Repository == Mercurial [[Repository|repositories]] 的 [[WorkingDirectory|working directory]] （工作目录）内部包含了store: {{{#!dot digraph G { rankdir = LR; compound=true; background="#999999"; subgraph cluster_0 { label="working directory"; style=filled; color=lightgrey; node [style=filled,color=white]; edge [style=invis]; "main.c" -> "main.h" -> ".hgignore" -> ".hgtags"; } subgraph cluster_1 { label = "store"; labelloc = b; style=filled; color="#eeeeee"; node [shape=box, style=filled, color=lightgray]; "rev 0" -> "rev 1" -> "rev 2" -> "rev 3" [dir=back, label="parent"]; } "main.c" -> "rev 2" [ltail=cluster_0, label="parent", labeldistance=5, minlen=2]; } }}} 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 == [[Commit|提交]]操作后，工作目录的 [[Parent|parents]] 就成了刚刚提交的新的 [[ChangeSet|changeset]] (也称为新 "[[Revision|版本]]"): |
版本仓库^存在与.hg隐藏目录中^包含了'''完整'''的项目历史. 不同与其它[[SCM|配置管理系统]],那些集中式版本管理系统,只有一个中央仓库,包含所有版本历史, 每人本地的工作目录,仅包含当前最新版本. 这将有利于开发者进行并行协作. 工作目录包含的是项目文件当供给编辑的在某个时间点的状态（比如上图中的rev 2）. Mercurial中的[[Tag|标签]] 和 [[.hgignore|忽略文件聲明]] 也被版本控制，所以他们也包括在上图中. Mercurial中的每个版本都有其`父辈版本`，比如上图中rev 2的parent是rev 1，而工作目录的parent是rev 2. == 变更检入 == [[Commit|检入]]操作后，工作目录的 [[Parent|父辈版本]] 就成了刚刚检入的新 [[ChangeSet|变更集]] (也称为新 "[[Revision|版本]]"): |
| Line 105: | Line 81: |
| 上图中的re 4是rev 2的一个'''[[Branch|分支]]''', 同时工作目录的版本也更新为rev 4. 现在rev 4是工作目录的'''parent'''. == Revisions, Changesets, Heads, and Tip == Mercurial中多个文件的相关修改称为[[ChangeSet|变更集]], 每个revision对应一个变更集. 每个变更集会分配一个递增的整数 [[RevisionNumber|版本号]]. 在分布式开发过程中, 各个用户的版本号会产生冲突. 因此每个变更及也会被分配一个全局唯一的[[ChangeSetID|变更集ID]]. 变更集ID是四十位的16进制数字, 如果前缀相同，也可以省略前缀，简写成"e38487"的形式. |
上图中的`rev 4`是`rev 2`的一个'''[[Branch|分支]]''', 现在`rev 4`是工作目录的'''parent'''. == 版本,变更集,头部,顶部 == Mercurial中多个文件的相关修改称为[[ChangeSet|变更集]], 每个`版本`对应一个变更集. 每个变更集会分配一个递增的整数 [[RevisionNumber|版本号]]. 在分布式开发过程中, 各个用户的版本号会产生冲突. 因此每个变更及也会被分配一个全局唯一的[[ChangeSetID|变更集ID]]. 变更集ID是四十位的16进制数字, 也可以略写成足够明确的"e38487"形式. |
| Line 133: | Line 111: |
| 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|合并]]. 而每一个未合并的分支,实际都创建了版本历史的一个新[[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 148: | Line 130: |
| Bob [[Clone|拷贝]] 了这个repo, 得到了Alice的store的一个完整、独立的本地拷贝。本地拷贝进行签出操作，他的工作目录对应到tip版本. | Bob 在本地[[Clone|克隆]]了这个仓库, 得到了Alice的版本仓库的一个完整、独立的本地复本. 并通过检出操作,获得了最新`顶部`版本. |
| Line 158: | Line 141: |
| Bob[[Commit|提交]]两个修改e和f: | Bob[[Commit|检入]]两个修改`e`和`f` ^在他本地仓库^: |
| Line 170: | Line 153: |
| 同时，Alice提交了她的修改g, 因此她的repository与Bob的不同了, 也就是说，她创建了一个 [[Branch|分支]]: | 同时，Alice检入了她的修改 `g`, 因此她的仓库与Bob的不同了, 也就是说，她创建了一个 [[Branch|分支]]: |
| Line 181: | Line 164: |
| Bob使用[[Pull|pulls]]操作将Alice的repo同步到本地. 这个操作将Alice的所有修改集更新到Bob的repository store中 (这个例子中只有一个修改集g). | Bob使用[[Pull|pulls]]^拉^操作将Alice的仓库变更到本地. 这个操作将Alice的所有修改集更新到Bob的`版本仓库`中 (这个例子中只有一个修改集g). |
| Line 197: | Line 181: |
| 因为Alice's '''g''' 版本是最新的head, 因此此版本也是 '''tip'''. Bob随后进行了 [[Merge|合并]] 操作, 将其本地修改(f)与repository中的tip进行合并. 这时, 他的工作目录具有两个parent(f和g): |
因为Alice's '''g''' 版本是最新的`头部`, 因此此版本也是 '''tip'''^顶部^. Bob随后进行了 [[Merge|合并]] 操作, 将其本地修改(f)与仓库中的'''tip'''进行合并. 这时, 他的工作目录具有两个父辈(f和g): |
| Line 215: | Line 199: |
| 查看并确认合并操作成功后, Bob提交合并结果，得到了一个新的 [[MergeChangeset|合并变更集]] h: | 查看并确认操作合并成功后, Bob 检入合并结果，得到了一个新的 [[MergeChangeset|合并变更集]] `h`在他的本地仓库中: |
| Line 233: | Line 217: |
| 现在，如果Alice '''pulls''' from Bob, 她会得到Bob的变更e, f和h: | 现在，如果Alice '''pulls''' 从 Bob的仓库, 她会得到Bob的变更 `e`, `f`和`h`: |
| Line 251: | Line 235: |
| 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|更新]] 操作来同步版本仓库到合并变更集 `h`. 这将改变她版本仓库的父辈到`h`,并将工作目录中的文件更新成`h`版本的. |
| Line 271: | Line 257: |
| == A Decentralized System == Mercurial是一个完全的分布式系统, 因此没有所谓的集中式repository概念. 这也意味着用户可以自由的定义协同工作的组织结构 (参阅 CommunicatingChanges): |
== 分布式系统 == Mercurial是一个完全的分布式系统, 因此没有所谓的集中式仓库概念. 这也意味着用户可以自由的定义协同工作的组织结构 (参阅 [[CommunicatingChanges|变更传播]] ): |
| Line 291: | Line 277: |
| 在一个集中式版本管理系统中提交实验性的修改可能会造成较大的负面影响, 但对于Mercurial之类的DVCS来说, 可以肆意的进行试验性操作， 大不了删除本地工作目录，因为在别的地方还有若干。 == What Mercurial can't do == SVN/CVS用户会将多个相关的项目放在同一个repository里. This is really not what hg was made for, so you should try a different way of working. 也就是说，只能签出整个repository，而不是其中的某个目录. 如果确实想要将多个项目放在同一个repository中, 可以使用1.3版本中的[[subrepos|Subrepositories]] 功能或者更老版本的ForestExtension. 关于Mercurial的入门操作, 请参阅 [[Tutorial]]. |
在一个集中式版本管理系统中提交实验性的修改可能会造成较大的负面影响, 但对于Mercurial之类的DVCS来说, 可以肆意的进行试验性操作， 大不了删除本地工作目录，因为在别的地方还有若干完整的。 == 什么是Mercurial不能作的 == SVN/CVS用户会将多个相关的项目放在同一个仓库里. 但是这真的不应该在Hg 中这么作,因为在Hg 中你只能检出整个仓库，而不是其中的某个目录. 如果确实想要将多个项目放在同一个仓库中, 可以使用1.3版本以后的[[ChineseSubrepository|子仓库]] 功能或者更老版本的 ForestExtension 将不同项目的仓库,嵌套成一个大仓库. 关于Mercurial的入门操作, 请参阅 [[ChineseTutorial|教程]]. |
Mercurial 理解
Mercurial 的分布式協同模式,对于新手而言是混乱的, 本文试图澄清一些基本概念,至于 Hg 的使用,请参考:教程.
(Translations: 中文（简体）, French, German, Italian, Japanese, Korean, Russian, Spanish, Thai )
1. 仓库中有什么?
版本仓库存在与.hg隐藏目录中包含了完整的项目历史. 不同与其它配置管理系统,那些集中式版本管理系统,只有一个中央仓库,包含所有版本历史, 每人本地的工作目录,仅包含当前最新版本. 这将有利于开发者进行并行协作.
工作目录包含的是项目文件当供给编辑的在某个时间点的状态（比如上图中的rev 2）. Mercurial中的标签 和 忽略文件聲明 也被版本控制，所以他们也包括在上图中.
Mercurial中的每个版本都有其父辈版本，比如上图中rev 2的parent是rev 1，而工作目录的parent是rev 2.
2. 变更检入
检入操作后，工作目录的 父辈版本 就成了刚刚检入的新 变更集 (也称为新 "版本"):
上图中的rev 4是rev 2的一个分支, 现在rev 4是工作目录的parent.
3. 版本,变更集,头部,顶部
Mercurial中多个文件的相关修改称为变更集, 每个版本对应一个变更集. 每个变更集会分配一个递增的整数 版本号. 在分布式开发过程中, 各个用户的版本号会产生冲突. 因此每个变更及也会被分配一个全局唯一的变更集ID. 变更集ID是四十位的16进制数字, 也可以略写成足够明确的"e38487"形式.
在版本历史的任何一点,都可以进行分支与合并. 而每一个未合并的分支,实际都创建了版本历史的一个新头部.
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 在本地克隆了这个仓库, 得到了Alice的版本仓库的一个完整、独立的本地复本. 并通过检出操作,获得了最新顶部版本.
Bob检入两个修改e和f 在他本地仓库:
同时，Alice检入了她的修改 g, 因此她的仓库与Bob的不同了, 也就是说，她创建了一个 分支:
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拉操作而改变. 她必须使用 更新 操作来同步版本仓库到合并变更集 h. 这将改变她版本仓库的父辈到h,并将工作目录中的文件更新成h版本的.
Alice和Bob完全同步了.
5. 分布式系统
Mercurial是一个完全的分布式系统, 因此没有所谓的集中式仓库概念. 这也意味着用户可以自由的定义协同工作的组织结构 (参阅 变更传播 ):
在一个集中式版本管理系统中提交实验性的修改可能会造成较大的负面影响, 但对于Mercurial之类的DVCS来说, 可以肆意的进行试验性操作， 大不了删除本地工作目录，因为在别的地方还有若干完整的。
6. 什么是Mercurial不能作的
SVN/CVS用户会将多个相关的项目放在同一个仓库里. 但是这真的不应该在Hg 中这么作,因为在Hg 中你只能检出整个仓库，而不是其中的某个目录.
如果确实想要将多个项目放在同一个仓库中, 可以使用1.3版本以后的子仓库 功能或者更老版本的 ForestExtension 将不同项目的仓库,嵌套成一个大仓库.
关于Mercurial的入门操作, 请参阅 教程.