hgbook
changeset 674:3b640272a966
Progres on resolve
author | Bryan O'Sullivan <bos@serpentine.com> |
---|---|
date | Sun Apr 12 00:05:30 2009 -0700 (2009-04-12) |
parents | dbe5f4bb6507 |
children | e6c99cbd0abd 83540574ee49 |
files | en/ch01-tour-basic.xml en/ch04-daily.xml en/ch05-collab.xml en/ch11-mq.xml en/examples/auto-snippets.xml en/examples/ch04/resolve en/examples/rename.divergent en/examples/run-example |
line diff
1.1 --- a/en/ch01-tour-basic.xml Thu Apr 09 22:54:10 2009 -0700 1.2 +++ b/en/ch01-tour-basic.xml Sun Apr 12 00:05:30 2009 -0700 1.3 @@ -589,7 +589,7 @@ 1.4 <sect3 id="sec:tour-basic:username"> 1.5 <title>Creating a Mercurial configuration file</title> 1.6 1.7 - <para id="x_4a">To set a user name, use your favourite editor 1.8 + <para id="x_4a">To set a user name, use your favorite editor 1.9 to create a file called <filename 1.10 role="special">.hgrc</filename> in your home directory. 1.11 Mercurial will use this file to look up your personalised
2.1 --- a/en/ch04-daily.xml Thu Apr 09 22:54:10 2009 -0700 2.2 +++ b/en/ch04-daily.xml Sun Apr 12 00:05:30 2009 -0700 2.3 @@ -26,14 +26,14 @@ 2.4 <para id="x_1a5">After you run a <command role="hg-cmd">hg commit</command>, 2.5 the files that you added before the commit will no longer be 2.6 listed in the output of <command role="hg-cmd">hg 2.7 - status</command>. The reason for this is that <command 2.8 + status</command>. The reason for this is that by default, <command 2.9 role="hg-cmd">hg status</command> only tells you about 2.10 - <quote>interesting</quote> files&emdash;those that you have 2.11 - modified or told Mercurial to do something with&emdash;by 2.12 - default. If you have a repository that contains thousands of 2.13 - files, you will rarely want to know about files that Mercurial 2.14 - is tracking, but that have not changed. (You can still get this 2.15 - information; we'll return to this later.)</para> 2.16 + <quote>interesting</quote> files&emdash;those that you have (for 2.17 + example) modified, removed, or renamed. If you have a repository 2.18 + that contains thousands of files, you will rarely want to know 2.19 + about files that Mercurial is tracking, but that have not 2.20 + changed. (You can still get this information; we'll return to 2.21 + this later.)</para> 2.22 2.23 <para id="x_1a6">Once you add a file, Mercurial doesn't do anything with it 2.24 immediately. Instead, it will take a snapshot of the file's 2.25 @@ -51,15 +51,15 @@ 2.26 2.27 &interaction.daily.files.add-dir; 2.28 2.29 - <para id="x_1a8">Notice in this example that Mercurial printed the names of 2.30 - the files it added, whereas it didn't do so when we added the 2.31 - file named <filename>a</filename> in the earlier 2.32 - example.</para> 2.33 + <para id="x_1a8">Notice in this example that Mercurial printed 2.34 + the names of the files it added, whereas it didn't do so when 2.35 + we added the file named <filename>myfile.txt</filename> in the 2.36 + earlier example.</para> 2.37 2.38 <para id="x_1a9">What's going on is that in the former case, we explicitly 2.39 - named the file to add on the command line, so the assumption 2.40 - that Mercurial makes in such cases is that you know what you 2.41 - were doing, and it doesn't print any output.</para> 2.42 + named the file to add on the command line. The assumption 2.43 + that Mercurial makes in such cases is that we know what we 2.44 + are doing, and it doesn't print any output.</para> 2.45 2.46 <para id="x_1aa">However, when we <emphasis>imply</emphasis> the names of 2.47 files by giving the name of a directory, Mercurial takes the 2.48 @@ -67,8 +67,8 @@ 2.49 something with. This makes it more clear what is happening, 2.50 and reduces the likelihood of a silent and nasty surprise. 2.51 This behavior is common to most Mercurial commands.</para> 2.52 - 2.53 - </sect2> 2.54 + </sect2> 2.55 + 2.56 <sect2> 2.57 <title>Mercurial tracks files, not directories</title> 2.58 2.59 @@ -102,15 +102,15 @@ 2.60 <para id="x_1ae">Another way to tackle a need for an empty directory is to 2.61 simply create one in your automated build scripts before they 2.62 will need it.</para> 2.63 - 2.64 </sect2> 2.65 </sect1> 2.66 + 2.67 <sect1> 2.68 <title>How to stop tracking a file</title> 2.69 2.70 <para id="x_1af">Once you decide that a file no longer belongs in your 2.71 repository, use the <command role="hg-cmd">hg remove</command> 2.72 - command; this deletes the file, and tells Mercurial to stop 2.73 + command. This deletes the file, and tells Mercurial to stop 2.74 tracking it. A removed file is represented in the output of 2.75 <command role="hg-cmd">hg status</command> with a 2.76 <quote><literal>R</literal></quote>.</para> 2.77 @@ -140,15 +140,16 @@ 2.78 <para id="x_1b4">Removing a file <emphasis>does not</emphasis> in any way 2.79 alter the <emphasis>history</emphasis> of the file.</para> 2.80 2.81 - <para id="x_1b5">If you update the working directory to a changeset in 2.82 - which a file that you have removed was still tracked, it will 2.83 - reappear in the working directory, with the contents it had 2.84 - when you committed that changeset. If you then update the 2.85 - working directory to a later changeset, in which the file had 2.86 - been removed, Mercurial will once again remove the file from 2.87 - the working directory.</para> 2.88 - 2.89 - </sect2> 2.90 + <para id="x_1b5">If you update the working directory to a 2.91 + changeset that was committed when it was still tracking a file 2.92 + that you later removed, the file will reappear in the working 2.93 + directory, with the contents it had when you committed that 2.94 + changeset. If you then update the working directory to a 2.95 + later changeset, in which the file had been removed, Mercurial 2.96 + will once again remove the file from the working 2.97 + directory.</para> 2.98 + </sect2> 2.99 + 2.100 <sect2> 2.101 <title>Missing files</title> 2.102 2.103 @@ -177,9 +178,9 @@ 2.104 name of the file to recover. It will reappear, in unmodified 2.105 form.</para> 2.106 2.107 -&interaction.daily.files.recover-missing; 2.108 - 2.109 - </sect2> 2.110 + &interaction.daily.files.recover-missing; 2.111 + </sect2> 2.112 + 2.113 <sect2> 2.114 <title>Aside: why tell Mercurial explicitly to remove a 2.115 file?</title> 2.116 @@ -192,8 +193,8 @@ 2.117 commit</command>, and stop tracking the file. In practice, 2.118 this made it too easy to accidentally remove a file without 2.119 noticing.</para> 2.120 - 2.121 - </sect2> 2.122 + </sect2> 2.123 + 2.124 <sect2> 2.125 <title>Useful shorthand&emdash;adding and removing files in one 2.126 step</title> 2.127 @@ -210,9 +211,9 @@ 2.128 followed by a commit.</para> 2.129 2.130 &interaction.daily.files.commit-addremove; 2.131 - 2.132 </sect2> 2.133 </sect1> 2.134 + 2.135 <sect1> 2.136 <title>Copying files</title> 2.137 2.138 @@ -272,14 +273,14 @@ 2.139 into its copy, <filename>new-file</filename>.</para> 2.140 2.141 &interaction.daily.copy.merge; 2.142 - 2.143 - </sect2> 2.144 + </sect2> 2.145 + 2.146 <sect2 id="sec:daily:why-copy"> 2.147 <title>Why should changes follow copies?</title> 2.148 2.149 - <para id="x_1c4">This behavior, of changes to a file propagating out to 2.150 - copies of the file, might seem esoteric, but in most cases 2.151 - it's highly desirable.</para> 2.152 + <para id="x_1c4">This behavior&emdash;of changes to a file 2.153 + propagating out to copies of the file&emdash;might seem 2.154 + esoteric, but in most cases it's highly desirable.</para> 2.155 2.156 <para id="x_1c5">First of all, remember that this propagation 2.157 <emphasis>only</emphasis> happens when you merge. So if you 2.158 @@ -288,8 +289,8 @@ 2.159 of your work, nothing will happen.</para> 2.160 2.161 <para id="x_1c6">The second thing to know is that modifications will only 2.162 - propagate across a copy as long as the repository that you're 2.163 - pulling changes from <emphasis>doesn't know</emphasis> about 2.164 + propagate across a copy as long as the changeset that you're 2.165 + merging changes from <emphasis>hasn't yet seen</emphasis> 2.166 the copy.</para> 2.167 2.168 <para id="x_1c7">The reason that Mercurial does this is as follows. Let's 2.169 @@ -301,8 +302,8 @@ 2.170 2.171 <para id="x_1c8">If you pulled and merged my changes, and Mercurial 2.172 <emphasis>didn't</emphasis> propagate changes across copies, 2.173 - your source file would now contain the bug, and unless you 2.174 - remembered to propagate the bug fix by hand, the bug would 2.175 + your new source file would now contain the bug, and unless you 2.176 + knew to propagate the bug fix by hand, the bug would 2.177 <emphasis>remain</emphasis> in your copy of the file.</para> 2.178 2.179 <para id="x_1c9">By automatically propagating the change that fixed the bug 2.180 @@ -315,9 +316,9 @@ 2.181 subsequent merge occurred, there's usually no further need to 2.182 propagate changes from the original file to the copied file, 2.183 and that's why Mercurial only propagates changes across copies 2.184 - until this point, and no further.</para> 2.185 - 2.186 - </sect2> 2.187 + at the first merge, and not afterwards.</para> 2.188 + </sect2> 2.189 + 2.190 <sect2> 2.191 <title>How to make changes <emphasis>not</emphasis> follow a 2.192 copy</title> 2.193 @@ -335,7 +336,7 @@ 2.194 2.195 </sect2> 2.196 <sect2> 2.197 - <title>Behaviour of the <command role="hg-cmd">hg copy</command> 2.198 + <title>Behavior of the <command role="hg-cmd">hg copy</command> 2.199 command</title> 2.200 2.201 <para id="x_1cc">When you use the <command role="hg-cmd">hg copy</command> 2.202 @@ -348,14 +349,17 @@ 2.203 behavior a little counterintuitive, which is why I mention it 2.204 here.)</para> 2.205 2.206 - <para id="x_1cd">The <command role="hg-cmd">hg copy</command> command acts 2.207 - similarly to the Unix <command>cp</command> command (you can 2.208 - use the <command role="hg-cmd">hg cp</command> alias if you 2.209 - prefer). The last argument is the 2.210 - <emphasis>destination</emphasis>, and all prior arguments are 2.211 - <emphasis>sources</emphasis>. If you pass it a single file as 2.212 - the source, and the destination does not exist, it creates a 2.213 - new file with that name.</para> 2.214 + <para id="x_1cd">The <command role="hg-cmd">hg copy</command> 2.215 + command acts similarly to the Unix <command>cp</command> 2.216 + command (you can use the <command role="hg-cmd">hg 2.217 + cp</command> alias if you prefer). We must supply two or 2.218 + more arguments, of which the last is treated as the 2.219 + <emphasis>destination</emphasis>, and all others are 2.220 + <emphasis>sources</emphasis>.</para> 2.221 + 2.222 + <para>If you pass <command role="hg-cmd">hg copy</command> a 2.223 + single file as the source, and the destination does not exist, 2.224 + it creates a new file with that name.</para> 2.225 2.226 &interaction.daily.copy.simple; 2.227 2.228 @@ -375,16 +379,16 @@ 2.229 2.230 &interaction.daily.copy.dir-src-dest; 2.231 2.232 - <para id="x_1d1">As with the <command role="hg-cmd">hg rename</command> 2.233 + <para id="x_1d1">As with the <command role="hg-cmd">hg remove</command> 2.234 command, if you copy a file manually and then want Mercurial 2.235 to know that you've copied the file, simply use the <option 2.236 role="hg-opt-copy">--after</option> option to <command 2.237 role="hg-cmd">hg copy</command>.</para> 2.238 2.239 &interaction.daily.copy.after; 2.240 - 2.241 </sect2> 2.242 </sect1> 2.243 + 2.244 <sect1> 2.245 <title>Renaming files</title> 2.246 2.247 @@ -426,6 +430,11 @@ 2.248 similar to the <command role="hg-cmd">hg copy</command> 2.249 command.</para> 2.250 2.251 + <para>If you're familiar with the Unix command line, you'll be 2.252 + glad to know that <command role="hg-cmd">hg rename</command> 2.253 + command can be invoked as <command role="hg-cmd">hg 2.254 + mv</command>.</para> 2.255 + 2.256 <sect2> 2.257 <title>Renaming files and merging changes</title> 2.258 2.259 @@ -446,8 +455,8 @@ 2.260 rename is definitely important. Without this facility, it 2.261 would simply be too easy for changes to become orphaned when 2.262 files are renamed.</para> 2.263 - 2.264 - </sect2> 2.265 + </sect2> 2.266 + 2.267 <sect2> 2.268 <title>Divergent renames and merging</title> 2.269 2.270 @@ -463,7 +472,9 @@ 2.271 &interaction.rename.divergent.rename.anne; 2.272 2.273 <para id="x_1dc">Meanwhile, Bob renames it to 2.274 - <filename>quux</filename>.</para> 2.275 + <filename>quux</filename>. (Remember that <command 2.276 + role="hg-cmd">hg mv</command> is an alias for <command 2.277 + role="hg-cmd">hg rename</command>.)</para> 2.278 2.279 &interaction.rename.divergent.rename.bob; 2.280 2.281 @@ -478,11 +489,11 @@ 2.282 2.283 &interaction.rename.divergent.merge; 2.284 2.285 - <para id="x_1df">Notice that Mercurial does warn about the divergent 2.286 - renames, but it leaves it up to you to do something about the 2.287 + <para id="x_1df">Notice that while Mercurial warns about the divergent 2.288 + renames, it leaves it up to you to do something about the 2.289 divergence after the merge.</para> 2.290 - 2.291 - </sect2> 2.292 + </sect2> 2.293 + 2.294 <sect2> 2.295 <title>Convergent renames and merging</title> 2.296 2.297 @@ -491,8 +502,8 @@ 2.298 to the same <emphasis>destination</emphasis>. In this case, 2.299 Mercurial runs its normal merge machinery, and lets you guide 2.300 it to a suitable resolution.</para> 2.301 - 2.302 - </sect2> 2.303 + </sect2> 2.304 + 2.305 <sect2> 2.306 <title>Other name-related corner cases</title> 2.307 2.308 @@ -507,6 +518,7 @@ 2.309 2.310 </sect2> 2.311 </sect1> 2.312 + 2.313 <sect1> 2.314 <title>Recovering from mistakes</title> 2.315 2.316 @@ -523,7 +535,7 @@ 2.317 <command role="hg-cmd">hg revert</command> to get rid of 2.318 erroneous changes to a file.</para> 2.319 2.320 - <para id="x_1e4">It's useful to remember that the <command role="hg-cmd">hg 2.321 + <para id="x_1e4">It's good to remember that the <command role="hg-cmd">hg 2.322 revert</command> command is useful for changes that you have 2.323 not yet committed. Once you've committed a change, if you 2.324 decide it was a mistake, you can still do something about it, 2.325 @@ -533,7 +545,133 @@ 2.326 role="hg-cmd">hg revert</command> command, and details about 2.327 how to deal with changes you have already committed, see <xref 2.328 linkend="chap:undo"/>.</para> 2.329 - 2.330 + </sect1> 2.331 + 2.332 + <sect1> 2.333 + <title>Dealing with tricky merges</title> 2.334 + 2.335 + <para>In a complicated or large project, it's not unusual for a 2.336 + merge of two changesets to result in some headaches. Suppose 2.337 + there's a big source file that's been extensively edited by each 2.338 + side of a merge: this is almost inevitably going to result in 2.339 + conflicts, some of which can take a few tries to sort 2.340 + out.</para> 2.341 + 2.342 + <para>Let's develop a simple case of this and see how to deal with 2.343 + it. We'll start off with a repository containing one file, and 2.344 + clone it twice.</para> 2.345 + 2.346 + &interaction.ch04-resolve.init; 2.347 + 2.348 + <para>In one clone, we'll modify the file in one way.</para> 2.349 + 2.350 + &interaction.ch04-resolve.left; 2.351 + 2.352 + <para>In another, we'll modify the file differently.</para> 2.353 + 2.354 + &interaction.ch04-resolve.right; 2.355 + 2.356 + <para>Next, we'll pull each set of changes into our original 2.357 + repo.</para> 2.358 + 2.359 + &interaction.ch04-resolve.pull; 2.360 + 2.361 + <para>We expect our repository to now contain two heads.</para> 2.362 + 2.363 + &interaction.ch04-resolve.heads; 2.364 + 2.365 + <para>Normally, if we run <command role="hg-cmd">hg 2.366 + merge</command> at this point, it will drop us into a GUI that 2.367 + will let us manually resolve the conflicting edits to 2.368 + <filename>myfile.txt</filename>. However, to simplify things 2.369 + for presentation here, we'd like the merge to fail immediately 2.370 + instead. Here's one way we can do so.</para> 2.371 + 2.372 + &interaction.ch04-resolve.export; 2.373 + 2.374 + <para>We've told Mercurial's merge machinery to run the command 2.375 + <command>false</command> (which, as we desire, fails 2.376 + immediately) if it detects a merge that it can't sort out 2.377 + automatically.</para> 2.378 + 2.379 + <para>If we now fire up <command role="hg-cmd">hg 2.380 + merge</command>, it should grind to a halt and report a 2.381 + failure.</para> 2.382 + 2.383 + &interaction.ch04-resolve.merge; 2.384 + 2.385 + <para>Even if we don't notice that the merge failed, Mercurial 2.386 + will prevent us from accidentally committing the result of a 2.387 + failed merge.</para> 2.388 + 2.389 + &interaction.ch04-resolve.cifail; 2.390 + 2.391 + <para>When <command role="hg-cmd">hg commit</command> fails in 2.392 + this case, it suggests that we use the unfamiliar <command 2.393 + role="hg-cmd">hg resolve</command> command. As usual, 2.394 + <command role="hg-cmd">hg help resolve</command> will print a 2.395 + helpful synopsis.</para> 2.396 + 2.397 + <sect2> 2.398 + <title>File resolution states</title> 2.399 + 2.400 + <para>When a merge occurs, most files will usually remain 2.401 + unmodified. For each file where Mercurial has to do 2.402 + something, it tracks the state of the file.</para> 2.403 + 2.404 + <itemizedlist> 2.405 + <listitem> 2.406 + <para>A <emphasis>resolved</emphasis> file has been 2.407 + successfully merged, either automatically by Mercurial or 2.408 + manually with human intervention.</para> 2.409 + </listitem> 2.410 + <listitem> 2.411 + <para>An <emphasis>unresolved</emphasis> file was not merged 2.412 + successfully, and needs more attention.</para> 2.413 + </listitem> 2.414 + </itemizedlist> 2.415 + 2.416 + <para>If Mercurial sees <emphasis>any</emphasis> file in the 2.417 + unresolved state after a merge, it considers the merge to have 2.418 + failed. Fortunately, we do not need to restart the entire 2.419 + merge from scratch.</para> 2.420 + 2.421 + <para>The <option role="hg-opt-resolve">--list</option> or 2.422 + <option role="hg-opt-resolve">-l</option> option to <command 2.423 + role="hg-cmd">hg resolve</command> prints out the state of 2.424 + each merged file.</para> 2.425 + 2.426 + &interaction.ch04-resolve.list; 2.427 + 2.428 + <para>In the output from <command role="hg-cmd">hg 2.429 + resolve</command>, a resolved file is marked with 2.430 + <literal>R</literal>, while an unresolved file is marked with 2.431 + <literal>U</literal>. If any files are listed with 2.432 + <literal>U</literal>, we know that an attempt to commit the 2.433 + results of the merge will fail.</para> 2.434 + </sect2> 2.435 + 2.436 + <sect2> 2.437 + <title>Resolving a file merge</title> 2.438 + 2.439 + <para>We have several options to move a file from the unresolved 2.440 + into the resolved state. By far the most common is to rerun 2.441 + <command role="hg-cmd">hg resolve</command>. If we pass the 2.442 + names of individual files or directories, it will retry the 2.443 + merges of any unresolved files present in those locations. We 2.444 + can also pass the <option role="hg-opt-resolve">--all</option> 2.445 + or <option role="hg-opt-resolve">-a</option> option, which 2.446 + will retry the merges of <emphasis>all</emphasis> unresolved 2.447 + files.</para> 2.448 + 2.449 + <para>Mercurial also lets us modify the resolution state of a 2.450 + file directly. We can manually mark a file as resolved using 2.451 + the <option role="hg-opt-resolve">--mark</option> option, or 2.452 + as unresolved using the <option 2.453 + role="hg-opt-resolve">--unmark</option> option. This allows 2.454 + us to clean up a particularly messy merge by hand, and to keep 2.455 + track of our progress with each file as we go.</para> 2.456 + </sect2> 2.457 </sect1> 2.458 </chapter> 2.459
3.1 --- a/en/ch05-collab.xml Thu Apr 09 22:54:10 2009 -0700 3.2 +++ b/en/ch05-collab.xml Sun Apr 12 00:05:30 2009 -0700 3.3 @@ -23,7 +23,7 @@ 3.4 3.5 <para id="x_44d">Also for human consumption, the web interface provides an 3.6 RSS feed of the changes in a repository. This lets you 3.7 - <quote>subscribe</quote> to a repository using your favourite 3.8 + <quote>subscribe</quote> to a repository using your favorite 3.9 feed reader, and be automatically notified of activity in that 3.10 repository as soon as it happens. I find this capability much 3.11 more convenient than the model of subscribing to a mailing list 3.12 @@ -109,7 +109,7 @@ 3.13 <para id="x_456">As one example, many projects have a loose-knit group of 3.14 collaborators who rarely physically meet each other. Some 3.15 groups like to overcome the isolation of working at a distance 3.16 - by organising occasional <quote>sprints</quote>. In a sprint, 3.17 + by organizing occasional <quote>sprints</quote>. In a sprint, 3.18 a number of people get together in a single location (a 3.19 company's conference room, a hotel meeting room, that kind of 3.20 place) and spend several days more or less locked in there, 3.21 @@ -286,7 +286,7 @@ 3.22 <sect2> 3.23 <title>The release train</title> 3.24 3.25 - <para id="x_46c">Some projects are organised on a <quote>train</quote> 3.26 + <para id="x_46c">Some projects are organized on a <quote>train</quote> 3.27 basis: a release is scheduled to happen every few months, and 3.28 whatever features are ready when the <quote>train</quote> is 3.29 ready to leave are allowed in.</para>
4.1 --- a/en/ch11-mq.xml Thu Apr 09 22:54:10 2009 -0700 4.2 +++ b/en/ch11-mq.xml Sun Apr 12 00:05:30 2009 -0700 4.3 @@ -1143,7 +1143,7 @@ 4.4 free software or open source project, or a series that you 4.5 intend to treat as a sequence of regular changesets when you're 4.6 done, you can use some simple techniques to keep your work well 4.7 - organised.</para> 4.8 + organized.</para> 4.9 4.10 <para id="x_434">Give your patches descriptive names. A good name for a 4.11 patch might be <filename>rework-device-alloc.patch</filename>,
5.1 --- a/en/examples/auto-snippets.xml Thu Apr 09 22:54:10 2009 -0700 5.2 +++ b/en/examples/auto-snippets.xml Sun Apr 12 00:05:30 2009 -0700 5.3 @@ -51,6 +51,15 @@ 5.4 <!ENTITY interaction.branching.stable SYSTEM "results/branching.stable.lxo"> 5.5 <!ENTITY interaction.branching.tag SYSTEM "results/branching.tag.lxo"> 5.6 <!ENTITY interaction.branching.update SYSTEM "results/branching.update.lxo"> 5.7 +<!ENTITY interaction.ch04-resolve.cifail SYSTEM "results/ch04-resolve.cifail.lxo"> 5.8 +<!ENTITY interaction.ch04-resolve.export SYSTEM "results/ch04-resolve.export.lxo"> 5.9 +<!ENTITY interaction.ch04-resolve.heads SYSTEM "results/ch04-resolve.heads.lxo"> 5.10 +<!ENTITY interaction.ch04-resolve.init SYSTEM "results/ch04-resolve.init.lxo"> 5.11 +<!ENTITY interaction.ch04-resolve.left SYSTEM "results/ch04-resolve.left.lxo"> 5.12 +<!ENTITY interaction.ch04-resolve.list SYSTEM "results/ch04-resolve.list.lxo"> 5.13 +<!ENTITY interaction.ch04-resolve.merge SYSTEM "results/ch04-resolve.merge.lxo"> 5.14 +<!ENTITY interaction.ch04-resolve.pull SYSTEM "results/ch04-resolve.pull.lxo"> 5.15 +<!ENTITY interaction.ch04-resolve.right SYSTEM "results/ch04-resolve.right.lxo"> 5.16 <!ENTITY interaction.cmdref.diff-p SYSTEM "results/cmdref.diff-p.lxo"> 5.17 <!ENTITY interaction.daily.copy.after SYSTEM "results/daily.copy.after.lxo"> 5.18 <!ENTITY interaction.daily.copy.cat SYSTEM "results/daily.copy.cat.lxo">
6.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 6.2 +++ b/en/examples/ch04/resolve Sun Apr 12 00:05:30 2009 -0700 6.3 @@ -0,0 +1,38 @@ 6.4 +#$ name: init 6.5 +hg init conflict 6.6 +cd conflict 6.7 +echo first > myfile.txt 6.8 +hg ci -A -m first 6.9 +cd .. 6.10 +hg clone conflict left 6.11 +hg clone conflict right 6.12 + 6.13 +#$ name: left 6.14 +cd left 6.15 +echo left >> myfile.txt 6.16 +hg ci -m left 6.17 + 6.18 +#$ name: right 6.19 +cd ../right 6.20 +echo right >> myfile.txt 6.21 +hg ci -m right 6.22 + 6.23 +#$ name: pull 6.24 +cd ../conflict 6.25 +hg pull -u ../left 6.26 +hg pull -u ../right 6.27 + 6.28 +#$ name: heads 6.29 +hg heads 6.30 + 6.31 +#$ name: export 6.32 +export HGMERGE=merge 6.33 + 6.34 +#$ name: merge 6.35 +hg merge 6.36 + 6.37 +#$ name: cifail 6.38 +hg commit -m 'Attempt to commit a failed merge' 6.39 + 6.40 +#$ name: list 6.41 +hg resolve -l
7.1 --- a/en/examples/rename.divergent Thu Apr 09 22:54:10 2009 -0700 7.2 +++ b/en/examples/rename.divergent Sun Apr 12 00:05:30 2009 -0700 7.3 @@ -14,7 +14,7 @@ 7.4 #$ name: rename.anne 7.5 7.6 cd anne 7.7 -hg mv foo bar 7.8 +hg rename foo bar 7.9 hg ci -m 'Rename foo to bar' 7.10 7.11 #$ name: rename.bob
8.1 --- a/en/examples/run-example Thu Apr 09 22:54:10 2009 -0700 8.2 +++ b/en/examples/run-example Sun Apr 12 00:05:30 2009 -0700 8.3 @@ -317,6 +317,7 @@ 8.4 if out: 8.5 ofp_basename = '%s.%s' % (self.name, out) 8.6 norm = os.path.normpath(ofp_basename) 8.7 + norm = norm.replace(os.sep, '-') 8.8 example.entities[ 8.9 '<!ENTITY interaction.%s ' 8.10 'SYSTEM "results/%s.lxo">' 8.11 @@ -345,7 +346,7 @@ 8.12 ofp.write(hunk) 8.13 # then its output 8.14 ofp.write(xml_escape(output)) 8.15 - ps = newps 8.16 + ps = newps 8.17 self.status('\n') 8.18 except: 8.19 print >> sys.stderr, '(killed)'