Show More
@@ -1,25 +1,25 b'' | |||
|
1 | 1 | Mercurial Frequently Asked Questions |
|
2 | ==================================== | |
|
2 | 3 | |
|
3 | 4 | Section 1: General Usage |
|
4 | 5 | ------------------------ |
|
5 | 6 | |
|
6 |
Q. I did an |
|
|
7 | .Q. I did an "hg pull" and my working directory is empty! | |
|
7 | 8 | |
|
8 | 9 | There are two parts to Mercurial: the repository and the working |
|
9 |
directory. |
|
|
10 | directory. "hg pull" pulls all new changes from a remote repository | |
|
10 | 11 | into the local one but doesn't alter the working directory. |
|
11 | 12 | |
|
12 | 13 | This keeps you from upsetting your work in progress, which may not be |
|
13 | 14 | ready to merge with the new changes you've pulled and also allows you |
|
14 | 15 | to manage merging more easily (see below about best practices). |
|
15 | 16 | |
|
16 |
To update your working directory, run |
|
|
17 |
want to update your working directory on a pull, you can also use |
|
|
18 |
pull -u |
|
|
17 | To update your working directory, run "hg update". If you're sure you | |
|
18 | want to update your working directory on a pull, you can also use "hg | |
|
19 | pull -u". This will refuse to merge or overwrite local changes. | |
|
19 | 20 | |
|
20 | 21 | |
|
21 |
Q. What |
|
|
22 | and tags? | |
|
22 | .Q. What are revision numbers, changeset IDs, and tags? | |
|
23 | 23 | |
|
24 | 24 | Mercurial will generally allow you to refer to a revision in three |
|
25 | 25 | ways: by revision number, by changeset ID, and by tag. |
@@ -46,7 +46,7 b' correspondence to a changeset ID. This l' | |||
|
46 | 46 | symbolically. |
|
47 | 47 | |
|
48 | 48 | |
|
49 | Q. What are branches, heads, and the tip? | |
|
49 | .Q. What are branches, heads, and the tip? | |
|
50 | 50 | |
|
51 | 51 | The central concept of Mercurial is branching. A 'branch' is simply |
|
52 | 52 | an independent line of development. In most other version control |
@@ -56,12 +56,12 b' effectively works on a private branch an' | |||
|
56 | 56 | of 'the main branch'. |
|
57 | 57 | |
|
58 | 58 | Thus Mercurial works hard to make repeated merging between branches |
|
59 |
easy. Simply run |
|
|
59 | easy. Simply run "hg pull" and "hg update -m" and commit the result. | |
|
60 | 60 | |
|
61 | 61 | 'Heads' are simply the most recent commits on a branch. Technically, |
|
62 | 62 | they are changesets which have no children. Merging is the process of |
|
63 | 63 | joining points on two branches into one, usually at their current |
|
64 |
heads. Use |
|
|
64 | heads. Use "hg heads" to find the heads in the current repository. | |
|
65 | 65 | |
|
66 | 66 | The 'tip' is the most recently changed head, and also the highest |
|
67 | 67 | numbered revision. If you have just made a commit, that commit will be |
@@ -72,10 +72,10 b" The 'tip' is the default revision for ma" | |||
|
72 | 72 | and also functions as a special symbolic tag. |
|
73 | 73 | |
|
74 | 74 | |
|
75 | Q. How does merging work? | |
|
75 | .Q. How does merging work? | |
|
76 | 76 | |
|
77 | 77 | The merge process is simple. Usually you will want to merge the tip |
|
78 |
into your working directory. Thus you run |
|
|
78 | into your working directory. Thus you run "hg update -m" and Mercurial | |
|
79 | 79 | will incorporate the changes from tip into your local changes. |
|
80 | 80 | |
|
81 | 81 | The first step of this process is tracing back through the history of |
@@ -99,7 +99,7 b' that would lose important history that w' | |||
|
99 | 99 | merges. |
|
100 | 100 | |
|
101 | 101 | |
|
102 | Q. How do tags work in Mercurial? | |
|
102 | .Q. How do tags work in Mercurial? | |
|
103 | 103 | |
|
104 | 104 | Tags work slightly differently in Mercurial than most revision |
|
105 | 105 | systems. The design attempts to meet the following requirements: |
@@ -112,8 +112,8 b' systems. The design attempts to meet the' | |||
|
112 | 112 | Thus Mercurial stores tags as a file in the working dir. This file is |
|
113 | 113 | called .hgtags and consists of a list of changeset IDs and their |
|
114 | 114 | corresponding tags. To add a tag to the system, simply add a line to |
|
115 |
this file and then commit it for it to take effect. The |
|
|
116 |
command will do this for you and |
|
|
115 | this file and then commit it for it to take effect. The "hg tag" | |
|
116 | command will do this for you and "hg tags" will show the currently | |
|
117 | 117 | effective tags. |
|
118 | 118 | |
|
119 | 119 | Note that because tags refer to changeset IDs and the changeset ID is |
@@ -121,13 +121,14 b' effectively the sum of all the contents ' | |||
|
121 | 121 | change, it is impossible in Mercurial to simultaneously commit and add |
|
122 | 122 | a tag. Thus tagging a revision must be done as a second step. |
|
123 | 123 | |
|
124 | Q. How do tags work with multiple heads? | |
|
124 | ||
|
125 | .Q. How do tags work with multiple heads? | |
|
125 | 126 | |
|
126 | 127 | The tags that are in effect at any given time are the tags specified |
|
127 | 128 | in each head, with heads closer to the tip taking precedence. |
|
128 | 129 | |
|
129 | 130 | |
|
130 | Q. What are some best practices for distributed development with Mercurial? | |
|
131 | .Q. What are some best practices for distributed development with Mercurial? | |
|
131 | 132 | |
|
132 | 133 | First, merge often! This makes merging easier for everyone and you |
|
133 | 134 | find out about conflicts (which are often rooted in incompatible |
@@ -143,21 +144,21 b' pull multiple copies over the network. N' | |||
|
143 | 144 | as you won't be changing them. |
|
144 | 145 | |
|
145 | 146 | The outgoing tree contains all the changes you intend for merger into |
|
146 |
upsteam. Publish this tree with 'hg serve |
|
|
147 |
push |
|
|
147 | upsteam. Publish this tree with 'hg serve" or hgweb.cgi or use 'hg | |
|
148 | push" to push it to another publicly availabe repository. | |
|
148 | 149 | |
|
149 | 150 | Then, for each feature you work on, create a new tree. Commit early |
|
150 | 151 | and commit often, merge with incoming regularly, and once you're |
|
151 | 152 | satisfied with your feature, pull the changes into your outgoing tree. |
|
152 | 153 | |
|
153 | 154 | |
|
154 | Q. How do I import from a repository created in a different SCM? | |
|
155 | .Q. How do I import from a repository created in a different SCM? | |
|
155 | 156 | |
|
156 | 157 | Take a look at contrib/convert-repo. This is an extensible |
|
157 | 158 | framework for converting between repository types. |
|
158 | 159 | |
|
159 | 160 | |
|
160 | Q. What about Windows support? | |
|
161 | .Q. What about Windows support? | |
|
161 | 162 | |
|
162 | 163 | Patches to support Windows are being actively integrated, a fully |
|
163 | 164 | working Windows version is probably not far off |
@@ -166,7 +167,7 b' working Windows version is probably not ' | |||
|
166 | 167 | Section 2: Technical |
|
167 | 168 | -------------------- |
|
168 | 169 | |
|
169 | Q. What limits does Mercurial have? | |
|
170 | .Q. What limits does Mercurial have? | |
|
170 | 171 | |
|
171 | 172 | Mercurial currently assumes that single files, indices, and manifests |
|
172 | 173 | can fit in memory for efficiency. |
@@ -186,7 +187,7 b' Mercurial is primarily developed for UNI' | |||
|
186 | 187 | may be present in ports. |
|
187 | 188 | |
|
188 | 189 | |
|
189 | Q. How does signing work? | |
|
190 | .Q. How does signing work? | |
|
190 | 191 | |
|
191 | 192 | Take a look at the hgeditor script for an example. The basic idea |
|
192 | 193 | is to sign the manifest ID inside that changelog entry. The manifest |
@@ -201,7 +202,7 b' This manifest is hashed similarly to the' | |||
|
201 | 202 | the hashes of the parent revisions. |
|
202 | 203 | |
|
203 | 204 | |
|
204 | Q. What about hash collisions? What about weaknesses in SHA1? | |
|
205 | .Q. What about hash collisions? What about weaknesses in SHA1? | |
|
205 | 206 | |
|
206 | 207 | The SHA1 hashes are large enough that the odds of accidental hash collision |
|
207 | 208 | are negligible for projects that could be handled by the human race. |
General Comments 0
You need to be logged in to leave comments.
Login now