Size: 6191
Comment: +(see CommunicatingChanges)
|
Size: 6235
Comment: lowercase links
|
Deletions are marked like this. | Additions are marked like this. |
Line 8: | Line 8: |
Mercurial Repositories (see ["Repository"]) contain a ["WorkingDirectory"] coupled with a store: | Mercurial [:Repository:repositories] contain a [:WorkingDirectory:working directory] coupled with a store: |
Line 34: | Line 34: |
The store contains the '''complete''' history of the project. Unlike traditional ["SCM"]s, where there's only one central copy of this history, | The store contains the '''complete''' history of the project. Unlike traditional [:SCM:SCMs], where there's only one central copy of this history, |
Line 37: | Line 37: |
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. | 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 ignored files are revision-controlled, they are also included. |
Line 41: | Line 41: |
When you '''["Commit"]''', the state of the working directory relative to its ["Parent"]s is recorded as a new ["Revision"]: | When you [:Commit:commit], the state of the working directory relative to its [:Parent:parents] is recorded as a new [:Revision:revision]: |
Line 74: | Line 74: |
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". |
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". |
Line 91: | Line 91: |
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. |
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. |
Line 107: | Line 107: |
Bob '''["Clone"]s''' this repo, and ends up with a complete copy of Alice's store (though his working directory is independent!): | Bob [:Clone:clones] this repo, and ends up with a complete copy of Alice's store (though his working directory is independent!): |
Line 118: | Line 118: |
Bob then '''["Commit"]s''' a couple changes: | Bob then [:Commit:commits] a couple changes: |
Line 143: | Line 143: |
Bob then '''["Pull"]s''' Alice's repo to synchronize. This copies all of Alice's changes into Bob's repo: | Bob then [:Pull:pulls] Alice's repo to synchronize. This copies all of Alice's changes into Bob's repo: |
Line 158: | 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:merge] which combines the last change he was working on ('''f''') with the tip, commits the result, and ends up with: |
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 [:Repository:repositories] contain a [:WorkingDirectory:working directory] coupled with a store:
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 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 [:Revision: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: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".
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.
Cloning, Making Changes, Merging, and Pulling
Let's start with a user Alice, who has a store that looks like:
Bob [:Clone:clones] this repo, and ends up with a complete copy of Alice's store (though his working directory is independent!):
Bob then [:Commit:commits] a couple changes:
Alice then makes her own change in parallel:
Bob then [:Pull:pulls] 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: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"].