1.1 --- a/fr/ch05-daily.xml	Sun Aug 16 04:58:01 2009 +0200
     1.2 +++ b/fr/ch05-daily.xml	Sat Sep 12 17:58:56 2009 +0200
     1.3 @@ -1,474 +1,871 @@
     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 id="chap:daily">
   1.472 +  <?dbhtml filename="mercurial-in-daily-use.html"?>
   1.473 +  <title>Mercurial pour une utilisation de tous les jours</title>
   1.474 +
   1.475 +  <sect1>
   1.476 +    <title>Informer Mercurial des fichier à suivre</title>
   1.477 +
   1.478 +    <para id="x_1a3">Mercurial ne suit pas les fichiers de votre dépôt tant
   1.479 +      que vous ne lui avez pas dit de les gérer. La commande <command
   1.480 +        role="hg-cmd">hg status</command> vous dira quels fichiers sont
   1.481 +      inconnus de Mercurial. Il utilise un
   1.482 +      <quote><literal>?</literal></quote> pour montrer ces fichiers.</para>
   1.483 +
   1.484 +    <para id="x_1a4">Pour informer Mercurial de suivre un fichier, utilisez
   1.485 +      la commande <command role="hg-cmd">hg add</command>. Une fois que vous
   1.486 +      avez ajouté un fichier, la ligne correspondante à ce fichier dans la
   1.487 +      sortie de <command role="hg-cmd">hg status</command> change de
   1.488 +      <quote><literal>?</literal></quote> à
   1.489 +      <quote><literal>A</literal></quote>.</para>
   1.490 +
   1.491 +    &interaction.daily.files.add;
   1.492 +
   1.493 +    <para id="x_1a5">Après avoir exécuté un <command role="hg-cmd">hg
   1.494 +        commit</command>, les fichiers que vous avez ajoutés avant le commit
   1.495 +      ne seront plus listés dans la sortie de <command role="hg-cmd">hg
   1.496 +        status</command>. La raison de ceci est que, par défaut, <command
   1.497 +        role="hg-cmd">hg status</command> ne vous montre que les fichiers
   1.498 +      <quote>intéressants</quote> &emdash;ceux que vous avez (par exemple)
   1.499 +      modifiés, supprimés ou renommés. Si vous aviez un dépôt qui contient un
   1.500 +      millier de fichiers, vous ne voudriez certainement que rarement entendre
   1.501 +      parler des fichiers que Mercurial suit, mais qui n'ont pas changés.
   1.502 +      (Vous pouvez quand même avoir cette information, nous y reviendrons
   1.503 +      plus tard.)</para>
   1.504 +
   1.505 +    <para id="x_1a6">Une fois que vous ajoutez un fichier, Mercurial ne fait
   1.506 +      rien du tout avec celui-ci immédiatement. Au lieu de ça, il va prendre
   1.507 +      un "snapshot" de l'état du fichier la prochaine fois que vous
   1.508 +      exécuterez un commit. Il continuera ensuite à suivre les changements
   1.509 +      que vous avez fait au fichier chaque fois que vous committerez, et ce,
   1.510 +      jusqu'à ce que vous supprimiez le fichier.</para>
   1.511 +
   1.512 +    <sect2>
   1.513 +      <title>Nommage des fichiers explicite versus implicite</title>
   1.514 +
   1.515 +      <para id="x_1a7">Un comportement utile que Mercurial possède est que si
   1.516 +        vous passez le nom d'un répertoire à une commande, toute commande
   1.517 +        Mercurial la traitera comme : <quote>Je veux opérer sur chaque fichier
   1.518 +          dans ce répertoire et ses sous-répertoires</quote>.</para>
   1.519 +
   1.520 +      &interaction.daily.files.add-dir;
   1.521 +
   1.522 +      <para id="x_1a8">Remarquez que dans cet exemple, Mercurial affiche le
   1.523 +        nom des fichiers qu'il a ajouté, alors qu'il ne l'a pas fait lorsque
   1.524 +        nous avons ajouté le fichier nommé <filename>myfile.txt</filename>
   1.525 +        dans l'exemple précédent.</para>
   1.526 +
   1.527 +      <para id="x_1a9">Ce qu'il se passe est que dans le premier cas, nous
   1.528 +        avons nommé explicitement le fichier à ajouter sur la ligne de
   1.529 +        commande. Ce que Mercurial suppose dans ce cas est que nous savons ce
   1.530 +        que nous faisons, il n'affiche donc rien en sortie.</para>
   1.531 +
   1.532 +      <para id="x_1aa">Cependant, lorsque nous avons
   1.533 +        <emphasis>implicitement</emphasis> donné les fichiers à l'aide du nom
   1.534 +        d'un répertoire, Mercurial prend l'initiative d'afficher le nom de
   1.535 +        chaque fichier avec lequel il fait quelque chose. Ceci clarifie ce
   1.536 +        qu'il se passe et réduit la probabilité d'une mauvaise surprise
   1.537 +        restée silencieuse. Ce comportement est commun à la plupart des
   1.538 +        commandes Mercurial.</para>
   1.539 +    </sect2>
   1.540 +    <sect2>
   1.541 +      <title>Mercurial suit les fichiers, pas les répertoires</title>
   1.542 +
   1.543 +      <para id="x_1ab">Mercurial ne suit pas les informations sur les
   1.544 +        répertoires. En contrepartie, il suit le chemin vers un fichier. Avant
   1.545 +        de créer un fichier, il crée au préalable les répertoires manquants
   1.546 +        dans le chemin. Après avoir supprimé un fichier, il supprime chaque
   1.547 +        répertoire vide qui apparaît dans le chemin du fichier. Ceci apparaît
   1.548 +        comme une distinction triviale, cependant, cela a une conséquence
   1.549 +        pratique mineure : il n'est pas possible de représenter un répertoire
   1.550 +        totalement vide dans Mercurial.</para>
   1.551 +
   1.552 +      <para id="x_1ac">Les répertoires vides sont rarement utiles. Il existe
   1.553 +        cependant des solutions alternatives et non intrusives que vous
   1.554 +        pouvez utiliser pour obtenir l'effet approprié. Les développeurs de
   1.555 +        Mercurial ont ainsi pensé que la complexité requise pour gérer les
   1.556 +        répertoires n'était pas aussi importante que le bénéfice que cette
   1.557 +        fonctionnalité apporterait.</para>
   1.558 +
   1.559 +      <para id="x_1ad">Si vous avez besoin d'un répertoire vide dans votre
   1.560 +        dépôt, il existe quelques façons d'y arriver. L'une d'elles est de
   1.561 +        créer un répertoire et ensuite, de faire un <command role="hg-cmd">hg
   1.562 +          add</command> sur un fichier <quote>caché</quote> dans ce
   1.563 +        répertoire. Sur les systèmes de type Unix, tout fichier dont le nom
   1.564 +        commence avec un point (<quote><literal>.</literal></quote>) est
   1.565 +        considéré comme caché par la plupart des commandes et outils
   1.566 +        graphiques. Cette approche est illustrée ci-après.</para>
   1.567 +      
   1.568 +      &interaction.daily.files.hidden;
   1.569 +
   1.570 +      <para id="x_1ae">Une autre façon de s'attaquer au besoin d'un
   1.571 +        répertoire vide est de simplement d'en créer un dans vos scripts
   1.572 +        de construction avant qu'ils n'en aient le besoin.</para>
   1.573 +    </sect2>
   1.574 +  </sect1>
   1.575 +
   1.576 +  <sect1>
   1.577 +    <title>Comment arrêter de suivre un fichier</title>
   1.578 +
   1.579 +    <para id="x_1af">Une fois que vous décidez qu'un fichier n'appartient
   1.580 +      plus à votre dépôt, utilisez la commande <command role="hg-cmd">hg
   1.581 +        remove</command>. Ceci supprime le fichier et informe Mercurial
   1.582 +      d'arrêter de le suivre (ce qui prendra effet lors du prochain commit).
   1.583 +      Un fichier supprimé est représenté dans la sortie de la commande
   1.584 +      <command role="hg-cmd">hg status</command> par un
   1.585 +      <quote><literal>R</literal></quote>.</para>
   1.586 +
   1.587 +    &interaction.daily.files.remove;
   1.588 +
   1.589 +    <para id="x_1b0">Après avoir fait un <command role="hg-cmd">hg
   1.590 +        remove</command> sur un fichier, Mercurial ne suivra plus aucun
   1.591 +      changement sur ce fichier, même si vous recréez un fichier avec le même
   1.592 +      nom dans votre répertoire de travail. Si vous recréez un fichier avec le
   1.593 +      même nom et que vous désirez que Mercurial suive ce dernier, faite
   1.594 +      simplement un <command role="hg-cmd">hg add</command> sur celui-ci.
   1.595 +      Mercurial saura alors que le nouveau fichier ne fait pas référence à
   1.596 +      l'ancien fichier qui portait le même nom.</para>
   1.597 +
   1.598 +    <sect2>
   1.599 +      <title>Supprimer un fichier n'affecte pas son historique</title>
   1.600 +
   1.601 +      <para id="x_1b1">Il est important de comprendre que supprimer un fichier
   1.602 +        n'a que deux effets.</para>
   1.603 +
   1.604 +      <itemizedlist>
   1.605 +        <listitem><para id="x_1b2">Il supprime la version actuelle de ce
   1.606 +            fichier du répertoire de travail.</para>
   1.607 +        </listitem>
   1.608 +        <listitem><para id="x_1b3">Il arrête, à partir du prochain commit, le
   1.609 +            suivi de Mercurial sur les changements qui ont lieu sur ce
   1.610 +            fichier.</para>
   1.611 +        </listitem></itemizedlist>
   1.612 +        
   1.613 +      <para id="x_1b4">Supprimer un fichier <emphasis>n'</emphasis>affecte en
   1.614 +        <emphasis>aucun</emphasis> cas l'<emphasis>historique</emphasis> du
   1.615 +        fichier.</para>
   1.616 +
   1.617 +      <para id="x_1b5">Si vous mettez à jour le répertoire de travail à un
   1.618 +        changeset qui a été committé alors que le fichier que vous venez de
   1.619 +        supprimer était encore suivi, ce fichier réapparaîtra dans le
   1.620 +        répertoire de travail, avec le contenu qu'il avait lorsque vous aviez
   1.621 +        committé ce changeset. Si vous mettez à jour (update) le répertoire de
   1.622 +        travail à un changeset ultérieur dans lequel le fichier a été
   1.623 +        supprimé, Mercurial supprimera une nouvelle fois le fichier du
   1.624 +        répertoire de travail.</para>
   1.625 +    </sect2>
   1.626 +
   1.627 +    <sect2>
   1.628 +      <title>Fichiers manquants</title>
   1.629 +
   1.630 +      <para id="x_1b6">Mercurial considère qu'un fichier que vous avez
   1.631 +        supprimé sans utiliser<command role="hg-cmd">hg remove</command>
   1.632 +        comme étant <emphasis>manquant</emphasis>.  Un fichier manquant est
   1.633 +        représenté avec un <quote><literal>!</literal></quote> en sortie de
   1.634 +        <command role="hg-cmd">hg status</command>.
   1.635 +        Les commandes Mercurial ne feront rien avec les fichiers
   1.636 +        manquants.</para>
   1.637 +
   1.638 +      &interaction.daily.files.missing;
   1.639 +
   1.640 +      <para id="x_1b7">Si votre dépôt contient un fichier que <command
   1.641 +          role="hg-cmd">hg status</command> reporte comme manquant, et que
   1.642 +        vous voulez que ce fichier reste supprimé, vous pouvez exécuter
   1.643 +        <command role="hg-cmd">hg remove <option
   1.644 +            role="hg-opt-remove">--after</option></command> à tout moment
   1.645 +        pour dire à Mercurial que vous aviez bien voulu supprimer ce
   1.646 +        fichier.</para>
   1.647 +
   1.648 +      &interaction.daily.files.remove-after;
   1.649 +
   1.650 +      <para id="x_1b8">D'un autre coté, si vous avez supprimé le fichier
   1.651 +        manquant par accident, donnez à la commande <command role="hg-cmd">hg
   1.652 +          revert</command> le nom du fichier à retrouver. Il réapparaitra dans
   1.653 +        sa forme non modifiée.</para>
   1.654 +
   1.655 +      &interaction.daily.files.recover-missing;
   1.656 +    
   1.657 +    </sect2>
   1.658 +
   1.659 +    <sect2>
   1.660 +      <title>Entre nous : Pourquoi dire explicitement à Mercurial de supprimer un
   1.661 +      fichier ?</title>
   1.662 +
   1.663 +      <para id="x_1b9">Vous pourriez vous demander pourquoi il est nécessaire
   1.664 +        de dire explicitement à Mercurial que vous souhaitez supprimer un
   1.665 +        fichier. Au début du développement de Mercurial, celui ci vous
   1.666 +        laissait pourtant supprimer un fichier sans soucis ; Mercurial vous
   1.667 +        aurait automatiquement informé de l'absence du fichier lorsque vous
   1.668 +        auriez lancé un <command role="hg-cmd">hg commit</command> et arrêté
   1.669 +        de le suivre. En pratique, ceci a montré qu'il était trop facile de
   1.670 +        supprimer accidentellement un fichier sans le remarquer.</para>
   1.671 +    </sect2>
   1.672 +
   1.673 +    <sect2>
   1.674 +      <title>Raccourci utile&emdash;ajouter et supprimer des fichiers en une
   1.675 +      seule étape.</title>
   1.676 +
   1.677 +      <para id="x_1ba">Mercurial offre une commande combinée, <command
   1.678 +          role="hg-cmd">hg addremove</command>, qui ajoute les fichiers non
   1.679 +        suivis et marque les fichiers manquants comme supprimés.</para>
   1.680 +
   1.681 +      &interaction.daily.files.addremove;
   1.682 +
   1.683 +      <para id="x_1bb">La commande <command role="hg-cmd">hg commit</command>
   1.684 +        fournit aussi une option <option role="hg-opt-commit">-A</option> qui
   1.685 +        exécute le même ajouter-et-supprimer, immédiatement suivi d'un
   1.686 +        commit.</para>
   1.687 +
   1.688 +      &interaction.daily.files.commit-addremove;
   1.689 +    
   1.690 +    </sect2>
   1.691 +  </sect1>
   1.692 +
   1.693 +  <sect1 id="chap:daily.copy">
   1.694 +    <title>Copier des fichiers</title>
   1.695 +
   1.696 +    <para id="x_1bc">Mercurial fournit une commande <command role="hg-cmd">hg
   1.697 +        copy</command> qui vous permet de faire une nouvelle copie d'un
   1.698 +      fichier. Lorsque vous copiez un fichier en utilisant cette commande,
   1.699 +      Mercurial crée un enregistrement du fait que ce nouveau fichier est une
   1.700 +      copie du fichier originel. Il traite ces fichiers copiés spécialement
   1.701 +      lorsque vous fusionnez (merge) votre travail avec quelqu'un
   1.702 +      d'autre.</para>
   1.703 +
   1.704 +    <sect2>
   1.705 +      <title>Les résultats d'une copie durant une fusion (merge)</title>
   1.706 +
   1.707 +      <para id="x_1bd">Ce qu'il se passe durant une fusion (merge) est que
   1.708 +        les changements <quote>suivent</quote> une copie. Pour illustrer ce
   1.709 +        que cela veut dire de la meilleure façon, créons un exemple. Nous
   1.710 +        allons commencer avec le mini dépôt usuel qui contient un simple
   1.711 +        fichier.</para>
   1.712 +
   1.713 +      &interaction.daily.copy.init;
   1.714 +
   1.715 +      <para id="x_1be">Nous devons faire du travail en parallèle, ainsi,
   1.716 +        nous aurons quelque chose à fusionner (merge). Donc clonons notre
   1.717 +        dépôt.</para>
   1.718 +
   1.719 +      &interaction.daily.copy.clone;
   1.720 +
   1.721 +      <para id="x_1bf">De retour dans notre dépôt initial, utilisons la
   1.722 +        commande <command role="hg-cmd">hg copy</command> pour faire une
   1.723 +        copie du premier fichier que nous avons créé.</para>
   1.724 +
   1.725 +      &interaction.daily.copy.copy;
   1.726 +
   1.727 +      <para id="x_1c0">Si nous regardons ensuite à la sortie de la commande
   1.728 +        <command role="hg-cmd">hg status</command>, les fichiers copiés
   1.729 +        ont l'air de fichiers normalement ajoutés.</para>
   1.730 +
   1.731 +      &interaction.daily.copy.status;
   1.732 +
   1.733 +      <para id="x_1c1">Mais si nous passons l'option <option
   1.734 +          role="hg-opt-status">-C</option> à <command role="hg-cmd">hg
   1.735 +          status</command>, il affiche une autre ligne de sortie : il s'agit
   1.736 +        du fichier <emphasis>source</emphasis> pour notre copie.</para>
   1.737 +
   1.738 +      &interaction.daily.copy.status-copy;
   1.739 +
   1.740 +      <para id="x_1c2">Maintenant, de retour dans le dépôt que nous avons
   1.741 +        cloné, créons un changement en parallèle. Nous allons ajouter une
   1.742 +        ligne de contenu au fichier original qui a été créé.</para>
   1.743 +
   1.744 +      &interaction.daily.copy.other;
   1.745 +
   1.746 +      <para id="x_1c3">Nous avons alors un fichier <filename>file</filename>
   1.747 +        modifié dans ce dépôt. Lorsque nous récupérons (pull) les changements
   1.748 +        depuis le premier répertoire et fusionnons (merge) les deux "heads",
   1.749 +        Mercurial propagera les changements que nous avons faits localement
   1.750 +        au fichier <filename>file</filename> dans sa copie
   1.751 +        <filename>new-file</filename>.</para>
   1.752 +
   1.753 +      &interaction.daily.copy.merge;
   1.754 +    
   1.755 +    </sect2>
   1.756 +    <sect2 id="sec:daily:why-copy">
   1.757 +      <title>Pourquoi est-ce que les changements devraient suivre les copies
   1.758 +        ?</title>
   1.759 +
   1.760 +      <para id="x_1c4">Ce comportement&emdash;des changements d'un fichiers
   1.761 +        qui se propagent aux copies de ce fichier&emdash;peut sembler
   1.762 +        ésotérique, mais, dans la plupart des cas, c'est hautement
   1.763 +        désirable.</para>
   1.764 +
   1.765 +      <para id="x_1c5">Pour commencer, souvenez vous que cette propagation
   1.766 +        a lieue <emphasis>seulement</emphasis> lors des fusions (merge).
   1.767 +        Donc, si vous faites un	<command role="hg-cmd">hg copy</command> sur
   1.768 +        un fichier, et par la suite modifiez le fichier original durant le
   1.769 +        cours normal de votre travail, rien n'a lieu.</para>
   1.770 +
   1.771 +      <para id="x_1c6">La deuxième chose à savoir c'est que les modifications
   1.772 +        ne se propageront à travers une copie que si le changeset à partir
   1.773 +        duquel vous faites une fusion (merge) <emphasis>n'a pas encore
   1.774 +          vu</emphasis> la copie.</para>
   1.775 +          
   1.776 +      <para id="x_1c7">La raison pour laquelle Mercurial fait ainsi est une
   1.777 +        règle. Imaginons que je corrige un important bug dans un fichier source
   1.778 +        et que je commit mes changements. Pendant ce temps, vous avez décidé de
   1.779 +        faire un <command role="hg-cmd">hg copy</command> du fichier dans
   1.780 +        votre dépôt, sans rien savoir au sujet du bug ou à propos de la
   1.781 +        correction. Vous avez alors commencé à "hacker" sur votre copie du
   1.782 +        fichier.</para>
   1.783 +
   1.784 +      <para id="x_1c8">Si vous aviez récupéré (pull) et fusionné (merge) mes
   1.785 +        changements, et que Mercurial <emphasis>n'avait pas</emphasis>
   1.786 +        propagé les changements à travers les copies, votre nouveau fichier
   1.787 +        source contiendrait maintenant le bug, et à moins que vous ne sachiez
   1.788 +        qu'il faille propager la correction du bug à la main, le bug aurait
   1.789 +        <emphasis>subsisté</emphasis> dans votre copie du fichier.</para>
   1.790 +
   1.791 +      <para id="x_1c9">En propageant automatiquement les changements qui
   1.792 +        fixent les bugs à partir du fichier original vers les copies,
   1.793 +        Mercurial prévient ce type de problèmes. A ma connaissance, Mercurial
   1.794 +        est le <emphasis>seul</emphasis> système de gestion de révisions qui
   1.795 +        propage les changements à travers les copies comme ceci.</para>
   1.796 +
   1.797 +      <para id="x_1ca">Une fois que votre historique des changements a un
   1.798 +        enregistrement concernant une copie et qu'une fusion postérieure a
   1.799 +        eu lieue, il n'y a d'habitude pas d'autre besoin de propager les
   1.800 +        changements du fichier originel vers le fichier copié. C'est pourquoi
   1.801 +        Mercurial ne propage les changements à travers les copies qu'à la
   1.802 +        première fusion, et pas d'avantage.</para>
   1.803 +    </sect2>
   1.804 +
   1.805 +    <sect2>
   1.806 +      <title>Comment faire des changements qui <emphasis>ne</emphasis>
   1.807 +      suivent <emphasis>pas</emphasis> une copie</title>
   1.808 +
   1.809 +      <para id="x_1cb">Si pour une raison ou une autre, vous décidez que
   1.810 +        cette fonctionnalité de propager automatiquement les changements à
   1.811 +        travers les copies n'est pas pour vous, utilisez simplement la
   1.812 +        commande normale de copie de votre système (sur les systèmes de type
   1.813 +        Unix, il s'agit de <command>cp</command>) pour faire une copie d'un
   1.814 +        fichier. Utilisez ensuite <command role="hg-cmd">hg add</command>
   1.815 +        pour ajouter les nouveaux fichiers à la main. Cependant, avant d'en
   1.816 +        faire ainsi, relisez <xref linkend="sec:daily:why-copy"/>, et faites
   1.817 +        un choix en connaissance de cause comme quoi cette fonctionnalité
   1.818 +        n'est pas appropriée à votre cas spécifique.</para>
   1.819 +
   1.820 +    </sect2>
   1.821 +    <sect2>
   1.822 +      <title>Comportement de la commande <command role="hg-cmd">hg copy</command></title>
   1.823 +
   1.824 +      <para id="x_1cc">Lorsque vous utilisez la commande <command
   1.825 +          role="hg-cmd">hg copy</command>, Mercurial crée une copie de chaque
   1.826 +        fichier source tel qu'il est actuellement dans le répertoire de
   1.827 +        travail. Cela signifie que si vous effectuez des modifications sur un
   1.828 +        fichier, puis faites un <command role="hg-cmd">hg copy</command> sur
   1.829 +        celui-ci sans avoir au préalable committé ces changements, la nouvelle
   1.830 +        copie contiendra aussi les modifications que vous avez fait jusqu'à
   1.831 +        ce point.	(Je trouve ce comportement quelque peu contre intuitif,
   1.832 +        c'est pourquoi j'en fais mention ici.)</para>
   1.833 +      <!-- Vérifier que je n'ai pas fait de contre sens en relisant la
   1.834 +      version anglaise, ce que je comprend ici me paraît un peu bizarre -->
   1.835 +
   1.836 +      <para id="x_1cd">La commande <command role="hg-cmd">hg copy</command>
   1.837 +        agit comme la commande Unix <command>cp</command> (vous pouvez
   1.838 +        utilisez l'alias <command role="hg-cmd">hg cp</command> si vous
   1.839 +        préférez).  Nous devons lui donner deux ou plus arguments où le
   1.840 +        dernier est considéré comme la <emphasis>destination</emphasis>, et
   1.841 +        les autres comme les <emphasis>sources</emphasis>.</para>
   1.842 +
   1.843 +      <para id="x_685">Si vous passez à <command role="hg-cmd">hg
   1.844 +          copy</command> un seul fichier source, et que la destination
   1.845 +        n'existe pas, ceci créera un nouveau fichier avec ce nom.</para>
   1.846 +
   1.847 +      &interaction.daily.copy.simple;
   1.848 +
   1.849 +      <para id="x_1ce">Si la destination est un répertoire, Mercurial copie
   1.850 +        les sources dans ce répertoire.</para>
   1.851 +
   1.852 +      &interaction.daily.copy.dir-dest;
   1.853 +
   1.854 +      <para id="x_1cf">La copie de répertoire est récursive et préserve la
   1.855 +        structure du répertoire source.</para>
   1.856 +
   1.857 +      &interaction.daily.copy.dir-src;
   1.858 +
   1.859 +      <para id="x_1d0">Si la source et la destination sont tous deux des
   1.860 +        répertoires, l'arborescence de la source est recréée dans le
   1.861 +        répertoire destination.</para>
   1.862 +    
   1.863 +      &interaction.daily.copy.dir-src-dest;
   1.864 +
   1.865 +      <para id="x_1d1">Comme avec la commande <command role="hg-cmd">hg
   1.866 +          remove</command>, si vous copiez un fichier manuellement et voulez
   1.867 +        que Mercurial sache qu'il s'agit d'une copie, utilisez simplement
   1.868 +        l'option <option role="hg-opt-copy">--after</option> avec <command
   1.869 +          role="hg-cmd">hg copy</command>.</para>
   1.870 +
   1.871 +      &interaction.daily.copy.after;
   1.872 +    </sect2>
   1.873 +  </sect1>
   1.874 +
   1.875 +  <sect1>
   1.876 +    <title>Renommer les fichiers</title>
   1.877 +
   1.878 +    <para id="x_1d2">Il est plus commun d'avoir besoin de renommer un
   1.879 +      fichier que d'en faire une copie. La raison pour laquelle j'ai discuté
   1.880 +      de la commande <command role="hg-cmd">hg copy</command> avant de parler
   1.881 +      de renommage des fichiers est que Mercurial traite les renommages
   1.882 +      essentiellement comme une copie. Ainsi, savoir comment Mercurial traite
   1.883 +      les copies de fichiers vous informe sur ce que vous êtes en droit
   1.884 +      d'attendre lorsque vous renommez un fichier.</para>
   1.885 +
   1.886 +    <para id="x_1d3">Lorsque vous utilisez la commande <command
   1.887 +        role="hg-cmd">hg rename</command>, Mercurial crée une copie de tous
   1.888 +      les fichiers sources, les supprime et marque ces fichiers comme étant
   1.889 +      supprimés.</para>
   1.890 +
   1.891 +    &interaction.daily.rename.rename;
   1.892 +
   1.893 +    <para id="x_1d4">La commande <command role="hg-cmd">hg status</command>
   1.894 +      montre les nouveaux fichiers comme ajoutés et les fichiers originaux
   1.895 +      comme supprimés.</para>
   1.896 +
   1.897 +    &interaction.daily.rename.status;
   1.898 +
   1.899 +    <para id="x_1d5">A cause du <command role="hg-cmd">hg	copy</command>,
   1.900 +      nous devons utiliser l'option <option role="hg-opt-status">-C</option>
   1.901 +      pour la commande <command	role="hg-cmd">hg status</command> afin
   1.902 +      d'observer que le fichier ajouté est bien suivi par Mercurial comme
   1.903 +      étant une copie de l'original maintenant supprimé.</para>
   1.904 +
   1.905 +    &interaction.daily.rename.status-copy;
   1.906 +
   1.907 +    <para id="x_1d6">Comme avec <command role="hg-cmd">hg remove</command> et
   1.908 +      <command role="hg-cmd">hg copy</command>, vous pouvez informer
   1.909 +      Mercurial au sujet d'un renommage après coup en utilisant l'option
   1.910 +      <option role="hg-opt-rename">--after</option>. Dans le plus grand
   1.911 +      respect, le comportement de la commande <command role="hg-cmd">hg
   1.912 +        rename</command>, et les options qu'il accepte sont similaires à la
   1.913 +      commande <command role="hg-cmd">hg copy</command>.</para>
   1.914 +
   1.915 +    <para id="x_686">Si vous êtes familier avec la ligne de commande Unix,
   1.916 +      vous serez heureux d'apprendre que la commande <command
   1.917 +        role="hg-cmd">hg rename</command> peut être invoquée par <command
   1.918 +        role="hg-cmd">hg mv</command>.</para>
   1.919 +
   1.920 +    <sect2>
   1.921 +      <title>Renommer les fichiers et fusionner (merge) les changements</title>
   1.922 +
   1.923 +      <para id="x_1d7">Puise que le "rename" de Mercurial est implanté comme un
   1.924 +        "copy-and-remove", la même propagation des changements a lieue après
   1.925 +        un "rename" qu'après un "copy" lorsque vous fusionnez (merge).</para>
   1.926 +
   1.927 +      <para id="x_1d8">Si je modifie un fichier et que vous le renommez, si
   1.928 +        ensuite nous fusionnons nos changements respectifs, mes modifications
   1.929 +        sur le fichier sous son nom originel seront propagés vers le même
   1.930 +        fichier sous son nouveau nom. (C'est quelque chose que vous pourriez
   1.931 +        espérer voir <quote>fonctionner simplement</quote>, mais tous les
   1.932 +        systèmes de gestion de version ne le font pas.)</para>
   1.933 +
   1.934 +      <para id="x_1d9">Tandis qu'avoir des changements qui suivent une copie
   1.935 +        est une fonctionnalité où vous hocheriez sûrement la tête en disant
   1.936 +        <quote>oui, cela pourrait être utile</quote>, il est clair que les
   1.937 +        voir suivre un renommage est définitivement important. Sans cette
   1.938 +        aptitude, il serait vraiment trop facile d'avoir des changements
   1.939 +        qui deviennent orphelins lorsque des fichiers sont renommés.</para>
   1.940 +    </sect2>
   1.941 +
   1.942 +    <sect2>
   1.943 +      <title>Renommages divergeants et fusion (merge)</title>
   1.944 +
   1.945 +      <para id="x_1da">Le cas de noms divergeants a lieu lorsque deux
   1.946 +        développeurs commencent avec un fichier&emdash;appelons le
   1.947 +        <filename>foo</filename>&emdash;dans leurs dépôts respectifs.</para>
   1.948 +
   1.949 +      &interaction.rename.divergent.clone;
   1.950 +
   1.951 +      <para id="x_1db">Anne renomme le fichier en
   1.952 +        <filename>bar</filename>.</para>
   1.953 +
   1.954 +      &interaction.rename.divergent.rename.anne;
   1.955 +
   1.956 +      <para id="x_1dc">Pendant ce temps, Bob le renomme en
   1.957 +        <filename>quux</filename>. (Souvenez vous que <command
   1.958 +          role="hg-cmd">hg mv</command> est un alias pour <command
   1.959 +          role="hg-cmd">hg rename</command>.)</para>
   1.960 +    
   1.961 +      &interaction.rename.divergent.rename.bob;
   1.962 +
   1.963 +      <para id="x_1dd">J'aime à penser qu'il s'agit d'un conflit puisque
   1.964 +        chaque développeur a exprimé différentes intentions au sujet de ce
   1.965 +        que le nom de ce fichier aurait du être.</para>
   1.966 +
   1.967 +      <para id="x_1de">Que pensez vous qu'il devrait se produire lorsqu'ils
   1.968 +        fusionnent (merge) leurs travaux ? Le comportement actuel de
   1.969 +        Mercurial est qu'il préserve toujours les <emphasis>deux</emphasis>
   1.970 +        noms lorsqu'il fusionne (merge) des changesets qui contiennent des
   1.971 +        renommages divergeants.</para>
   1.972 +
   1.973 +      &interaction.rename.divergent.merge;
   1.974 +
   1.975 +      <para id="x_1df">Remarquez que bien que Mercurial vous avertisse au
   1.976 +        sujet de la divergeance des renommages, il vous laisse faire quelque
   1.977 +        chose au sujet de la divergeance après la fusion (merge).</para>
   1.978 +    </sect2>
   1.979 +
   1.980 +    <sect2>
   1.981 +      <title>Renommages et fusion convergeants</title>
   1.982 +
   1.983 +      <para id="x_1e0">Un autre type de conflit de renommage intervient
   1.984 +        lorsque deux personne choisissent de renommer différents fichiers
   1.985 +        <emphasis>source</emphasis> vers la même
   1.986 +        <emphasis>destination</emphasis>. Dans ce cas, Mercurial exécute la
   1.987 +        machinerie normale de fusion (merge) et vous guide vers une
   1.988 +        solution convenable.</para>
   1.989 +    </sect2>
   1.990 +
   1.991 +    <sect2>
   1.992 +      <title>Autres cas anguleux relatifs aux noms</title>
   1.993 +
   1.994 +      <para id="x_1e1">Mercurial possède un bug de longue date dans lequel il
   1.995 +        échoue à traiter une fusion (merge) où un coté a un fichier avec un
   1.996 +        nom donné, alors que l'autre coté possède un répertoire avec le même nom.
   1.997 +        Ceci est documenté dans l'<ulink role="hg-bug"
   1.998 +          url="http://www.selenic.com/mercurial/bts/issue29">issue
   1.999 +          29</ulink>.</para>
  1.1000 +
  1.1001 +      &interaction.issue29.go;
  1.1002 +
  1.1003 +    </sect2>
  1.1004 +  </sect1>
  1.1005 +
  1.1006 +  <sect1>
  1.1007 +    <title>Récupération d'erreurs</title>
  1.1008 +
  1.1009 +    <para id="x_1e2">Mercurial possède certaines commandes utiles qui vont
  1.1010 +      vous aider à récupérer de certaines erreurs communes.</para>
  1.1011 +
  1.1012 +    <para id="x_1e3">La commande <command role="hg-cmd">hg revert</command>
  1.1013 +      vous permet d'annuler les changements que vous avez faits dans votre
  1.1014 +      répertoire de travail. Par exemple, si vous faites un <command
  1.1015 +        role="hg-cmd">hg add</command> sur un fichier par accident, exécutez
  1.1016 +      juste <command role="hg-cmd">hg	revert</command> avec le nom du fichier
  1.1017 +      que vous avez ajouté et tandis que le fichier ne sera touché d'une
  1.1018 +      quelconque manière, il ne sera plus suivi comme ajouté par Mercurial.
  1.1019 +      Vous pouvez aussi utiliser la commande <command role="hg-cmd">hg
  1.1020 +        revert</command> pour vous débarrasser de modifications erronés
  1.1021 +      apportées à un fichier.</para>
  1.1022 +
  1.1023 +    <para id="x_1e4">Il est utile de se souvenir que la commande <command
  1.1024 +        role="hg-cmd">hg revert</command> est utile pour les modifications
  1.1025 +      qui n'ont pas encore été committées. Une fois que vous avez committé un
  1.1026 +      changement, si vous décidez qu'il s'agissait d'une erreur, vous pouvez
  1.1027 +      toujours faire quelque chose à ce sujet, bien que vos options soient
  1.1028 +      un peu plus limitées.</para>
  1.1029 +
  1.1030 +    <para id="x_1e5">Pour plus d'informations au sujet de la commande
  1.1031 +      <command role="hg-cmd">hg revert</command>, et des détails sur comment
  1.1032 +      traiter les modifications que vous avez déjà committées, référez vous à
  1.1033 +      <xref linkend="chap:undo"/>.</para>
  1.1034 +  </sect1>
  1.1035 +
  1.1036 +  <sect1>
  1.1037 +    <title>Traiter avec les fusions (merge) malicieuses</title>
  1.1038 +
  1.1039 +    <para id="x_687">Dans des projets compliqués ou conséquents, il n'est pas
  1.1040 +      rare qu'une fusion (merge) de deux changesets finisse par une migraine.
  1.1041 +      Supposez qu'il y ait un gros fichier source qui ait été largement édité de
  1.1042 +      chaque coté de la fusion (merge) : ceci va inévitablement résulter en
  1.1043 +      conflits, dont certains peuvent prendre plusieurs essais pour s'en
  1.1044 +      sortir.</para>
  1.1045 +
  1.1046 +    <para id="x_688">Développons en un cas simple pour voir comment le gérer.
  1.1047 +      Nous allons commencer avec un dépôt contenant un fichier, et le
  1.1048 +      cloner deux fois.</para>
  1.1049 +
  1.1050 +    &interaction.ch04-resolve.init;
  1.1051 +
  1.1052 +    <para id="x_689">Dans un des clones, nous allons modifier le fichier
  1.1053 +      d'une façon.</para>
  1.1054 +
  1.1055 +    &interaction.ch04-resolve.left;
  1.1056 +
  1.1057 +    <para id="x_68a">Dans un autre, nous allons modifier le fichier
  1.1058 +      différemment.</para>
  1.1059 +
  1.1060 +    &interaction.ch04-resolve.right;
  1.1061 +
  1.1062 +    <para id="x_68b">Ensuite, nous allons récupérer (pull) chaque ensemble de
  1.1063 +      changement dans notre dépôt original.</para>
  1.1064 +
  1.1065 +    &interaction.ch04-resolve.pull;
  1.1066 +
  1.1067 +    <para id="x_68c">Nous nous attendons à ce que notre dépôt contienne deux
  1.1068 +      "heads".</para>
  1.1069 +
  1.1070 +    &interaction.ch04-resolve.heads;
  1.1071 +
  1.1072 +    <para id="x_68d">Normalement, si nous lançons <command role="hg-cmd">hg
  1.1073 +        merge</command> à ce point, il nous renverra vers une interface
  1.1074 +      utilisateur qui nous permettra de résoudre manuellement les éditions
  1.1075 +      conflictuelles sur le fichier <filename>myfile.txt</filename>.
  1.1076 +      Cependant, pour simplifier ici les choses dans la présentation, nous
  1.1077 +      aimerions plutôt que la fusion (merge) échoue immédiatement. Voici une
  1.1078 +      façon de le faire.</para>
  1.1079 +
  1.1080 +    &interaction.ch04-resolve.export;
  1.1081 +
  1.1082 +    <para id="x_68e">Nous avons dit au processus de fusion de Mercurial
  1.1083 +      d'exécuter la commande <command>false</command> (qui échoue
  1.1084 +      immédiatement, à la demande) s'il détecte une fusion (merge) qu'il ne
  1.1085 +      peut pas arranger automatiquement.</para>
  1.1086 +
  1.1087 +    <para id="x_68f">Si nous appelons maintenant <command role="hg-cmd">hg
  1.1088 +        merge</command>, il devrait échouer et reporter une erreur.</para>
  1.1089 +
  1.1090 +    &interaction.ch04-resolve.merge;
  1.1091 +
  1.1092 +    <para id="x_690">Même si nous ne remarquons pas qu'une fusion (merge) a
  1.1093 +      échoué, Mercurial nous empêchera de committer le résultat d'une fusion
  1.1094 +      ratée.</para>
  1.1095 +
  1.1096 +    &interaction.ch04-resolve.cifail;
  1.1097 +
  1.1098 +    <para id="x_691">Lorsque <command role="hg-cmd">hg commit</command>
  1.1099 +      échoue dans ce cas, il suggère que nous utilisons la commande peu
  1.1100 +      connue <command	role="hg-cmd">hg resolve</command>.  Comme d'habitude,
  1.1101 +      <command role="hg-cmd">hg help resolve</command> affichera une aide
  1.1102 +      sommaire.</para>
  1.1103 +
  1.1104 +    <sect2>
  1.1105 +      <title>États de résolution des fichiers</title>
  1.1106 +      <!-- TODO Vérifier traduction : File resolution states -->
  1.1107 +
  1.1108 +      <para id="x_692">Lorsqu'une fusion intervient, la plupart des fichiers
  1.1109 +        vont, la plupart du temps, rester sans modification. Pour chaque
  1.1110 +        fichier sur lequel Mercurial doit faire quelque chose, il suit l'état
  1.1111 +        de celui-ci.</para>
  1.1112 +
  1.1113 +      <itemizedlist>
  1.1114 +        <listitem><para id="x_693">Un fichier
  1.1115 +            <quote><emphasis>resolved</emphasis></quote> a été fusionné
  1.1116 +            (merge) avec succès, que ce soit automatiquement par Mercurial ou
  1.1117 +            manuellement par une intervention humaine.</para></listitem>
  1.1118 +        <listitem><para id="x_694">Un fichier
  1.1119 +            <quote><emphasis>unresolved</emphasis></quote> n'a pas été
  1.1120 +            fusionné (merge) correctement et a besoin de plus
  1.1121 +            d'attention.</para>
  1.1122 +        </listitem>
  1.1123 +      </itemizedlist>
  1.1124 +
  1.1125 +      <para id="x_695">Si Mercurial voit un fichier
  1.1126 +        <emphasis>quelconque</emphasis> dans un état
  1.1127 +        <quote>unresolved</quote> après une fusion (merge), il considère que
  1.1128 +        la fusion (merge) a échoué. Heureusement, nous n'avons pas à
  1.1129 +        recommencer la procédure à partir du début.</para>
  1.1130 +
  1.1131 +      <para id="x_696">L'option <option role="hg-opt-resolve">--list</option>
  1.1132 +        ou <option role="hg-opt-resolve">-l</option> passée à <command
  1.1133 +          role="hg-cmd">hg resolve</command> liste l'état de chaque fichier
  1.1134 +        fusionné (merge).</para>
  1.1135 +
  1.1136 +      &interaction.ch04-resolve.list;
  1.1137 +
  1.1138 +      <para id="x_697">En sortie de <command role="hg-cmd">hg
  1.1139 +          resolve</command>, un fichier "resolved" est marqué avec un
  1.1140 +        <literal>R</literal>, alors qu'un fichier "unresolved" est marqué
  1.1141 +        d'un <literal>U</literal>.  S'il existe un fichier listé avec un
  1.1142 +        <literal>U</literal>, nous savons qu'essayer de committer le résultat
  1.1143 +        de la fusion (merge) échouera.</para>
  1.1144 +    </sect2>
  1.1145 +
  1.1146 +    <sect2>
  1.1147 +      <title>Résoudre une fusion de fichier</title>
  1.1148 +
  1.1149 +      <para id="x_698">Nous avons plusieurs options pour changer l'état d'un
  1.1150 +        fichier de "unresolved" à "resolved". Le plus commun est de relancer
  1.1151 +        <command role="hg-cmd">hg resolve</command>. Si nous passons les noms
  1.1152 +        des fichiers individuels ou des répertoires, ceci retentera la fusion
  1.1153 +        de tous les fichiers présents à cet endroit. Nous pouvons aussi
  1.1154 +        passer l'option <option role="hg-opt-resolve">--all</option> ou
  1.1155 +        <option role="hg-opt-resolve">-a</option> qui tentera de fusionner
  1.1156 +        <emphasis>tous</emphasis> les fichiers "unresolved".</para>
  1.1157 +
  1.1158 +      <para id="x_699">Mercurial nous laisse aussi modifier la résolution
  1.1159 +        d'un fichier directement. Nous pouvons marquer un fichier "resolved"
  1.1160 +        en utilisant l'option <option role="hg-opt-resolve">--mark</option>,
  1.1161 +        ou "unresolved" en utilisant l'option <option
  1.1162 +          role="hg-opt-resolve">--unmark</option>. Ceci nous autorise à
  1.1163 +        nettoyer une fusion particulièrement compliquée à la main, et de
  1.1164 +        garder un suivi de nos progrès avec chaque fichier pendant que nous
  1.1165 +        procédons.</para>
  1.1166 +    </sect2>
  1.1167 +  </sect1>
  1.1168 +
  1.1169 +  <sect1>
  1.1170 +    <title>Des "diffs" plus utiles</title>
  1.1171 +
  1.1172 +    <para id="x_6c7">La sortie par défaut de la commande <command
  1.1173 +        role="hg-cmd">hg diff</command> est compatible rétrospectivement avec
  1.1174 +      la commande régulière <command>diff</command>, mais ceci a quelques
  1.1175 +      inconvénients.</para>
  1.1176 +
  1.1177 +    <para id="x_6c8">Considérez le cas où nous utilisons <command role="hg-cmd">hg
  1.1178 +        rename</command> pour renommer un fichier.</para>
  1.1179 +
  1.1180 +    &interaction.ch04-diff.rename.basic;
  1.1181 +
  1.1182 +    <para id="x_6c9">La sortie de <command role="hg-cmd">hg diff</command>
  1.1183 +      ci-dessus cache le fait que nous avons simplement renommé un fichier.
  1.1184 +      La commande <command role="hg-cmd">hg diff</command> accepte l'option
  1.1185 +      <option>--git</option> ou <option>-g</option> pour utiliser un nouveau
  1.1186 +      format de diff qui montre ces informations sous une forme plus
  1.1187 +      expressive.</para>
  1.1188 +
  1.1189 +    &interaction.ch04-diff.rename.git;
  1.1190 +
  1.1191 +    <para id="x_6ca">Cette option peut aussi aider avec le cas autrement
  1.1192 +      confus : un fichier qui apparaît comme étant modifié en accord avec
  1.1193 +      <command role="hg-cmd">hg status</command>, mais où <command
  1.1194 +        role="hg-cmd">hg diff</command> n'affiche rien. Cette situation peut
  1.1195 +      survenir si nous changeons les permissions d'exécution du
  1.1196 +      fichier.</para>
  1.1197 +
  1.1198 +    &interaction.ch04-diff.chmod;
  1.1199 +
  1.1200 +    <para id="x_6cb">La commande normale <command>diff</command> ne fait pas
  1.1201 +      attention aux permissions des fichiers, ce qui explique pourquoi
  1.1202 +      <command role="hg-cmd">hg diff</command> n'affiche rien du tout par
  1.1203 +      défaut. Si nous lui passons l'option <option>-g</option>, ceci nous
  1.1204 +      informe de ce qu'il s'est vraiment passé.</para>
  1.1205 +
  1.1206 +    &interaction.ch04-diff.chmod.git;
  1.1207 +  </sect1>
  1.1208 +
  1.1209 +  <sect1>
  1.1210 +    <title>Quels fichiers suivre et lesquels éviter</title>
  1.1211 +
  1.1212 +    <para id="x_6cc">Les systèmes de gestion de révisions sont en général
  1.1213 +      meilleurs pour gérer les fichiers textes qui sont écrits par les
  1.1214 +      humains, comme le code source, où les fichiers ne changent pas
  1.1215 +      énormément d'une révision à l'autre. Certains systèmes de gestion de
  1.1216 +      révisions centralisés peuvent aussi traiter très convenablement les
  1.1217 +      fichiers binaires, tels que les images bitmap.</para>
  1.1218 +
  1.1219 +    <para id="x_6cd">Par exemple, une équipe de développement de jeux va
  1.1220 +      probablement gérer les deux types : ses codes source et tous ses binaires
  1.1221 +      (ex. données géométriques, textures, schémas de cartes) dans un système
  1.1222 +      de contrôle de révisions.</para>
  1.1223 +    <!-- Vérifier la traduction de map layouts que j'ai traduit par schémas
  1.1224 +    de cartes -->
  1.1225 +
  1.1226 +    <para id="x_6ce">Puisqu'il est d'habitude impossible de fusionner (merge)
  1.1227 +      deux modifications conflictuelles sur un fichier binaire, les systèmes
  1.1228 +      de version centralisés offrent souvent un mécanisme de verrou (lock) qui
  1.1229 +      permet à un utilisateur de dire <quote>Je suis la seule personne qui
  1.1230 +        peut éditer ce fichier</quote>.</para>
  1.1231 +
  1.1232 +    <para id="x_6cf">En comparaison avec un système centralisé, un système
  1.1233 +      décentralisé de gestion de révision change certains facteurs qui
  1.1234 +      guident les décisions sur quels fichiers gérer et comment.</para>
  1.1235 +
  1.1236 +    <para id="x_6d0">Par exemple, un système distribué de gestion de révisions
  1.1237 +      ne peut pas, par sa nature, offrir un système de véroux (lock) sur les
  1.1238 +      fichiers. Il n'y a donc pas de mécanisme inclus pour empêcher deux
  1.1239 +      personnes de faire des modifications conflictuelles sur un fichier
  1.1240 +      binaire. Si vous avez une équipe où plusieurs personnes peuvent souvent
  1.1241 +      éditer un fichier binaire, cela ne serait pas une très bonne idée
  1.1242 +      d'utiliser Mercurial &emdash;ou tout autre système distribué de gestion
  1.1243 +      de révisions&emdash;pour gérer ces fichiers.</para>
  1.1244 +
  1.1245 +    <para id="x_6d1">Lorsque vous sauvegardez les modifications sur un
  1.1246 +      fichier, Mercurial ne sauvegarde d'habitude que les différences entre
  1.1247 +      la version précédente et la version actuelle d'un fichier. Pour la
  1.1248 +      plupart des fichiers texte, ceci est très efficace. Cependant, certains
  1.1249 +      fichiers (en particulier les fichiers binaires) sont construits d'une
  1.1250 +      façon que même un petit changement sur un contenu logique résulte sur
  1.1251 +      un changement de la plupart des octets du fichier. Par exemple, les
  1.1252 +      fichiers compressés sont particulièrement sujets à ce comportement. Si
  1.1253 +      les différences entre deux versions successives d'un fichier sont
  1.1254 +      toujours très grandes, Mercurial ne sera pas capable de sauvegarder
  1.1255 +      l'historique des révisions sur le fichier très efficacement. Ceci peut
  1.1256 +      affecter aussi bien les besoins pour la sauvegarde locale que le temps
  1.1257 +      nécessaire à cloner le dépôt.</para>
  1.1258 +
  1.1259 +    <para id="x_6d2">Pour avoir une idée de comment ceci pourrait vous
  1.1260 +      affecter en pratique, supposez que nous voulions que Mercurial gère des
  1.1261 +      documents OpenOffice. OpenOffice sauvegarde les documents sur le disque
  1.1262 +      comme des fichiers compressés zip. Même le fait d'éditer ces fichiers
  1.1263 +      d'une seule lettre, changera les bits de la quasi totalité du fichier
  1.1264 +      lorsque vous le sauvegarderez. Maintenant, supposez que ce fichier
  1.1265 +      fasse une taille de 2Mo. Puisque la plupart du fichier change à chaque
  1.1266 +      fois que vous sauvegardez, Mercurial aura à sauvegarder tous les 2Mo du
  1.1267 +      fichier à chaque commit, alors que de votre point de vue, il n'y a
  1.1268 +      que peu de mots qui changent à chaque fois. Un seul fichier
  1.1269 +      souvent édité qui n'est pas bien traité par les hypothèses que Mercurial
  1.1270 +      fait sur les sauvegardes peut facilement avoir un effet colossal sur la
  1.1271 +      taille du dépôt.</para>
  1.1272 +
  1.1273 +    <para id="x_6d3">Même pire, si vous et quelqu'un d'autre éditez le même
  1.1274 +      document OpenOffice sur lequel vous travaillez, il n'y a pas de façon
  1.1275 +      utile pour fusionner votre travail. En fait, il n'y a pas de moyen
  1.1276 +      utile de montrer que les différences sont faites à partir de votre
  1.1277 +      vision des modifications.</para>
  1.1278 +
  1.1279 +    <para id="x_6d4">Il y a ainsi quelques recommandations claires sur les
  1.1280 +      types de fichiers spécifiques avec lesquels faire très
  1.1281 +      attention.</para>
  1.1282 +
  1.1283 +    <itemizedlist>
  1.1284 +      <listitem><para id="x_6d5">Les fichier qui sont très gros et
  1.1285 +          incompressibles, comme les images ISO de CD-ROM, sont, par
  1.1286 +          construction très gros et les cloner à travers un réseau sera très
  1.1287 +          long.</para></listitem>
  1.1288 +     <!-- TODO : Trouver une meilleure traduction pour : ISO CD-ROM images, will by
  1.1289 +     virtue of sheer size make clones over a network very slow. -->
  1.1290 +      <listitem><para id="x_6d6">Les fichiers qui changent beaucoup d'une
  1.1291 +          révision à l'autre peuvent être très chers à sauvegarder si vous
  1.1292 +          les éditez fréquemment, de même que les conflits entre deux éditions
  1.1293 +          concurrentes peuvent être difficiles à résoudre.</para>
  1.1294 +      </listitem>
  1.1295 +    </itemizedlist>
  1.1296 +  </sect1>
  1.1297 +
  1.1298 +  <sect1>
  1.1299 +    <title>Sauvegardes et miroirs</title>
  1.1300 +
  1.1301 +    <para id="x_6d7">Puisque Mercurial maintient une copie complète de
  1.1302 +      l'historique de chaque clone, toute personne qui utilise Mercurial pour
  1.1303 +      collaborer à un projet peut potentiellement agir comme une source de
  1.1304 +      sauvegarde si une catastrophe survenait. Si un dépôt central devient
  1.1305 +      indisponible, vous pouvez construire un remplaçant en clonant une copie
  1.1306 +      du dépôt à partir d'un des contributeurs en récupérant (pull) tous les
  1.1307 +      changements qui n'auraient pas été vus par les autres.</para>
  1.1308 +
  1.1309 +    <para id="x_6d8">Il est simple d'utiliser Mercurial pour construire des
  1.1310 +      serveurs hors site de sauvegarde et des miroirs distants. Initiez une
  1.1311 +      tâche périodique (ex. via la commande <command>cron</command>) sur un
  1.1312 +      serveur distant pour récupérer (pull) les changements de votre dépôt
  1.1313 +      distant chaque heure. Ceci sera difficile seulement dans le cas
  1.1314 +      improbable où le nombre des dépôts maîtres que vous maintenez change
  1.1315 +      souvent, auquel cas vous aurez besoin de faire un peu de scripting pour
  1.1316 +      rafraichir la liste des dépôt à sauvegarder.</para>
  1.1317 +
  1.1318 +    <para id="x_6d9">Si vous exécutez des sauvegardes traditionnelles de
  1.1319 +      votre dépôt maître sur bande ou disque, et que vous voulez sauvegarder
  1.1320 +      un dépôt nommé <filename>myrepo</filename>, utilisez la commande
  1.1321 +      <command>hg clone -U myrepo myrepo.bak</command> pour créer un clone de
  1.1322 +      <filename>myrepo</filename> avant de commencer vos backups.
  1.1323 +      L'option <option>-U</option> ne crée pas de répertoire de travail après
  1.1324 +      que le clone soit accompli, puisque ceci serait superflu et ferait que
  1.1325 +      la sauvegarde prenne plus de temps.</para>
  1.1326 +
  1.1327 +    <para id="x_6da">Si vous voulez ensuite sauvegarder
  1.1328 +      <filename>myrepo.bak</filename> au lieu de <filename>myrepo</filename>,
  1.1329 +      vous aurez la garantie d'avoir une image (snapshot) consistante de
  1.1330 +      votre dépôt sur lequel un développeur insomniaque n'enverra (push) pas de
  1.1331 +      changements en milieu de sauvegarde.</para>
  1.1332 +  </sect1>
  1.1333  </chapter>
  1.1334  
  1.1335  <!--
  1.1336  local variables: 
  1.1337  sgml-parent-document: ("00book.xml" "book" "chapter")
  1.1338  end:
  1.1339 --->
  1.1340 \ No newline at end of file
  1.1341 +-->