1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/fr/ch05-daily.xml	Tue Sep 01 17:00:12 2009 +0200
     1.3 @@ -0,0 +1,474 @@
     1.4 +<!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
     1.5 +
     1.6 +<chapter>
     1.7 +<title>Mercurial in daily use</title>
     1.8 +<para>\label{chap:daily}</para>
     1.9 +
    1.10 +<sect1>
    1.11 +<title>Telling Mercurial which files to track</title>
    1.12 +
    1.13 +<para>Mercurial does not work with files in your repository unless you tell
    1.14 +it to manage them.  The <command role="hg-cmd">hg status</command> command will tell you which
    1.15 +files Mercurial doesn't know about; it uses a <quote><literal>?</literal></quote> to
    1.16 +display such files.</para>
    1.17 +
    1.18 +<para>To tell Mercurial to track a file, use the <command role="hg-cmd">hg add</command> command.  Once
    1.19 +you have added a file, the entry in the output of <command role="hg-cmd">hg status</command> for
    1.20 +that file changes from <quote><literal>?</literal></quote> to <quote><literal>A</literal></quote>.
    1.21 +<!-- &interaction.daily.files.add; --></para>
    1.22 +
    1.23 +<para>After you run a <command role="hg-cmd">hg commit</command>, the files that you added before the
    1.24 +commit will no longer be listed in the output of <command role="hg-cmd">hg status</command>.  The
    1.25 +reason for this is that <command role="hg-cmd">hg status</command> only tells you about
    1.26 +<quote>interesting</quote> files&emdash;those that you have modified or told Mercurial
    1.27 +to do something with&emdash;by default.  If you have a repository that
    1.28 +contains thousands of files, you will rarely want to know about files
    1.29 +that Mercurial is tracking, but that have not changed.  (You can still
    1.30 +get this information; we'll return to this later.)</para>
    1.31 +
    1.32 +<para>Once you add a file, Mercurial doesn't do anything with it
    1.33 +immediately.  Instead, it will take a snapshot of the file's state the
    1.34 +next time you perform a commit.  It will then continue to track the
    1.35 +changes you make to the file every time you commit, until you remove
    1.36 +the file.</para>
    1.37 +
    1.38 +<sect2>
    1.39 +<title>Explicit versus implicit file naming</title>
    1.40 +
    1.41 +<para>A useful behaviour that Mercurial has is that if you pass the name of
    1.42 +a directory to a command, every Mercurial command will treat this as
    1.43 +<quote>I want to operate on every file in this directory and its
    1.44 +subdirectories</quote>.
    1.45 +<!-- &interaction.daily.files.add-dir; -->
    1.46 +Notice in this example that Mercurial printed the names of the files
    1.47 +it added, whereas it didn't do so when we added the file named
    1.48 +<filename>a</filename> in the earlier example.</para>
    1.49 +
    1.50 +<para>What's going on is that in the former case, we explicitly named the
    1.51 +file to add on the command line, so the assumption that Mercurial
    1.52 +makes in such cases is that you know what you were doing, and it
    1.53 +doesn't print any output.</para>
    1.54 +
    1.55 +<para>However, when we <emphasis>imply</emphasis> the names of files by giving the name of
    1.56 +a directory, Mercurial takes the extra step of printing the name of
    1.57 +each file that it does something with.  This makes it more clear what
    1.58 +is happening, and reduces the likelihood of a silent and nasty
    1.59 +surprise.  This behaviour is common to most Mercurial commands.</para>
    1.60 +
    1.61 +</sect2>
    1.62 +<sect2>
    1.63 +<title>Aside: Mercurial tracks files, not directories</title>
    1.64 +
    1.65 +<para>Mercurial does not track directory information.  Instead, it tracks
    1.66 +the path to a file.  Before creating a file, it first creates any
    1.67 +missing directory components of the path.  After it deletes a file, it
    1.68 +then deletes any empty directories that were in the deleted file's
    1.69 +path.  This sounds like a trivial distinction, but it has one minor
    1.70 +practical consequence: it is not possible to represent a completely
    1.71 +empty directory in Mercurial.
    1.72 +</para>
    1.73 +
    1.74 +<para>Empty directories are rarely useful, and there are unintrusive
    1.75 +workarounds that you can use to achieve an appropriate effect.  The
    1.76 +developers of Mercurial thus felt that the complexity that would be
    1.77 +required to manage empty directories was not worth the limited benefit
    1.78 +this feature would bring.
    1.79 +</para>
    1.80 +
    1.81 +<para>If you need an empty directory in your repository, there are a few
    1.82 +ways to achieve this. One is to create a directory, then <command role="hg-cmd">hg add</command> a
    1.83 +<quote>hidden</quote> file to that directory.  On Unix-like systems, any file
    1.84 +name that begins with a period (<quote><literal>.</literal></quote>) is treated as hidden
    1.85 +by most commands and GUI tools.  This approach is illustrated in
    1.86 +figure <xref linkend="ex:daily:hidden"/>.
    1.87 +</para>
    1.88 +
    1.89 +<informalfigure>
    1.90 +<para>  <!-- &interaction.daily.files.hidden; -->
    1.91 +  <caption><para>Simulating an empty directory using a hidden file</para></caption>
    1.92 +  \label{ex:daily:hidden}
    1.93 +</para>
    1.94 +</informalfigure>
    1.95 +
    1.96 +<para>Another way to tackle a need for an empty directory is to simply
    1.97 +create one in your automated build scripts before they will need it.
    1.98 +</para>
    1.99 +
   1.100 +</sect2>
   1.101 +</sect1>
   1.102 +<sect1>
   1.103 +<title>How to stop tracking a file</title>
   1.104 +
   1.105 +<para>Once you decide that a file no longer belongs in your repository, use
   1.106 +the <command role="hg-cmd">hg remove</command> command; this deletes the file, and tells Mercurial
   1.107 +to stop tracking it.  A removed file is represented in the output of
   1.108 +<command role="hg-cmd">hg status</command> with a <quote><literal>R</literal></quote>.
   1.109 +<!-- &interaction.daily.files.remove; -->
   1.110 +</para>
   1.111 +
   1.112 +<para>After you <command role="hg-cmd">hg remove</command> a file, Mercurial will no longer track
   1.113 +changes to that file, even if you recreate a file with the same name
   1.114 +in your working directory.  If you do recreate a file with the same
   1.115 +name and want Mercurial to track the new file, simply <command role="hg-cmd">hg add</command> it.
   1.116 +Mercurial will know that the newly added file is not related to the
   1.117 +old file of the same name.
   1.118 +</para>
   1.119 +
   1.120 +<sect2>
   1.121 +<title>Removing a file does not affect its history</title>
   1.122 +
   1.123 +<para>It is important to understand that removing a file has only two
   1.124 +effects.
   1.125 +</para>
   1.126 +<itemizedlist>
   1.127 +<listitem><para>It removes the current version of the file from the working
   1.128 +  directory.
   1.129 +</para>
   1.130 +</listitem>
   1.131 +<listitem><para>It stops Mercurial from tracking changes to the file, from the
   1.132 +  time of the next commit.
   1.133 +</para>
   1.134 +</listitem></itemizedlist>
   1.135 +<para>Removing a file <emphasis>does not</emphasis> in any way alter the <emphasis>history</emphasis> of
   1.136 +the file.
   1.137 +</para>
   1.138 +
   1.139 +<para>If you update the working directory to a changeset in which a file
   1.140 +that you have removed was still tracked, it will reappear in the
   1.141 +working directory, with the contents it had when you committed that
   1.142 +changeset.  If you then update the working directory to a later
   1.143 +changeset, in which the file had been removed, Mercurial will once
   1.144 +again remove the file from the working directory.
   1.145 +</para>
   1.146 +
   1.147 +</sect2>
   1.148 +<sect2>
   1.149 +<title>Missing files</title>
   1.150 +
   1.151 +<para>Mercurial considers a file that you have deleted, but not used
   1.152 +<command role="hg-cmd">hg remove</command> to delete, to be <emphasis>missing</emphasis>.  A missing file is
   1.153 +represented with <quote><literal>!</literal></quote> in the output of <command role="hg-cmd">hg status</command>.
   1.154 +Mercurial commands will not generally do anything with missing files.
   1.155 +<!-- &interaction.daily.files.missing; -->
   1.156 +</para>
   1.157 +
   1.158 +<para>If your repository contains a file that <command role="hg-cmd">hg status</command> reports as
   1.159 +missing, and you want the file to stay gone, you can run
   1.160 +<command role="hg-cmd">hg remove <option role="hg-opt-remove">--after</option></command> at any time later on, to
   1.161 +tell Mercurial that you really did mean to remove the file.
   1.162 +<!-- &interaction.daily.files.remove-after; -->
   1.163 +</para>
   1.164 +
   1.165 +<para>On the other hand, if you deleted the missing file by accident, use
   1.166 +<command role="hg-cmd">hg revert <emphasis>filename</emphasis></command> to recover the file.  It will
   1.167 +reappear, in unmodified form.
   1.168 +<!-- &interaction.daily.files.recover-missing; -->
   1.169 +</para>
   1.170 +
   1.171 +<para>\subsection{Aside: why tell Mercurial explicitly to
   1.172 +  remove a file?}
   1.173 +</para>
   1.174 +
   1.175 +<para>You might wonder why Mercurial requires you to explicitly tell it that
   1.176 +you are deleting a file.  Early during the development of Mercurial,
   1.177 +it let you delete a file however you pleased; Mercurial would notice
   1.178 +the absence of the file automatically when you next ran a
   1.179 +<command role="hg-cmd">hg commit</command>, and stop tracking the file.  In practice, this made it
   1.180 +too easy to accidentally remove a file without noticing.
   1.181 +</para>
   1.182 +
   1.183 +<para>\subsection{Useful shorthand&emdash;adding and removing files
   1.184 +  in one step}
   1.185 +</para>
   1.186 +
   1.187 +<para>Mercurial offers a combination command, <command role="hg-cmd">hg addremove</command>, that adds
   1.188 +untracked files and marks missing files as removed.
   1.189 +<!-- &interaction.daily.files.addremove; -->
   1.190 +The <command role="hg-cmd">hg commit</command> command also provides a <option role="hg-opt-commit">-A</option> option
   1.191 +that performs this same add-and-remove, immediately followed by a
   1.192 +commit.
   1.193 +<!-- &interaction.daily.files.commit-addremove; -->
   1.194 +</para>
   1.195 +
   1.196 +</sect2>
   1.197 +</sect1>
   1.198 +<sect1>
   1.199 +<title>Copying files</title>
   1.200 +
   1.201 +<para>Mercurial provides a <command role="hg-cmd">hg copy</command> command that lets you make a new
   1.202 +copy of a file.  When you copy a file using this command, Mercurial
   1.203 +makes a record of the fact that the new file is a copy of the original
   1.204 +file.  It treats these copied files specially when you merge your work
   1.205 +with someone else's.
   1.206 +</para>
   1.207 +
   1.208 +<sect2>
   1.209 +<title>The results of copying during a merge</title>
   1.210 +
   1.211 +<para>What happens during a merge is that changes <quote>follow</quote> a copy.  To
   1.212 +best illustrate what this means, let's create an example.  We'll start
   1.213 +with the usual tiny repository that contains a single file.
   1.214 +<!-- &interaction.daily.copy.init; -->
   1.215 +We need to do some work in parallel, so that we'll have something to
   1.216 +merge.  So let's clone our repository.
   1.217 +<!-- &interaction.daily.copy.clone; -->
   1.218 +Back in our initial repository, let's use the <command role="hg-cmd">hg copy</command> command to
   1.219 +make a copy of the first file we created.
   1.220 +<!-- &interaction.daily.copy.copy; -->
   1.221 +</para>
   1.222 +
   1.223 +<para>If we look at the output of the <command role="hg-cmd">hg status</command> command afterwards, the
   1.224 +copied file looks just like a normal added file.
   1.225 +<!-- &interaction.daily.copy.status; -->
   1.226 +But if we pass the <option role="hg-opt-status">-C</option> option to <command role="hg-cmd">hg status</command>, it
   1.227 +prints another line of output: this is the file that our newly-added
   1.228 +file was copied <emphasis>from</emphasis>.
   1.229 +<!-- &interaction.daily.copy.status-copy; -->
   1.230 +</para>
   1.231 +
   1.232 +<para>Now, back in the repository we cloned, let's make a change in
   1.233 +parallel.  We'll add a line of content to the original file that we
   1.234 +created.
   1.235 +<!-- &interaction.daily.copy.other; -->
   1.236 +Now we have a modified <filename>file</filename> in this repository.  When we
   1.237 +pull the changes from the first repository, and merge the two heads,
   1.238 +Mercurial will propagate the changes that we made locally to
   1.239 +<filename>file</filename> into its copy, <filename>new-file</filename>.
   1.240 +<!-- &interaction.daily.copy.merge; -->
   1.241 +</para>
   1.242 +
   1.243 +</sect2>
   1.244 +<sect2>
   1.245 +<title>Why should changes follow copies?</title>
   1.246 +<para>\label{sec:daily:why-copy}
   1.247 +</para>
   1.248 +
   1.249 +<para>This behaviour, of changes to a file propagating out to copies of the
   1.250 +file, might seem esoteric, but in most cases it's highly desirable.
   1.251 +</para>
   1.252 +
   1.253 +<para>First of all, remember that this propagation <emphasis>only</emphasis> happens when
   1.254 +you merge.  So if you <command role="hg-cmd">hg copy</command> a file, and subsequently modify the
   1.255 +original file during the normal course of your work, nothing will
   1.256 +happen.
   1.257 +</para>
   1.258 +
   1.259 +<para>The second thing to know is that modifications will only propagate
   1.260 +across a copy as long as the repository that you're pulling changes
   1.261 +from <emphasis>doesn't know</emphasis> about the copy.
   1.262 +</para>
   1.263 +
   1.264 +<para>The reason that Mercurial does this is as follows.  Let's say I make
   1.265 +an important bug fix in a source file, and commit my changes.
   1.266 +Meanwhile, you've decided to <command role="hg-cmd">hg copy</command> the file in your repository,
   1.267 +without knowing about the bug or having seen the fix, and you have
   1.268 +started hacking on your copy of the file.
   1.269 +</para>
   1.270 +
   1.271 +<para>If you pulled and merged my changes, and Mercurial <emphasis>didn't</emphasis>
   1.272 +propagate changes across copies, your source file would now contain
   1.273 +the bug, and unless you remembered to propagate the bug fix by hand,
   1.274 +the bug would <emphasis>remain</emphasis> in your copy of the file.
   1.275 +</para>
   1.276 +
   1.277 +<para>By automatically propagating the change that fixed the bug from the
   1.278 +original file to the copy, Mercurial prevents this class of problem.
   1.279 +To my knowledge, Mercurial is the <emphasis>only</emphasis> revision control system
   1.280 +that propagates changes across copies like this.
   1.281 +</para>
   1.282 +
   1.283 +<para>Once your change history has a record that the copy and subsequent
   1.284 +merge occurred, there's usually no further need to propagate changes
   1.285 +from the original file to the copied file, and that's why Mercurial
   1.286 +only propagates changes across copies until this point, and no
   1.287 +further.
   1.288 +</para>
   1.289 +
   1.290 +</sect2>
   1.291 +<sect2>
   1.292 +<title>How to make changes <emphasis>not</emphasis> follow a copy</title>
   1.293 +
   1.294 +<para>If, for some reason, you decide that this business of automatically
   1.295 +propagating changes across copies is not for you, simply use your
   1.296 +system's normal file copy command (on Unix-like systems, that's
   1.297 +<command>cp</command>) to make a copy of a file, then <command role="hg-cmd">hg add</command> the new copy
   1.298 +by hand.  Before you do so, though, please do reread
   1.299 +section <xref linkend="sec:daily:why-copy"/>, and make an informed decision that
   1.300 +this behaviour is not appropriate to your specific case.
   1.301 +</para>
   1.302 +
   1.303 +</sect2>
   1.304 +<sect2>
   1.305 +<title>Behaviour of the <command role="hg-cmd">hg copy</command> command</title>
   1.306 +
   1.307 +<para>When you use the <command role="hg-cmd">hg copy</command> command, Mercurial makes a copy of each
   1.308 +source file as it currently stands in the working directory.  This
   1.309 +means that if you make some modifications to a file, then <command role="hg-cmd">hg copy</command>
   1.310 +it without first having committed those changes, the new copy will
   1.311 +also contain the modifications you have made up until that point.  (I
   1.312 +find this behaviour a little counterintuitive, which is why I mention
   1.313 +it here.)
   1.314 +</para>
   1.315 +
   1.316 +<para>The <command role="hg-cmd">hg copy</command> command acts similarly to the Unix <command>cp</command>
   1.317 +command (you can use the <command role="hg-cmd">hg cp</command> alias if you prefer).  The last
   1.318 +argument is the <emphasis>destination</emphasis>, and all prior arguments are
   1.319 +<emphasis>sources</emphasis>.  If you pass it a single file as the source, and the
   1.320 +destination does not exist, it creates a new file with that name.
   1.321 +<!-- &interaction.daily.copy.simple; -->
   1.322 +If the destination is a directory, Mercurial copies its sources into
   1.323 +that directory.
   1.324 +<!-- &interaction.daily.copy.dir-dest; -->
   1.325 +Copying a directory is recursive, and preserves the directory
   1.326 +structure of the source.
   1.327 +<!-- &interaction.daily.copy.dir-src; -->
   1.328 +If the source and destination are both directories, the source tree is
   1.329 +recreated in the destination directory.
   1.330 +<!-- &interaction.daily.copy.dir-src-dest; -->
   1.331 +</para>
   1.332 +
   1.333 +<para>As with the <command role="hg-cmd">hg rename</command> command, if you copy a file manually and
   1.334 +then want Mercurial to know that you've copied the file, simply use
   1.335 +the <option role="hg-opt-copy">--after</option> option to <command role="hg-cmd">hg copy</command>.
   1.336 +<!-- &interaction.daily.copy.after; -->
   1.337 +</para>
   1.338 +
   1.339 +</sect2>
   1.340 +</sect1>
   1.341 +<sect1>
   1.342 +<title>Renaming files</title>
   1.343 +
   1.344 +<para>It's rather more common to need to rename a file than to make a copy
   1.345 +of it.  The reason I discussed the <command role="hg-cmd">hg copy</command> command before talking
   1.346 +about renaming files is that Mercurial treats a rename in essentially
   1.347 +the same way as a copy.  Therefore, knowing what Mercurial does when
   1.348 +you copy a file tells you what to expect when you rename a file.
   1.349 +</para>
   1.350 +
   1.351 +<para>When you use the <command role="hg-cmd">hg rename</command> command, Mercurial makes a copy of
   1.352 +each source file, then deletes it and marks the file as removed.
   1.353 +<!-- &interaction.daily.rename.rename; -->
   1.354 +The <command role="hg-cmd">hg status</command> command shows the newly copied file as added, and
   1.355 +the copied-from file as removed.
   1.356 +<!-- &interaction.daily.rename.status; -->
   1.357 +As with the results of a <command role="hg-cmd">hg copy</command>, we must use the
   1.358 +<option role="hg-opt-status">-C</option> option to <command role="hg-cmd">hg status</command> to see that the added file
   1.359 +is really being tracked by Mercurial as a copy of the original, now
   1.360 +removed, file.
   1.361 +<!-- &interaction.daily.rename.status-copy; -->
   1.362 +</para>
   1.363 +
   1.364 +<para>As with <command role="hg-cmd">hg remove</command> and <command role="hg-cmd">hg copy</command>, you can tell Mercurial about
   1.365 +a rename after the fact using the <option role="hg-opt-rename">--after</option> option.  In
   1.366 +most other respects, the behaviour of the <command role="hg-cmd">hg rename</command> command, and
   1.367 +the options it accepts, are similar to the <command role="hg-cmd">hg copy</command> command.
   1.368 +</para>
   1.369 +
   1.370 +<sect2>
   1.371 +<title>Renaming files and merging changes</title>
   1.372 +
   1.373 +<para>Since Mercurial's rename is implemented as copy-and-remove, the same
   1.374 +propagation of changes happens when you merge after a rename as after
   1.375 +a copy.
   1.376 +</para>
   1.377 +
   1.378 +<para>If I modify a file, and you rename it to a new name, and then we merge
   1.379 +our respective changes, my modifications to the file under its
   1.380 +original name will be propagated into the file under its new name.
   1.381 +(This is something you might expect to <quote>simply work,</quote> but not all
   1.382 +revision control systems actually do this.)
   1.383 +</para>
   1.384 +
   1.385 +<para>Whereas having changes follow a copy is a feature where you can
   1.386 +perhaps nod and say <quote>yes, that might be useful,</quote> it should be clear
   1.387 +that having them follow a rename is definitely important.  Without
   1.388 +this facility, it would simply be too easy for changes to become
   1.389 +orphaned when files are renamed.
   1.390 +</para>
   1.391 +
   1.392 +</sect2>
   1.393 +<sect2>
   1.394 +<title>Divergent renames and merging</title>
   1.395 +
   1.396 +<para>The case of diverging names occurs when two developers start with a
   1.397 +file&emdash;let's call it <filename>foo</filename>&emdash;in their respective
   1.398 +repositories.
   1.399 +</para>
   1.400 +
   1.401 +<para><!-- &interaction.rename.divergent.clone; -->
   1.402 +Anne renames the file to <filename>bar</filename>.
   1.403 +<!-- &interaction.rename.divergent.rename.anne; -->
   1.404 +Meanwhile, Bob renames it to <filename>quux</filename>.
   1.405 +<!-- &interaction.rename.divergent.rename.bob; -->
   1.406 +</para>
   1.407 +
   1.408 +<para>I like to think of this as a conflict because each developer has
   1.409 +expressed different intentions about what the file ought to be named.
   1.410 +</para>
   1.411 +
   1.412 +<para>What do you think should happen when they merge their work?
   1.413 +Mercurial's actual behaviour is that it always preserves <emphasis>both</emphasis>
   1.414 +names when it merges changesets that contain divergent renames.
   1.415 +<!-- &interaction.rename.divergent.merge; -->
   1.416 +</para>
   1.417 +
   1.418 +<para>Notice that Mercurial does warn about the divergent renames, but it
   1.419 +leaves it up to you to do something about the divergence after the merge.
   1.420 +</para>
   1.421 +
   1.422 +</sect2>
   1.423 +<sect2>
   1.424 +<title>Convergent renames and merging</title>
   1.425 +
   1.426 +<para>Another kind of rename conflict occurs when two people choose to
   1.427 +rename different <emphasis>source</emphasis> files to the same <emphasis>destination</emphasis>.
   1.428 +In this case, Mercurial runs its normal merge machinery, and lets you
   1.429 +guide it to a suitable resolution.
   1.430 +</para>
   1.431 +
   1.432 +</sect2>
   1.433 +<sect2>
   1.434 +<title>Other name-related corner cases</title>
   1.435 +
   1.436 +<para>Mercurial has a longstanding bug in which it fails to handle a merge
   1.437 +where one side has a file with a given name, while another has a
   1.438 +directory with the same name.  This is documented as <ulink role="hg-bug" url="http://www.selenic.com/mercurial/bts/issue29">issue 29</ulink>.
   1.439 +<!-- &interaction.issue29.go; -->
   1.440 +</para>
   1.441 +
   1.442 +</sect2>
   1.443 +</sect1>
   1.444 +<sect1>
   1.445 +<title>Recovering from mistakes</title>
   1.446 +
   1.447 +<para>Mercurial has some useful commands that will help you to recover from
   1.448 +some common mistakes.
   1.449 +</para>
   1.450 +
   1.451 +<para>The <command role="hg-cmd">hg revert</command> command lets you undo changes that you have made to
   1.452 +your working directory.  For example, if you <command role="hg-cmd">hg add</command> a file by
   1.453 +accident, just run <command role="hg-cmd">hg revert</command> with the name of the file you added,
   1.454 +and while the file won't be touched in any way, it won't be tracked
   1.455 +for adding by Mercurial any longer, either.  You can also use
   1.456 +<command role="hg-cmd">hg revert</command> to get rid of erroneous changes to a file.
   1.457 +</para>
   1.458 +
   1.459 +<para>It's useful to remember that the <command role="hg-cmd">hg revert</command> command is useful for
   1.460 +changes that you have not yet committed.  Once you've committed a
   1.461 +change, if you decide it was a mistake, you can still do something
   1.462 +about it, though your options may be more limited.
   1.463 +</para>
   1.464 +
   1.465 +<para>For more information about the <command role="hg-cmd">hg revert</command> command, and details
   1.466 +about how to deal with changes you have already committed, see
   1.467 +chapter <xref linkend="chap:undo"/>.
   1.468 +</para>
   1.469 +
   1.470 +</sect1>
   1.471 +</chapter>
   1.472 +
   1.473 +<!--
   1.474 +local variables: 
   1.475 +sgml-parent-document: ("00book.xml" "book" "chapter")
   1.476 +end:
   1.477 +-->
   1.478 \ No newline at end of file