Show More
@@ -1,124 +1,126 b'' | |||
|
1 | 1 | MERCURIAL QUICK-START |
|
2 | 2 | |
|
3 | 3 | Setting up Mercurial: |
|
4 | 4 | |
|
5 | 5 | Note: some distributions fails to include bits of distutils by |
|
6 | 6 | default, you'll need python-dev to install. You'll also need a C |
|
7 | 7 | compiler and a 3-way merge tool like merge, tkdiff, or kdiff3. |
|
8 | 8 | |
|
9 | 9 | First, unpack the source: |
|
10 | 10 | |
|
11 | 11 | $ tar xvzf mercurial-<ver>.tar.gz |
|
12 | 12 | $ cd mercurial-<ver> |
|
13 | 13 | |
|
14 | 14 | To install system-wide: |
|
15 | 15 | |
|
16 | 16 | $ python setup.py install # change python to python2.3 if 2.2 is default |
|
17 | 17 | |
|
18 | 18 | To install in your home directory (~/bin and ~/lib, actually), run: |
|
19 | 19 | |
|
20 | 20 | $ python2.3 setup.py install --home=~ |
|
21 | 21 | $ export PYTHONPATH=${HOME}/lib/python # (or lib64/ on some systems) |
|
22 | 22 | $ export PATH=${HOME}/bin:$PATH # add these to your .bashrc |
|
23 | 23 | |
|
24 | 24 | And finally: |
|
25 | 25 | |
|
26 | 26 | $ hg # test installation, show help |
|
27 | 27 | |
|
28 | 28 | If you get complaints about missing modules, you probably haven't set |
|
29 | 29 | PYTHONPATH correctly. |
|
30 | 30 | |
|
31 | 31 | Setting up a Mercurial project: |
|
32 | 32 | |
|
33 | 33 | $ cd project/ |
|
34 | 34 | $ hg init # creates .hg |
|
35 | 35 | $ hg status # show changes between repo and working dir |
|
36 | 36 | $ hg diff # generate a unidiff |
|
37 | 37 | $ hg addremove # add all unknown files and remove all missing files |
|
38 | 38 | $ hg commit # commit all changes, edit changelog entry |
|
39 | 39 | $ hg export <rev> # export a changeset as a diff |
|
40 | 40 | |
|
41 | 41 | Mercurial will look for a file named .hgignore in the root of your |
|
42 | 42 | repository contains a set of regular expressions to ignore in file |
|
43 | 43 | paths. |
|
44 | 44 | |
|
45 | 45 | Mercurial commands: |
|
46 | 46 | |
|
47 | 47 | $ hg help [command] # get online help |
|
48 | 48 | $ hg history # show changesets |
|
49 | 49 | $ hg log Makefile # show commits per file |
|
50 | 50 | $ hg update # check out the tip revision |
|
51 | 51 | $ hg update <id> # check out a specified changeset |
|
52 | 52 | # IDs can be tags, revision numbers, or unique |
|
53 | 53 | # subsets of changeset hash numbers |
|
54 | 54 | $ hg add foo # add a new file for the next commit |
|
55 | 55 | $ hg remove bar # mark a file as removed |
|
56 | 56 | $ hg verify # check repo integrity |
|
57 | 57 | $ hg tags # show current tags |
|
58 | $ hg tag <name> # tag current tip with distributed tag <name> | |
|
59 | $ hg tag -l <name> # tag current tip with local tag <name> | |
|
58 | 60 | $ hg annotate [files] # show changeset numbers for each file line |
|
59 | 61 | |
|
60 | 62 | Branching and merging: |
|
61 | 63 | |
|
62 | 64 | $ cd .. |
|
63 | 65 | $ mkdir linux-work |
|
64 | 66 | $ cd linux-work |
|
65 | 67 | $ hg init ../linux # create a new branch |
|
66 | 68 | $ hg update # populate the working directory |
|
67 | 69 | $ <make changes> |
|
68 | 70 | $ hg commit |
|
69 | 71 | $ cd ../linux |
|
70 | 72 | $ hg pull ../linux-work # pull changesets from linux-work |
|
71 | 73 | $ hg update -m # merge the new tip from linux-work into |
|
72 | 74 | # our working directory |
|
73 | 75 | |
|
74 | 76 | Importing patches: |
|
75 | 77 | |
|
76 | 78 | Fast: |
|
77 | 79 | $ patch < ../p/foo.patch |
|
78 | 80 | $ hg addremove |
|
79 | 81 | $ hg commit |
|
80 | 82 | |
|
81 | 83 | Faster: |
|
82 | 84 | $ patch < ../p/foo.patch |
|
83 | 85 | $ hg commit `lsdiff -p1 ../p/foo.patch` |
|
84 | 86 | |
|
85 | 87 | Fastest: |
|
86 | 88 | $ cat ../p/patchlist | xargs hg import -p1 -b ../p |
|
87 | 89 | |
|
88 | 90 | Exporting a patch: |
|
89 | 91 | |
|
90 | 92 | (make changes) |
|
91 | 93 | $ hg commit |
|
92 | 94 | $ hg tip |
|
93 | 95 | 28237:747a537bd090880c29eae861df4d81b245aa0190 |
|
94 | 96 | $ hg export 28237 > foo.patch # export changeset 28237 |
|
95 | 97 | |
|
96 | 98 | Network support: |
|
97 | 99 | |
|
98 | 100 | # pull from the primary Mercurial repo |
|
99 | 101 | foo$ hg init |
|
100 | 102 | foo$ hg pull http://selenic.com/hg/ |
|
101 | 103 | foo$ hg update # hg co works too |
|
102 | 104 | |
|
103 | 105 | # export your current repo via HTTP with browsable interface |
|
104 | 106 | foo$ hg serve -n "My repo" -p 80 |
|
105 | 107 | |
|
106 | 108 | # pushing changes to a remote repo with SSH |
|
107 | 109 | foo$ hg push ssh://user@example.com/~/hg/ |
|
108 | 110 | |
|
109 | 111 | # merge changes from a remote machine |
|
110 | 112 | bar$ hg pull http://foo/ |
|
111 | 113 | bar$ hg update -m # merge changes into your working directory |
|
112 | 114 | |
|
113 | 115 | # Set up a CGI server on your webserver |
|
114 | 116 | foo$ cp hgweb.cgi ~/public_html/hg/index.cgi |
|
115 | 117 | foo$ emacs ~/public_html/hg/index.cgi # adjust the defaults |
|
116 | 118 | |
|
117 | 119 | Symbolic repository names: |
|
118 | 120 | |
|
119 | 121 | Mercurial uses an options file called ~/.hgrc. To track locations |
|
120 | 122 | symbolically, add a section to it like this: |
|
121 | 123 | |
|
122 | 124 | [paths] |
|
123 | 125 | main = http://selenic.com/hg |
|
124 | 126 | linux = http://www.kernel.org/hg/ |
@@ -1,317 +1,317 b'' | |||
|
1 | 1 | Mercurial Frequently Asked Questions |
|
2 | 2 | ==================================== |
|
3 | 3 | |
|
4 | 4 | Section 1: General Usage |
|
5 | 5 | ------------------------ |
|
6 | 6 | |
|
7 | 7 | .Q. I did an "hg pull" and my working directory is empty! |
|
8 | 8 | |
|
9 | 9 | There are two parts to Mercurial: the repository and the working |
|
10 | 10 | directory. "hg pull" pulls all new changes from a remote repository |
|
11 | 11 | into the local one but doesn't alter the working directory. |
|
12 | 12 | |
|
13 | 13 | This keeps you from upsetting your work in progress, which may not be |
|
14 | 14 | ready to merge with the new changes you've pulled and also allows you |
|
15 | 15 | to manage merging more easily (see below about best practices). |
|
16 | 16 | |
|
17 | 17 | To update your working directory, run "hg update". If you're sure you |
|
18 | 18 | want to update your working directory on a pull, you can also use "hg |
|
19 | 19 | pull -u". This will refuse to merge or overwrite local changes. |
|
20 | 20 | |
|
21 | 21 | |
|
22 | 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. |
|
26 | 26 | |
|
27 | 27 | A revision number is a simple decimal number that corresponds with the |
|
28 | 28 | ordering of commits in the local repository. It is important to |
|
29 | 29 | understand that this ordering can change from machine to machine due |
|
30 | 30 | to Mercurial's distributed, decentralized architecture. |
|
31 | 31 | |
|
32 | 32 | This is where changeset IDs come in. A changeset ID is a 160-bit |
|
33 | 33 | identifier that uniquely describes a changeset and its position in the |
|
34 | 34 | change history, regardless of which machine it's on. This is |
|
35 | 35 | represented to the user as a 40 digit hexadecimal number. As that |
|
36 | 36 | tends to be unwieldy, Mercurial will accept any unambiguous substring |
|
37 | 37 | of that number when specifying versions. It will also generally print |
|
38 | 38 | these numbers in "short form", which is the first 12 digits. |
|
39 | 39 | |
|
40 | 40 | You should always use some form of changeset ID rather than the local |
|
41 | 41 | revision number when discussing revisions with other Mercurial users |
|
42 | 42 | as they may have different revision numbering on their system. |
|
43 | 43 | |
|
44 | 44 | Finally, a tag is an arbitrary string that has been assigned a |
|
45 | 45 | correspondence to a changeset ID. This lets you refer to revisions |
|
46 | 46 | symbolically. |
|
47 | 47 | |
|
48 | 48 | |
|
49 | 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 |
|
53 | 53 | systems, all users generally commit to the same line of development |
|
54 | 54 | called 'the trunk' or 'the main branch'. In Mercurial, every developer |
|
55 | 55 | effectively works on a private branch and there is no internal concept |
|
56 | 56 | of 'the main branch'. |
|
57 | 57 | |
|
58 | 58 | Thus Mercurial works hard to make repeated merging between branches |
|
59 | 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 | 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 |
|
68 | 68 | the head. Alternately, if you have just pulled from another |
|
69 | 69 | repository, the tip of that repository becomes the current tip. |
|
70 | 70 | |
|
71 | 71 | The 'tip' is the default revision for many commands such as update, |
|
72 | 72 | and also functions as a special symbolic tag. |
|
73 | 73 | |
|
74 | 74 | |
|
75 | 75 | .Q. How does merging work? |
|
76 | 76 | |
|
77 | 77 | The merge process is simple. Usually you will want to merge the tip |
|
78 | 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 |
|
82 | 82 | changesets and finding the 'common ancestor' of the two versions that |
|
83 | 83 | are being merged. This is done on a project-wide and a file by file |
|
84 | 84 | basis. |
|
85 | 85 | |
|
86 | 86 | For files that have been changed in both projects, a three-way merge |
|
87 | 87 | is attempted to add the changes made remotely into the changes made |
|
88 | 88 | locally. If there are conflicts between these changes, the user is |
|
89 | 89 | prompted to interactively resolve them. |
|
90 | 90 | |
|
91 | 91 | Mercurial uses a helper tool for this, which is usually found by the |
|
92 | 92 | hgmerge script. Example tools include tkdiff, kdiff3, and the classic |
|
93 | 93 | RCS merge. |
|
94 | 94 | |
|
95 | 95 | After you've completed the merge and you're satisfied that the results |
|
96 | 96 | are correct, it's a good idea to commit your changes. Mercurial won't |
|
97 | 97 | allow you to perform another merge until you've done this commit as |
|
98 | 98 | that would lose important history that will be needed for future |
|
99 | 99 | merges. |
|
100 | 100 | |
|
101 | 101 | |
|
102 | 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: |
|
106 | 106 | |
|
107 | 107 | - be version controlled and mergeable just like any other file |
|
108 | 108 | - allow signing of tags |
|
109 | 109 | - allow adding a tag to an already committed changeset |
|
110 | 110 | - allow changing tags in the future |
|
111 | 111 | |
|
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 | 115 | this file and then commit it for it to take effect. The "hg tag" |
|
116 | 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 |
|
120 | 120 | effectively the sum of all the contents of the repository for that |
|
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 | 124 | |
|
125 | 125 | .Q. What if I want to just keep local tags? |
|
126 | 126 | |
|
127 | You can add a section called "[tags]" to your .hg/hgrc which contains | |
|
128 | a list of tag = changeset ID pairs. Unlike traditional tags, these are | |
|
129 | only visible in the local repository, but otherwise act just like | |
|
130 | normal tags. | |
|
127 | You can use "hg tag" command with an option "-l" or "--local". This | |
|
128 | will store the tag in the file .hg/localtags, which will not be | |
|
129 | distributed or versioned. The format of this file is identical to the | |
|
130 | one of .hgtags and the tags stored there are handled the same. | |
|
131 | 131 | |
|
132 | 132 | |
|
133 | 133 | .Q. How do tags work with multiple heads? |
|
134 | 134 | |
|
135 | 135 | The tags that are in effect at any given time are the tags specified |
|
136 | 136 | in each head, with heads closer to the tip taking precedence. Local |
|
137 | 137 | tags override all other tags. |
|
138 | 138 | |
|
139 | 139 | |
|
140 | 140 | .Q. What are some best practices for distributed development with Mercurial? |
|
141 | 141 | |
|
142 | 142 | First, merge often! This makes merging easier for everyone and you |
|
143 | 143 | find out about conflicts (which are often rooted in incompatible |
|
144 | 144 | design decisions) earlier. |
|
145 | 145 | |
|
146 | 146 | Second, don't hesitate to use multiple trees locally. Mercurial makes |
|
147 | 147 | this fast and light-weight. Typical usage is to have an incoming tree, |
|
148 | 148 | an outgoing tree, and a separate tree for each area being worked on. |
|
149 | 149 | |
|
150 | 150 | The incoming tree is best maintained as a pristine copy of the |
|
151 | 151 | upstream repository. This works as a cache so that you don't have to |
|
152 | 152 | pull multiple copies over the network. No need to check files out here |
|
153 | 153 | as you won't be changing them. |
|
154 | 154 | |
|
155 | 155 | The outgoing tree contains all the changes you intend for merger into |
|
156 | 156 | upsteam. Publish this tree with 'hg serve" or hgweb.cgi or use 'hg |
|
157 | 157 | push" to push it to another publicly availabe repository. |
|
158 | 158 | |
|
159 | 159 | Then, for each feature you work on, create a new tree. Commit early |
|
160 | 160 | and commit often, merge with incoming regularly, and once you're |
|
161 | 161 | satisfied with your feature, pull the changes into your outgoing tree. |
|
162 | 162 | |
|
163 | 163 | |
|
164 | 164 | .Q. How do I import from a repository created in a different SCM? |
|
165 | 165 | |
|
166 | 166 | Take a look at contrib/convert-repo. This is an extensible |
|
167 | 167 | framework for converting between repository types. |
|
168 | 168 | |
|
169 | 169 | |
|
170 | 170 | .Q. What about Windows support? |
|
171 | 171 | |
|
172 | 172 | Patches to support Windows are being actively integrated, a fully |
|
173 | 173 | working Windows version is probably not far off |
|
174 | 174 | |
|
175 | 175 | |
|
176 | 176 | Section 2: Bugs and Features |
|
177 | 177 | ---------------------------- |
|
178 | 178 | |
|
179 | 179 | .Q. I found a bug, what do I do? |
|
180 | 180 | |
|
181 | 181 | Report it to the mercurial mailing list, mercurial@selenic.com. |
|
182 | 182 | |
|
183 | 183 | |
|
184 | 184 | .Q. What should I include in my bug report? |
|
185 | 185 | |
|
186 | 186 | Enough information to reproduce or diagnose the bug. If you can, try |
|
187 | 187 | using the hg -v and hg -d switches to figure out exactly what |
|
188 | 188 | Mercurial is doing. |
|
189 | 189 | |
|
190 | 190 | If you can reproduce the bug in a simple repository, that is very |
|
191 | 191 | helpful. The best is to create a simple shell script to automate this |
|
192 | 192 | process, which can then be added to our test suite. |
|
193 | 193 | |
|
194 | 194 | |
|
195 | 195 | .Q. Can Mercurial do <x>? |
|
196 | 196 | |
|
197 | 197 | If you'd like to request a feature, send your request to |
|
198 | 198 | mercurial@selenic.com. As Mercurial is still very new, there are |
|
199 | 199 | certainly features it is missing and you can give up feedback on how |
|
200 | 200 | best to implement them. |
|
201 | 201 | |
|
202 | 202 | |
|
203 | 203 | Section 3: Technical |
|
204 | 204 | -------------------- |
|
205 | 205 | |
|
206 | 206 | .Q. What limits does Mercurial have? |
|
207 | 207 | |
|
208 | 208 | Mercurial currently assumes that single files, indices, and manifests |
|
209 | 209 | can fit in memory for efficiency. |
|
210 | 210 | |
|
211 | 211 | Offsets in revlogs are currently tracked with 32 bits, so a revlog for |
|
212 | 212 | a single file can currently not grow beyond 4G. |
|
213 | 213 | |
|
214 | 214 | There should otherwise be no limits on file name length, file size, |
|
215 | 215 | file contents, number of files, or number of revisions. |
|
216 | 216 | |
|
217 | 217 | The network protocol is big-endian. |
|
218 | 218 | |
|
219 | 219 | File names cannot contain the null character. Committer addresses |
|
220 | 220 | cannot contain newlines. |
|
221 | 221 | |
|
222 | 222 | Mercurial is primarily developed for UNIX systems, so some UNIXisms |
|
223 | 223 | may be present in ports. |
|
224 | 224 | |
|
225 | 225 | |
|
226 | 226 | .Q. How does Mercurial store its data? |
|
227 | 227 | |
|
228 | 228 | The fundamental storage type in Mercurial is a "revlog". A revlog is |
|
229 | 229 | the set of all revisions of a named object. Each revision is either |
|
230 | 230 | stored compressed in its entirety or as a compressed binary delta |
|
231 | 231 | against the previous version. The decision of when to store a full |
|
232 | 232 | version is made based on how much data would be needed to reconstruct |
|
233 | 233 | the file. This lets us ensure that we never need to read huge amounts |
|
234 | 234 | of data to reconstruct a object, regardless of how many revisions of it |
|
235 | 235 | we store. |
|
236 | 236 | |
|
237 | 237 | In fact, we should always be able to do it with a single read, |
|
238 | 238 | provided we know when and where to read. This is where the index comes |
|
239 | 239 | in. Each revlog has an index containing a special hash (nodeid) of the |
|
240 | 240 | text, hashes for its parents, and where and how much of the revlog |
|
241 | 241 | data we need to read to reconstruct it. Thus, with one read of the |
|
242 | 242 | index and one read of the data, we can reconstruct any version in time |
|
243 | 243 | proportional to the object size. |
|
244 | 244 | |
|
245 | 245 | Similarly, revlogs and their indices are append-only. This means that |
|
246 | 246 | adding a new version is also O(1) seeks. |
|
247 | 247 | |
|
248 | 248 | Revlogs are used to represent all revisions of files, manifests, and |
|
249 | 249 | changesets. Compression for typical objects with lots of revisions can |
|
250 | 250 | range from 100 to 1 for things like project makefiles to over 2000 to |
|
251 | 251 | 1 for objects like the manifest. |
|
252 | 252 | |
|
253 | 253 | |
|
254 | 254 | .Q. How are manifests and changesets stored? |
|
255 | 255 | |
|
256 | 256 | A manifest is simply a list of all files in a given revision of a |
|
257 | 257 | project along with the nodeids of the corresponding file revisions. So |
|
258 | 258 | grabbing a given version of the project means simply looking up its |
|
259 | 259 | manifest and reconstruction all the file revisions pointed to by it. |
|
260 | 260 | |
|
261 | 261 | A changeset is a list of all files changed in a check-in along with a |
|
262 | 262 | change description and some metadata like user and date. It also |
|
263 | 263 | contains a nodeid to the relevent revision of the manifest. |
|
264 | 264 | |
|
265 | 265 | |
|
266 | 266 | .Q. How do Mercurial hashes get calculated? |
|
267 | 267 | |
|
268 | 268 | Mercurial hashes both the contents of an object and the hash of its |
|
269 | 269 | parents to create an identifier that uniquely identifies an object's |
|
270 | 270 | contents and history. This greatly simplifies merging of histories |
|
271 | 271 | because it avoid graph cycles that can occur when a object is reverted |
|
272 | 272 | to an earlier state. |
|
273 | 273 | |
|
274 | 274 | All file revisions have an associated hash value. These are listed in |
|
275 | 275 | the manifest of a given project revision, and the manifest hash is |
|
276 | 276 | listed in the changeset. The changeset hash is again a hash of the |
|
277 | 277 | changeset contents and its parents, so it uniquely identifies the |
|
278 | 278 | entire history of the project to that point. |
|
279 | 279 | |
|
280 | 280 | |
|
281 | 281 | .Q. What checks are there on repository integrity? |
|
282 | 282 | |
|
283 | 283 | Every time a revlog object is retrieved, it is checked against its |
|
284 | 284 | hash for integrity. It is also incidentally doublechecked by the |
|
285 | 285 | Adler32 checksum used by the underlying zlib compression. |
|
286 | 286 | |
|
287 | 287 | Running 'hg verify' decompresses and reconstitutes each revision of |
|
288 | 288 | each object in the repository and cross-checks all of the index |
|
289 | 289 | metadata with those contents. |
|
290 | 290 | |
|
291 | 291 | But this alone is not enough to ensure that someone hasn't tampered |
|
292 | 292 | with a repository. For that, you need cryptographic signing. |
|
293 | 293 | |
|
294 | 294 | |
|
295 | 295 | .Q. How does signing work with Mercurial? |
|
296 | 296 | |
|
297 | 297 | Take a look at the hgeditor script for an example. The basic idea is |
|
298 | 298 | to use GPG to sign the manifest ID inside that changelog entry. The |
|
299 | 299 | manifest ID is a recursive hash of all of the files in the system and |
|
300 | 300 | their complete history, and thus signing the manifest hash signs the |
|
301 | 301 | entire project contents. |
|
302 | 302 | |
|
303 | 303 | |
|
304 | 304 | .Q. What about hash collisions? What about weaknesses in SHA1? |
|
305 | 305 | |
|
306 | 306 | The SHA1 hashes are large enough that the odds of accidental hash collision |
|
307 | 307 | are negligible for projects that could be handled by the human race. |
|
308 | 308 | The known weaknesses in SHA1 are currently still not practical to |
|
309 | 309 | attack, and Mercurial will switch to SHA256 hashing before that |
|
310 | 310 | becomes a realistic concern. |
|
311 | 311 | |
|
312 | 312 | Collisions with the "short hashes" are not a concern as they're always |
|
313 | 313 | checked for ambiguity and are still long enough that they're not |
|
314 | 314 | likely to happen for reasonably-sized projects (< 1M changes). |
|
315 | 315 | |
|
316 | 316 | |
|
317 | 317 |
@@ -1,591 +1,592 b'' | |||
|
1 | 1 | HG(1) |
|
2 | 2 | ===== |
|
3 | 3 | Matt Mackall <mpm@selenic.com> |
|
4 | 4 | |
|
5 | 5 | NAME |
|
6 | 6 | ---- |
|
7 | 7 | hg - Mercurial source code management system |
|
8 | 8 | |
|
9 | 9 | SYNOPSIS |
|
10 | 10 | -------- |
|
11 | 11 | 'hg' [-v -d -q -y] <command> [command options] [files] |
|
12 | 12 | |
|
13 | 13 | DESCRIPTION |
|
14 | 14 | ----------- |
|
15 | 15 | The hg(1) command provides a command line interface to the Mercurial system. |
|
16 | 16 | |
|
17 | 17 | OPTIONS |
|
18 | 18 | ------- |
|
19 | 19 | |
|
20 | 20 | --debug, -d:: |
|
21 | 21 | enable debugging output |
|
22 | 22 | |
|
23 | 23 | --quiet, -q:: |
|
24 | 24 | suppress output |
|
25 | 25 | |
|
26 | 26 | --verbose, -v:: |
|
27 | 27 | enable additional output |
|
28 | 28 | |
|
29 | 29 | --noninteractive, -y:: |
|
30 | 30 | do not prompt, assume 'yes' for any required answers |
|
31 | 31 | |
|
32 | 32 | COMMAND ELEMENTS |
|
33 | 33 | ---------------- |
|
34 | 34 | |
|
35 | 35 | files ...:: |
|
36 | 36 | indicates one or more filename or relative path filenames |
|
37 | 37 | |
|
38 | 38 | path:: |
|
39 | 39 | indicates a path on the local machine |
|
40 | 40 | |
|
41 | 41 | revision:: |
|
42 | 42 | indicates a changeset which can be specified as a changeset revision |
|
43 | 43 | number, a tag, or a unique substring of the changeset hash value |
|
44 | 44 | |
|
45 | 45 | repository path:: |
|
46 | 46 | either the pathname of a local repository or the URI of a remote |
|
47 | 47 | repository. There are two available URI protocols, http:// which is |
|
48 | 48 | fast and the old-http:// protocol which is much slower but does not |
|
49 | 49 | require a special server on the web host. |
|
50 | 50 | |
|
51 | 51 | COMMANDS |
|
52 | 52 | -------- |
|
53 | 53 | |
|
54 | 54 | add [files ...]:: |
|
55 | 55 | Schedule files to be version controlled and added to the repository. |
|
56 | 56 | |
|
57 | 57 | The files will be added to the repository at the next commit. |
|
58 | 58 | |
|
59 | 59 | addremove:: |
|
60 | 60 | Add all new files and remove all missing files from the repository. |
|
61 | 61 | |
|
62 | 62 | New files are ignored if they match any of the patterns in .hgignore. As |
|
63 | 63 | with add, these changes take effect at the next commit. |
|
64 | 64 | |
|
65 | 65 | annotate [-r <rev> -u -n -c] [files ...]:: |
|
66 | 66 | List changes in files, showing the revision id responsible for each line |
|
67 | 67 | |
|
68 | 68 | This command is useful to discover who did a change or when a change took |
|
69 | 69 | place. |
|
70 | 70 | |
|
71 | 71 | options: |
|
72 | 72 | -r, --revision <rev> annotate the specified revision |
|
73 | 73 | -u, --user list the author |
|
74 | 74 | -c, --changeset list the changeset |
|
75 | 75 | -n, --number list the revision number (default) |
|
76 | 76 | |
|
77 | 77 | cat <file> [revision]:: |
|
78 | 78 | Output to stdout the given revision for the specified file. |
|
79 | 79 | |
|
80 | 80 | If no revision is given then the tip is used. |
|
81 | 81 | |
|
82 | 82 | clone [-U] <source> [dest]:: |
|
83 | 83 | Create a copy of an existing repository in a new directory. |
|
84 | 84 | |
|
85 | 85 | If no destination directory name is specified, it defaults to the |
|
86 | 86 | basename of the source. |
|
87 | 87 | |
|
88 | 88 | The source is added to the new repository's .hg/hgrc file to be used in |
|
89 | 89 | future pulls. |
|
90 | 90 | |
|
91 | 91 | For efficiency, hardlinks are used for cloning whenever the |
|
92 | 92 | source and destination are on the same filesystem. |
|
93 | 93 | |
|
94 | 94 | options: |
|
95 | 95 | -U, --noupdate do not update the new working directory |
|
96 | 96 | |
|
97 | 97 | commit [-A -t -l <file> -t <text> -u <user> -d <datecode>] [files...]:: |
|
98 | 98 | Commit changes to the given files into the repository. |
|
99 | 99 | |
|
100 | 100 | If a list of files is omitted, all changes reported by "hg status" |
|
101 | 101 | will be commited. |
|
102 | 102 | |
|
103 | 103 | The HGEDITOR or EDITOR environment variables are used to start an |
|
104 | 104 | editor to add a commit comment. |
|
105 | 105 | |
|
106 | 106 | Options: |
|
107 | 107 | |
|
108 | 108 | -A, --addremove run addremove during commit |
|
109 | 109 | -t, --text <text> use <text> as commit message |
|
110 | 110 | -l, --logfile <file> show the commit message for the given file |
|
111 | 111 | -d, --date <datecode> record datecode as commit date |
|
112 | 112 | -u, --user <user> record user as commiter |
|
113 | 113 | |
|
114 | 114 | aliases: ci |
|
115 | 115 | |
|
116 | 116 | copy <source> <dest>:: |
|
117 | 117 | Mark <dest> file as a copy or rename of a <source> one |
|
118 | 118 | |
|
119 | 119 | This command takes effect for the next commit. |
|
120 | 120 | |
|
121 | 121 | diff [-r revision] [-r revision] [files ...]:: |
|
122 | 122 | Show differences between revisions for the specified files. |
|
123 | 123 | |
|
124 | 124 | Differences between files are shown using the unified diff format. |
|
125 | 125 | |
|
126 | 126 | When two revision arguments are given, then changes are shown |
|
127 | 127 | between those revisions. If only one revision is specified then |
|
128 | 128 | that revision is compared to the working directory, and, when no |
|
129 | 129 | revisions are specified, the working directory files are compared |
|
130 | 130 | to its parent. |
|
131 | 131 | |
|
132 | 132 | export [-o filespec] [revision] ...:: |
|
133 | 133 | Print the changeset header and diffs for one or more revisions. |
|
134 | 134 | |
|
135 | 135 | The information shown in the changeset header is: author, |
|
136 | 136 | changeset hash, parent and commit comment. |
|
137 | 137 | |
|
138 | 138 | Output may be to a file, in which case the name of the file is |
|
139 | 139 | given using a format string. The formatting rules are as follows: |
|
140 | 140 | |
|
141 | 141 | %% literal "%" character |
|
142 | 142 | %H changeset hash (40 bytes of hexadecimal) |
|
143 | 143 | %N number of patches being generated |
|
144 | 144 | %R changeset revision number |
|
145 | 145 | %b basename of the exporting repository |
|
146 | 146 | %h short-form changeset hash (12 bytes of hexadecimal) |
|
147 | 147 | %n zero-padded sequence number, starting at 1 |
|
148 | 148 | %r zero-padded changeset revision number |
|
149 | 149 | |
|
150 | 150 | Options: |
|
151 | 151 | |
|
152 | 152 | -o, --output <filespec> print output to file with formatted named |
|
153 | 153 | |
|
154 | 154 | forget [files]:: |
|
155 | 155 | Undo an 'hg add' scheduled for the next commit. |
|
156 | 156 | |
|
157 | 157 | heads:: |
|
158 | 158 | Show all repository head changesets. |
|
159 | 159 | |
|
160 | 160 | Repository "heads" are changesets that don't have children |
|
161 | 161 | changesets. They are where development generally takes place and |
|
162 | 162 | are the usual targets for update and merge operations. |
|
163 | 163 | |
|
164 | 164 | identify:: |
|
165 | 165 | Print a short summary of the current state of the repo. |
|
166 | 166 | |
|
167 | 167 | This summary identifies the repository state using one or two parent |
|
168 | 168 | hash identifiers, followed by a "+" if there are uncommitted changes |
|
169 | 169 | in the working directory, followed by a list of tags for this revision. |
|
170 | 170 | |
|
171 | 171 | aliases: id |
|
172 | 172 | |
|
173 | 173 | import [-p <n> -b <base> -q] <patches>:: |
|
174 | 174 | Import a list of patches and commit them individually. |
|
175 | 175 | |
|
176 | 176 | options: |
|
177 | 177 | -p, --strip <n> directory strip option for patch. This has the same |
|
178 | 178 | meaning as the correnponding patch option |
|
179 | 179 | -b <path> base directory to read patches from |
|
180 | 180 | |
|
181 | 181 | aliases: patch |
|
182 | 182 | |
|
183 | 183 | init:: |
|
184 | 184 | Initialize a new repository in the current directory. |
|
185 | 185 | |
|
186 | 186 | locate [options] [patterns]:: |
|
187 | 187 | Print all files under Mercurial control whose basenames match the |
|
188 | 188 | given patterns. |
|
189 | 189 | |
|
190 | 190 | Patterns are shell-style globs. To restrict searches to specific |
|
191 | 191 | directories, use the "-i <pat>" option. To eliminate particular |
|
192 | 192 | directories from searching, use the "-x <pat>" option. |
|
193 | 193 | |
|
194 | 194 | This command searches the current directory and its |
|
195 | 195 | subdirectories. To search an entire repository, move to the root |
|
196 | 196 | of the repository. |
|
197 | 197 | |
|
198 | 198 | If no patterns are given to match, this command prints all file |
|
199 | 199 | names. |
|
200 | 200 | |
|
201 | 201 | If you want to feed the output of this command into the "xargs" |
|
202 | 202 | command, use the "-0" option to both this command and "xargs". |
|
203 | 203 | This will avoid the problem of "xargs" treating single filenames |
|
204 | 204 | that contain white space as multiple file names. |
|
205 | 205 | |
|
206 | 206 | options: |
|
207 | 207 | |
|
208 | 208 | -0, --print0 end filenames with NUL, for use with xargs |
|
209 | 209 | -f, --fullpath print complete paths from the filesystem root |
|
210 | 210 | -i, --include <pat> include directories matching the given globs |
|
211 | 211 | -r, --rev <rev> search the repository as it stood at rev |
|
212 | 212 | -x, --exclude <pat> exclude directories matching the given globs |
|
213 | 213 | |
|
214 | 214 | log [-r revision ...] [-p] [file]:: |
|
215 | 215 | Print the revision history of the specified file or the entire project. |
|
216 | 216 | |
|
217 | 217 | By default this command outputs: changeset id and hash, tags, |
|
218 | 218 | parents, user, date and time, and a summary for each commit. The |
|
219 | 219 | -v switch adds some more detail, such as changed files, manifest |
|
220 | 220 | hashes or message signatures. |
|
221 | 221 | |
|
222 | 222 | options: |
|
223 | 223 | -r, --rev <A>, ... When a revision argument is given, only this file or |
|
224 | 224 | changelog revision is displayed. With two revision |
|
225 | 225 | arguments all revisions in this range are listed. |
|
226 | 226 | Additional revision arguments may be given repeating |
|
227 | 227 | the above cycle. |
|
228 | 228 | -p, --patch show patch |
|
229 | 229 | |
|
230 | 230 | aliases: history |
|
231 | 231 | |
|
232 | 232 | manifest [revision]:: |
|
233 | 233 | Print a list of version controlled files for the given revision. |
|
234 | 234 | |
|
235 | 235 | The manifest is the list of files being version controlled. If no revision |
|
236 | 236 | is given then the tip is used. |
|
237 | 237 | |
|
238 | 238 | parents:: |
|
239 | 239 | Print the working directory's parent revisions. |
|
240 | 240 | |
|
241 | 241 | pull <repository path>:: |
|
242 | 242 | Pull changes from a remote repository to a local one. |
|
243 | 243 | |
|
244 | 244 | This finds all changes from the repository at the specified path |
|
245 | 245 | or URL and adds them to the local repository. By default, this |
|
246 | 246 | does not update the copy of the project in the working directory. |
|
247 | 247 | |
|
248 | 248 | options: |
|
249 | 249 | -u, --update update the working directory to tip after pull |
|
250 | 250 | |
|
251 | 251 | push <destination>:: |
|
252 | 252 | Push changes from the local repository to the given destination. |
|
253 | 253 | |
|
254 | 254 | This is the symmetrical operation for pull. It helps to move |
|
255 | 255 | changes from the current repository to a different one. If the |
|
256 | 256 | destination is local this is identical to a pull in that directory |
|
257 | 257 | from the current one. |
|
258 | 258 | |
|
259 | 259 | The other currently available push method is SSH. This requires an |
|
260 | 260 | accessible shell account on the destination machine and a copy of |
|
261 | 261 | hg in the remote path. Destinations are specified in the following |
|
262 | 262 | form: |
|
263 | 263 | |
|
264 | 264 | ssh://[user@]host[:port]/path |
|
265 | 265 | |
|
266 | 266 | rawcommit [-p -d -u -F -t -l]:: |
|
267 | 267 | Lowlevel commit, for use in helper scripts. |
|
268 | 268 | |
|
269 | 269 | This command is not intended to be used by normal users, as it is |
|
270 | 270 | primarily useful for importing from other SCMs. |
|
271 | 271 | |
|
272 | 272 | recover:: |
|
273 | 273 | Recover from an interrupted commit or pull. |
|
274 | 274 | |
|
275 | 275 | This command tries to fix the repository status after an interrupted |
|
276 | 276 | operation. It should only be necessary when Mercurial suggests it. |
|
277 | 277 | |
|
278 | 278 | remove [files ...]:: |
|
279 | 279 | Schedule the indicated files for removal from the repository. |
|
280 | 280 | |
|
281 | 281 | This command shedules the files to be removed at the next commit. |
|
282 | 282 | This only removes files from the current branch, not from the |
|
283 | 283 | entire project history. |
|
284 | 284 | |
|
285 | 285 | aliases: rm |
|
286 | 286 | |
|
287 | 287 | revert [names ...]:: |
|
288 | 288 | Revert any uncommitted modifications made to the named files or |
|
289 | 289 | directories. This restores the contents of the affected files to |
|
290 | 290 | an unmodified state. |
|
291 | 291 | |
|
292 | 292 | If a file has been deleted, it is recreated. If the executable |
|
293 | 293 | mode of a file was changed, it is reset. |
|
294 | 294 | |
|
295 | 295 | If a directory is given, all files in that directory and its |
|
296 | 296 | subdirectories are reverted. |
|
297 | 297 | |
|
298 | 298 | If no arguments are given, all files in the current directory and |
|
299 | 299 | its subdirectories are reverted. |
|
300 | 300 | |
|
301 | 301 | options: |
|
302 | 302 | -r, --rev <rev> revision to revert to |
|
303 | 303 | -n, --nonrecursive do not recurse into subdirectories |
|
304 | 304 | |
|
305 | 305 | root:: |
|
306 | 306 | Print the root directory of the current repository. |
|
307 | 307 | |
|
308 | 308 | serve [options]:: |
|
309 | 309 | Start a local HTTP repository browser and pull server. |
|
310 | 310 | |
|
311 | 311 | By default, the server logs accesses to stdout and errors to |
|
312 | 312 | stderr. Use the "-A" and "-E" options to log to files. |
|
313 | 313 | |
|
314 | 314 | options: |
|
315 | 315 | -A, --accesslog <file> name of access log file to write to |
|
316 | 316 | -E, --errorlog <file> name of error log file to write to |
|
317 | 317 | -a, --address <addr> address to use |
|
318 | 318 | -p, --port <n> port to use (default: 8000) |
|
319 | 319 | -n, --name <name> name to show in web pages (default: working dir) |
|
320 | 320 | -t, --templatedir <path> web templates to use |
|
321 | 321 | |
|
322 | 322 | status:: |
|
323 | 323 | Show changed files in the working directory. |
|
324 | 324 | |
|
325 | 325 | The codes used to show the status of files are: |
|
326 | 326 | |
|
327 | 327 | C = changed |
|
328 | 328 | A = added |
|
329 | 329 | R = removed |
|
330 | 330 | ? = not tracked |
|
331 | 331 | |
|
332 | tag [-t <text> -d <datecode> -u <user>] <name> [revision]:: | |
|
332 | tag [-l -t <text> -d <datecode> -u <user>] <name> [revision]:: | |
|
333 | 333 | Name a particular revision using <name>. |
|
334 | 334 | |
|
335 | 335 | Tags are used to name particular revisions of the repository and are |
|
336 | 336 | very useful to compare different revision, to go back to significant |
|
337 | 337 | earlier versions or to mark branch points as releases, etc. |
|
338 | 338 | |
|
339 | 339 | If no revision is given, the tip is used. |
|
340 | 340 | |
|
341 | 341 | To facilitate version control, distribution, and merging of tags, |
|
342 | 342 | they are stored as a file named ".hgtags" which is managed |
|
343 | 343 | similarly to other project files and can be hand-edited if |
|
344 | 344 | necessary. |
|
345 | 345 | |
|
346 | 346 | options: |
|
347 | -l, --local make the tag local | |
|
347 | 348 | -t, --text <text> message for tag commit log entry |
|
348 | 349 | -d, --date <datecode> datecode for commit |
|
349 | 350 | -u, --user <user> user for commit |
|
350 | 351 | |
|
351 | Note: Mercurial also has support for "local tags" that are not | |
|
352 | version-controlled or distributed which are stored in the .hg/hgrc | |
|
353 | file. | |
|
352 | Note: Local tags are not version-controlled or distributed and are | |
|
353 | stored in the .hg/localtags file. If there exists a local tag and | |
|
354 | a public tag with the same name, local tag is used. | |
|
354 | 355 | |
|
355 | 356 | tags:: |
|
356 | 357 | List the repository tags. |
|
357 | 358 | |
|
358 | 359 | This lists both regular and local tags. |
|
359 | 360 | |
|
360 | 361 | tip:: |
|
361 | 362 | Show the tip revision. |
|
362 | 363 | |
|
363 | 364 | undo:: |
|
364 | 365 | Undo the last commit or pull transaction. |
|
365 | 366 | |
|
366 | 367 | Roll back the last pull or commit transaction on the |
|
367 | 368 | repository, restoring the project to its earlier state. |
|
368 | 369 | |
|
369 | 370 | This command should be used with care. There is only one level of |
|
370 | 371 | undo and there is no redo. |
|
371 | 372 | |
|
372 | 373 | This command is not intended for use on public repositories. Once |
|
373 | 374 | a change is visible for pull by other users, undoing it locally is |
|
374 | 375 | ineffective. |
|
375 | 376 | |
|
376 | 377 | update [-m -C] [revision]:: |
|
377 | 378 | Update the working directory to the specified revision. |
|
378 | 379 | |
|
379 | 380 | By default, update will refuse to run if doing so would require |
|
380 | 381 | merging or discarding local changes. |
|
381 | 382 | |
|
382 | 383 | With the -m option, a merge will be performed. |
|
383 | 384 | |
|
384 | 385 | With the -C option, local changes will be lost. |
|
385 | 386 | |
|
386 | 387 | options: |
|
387 | 388 | -m, --merge allow merging of branches |
|
388 | 389 | -C, --clean overwrite locally modified files |
|
389 | 390 | |
|
390 | 391 | aliases: up checkout co |
|
391 | 392 | |
|
392 | 393 | verify:: |
|
393 | 394 | Verify the integrity of the current repository. |
|
394 | 395 | |
|
395 | 396 | This will perform an extensive check of the repository's |
|
396 | 397 | integrity, validating the hashes and checksums of each entry in |
|
397 | 398 | the changelog, manifest, and tracked files, as well as the |
|
398 | 399 | integrity of their crosslinks and indices. |
|
399 | 400 | |
|
400 | 401 | SPECIFYING SINGLE REVISIONS |
|
401 | 402 | --------------------------- |
|
402 | 403 | |
|
403 | 404 | Mercurial accepts several notations for identifying individual |
|
404 | 405 | revisions. |
|
405 | 406 | |
|
406 | 407 | A plain integer is treated as a revision number. Negative |
|
407 | 408 | integers are treated as offsets from the tip, with -1 denoting the |
|
408 | 409 | tip. |
|
409 | 410 | |
|
410 | 411 | A 40-digit hexadecimal string is treated as a unique revision |
|
411 | 412 | identifier. |
|
412 | 413 | |
|
413 | 414 | A hexadecimal string less than 40 characters long is treated as a |
|
414 | 415 | unique revision identifier, and referred to as a short-form |
|
415 | 416 | identifier. A short-form identifier is only valid if it is the |
|
416 | 417 | prefix of one full-length identifier. |
|
417 | 418 | |
|
418 | 419 | Any other string is treated as a tag name, which is a symbolic |
|
419 | 420 | name associated with a revision identifier. Tag names may not |
|
420 | 421 | contain the ":" character. |
|
421 | 422 | |
|
422 | 423 | The reserved name "tip" is a special tag that always identifies |
|
423 | 424 | the most recent revision. |
|
424 | 425 | |
|
425 | 426 | SPECIFYING MULTIPLE REVISIONS |
|
426 | 427 | ----------------------------- |
|
427 | 428 | |
|
428 | 429 | When Mercurial accepts more than one revision, they may be |
|
429 | 430 | specified individually, or provided as a continuous range, |
|
430 | 431 | separated by the ":" character. |
|
431 | 432 | |
|
432 | 433 | The syntax of range notation is [BEGIN]:[END], where BEGIN and END |
|
433 | 434 | are revision identifiers. Both BEGIN and END are optional. If |
|
434 | 435 | BEGIN is not specified, it defaults to revision number 0. If END |
|
435 | 436 | is not specified, it defaults to the tip. The range ":" thus |
|
436 | 437 | means "all revisions". |
|
437 | 438 | |
|
438 | 439 | If BEGIN is greater than END, revisions are treated in reverse |
|
439 | 440 | order. |
|
440 | 441 | |
|
441 | 442 | A range acts as an open interval. This means that a range of 3:5 |
|
442 | 443 | gives 3, 4 and 5. Similarly, a range of 4:2 gives 4, 3, and 2. |
|
443 | 444 | |
|
444 | 445 | ENVIRONMENT VARIABLES |
|
445 | 446 | --------------------- |
|
446 | 447 | |
|
447 | 448 | HGEDITOR:: |
|
448 | 449 | This is the name of the editor to use when committing. Defaults to the |
|
449 | 450 | value of EDITOR. |
|
450 | 451 | |
|
451 | 452 | (deprecated, use .hgrc) |
|
452 | 453 | |
|
453 | 454 | HGMERGE:: |
|
454 | 455 | An executable to use for resolving merge conflicts. The program |
|
455 | 456 | will be executed with three arguments: local file, remote file, |
|
456 | 457 | ancestor file. |
|
457 | 458 | |
|
458 | 459 | The default program is "hgmerge", which is a shell script provided |
|
459 | 460 | by Mercurial with some sensible defaults. |
|
460 | 461 | |
|
461 | 462 | (deprecated, use .hgrc) |
|
462 | 463 | |
|
463 | 464 | HGUSER:: |
|
464 | 465 | This is the string used for the author of a commit. |
|
465 | 466 | |
|
466 | 467 | (deprecated, use .hgrc) |
|
467 | 468 | |
|
468 | 469 | EMAIL:: |
|
469 | 470 | If HGUSER is not set, this will be used as the author for a commit. |
|
470 | 471 | |
|
471 | 472 | LOGNAME:: |
|
472 | 473 | If neither HGUSER nor EMAIL is set, LOGNAME will be used (with |
|
473 | 474 | '@hostname' appended) as the author value for a commit. |
|
474 | 475 | |
|
475 | 476 | EDITOR:: |
|
476 | 477 | This is the name of the editor used in the hgmerge script. It will be |
|
477 | 478 | used for commit messages if HGEDITOR isn't set. Defaults to 'vi'. |
|
478 | 479 | |
|
479 | 480 | PYTHONPATH:: |
|
480 | 481 | This is used by Python to find imported modules and may need to be set |
|
481 | 482 | appropriately if Mercurial is not installed system-wide. |
|
482 | 483 | |
|
483 | 484 | FILES |
|
484 | 485 | ----- |
|
485 | 486 | .hgignore:: |
|
486 | 487 | This file contains regular expressions (one per line) that describe file |
|
487 | 488 | names that should be ignored by hg. |
|
488 | 489 | |
|
489 | 490 | .hgtags:: |
|
490 | 491 | This file contains changeset hash values and text tag names (one of each |
|
491 | 492 | seperated by spaces) that correspond to tagged versions of the repository |
|
492 | 493 | contents. |
|
493 | 494 | |
|
494 | 495 | $HOME/.hgrc, .hg/hgrc:: |
|
495 | 496 | This file contains defaults and configuration. Values in .hg/hgrc |
|
496 | 497 | override those in .hgrc. |
|
497 | 498 | |
|
498 | 499 | |
|
499 | 500 | UI OPTIONS |
|
500 | 501 | ---------- |
|
501 | 502 | |
|
502 | 503 | Various configuration options can be set in .hgrc: |
|
503 | 504 | |
|
504 | 505 | ------------- |
|
505 | 506 | [ui] |
|
506 | 507 | verbose = 0 |
|
507 | 508 | username = Matt Mackall <mpm@selenic.com> |
|
508 | 509 | editor = hgeditor |
|
509 | 510 | merge = hgmerge |
|
510 | 511 | ------------- |
|
511 | 512 | |
|
512 | 513 | |
|
513 | 514 | NAMED REPOSITORIES |
|
514 | 515 | ------------------ |
|
515 | 516 | |
|
516 | 517 | To give symbolic names to a repository, create a section in .hgrc |
|
517 | 518 | or .hg/hgrc containing assignments of names to paths. Example: |
|
518 | 519 | |
|
519 | 520 | ----------------- |
|
520 | 521 | [paths] |
|
521 | 522 | hg = http://selenic.com/hg |
|
522 | 523 | tah = http://hg.intevation.org/mercurial-tah/ |
|
523 | 524 | ----------------- |
|
524 | 525 | |
|
525 | 526 | |
|
526 | 527 | LOCAL TAGS |
|
527 | 528 | ---------- |
|
528 | 529 | |
|
529 | 530 | To create tags that are local to the repository and not distributed or |
|
530 | 531 | version-controlled, create an hgrc section like the following: |
|
531 | 532 | |
|
532 | 533 | ---------------- |
|
533 | 534 | [tags] |
|
534 | 535 | working = 2dcced388cab3677a8f543c3c47a0ad34ac9d435 |
|
535 | 536 | tested = 12e0fdbc57a0be78f0e817fd1d170a3615cd35da |
|
536 | 537 | ---------------- |
|
537 | 538 | |
|
538 | 539 | |
|
539 | 540 | HOOKS |
|
540 | 541 | ----- |
|
541 | 542 | |
|
542 | 543 | Mercurial supports a set of 'hook', commands that get automatically |
|
543 | 544 | executed by various actions such as starting or finishing a commit. To |
|
544 | 545 | specify a hook, simply create an hgrc section like the following: |
|
545 | 546 | |
|
546 | 547 | ----------------- |
|
547 | 548 | [hooks] |
|
548 | 549 | precommit = echo "this hook gets executed immediately before a commit" |
|
549 | 550 | commit = hg export $NODE | mail -s "new commit $NODE" commit-list |
|
550 | 551 | ----------------- |
|
551 | 552 | |
|
552 | 553 | |
|
553 | 554 | NON_TRANSPARENT PROXY SUPPORT |
|
554 | 555 | ----------------------------- |
|
555 | 556 | |
|
556 | 557 | To access a Mercurial repository through a proxy, create a file |
|
557 | 558 | $HOME/.hgrc in the following format: |
|
558 | 559 | |
|
559 | 560 | -------------- |
|
560 | 561 | [http_proxy] |
|
561 | 562 | host=myproxy:8080 |
|
562 | 563 | user=<username> |
|
563 | 564 | passwd=<password> |
|
564 | 565 | no=<localhost1>,<localhost2>,<localhost3>,... |
|
565 | 566 | -------------- |
|
566 | 567 | |
|
567 | 568 | "user" and "passwd" fields are used for authenticating proxies, "no" is a |
|
568 | 569 | comma-separated list of local host names to not proxy. |
|
569 | 570 | |
|
570 | 571 | BUGS |
|
571 | 572 | ---- |
|
572 | 573 | Probably lots, please post them to the mailing list (See Resources below) |
|
573 | 574 | when you find them. |
|
574 | 575 | |
|
575 | 576 | AUTHOR |
|
576 | 577 | ------ |
|
577 | 578 | Written by Matt Mackall <mpm@selenic.com> |
|
578 | 579 | |
|
579 | 580 | RESOURCES |
|
580 | 581 | --------- |
|
581 | 582 | http://selenic.com/mercurial[Main Web Site] |
|
582 | 583 | |
|
583 | 584 | http://selenic.com/hg[Source code repository] |
|
584 | 585 | |
|
585 | 586 | http://selenic.com/mailman/listinfo/mercurial[Mailing list] |
|
586 | 587 | |
|
587 | 588 | COPYING |
|
588 | 589 | ------- |
|
589 | 590 | Copyright (C) 2005 Matt Mackall. |
|
590 | 591 | Free use of this software is granted under the terms of the GNU General |
|
591 | 592 | Public License (GPL). |
General Comments 0
You need to be logged in to leave comments.
Login now