hgbook
changeset 701:477d6a3e5023
Many final changes.
author | Bryan O'Sullivan <bos@serpentine.com> |
---|---|
date | Mon May 04 23:52:38 2009 -0700 (2009-05-04) |
parents | d2aacc06e562 |
children | 18131160f7ee |
files | en/appB-mq-ref.xml en/ch02-tour-merge.xml en/ch03-concepts.xml en/ch04-daily.xml en/ch05-collab.xml en/ch06-filenames.xml en/ch07-branch.xml en/ch09-hook.xml en/examples/auto-snippets.xml en/examples/daily.copy en/examples/tour |
line diff
1.1 --- a/en/appB-mq-ref.xml Sun May 03 20:27:28 2009 -0700 1.2 +++ b/en/appB-mq-ref.xml Mon May 04 23:52:38 2009 -0700 1.3 @@ -72,6 +72,16 @@ 1.4 1.5 </sect2> 1.6 <sect2> 1.7 + <title><command role="hg-ext-mq">qfold</command>&emdash;move 1.8 + applied patches into repository history</title> 1.9 + 1.10 + <para>The <command>hg qfinish</command> command converts the 1.11 + specified applied patches into permanent changes by moving 1.12 + them out of MQ's control so that they will be treated as 1.13 + normal repository history.</para> 1.14 + </sect2> 1.15 + 1.16 + <sect2> 1.17 <title><command role="hg-ext-mq">qfold</command>&emdash;merge 1.18 (<quote>fold</quote>) several patches into one</title> 1.19 1.20 @@ -328,8 +338,8 @@ 1.21 no such text, a default commit message is used that 1.22 identifies the name of the patch.</para> 1.23 </listitem></itemizedlist> 1.24 - <para id="x_615">If a patch contains a Mercurial patch header (XXX add 1.25 - link), the information in the patch header overrides these 1.26 + <para id="x_615">If a patch contains a Mercurial patch header, 1.27 + the information in the patch header overrides these 1.28 defaults.</para> 1.29 1.30 <para id="x_616">Options:</para> 1.31 @@ -435,21 +445,6 @@ 1.32 1.33 </sect2> 1.34 <sect2> 1.35 - <title><command 1.36 - role="hg-ext-mq">qrestore</command>&emdash;restore saved 1.37 - queue state</title> 1.38 - 1.39 - <para id="x_628">XXX No idea what this does.</para> 1.40 - 1.41 - </sect2> 1.42 - <sect2> 1.43 - <title><command role="hg-ext-mq">qsave</command>&emdash;save 1.44 - current queue state</title> 1.45 - 1.46 - <para id="x_629">XXX Likewise.</para> 1.47 - 1.48 - </sect2> 1.49 - <sect2> 1.50 <title><command role="hg-ext-mq">qseries</command>&emdash;print 1.51 the entire patch series</title> 1.52 1.53 @@ -501,9 +496,7 @@ 1.54 changesets in the backup bundle.</para> 1.55 </listitem> 1.56 <listitem><para id="x_631"><option role="hg-opt-strip">-f</option>: If a 1.57 - branch has multiple heads, remove all heads. XXX This 1.58 - should be renamed, and use <literal>-f</literal> to strip 1.59 - revs when there are pending changes.</para> 1.60 + branch has multiple heads, remove all heads.</para> 1.61 </listitem> 1.62 <listitem><para id="x_632"><option role="hg-opt-strip">-n</option>: Do 1.63 not save a backup bundle.</para>
2.1 --- a/en/ch02-tour-merge.xml Sun May 03 20:27:28 2009 -0700 2.2 +++ b/en/ch02-tour-merge.xml Mon May 04 23:52:38 2009 -0700 2.3 @@ -146,6 +146,7 @@ 2.4 2.5 &interaction.tour.merge.parents; 2.6 </sect2> 2.7 + 2.8 <sect2> 2.9 <title>Committing the results of the merge</title> 2.10 2.11 @@ -292,8 +293,8 @@ 2.12 strengths and weaknesses. Most are tuned for merging files 2.13 containing plain text, while a few are aimed at specialised 2.14 file formats (generally XML).</para> 2.15 - 2.16 </sect2> 2.17 + 2.18 <sect2> 2.19 <title>A worked example</title> 2.20 2.21 @@ -365,6 +366,7 @@ 2.22 </note> 2.23 </sect2> 2.24 </sect1> 2.25 + 2.26 <sect1 id="sec:tour-merge:fetch"> 2.27 <title>Simplifying the pull-merge-commit sequence</title> 2.28 2.29 @@ -421,7 +423,27 @@ 2.30 the extension, but since the <literal 2.31 role="hg-ext">fetch</literal> extension is in the standard 2.32 distribution, Mercurial knows where to search for it.)</para> 2.33 - 2.34 + </sect1> 2.35 + 2.36 + <sect1> 2.37 + <title>Renaming, copying, and merging</title> 2.38 + 2.39 + <para>During the life of a project, we will often want to change 2.40 + the layout of its files and directories. This can be as simple 2.41 + as renaming a single file, or as complex as restructuring the 2.42 + entire hierarchy of files within the project.</para> 2.43 + 2.44 + <para>Mercurial supports these kinds of complex changes fluently, 2.45 + provided we tell it what we're doing. If we want to rename a 2.46 + file, we should use the <command>hg rename</command><footnote> 2.47 + <para>If you're a Unix user, you'll be glad to know that the 2.48 + <command>hg rename</command> command can be abbreviated as 2.49 + <command>hg mv</command>.</para> 2.50 + </footnote> command to rename it, so that Mercurial can do the 2.51 + right thing later when we merge.</para> 2.52 + 2.53 + <para>We will cover the use of these commands in more detail in 2.54 + <xref linkend="chap:daily.copy"/>.</para> 2.55 </sect1> 2.56 </chapter> 2.57
3.1 --- a/en/ch03-concepts.xml Sun May 03 20:27:28 2009 -0700 3.2 +++ b/en/ch03-concepts.xml Mon May 04 23:52:38 2009 -0700 3.3 @@ -112,12 +112,15 @@ 3.4 <para id="x_2f3">As the illustration shows, there is 3.5 <emphasis>not</emphasis> a <quote>one to one</quote> 3.6 relationship between revisions in the changelog, manifest, or 3.7 - filelog. If the manifest hasn't changed between two 3.8 - changesets, the changelog entries for those changesets will 3.9 - point to the same revision of the manifest. If a file that 3.10 + filelog. If a file that 3.11 Mercurial tracks hasn't changed between two changesets, the 3.12 entry for that file in the two revisions of the manifest will 3.13 - point to the same revision of its filelog.</para> 3.14 + point to the same revision of its filelog<footnote> 3.15 + <para>It is possible (though unusual) for the manifest to 3.16 + remain the same between two changesets, in which case the 3.17 + changelog entries for those changesets will point to the 3.18 + same revision of the manifest.</para> 3.19 + </footnote>.</para> 3.20 3.21 </sect2> 3.22 </sect1> 3.23 @@ -175,16 +178,18 @@ 3.24 <sect2> 3.25 <title>Fast retrieval</title> 3.26 3.27 - <para id="x_2fa">Mercurial cleverly avoids a pitfall common to all earlier 3.28 - revision control systems: the problem of <emphasis>inefficient 3.29 - retrieval</emphasis>. Most revision control systems store 3.30 - the contents of a revision as an incremental series of 3.31 - modifications against a <quote>snapshot</quote>. To 3.32 - reconstruct a specific revision, you must first read the 3.33 - snapshot, and then every one of the revisions between the 3.34 - snapshot and your target revision. The more history that a 3.35 - file accumulates, the more revisions you must read, hence the 3.36 - longer it takes to reconstruct a particular revision.</para> 3.37 + <para id="x_2fa">Mercurial cleverly avoids a pitfall common to 3.38 + all earlier revision control systems: the problem of 3.39 + <emphasis>inefficient retrieval</emphasis>. Most revision 3.40 + control systems store the contents of a revision as an 3.41 + incremental series of modifications against a 3.42 + <quote>snapshot</quote>. (Some base the snapshot on the 3.43 + oldest revision, others on the newest.) To reconstruct a 3.44 + specific revision, you must first read the snapshot, and then 3.45 + every one of the revisions between the snapshot and your 3.46 + target revision. The more history that a file accumulates, 3.47 + the more revisions you must read, hence the longer it takes to 3.48 + reconstruct a particular revision.</para> 3.49 3.50 <figure id="fig:concepts:snapshot"> 3.51 <title>Snapshot of a revlog, with incremental deltas</title> 3.52 @@ -211,25 +216,15 @@ 3.53 <sect3> 3.54 <title>Aside: the influence of video compression</title> 3.55 3.56 - <para id="x_2fe">If you're familiar with video compression or have ever 3.57 - watched a TV feed through a digital cable or satellite 3.58 - service, you may know that most video compression schemes 3.59 - store each frame of video as a delta against its predecessor 3.60 - frame. In addition, these schemes use <quote>lossy</quote> 3.61 - compression techniques to increase the compression ratio, so 3.62 - visual errors accumulate over the course of a number of 3.63 - inter-frame deltas.</para> 3.64 - 3.65 - <para id="x_2ff">Because it's possible for a video stream to <quote>drop 3.66 - out</quote> occasionally due to signal glitches, and to 3.67 - limit the accumulation of artefacts introduced by the lossy 3.68 - compression process, video encoders periodically insert a 3.69 - complete frame (called a <quote>key frame</quote>) into the 3.70 - video stream; the next delta is generated against that 3.71 - frame. This means that if the video signal gets 3.72 - interrupted, it will resume once the next key frame is 3.73 - received. Also, the accumulation of encoding errors 3.74 - restarts anew with each key frame.</para> 3.75 + <para id="x_2fe">If you're familiar with video compression or 3.76 + have ever watched a TV feed through a digital cable or 3.77 + satellite service, you may know that most video compression 3.78 + schemes store each frame of video as a delta against its 3.79 + predecessor frame.</para> 3.80 + 3.81 + <para id="x_2ff">Mercurial borrows this idea to make it 3.82 + possible to reconstruct a revision from a snapshot and a 3.83 + small number of deltas.</para> 3.84 3.85 </sect3> 3.86 </sect2> 3.87 @@ -261,9 +256,9 @@ 3.88 uncorrupted sections of the revlog, both before and after the 3.89 corrupted section. This would not be possible with a 3.90 delta-only storage model.</para> 3.91 - 3.92 </sect2> 3.93 </sect1> 3.94 + 3.95 <sect1> 3.96 <title>Revision history, branching, and merging</title> 3.97 3.98 @@ -314,11 +309,15 @@ 3.99 those files, with the same contents it had when the changeset 3.100 was committed.</para> 3.101 3.102 - <para id="x_309">The <emphasis>dirstate</emphasis> contains Mercurial's 3.103 - knowledge of the working directory. This details which 3.104 - changeset the working directory is updated to, and all of the 3.105 - files that Mercurial is tracking in the working 3.106 - directory.</para> 3.107 + <para id="x_309">The <emphasis>dirstate</emphasis> is a special 3.108 + structure that contains Mercurial's knowledge of the working 3.109 + directory. It is maintained as a file named 3.110 + <filename>.hg/dirstate</filename> inside a repository. The 3.111 + dirstate details which changeset the working directory is 3.112 + updated to, and all of the files that Mercurial is tracking in 3.113 + the working directory. It also lets Mercurial quickly notice 3.114 + changed files, by recording their checkout times and 3.115 + sizes.</para> 3.116 3.117 <para id="x_30a">Just as a revision of a revlog has room for two parents, so 3.118 that it can represent either a normal revision (with one parent) 3.119 @@ -426,9 +425,9 @@ 3.120 </figure> 3.121 3.122 <note> 3.123 - <para id="x_315"> If you're new to Mercurial, you should keep in mind a 3.124 - common <quote>error</quote>, which is to use the <command 3.125 - role="hg-cmd">hg pull</command> command without any 3.126 + <para id="x_315">If you're new to Mercurial, you should keep 3.127 + in mind a common <quote>error</quote>, which is to use the 3.128 + <command role="hg-cmd">hg pull</command> command without any 3.129 options. By default, the <command role="hg-cmd">hg 3.130 pull</command> command <emphasis>does not</emphasis> 3.131 update the working directory, so you'll bring new changesets 3.132 @@ -436,16 +435,19 @@ 3.133 synced at the same changeset as before the pull. If you 3.134 make some changes and commit afterwards, you'll thus create 3.135 a new head, because your working directory isn't synced to 3.136 - whatever the current tip is.</para> 3.137 - 3.138 - <para id="x_316"> I put the word <quote>error</quote> in 3.139 - quotes because all that you need to do to rectify this 3.140 - situation is <command role="hg-cmd">hg merge</command>, then 3.141 - <command role="hg-cmd">hg commit</command>. In other words, 3.142 - this almost never has negative consequences; it's just 3.143 - something of a surprise for newcomers. I'll discuss other 3.144 - ways to avoid this behavior, and why Mercurial behaves in 3.145 - this initially surprising way, later on.</para> 3.146 + whatever the current tip is. To combine the operation of a 3.147 + pull, followed by an update, run <command>hg pull 3.148 + -u</command>.</para> 3.149 + 3.150 + <para id="x_316">I put the word <quote>error</quote> in quotes 3.151 + because all that you need to do to rectify the situation 3.152 + where you created a new head by accident is 3.153 + <command role="hg-cmd">hg merge</command>, then <command 3.154 + role="hg-cmd">hg commit</command>. In other words, this 3.155 + almost never has negative consequences; it's just something 3.156 + of a surprise for newcomers. I'll discuss other ways to 3.157 + avoid this behavior, and why Mercurial behaves in this 3.158 + initially surprising way, later on.</para> 3.159 </note> 3.160 3.161 </sect2> 3.162 @@ -511,13 +513,15 @@ 3.163 working directory has two parents; these will become the 3.164 parents of the new changeset.</para> 3.165 3.166 - <para id="x_322">Mercurial lets you perform multiple merges, but you must 3.167 - commit the results of each individual merge as you go. This 3.168 - is necessary because Mercurial only tracks two parents for 3.169 - both revisions and the working directory. While it would be 3.170 - technically possible to merge multiple changesets at once, the 3.171 - prospect of user confusion and making a terrible mess of a 3.172 - merge immediately becomes overwhelming.</para> 3.173 + <para id="x_322">Mercurial lets you perform multiple merges, but 3.174 + you must commit the results of each individual merge as you 3.175 + go. This is necessary because Mercurial only tracks two 3.176 + parents for both revisions and the working directory. While 3.177 + it would be technically feasible to merge multiple changesets 3.178 + at once, Mercurial avoids this for simplicity. With multi-way 3.179 + merges, the risks of user confusion, nasty conflict 3.180 + resolution, and making a terrible mess of a merge would grow 3.181 + intolerable.</para> 3.182 3.183 </sect2> 3.184 3.185 @@ -598,10 +602,17 @@ 3.186 transferred, yielding better network performance over most 3.187 kinds of network.</para> 3.188 3.189 - <para id="x_329">(If the connection is over <command>ssh</command>, 3.190 - Mercurial <emphasis>doesn't</emphasis> recompress the 3.191 - stream, because <command>ssh</command> can already do this 3.192 - itself.)</para> 3.193 + <para id="x_329">If the connection is over 3.194 + <command>ssh</command>, Mercurial 3.195 + <emphasis>doesn't</emphasis> recompress the stream, because 3.196 + <command>ssh</command> can already do this itself. You can 3.197 + tell Mercurial to always use <command>ssh</command>'s 3.198 + compression feature by editing the 3.199 + <filename>.hgrc</filename> file in your home directory as 3.200 + follows.</para> 3.201 + 3.202 + <programlisting>[ui] 3.203 +ssh = ssh -C</programlisting> 3.204 3.205 </sect3> 3.206 </sect2> 3.207 @@ -611,9 +622,8 @@ 3.208 <para id="x_32a">Appending to files isn't the whole story when 3.209 it comes to guaranteeing that a reader won't see a partial 3.210 write. If you recall <xref linkend="fig:concepts:metadata"/>, 3.211 - revisions in 3.212 - the changelog point to revisions in the manifest, and 3.213 - revisions in the manifest point to revisions in filelogs. 3.214 + revisions in the changelog point to revisions in the manifest, 3.215 + and revisions in the manifest point to revisions in filelogs. 3.216 This hierarchy is deliberate.</para> 3.217 3.218 <para id="x_32b">A writer starts a transaction by writing filelog and 3.219 @@ -637,7 +647,7 @@ 3.220 being written to while the read is occurring. This has a big 3.221 effect on scalability; you can have an arbitrary number of 3.222 Mercurial processes safely reading data from a repository 3.223 - safely all at once, no matter whether it's being written to or 3.224 + all at once, no matter whether it's being written to or 3.225 not.</para> 3.226 3.227 <para id="x_32e">The lockless nature of reading means that if you're 3.228 @@ -709,8 +719,8 @@ 3.229 storage is cheap, and this method gives the highest 3.230 performance while deferring most book-keeping to the operating 3.231 system. An alternative scheme would most likely reduce 3.232 - performance and increase the complexity of the software, each 3.233 - of which is much more important to the <quote>feel</quote> of 3.234 + performance and increase the complexity of the software, but 3.235 + speed and simplicity are key to the <quote>feel</quote> of 3.236 day-to-day use.</para> 3.237 3.238 </sect2> 3.239 @@ -731,18 +741,32 @@ 3.240 dirstate so that it knows what to do with those files when you 3.241 commit.</para> 3.242 3.243 - <para id="x_337">When Mercurial is checking the states of files in the 3.244 - working directory, it first checks a file's modification time. 3.245 - If that has not changed, the file must not have been modified. 3.246 - If the file's size has changed, the file must have been 3.247 - modified. If the modification time has changed, but the size 3.248 - has not, only then does Mercurial need to read the actual 3.249 - contents of the file to see if they've changed. Storing these 3.250 - few extra pieces of information dramatically reduces the 3.251 - amount of data that Mercurial needs to read, which yields 3.252 - large performance improvements compared to other revision 3.253 - control systems.</para> 3.254 - 3.255 + <para id="x_337">The dirstate helps Mercurial to efficiently 3.256 + check the status of files in a repository.</para> 3.257 + 3.258 + <itemizedlist> 3.259 + <listitem> 3.260 + <para>When Mercurial checks the state of a file in the 3.261 + working directory, it first checks a file's modification 3.262 + time against the time in the dirstate that records when 3.263 + Mercurial last wrote the file. If the last modified time 3.264 + is the same as the time when Mercurial wrote the file, the 3.265 + file must not have been modified, so Mercurial does not 3.266 + need to check any further.</para> 3.267 + </listitem> 3.268 + <listitem> 3.269 + <para>If the file's size has changed, the file must have 3.270 + been modified. If the modification time has changed, but 3.271 + the size has not, only then does Mercurial need to 3.272 + actually read the contents of the file to see if it has 3.273 + changed.</para> 3.274 + </listitem> 3.275 + </itemizedlist> 3.276 + 3.277 + <para>Storing the modification time and size dramatically 3.278 + reduces the number of read operations that Mercurial needs to 3.279 + perform when we run commands like <command>hg status</command>. 3.280 + This results in large performance improvements.</para> 3.281 </sect2> 3.282 </sect1> 3.283 </chapter>
4.1 --- a/en/ch04-daily.xml Sun May 03 20:27:28 2009 -0700 4.2 +++ b/en/ch04-daily.xml Mon May 04 23:52:38 2009 -0700 4.3 @@ -108,10 +108,11 @@ 4.4 <sect1> 4.5 <title>How to stop tracking a file</title> 4.6 4.7 - <para id="x_1af">Once you decide that a file no longer belongs in your 4.8 - repository, use the <command role="hg-cmd">hg remove</command> 4.9 - command. This deletes the file, and tells Mercurial to stop 4.10 - tracking it. A removed file is represented in the output of 4.11 + <para id="x_1af">Once you decide that a file no longer belongs in 4.12 + your repository, use the <command role="hg-cmd">hg 4.13 + remove</command> command. This deletes the file, and tells 4.14 + Mercurial to stop tracking it (which will occur at the next 4.15 + commit). A removed file is represented in the output of 4.16 <command role="hg-cmd">hg status</command> with a 4.17 <quote><literal>R</literal></quote>.</para> 4.18 4.19 @@ -214,7 +215,7 @@ 4.20 </sect2> 4.21 </sect1> 4.22 4.23 - <sect1> 4.24 + <sect1 id="chap:daily.copy"> 4.25 <title>Copying files</title> 4.26 4.27 <para id="x_1bc">Mercurial provides a <command role="hg-cmd">hg 4.28 @@ -535,11 +536,12 @@ 4.29 <command role="hg-cmd">hg revert</command> to get rid of 4.30 erroneous changes to a file.</para> 4.31 4.32 - <para id="x_1e4">It's good to remember that the <command role="hg-cmd">hg 4.33 - revert</command> command is useful for changes that you have 4.34 - not yet committed. Once you've committed a change, if you 4.35 - decide it was a mistake, you can still do something about it, 4.36 - though your options may be more limited.</para> 4.37 + <para id="x_1e4">It is helpful to remember that the <command 4.38 + role="hg-cmd">hg revert</command> command is useful for 4.39 + changes that you have not yet committed. Once you've committed 4.40 + a change, if you decide it was a mistake, you can still do 4.41 + something about it, though your options may be more 4.42 + limited.</para> 4.43 4.44 <para id="x_1e5">For more information about the <command 4.45 role="hg-cmd">hg revert</command> command, and details about 4.46 @@ -817,7 +819,7 @@ 4.47 4.48 <para id="x_6d9">If you perform traditional backups of your master 4.49 repositories to tape or disk, and you want to back up a 4.50 - repository named <filename>myrepo</filename>. Use <command>hg 4.51 + repository named <filename>myrepo</filename>, use <command>hg 4.52 clone -U myrepo myrepo.bak</command> to create a 4.53 clone of <filename>myrepo</filename> before you start your 4.54 backups. The <option>-U</option> option doesn't check out a
5.1 --- a/en/ch05-collab.xml Sun May 03 20:27:28 2009 -0700 5.2 +++ b/en/ch05-collab.xml Mon May 04 23:52:38 2009 -0700 5.3 @@ -55,18 +55,12 @@ 5.4 linkend="sec:collab:serve"/> below for details of how to use 5.5 this command.</para> 5.6 5.7 - <para id="x_69e">For longer-lived repositories that you'd like to have 5.8 - permanently available, there are several public hosting services 5.9 - available.</para> 5.10 - 5.11 - <itemizedlist> 5.12 - <listitem> 5.13 - <para id="x_69f">Bitbucket, at <ulink 5.14 - url="http://bitbucket.org/">http://bitbucket.org/</ulink>, 5.15 - provides free hosting for open source projects, and paid 5.16 - hosting for commercial projects.</para> 5.17 - </listitem> 5.18 - </itemizedlist> 5.19 + <para id="x_69e">For longer-lived repositories that you'd like to 5.20 + have permanently available, there are several public hosting 5.21 + services available. Some are free to open source projects, 5.22 + while others offer paid commercial hosting. An up-to-date list 5.23 + is available at <ulink 5.24 + url="http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting">http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting</ulink>.</para> 5.25 5.26 <para id="x_6a0">If you would prefer to host your own repositories, Mercurial 5.27 has built-in support for several popular hosting technologies, 5.28 @@ -827,7 +821,7 @@ 5.29 so that they only print output if they're run interactively. 5.30 Otherwise these banners will at least clutter up Mercurial's 5.31 output. Worse, they could potentially cause problems with 5.32 - running Mercurial commands remotely. Mercurial makes tries to 5.33 + running Mercurial commands remotely. Mercurial tries to 5.34 detect and ignore banners in non-interactive 5.35 <command>ssh</command> sessions, but it is not foolproof. (If 5.36 you're editing your login scripts on your server, the usual 5.37 @@ -1107,7 +1101,7 @@ 5.38 directions inside it to correctly set your 5.39 <envar>PYTHONPATH</envar> environment variable.</para> 5.40 5.41 - <para id="x_4cf">Finally, you are <emphasis>certain</emphasis> to by 5.42 + <para id="x_4cf">Finally, you are <emphasis>certain</emphasis> to be 5.43 served with another colourful Python backtrace: this one 5.44 will complain that it can't find <filename 5.45 class="directory">/path/to/repository</filename>. Edit
6.1 --- a/en/ch06-filenames.xml Sun May 03 20:27:28 2009 -0700 6.2 +++ b/en/ch06-filenames.xml Mon May 04 23:52:38 2009 -0700 6.3 @@ -358,10 +358,11 @@ 6.4 interchangeable is also referred to as <emphasis>case 6.5 folding</emphasis>.</para> 6.6 </listitem> 6.7 - <listitem><para id="x_56e">Case sensitive. The case of a name is 6.8 - significant at all times. The names <filename>foo</filename> 6.9 - and {FoO} identify different files. This is the way Linux 6.10 - and Unix systems normally work.</para> 6.11 + <listitem><para id="x_56e">Case sensitive. The case of a name 6.12 + is significant at all times. The names 6.13 + <filename>foo</filename> and <filename>FoO</filename> 6.14 + identify different files. This is the way Linux and Unix 6.15 + systems normally work.</para> 6.16 </listitem></itemizedlist> 6.17 6.18 <para id="x_56f">On Unix-like systems, it is possible to have any or all of
7.1 --- a/en/ch07-branch.xml Sun May 03 20:27:28 2009 -0700 7.2 +++ b/en/ch07-branch.xml Mon May 04 23:52:38 2009 -0700 7.3 @@ -183,15 +183,15 @@ 7.4 after the revision you specified. This has an interaction 7.5 with tags that can surprise the unwary.</para> 7.6 7.7 - <para id="x_381">Recall that a tag is stored as a revision to the <filename 7.8 - role="special">.hgtags</filename> file, so that when you 7.9 - create a tag, the changeset in which it's recorded necessarily 7.10 - refers to an older changeset. When you run <command 7.11 - role="hg-cmd">hg clone -r foo</command> to clone a 7.12 - repository as of tag <literal>foo</literal>, the new clone 7.13 - <emphasis>will not contain the history that created the 7.14 - tag</emphasis> that you used to clone the repository. The 7.15 - result is that you'll get exactly the right subset of the 7.16 + <para id="x_381">Recall that a tag is stored as a revision to 7.17 + the <filename role="special">.hgtags</filename> file. When you 7.18 + create a tag, the changeset in which its recorded refers to an 7.19 + older changeset. When you run <command role="hg-cmd">hg clone 7.20 + -r foo</command> to clone a repository as of tag 7.21 + <literal>foo</literal>, the new clone <emphasis>will not 7.22 + contain any revision newer than the one the tag refers to, 7.23 + including the revision where the tag was created</emphasis>. 7.24 + The result is that you'll get exactly the right subset of the 7.25 project's history in the new repository, but 7.26 <emphasis>not</emphasis> the tag you might have 7.27 expected.</para> 7.28 @@ -227,9 +227,10 @@ 7.29 <sect1> 7.30 <title>The flow of changes&emdash;big picture vs. little</title> 7.31 7.32 - <para id="x_384">To return to the outline I sketched at the beginning of a 7.33 - chapter, let's think about a project that has multiple 7.34 - concurrent pieces of work under development at once.</para> 7.35 + <para id="x_384">To return to the outline I sketched at the 7.36 + beginning of the chapter, let's think about a project that has 7.37 + multiple concurrent pieces of work under development at 7.38 + once.</para> 7.39 7.40 <para id="x_385">There might be a push for a new <quote>main</quote> release; 7.41 a new minor bugfix release to the last main release; and an 7.42 @@ -416,7 +417,7 @@ 7.43 7.44 <para id="x_39e">If you have more than one named branch in a repository, 7.45 Mercurial will remember the branch that your working directory 7.46 - on when you start a command like <command role="hg-cmd">hg 7.47 + is on when you start a command like <command role="hg-cmd">hg 7.48 update</command> or <command role="hg-cmd">hg pull 7.49 -u</command>. It will update the working directory to the tip 7.50 of this branch, no matter what the <quote>repo-wide</quote> tip
8.1 --- a/en/ch09-hook.xml Sun May 03 20:27:28 2009 -0700 8.2 +++ b/en/ch09-hook.xml Mon May 04 23:52:38 2009 -0700 8.3 @@ -21,6 +21,12 @@ 8.4 supports. We will revisit each of these hooks in more detail 8.5 later, in <xref linkend="sec:hook:ref"/>.</para> 8.6 8.7 + <para id="x_1f6">Each of the hooks whose description begins with the word 8.8 + <quote>Controlling</quote> has the ability to determine whether 8.9 + an activity can proceed. If the hook succeeds, the activity may 8.10 + proceed; if it fails, the activity is either not permitted or 8.11 + undone, depending on the hook.</para> 8.12 + 8.13 <itemizedlist> 8.14 <listitem><para id="x_1e9"><literal role="hook">changegroup</literal>: This 8.15 is run after a group of changesets has been brought into the 8.16 @@ -87,12 +93,6 @@ 8.17 finished. 8.18 </para> 8.19 </listitem></itemizedlist> 8.20 - <para id="x_1f6">Each of the hooks whose description begins with the word 8.21 - <quote>Controlling</quote> has the ability to determine whether 8.22 - an activity can proceed. If the hook succeeds, the activity may 8.23 - proceed; if it fails, the activity is either not permitted or 8.24 - undone, depending on the hook. 8.25 - </para> 8.26 8.27 </sect1> 8.28 <sect1> 8.29 @@ -139,11 +139,11 @@ 8.30 </para> 8.31 </note> 8.32 8.33 - <para id="x_1fb">XXX To see what hooks are defined in a repository, use the 8.34 - <command role="hg-cmd">hg config hooks</command> command. If 8.35 - you are working in one repository, but talking to another that 8.36 - you do not own (e.g. using <command role="hg-cmd">hg 8.37 - pull</command> or <command role="hg-cmd">hg 8.38 + <para id="x_1fb">To see what hooks are defined in a repository, 8.39 + use the <command role="hg-cmd">hg showconfig hooks</command> 8.40 + command. If you are working in one repository, but talking to 8.41 + another that you do not own (e.g. using <command 8.42 + role="hg-cmd">hg pull</command> or <command role="hg-cmd">hg 8.43 incoming</command>), remember that it is the other 8.44 repository's hooks you should be checking, not your own. 8.45 </para> 8.46 @@ -585,11 +585,11 @@ 8.47 8.48 &interaction.ch09-hook.ws.better; 8.49 8.50 - <para id="x_237">As a final aside, note in the example above the use of 8.51 - <command>perl</command>'s in-place editing feature to get rid 8.52 - of trailing whitespace from a file. This is concise and 8.53 - useful enough that I will reproduce it here. 8.54 - </para> 8.55 + <para id="x_237">As a final aside, note in the example above the 8.56 + use of <command>sed</command>'s in-place editing feature to 8.57 + get rid of trailing whitespace from a file. This is concise 8.58 + and useful enough that I will reproduce it here (using 8.59 + <command>perl</command> for good measure).</para> 8.60 <programlisting>perl -pi -e 's,\s+$,,' filename</programlisting> 8.61 8.62 </sect2> 8.63 @@ -817,10 +817,7 @@ 8.64 role="rc-item-bugzilla">version</envar>: The version 8.65 of Bugzilla installed on the server. The database 8.66 schema that Bugzilla uses changes occasionally, so this 8.67 - hook has to know exactly which schema to use. At the 8.68 - moment, the only version supported is 8.69 - <literal>2.16</literal>. 8.70 - </para> 8.71 + hook has to know exactly which schema to use.</para> 8.72 </listitem> 8.73 <listitem><para id="x_253"><envar role="rc-item-bugzilla">host</envar>: 8.74 The hostname of the MySQL server that stores your
9.1 --- a/en/examples/auto-snippets.xml Sun May 03 20:27:28 2009 -0700 9.2 +++ b/en/examples/auto-snippets.xml Mon May 04 23:52:38 2009 -0700 9.3 @@ -57,6 +57,15 @@ 9.4 <!ENTITY interaction.ch01-new.init SYSTEM "results/ch01-new.init.lxo"> 9.5 <!ENTITY interaction.ch01-new.ls SYSTEM "results/ch01-new.ls.lxo"> 9.6 <!ENTITY interaction.ch01-new.ls2 SYSTEM "results/ch01-new.ls2.lxo"> 9.7 +<!ENTITY interaction.ch02-rename.alice SYSTEM "results/ch02-rename.alice.lxo"> 9.8 +<!ENTITY interaction.ch02-rename.bob SYSTEM "results/ch02-rename.bob.lxo"> 9.9 +<!ENTITY interaction.ch02-rename.clone SYSTEM "results/ch02-rename.clone.lxo"> 9.10 +<!ENTITY interaction.ch02-rename.clone2 SYSTEM "results/ch02-rename.clone2.lxo"> 9.11 +<!ENTITY interaction.ch02-rename.init SYSTEM "results/ch02-rename.init.lxo"> 9.12 +<!ENTITY interaction.ch02-rename.merge SYSTEM "results/ch02-rename.merge.lxo"> 9.13 +<!ENTITY interaction.ch02-rename.merge2 SYSTEM "results/ch02-rename.merge2.lxo"> 9.14 +<!ENTITY interaction.ch02-rename.status SYSTEM "results/ch02-rename.status.lxo"> 9.15 +<!ENTITY interaction.ch02-rename.status2 SYSTEM "results/ch02-rename.status2.lxo"> 9.16 <!ENTITY interaction.ch04-diff.chmod SYSTEM "results/ch04-diff.chmod.lxo"> 9.17 <!ENTITY interaction.ch04-diff.chmod.git SYSTEM "results/ch04-diff.chmod.git.lxo"> 9.18 <!ENTITY interaction.ch04-diff.rename.basic SYSTEM "results/ch04-diff.rename.basic.lxo"> 9.19 @@ -88,6 +97,19 @@ 9.20 <!ENTITY interaction.daily.copy.dir-src-dest SYSTEM "results/daily.copy.dir-src-dest.lxo"> 9.21 <!ENTITY interaction.daily.copy.init SYSTEM "results/daily.copy.init.lxo"> 9.22 <!ENTITY interaction.daily.copy.merge SYSTEM "results/daily.copy.merge.lxo"> 9.23 +<!ENTITY interaction.daily.copy.orig.after SYSTEM "results/daily.copy.orig.after.lxo"> 9.24 +<!ENTITY interaction.daily.copy.orig.cat SYSTEM "results/daily.copy.orig.cat.lxo"> 9.25 +<!ENTITY interaction.daily.copy.orig.clone SYSTEM "results/daily.copy.orig.clone.lxo"> 9.26 +<!ENTITY interaction.daily.copy.orig.copy SYSTEM "results/daily.copy.orig.copy.lxo"> 9.27 +<!ENTITY interaction.daily.copy.orig.dir-dest SYSTEM "results/daily.copy.orig.dir-dest.lxo"> 9.28 +<!ENTITY interaction.daily.copy.orig.dir-src SYSTEM "results/daily.copy.orig.dir-src.lxo"> 9.29 +<!ENTITY interaction.daily.copy.orig.dir-src-dest SYSTEM "results/daily.copy.orig.dir-src-dest.lxo"> 9.30 +<!ENTITY interaction.daily.copy.orig.init SYSTEM "results/daily.copy.orig.init.lxo"> 9.31 +<!ENTITY interaction.daily.copy.orig.merge SYSTEM "results/daily.copy.orig.merge.lxo"> 9.32 +<!ENTITY interaction.daily.copy.orig.other SYSTEM "results/daily.copy.orig.other.lxo"> 9.33 +<!ENTITY interaction.daily.copy.orig.simple SYSTEM "results/daily.copy.orig.simple.lxo"> 9.34 +<!ENTITY interaction.daily.copy.orig.status SYSTEM "results/daily.copy.orig.status.lxo"> 9.35 +<!ENTITY interaction.daily.copy.orig.status-copy SYSTEM "results/daily.copy.orig.status-copy.lxo"> 9.36 <!ENTITY interaction.daily.copy.other SYSTEM "results/daily.copy.other.lxo"> 9.37 <!ENTITY interaction.daily.copy.simple SYSTEM "results/daily.copy.simple.lxo"> 9.38 <!ENTITY interaction.daily.copy.status SYSTEM "results/daily.copy.status.lxo">
10.1 --- a/en/examples/daily.copy Sun May 03 20:27:28 2009 -0700 10.2 +++ b/en/examples/daily.copy Mon May 04 23:52:38 2009 -0700 10.3 @@ -51,9 +51,9 @@ 10.4 cd copy-example 10.5 echo a > a 10.6 echo b > b 10.7 -mkdir c 10.8 -mkdir c/a 10.9 -echo c > c/a/c 10.10 +mkdir z 10.11 +mkdir z/a 10.12 +echo c > z/a/c 10.13 hg ci -Ama 10.14 10.15 #$ name: simple 10.16 @@ -70,13 +70,13 @@ 10.17 10.18 #$ name: dir-src 10.19 10.20 -hg copy c e 10.21 +hg copy z e 10.22 10.23 #$ name: dir-src-dest 10.24 10.25 -hg copy c d 10.26 +hg copy z d 10.27 10.28 #$ name: after 10.29 10.30 -cp a z 10.31 -hg copy --after a z 10.32 +cp a n 10.33 +hg copy --after a n
11.1 --- a/en/examples/tour Sun May 03 20:27:28 2009 -0700 11.2 +++ b/en/examples/tour Mon May 04 23:52:38 2009 -0700 11.3 @@ -151,13 +151,18 @@ 11.4 cp hello.c ../new-hello.c 11.5 sed -i '/printf("hello,/i\\tprintf("once more, hello.\\n");' ../new-hello.c 11.6 11.7 +my-text-editor() 11.8 +{ 11.9 +cp ../new-hello.c hello.c 11.10 +} 11.11 + 11.12 #$ name: merge.clone 11.13 11.14 cd .. 11.15 hg clone hello my-new-hello 11.16 cd my-new-hello 11.17 -# The file new-hello.c is lightly edited. 11.18 -cp ../new-hello.c hello.c 11.19 +# Make some simple edits to hello.c. 11.20 +my-text-editor hello.c 11.21 hg commit -m 'A new hello for a new day.' 11.22 11.23 #$ name: merge.dummy2