| rev |
line source |
|
bos@559
|
1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
|
|
bos@559
|
2
|
|
bos@559
|
3 <chapter id="chap:undo">
|
|
bos@559
|
4 <title>Finding and fixing your mistakes</title>
|
|
bos@559
|
5
|
|
bos@559
|
6 <para>To err might be human, but to really handle the consequences
|
|
bos@559
|
7 well takes a top-notch revision control system. In this chapter,
|
|
bos@559
|
8 we'll discuss some of the techniques you can use when you find
|
|
bos@559
|
9 that a problem has crept into your project. Mercurial has some
|
|
bos@559
|
10 highly capable features that will help you to isolate the sources
|
|
bos@559
|
11 of problems, and to handle them appropriately.</para>
|
|
bos@559
|
12
|
|
bos@559
|
13 <sect1>
|
|
bos@559
|
14 <title>Erasing local history</title>
|
|
bos@559
|
15
|
|
bos@559
|
16 <sect2>
|
|
bos@559
|
17 <title>The accidental commit</title>
|
|
bos@559
|
18
|
|
bos@559
|
19 <para>I have the occasional but persistent problem of typing
|
|
bos@559
|
20 rather more quickly than I can think, which sometimes results
|
|
bos@559
|
21 in me committing a changeset that is either incomplete or
|
|
bos@559
|
22 plain wrong. In my case, the usual kind of incomplete
|
|
bos@559
|
23 changeset is one in which I've created a new source file, but
|
|
bos@559
|
24 forgotten to <command role="hg-cmd">hg add</command> it. A
|
|
bos@559
|
25 <quote>plain wrong</quote> changeset is not as common, but no
|
|
bos@559
|
26 less annoying.</para>
|
|
bos@559
|
27
|
|
bos@559
|
28 </sect2>
|
|
bos@559
|
29 <sect2 id="sec:undo:rollback">
|
|
bos@559
|
30 <title>Rolling back a transaction</title>
|
|
bos@559
|
31
|
|
bos@559
|
32 <para>In section <xref linkend="sec:concepts:txn"/>, I mentioned
|
|
bos@559
|
33 that Mercurial treats each modification of a repository as a
|
|
bos@559
|
34 <emphasis>transaction</emphasis>. Every time you commit a
|
|
bos@559
|
35 changeset or pull changes from another repository, Mercurial
|
|
bos@559
|
36 remembers what you did. You can undo, or <emphasis>roll
|
|
bos@559
|
37 back</emphasis>, exactly one of these actions using the
|
|
bos@559
|
38 <command role="hg-cmd">hg rollback</command> command. (See
|
|
bos@559
|
39 section <xref linkend="sec:undo:rollback-after-push"/> for an
|
|
bos@559
|
40 important caveat about the use of this command.)</para>
|
|
bos@559
|
41
|
|
bos@559
|
42 <para>Here's a mistake that I often find myself making:
|
|
bos@559
|
43 committing a change in which I've created a new file, but
|
|
bos@559
|
44 forgotten to <command role="hg-cmd">hg add</command> it. <!--
|
|
bos@559
|
45 &interaction.rollback.commit; --> Looking at the output of
|
|
bos@559
|
46 <command role="hg-cmd">hg status</command> after the commit
|
|
bos@559
|
47 immediately confirms the error. <!--
|
|
bos@559
|
48 &interaction.rollback.status; --> The commit captured the
|
|
bos@559
|
49 changes to the file <filename>a</filename>, but not the new
|
|
bos@559
|
50 file <filename>b</filename>. If I were to push this changeset
|
|
bos@559
|
51 to a repository that I shared with a colleague, the chances
|
|
bos@559
|
52 are high that something in <filename>a</filename> would refer
|
|
bos@559
|
53 to <filename>b</filename>, which would not be present in their
|
|
bos@559
|
54 repository when they pulled my changes. I would thus become
|
|
bos@559
|
55 the object of some indignation.</para>
|
|
bos@559
|
56
|
|
bos@559
|
57 <para>However, luck is with me&emdash;I've caught my error
|
|
bos@559
|
58 before I pushed the changeset. I use the <command
|
|
bos@559
|
59 role="hg-cmd">hg rollback</command> command, and Mercurial
|
|
bos@559
|
60 makes that last changeset vanish. <!--
|
|
bos@559
|
61 &interaction.rollback.rollback; --> Notice that the changeset
|
|
bos@559
|
62 is no longer present in the repository's history, and the
|
|
bos@559
|
63 working directory once again thinks that the file
|
|
bos@559
|
64 <filename>a</filename> is modified. The commit and rollback
|
|
bos@559
|
65 have left the working directory exactly as it was prior to the
|
|
bos@559
|
66 commit; the changeset has been completely erased. I can now
|
|
bos@559
|
67 safely <command role="hg-cmd">hg add</command> the file
|
|
bos@559
|
68 <filename>b</filename>, and rerun my commit. <!--
|
|
bos@559
|
69 &interaction.rollback.add; --></para>
|
|
bos@559
|
70
|
|
bos@559
|
71 </sect2>
|
|
bos@559
|
72 <sect2>
|
|
bos@559
|
73 <title>The erroneous pull</title>
|
|
bos@559
|
74
|
|
bos@559
|
75 <para>It's common practice with Mercurial to maintain separate
|
|
bos@559
|
76 development branches of a project in different repositories.
|
|
bos@559
|
77 Your development team might have one shared repository for
|
|
bos@559
|
78 your project's <quote>0.9</quote> release, and another,
|
|
bos@559
|
79 containing different changes, for the <quote>1.0</quote>
|
|
bos@559
|
80 release.</para>
|
|
bos@559
|
81
|
|
bos@559
|
82 <para>Given this, you can imagine that the consequences could be
|
|
bos@559
|
83 messy if you had a local <quote>0.9</quote> repository, and
|
|
bos@559
|
84 accidentally pulled changes from the shared <quote>1.0</quote>
|
|
bos@559
|
85 repository into it. At worst, you could be paying
|
|
bos@559
|
86 insufficient attention, and push those changes into the shared
|
|
bos@559
|
87 <quote>0.9</quote> tree, confusing your entire team (but don't
|
|
bos@559
|
88 worry, we'll return to this horror scenario later). However,
|
|
bos@559
|
89 it's more likely that you'll notice immediately, because
|
|
bos@559
|
90 Mercurial will display the URL it's pulling from, or you will
|
|
bos@559
|
91 see it pull a suspiciously large number of changes into the
|
|
bos@559
|
92 repository.</para>
|
|
bos@559
|
93
|
|
bos@559
|
94 <para>The <command role="hg-cmd">hg rollback</command> command
|
|
bos@559
|
95 will work nicely to expunge all of the changesets that you
|
|
bos@559
|
96 just pulled. Mercurial groups all changes from one <command
|
|
bos@559
|
97 role="hg-cmd">hg pull</command> into a single transaction,
|
|
bos@559
|
98 so one <command role="hg-cmd">hg rollback</command> is all you
|
|
bos@559
|
99 need to undo this mistake.</para>
|
|
bos@559
|
100
|
|
bos@559
|
101 </sect2>
|
|
bos@559
|
102 <sect2 id="sec:undo:rollback-after-push">
|
|
bos@559
|
103 <title>Rolling back is useless once you've pushed</title>
|
|
bos@559
|
104
|
|
bos@559
|
105 <para>The value of the <command role="hg-cmd">hg
|
|
bos@559
|
106 rollback</command> command drops to zero once you've pushed
|
|
bos@559
|
107 your changes to another repository. Rolling back a change
|
|
bos@559
|
108 makes it disappear entirely, but <emphasis>only</emphasis> in
|
|
bos@559
|
109 the repository in which you perform the <command
|
|
bos@559
|
110 role="hg-cmd">hg rollback</command>. Because a rollback
|
|
bos@559
|
111 eliminates history, there's no way for the disappearance of a
|
|
bos@559
|
112 change to propagate between repositories.</para>
|
|
bos@559
|
113
|
|
bos@559
|
114 <para>If you've pushed a change to another
|
|
bos@559
|
115 repository&emdash;particularly if it's a shared
|
|
bos@559
|
116 repository&emdash;it has essentially <quote>escaped into the
|
|
bos@559
|
117 wild,</quote> and you'll have to recover from your mistake
|
|
bos@559
|
118 in a different way. What will happen if you push a changeset
|
|
bos@559
|
119 somewhere, then roll it back, then pull from the repository
|
|
bos@559
|
120 you pushed to, is that the changeset will reappear in your
|
|
bos@559
|
121 repository.</para>
|
|
bos@559
|
122
|
|
bos@559
|
123 <para>(If you absolutely know for sure that the change you want
|
|
bos@559
|
124 to roll back is the most recent change in the repository that
|
|
bos@559
|
125 you pushed to, <emphasis>and</emphasis> you know that nobody
|
|
bos@559
|
126 else could have pulled it from that repository, you can roll
|
|
bos@559
|
127 back the changeset there, too, but you really should really
|
|
bos@559
|
128 not rely on this working reliably. If you do this, sooner or
|
|
bos@559
|
129 later a change really will make it into a repository that you
|
|
bos@559
|
130 don't directly control (or have forgotten about), and come
|
|
bos@559
|
131 back to bite you.)</para>
|
|
bos@559
|
132
|
|
bos@559
|
133 </sect2>
|
|
bos@559
|
134 <sect2>
|
|
bos@559
|
135 <title>You can only roll back once</title>
|
|
bos@559
|
136
|
|
bos@559
|
137 <para>Mercurial stores exactly one transaction in its
|
|
bos@559
|
138 transaction log; that transaction is the most recent one that
|
|
bos@559
|
139 occurred in the repository. This means that you can only roll
|
|
bos@559
|
140 back one transaction. If you expect to be able to roll back
|
|
bos@559
|
141 one transaction, then its predecessor, this is not the
|
|
bos@559
|
142 behaviour you will get. <!-- &interaction.rollback.twice; -->
|
|
bos@559
|
143 Once you've rolled back one transaction in a repository, you
|
|
bos@559
|
144 can't roll back again in that repository until you perform
|
|
bos@559
|
145 another commit or pull.</para>
|
|
bos@559
|
146
|
|
bos@559
|
147 </sect2>
|
|
bos@559
|
148 </sect1>
|
|
bos@559
|
149 <sect1>
|
|
bos@559
|
150 <title>Reverting the mistaken change</title>
|
|
bos@559
|
151
|
|
bos@559
|
152 <para>If you make a modification to a file, and decide that you
|
|
bos@559
|
153 really didn't want to change the file at all, and you haven't
|
|
bos@559
|
154 yet committed your changes, the <command role="hg-cmd">hg
|
|
bos@559
|
155 revert</command> command is the one you'll need. It looks at
|
|
bos@559
|
156 the changeset that's the parent of the working directory, and
|
|
bos@559
|
157 restores the contents of the file to their state as of that
|
|
bos@559
|
158 changeset. (That's a long-winded way of saying that, in the
|
|
bos@559
|
159 normal case, it undoes your modifications.)</para>
|
|
bos@559
|
160
|
|
bos@559
|
161 <para>Let's illustrate how the <command role="hg-cmd">hg
|
|
bos@559
|
162 revert</command> command works with yet another small example.
|
|
bos@559
|
163 We'll begin by modifying a file that Mercurial is already
|
|
bos@559
|
164 tracking. <!-- &interaction.daily.revert.modify; --> If we don't
|
|
bos@559
|
165 want that change, we can simply <command role="hg-cmd">hg
|
|
bos@559
|
166 revert</command> the file. <!--
|
|
bos@559
|
167 &interaction.daily.revert.unmodify; --> The <command
|
|
bos@559
|
168 role="hg-cmd">hg revert</command> command provides us with an
|
|
bos@559
|
169 extra degree of safety by saving our modified file with a
|
|
bos@559
|
170 <filename>.orig</filename> extension. <!--
|
|
bos@559
|
171 &interaction.daily.revert.status; --></para>
|
|
bos@559
|
172
|
|
bos@559
|
173 <para>Here is a summary of the cases that the <command
|
|
bos@559
|
174 role="hg-cmd">hg revert</command> command can deal with. We
|
|
bos@559
|
175 will describe each of these in more detail in the section that
|
|
bos@559
|
176 follows.</para>
|
|
bos@559
|
177 <itemizedlist>
|
|
bos@559
|
178 <listitem><para>If you modify a file, it will restore the file
|
|
bos@559
|
179 to its unmodified state.</para>
|
|
bos@559
|
180 </listitem>
|
|
bos@559
|
181 <listitem><para>If you <command role="hg-cmd">hg add</command> a
|
|
bos@559
|
182 file, it will undo the <quote>added</quote> state of the
|
|
bos@559
|
183 file, but leave the file itself untouched.</para>
|
|
bos@559
|
184 </listitem>
|
|
bos@559
|
185 <listitem><para>If you delete a file without telling Mercurial,
|
|
bos@559
|
186 it will restore the file to its unmodified contents.</para>
|
|
bos@559
|
187 </listitem>
|
|
bos@559
|
188 <listitem><para>If you use the <command role="hg-cmd">hg
|
|
bos@559
|
189 remove</command> command to remove a file, it will undo
|
|
bos@559
|
190 the <quote>removed</quote> state of the file, and restore
|
|
bos@559
|
191 the file to its unmodified contents.</para>
|
|
bos@559
|
192 </listitem></itemizedlist>
|
|
bos@559
|
193
|
|
bos@559
|
194 <sect2 id="sec:undo:mgmt">
|
|
bos@559
|
195 <title>File management errors</title>
|
|
bos@559
|
196
|
|
bos@559
|
197 <para>The <command role="hg-cmd">hg revert</command> command is
|
|
bos@559
|
198 useful for more than just modified files. It lets you reverse
|
|
bos@559
|
199 the results of all of Mercurial's file management
|
|
bos@559
|
200 commands&emdash;<command role="hg-cmd">hg add</command>,
|
|
bos@559
|
201 <command role="hg-cmd">hg remove</command>, and so on.</para>
|
|
bos@559
|
202
|
|
bos@559
|
203 <para>If you <command role="hg-cmd">hg add</command> a file,
|
|
bos@559
|
204 then decide that in fact you don't want Mercurial to track it,
|
|
bos@559
|
205 use <command role="hg-cmd">hg revert</command> to undo the
|
|
bos@559
|
206 add. Don't worry; Mercurial will not modify the file in any
|
|
bos@559
|
207 way. It will just <quote>unmark</quote> the file. <!--
|
|
bos@559
|
208 &interaction.daily.revert.add; --></para>
|
|
bos@559
|
209
|
|
bos@559
|
210 <para>Similarly, if you ask Mercurial to <command
|
|
bos@559
|
211 role="hg-cmd">hg remove</command> a file, you can use
|
|
bos@559
|
212 <command role="hg-cmd">hg revert</command> to restore it to
|
|
bos@559
|
213 the contents it had as of the parent of the working directory.
|
|
bos@559
|
214 <!-- &interaction.daily.revert.remove; --> This works just as
|
|
bos@559
|
215 well for a file that you deleted by hand, without telling
|
|
bos@559
|
216 Mercurial (recall that in Mercurial terminology, this kind of
|
|
bos@559
|
217 file is called <quote>missing</quote>). <!--
|
|
bos@559
|
218 &interaction.daily.revert.missing; --></para>
|
|
bos@559
|
219
|
|
bos@559
|
220 <para>If you revert a <command role="hg-cmd">hg copy</command>,
|
|
bos@559
|
221 the copied-to file remains in your working directory
|
|
bos@559
|
222 afterwards, untracked. Since a copy doesn't affect the
|
|
bos@559
|
223 copied-from file in any way, Mercurial doesn't do anything
|
|
bos@559
|
224 with the copied-from file. <!--
|
|
bos@559
|
225 &interaction.daily.revert.copy; --></para>
|
|
bos@559
|
226
|
|
bos@559
|
227 <sect3>
|
|
bos@559
|
228 <title>A slightly special case: reverting a rename</title>
|
|
bos@559
|
229
|
|
bos@559
|
230 <para>If you <command role="hg-cmd">hg rename</command> a
|
|
bos@559
|
231 file, there is one small detail that you should remember.
|
|
bos@559
|
232 When you <command role="hg-cmd">hg revert</command> a
|
|
bos@559
|
233 rename, it's not enough to provide the name of the
|
|
bos@559
|
234 renamed-to file, as you can see here. <!--
|
|
bos@559
|
235 &interaction.daily.revert.rename; --> As you can see from
|
|
bos@559
|
236 the output of <command role="hg-cmd">hg status</command>,
|
|
bos@559
|
237 the renamed-to file is no longer identified as added, but
|
|
bos@559
|
238 the renamed-<emphasis>from</emphasis> file is still removed!
|
|
bos@559
|
239 This is counter-intuitive (at least to me), but at least
|
|
bos@559
|
240 it's easy to deal with. <!--
|
|
bos@559
|
241 &interaction.daily.revert.rename-orig; --> So remember, to
|
|
bos@559
|
242 revert a <command role="hg-cmd">hg rename</command>, you
|
|
bos@559
|
243 must provide <emphasis>both</emphasis> the source and
|
|
bos@559
|
244 destination names.</para>
|
|
bos@559
|
245
|
|
bos@559
|
246 <para>% TODO: the output doesn't look like it will be
|
|
bos@559
|
247 removed!</para>
|
|
bos@559
|
248
|
|
bos@559
|
249 <para>(By the way, if you rename a file, then modify the
|
|
bos@559
|
250 renamed-to file, then revert both components of the rename,
|
|
bos@559
|
251 when Mercurial restores the file that was removed as part of
|
|
bos@559
|
252 the rename, it will be unmodified. If you need the
|
|
bos@559
|
253 modifications in the renamed-to file to show up in the
|
|
bos@559
|
254 renamed-from file, don't forget to copy them over.)</para>
|
|
bos@559
|
255
|
|
bos@559
|
256 <para>These fiddly aspects of reverting a rename arguably
|
|
bos@559
|
257 constitute a small bug in Mercurial.</para>
|
|
bos@559
|
258
|
|
bos@559
|
259 </sect3>
|
|
bos@559
|
260 </sect2>
|
|
bos@559
|
261 </sect1>
|
|
bos@559
|
262 <sect1>
|
|
bos@559
|
263 <title>Dealing with committed changes</title>
|
|
bos@559
|
264
|
|
bos@559
|
265 <para>Consider a case where you have committed a change $a$, and
|
|
bos@559
|
266 another change $b$ on top of it; you then realise that change
|
|
bos@559
|
267 $a$ was incorrect. Mercurial lets you <quote>back out</quote>
|
|
bos@559
|
268 an entire changeset automatically, and building blocks that let
|
|
bos@559
|
269 you reverse part of a changeset by hand.</para>
|
|
bos@559
|
270
|
|
bos@559
|
271 <para>Before you read this section, here's something to keep in
|
|
bos@559
|
272 mind: the <command role="hg-cmd">hg backout</command> command
|
|
bos@559
|
273 undoes changes by <emphasis>adding</emphasis> history, not by
|
|
bos@559
|
274 modifying or erasing it. It's the right tool to use if you're
|
|
bos@559
|
275 fixing bugs, but not if you're trying to undo some change that
|
|
bos@559
|
276 has catastrophic consequences. To deal with those, see section
|
|
bos@559
|
277 <xref linkend="sec:undo:aaaiiieee"/>.</para>
|
|
bos@559
|
278
|
|
bos@559
|
279 <sect2>
|
|
bos@559
|
280 <title>Backing out a changeset</title>
|
|
bos@559
|
281
|
|
bos@559
|
282 <para>The <command role="hg-cmd">hg backout</command> command
|
|
bos@559
|
283 lets you <quote>undo</quote> the effects of an entire
|
|
bos@559
|
284 changeset in an automated fashion. Because Mercurial's
|
|
bos@559
|
285 history is immutable, this command <emphasis>does
|
|
bos@559
|
286 not</emphasis> get rid of the changeset you want to undo.
|
|
bos@559
|
287 Instead, it creates a new changeset that
|
|
bos@559
|
288 <emphasis>reverses</emphasis> the effect of the to-be-undone
|
|
bos@559
|
289 changeset.</para>
|
|
bos@559
|
290
|
|
bos@559
|
291 <para>The operation of the <command role="hg-cmd">hg
|
|
bos@559
|
292 backout</command> command is a little intricate, so let's
|
|
bos@559
|
293 illustrate it with some examples. First, we'll create a
|
|
bos@559
|
294 repository with some simple changes. <!--
|
|
bos@559
|
295 &interaction.backout.init; --></para>
|
|
bos@559
|
296
|
|
bos@559
|
297 <para>The <command role="hg-cmd">hg backout</command> command
|
|
bos@559
|
298 takes a single changeset ID as its argument; this is the
|
|
bos@559
|
299 changeset to back out. Normally, <command role="hg-cmd">hg
|
|
bos@559
|
300 backout</command> will drop you into a text editor to write
|
|
bos@559
|
301 a commit message, so you can record why you're backing the
|
|
bos@559
|
302 change out. In this example, we provide a commit message on
|
|
bos@559
|
303 the command line using the <option
|
|
bos@559
|
304 role="hg-opt-backout">-m</option> option.</para>
|
|
bos@559
|
305
|
|
bos@559
|
306 </sect2>
|
|
bos@559
|
307 <sect2>
|
|
bos@559
|
308 <title>Backing out the tip changeset</title>
|
|
bos@559
|
309
|
|
bos@559
|
310 <para>We're going to start by backing out the last changeset we
|
|
bos@559
|
311 committed. <!-- &interaction.backout.simple; --> You can see
|
|
bos@559
|
312 that the second line from <filename>myfile</filename> is no
|
|
bos@559
|
313 longer present. Taking a look at the output of <command
|
|
bos@559
|
314 role="hg-cmd">hg log</command> gives us an idea of what the
|
|
bos@559
|
315 <command role="hg-cmd">hg backout</command> command has done.
|
|
bos@559
|
316 <!-- &interaction.backout.simple.log; --> Notice that the new
|
|
bos@559
|
317 changeset that <command role="hg-cmd">hg backout</command> has
|
|
bos@559
|
318 created is a child of the changeset we backed out. It's
|
|
bos@559
|
319 easier to see this in figure <xref
|
|
bos@559
|
320 linkend="fig:undo:backout"/>, which presents a graphical
|
|
bos@559
|
321 view of the change history. As you can see, the history is
|
|
bos@559
|
322 nice and linear.</para>
|
|
bos@559
|
323
|
|
bos@559
|
324 <informalfigure id="fig:undo:backout">
|
|
bos@559
|
325 <mediaobject><imageobject><imagedata
|
|
bos@559
|
326 fileref="undo-simple"/></imageobject><textobject><phrase>XXX
|
|
bos@559
|
327 add text</phrase></textobject><caption><para>Backing out
|
|
bos@559
|
328 a change using the <command role="hg-cmd">hg
|
|
bos@559
|
329 backout</command>
|
|
bos@559
|
330 command</para></caption></mediaobject>
|
|
bos@559
|
331
|
|
bos@559
|
332 </informalfigure>
|
|
bos@559
|
333
|
|
bos@559
|
334 </sect2>
|
|
bos@559
|
335 <sect2>
|
|
bos@559
|
336 <title>Backing out a non-tip change</title>
|
|
bos@559
|
337
|
|
bos@559
|
338 <para>If you want to back out a change other than the last one
|
|
bos@559
|
339 you committed, pass the <option
|
|
bos@559
|
340 role="hg-opt-backout">--merge</option> option to the
|
|
bos@559
|
341 <command role="hg-cmd">hg backout</command> command. <!--
|
|
bos@559
|
342 &interaction.backout.non-tip.clone; --> This makes backing out
|
|
bos@559
|
343 any changeset a <quote>one-shot</quote> operation that's
|
|
bos@559
|
344 usually simple and fast. <!--
|
|
bos@559
|
345 &interaction.backout.non-tip.backout; --></para>
|
|
bos@559
|
346
|
|
bos@559
|
347 <para>If you take a look at the contents of
|
|
bos@559
|
348 <filename>myfile</filename> after the backout finishes, you'll
|
|
bos@559
|
349 see that the first and third changes are present, but not the
|
|
bos@559
|
350 second. <!-- &interaction.backout.non-tip.cat; --></para>
|
|
bos@559
|
351
|
|
bos@559
|
352 <para>As the graphical history in figure <xref
|
|
bos@559
|
353 linkend="fig:undo:backout-non-tip"/> illustrates, Mercurial
|
|
bos@559
|
354 actually commits <emphasis>two</emphasis> changes in this kind
|
|
bos@559
|
355 of situation (the box-shaped nodes are the ones that Mercurial
|
|
bos@559
|
356 commits automatically). Before Mercurial begins the backout
|
|
bos@559
|
357 process, it first remembers what the current parent of the
|
|
bos@559
|
358 working directory is. It then backs out the target changeset,
|
|
bos@559
|
359 and commits that as a changeset. Finally, it merges back to
|
|
bos@559
|
360 the previous parent of the working directory, and commits the
|
|
bos@559
|
361 result of the merge.</para>
|
|
bos@559
|
362
|
|
bos@559
|
363 <para>% TODO: to me it looks like mercurial doesn't commit the
|
|
bos@559
|
364 second merge automatically!</para>
|
|
bos@559
|
365
|
|
bos@559
|
366 <informalfigure id="fig:undo:backout-non-tip">
|
|
bos@559
|
367 <mediaobject><imageobject><imagedata
|
|
bos@559
|
368 fileref="undo-non-tip"/></imageobject><textobject><phrase>XXX
|
|
bos@559
|
369 add text</phrase></textobject><caption><para>Automated
|
|
bos@559
|
370 backout of a non-tip change using the <command
|
|
bos@559
|
371 role="hg-cmd">hg backout</command>
|
|
bos@559
|
372 command</para></caption></mediaobject>
|
|
bos@559
|
373 </informalfigure>
|
|
bos@559
|
374
|
|
bos@559
|
375 <para>The result is that you end up <quote>back where you
|
|
bos@559
|
376 were</quote>, only with some extra history that undoes the
|
|
bos@559
|
377 effect of the changeset you wanted to back out.</para>
|
|
bos@559
|
378
|
|
bos@559
|
379 <sect3>
|
|
bos@559
|
380 <title>Always use the <option
|
|
bos@559
|
381 role="hg-opt-backout">--merge</option> option</title>
|
|
bos@559
|
382
|
|
bos@559
|
383 <para>In fact, since the <option
|
|
bos@559
|
384 role="hg-opt-backout">--merge</option> option will do the
|
|
bos@559
|
385 <quote>right thing</quote> whether or not the changeset
|
|
bos@559
|
386 you're backing out is the tip (i.e. it won't try to merge if
|
|
bos@559
|
387 it's backing out the tip, since there's no need), you should
|
|
bos@559
|
388 <emphasis>always</emphasis> use this option when you run the
|
|
bos@559
|
389 <command role="hg-cmd">hg backout</command> command.</para>
|
|
bos@559
|
390
|
|
bos@559
|
391 </sect3>
|
|
bos@559
|
392 </sect2>
|
|
bos@559
|
393 <sect2>
|
|
bos@559
|
394 <title>Gaining more control of the backout process</title>
|
|
bos@559
|
395
|
|
bos@559
|
396 <para>While I've recommended that you always use the <option
|
|
bos@559
|
397 role="hg-opt-backout">--merge</option> option when backing
|
|
bos@559
|
398 out a change, the <command role="hg-cmd">hg backout</command>
|
|
bos@559
|
399 command lets you decide how to merge a backout changeset.
|
|
bos@559
|
400 Taking control of the backout process by hand is something you
|
|
bos@559
|
401 will rarely need to do, but it can be useful to understand
|
|
bos@559
|
402 what the <command role="hg-cmd">hg backout</command> command
|
|
bos@559
|
403 is doing for you automatically. To illustrate this, let's
|
|
bos@559
|
404 clone our first repository, but omit the backout change that
|
|
bos@559
|
405 it contains.</para>
|
|
bos@559
|
406
|
|
bos@559
|
407 <para><!-- &interaction.backout.manual.clone; --> As with our
|
|
bos@559
|
408 earlier example, We'll commit a third changeset, then back out
|
|
bos@559
|
409 its parent, and see what happens. <!--
|
|
bos@559
|
410 &interaction.backout.manual.backout; --> Our new changeset is
|
|
bos@559
|
411 again a descendant of the changeset we backout out; it's thus
|
|
bos@559
|
412 a new head, <emphasis>not</emphasis> a descendant of the
|
|
bos@559
|
413 changeset that was the tip. The <command role="hg-cmd">hg
|
|
bos@559
|
414 backout</command> command was quite explicit in telling us
|
|
bos@559
|
415 this. <!-- &interaction.backout.manual.log; --></para>
|
|
bos@559
|
416
|
|
bos@559
|
417 <para>Again, it's easier to see what has happened by looking at
|
|
bos@559
|
418 a graph of the revision history, in figure <xref
|
|
bos@559
|
419 linkend="fig:undo:backout-manual"/>. This makes it clear
|
|
bos@559
|
420 that when we use <command role="hg-cmd">hg backout</command>
|
|
bos@559
|
421 to back out a change other than the tip, Mercurial adds a new
|
|
bos@559
|
422 head to the repository (the change it committed is
|
|
bos@559
|
423 box-shaped).</para>
|
|
bos@559
|
424
|
|
bos@559
|
425 <informalfigure id="fig:undo:backout-manual">
|
|
bos@559
|
426 <mediaobject><imageobject><imagedata
|
|
bos@559
|
427 fileref="undo-manual"/></imageobject><textobject><phrase>XXX
|
|
bos@559
|
428 add text</phrase></textobject><caption><para>Backing out
|
|
bos@559
|
429 a change using the <command role="hg-cmd">hg
|
|
bos@559
|
430 backout</command>
|
|
bos@559
|
431 command</para></caption></mediaobject>
|
|
bos@559
|
432
|
|
bos@559
|
433 </informalfigure>
|
|
bos@559
|
434
|
|
bos@559
|
435 <para>After the <command role="hg-cmd">hg backout</command>
|
|
bos@559
|
436 command has completed, it leaves the new
|
|
bos@559
|
437 <quote>backout</quote> changeset as the parent of the working
|
|
bos@559
|
438 directory. <!-- &interaction.backout.manual.parents; --> Now
|
|
bos@559
|
439 we have two isolated sets of changes. <!--
|
|
bos@559
|
440 &interaction.backout.manual.heads; --></para>
|
|
bos@559
|
441
|
|
bos@559
|
442 <para>Let's think about what we expect to see as the contents of
|
|
bos@559
|
443 <filename>myfile</filename> now. The first change should be
|
|
bos@559
|
444 present, because we've never backed it out. The second change
|
|
bos@559
|
445 should be missing, as that's the change we backed out. Since
|
|
bos@559
|
446 the history graph shows the third change as a separate head,
|
|
bos@559
|
447 we <emphasis>don't</emphasis> expect to see the third change
|
|
bos@559
|
448 present in <filename>myfile</filename>. <!--
|
|
bos@559
|
449 &interaction.backout.manual.cat; --> To get the third change
|
|
bos@559
|
450 back into the file, we just do a normal merge of our two
|
|
bos@559
|
451 heads. <!-- &interaction.backout.manual.merge; --> Afterwards,
|
|
bos@559
|
452 the graphical history of our repository looks like figure
|
|
bos@559
|
453 <xref linkend="fig:undo:backout-manual-merge"/>.</para>
|
|
bos@559
|
454
|
|
bos@559
|
455 <informalfigure id="fig:undo:backout-manual-merge">
|
|
bos@559
|
456 <mediaobject><imageobject><imagedata
|
|
bos@559
|
457 fileref="undo-manual-merge"/></imageobject><textobject><phrase>XXX
|
|
bos@559
|
458 add text</phrase></textobject><caption><para>Manually
|
|
bos@559
|
459 merging a backout change</para></caption></mediaobject>
|
|
bos@559
|
460
|
|
bos@559
|
461 </informalfigure>
|
|
bos@559
|
462
|
|
bos@559
|
463 </sect2>
|
|
bos@559
|
464 <sect2>
|
|
bos@559
|
465 <title>Why <command role="hg-cmd">hg backout</command> works as
|
|
bos@559
|
466 it does</title>
|
|
bos@559
|
467
|
|
bos@559
|
468 <para>Here's a brief description of how the <command
|
|
bos@559
|
469 role="hg-cmd">hg backout</command> command works.</para>
|
|
bos@559
|
470 <orderedlist>
|
|
bos@559
|
471 <listitem><para>It ensures that the working directory is
|
|
bos@559
|
472 <quote>clean</quote>, i.e. that the output of <command
|
|
bos@559
|
473 role="hg-cmd">hg status</command> would be empty.</para>
|
|
bos@559
|
474 </listitem>
|
|
bos@559
|
475 <listitem><para>It remembers the current parent of the working
|
|
bos@559
|
476 directory. Let's call this changeset
|
|
bos@559
|
477 <literal>orig</literal></para>
|
|
bos@559
|
478 </listitem>
|
|
bos@559
|
479 <listitem><para>It does the equivalent of a <command
|
|
bos@559
|
480 role="hg-cmd">hg update</command> to sync the working
|
|
bos@559
|
481 directory to the changeset you want to back out. Let's
|
|
bos@559
|
482 call this changeset <literal>backout</literal></para>
|
|
bos@559
|
483 </listitem>
|
|
bos@559
|
484 <listitem><para>It finds the parent of that changeset. Let's
|
|
bos@559
|
485 call that changeset <literal>parent</literal>.</para>
|
|
bos@559
|
486 </listitem>
|
|
bos@559
|
487 <listitem><para>For each file that the
|
|
bos@559
|
488 <literal>backout</literal> changeset affected, it does the
|
|
bos@559
|
489 equivalent of a <command role="hg-cmd">hg revert -r
|
|
bos@559
|
490 parent</command> on that file, to restore it to the
|
|
bos@559
|
491 contents it had before that changeset was
|
|
bos@559
|
492 committed.</para>
|
|
bos@559
|
493 </listitem>
|
|
bos@559
|
494 <listitem><para>It commits the result as a new changeset.
|
|
bos@559
|
495 This changeset has <literal>backout</literal> as its
|
|
bos@559
|
496 parent.</para>
|
|
bos@559
|
497 </listitem>
|
|
bos@559
|
498 <listitem><para>If you specify <option
|
|
bos@559
|
499 role="hg-opt-backout">--merge</option> on the command
|
|
bos@559
|
500 line, it merges with <literal>orig</literal>, and commits
|
|
bos@559
|
501 the result of the merge.</para>
|
|
bos@559
|
502 </listitem></orderedlist>
|
|
bos@559
|
503
|
|
bos@559
|
504 <para>An alternative way to implement the <command
|
|
bos@559
|
505 role="hg-cmd">hg backout</command> command would be to
|
|
bos@559
|
506 <command role="hg-cmd">hg export</command> the
|
|
bos@559
|
507 to-be-backed-out changeset as a diff, then use the <option
|
|
bos@559
|
508 role="cmd-opt-patch">--reverse</option> option to the
|
|
bos@559
|
509 <command>patch</command> command to reverse the effect of the
|
|
bos@559
|
510 change without fiddling with the working directory. This
|
|
bos@559
|
511 sounds much simpler, but it would not work nearly as
|
|
bos@559
|
512 well.</para>
|
|
bos@559
|
513
|
|
bos@559
|
514 <para>The reason that <command role="hg-cmd">hg
|
|
bos@559
|
515 backout</command> does an update, a commit, a merge, and
|
|
bos@559
|
516 another commit is to give the merge machinery the best chance
|
|
bos@559
|
517 to do a good job when dealing with all the changes
|
|
bos@559
|
518 <emphasis>between</emphasis> the change you're backing out and
|
|
bos@559
|
519 the current tip.</para>
|
|
bos@559
|
520
|
|
bos@559
|
521 <para>If you're backing out a changeset that's 100 revisions
|
|
bos@559
|
522 back in your project's history, the chances that the
|
|
bos@559
|
523 <command>patch</command> command will be able to apply a
|
|
bos@559
|
524 reverse diff cleanly are not good, because intervening changes
|
|
bos@559
|
525 are likely to have <quote>broken the context</quote> that
|
|
bos@559
|
526 <command>patch</command> uses to determine whether it can
|
|
bos@559
|
527 apply a patch (if this sounds like gibberish, see <xref
|
|
bos@559
|
528 linkend="sec:mq:patch"/> for a
|
|
bos@559
|
529 discussion of the <command>patch</command> command). Also,
|
|
bos@559
|
530 Mercurial's merge machinery will handle files and directories
|
|
bos@559
|
531 being renamed, permission changes, and modifications to binary
|
|
bos@559
|
532 files, none of which <command>patch</command> can deal
|
|
bos@559
|
533 with.</para>
|
|
bos@559
|
534
|
|
bos@559
|
535 </sect2>
|
|
bos@559
|
536 </sect1>
|
|
bos@559
|
537 <sect1 id="sec:undo:aaaiiieee">
|
|
bos@559
|
538 <title>Changes that should never have been</title>
|
|
bos@559
|
539
|
|
bos@559
|
540 <para>Most of the time, the <command role="hg-cmd">hg
|
|
bos@559
|
541 backout</command> command is exactly what you need if you want
|
|
bos@559
|
542 to undo the effects of a change. It leaves a permanent record
|
|
bos@559
|
543 of exactly what you did, both when committing the original
|
|
bos@559
|
544 changeset and when you cleaned up after it.</para>
|
|
bos@559
|
545
|
|
bos@559
|
546 <para>On rare occasions, though, you may find that you've
|
|
bos@559
|
547 committed a change that really should not be present in the
|
|
bos@559
|
548 repository at all. For example, it would be very unusual, and
|
|
bos@559
|
549 usually considered a mistake, to commit a software project's
|
|
bos@559
|
550 object files as well as its source files. Object files have
|
|
bos@559
|
551 almost no intrinsic value, and they're <emphasis>big</emphasis>,
|
|
bos@559
|
552 so they increase the size of the repository and the amount of
|
|
bos@559
|
553 time it takes to clone or pull changes.</para>
|
|
bos@559
|
554
|
|
bos@559
|
555 <para>Before I discuss the options that you have if you commit a
|
|
bos@559
|
556 <quote>brown paper bag</quote> change (the kind that's so bad
|
|
bos@559
|
557 that you want to pull a brown paper bag over your head), let me
|
|
bos@559
|
558 first discuss some approaches that probably won't work.</para>
|
|
bos@559
|
559
|
|
bos@559
|
560 <para>Since Mercurial treats history as accumulative&emdash;every
|
|
bos@559
|
561 change builds on top of all changes that preceded it&emdash;you
|
|
bos@559
|
562 generally can't just make disastrous changes disappear. The one
|
|
bos@559
|
563 exception is when you've just committed a change, and it hasn't
|
|
bos@559
|
564 been pushed or pulled into another repository. That's when you
|
|
bos@559
|
565 can safely use the <command role="hg-cmd">hg rollback</command>
|
|
bos@559
|
566 command, as I detailed in section <xref
|
|
bos@559
|
567 linkend="sec:undo:rollback"/>.</para>
|
|
bos@559
|
568
|
|
bos@559
|
569 <para>After you've pushed a bad change to another repository, you
|
|
bos@559
|
570 <emphasis>could</emphasis> still use <command role="hg-cmd">hg
|
|
bos@559
|
571 rollback</command> to make your local copy of the change
|
|
bos@559
|
572 disappear, but it won't have the consequences you want. The
|
|
bos@559
|
573 change will still be present in the remote repository, so it
|
|
bos@559
|
574 will reappear in your local repository the next time you
|
|
bos@559
|
575 pull.</para>
|
|
bos@559
|
576
|
|
bos@559
|
577 <para>If a situation like this arises, and you know which
|
|
bos@559
|
578 repositories your bad change has propagated into, you can
|
|
bos@559
|
579 <emphasis>try</emphasis> to get rid of the changeefrom
|
|
bos@559
|
580 <emphasis>every</emphasis> one of those repositories. This is,
|
|
bos@559
|
581 of course, not a satisfactory solution: if you miss even a
|
|
bos@559
|
582 single repository while you're expunging, the change is still
|
|
bos@559
|
583 <quote>in the wild</quote>, and could propagate further.</para>
|
|
bos@559
|
584
|
|
bos@559
|
585 <para>If you've committed one or more changes
|
|
bos@559
|
586 <emphasis>after</emphasis> the change that you'd like to see
|
|
bos@559
|
587 disappear, your options are further reduced. Mercurial doesn't
|
|
bos@559
|
588 provide a way to <quote>punch a hole</quote> in history, leaving
|
|
bos@559
|
589 changesets intact.</para>
|
|
bos@559
|
590
|
|
bos@559
|
591 <para>XXX This needs filling out. The
|
|
bos@559
|
592 <literal>hg-replay</literal> script in the
|
|
bos@559
|
593 <literal>examples</literal> directory works, but doesn't handle
|
|
bos@559
|
594 merge changesets. Kind of an important omission.</para>
|
|
bos@559
|
595
|
|
bos@559
|
596 <sect2>
|
|
bos@559
|
597 <title>Protect yourself from <quote>escaped</quote>
|
|
bos@559
|
598 changes</title>
|
|
bos@559
|
599
|
|
bos@559
|
600 <para>If you've committed some changes to your local repository
|
|
bos@559
|
601 and they've been pushed or pulled somewhere else, this isn't
|
|
bos@559
|
602 necessarily a disaster. You can protect yourself ahead of
|
|
bos@559
|
603 time against some classes of bad changeset. This is
|
|
bos@559
|
604 particularly easy if your team usually pulls changes from a
|
|
bos@559
|
605 central repository.</para>
|
|
bos@559
|
606
|
|
bos@559
|
607 <para>By configuring some hooks on that repository to validate
|
|
bos@559
|
608 incoming changesets (see chapter <xref linkend="chap:hook"/>),
|
|
bos@559
|
609 you can
|
|
bos@559
|
610 automatically prevent some kinds of bad changeset from being
|
|
bos@559
|
611 pushed to the central repository at all. With such a
|
|
bos@559
|
612 configuration in place, some kinds of bad changeset will
|
|
bos@559
|
613 naturally tend to <quote>die out</quote> because they can't
|
|
bos@559
|
614 propagate into the central repository. Better yet, this
|
|
bos@559
|
615 happens without any need for explicit intervention.</para>
|
|
bos@559
|
616
|
|
bos@559
|
617 <para>For instance, an incoming change hook that verifies that a
|
|
bos@559
|
618 changeset will actually compile can prevent people from
|
|
bos@559
|
619 inadvertantly <quote>breaking the build</quote>.</para>
|
|
bos@559
|
620
|
|
bos@559
|
621 </sect2>
|
|
bos@559
|
622 </sect1>
|
|
bos@559
|
623 <sect1 id="sec:undo:bisect">
|
|
bos@559
|
624 <title>Finding the source of a bug</title>
|
|
bos@559
|
625
|
|
bos@559
|
626 <para>While it's all very well to be able to back out a changeset
|
|
bos@559
|
627 that introduced a bug, this requires that you know which
|
|
bos@559
|
628 changeset to back out. Mercurial provides an invaluable
|
|
bos@559
|
629 command, called <command role="hg-cmd">hg bisect</command>, that
|
|
bos@559
|
630 helps you to automate this process and accomplish it very
|
|
bos@559
|
631 efficiently.</para>
|
|
bos@559
|
632
|
|
bos@559
|
633 <para>The idea behind the <command role="hg-cmd">hg
|
|
bos@559
|
634 bisect</command> command is that a changeset has introduced
|
|
bos@559
|
635 some change of behaviour that you can identify with a simple
|
|
bos@559
|
636 binary test. You don't know which piece of code introduced the
|
|
bos@559
|
637 change, but you know how to test for the presence of the bug.
|
|
bos@559
|
638 The <command role="hg-cmd">hg bisect</command> command uses your
|
|
bos@559
|
639 test to direct its search for the changeset that introduced the
|
|
bos@559
|
640 code that caused the bug.</para>
|
|
bos@559
|
641
|
|
bos@559
|
642 <para>Here are a few scenarios to help you understand how you
|
|
bos@559
|
643 might apply this command.</para>
|
|
bos@559
|
644 <itemizedlist>
|
|
bos@559
|
645 <listitem><para>The most recent version of your software has a
|
|
bos@559
|
646 bug that you remember wasn't present a few weeks ago, but
|
|
bos@559
|
647 you don't know when it was introduced. Here, your binary
|
|
bos@559
|
648 test checks for the presence of that bug.</para>
|
|
bos@559
|
649 </listitem>
|
|
bos@559
|
650 <listitem><para>You fixed a bug in a rush, and now it's time to
|
|
bos@559
|
651 close the entry in your team's bug database. The bug
|
|
bos@559
|
652 database requires a changeset ID when you close an entry,
|
|
bos@559
|
653 but you don't remember which changeset you fixed the bug in.
|
|
bos@559
|
654 Once again, your binary test checks for the presence of the
|
|
bos@559
|
655 bug.</para>
|
|
bos@559
|
656 </listitem>
|
|
bos@559
|
657 <listitem><para>Your software works correctly, but runs 15%
|
|
bos@559
|
658 slower than the last time you measured it. You want to know
|
|
bos@559
|
659 which changeset introduced the performance regression. In
|
|
bos@559
|
660 this case, your binary test measures the performance of your
|
|
bos@559
|
661 software, to see whether it's <quote>fast</quote> or
|
|
bos@559
|
662 <quote>slow</quote>.</para>
|
|
bos@559
|
663 </listitem>
|
|
bos@559
|
664 <listitem><para>The sizes of the components of your project that
|
|
bos@559
|
665 you ship exploded recently, and you suspect that something
|
|
bos@559
|
666 changed in the way you build your project.</para>
|
|
bos@559
|
667 </listitem></itemizedlist>
|
|
bos@559
|
668
|
|
bos@559
|
669 <para>From these examples, it should be clear that the <command
|
|
bos@559
|
670 role="hg-cmd">hg bisect</command> command is not useful only
|
|
bos@559
|
671 for finding the sources of bugs. You can use it to find any
|
|
bos@559
|
672 <quote>emergent property</quote> of a repository (anything that
|
|
bos@559
|
673 you can't find from a simple text search of the files in the
|
|
bos@559
|
674 tree) for which you can write a binary test.</para>
|
|
bos@559
|
675
|
|
bos@559
|
676 <para>We'll introduce a little bit of terminology here, just to
|
|
bos@559
|
677 make it clear which parts of the search process are your
|
|
bos@559
|
678 responsibility, and which are Mercurial's. A
|
|
bos@559
|
679 <emphasis>test</emphasis> is something that
|
|
bos@559
|
680 <emphasis>you</emphasis> run when <command role="hg-cmd">hg
|
|
bos@559
|
681 bisect</command> chooses a changeset. A
|
|
bos@559
|
682 <emphasis>probe</emphasis> is what <command role="hg-cmd">hg
|
|
bos@559
|
683 bisect</command> runs to tell whether a revision is good.
|
|
bos@559
|
684 Finally, we'll use the word <quote>bisect</quote>, as both a
|
|
bos@559
|
685 noun and a verb, to stand in for the phrase <quote>search using
|
|
bos@559
|
686 the <command role="hg-cmd">hg bisect</command>
|
|
bos@559
|
687 command</quote>.</para>
|
|
bos@559
|
688
|
|
bos@559
|
689 <para>One simple way to automate the searching process would be
|
|
bos@559
|
690 simply to probe every changeset. However, this scales poorly.
|
|
bos@559
|
691 If it took ten minutes to test a single changeset, and you had
|
|
bos@559
|
692 10,000 changesets in your repository, the exhaustive approach
|
|
bos@559
|
693 would take on average 35 <emphasis>days</emphasis> to find the
|
|
bos@559
|
694 changeset that introduced a bug. Even if you knew that the bug
|
|
bos@559
|
695 was introduced by one of the last 500 changesets, and limited
|
|
bos@559
|
696 your search to those, you'd still be looking at over 40 hours to
|
|
bos@559
|
697 find the changeset that introduced your bug.</para>
|
|
bos@559
|
698
|
|
bos@559
|
699 <para>What the <command role="hg-cmd">hg bisect</command> command
|
|
bos@559
|
700 does is use its knowledge of the <quote>shape</quote> of your
|
|
bos@559
|
701 project's revision history to perform a search in time
|
|
bos@559
|
702 proportional to the <emphasis>logarithm</emphasis> of the number
|
|
bos@559
|
703 of changesets to check (the kind of search it performs is called
|
|
bos@559
|
704 a dichotomic search). With this approach, searching through
|
|
bos@559
|
705 10,000 changesets will take less than three hours, even at ten
|
|
bos@559
|
706 minutes per test (the search will require about 14 tests).
|
|
bos@559
|
707 Limit your search to the last hundred changesets, and it will
|
|
bos@559
|
708 take only about an hour (roughly seven tests).</para>
|
|
bos@559
|
709
|
|
bos@559
|
710 <para>The <command role="hg-cmd">hg bisect</command> command is
|
|
bos@559
|
711 aware of the <quote>branchy</quote> nature of a Mercurial
|
|
bos@559
|
712 project's revision history, so it has no problems dealing with
|
|
bos@559
|
713 branches, merges, or multiple heads in a repository. It can
|
|
bos@559
|
714 prune entire branches of history with a single probe, which is
|
|
bos@559
|
715 how it operates so efficiently.</para>
|
|
bos@559
|
716
|
|
bos@559
|
717 <sect2>
|
|
bos@559
|
718 <title>Using the <command role="hg-cmd">hg bisect</command>
|
|
bos@559
|
719 command</title>
|
|
bos@559
|
720
|
|
bos@559
|
721 <para>Here's an example of <command role="hg-cmd">hg
|
|
bos@559
|
722 bisect</command> in action.</para>
|
|
bos@559
|
723
|
|
bos@559
|
724 <note>
|
|
bos@559
|
725 <para> In versions 0.9.5 and earlier of Mercurial, <command
|
|
bos@559
|
726 role="hg-cmd">hg bisect</command> was not a core command:
|
|
bos@559
|
727 it was distributed with Mercurial as an extension. This
|
|
bos@559
|
728 section describes the built-in command, not the old
|
|
bos@559
|
729 extension.</para>
|
|
bos@559
|
730 </note>
|
|
bos@559
|
731
|
|
bos@559
|
732 <para>Now let's create a repository, so that we can try out the
|
|
bos@559
|
733 <command role="hg-cmd">hg bisect</command> command in
|
|
bos@559
|
734 isolation. <!-- &interaction.bisect.init; --> We'll simulate a
|
|
bos@559
|
735 project that has a bug in it in a simple-minded way: create
|
|
bos@559
|
736 trivial changes in a loop, and nominate one specific change
|
|
bos@559
|
737 that will have the <quote>bug</quote>. This loop creates 35
|
|
bos@559
|
738 changesets, each adding a single file to the repository.
|
|
bos@559
|
739 We'll represent our <quote>bug</quote> with a file that
|
|
bos@559
|
740 contains the text <quote>i have a gub</quote>. <!--
|
|
bos@559
|
741 &interaction.bisect.commits; --></para>
|
|
bos@559
|
742
|
|
bos@559
|
743 <para>The next thing that we'd like to do is figure out how to
|
|
bos@559
|
744 use the <command role="hg-cmd">hg bisect</command> command.
|
|
bos@559
|
745 We can use Mercurial's normal built-in help mechanism for
|
|
bos@559
|
746 this. <!-- &interaction.bisect.help; --></para>
|
|
bos@559
|
747
|
|
bos@559
|
748 <para>The <command role="hg-cmd">hg bisect</command> command
|
|
bos@559
|
749 works in steps. Each step proceeds as follows.</para>
|
|
bos@559
|
750 <orderedlist>
|
|
bos@559
|
751 <listitem><para>You run your binary test.</para>
|
|
bos@559
|
752 <itemizedlist>
|
|
bos@559
|
753 <listitem><para>If the test succeeded, you tell <command
|
|
bos@559
|
754 role="hg-cmd">hg bisect</command> by running the
|
|
bos@559
|
755 <command role="hg-cmd">hg bisect good</command>
|
|
bos@559
|
756 command.</para>
|
|
bos@559
|
757 </listitem>
|
|
bos@559
|
758 <listitem><para>If it failed, run the <command
|
|
bos@559
|
759 role="hg-cmd">hg bisect bad</command>
|
|
bos@559
|
760 command.</para></listitem></itemizedlist>
|
|
bos@559
|
761 </listitem>
|
|
bos@559
|
762 <listitem><para>The command uses your information to decide
|
|
bos@559
|
763 which changeset to test next.</para>
|
|
bos@559
|
764 </listitem>
|
|
bos@559
|
765 <listitem><para>It updates the working directory to that
|
|
bos@559
|
766 changeset, and the process begins again.</para>
|
|
bos@559
|
767 </listitem></orderedlist>
|
|
bos@559
|
768 <para>The process ends when <command role="hg-cmd">hg
|
|
bos@559
|
769 bisect</command> identifies a unique changeset that marks
|
|
bos@559
|
770 the point where your test transitioned from
|
|
bos@559
|
771 <quote>succeeding</quote> to <quote>failing</quote>.</para>
|
|
bos@559
|
772
|
|
bos@559
|
773 <para>To start the search, we must run the <command
|
|
bos@559
|
774 role="hg-cmd">hg bisect --reset</command> command. <!--
|
|
bos@559
|
775 &interaction.bisect.search.init; --></para>
|
|
bos@559
|
776
|
|
bos@559
|
777 <para>In our case, the binary test we use is simple: we check to
|
|
bos@559
|
778 see if any file in the repository contains the string <quote>i
|
|
bos@559
|
779 have a gub</quote>. If it does, this changeset contains the
|
|
bos@559
|
780 change that <quote>caused the bug</quote>. By convention, a
|
|
bos@559
|
781 changeset that has the property we're searching for is
|
|
bos@559
|
782 <quote>bad</quote>, while one that doesn't is
|
|
bos@559
|
783 <quote>good</quote>.</para>
|
|
bos@559
|
784
|
|
bos@559
|
785 <para>Most of the time, the revision to which the working
|
|
bos@559
|
786 directory is synced (usually the tip) already exhibits the
|
|
bos@559
|
787 problem introduced by the buggy change, so we'll mark it as
|
|
bos@559
|
788 <quote>bad</quote>. <!-- &interaction.bisect.search.bad-init;
|
|
bos@559
|
789 --></para>
|
|
bos@559
|
790
|
|
bos@559
|
791 <para>Our next task is to nominate a changeset that we know
|
|
bos@559
|
792 <emphasis>doesn't</emphasis> have the bug; the <command
|
|
bos@559
|
793 role="hg-cmd">hg bisect</command> command will
|
|
bos@559
|
794 <quote>bracket</quote> its search between the first pair of
|
|
bos@559
|
795 good and bad changesets. In our case, we know that revision
|
|
bos@559
|
796 10 didn't have the bug. (I'll have more words about choosing
|
|
bos@559
|
797 the first <quote>good</quote> changeset later.) <!--
|
|
bos@559
|
798 &interaction.bisect.search.good-init; --></para>
|
|
bos@559
|
799
|
|
bos@559
|
800 <para>Notice that this command printed some output.</para>
|
|
bos@559
|
801 <itemizedlist>
|
|
bos@559
|
802 <listitem><para>It told us how many changesets it must
|
|
bos@559
|
803 consider before it can identify the one that introduced
|
|
bos@559
|
804 the bug, and how many tests that will require.</para>
|
|
bos@559
|
805 </listitem>
|
|
bos@559
|
806 <listitem><para>It updated the working directory to the next
|
|
bos@559
|
807 changeset to test, and told us which changeset it's
|
|
bos@559
|
808 testing.</para>
|
|
bos@559
|
809 </listitem></itemizedlist>
|
|
bos@559
|
810
|
|
bos@559
|
811 <para>We now run our test in the working directory. We use the
|
|
bos@559
|
812 <command>grep</command> command to see if our
|
|
bos@559
|
813 <quote>bad</quote> file is present in the working directory.
|
|
bos@559
|
814 If it is, this revision is bad; if not, this revision is good.
|
|
bos@559
|
815 <!-- &interaction.bisect.search.step1; --></para>
|
|
bos@559
|
816
|
|
bos@559
|
817 <para>This test looks like a perfect candidate for automation,
|
|
bos@559
|
818 so let's turn it into a shell function. <!--
|
|
bos@559
|
819 &interaction.bisect.search.mytest; --> We can now run an
|
|
bos@559
|
820 entire test step with a single command,
|
|
bos@559
|
821 <literal>mytest</literal>. <!--
|
|
bos@559
|
822 &interaction.bisect.search.step2; --> A few more invocations
|
|
bos@559
|
823 of our canned test step command, and we're done. <!--
|
|
bos@559
|
824 &interaction.bisect.search.rest; --></para>
|
|
bos@559
|
825
|
|
bos@559
|
826 <para>Even though we had 40 changesets to search through, the
|
|
bos@559
|
827 <command role="hg-cmd">hg bisect</command> command let us find
|
|
bos@559
|
828 the changeset that introduced our <quote>bug</quote> with only
|
|
bos@559
|
829 five tests. Because the number of tests that the <command
|
|
bos@559
|
830 role="hg-cmd">hg bisect</command> command performs grows
|
|
bos@559
|
831 logarithmically with the number of changesets to search, the
|
|
bos@559
|
832 advantage that it has over the <quote>brute force</quote>
|
|
bos@559
|
833 search approach increases with every changeset you add.</para>
|
|
bos@559
|
834
|
|
bos@559
|
835 </sect2>
|
|
bos@559
|
836 <sect2>
|
|
bos@559
|
837 <title>Cleaning up after your search</title>
|
|
bos@559
|
838
|
|
bos@559
|
839 <para>When you're finished using the <command role="hg-cmd">hg
|
|
bos@559
|
840 bisect</command> command in a repository, you can use the
|
|
bos@559
|
841 <command role="hg-cmd">hg bisect reset</command> command to
|
|
bos@559
|
842 drop the information it was using to drive your search. The
|
|
bos@559
|
843 command doesn't use much space, so it doesn't matter if you
|
|
bos@559
|
844 forget to run this command. However, <command
|
|
bos@559
|
845 role="hg-cmd">hg bisect</command> won't let you start a new
|
|
bos@559
|
846 search in that repository until you do a <command
|
|
bos@559
|
847 role="hg-cmd">hg bisect reset</command>. <!--
|
|
bos@559
|
848 &interaction.bisect.search.reset; --></para>
|
|
bos@559
|
849
|
|
bos@559
|
850 </sect2>
|
|
bos@559
|
851 </sect1>
|
|
bos@559
|
852 <sect1>
|
|
bos@559
|
853 <title>Tips for finding bugs effectively</title>
|
|
bos@559
|
854
|
|
bos@559
|
855 <sect2>
|
|
bos@559
|
856 <title>Give consistent input</title>
|
|
bos@559
|
857
|
|
bos@559
|
858 <para>The <command role="hg-cmd">hg bisect</command> command
|
|
bos@559
|
859 requires that you correctly report the result of every test
|
|
bos@559
|
860 you perform. If you tell it that a test failed when it really
|
|
bos@559
|
861 succeeded, it <emphasis>might</emphasis> be able to detect the
|
|
bos@559
|
862 inconsistency. If it can identify an inconsistency in your
|
|
bos@559
|
863 reports, it will tell you that a particular changeset is both
|
|
bos@559
|
864 good and bad. However, it can't do this perfectly; it's about
|
|
bos@559
|
865 as likely to report the wrong changeset as the source of the
|
|
bos@559
|
866 bug.</para>
|
|
bos@559
|
867
|
|
bos@559
|
868 </sect2>
|
|
bos@559
|
869 <sect2>
|
|
bos@559
|
870 <title>Automate as much as possible</title>
|
|
bos@559
|
871
|
|
bos@559
|
872 <para>When I started using the <command role="hg-cmd">hg
|
|
bos@559
|
873 bisect</command> command, I tried a few times to run my
|
|
bos@559
|
874 tests by hand, on the command line. This is an approach that
|
|
bos@559
|
875 I, at least, am not suited to. After a few tries, I found
|
|
bos@559
|
876 that I was making enough mistakes that I was having to restart
|
|
bos@559
|
877 my searches several times before finally getting correct
|
|
bos@559
|
878 results.</para>
|
|
bos@559
|
879
|
|
bos@559
|
880 <para>My initial problems with driving the <command
|
|
bos@559
|
881 role="hg-cmd">hg bisect</command> command by hand occurred
|
|
bos@559
|
882 even with simple searches on small repositories; if the
|
|
bos@559
|
883 problem you're looking for is more subtle, or the number of
|
|
bos@559
|
884 tests that <command role="hg-cmd">hg bisect</command> must
|
|
bos@559
|
885 perform increases, the likelihood of operator error ruining
|
|
bos@559
|
886 the search is much higher. Once I started automating my
|
|
bos@559
|
887 tests, I had much better results.</para>
|
|
bos@559
|
888
|
|
bos@559
|
889 <para>The key to automated testing is twofold:</para>
|
|
bos@559
|
890 <itemizedlist>
|
|
bos@559
|
891 <listitem><para>always test for the same symptom, and</para>
|
|
bos@559
|
892 </listitem>
|
|
bos@559
|
893 <listitem><para>always feed consistent input to the <command
|
|
bos@559
|
894 role="hg-cmd">hg bisect</command> command.</para>
|
|
bos@559
|
895 </listitem></itemizedlist>
|
|
bos@559
|
896 <para>In my tutorial example above, the <command>grep</command>
|
|
bos@559
|
897 command tests for the symptom, and the <literal>if</literal>
|
|
bos@559
|
898 statement takes the result of this check and ensures that we
|
|
bos@559
|
899 always feed the same input to the <command role="hg-cmd">hg
|
|
bos@559
|
900 bisect</command> command. The <literal>mytest</literal>
|
|
bos@559
|
901 function marries these together in a reproducible way, so that
|
|
bos@559
|
902 every test is uniform and consistent.</para>
|
|
bos@559
|
903
|
|
bos@559
|
904 </sect2>
|
|
bos@559
|
905 <sect2>
|
|
bos@559
|
906 <title>Check your results</title>
|
|
bos@559
|
907
|
|
bos@559
|
908 <para>Because the output of a <command role="hg-cmd">hg
|
|
bos@559
|
909 bisect</command> search is only as good as the input you
|
|
bos@559
|
910 give it, don't take the changeset it reports as the absolute
|
|
bos@559
|
911 truth. A simple way to cross-check its report is to manually
|
|
bos@559
|
912 run your test at each of the following changesets:</para>
|
|
bos@559
|
913 <itemizedlist>
|
|
bos@559
|
914 <listitem><para>The changeset that it reports as the first bad
|
|
bos@559
|
915 revision. Your test should still report this as
|
|
bos@559
|
916 bad.</para>
|
|
bos@559
|
917 </listitem>
|
|
bos@559
|
918 <listitem><para>The parent of that changeset (either parent,
|
|
bos@559
|
919 if it's a merge). Your test should report this changeset
|
|
bos@559
|
920 as good.</para>
|
|
bos@559
|
921 </listitem>
|
|
bos@559
|
922 <listitem><para>A child of that changeset. Your test should
|
|
bos@559
|
923 report this changeset as bad.</para>
|
|
bos@559
|
924 </listitem></itemizedlist>
|
|
bos@559
|
925
|
|
bos@559
|
926 </sect2>
|
|
bos@559
|
927 <sect2>
|
|
bos@559
|
928 <title>Beware interference between bugs</title>
|
|
bos@559
|
929
|
|
bos@559
|
930 <para>It's possible that your search for one bug could be
|
|
bos@559
|
931 disrupted by the presence of another. For example, let's say
|
|
bos@559
|
932 your software crashes at revision 100, and worked correctly at
|
|
bos@559
|
933 revision 50. Unknown to you, someone else introduced a
|
|
bos@559
|
934 different crashing bug at revision 60, and fixed it at
|
|
bos@559
|
935 revision 80. This could distort your results in one of
|
|
bos@559
|
936 several ways.</para>
|
|
bos@559
|
937
|
|
bos@559
|
938 <para>It is possible that this other bug completely
|
|
bos@559
|
939 <quote>masks</quote> yours, which is to say that it occurs
|
|
bos@559
|
940 before your bug has a chance to manifest itself. If you can't
|
|
bos@559
|
941 avoid that other bug (for example, it prevents your project
|
|
bos@559
|
942 from building), and so can't tell whether your bug is present
|
|
bos@559
|
943 in a particular changeset, the <command role="hg-cmd">hg
|
|
bos@559
|
944 bisect</command> command cannot help you directly. Instead,
|
|
bos@559
|
945 you can mark a changeset as untested by running <command
|
|
bos@559
|
946 role="hg-cmd">hg bisect --skip</command>.</para>
|
|
bos@559
|
947
|
|
bos@559
|
948 <para>A different problem could arise if your test for a bug's
|
|
bos@559
|
949 presence is not specific enough. If you check for <quote>my
|
|
bos@559
|
950 program crashes</quote>, then both your crashing bug and an
|
|
bos@559
|
951 unrelated crashing bug that masks it will look like the same
|
|
bos@559
|
952 thing, and mislead <command role="hg-cmd">hg
|
|
bos@559
|
953 bisect</command>.</para>
|
|
bos@559
|
954
|
|
bos@559
|
955 <para>Another useful situation in which to use <command
|
|
bos@559
|
956 role="hg-cmd">hg bisect --skip</command> is if you can't
|
|
bos@559
|
957 test a revision because your project was in a broken and hence
|
|
bos@559
|
958 untestable state at that revision, perhaps because someone
|
|
bos@559
|
959 checked in a change that prevented the project from
|
|
bos@559
|
960 building.</para>
|
|
bos@559
|
961
|
|
bos@559
|
962 </sect2>
|
|
bos@559
|
963 <sect2>
|
|
bos@559
|
964 <title>Bracket your search lazily</title>
|
|
bos@559
|
965
|
|
bos@559
|
966 <para>Choosing the first <quote>good</quote> and
|
|
bos@559
|
967 <quote>bad</quote> changesets that will mark the end points of
|
|
bos@559
|
968 your search is often easy, but it bears a little discussion
|
|
bos@559
|
969 nevertheless. From the perspective of <command
|
|
bos@559
|
970 role="hg-cmd">hg bisect</command>, the <quote>newest</quote>
|
|
bos@559
|
971 changeset is conventionally <quote>bad</quote>, and the older
|
|
bos@559
|
972 changeset is <quote>good</quote>.</para>
|
|
bos@559
|
973
|
|
bos@559
|
974 <para>If you're having trouble remembering when a suitable
|
|
bos@559
|
975 <quote>good</quote> change was, so that you can tell <command
|
|
bos@559
|
976 role="hg-cmd">hg bisect</command>, you could do worse than
|
|
bos@559
|
977 testing changesets at random. Just remember to eliminate
|
|
bos@559
|
978 contenders that can't possibly exhibit the bug (perhaps
|
|
bos@559
|
979 because the feature with the bug isn't present yet) and those
|
|
bos@559
|
980 where another problem masks the bug (as I discussed
|
|
bos@559
|
981 above).</para>
|
|
bos@559
|
982
|
|
bos@559
|
983 <para>Even if you end up <quote>early</quote> by thousands of
|
|
bos@559
|
984 changesets or months of history, you will only add a handful
|
|
bos@559
|
985 of tests to the total number that <command role="hg-cmd">hg
|
|
bos@559
|
986 bisect</command> must perform, thanks to its logarithmic
|
|
bos@559
|
987 behaviour.</para>
|
|
bos@559
|
988
|
|
bos@559
|
989 </sect2>
|
|
bos@559
|
990 </sect1>
|
|
bos@559
|
991 </chapter>
|
|
bos@559
|
992
|
|
bos@559
|
993 <!--
|
|
bos@559
|
994 local variables:
|
|
bos@559
|
995 sgml-parent-document: ("00book.xml" "book" "chapter")
|
|
bos@559
|
996 end:
|
|
bos@559
|
997 -->
|
