rev |
line source |
bos@553
|
1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
|
bos@553
|
2
|
bos@559
|
3 <chapter id="chap:tour-basic">
|
bos@572
|
4 <?dbhtml filename="a-tour-of-mercurial-the-basics.html"?>
|
bos@553
|
5 <title>A tour of Mercurial: the basics</title>
|
bos@559
|
6
|
bos@559
|
7 <sect1 id="sec:tour:install">
|
bos@553
|
8 <title>Installing Mercurial on your system</title>
|
bos@553
|
9
|
bos@584
|
10 <para id="x_1">Prebuilt binary packages of Mercurial are available for
|
bos@553
|
11 every popular operating system. These make it easy to start
|
bos@553
|
12 using Mercurial on your computer immediately.</para>
|
bos@553
|
13
|
bos@553
|
14 <sect2>
|
bos@609
|
15 <title>Windows</title>
|
bos@609
|
16
|
bos@609
|
17 <para id="x_c">The best version of Mercurial for Windows is
|
bos@609
|
18 TortoiseHg, which can be found at <ulink
|
bos@609
|
19 url="http://bitbucket.org/tortoisehg/stable/wiki/Home">http://bitbucket.org/tortoisehg/stable/wiki/Home</ulink>.
|
bos@609
|
20 This package has no external dependencies; it <quote>just
|
bos@609
|
21 works</quote>. It provides both command line and graphical
|
bos@609
|
22 user interfaces.</para>
|
bos@609
|
23
|
bos@609
|
24 </sect2>
|
bos@609
|
25
|
bos@609
|
26 <sect2>
|
bos@609
|
27 <title>Mac OS X</title>
|
bos@609
|
28
|
bos@609
|
29 <para id="x_a">Lee Cantey publishes an installer of Mercurial
|
bos@609
|
30 for Mac OS X at <ulink
|
bos@609
|
31 url="http://mercurial.berkwood.com">http://mercurial.berkwood.com</ulink>.</para>
|
bos@609
|
32 </sect2>
|
bos@609
|
33
|
bos@609
|
34 <sect2>
|
bos@553
|
35 <title>Linux</title>
|
bos@553
|
36
|
bos@584
|
37 <para id="x_2">Because each Linux distribution has its own packaging
|
bos@553
|
38 tools, policies, and rate of development, it's difficult to
|
bos@553
|
39 give a comprehensive set of instructions on how to install
|
bos@553
|
40 Mercurial binaries. The version of Mercurial that you will
|
bos@553
|
41 end up with can vary depending on how active the person is who
|
bos@553
|
42 maintains the package for your distribution.</para>
|
bos@553
|
43
|
bos@584
|
44 <para id="x_3">To keep things simple, I will focus on installing
|
bos@553
|
45 Mercurial from the command line under the most popular Linux
|
bos@553
|
46 distributions. Most of these distributions provide graphical
|
bos@553
|
47 package managers that will let you install Mercurial with a
|
bos@553
|
48 single click; the package name to look for is
|
bos@553
|
49 <literal>mercurial</literal>.</para>
|
bos@553
|
50
|
bos@553
|
51 <itemizedlist>
|
bos@609
|
52 <listitem><para id="x_4">Ubuntu and Debian:</para>
|
bos@579
|
53 <programlisting>apt-get install mercurial</programlisting></listitem>
|
bos@609
|
54 <listitem><para id="x_5">Fedora and OpenSUSE:</para>
|
bos@579
|
55 <programlisting>yum install mercurial</programlisting></listitem>
|
bos@584
|
56 <listitem><para id="x_6">Gentoo:</para>
|
bos@553
|
57 <programlisting>emerge mercurial</programlisting></listitem>
|
bos@553
|
58 </itemizedlist>
|
bos@553
|
59
|
bos@553
|
60 </sect2>
|
bos@553
|
61 <sect2>
|
bos@553
|
62 <title>Solaris</title>
|
bos@553
|
63
|
bos@584
|
64 <para id="x_9">SunFreeWare, at <ulink
|
bos@553
|
65 url="http://www.sunfreeware.com">http://www.sunfreeware.com</ulink>,
|
bos@609
|
66 provides prebuilt packages of Mercurial.</para>
|
bos@609
|
67
|
bos@609
|
68 </sect2>
|
bos@609
|
69
|
bos@553
|
70 </sect1>
|
bos@609
|
71
|
bos@553
|
72 <sect1>
|
bos@553
|
73 <title>Getting started</title>
|
bos@553
|
74
|
bos@584
|
75 <para id="x_e">To begin, we'll use the <command role="hg-cmd">hg
|
bos@553
|
76 version</command> command to find out whether Mercurial is
|
bos@553
|
77 actually installed properly. The actual version information
|
bos@553
|
78 that it prints isn't so important; it's whether it prints
|
bos@559
|
79 anything at all that we care about.</para>
|
bos@559
|
80
|
bos@566
|
81 &interaction.tour.version;
|
bos@553
|
82
|
bos@553
|
83 <sect2>
|
bos@553
|
84 <title>Built-in help</title>
|
bos@553
|
85
|
bos@584
|
86 <para id="x_f">Mercurial provides a built-in help system. This is
|
bos@559
|
87 invaluable for those times when you find yourself stuck
|
bos@559
|
88 trying to remember how to run a command. If you are
|
bos@559
|
89 completely stuck, simply run <command role="hg-cmd">hg
|
bos@559
|
90 help</command>; it will print a brief list of commands,
|
bos@559
|
91 along with a description of what each does. If you ask for
|
bos@559
|
92 help on a specific command (as below), it prints more
|
bos@559
|
93 detailed information.</para>
|
bos@559
|
94
|
bos@566
|
95 &interaction.tour.help;
|
bos@559
|
96
|
bos@584
|
97 <para id="x_10">For a more impressive level of detail (which you won't
|
bos@559
|
98 usually need) run <command role="hg-cmd">hg help <option
|
bos@559
|
99 role="hg-opt-global">-v</option></command>. The <option
|
bos@559
|
100 role="hg-opt-global">-v</option> option is short for
|
bos@559
|
101 <option role="hg-opt-global">--verbose</option>, and tells
|
bos@559
|
102 Mercurial to print more information than it usually
|
bos@559
|
103 would.</para>
|
bos@553
|
104
|
bos@553
|
105 </sect2>
|
bos@553
|
106 </sect1>
|
bos@553
|
107 <sect1>
|
bos@553
|
108 <title>Working with a repository</title>
|
bos@553
|
109
|
bos@584
|
110 <para id="x_11">In Mercurial, everything happens inside a
|
bos@553
|
111 <emphasis>repository</emphasis>. The repository for a project
|
bos@553
|
112 contains all of the files that <quote>belong to</quote> that
|
bos@553
|
113 project, along with a historical record of the project's
|
bos@553
|
114 files.</para>
|
bos@553
|
115
|
bos@584
|
116 <para id="x_12">There's nothing particularly magical about a repository; it
|
bos@553
|
117 is simply a directory tree in your filesystem that Mercurial
|
bos@553
|
118 treats as special. You can rename or delete a repository any
|
bos@553
|
119 time you like, using either the command line or your file
|
bos@553
|
120 browser.</para>
|
bos@553
|
121
|
bos@553
|
122 <sect2>
|
bos@553
|
123 <title>Making a local copy of a repository</title>
|
bos@553
|
124
|
bos@584
|
125 <para id="x_13"><emphasis>Copying</emphasis> a repository is just a little
|
bos@553
|
126 bit special. While you could use a normal file copying
|
bos@553
|
127 command to make a copy of a repository, it's best to use a
|
bos@553
|
128 built-in command that Mercurial provides. This command is
|
bos@553
|
129 called <command role="hg-cmd">hg clone</command>, because it
|
bos@609
|
130 makes an identical copy of an existing repository.</para>
|
bos@559
|
131
|
bos@566
|
132 &interaction.tour.clone;
|
bos@559
|
133
|
bos@609
|
134 <para>One advantage of using <command role="hg-cmd">hg
|
bos@609
|
135 clone</command> is that, as we can see above, it lets us clone
|
bos@609
|
136 repositories over the network. Another is that it remembers
|
bos@609
|
137 where we cloned from, which we'll find useful soon when we
|
bos@609
|
138 want to fetch new changes from another repository.</para>
|
bos@609
|
139
|
bos@584
|
140 <para id="x_14">If our clone succeeded, we should now have a local
|
bos@559
|
141 directory called <filename class="directory">hello</filename>.
|
bos@559
|
142 This directory will contain some files.</para>
|
bos@559
|
143
|
bos@566
|
144 &interaction.tour.ls;
|
bos@559
|
145
|
bos@584
|
146 <para id="x_15">These files have the same contents and history in our
|
bos@559
|
147 repository as they do in the repository we cloned.</para>
|
bos@553
|
148
|
bos@609
|
149 <para id="x_16">Every Mercurial repository is complete,
|
bos@609
|
150 self-contained, and independent. It contains its own private
|
bos@609
|
151 copy of a project's files and history. As we just mentioned,
|
bos@609
|
152 a cloned repository remembers the location of the repository
|
bos@609
|
153 it was cloned from, but Mercurial will not communicate with
|
bos@609
|
154 that repository, or any other, unless you tell it to.</para>
|
bos@553
|
155
|
bos@584
|
156 <para id="x_17">What this means for now is that we're free to experiment
|
bos@553
|
157 with our repository, safe in the knowledge that it's a private
|
bos@553
|
158 <quote>sandbox</quote> that won't affect anyone else.</para>
|
bos@553
|
159
|
bos@553
|
160 </sect2>
|
bos@553
|
161 <sect2>
|
bos@553
|
162 <title>What's in a repository?</title>
|
bos@553
|
163
|
bos@584
|
164 <para id="x_18">When we take a more detailed look inside a repository, we
|
bos@553
|
165 can see that it contains a directory named <filename
|
bos@553
|
166 class="directory">.hg</filename>. This is where Mercurial
|
bos@559
|
167 keeps all of its metadata for the repository.</para>
|
bos@559
|
168
|
bos@566
|
169 &interaction.tour.ls-a;
|
bos@553
|
170
|
bos@584
|
171 <para id="x_19">The contents of the <filename
|
bos@553
|
172 class="directory">.hg</filename> directory and its
|
bos@553
|
173 subdirectories are private to Mercurial. Every other file and
|
bos@553
|
174 directory in the repository is yours to do with as you
|
bos@553
|
175 please.</para>
|
bos@553
|
176
|
bos@584
|
177 <para id="x_1a">To introduce a little terminology, the <filename
|
bos@553
|
178 class="directory">.hg</filename> directory is the
|
bos@553
|
179 <quote>real</quote> repository, and all of the files and
|
bos@553
|
180 directories that coexist with it are said to live in the
|
bos@553
|
181 <emphasis>working directory</emphasis>. An easy way to
|
bos@553
|
182 remember the distinction is that the
|
bos@553
|
183 <emphasis>repository</emphasis> contains the
|
bos@553
|
184 <emphasis>history</emphasis> of your project, while the
|
bos@553
|
185 <emphasis>working directory</emphasis> contains a
|
bos@553
|
186 <emphasis>snapshot</emphasis> of your project at a particular
|
bos@553
|
187 point in history.</para>
|
bos@553
|
188
|
bos@553
|
189 </sect2>
|
bos@553
|
190 </sect1>
|
bos@553
|
191 <sect1>
|
bos@553
|
192 <title>A tour through history</title>
|
bos@553
|
193
|
bos@584
|
194 <para id="x_1b">One of the first things we might want to do with a new,
|
bos@553
|
195 unfamiliar repository is understand its history. The <command
|
bos@553
|
196 role="hg-cmd">hg log</command> command gives us a view of
|
bos@609
|
197 the history of changes in the repository.</para>
|
bos@559
|
198
|
bos@566
|
199 &interaction.tour.log;
|
bos@559
|
200
|
bos@584
|
201 <para id="x_1c">By default, this command prints a brief paragraph of output
|
bos@559
|
202 for each change to the project that was recorded. In Mercurial
|
bos@559
|
203 terminology, we call each of these recorded events a
|
bos@553
|
204 <emphasis>changeset</emphasis>, because it can contain a record
|
bos@553
|
205 of changes to several files.</para>
|
bos@553
|
206
|
bos@584
|
207 <para id="x_1d">The fields in a record of output from <command
|
bos@553
|
208 role="hg-cmd">hg log</command> are as follows.</para>
|
bos@609
|
209
|
bos@553
|
210 <itemizedlist>
|
bos@609
|
211 <listitem><para id="x_1e"><literal>changeset</literal>: This
|
bos@609
|
212 field has the format of a number, followed by a colon,
|
bos@609
|
213 followed by a hexadecimal (or <emphasis>hex</emphasis>)
|
bos@609
|
214 string. These are <emphasis>identifiers</emphasis> for the
|
bos@609
|
215 changeset. The hex string is a unique identifier: the same
|
bos@609
|
216 hex string will always refer to the same changeset. The
|
bos@609
|
217 number is shorter and easier to type than the hex string,
|
bos@609
|
218 but it isn't unique: the same number in two different clones
|
bos@609
|
219 of a repository may identify different changesets. Why
|
bos@609
|
220 provide the number at all, then? For local
|
bos@609
|
221 convenience.</para>
|
bos@609
|
222 </listitem>
|
bos@584
|
223 <listitem><para id="x_1f"><literal>user</literal>: The identity of the
|
bos@553
|
224 person who created the changeset. This is a free-form
|
bos@553
|
225 field, but it most often contains a person's name and email
|
bos@553
|
226 address.</para></listitem>
|
bos@584
|
227 <listitem><para id="x_20"><literal>date</literal>: The date and time on
|
bos@553
|
228 which the changeset was created, and the timezone in which
|
bos@553
|
229 it was created. (The date and time are local to that
|
bos@553
|
230 timezone; they display what time and date it was for the
|
bos@553
|
231 person who created the changeset.)</para></listitem>
|
bos@584
|
232 <listitem><para id="x_21"><literal>summary</literal>: The first line of
|
bos@553
|
233 the text message that the creator of the changeset entered
|
bos@609
|
234 to describe the changeset.</para></listitem>
|
bos@609
|
235 <listitem>
|
bos@609
|
236 <para>Some changesets, such as the first in the list above,
|
bos@609
|
237 have a <literal>tag</literal> field. A tag is another way
|
bos@609
|
238 to identify a changeset, by giving it an easy-to-remember
|
bos@609
|
239 name. (The tag named <literal>tip</literal> is special: it
|
bos@609
|
240 always refers to the newest change in a repository.)</para>
|
bos@609
|
241 </listitem>
|
bos@609
|
242 </itemizedlist>
|
bos@609
|
243
|
bos@609
|
244 <para id="x_22">The default output printed by <command
|
bos@609
|
245 role="hg-cmd">hg log</command> is purely a summary; it is
|
bos@609
|
246 missing a lot of detail.</para>
|
bos@553
|
247
|
bos@592
|
248 <para id="x_23"><xref linkend="fig:tour-basic:history"/> provides
|
bos@592
|
249 a graphical representation of the history of the <filename
|
bos@553
|
250 class="directory">hello</filename> repository, to make it a
|
bos@553
|
251 little easier to see which direction history is
|
bos@553
|
252 <quote>flowing</quote> in. We'll be returning to this figure
|
bos@553
|
253 several times in this chapter and the chapter that
|
bos@553
|
254 follows.</para>
|
bos@553
|
255
|
bos@591
|
256 <figure id="fig:tour-basic:history">
|
bos@591
|
257 <title>Graphical history of the <filename
|
bos@591
|
258 class="directory">hello</filename> repository</title>
|
bos@558
|
259 <mediaobject>
|
bos@594
|
260 <imageobject><imagedata fileref="figs/tour-history.png"/></imageobject>
|
bos@558
|
261 <textobject><phrase>XXX add text</phrase></textobject>
|
bos@558
|
262 </mediaobject>
|
bos@591
|
263 </figure>
|
bos@553
|
264
|
bos@553
|
265 <sect2>
|
bos@553
|
266 <title>Changesets, revisions, and talking to other
|
bos@553
|
267 people</title>
|
bos@553
|
268
|
bos@584
|
269 <para id="x_25">As English is a notoriously sloppy language, and computer
|
bos@553
|
270 science has a hallowed history of terminological confusion
|
bos@553
|
271 (why use one term when four will do?), revision control has a
|
bos@553
|
272 variety of words and phrases that mean the same thing. If you
|
bos@553
|
273 are talking about Mercurial history with other people, you
|
bos@553
|
274 will find that the word <quote>changeset</quote> is often
|
bos@553
|
275 compressed to <quote>change</quote> or (when written)
|
bos@553
|
276 <quote>cset</quote>, and sometimes a changeset is referred to
|
bos@553
|
277 as a <quote>revision</quote> or a <quote>rev</quote>.</para>
|
bos@553
|
278
|
bos@584
|
279 <para id="x_26">While it doesn't matter what <emphasis>word</emphasis> you
|
bos@553
|
280 use to refer to the concept of <quote>a changeset</quote>, the
|
bos@553
|
281 <emphasis>identifier</emphasis> that you use to refer to
|
bos@553
|
282 <quote>a <emphasis>specific</emphasis> changeset</quote> is of
|
bos@553
|
283 great importance. Recall that the <literal>changeset</literal>
|
bos@553
|
284 field in the output from <command role="hg-cmd">hg
|
bos@553
|
285 log</command> identifies a changeset using both a number and
|
bos@553
|
286 a hexadecimal string.</para>
|
bos@553
|
287 <itemizedlist>
|
bos@609
|
288 <listitem><para id="x_27">The revision number is a handy
|
bos@609
|
289 notation that is <emphasis>only valid in that
|
bos@609
|
290 repository</emphasis>.</para></listitem>
|
bos@609
|
291 <listitem><para id="x_28">The hexadecimal string is the
|
bos@553
|
292 <emphasis>permanent, unchanging identifier</emphasis> that
|
bos@553
|
293 will always identify that exact changeset in
|
bos@553
|
294 <emphasis>every</emphasis> copy of the
|
bos@553
|
295 repository.</para></listitem></itemizedlist>
|
bos@609
|
296
|
bos@609
|
297 <para id="x_29">This distinction is important. If you send
|
bos@609
|
298 someone an email talking about <quote>revision 33</quote>,
|
bos@609
|
299 there's a high likelihood that their revision 33 will
|
bos@609
|
300 <emphasis>not be the same</emphasis> as yours. The reason for
|
bos@609
|
301 this is that a revision number depends on the order in which
|
bos@609
|
302 changes arrived in a repository, and there is no guarantee
|
bos@609
|
303 that the same changes will happen in the same order in
|
bos@609
|
304 different repositories. Three changes <literal>a,b,c</literal>
|
bos@609
|
305 can easily appear in one repository as
|
bos@609
|
306 <literal>0,1,2</literal>, while in another as
|
bos@609
|
307 <literal>0,2,1</literal>.</para>
|
bos@553
|
308
|
bos@584
|
309 <para id="x_2a">Mercurial uses revision numbers purely as a convenient
|
bos@553
|
310 shorthand. If you need to discuss a changeset with someone,
|
bos@553
|
311 or make a record of a changeset for some other reason (for
|
bos@553
|
312 example, in a bug report), use the hexadecimal
|
bos@553
|
313 identifier.</para>
|
bos@553
|
314
|
bos@553
|
315 </sect2>
|
bos@553
|
316 <sect2>
|
bos@553
|
317 <title>Viewing specific revisions</title>
|
bos@553
|
318
|
bos@584
|
319 <para id="x_2b">To narrow the output of <command role="hg-cmd">hg
|
bos@553
|
320 log</command> down to a single revision, use the <option
|
bos@553
|
321 role="hg-opt-log">-r</option> (or <option
|
bos@553
|
322 role="hg-opt-log">--rev</option>) option. You can use
|
bos@609
|
323 either a revision number or a hexadecimal identifier,
|
bos@559
|
324 and you can provide as many revisions as you want.</para>
|
bos@559
|
325
|
bos@566
|
326 &interaction.tour.log-r;
|
bos@553
|
327
|
bos@584
|
328 <para id="x_2c">If you want to see the history of several revisions
|
bos@553
|
329 without having to list each one, you can use <emphasis>range
|
bos@553
|
330 notation</emphasis>; this lets you express the idea <quote>I
|
bos@559
|
331 want all revisions between <literal>abc</literal> and
|
bos@559
|
332 <literal>def</literal>, inclusive</quote>.</para>
|
bos@559
|
333
|
bos@566
|
334 &interaction.tour.log.range;
|
bos@559
|
335
|
bos@584
|
336 <para id="x_2d">Mercurial also honours the order in which you specify
|
bos@559
|
337 revisions, so <command role="hg-cmd">hg log -r 2:4</command>
|
bos@559
|
338 prints 2, 3, and 4. while <command role="hg-cmd">hg log -r
|
bos@559
|
339 4:2</command> prints 4, 3, and 2.</para>
|
bos@553
|
340
|
bos@553
|
341 </sect2>
|
bos@553
|
342 <sect2>
|
bos@553
|
343 <title>More detailed information</title>
|
bos@553
|
344
|
bos@584
|
345 <para id="x_2e">While the summary information printed by <command
|
bos@553
|
346 role="hg-cmd">hg log</command> is useful if you already know
|
bos@553
|
347 what you're looking for, you may need to see a complete
|
bos@553
|
348 description of the change, or a list of the files changed, if
|
bos@553
|
349 you're trying to decide whether a changeset is the one you're
|
bos@553
|
350 looking for. The <command role="hg-cmd">hg log</command>
|
bos@553
|
351 command's <option role="hg-opt-global">-v</option> (or <option
|
bos@553
|
352 role="hg-opt-global">--verbose</option>) option gives you
|
bos@559
|
353 this extra detail.</para>
|
bos@559
|
354
|
bos@566
|
355 &interaction.tour.log-v;
|
bos@553
|
356
|
bos@592
|
357 <para id="x_2f">If you want to see both the description and
|
bos@592
|
358 content of a change, add the <option
|
bos@592
|
359 role="hg-opt-log">-p</option> (or <option
|
bos@592
|
360 role="hg-opt-log">--patch</option>) option. This displays
|
bos@592
|
361 the content of a change as a <emphasis>unified diff</emphasis>
|
bos@592
|
362 (if you've never seen a unified diff before, see <xref
|
bos@592
|
363 linkend="sec:mq:patch"/> for an overview).</para>
|
bos@559
|
364
|
bos@566
|
365 &interaction.tour.log-vp;
|
bos@553
|
366
|
bos@609
|
367 <para>The <option role="hg-opt-log">-p</option> option is
|
bos@609
|
368 tremendously useful, so it's well worth remembering.</para>
|
bos@609
|
369
|
bos@553
|
370 </sect2>
|
bos@553
|
371 </sect1>
|
bos@609
|
372
|
bos@553
|
373 <sect1>
|
bos@553
|
374 <title>All about command options</title>
|
bos@553
|
375
|
bos@584
|
376 <para id="x_30">Let's take a brief break from exploring Mercurial commands
|
bos@553
|
377 to discuss a pattern in the way that they work; you may find
|
bos@553
|
378 this useful to keep in mind as we continue our tour.</para>
|
bos@553
|
379
|
bos@584
|
380 <para id="x_31">Mercurial has a consistent and straightforward approach to
|
bos@553
|
381 dealing with the options that you can pass to commands. It
|
bos@553
|
382 follows the conventions for options that are common to modern
|
bos@553
|
383 Linux and Unix systems.</para>
|
bos@609
|
384
|
bos@553
|
385 <itemizedlist>
|
bos@609
|
386 <listitem>
|
bos@609
|
387 <para id="x_32">Every option has a long name. For example, as
|
bos@553
|
388 we've already seen, the <command role="hg-cmd">hg
|
bos@553
|
389 log</command> command accepts a <option
|
bos@609
|
390 role="hg-opt-log">--rev</option> option.</para>
|
bos@609
|
391 </listitem>
|
bos@609
|
392 <listitem>
|
bos@609
|
393 <para id="x_33">Most options have short names, too. Instead
|
bos@609
|
394 of <option role="hg-opt-log">--rev</option>, we can use
|
bos@609
|
395 <option role="hg-opt-log">-r</option>. (The reason that
|
bos@609
|
396 some options don't have short names is that the options in
|
bos@609
|
397 question are rarely used.)</para>
|
bos@609
|
398 </listitem>
|
bos@609
|
399 <listitem>
|
bos@609
|
400 <para id="x_34">Long options start with two dashes (e.g.
|
bos@609
|
401 <option role="hg-opt-log">--rev</option>), while short
|
bos@609
|
402 options start with one (e.g. <option
|
bos@609
|
403 role="hg-opt-log">-r</option>).</para>
|
bos@609
|
404 </listitem>
|
bos@609
|
405 <listitem>
|
bos@609
|
406 <para id="x_35">Option naming and usage is consistent across
|
bos@553
|
407 commands. For example, every command that lets you specify
|
bos@553
|
408 a changeset ID or revision number accepts both <option
|
bos@553
|
409 role="hg-opt-log">-r</option> and <option
|
bos@609
|
410 role="hg-opt-log">--rev</option> arguments.</para>
|
bos@609
|
411 </listitem>
|
bos@609
|
412 <listitem>
|
bos@609
|
413 <para>If you are using short options, you can save typing by
|
bos@609
|
414 running them together. For example, the command <command
|
bos@609
|
415 role="hg-cmd">hg log -v -p -r 2</command> can be written
|
bos@609
|
416 as <command role="hg-cmd">hg log -vpr2</command>.</para>
|
bos@609
|
417 </listitem>
|
bos@609
|
418 </itemizedlist>
|
bos@609
|
419
|
bos@584
|
420 <para id="x_36">In the examples throughout this book, I use short options
|
bos@553
|
421 instead of long. This just reflects my own preference, so don't
|
bos@553
|
422 read anything significant into it.</para>
|
bos@553
|
423
|
bos@584
|
424 <para id="x_37">Most commands that print output of some kind will print more
|
bos@553
|
425 output when passed a <option role="hg-opt-global">-v</option>
|
bos@553
|
426 (or <option role="hg-opt-global">--verbose</option>) option, and
|
bos@553
|
427 less when passed <option role="hg-opt-global">-q</option> (or
|
bos@553
|
428 <option role="hg-opt-global">--quiet</option>).</para>
|
bos@553
|
429
|
bos@609
|
430 <note>
|
bos@609
|
431 <title>Option naming consistency</title>
|
bos@609
|
432
|
bos@609
|
433 <para>Almost always, Mercurial commands use consistent option
|
bos@609
|
434 names to refer to the same concepts. For instance, if a
|
bos@609
|
435 command deals with changesets, you'll always identify them
|
bos@609
|
436 with <option role="hg-opt-log">--rev</option> or <option
|
bos@609
|
437 role="hg-opt-log">-r</option>. This consistent use of
|
bos@609
|
438 option names makes it easier to remember what options a
|
bos@609
|
439 particular command takes.</para>
|
bos@609
|
440 </note>
|
bos@609
|
441
|
bos@553
|
442 </sect1>
|
bos@553
|
443 <sect1>
|
bos@553
|
444 <title>Making and reviewing changes</title>
|
bos@553
|
445
|
bos@584
|
446 <para id="x_38">Now that we have a grasp of viewing history in Mercurial,
|
bos@553
|
447 let's take a look at making some changes and examining
|
bos@553
|
448 them.</para>
|
bos@553
|
449
|
bos@584
|
450 <para id="x_39">The first thing we'll do is isolate our experiment in a
|
bos@553
|
451 repository of its own. We use the <command role="hg-cmd">hg
|
bos@553
|
452 clone</command> command, but we don't need to clone a copy of
|
bos@553
|
453 the remote repository. Since we already have a copy of it
|
bos@553
|
454 locally, we can just clone that instead. This is much faster
|
bos@553
|
455 than cloning over the network, and cloning a local repository
|
bos@609
|
456 uses less disk space in most cases, too<footnote>
|
bos@609
|
457 <para>The saving of space arises when source and destination
|
bos@609
|
458 repositories are on the same filesystem, in which case
|
bos@609
|
459 Mercurial will use hardlinks to do copy-on-write sharing of
|
bos@609
|
460 its internal metadata. If that explanation meant nothing to
|
bos@609
|
461 you, don't worry: everything happens transparently and
|
bos@609
|
462 automatically, and you don't need to understand it.</para>
|
bos@609
|
463 </footnote>.</para>
|
bos@559
|
464
|
bos@566
|
465 &interaction.tour.reclone;
|
bos@559
|
466
|
bos@584
|
467 <para id="x_3a">As an aside, it's often good practice to keep a
|
bos@559
|
468 <quote>pristine</quote> copy of a remote repository around,
|
bos@559
|
469 which you can then make temporary clones of to create sandboxes
|
bos@559
|
470 for each task you want to work on. This lets you work on
|
bos@559
|
471 multiple tasks in parallel, each isolated from the others until
|
bos@559
|
472 it's complete and you're ready to integrate it back. Because
|
bos@559
|
473 local clones are so cheap, there's almost no overhead to cloning
|
bos@559
|
474 and destroying repositories whenever you want.</para>
|
bos@553
|
475
|
bos@584
|
476 <para id="x_3b">In our <filename class="directory">my-hello</filename>
|
bos@553
|
477 repository, we have a file <filename>hello.c</filename> that
|
bos@609
|
478 contains the classic <quote>hello, world</quote> program.</para>
|
bos@609
|
479
|
bos@609
|
480 &interaction.tour.cat1;
|
bos@609
|
481
|
bos@609
|
482 <para>Let's edit this file so that it prints a second line of
|
bos@609
|
483 output.</para>
|
bos@609
|
484
|
bos@609
|
485 &interaction.tour.cat2;
|
bos@553
|
486
|
bos@584
|
487 <para id="x_3c">Mercurial's <command role="hg-cmd">hg status</command>
|
bos@553
|
488 command will tell us what Mercurial knows about the files in the
|
bos@559
|
489 repository.</para>
|
bos@559
|
490
|
bos@566
|
491 &interaction.tour.status;
|
bos@559
|
492
|
bos@584
|
493 <para id="x_3d">The <command role="hg-cmd">hg status</command> command
|
bos@559
|
494 prints no output for some files, but a line starting with
|
bos@553
|
495 <quote><literal>M</literal></quote> for
|
bos@553
|
496 <filename>hello.c</filename>. Unless you tell it to, <command
|
bos@553
|
497 role="hg-cmd">hg status</command> will not print any output
|
bos@553
|
498 for files that have not been modified.</para>
|
bos@553
|
499
|
bos@584
|
500 <para id="x_3e">The <quote><literal>M</literal></quote> indicates that
|
bos@553
|
501 Mercurial has noticed that we modified
|
bos@553
|
502 <filename>hello.c</filename>. We didn't need to
|
bos@553
|
503 <emphasis>inform</emphasis> Mercurial that we were going to
|
bos@553
|
504 modify the file before we started, or that we had modified the
|
bos@553
|
505 file after we were done; it was able to figure this out
|
bos@553
|
506 itself.</para>
|
bos@553
|
507
|
bos@609
|
508 <para id="x_3f">It's somewhat helpful to know that we've modified
|
bos@553
|
509 <filename>hello.c</filename>, but we might prefer to know
|
bos@553
|
510 exactly <emphasis>what</emphasis> changes we've made to it. To
|
bos@553
|
511 do this, we use the <command role="hg-cmd">hg diff</command>
|
bos@559
|
512 command.</para>
|
bos@559
|
513
|
bos@566
|
514 &interaction.tour.diff;
|
bos@553
|
515
|
bos@609
|
516 <tip>
|
bos@609
|
517 <title>Understanding patches</title>
|
bos@609
|
518
|
bos@609
|
519 <para>Remember to take a look at <xref
|
bos@609
|
520 linkend="sec:mq:patch"/> if you don't know how to read
|
bos@609
|
521 output above.</para>
|
bos@609
|
522 </tip>
|
bos@553
|
523 </sect1>
|
bos@553
|
524 <sect1>
|
bos@553
|
525 <title>Recording changes in a new changeset</title>
|
bos@553
|
526
|
bos@584
|
527 <para id="x_40">We can modify files, build and test our changes, and use
|
bos@553
|
528 <command role="hg-cmd">hg status</command> and <command
|
bos@553
|
529 role="hg-cmd">hg diff</command> to review our changes, until
|
bos@553
|
530 we're satisfied with what we've done and arrive at a natural
|
bos@553
|
531 stopping point where we want to record our work in a new
|
bos@553
|
532 changeset.</para>
|
bos@553
|
533
|
bos@584
|
534 <para id="x_41">The <command role="hg-cmd">hg commit</command> command lets
|
bos@553
|
535 us create a new changeset; we'll usually refer to this as
|
bos@553
|
536 <quote>making a commit</quote> or
|
bos@553
|
537 <quote>committing</quote>.</para>
|
bos@553
|
538
|
bos@553
|
539 <sect2>
|
bos@553
|
540 <title>Setting up a username</title>
|
bos@553
|
541
|
bos@584
|
542 <para id="x_42">When you try to run <command role="hg-cmd">hg
|
bos@553
|
543 commit</command> for the first time, it is not guaranteed to
|
bos@553
|
544 succeed. Mercurial records your name and address with each
|
bos@553
|
545 change that you commit, so that you and others will later be
|
bos@553
|
546 able to tell who made each change. Mercurial tries to
|
bos@553
|
547 automatically figure out a sensible username to commit the
|
bos@553
|
548 change with. It will attempt each of the following methods,
|
bos@553
|
549 in order:</para>
|
bos@553
|
550 <orderedlist>
|
bos@584
|
551 <listitem><para id="x_43">If you specify a <option
|
bos@553
|
552 role="hg-opt-commit">-u</option> option to the <command
|
bos@553
|
553 role="hg-cmd">hg commit</command> command on the command
|
bos@553
|
554 line, followed by a username, this is always given the
|
bos@553
|
555 highest precedence.</para></listitem>
|
bos@584
|
556 <listitem><para id="x_44">If you have set the <envar>HGUSER</envar>
|
bos@553
|
557 environment variable, this is checked
|
bos@553
|
558 next.</para></listitem>
|
bos@592
|
559 <listitem><para id="x_45">If you create a file in your home
|
bos@592
|
560 directory called <filename
|
bos@592
|
561 role="special">.hgrc</filename>, with a <envar
|
bos@592
|
562 role="rc-item-ui">username</envar> entry, that will be
|
bos@592
|
563 used next. To see what the contents of this file should
|
bos@592
|
564 look like, refer to <xref
|
bos@558
|
565 linkend="sec:tour-basic:username"/>
|
bos@553
|
566 below.</para></listitem>
|
bos@584
|
567 <listitem><para id="x_46">If you have set the <envar>EMAIL</envar>
|
bos@553
|
568 environment variable, this will be used
|
bos@553
|
569 next.</para></listitem>
|
bos@584
|
570 <listitem><para id="x_47">Mercurial will query your system to find out
|
bos@553
|
571 your local user name and host name, and construct a
|
bos@553
|
572 username from these components. Since this often results
|
bos@553
|
573 in a username that is not very useful, it will print a
|
bos@553
|
574 warning if it has to do
|
bos@558
|
575 this.</para></listitem>
|
bos@558
|
576 </orderedlist>
|
bos@584
|
577 <para id="x_48">If all of these mechanisms fail, Mercurial will
|
bos@553
|
578 fail, printing an error message. In this case, it will not
|
bos@553
|
579 let you commit until you set up a
|
bos@558
|
580 username.</para>
|
bos@584
|
581 <para id="x_49">You should think of the <envar>HGUSER</envar> environment
|
bos@558
|
582 variable and the <option role="hg-opt-commit">-u</option>
|
bos@558
|
583 option to the <command role="hg-cmd">hg commit</command>
|
bos@558
|
584 command as ways to <emphasis>override</emphasis> Mercurial's
|
bos@558
|
585 default selection of username. For normal use, the simplest
|
bos@558
|
586 and most robust way to set a username for yourself is by
|
bos@558
|
587 creating a <filename role="special">.hgrc</filename> file; see
|
bos@558
|
588 below for details.</para>
|
bos@558
|
589 <sect3 id="sec:tour-basic:username">
|
bos@553
|
590 <title>Creating a Mercurial configuration file</title>
|
bos@558
|
591
|
bos@674
|
592 <para id="x_4a">To set a user name, use your favorite editor
|
bos@553
|
593 to create a file called <filename
|
bos@553
|
594 role="special">.hgrc</filename> in your home directory.
|
bos@553
|
595 Mercurial will use this file to look up your personalised
|
bos@553
|
596 configuration settings. The initial contents of your
|
bos@553
|
597 <filename role="special">.hgrc</filename> should look like
|
bos@558
|
598 this.</para>
|
bos@609
|
599
|
bos@609
|
600 <remark>Figure out what the appropriate directory is on
|
bos@609
|
601 Windows.</remark>
|
bos@609
|
602
|
bos@558
|
603 <programlisting># This is a Mercurial configuration file.
|
bos@579
|
604 [ui]
|
bos@609
|
605 username = Firstname Lastname <email.address@domain.net></programlisting>
|
bos@558
|
606
|
bos@584
|
607 <para id="x_4b">The <quote><literal>[ui]</literal></quote> line begins a
|
bos@558
|
608 <emphasis>section</emphasis> of the config file, so you can
|
bos@558
|
609 read the <quote><literal>username = ...</literal></quote>
|
bos@558
|
610 line as meaning <quote>set the value of the
|
bos@558
|
611 <literal>username</literal> item in the
|
bos@558
|
612 <literal>ui</literal> section</quote>. A section continues
|
bos@558
|
613 until a new section begins, or the end of the file.
|
bos@558
|
614 Mercurial ignores empty lines and treats any text from
|
bos@558
|
615 <quote><literal>#</literal></quote> to the end of a line as
|
bos@558
|
616 a comment.</para>
|
bos@553
|
617 </sect3>
|
bos@558
|
618
|
bos@553
|
619 <sect3>
|
bos@553
|
620 <title>Choosing a user name</title>
|
bos@553
|
621
|
bos@584
|
622 <para id="x_4c">You can use any text you like as the value of
|
bos@553
|
623 the <literal>username</literal> config item, since this
|
bos@609
|
624 information is for reading by other people, but will not be
|
bos@609
|
625 interpreted by Mercurial. The convention that most
|
bos@553
|
626 people follow is to use their name and email address, as
|
bos@558
|
627 in the example above.</para>
|
bos@553
|
628 <note>
|
bos@584
|
629 <para id="x_4d">Mercurial's built-in web server obfuscates
|
bos@553
|
630 email addresses, to make it more difficult for the email
|
bos@553
|
631 harvesting tools that spammers use. This reduces the
|
bos@553
|
632 likelihood that you'll start receiving more junk email
|
bos@553
|
633 if you publish a Mercurial repository on the
|
bos@558
|
634 web.</para></note>
|
bos@553
|
635
|
bos@553
|
636 </sect3>
|
bos@553
|
637 </sect2>
|
bos@553
|
638 <sect2>
|
bos@553
|
639 <title>Writing a commit message</title>
|
bos@553
|
640
|
bos@584
|
641 <para id="x_4e">When we commit a change, Mercurial drops us into
|
bos@553
|
642 a text editor, to enter a message that will describe the
|
bos@553
|
643 modifications we've made in this changeset. This is called
|
bos@553
|
644 the <emphasis>commit message</emphasis>. It will be a
|
bos@553
|
645 record for readers of what we did and why, and it will be
|
bos@553
|
646 printed by <command role="hg-cmd">hg log</command> after
|
bos@558
|
647 we've finished committing.</para>
|
bos@558
|
648
|
bos@566
|
649 &interaction.tour.commit;
|
bos@558
|
650
|
bos@584
|
651 <para id="x_4f">The editor that the <command role="hg-cmd">hg
|
bos@553
|
652 commit</command> command drops us into will contain an
|
bos@609
|
653 empty line or two, followed by a number of lines starting with
|
bos@558
|
654 <quote><literal>HG:</literal></quote>.</para>
|
bos@558
|
655
|
bos@609
|
656 <programlisting>
|
bos@609
|
657 This is where I type my commit comment.
|
bos@609
|
658
|
bos@609
|
659 HG: Enter commit message. Lines beginning with 'HG:' are removed.
|
bos@609
|
660 HG: --
|
bos@609
|
661 HG: user: Bryan O'Sullivan <bos@serpentine.com>
|
bos@609
|
662 HG: branch 'default'
|
bos@609
|
663 HG: changed hello.c</programlisting>
|
bos@558
|
664
|
bos@584
|
665 <para id="x_50">Mercurial ignores the lines that start with
|
bos@553
|
666 <quote><literal>HG:</literal></quote>; it uses them only to
|
bos@553
|
667 tell us which files it's recording changes to. Modifying or
|
bos@558
|
668 deleting these lines has no effect.</para>
|
bos@553
|
669 </sect2>
|
bos@553
|
670 <sect2>
|
bos@553
|
671 <title>Writing a good commit message</title>
|
bos@553
|
672
|
bos@584
|
673 <para id="x_51">Since <command role="hg-cmd">hg log</command>
|
bos@553
|
674 only prints the first line of a commit message by default,
|
bos@553
|
675 it's best to write a commit message whose first line stands
|
bos@553
|
676 alone. Here's a real example of a commit message that
|
bos@553
|
677 <emphasis>doesn't</emphasis> follow this guideline, and
|
bos@553
|
678 hence has a summary that is not
|
bos@558
|
679 readable.</para>
|
bos@558
|
680
|
bos@558
|
681 <programlisting>
|
bos@558
|
682 changeset: 73:584af0e231be
|
bos@579
|
683 user: Censored Person <censored.person@example.org>
|
bos@579
|
684 date: Tue Sep 26 21:37:07 2006 -0700
|
bos@558
|
685 summary: include buildmeister/commondefs. Add exports.</programlisting>
|
bos@558
|
686
|
bos@584
|
687 <para id="x_52">As far as the remainder of the contents of the
|
bos@553
|
688 commit message are concerned, there are no hard-and-fast
|
bos@553
|
689 rules. Mercurial itself doesn't interpret or care about the
|
bos@553
|
690 contents of the commit message, though your project may have
|
bos@553
|
691 policies that dictate a certain kind of
|
bos@558
|
692 formatting.</para>
|
bos@584
|
693 <para id="x_53">My personal preference is for short, but
|
bos@553
|
694 informative, commit messages that tell me something that I
|
bos@553
|
695 can't figure out with a quick glance at the output of
|
bos@553
|
696 <command role="hg-cmd">hg log
|
bos@558
|
697 --patch</command>.</para>
|
bos@553
|
698 </sect2>
|
bos@553
|
699 <sect2>
|
bos@553
|
700 <title>Aborting a commit</title>
|
bos@553
|
701
|
bos@584
|
702 <para id="x_54">If you decide that you don't want to commit
|
bos@553
|
703 while in the middle of editing a commit message, simply exit
|
bos@553
|
704 from your editor without saving the file that it's editing.
|
bos@553
|
705 This will cause nothing to happen to either the repository
|
bos@558
|
706 or the working directory.</para>
|
bos@584
|
707 <para id="x_55">If we run the <command role="hg-cmd">hg
|
bos@553
|
708 commit</command> command without any arguments, it records
|
bos@553
|
709 all of the changes we've made, as reported by <command
|
bos@553
|
710 role="hg-cmd">hg status</command> and <command
|
bos@558
|
711 role="hg-cmd">hg diff</command>.</para>
|
bos@553
|
712 </sect2>
|
bos@553
|
713 <sect2>
|
bos@553
|
714 <title>Admiring our new handiwork</title>
|
bos@553
|
715
|
bos@584
|
716 <para id="x_56">Once we've finished the commit, we can use the
|
bos@553
|
717 <command role="hg-cmd">hg tip</command> command to display
|
bos@553
|
718 the changeset we just created. This command produces output
|
bos@553
|
719 that is identical to <command role="hg-cmd">hg
|
bos@553
|
720 log</command>, but it only displays the newest revision in
|
bos@558
|
721 the repository.</para>
|
bos@558
|
722
|
bos@566
|
723 &interaction.tour.tip;
|
bos@558
|
724
|
bos@609
|
725 <para id="x_57">We refer to the newest revision in the
|
bos@609
|
726 repository as the <emphasis>tip revision</emphasis>, or simply
|
bos@609
|
727 the <emphasis>tip</emphasis>.</para>
|
bos@609
|
728
|
bos@609
|
729 <para>By the way, the <command role="hg-cmd">hg tip</command>
|
bos@609
|
730 command accepts many of the same options as <command
|
bos@609
|
731 role="hg-cmd">hg log</command>, so <option
|
bos@609
|
732 role="hg-opt-global">-v</option> above indicates <quote>be
|
bos@609
|
733 verbose</quote>, <option role="hg-opt-tip">-p</option>
|
bos@609
|
734 specifies <quote>print a patch</quote>. The use of <option
|
bos@609
|
735 role="hg-opt-tip">-p</option> to print patches is another
|
bos@609
|
736 example of the consistent naming we mentioned earlier.</para>
|
bos@553
|
737 </sect2>
|
bos@553
|
738 </sect1>
|
bos@558
|
739
|
bos@553
|
740 <sect1>
|
bos@553
|
741 <title>Sharing changes</title>
|
bos@553
|
742
|
bos@584
|
743 <para id="x_58">We mentioned earlier that repositories in
|
bos@553
|
744 Mercurial are self-contained. This means that the changeset
|
bos@553
|
745 we just created exists only in our <filename
|
bos@553
|
746 class="directory">my-hello</filename> repository. Let's
|
bos@553
|
747 look at a few ways that we can propagate this change into
|
bos@558
|
748 other repositories.</para>
|
bos@558
|
749
|
bos@558
|
750 <sect2 id="sec:tour:pull">
|
bos@553
|
751 <title>Pulling changes from another repository</title>
|
bos@584
|
752 <para id="x_59">To get started, let's clone our original
|
bos@553
|
753 <filename class="directory">hello</filename> repository,
|
bos@553
|
754 which does not contain the change we just committed. We'll
|
bos@553
|
755 call our temporary repository <filename
|
bos@558
|
756 class="directory">hello-pull</filename>.</para>
|
bos@558
|
757
|
bos@566
|
758 &interaction.tour.clone-pull;
|
bos@558
|
759
|
bos@584
|
760 <para id="x_5a">We'll use the <command role="hg-cmd">hg
|
bos@553
|
761 pull</command> command to bring changes from <filename
|
bos@553
|
762 class="directory">my-hello</filename> into <filename
|
bos@553
|
763 class="directory">hello-pull</filename>. However, blindly
|
bos@553
|
764 pulling unknown changes into a repository is a somewhat
|
bos@553
|
765 scary prospect. Mercurial provides the <command
|
bos@553
|
766 role="hg-cmd">hg incoming</command> command to tell us
|
bos@553
|
767 what changes the <command role="hg-cmd">hg pull</command>
|
bos@553
|
768 command <emphasis>would</emphasis> pull into the repository,
|
bos@558
|
769 without actually pulling the changes in.</para>
|
bos@558
|
770
|
bos@566
|
771 &interaction.tour.incoming;
|
bos@558
|
772
|
bos@609
|
773 <para id="x_5b">Suppose you're pulling changes from a repository
|
bos@609
|
774 on the network somewhere. While you are looking at the <command
|
bos@609
|
775 role="hg-cmd">hg incoming</command> output, and before you
|
bos@609
|
776 pull those changes, someone might have committed something in
|
bos@609
|
777 the remote repository. This means that it's possible to pull
|
bos@609
|
778 more changes than you saw when using <command
|
bos@609
|
779 role="hg-cmd">hg incoming</command>.</para>
|
bos@558
|
780
|
bos@584
|
781 <para id="x_5c">Bringing changes into a repository is a simple
|
bos@553
|
782 matter of running the <command role="hg-cmd">hg
|
bos@553
|
783 pull</command> command, and telling it which repository to
|
bos@558
|
784 pull from.</para>
|
bos@558
|
785
|
bos@566
|
786 &interaction.tour.pull;
|
bos@558
|
787
|
bos@584
|
788 <para id="x_5d">As you can see
|
bos@553
|
789 from the before-and-after output of <command
|
bos@553
|
790 role="hg-cmd">hg tip</command>, we have successfully
|
bos@553
|
791 pulled changes into our repository. There remains one step
|
bos@553
|
792 before we can see these changes in the working
|
bos@558
|
793 directory.</para>
|
bos@553
|
794 </sect2>
|
bos@553
|
795 <sect2>
|
bos@553
|
796 <title>Updating the working directory</title>
|
bos@553
|
797
|
bos@592
|
798 <para id="x_5e">We have so far glossed over the relationship
|
bos@592
|
799 between a repository and its working directory. The <command
|
bos@559
|
800 role="hg-cmd">hg pull</command> command that we ran in
|
bos@592
|
801 <xref linkend="sec:tour:pull"/> brought changes into the
|
bos@592
|
802 repository, but if we check, there's no sign of those changes
|
bos@592
|
803 in the working directory. This is because <command
|
bos@559
|
804 role="hg-cmd">hg pull</command> does not (by default) touch
|
bos@559
|
805 the working directory. Instead, we use the <command
|
bos@559
|
806 role="hg-cmd">hg update</command> command to do this.</para>
|
bos@559
|
807
|
bos@566
|
808 &interaction.tour.update;
|
bos@559
|
809
|
bos@584
|
810 <para id="x_5f">It might seem a bit strange that <command role="hg-cmd">hg
|
bos@559
|
811 pull</command> doesn't update the working directory
|
bos@559
|
812 automatically. There's actually a good reason for this: you
|
bos@559
|
813 can use <command role="hg-cmd">hg update</command> to update
|
bos@559
|
814 the working directory to the state it was in at <emphasis>any
|
bos@559
|
815 revision</emphasis> in the history of the repository. If
|
bos@609
|
816 you had the working directory updated to an old revision&emdash;to
|
bos@609
|
817 hunt down the origin of a bug, say&emdash;and ran a <command
|
bos@559
|
818 role="hg-cmd">hg pull</command> which automatically updated
|
bos@559
|
819 the working directory to a new revision, you might not be
|
bos@559
|
820 terribly happy.</para>
|
bos@584
|
821 <para id="x_60">However, since pull-then-update is such a common thing to
|
bos@559
|
822 do, Mercurial lets you combine the two by passing the <option
|
bos@559
|
823 role="hg-opt-pull">-u</option> option to <command
|
bos@559
|
824 role="hg-cmd">hg pull</command>.</para>
|
bos@558
|
825
|
bos@584
|
826 <para id="x_61">If you look back at the output of <command
|
bos@592
|
827 role="hg-cmd">hg pull</command> in <xref
|
bos@558
|
828 linkend="sec:tour:pull"/> when we ran it without <option
|
bos@559
|
829 role="hg-opt-pull">-u</option>, you can see that it printed
|
bos@559
|
830 a helpful reminder that we'd have to take an explicit step to
|
bos@559
|
831 update the working directory:</para>
|
bos@558
|
832
|
bos@558
|
833 <!-- &interaction.xxx.fixme; -->
|
bos@558
|
834
|
bos@584
|
835 <para id="x_62">To find out what revision the working directory is at, use
|
bos@559
|
836 the <command role="hg-cmd">hg parents</command>
|
bos@559
|
837 command.</para>
|
bos@558
|
838
|
bos@566
|
839 &interaction.tour.parents;
|
bos@558
|
840
|
bos@592
|
841 <para id="x_63">If you look back at <xref
|
bos@559
|
842 linkend="fig:tour-basic:history"/>,
|
bos@559
|
843 you'll see arrows connecting each changeset. The node that
|
bos@559
|
844 the arrow leads <emphasis>from</emphasis> in each case is a
|
bos@559
|
845 parent, and the node that the arrow leads
|
bos@559
|
846 <emphasis>to</emphasis> is its child. The working directory
|
bos@559
|
847 has a parent in just the same way; this is the changeset that
|
bos@559
|
848 the working directory currently contains.</para>
|
bos@559
|
849
|
bos@584
|
850 <para id="x_64">To update the working directory to a particular revision,
|
bos@559
|
851
|
bos@559
|
852 give a revision number or changeset ID to the <command
|
bos@559
|
853 role="hg-cmd">hg update</command> command.</para>
|
bos@559
|
854
|
bos@566
|
855 &interaction.tour.older;
|
bos@559
|
856
|
bos@584
|
857 <para id="x_65">If you omit an explicit revision, <command
|
bos@559
|
858 role="hg-cmd">hg update</command> will update to the tip
|
bos@559
|
859 revision, as shown by the second call to <command
|
bos@559
|
860 role="hg-cmd">hg update</command> in the example
|
bos@559
|
861 above.</para>
|
bos@558
|
862 </sect2>
|
bos@558
|
863
|
bos@553
|
864 <sect2>
|
bos@553
|
865 <title>Pushing changes to another repository</title>
|
bos@553
|
866
|
bos@584
|
867 <para id="x_66">Mercurial lets us push changes to another
|
bos@553
|
868 repository, from the repository we're currently visiting.
|
bos@553
|
869 As with the example of <command role="hg-cmd">hg
|
bos@553
|
870 pull</command> above, we'll create a temporary repository
|
bos@558
|
871 to push our changes into.</para>
|
bos@558
|
872
|
bos@566
|
873 &interaction.tour.clone-push;
|
bos@558
|
874
|
bos@584
|
875 <para id="x_67">The <command role="hg-cmd">hg outgoing</command> command
|
bos@553
|
876 tells us what changes would be pushed into another
|
bos@558
|
877 repository.</para>
|
bos@558
|
878
|
bos@566
|
879 &interaction.tour.outgoing;
|
bos@558
|
880
|
bos@584
|
881 <para id="x_68">And the
|
bos@553
|
882 <command role="hg-cmd">hg push</command> command does the
|
bos@558
|
883 actual push.</para>
|
bos@558
|
884
|
bos@566
|
885 &interaction.tour.push;
|
bos@558
|
886
|
bos@609
|
887 <para id="x_69">As with <command role="hg-cmd">hg
|
bos@609
|
888 pull</command>, the <command role="hg-cmd">hg push</command>
|
bos@609
|
889 command does not update the working directory in the
|
bos@609
|
890 repository that it's pushing changes into. Unlike <command
|
bos@609
|
891 role="hg-cmd">hg pull</command>, <command role="hg-cmd">hg
|
bos@609
|
892 push</command> does not provide a <literal>-u</literal>
|
bos@609
|
893 option that updates the other repository's working directory.
|
bos@609
|
894 This asymmetry is deliberate: the repository we're pushing to
|
bos@609
|
895 might be on a remote server and shared between several people.
|
bos@609
|
896 If we were to update its working directory while someone was
|
bos@609
|
897 working in it, their work would be disrupted.</para>
|
bos@558
|
898
|
bos@584
|
899 <para id="x_6a">What happens if we try to pull or push changes
|
bos@553
|
900 and the receiving repository already has those changes?
|
bos@558
|
901 Nothing too exciting.</para>
|
bos@558
|
902
|
bos@566
|
903 &interaction.tour.push.nothing;
|
bos@553
|
904 </sect2>
|
bos@553
|
905 <sect2>
|
bos@553
|
906 <title>Sharing changes over a network</title>
|
bos@553
|
907
|
bos@584
|
908 <para id="x_6b">The commands we have covered in the previous few
|
bos@553
|
909 sections are not limited to working with local repositories.
|
bos@553
|
910 Each works in exactly the same fashion over a network
|
bos@558
|
911 connection; simply pass in a URL instead of a local
|
bos@558
|
912 path.</para>
|
bos@558
|
913
|
bos@566
|
914 &interaction.tour.outgoing.net;
|
bos@558
|
915
|
bos@584
|
916 <para id="x_6c">In this example, we
|
bos@553
|
917 can see what changes we could push to the remote repository,
|
bos@553
|
918 but the repository is understandably not set up to let
|
bos@558
|
919 anonymous users push to it.</para>
|
bos@558
|
920
|
bos@566
|
921 &interaction.tour.push.net;
|
bos@553
|
922 </sect2>
|
bos@553
|
923 </sect1>
|
bos@553
|
924 </chapter>
|
bos@553
|
925
|
bos@553
|
926 <!--
|
bos@553
|
927 local variables:
|
bos@553
|
928 sgml-parent-document: ("00book.xml" "book" "chapter")
|
bos@553
|
929 end:
|
bos@553
|
930 -->
|