|
Size: 4594
Comment:
|
Size: 6191
Comment: +(see CommunicatingChanges)
|
| 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. [[TableOfContents]] |
|
| Line 3: | Line 8: |
| Mercurial repositories contain a working directory coupled with a store: | Mercurial Repositories (see ["Repository"]) contain a ["WorkingDirectory"] coupled with a store: |
| Line 7: | Line 12: |
| rankdir = BT | compound=true; rankdir = LR |
| Line 9: | Line 15: |
| subgraph cluster_1 { style=filled; color="#eeeeee"; node [shape=box,style=filled,color=lightgray]; "rev 0" -> "rev 1" -> "rev 2" -> "rev 3"; label = "store"; } |
|
| Line 17: | Line 30: |
| "rev 2" -> ".hgtags" [lhead = cluster_0 constraint=false] } }}} The store contains the '''complete''' history of the project. Unlike traditional ["SCM"]s, 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"]s and ignored files are revision-controlled, they are also included. == Committing Changes == When you '''["Commit"]''', the state of the working directory relative to its ["Parent"]s is recorded as a new ["Revision"]: {{{#!dot digraph G { compound=true; rankdir = LR background="#999999"; |
|
| Line 22: | Line 53: |
| "rev 2" -> "rev 4"; | |
| Line 24: | Line 56: |
| } }}} The working directory contains a copy of the project's files at a given point in time, ready for editing. Because tags and ignored files are revision-controlled, they are also included. The store contains the '''complete''' history of the project. Unlike traditional 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. |
subgraph cluster_0 { style=filled; color=lightgrey; node [style=filled,color=white]; edge [style=invis]; "main.c"-> "main.h" -> ".hgignore" -> ".hgtags" label="working directory"; } "rev 2" -> ".hgtags" [style = dotted lhead = cluster_0 constraint=false] "rev 4" -> ".hgtags" [lhead = cluster_0 constraint=false] ".hgtags" -> "rev 4" [color = red label = "commit" ltail = cluster_0 constraint=false] } }}} Note here that revision 4 is a '''branch''' of revision 2, which was the revision in the working directory. Now revision 4 is the working directory's '''parent'''. |
| Line 34: | Line 74: |
| 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 groups related changes to multiple files into single atomic '''["ChangeSet"]s''', which are '''revisions''' of the whole project. These each get a sequential ["RevisionNumber"]. Because Mercurial allows distributed parallel development, these revision numbers may disagree between users. So Mercurial also assigns each revision a global '''["ChangeSetID"]'''. Changeset IDs are 40-digit hexadecimal numbers, but they can be abbreviated to any unambiguous prefix, like "e38487". |
| Line 51: | Line 91: |
| Branches and merges in the revision history can occur at any point. Each unmerged branch creates a new '''head''' of the revision history. 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. == Cloning, Making Changes, and Pulling == |
Branches and ["Merge"]s in the revision history can occur at any point. Each unmerged branch creates a new '''["Head"]''' of the revision history. 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. == Cloning, Making Changes, Merging, and Pulling == |
| Line 67: | Line 107: |
| Bob '''clones''' this repo, and ends up with a complete copy: | Bob '''["Clone"]s''' this repo, and ends up with a complete copy of Alice's store (though his working directory is independent!): |
| Line 78: | Line 118: |
| Bob then '''commits''' a couple changes: | Bob then '''["Commit"]s''' a couple changes: |
| Line 103: | Line 143: |
| Bob then '''pulls''' Alice's repo to synchronize. This copies all of Alice's changes into Bob's repo: | Bob then '''["Pull"]s''' Alice's repo to synchronize. This copies all of Alice's changes into Bob's repo: |
| Line 118: | Line 158: |
| 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, commits the result, and ends up with: | 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, commits the result, and ends up with: |
| Line 156: | Line 196: |
| 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: | 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): |
| Line 175: | Line 215: |
For a hands-on introduction to using Mercurial, see the ["Tutorial"]. |
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.
What's in a Repository
Mercurial Repositories (see ["Repository"]) contain a ["WorkingDirectory"] coupled with a store:
The store contains the complete history of the project. Unlike traditional ["SCM"]s, 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"]s and ignored files are revision-controlled, they are also included.
Committing Changes
When you ["Commit"], the state of the working directory relative to its ["Parent"]s is recorded as a new ["Revision"]:
Note here that revision 4 is a 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"]s, which are revisions of the whole project. These each get a sequential ["RevisionNumber"]. Because Mercurial allows distributed parallel development, these revision numbers may disagree between users. So Mercurial also assigns each revision a global ["ChangeSetID"]. Changeset IDs are 40-digit hexadecimal numbers, but they can be abbreviated to any unambiguous prefix, like "e38487".
Branches and ["Merge"]s in the revision history can occur at any point. Each unmerged branch creates a new ["Head"] of the revision history. 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.
Cloning, Making Changes, Merging, and Pulling
Let's start with a user Alice, who has a store that looks like:
Bob ["Clone"]s this repo, and ends up with a complete copy of Alice's store (though his working directory is independent!):
Bob then ["Commit"]s a couple changes:
Alice then makes her own change in parallel:
Bob then ["Pull"]s Alice's repo to synchronize. This copies all of Alice's changes into Bob's repo:
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, commits the result, and ends up with:
Now if Alice pulls from Bob, she will get Bob's changes e, f, and h, and they will be fully synchronized:
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):
For a hands-on introduction to using Mercurial, see the ["Tutorial"].