bos@559: <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
bos@559: 
bos@685: <chapter id="chap:daily">
bos@572:   <?dbhtml filename="mercurial-in-daily-use.html"?>
andre@1018:   <title>Utilisation quotidienne de Mercurial</title>
bos@559: 
bos@559:   <sect1>
andre@1018:     <title>Informer Mercurial des fichiers à suivre</title>
youshe@990: 
youshe@990:     <para id="x_1a3">Mercurial ne suit pas les fichiers de votre dépôt tant
youshe@990:       que vous ne lui avez pas dit de les gérer. La commande <command
youshe@990:         role="hg-cmd">hg status</command> vous dira quels fichiers sont
youshe@988:       inconnus de Mercurial. Il utilise un
youshe@988:       <quote><literal>?</literal></quote> pour montrer ces fichiers.</para>
youshe@988: 
youshe@988:     <para id="x_1a4">Pour informer Mercurial de suivre un fichier, utilisez
youshe@988:       la commande <command role="hg-cmd">hg add</command>. Une fois que vous
youshe@988:       avez ajouté un fichier, la ligne correspondante à ce fichier dans la
youshe@988:       sortie de <command role="hg-cmd">hg status</command> change de
youshe@988:       <quote><literal>?</literal></quote> à
bos@567:       <quote><literal>A</literal></quote>.</para>
bos@567: 
youshe@988:     &interaction.daily.files.add;
youshe@988: 
youshe@988:     <para id="x_1a5">Après avoir exécuté un <command role="hg-cmd">hg
youshe@990:         commit</command>, les fichiers que vous avez ajoutés avant le commit
youshe@990:       ne seront plus listés dans la sortie de <command role="hg-cmd">hg
youshe@990:         status</command>. La raison de ceci est que, par défaut, <command
youshe@988:         role="hg-cmd">hg status</command> ne vous montre que les fichiers
youshe@988:       <quote>intéressants</quote> &emdash;ceux que vous avez (par exemple)
andre@1018:       modifiés, supprimés ou renommés. Si vous avez un dépôt qui contient un
youshe@990:       millier de fichiers, vous ne voudriez certainement que rarement entendre
youshe@988:       parler des fichiers que Mercurial suit, mais qui n'ont pas changés.
youshe@988:       (Vous pouvez quand même avoir cette information, nous y reviendrons
youshe@988:       plus tard.)</para>
youshe@988: 
youshe@988:     <para id="x_1a6">Une fois que vous ajoutez un fichier, Mercurial ne fait
youshe@990:       rien du tout avec celui-ci immédiatement. Au lieu de ça, il va prendre
youshe@988:       un "snapshot" de l'état du fichier la prochaine fois que vous
youshe@988:       exécuterez un commit. Il continuera ensuite à suivre les changements
youshe@990:       que vous avez fait au fichier chaque fois que vous committerez, et ce,
youshe@990:       jusqu'à ce que vous supprimiez le fichier.</para>
youshe@988: 
youshe@988:     <sect2>
youshe@988:       <title>Nommage des fichiers explicite versus implicite</title>
youshe@988: 
youshe@988:       <para id="x_1a7">Un comportement utile que Mercurial possède est que si
youshe@988:         vous passez le nom d'un répertoire à une commande, toute commande
youshe@990:         Mercurial la traitera comme : <quote>Je veux opérer sur chaque fichier
youshe@988:           dans ce répertoire et ses sous-répertoires</quote>.</para>
bos@567: 
bos@567:       &interaction.daily.files.add-dir;
bos@567: 
youshe@988:       <para id="x_1a8">Remarquez que dans cet exemple, Mercurial affiche le
youshe@988:         nom des fichiers qu'il a ajouté, alors qu'il ne l'a pas fait lorsque
youshe@988:         nous avons ajouté le fichier nommé <filename>myfile.txt</filename>
youshe@988:         dans l'exemple précédent.</para>
youshe@988: 
youshe@988:       <para id="x_1a9">Ce qu'il se passe est que dans le premier cas, nous
youshe@988:         avons nommé explicitement le fichier à ajouter sur la ligne de
youshe@990:         commande. Ce que Mercurial suppose dans ce cas est que nous savons ce
youshe@990:         que nous faisons, il n'affiche donc rien en sortie.</para>
youshe@988: 
youshe@988:       <para id="x_1aa">Cependant, lorsque nous avons
youshe@988:         <emphasis>implicitement</emphasis> donné les fichiers à l'aide du nom
youshe@990:         d'un répertoire, Mercurial prend l'initiative d'afficher le nom de
youshe@988:         chaque fichier avec lequel il fait quelque chose. Ceci clarifie ce
youshe@990:         qu'il se passe et réduit la probabilité d'une mauvaise surprise
youshe@990:         restée silencieuse. Ce comportement est commun à la plupart des
youshe@990:         commandes Mercurial.</para>
youshe@988:     </sect2>
youshe@988:     <sect2>
youshe@988:       <title>Mercurial suit les fichiers, pas les répertoires</title>
youshe@988: 
youshe@988:       <para id="x_1ab">Mercurial ne suit pas les informations sur les
youshe@990:         répertoires. En contrepartie, il suit le chemin vers un fichier. Avant
youshe@988:         de créer un fichier, il crée au préalable les répertoires manquants
youshe@988:         dans le chemin. Après avoir supprimé un fichier, il supprime chaque
youshe@988:         répertoire vide qui apparaît dans le chemin du fichier. Ceci apparaît
youshe@990:         comme une distinction triviale, cependant, cela a une conséquence
youshe@988:         pratique mineure : il n'est pas possible de représenter un répertoire
youshe@988:         totalement vide dans Mercurial.</para>
youshe@988: 
youshe@988:       <para id="x_1ac">Les répertoires vides sont rarement utiles. Il existe
youshe@990:         cependant des solutions alternatives et non intrusives que vous
youshe@990:         pouvez utiliser pour obtenir l'effet approprié. Les développeurs de
youshe@990:         Mercurial ont ainsi pensé que la complexité requise pour gérer les
youshe@990:         répertoires n'était pas aussi importante que le bénéfice que cette
youshe@990:         fonctionnalité apporterait.</para>
youshe@988: 
youshe@988:       <para id="x_1ad">Si vous avez besoin d'un répertoire vide dans votre
youshe@988:         dépôt, il existe quelques façons d'y arriver. L'une d'elles est de
youshe@990:         créer un répertoire et ensuite, de faire un <command role="hg-cmd">hg
youshe@990:           add</command> sur un fichier <quote>caché</quote> dans ce
youshe@990:         répertoire. Sur les systèmes de type Unix, tout fichier dont le nom
youshe@988:         commence avec un point (<quote><literal>.</literal></quote>) est
youshe@988:         considéré comme caché par la plupart des commandes et outils
youshe@990:         graphiques. Cette approche est illustrée ci-après.</para>
youshe@988:       
youshe@988:       &interaction.daily.files.hidden;
youshe@988: 
youshe@988:       <para id="x_1ae">Une autre façon de s'attaquer au besoin d'un
youshe@990:         répertoire vide est de simplement d'en créer un dans vos scripts
youshe@988:         de construction avant qu'ils n'en aient le besoin.</para>
bos@559:     </sect2>
bos@559:   </sect1>
bos@674: 
bos@559:   <sect1>
youshe@988:     <title>Comment arrêter de suivre un fichier</title>
youshe@988: 
youshe@988:     <para id="x_1af">Une fois que vous décidez qu'un fichier n'appartient
youshe@988:       plus à votre dépôt, utilisez la commande <command role="hg-cmd">hg
youshe@988:         remove</command>. Ceci supprime le fichier et informe Mercurial
youshe@988:       d'arrêter de le suivre (ce qui prendra effet lors du prochain commit).
youshe@988:       Un fichier supprimé est représenté dans la sortie de la commande
youshe@988:       <command role="hg-cmd">hg status</command> par un
bos@567:       <quote><literal>R</literal></quote>.</para>
bos@567: 
bos@567:     &interaction.daily.files.remove;
bos@559: 
youshe@988:     <para id="x_1b0">Après avoir fait un <command role="hg-cmd">hg
youshe@988:         remove</command> sur un fichier, Mercurial ne suivra plus aucun
youshe@988:       changement sur ce fichier, même si vous recréez un fichier avec le même
youshe@990:       nom dans votre répertoire de travail. Si vous recréez un fichier avec le
youshe@988:       même nom et que vous désirez que Mercurial suive ce dernier, faite
youshe@988:       simplement un <command role="hg-cmd">hg add</command> sur celui-ci.
youshe@988:       Mercurial saura alors que le nouveau fichier ne fait pas référence à
youshe@988:       l'ancien fichier qui portait le même nom.</para>
youshe@988: 
youshe@988:     <sect2>
youshe@988:       <title>Supprimer un fichier n'affecte pas son historique</title>
youshe@988: 
youshe@990:       <para id="x_1b1">Il est important de comprendre que supprimer un fichier
youshe@988:         n'a que deux effets.</para>
youshe@988: 
bos@559:       <itemizedlist>
youshe@988:         <listitem><para id="x_1b2">Il supprime la version actuelle de ce
youshe@988:             fichier du répertoire de travail.</para>
youshe@988:         </listitem>
youshe@988:         <listitem><para id="x_1b3">Il arrête, à partir du prochain commit, le
youshe@988:             suivi de Mercurial sur les changements qui ont lieu sur ce
youshe@988:             fichier.</para>
youshe@988:         </listitem></itemizedlist>
youshe@988:         
youshe@988:       <para id="x_1b4">Supprimer un fichier <emphasis>n'</emphasis>affecte en
youshe@988:         <emphasis>aucun</emphasis> cas l'<emphasis>historique</emphasis> du
youshe@988:         fichier.</para>
youshe@988: 
youshe@988:       <para id="x_1b5">Si vous mettez à jour le répertoire de travail à un
youshe@990:         changeset qui a été committé alors que le fichier que vous venez de
youshe@990:         supprimer était encore suivi, ce fichier réapparaîtra dans le
youshe@988:         répertoire de travail, avec le contenu qu'il avait lorsque vous aviez
youshe@990:         committé ce changeset. Si vous mettez à jour (update) le répertoire de
youshe@990:         travail à un changeset ultérieur dans lequel le fichier a été
youshe@988:         supprimé, Mercurial supprimera une nouvelle fois le fichier du
youshe@988:         répertoire de travail.</para>
youshe@988:     </sect2>
youshe@988: 
youshe@988:     <sect2>
youshe@990:       <title>Fichiers manquants</title>
youshe@988: 
youshe@988:       <para id="x_1b6">Mercurial considère qu'un fichier que vous avez
youshe@988:         supprimé sans utiliser<command role="hg-cmd">hg remove</command>
youshe@988:         comme étant <emphasis>manquant</emphasis>.  Un fichier manquant est
youshe@988:         représenté avec un <quote><literal>!</literal></quote> en sortie de
youshe@988:         <command role="hg-cmd">hg status</command>.
youshe@988:         Les commandes Mercurial ne feront rien avec les fichiers
youshe@988:         manquants.</para>
bos@567: 
bos@567:       &interaction.daily.files.missing;
bos@559: 
youshe@988:       <para id="x_1b7">Si votre dépôt contient un fichier que <command
youshe@990:           role="hg-cmd">hg status</command> reporte comme manquant, et que
youshe@988:         vous voulez que ce fichier reste supprimé, vous pouvez exécuter
youshe@988:         <command role="hg-cmd">hg remove <option
youshe@988:             role="hg-opt-remove">--after</option></command> à tout moment
youshe@988:         pour dire à Mercurial que vous aviez bien voulu supprimer ce
youshe@988:         fichier.</para>
bos@567: 
bos@567:       &interaction.daily.files.remove-after;
bos@559: 
andre@1018:       <para id="x_1b8">D'un autre côté, si vous avez supprimé le fichier
youshe@988:         manquant par accident, donnez à la commande <command role="hg-cmd">hg
youshe@990:           revert</command> le nom du fichier à retrouver. Il réapparaitra dans
youshe@988:         sa forme non modifiée.</para>
bos@559: 
bos@674:       &interaction.daily.files.recover-missing;
youshe@988:     
youshe@988:     </sect2>
youshe@988: 
youshe@988:     <sect2>
andre@1018:       <title>Aparté : Pourquoi dire explicitement à Mercurial de supprimer un
youshe@988:       fichier ?</title>
andre@1018: <!-- TODO Choisir une traduction commune à tous les chapitres pour Aside -->
youshe@988:       <para id="x_1b9">Vous pourriez vous demander pourquoi il est nécessaire
youshe@990:         de dire explicitement à Mercurial que vous souhaitez supprimer un
youshe@988:         fichier. Au début du développement de Mercurial, celui ci vous
andre@1018:         laissait pourtant supprimer un fichier sans souci ; Mercurial vous
youshe@988:         aurait automatiquement informé de l'absence du fichier lorsque vous
youshe@988:         auriez lancé un <command role="hg-cmd">hg commit</command> et arrêté
youshe@988:         de le suivre. En pratique, ceci a montré qu'il était trop facile de
youshe@988:         supprimer accidentellement un fichier sans le remarquer.</para>
youshe@988:     </sect2>
youshe@988: 
youshe@988:     <sect2>
youshe@990:       <title>Raccourci utile&emdash;ajouter et supprimer des fichiers en une
youshe@988:       seule étape.</title>
youshe@988: 
youshe@988:       <para id="x_1ba">Mercurial offre une commande combinée, <command
youshe@988:           role="hg-cmd">hg addremove</command>, qui ajoute les fichiers non
youshe@988:         suivis et marque les fichiers manquants comme supprimés.</para>
bos@567: 
bos@567:       &interaction.daily.files.addremove;
bos@567: 
youshe@988:       <para id="x_1bb">La commande <command role="hg-cmd">hg commit</command>
youshe@988:         fournit aussi une option <option role="hg-opt-commit">-A</option> qui
youshe@988:         exécute le même ajouter-et-supprimer, immédiatement suivi d'un
youshe@988:         commit.</para>
bos@567: 
bos@567:       &interaction.daily.files.commit-addremove;
youshe@988:     
bos@559:     </sect2>
bos@559:   </sect1>
bos@674: 
bos@701:   <sect1 id="chap:daily.copy">
youshe@988:     <title>Copier des fichiers</title>
youshe@988: 
youshe@988:     <para id="x_1bc">Mercurial fournit une commande <command role="hg-cmd">hg
youshe@988:         copy</command> qui vous permet de faire une nouvelle copie d'un
youshe@988:       fichier. Lorsque vous copiez un fichier en utilisant cette commande,
youshe@988:       Mercurial crée un enregistrement du fait que ce nouveau fichier est une
youshe@988:       copie du fichier originel. Il traite ces fichiers copiés spécialement
youshe@990:       lorsque vous fusionnez (merge) votre travail avec quelqu'un
youshe@988:       d'autre.</para>
youshe@988: 
youshe@988:     <sect2>
youshe@990:       <title>Les résultats d'une copie durant une fusion (merge)</title>
youshe@988: 
youshe@988:       <para id="x_1bd">Ce qu'il se passe durant une fusion (merge) est que
youshe@988:         les changements <quote>suivent</quote> une copie. Pour illustrer ce
youshe@990:         que cela veut dire de la meilleure façon, créons un exemple. Nous
youshe@988:         allons commencer avec le mini dépôt usuel qui contient un simple
youshe@988:         fichier.</para>
bos@567: 
bos@567:       &interaction.daily.copy.init;
bos@567: 
youshe@988:       <para id="x_1be">Nous devons faire du travail en parallèle, ainsi,
youshe@988:         nous aurons quelque chose à fusionner (merge). Donc clonons notre
youshe@988:         dépôt.</para>
bos@567: 
bos@567:       &interaction.daily.copy.clone;
bos@567: 
youshe@988:       <para id="x_1bf">De retour dans notre dépôt initial, utilisons la
youshe@988:         commande <command role="hg-cmd">hg copy</command> pour faire une
youshe@988:         copie du premier fichier que nous avons créé.</para>
bos@567: 
bos@567:       &interaction.daily.copy.copy;
bos@559: 
youshe@988:       <para id="x_1c0">Si nous regardons ensuite à la sortie de la commande
youshe@988:         <command role="hg-cmd">hg status</command>, les fichiers copiés
youshe@988:         ont l'air de fichiers normalement ajoutés.</para>
bos@567: 
bos@567:       &interaction.daily.copy.status;
bos@567: 
youshe@988:       <para id="x_1c1">Mais si nous passons l'option <option
youshe@988:           role="hg-opt-status">-C</option> à <command role="hg-cmd">hg
youshe@988:           status</command>, il affiche une autre ligne de sortie : il s'agit
youshe@988:         du fichier <emphasis>source</emphasis> pour notre copie.</para>
bos@567: 
bos@567:       &interaction.daily.copy.status-copy;
bos@559: 
youshe@988:       <para id="x_1c2">Maintenant, de retour dans le dépôt que nous avons
youshe@990:         cloné, créons un changement en parallèle. Nous allons ajouter une
youshe@988:         ligne de contenu au fichier original qui a été créé.</para>
bos@567: 
bos@567:       &interaction.daily.copy.other;
bos@567: 
youshe@990:       <para id="x_1c3">Nous avons alors un fichier <filename>file</filename>
youshe@990:         modifié dans ce dépôt. Lorsque nous récupérons (pull) les changements
youshe@990:         depuis le premier répertoire et fusionnons (merge) les deux "heads",
youshe@990:         Mercurial propagera les changements que nous avons faits localement
youshe@990:         au fichier <filename>file</filename> dans sa copie
youshe@988:         <filename>new-file</filename>.</para>
bos@567: 
bos@567:       &interaction.daily.copy.merge;
youshe@988:     
youshe@988:     </sect2>
bos@559:     <sect2 id="sec:daily:why-copy">
andre@1018:       <title>Pourquoi les changements devraient-ils suivre les copies ?</title>
andre@1018: 
andre@1018:       <para id="x_1c4">Ce comportement&emdash;des changements d'un fichier
youshe@988:         qui se propagent aux copies de ce fichier&emdash;peut sembler
andre@1018:         ésotérique, mais, dans la plupart des cas, c'est fortement
andre@1018:         souhaitable.</para>
andre@1018: 
andre@1018:       <para id="x_1c5">Pour commencer, souvenez-vous que cette propagation
andre@1018:         a lieu <emphasis>seulement</emphasis> lors des fusions (merge).
youshe@988:         Donc, si vous faites un	<command role="hg-cmd">hg copy</command> sur
youshe@988:         un fichier, et par la suite modifiez le fichier original durant le
andre@1018:         cours normal de votre travail, rien n'aura lieu.</para>
andre@1018: 
andre@1018:       <para id="x_1c6">La deuxième chose à savoir est que les modifications
youshe@988:         ne se propageront à travers une copie que si le changeset à partir
youshe@988:         duquel vous faites une fusion (merge) <emphasis>n'a pas encore
youshe@988:           vu</emphasis> la copie.</para>
youshe@988:           
youshe@988:       <para id="x_1c7">La raison pour laquelle Mercurial fait ainsi est une
youshe@990:         règle. Imaginons que je corrige un important bug dans un fichier source
youshe@990:         et que je commit mes changements. Pendant ce temps, vous avez décidé de
youshe@988:         faire un <command role="hg-cmd">hg copy</command> du fichier dans
youshe@990:         votre dépôt, sans rien savoir au sujet du bug ou à propos de la
youshe@990:         correction. Vous avez alors commencé à "hacker" sur votre copie du
youshe@990:         fichier.</para>
youshe@988: 
youshe@988:       <para id="x_1c8">Si vous aviez récupéré (pull) et fusionné (merge) mes
youshe@988:         changements, et que Mercurial <emphasis>n'avait pas</emphasis>
youshe@988:         propagé les changements à travers les copies, votre nouveau fichier
youshe@990:         source contiendrait maintenant le bug, et à moins que vous ne sachiez
youshe@988:         qu'il faille propager la correction du bug à la main, le bug aurait
youshe@988:         <emphasis>subsisté</emphasis> dans votre copie du fichier.</para>
youshe@988: 
youshe@988:       <para id="x_1c9">En propageant automatiquement les changements qui
youshe@988:         fixent les bugs à partir du fichier original vers les copies,
andre@1018:         Mercurial prévient ce type de problèmes. À ma connaissance, Mercurial
youshe@988:         est le <emphasis>seul</emphasis> système de gestion de révisions qui
youshe@988:         propage les changements à travers les copies comme ceci.</para>
youshe@988: 
youshe@988:       <para id="x_1ca">Une fois que votre historique des changements a un
youshe@990:         enregistrement concernant une copie et qu'une fusion postérieure a
andre@1018:         eu lieu, il n'y a d'habitude pas d'autre besoin de propager les
youshe@990:         changements du fichier originel vers le fichier copié. C'est pourquoi
youshe@990:         Mercurial ne propage les changements à travers les copies qu'à la
andre@1018:         première fusion, et pas après.</para>
youshe@988:     </sect2>
youshe@988: 
youshe@988:     <sect2>
youshe@988:       <title>Comment faire des changements qui <emphasis>ne</emphasis>
youshe@988:       suivent <emphasis>pas</emphasis> une copie</title>
youshe@988: 
youshe@988:       <para id="x_1cb">Si pour une raison ou une autre, vous décidez que
youshe@988:         cette fonctionnalité de propager automatiquement les changements à
youshe@988:         travers les copies n'est pas pour vous, utilisez simplement la
youshe@988:         commande normale de copie de votre système (sur les systèmes de type
youshe@988:         Unix, il s'agit de <command>cp</command>) pour faire une copie d'un
youshe@988:         fichier. Utilisez ensuite <command role="hg-cmd">hg add</command>
youshe@988:         pour ajouter les nouveaux fichiers à la main. Cependant, avant d'en
youshe@988:         faire ainsi, relisez <xref linkend="sec:daily:why-copy"/>, et faites
youshe@990:         un choix en connaissance de cause comme quoi cette fonctionnalité
youshe@990:         n'est pas appropriée à votre cas spécifique.</para>
youshe@988: 
youshe@988:     </sect2>
youshe@988:     <sect2>
youshe@988:       <title>Comportement de la commande <command role="hg-cmd">hg copy</command></title>
youshe@988: 
youshe@988:       <para id="x_1cc">Lorsque vous utilisez la commande <command
youshe@988:           role="hg-cmd">hg copy</command>, Mercurial crée une copie de chaque
youshe@988:         fichier source tel qu'il est actuellement dans le répertoire de
youshe@990:         travail. Cela signifie que si vous effectuez des modifications sur un
youshe@988:         fichier, puis faites un <command role="hg-cmd">hg copy</command> sur
youshe@990:         celui-ci sans avoir au préalable committé ces changements, la nouvelle
youshe@988:         copie contiendra aussi les modifications que vous avez fait jusqu'à
youshe@990:         ce point.	(Je trouve ce comportement quelque peu contre intuitif,
youshe@990:         c'est pourquoi j'en fais mention ici.)</para>
youshe@990:       <!-- Vérifier que je n'ai pas fait de contre sens en relisant la
youshe@990:       version anglaise, ce que je comprend ici me paraît un peu bizarre -->
youshe@988: 
youshe@988:       <para id="x_1cd">La commande <command role="hg-cmd">hg copy</command>
youshe@988:         agit comme la commande Unix <command>cp</command> (vous pouvez
youshe@988:         utilisez l'alias <command role="hg-cmd">hg cp</command> si vous
youshe@988:         préférez).  Nous devons lui donner deux ou plus arguments où le
youshe@988:         dernier est considéré comme la <emphasis>destination</emphasis>, et
youshe@988:         les autres comme les <emphasis>sources</emphasis>.</para>
youshe@988: 
youshe@988:       <para id="x_685">Si vous passez à <command role="hg-cmd">hg
youshe@988:           copy</command> un seul fichier source, et que la destination
youshe@988:         n'existe pas, ceci créera un nouveau fichier avec ce nom.</para>
bos@567: 
bos@567:       &interaction.daily.copy.simple;
youshe@988: 
youshe@988:       <para id="x_1ce">Si la destination est un répertoire, Mercurial copie
youshe@988:         les sources dans ce répertoire.</para>
bos@567: 
bos@567:       &interaction.daily.copy.dir-dest;
bos@567: 
youshe@988:       <para id="x_1cf">La copie de répertoire est récursive et préserve la
youshe@988:         structure du répertoire source.</para>
bos@567: 
bos@567:       &interaction.daily.copy.dir-src;
bos@567: 
youshe@988:       <para id="x_1d0">Si la source et la destination sont tous deux des
youshe@990:         répertoires, l'arborescence de la source est recréée dans le
youshe@988:         répertoire destination.</para>
youshe@988:     
youshe@988:       &interaction.daily.copy.dir-src-dest;
youshe@988: 
youshe@988:       <para id="x_1d1">Comme avec la commande <command role="hg-cmd">hg
youshe@988:           remove</command>, si vous copiez un fichier manuellement et voulez
youshe@988:         que Mercurial sache qu'il s'agit d'une copie, utilisez simplement
youshe@988:         l'option <option role="hg-opt-copy">--after</option> avec <command
youshe@988:           role="hg-cmd">hg copy</command>.</para>
bos@567: 
bos@567:       &interaction.daily.copy.after;
bos@559:     </sect2>
bos@559:   </sect1>
bos@674: 
bos@559:   <sect1>
youshe@988:     <title>Renommer les fichiers</title>
youshe@988: 
youshe@988:     <para id="x_1d2">Il est plus commun d'avoir besoin de renommer un
youshe@988:       fichier que d'en faire une copie. La raison pour laquelle j'ai discuté
youshe@988:       de la commande <command role="hg-cmd">hg copy</command> avant de parler
youshe@988:       de renommage des fichiers est que Mercurial traite les renommages
youshe@990:       essentiellement comme une copie. Ainsi, savoir comment Mercurial traite
youshe@988:       les copies de fichiers vous informe sur ce que vous êtes en droit
youshe@988:       d'attendre lorsque vous renommez un fichier.</para>
youshe@988: 
youshe@988:     <para id="x_1d3">Lorsque vous utilisez la commande <command
youshe@990:         role="hg-cmd">hg rename</command>, Mercurial crée une copie de tous
youshe@990:       les fichiers sources, les supprime et marque ces fichiers comme étant
youshe@988:       supprimés.</para>
youshe@988: 
youshe@988:     &interaction.daily.rename.rename;
youshe@988: 
youshe@988:     <para id="x_1d4">La commande <command role="hg-cmd">hg status</command>
youshe@990:       montre les nouveaux fichiers comme ajoutés et les fichiers originaux
youshe@990:       comme supprimés.</para>
bos@567: 
bos@567:     &interaction.daily.rename.status;
bos@567: 
andre@1018:     <para id="x_1d5">À cause du <command role="hg-cmd">hg copy</command>,
youshe@988:       nous devons utiliser l'option <option role="hg-opt-status">-C</option>
youshe@990:       pour la commande <command	role="hg-cmd">hg status</command> afin
youshe@990:       d'observer que le fichier ajouté est bien suivi par Mercurial comme
youshe@990:       étant une copie de l'original maintenant supprimé.</para>
bos@567: 
bos@567:     &interaction.daily.rename.status-copy;
bos@559: 
youshe@988:     <para id="x_1d6">Comme avec <command role="hg-cmd">hg remove</command> et
youshe@988:       <command role="hg-cmd">hg copy</command>, vous pouvez informer
andre@1018:       Mercurial d'un renommage après coup en utilisant l'option
andre@1018:       <option role="hg-opt-rename">--after</option>. Dans la plupart des autres
andre@1018:       situations, le comportement de la commande <command role="hg-cmd">hg
andre@1018:         rename</command>, et les options qu'elle accepte sont similaires à la
youshe@988:       commande <command role="hg-cmd">hg copy</command>.</para>
youshe@988: 
youshe@990:     <para id="x_686">Si vous êtes familier avec la ligne de commande Unix,
youshe@988:       vous serez heureux d'apprendre que la commande <command
youshe@988:         role="hg-cmd">hg rename</command> peut être invoquée par <command
youshe@988:         role="hg-cmd">hg mv</command>.</para>
youshe@988: 
youshe@988:     <sect2>
youshe@988:       <title>Renommer les fichiers et fusionner (merge) les changements</title>
youshe@988: 
andre@1018:       <para id="x_1d7">Puisque le <quote>rename</quote> de Mercurial est implanté comme un
andre@1018:         <quote>copy-and-remove</quote>, la même propagation des changements a lieu après
andre@1018:         un <quote>rename</quote> qu'après un <quote>copy</quote> lorsque vous fusionnez (merge).</para>
youshe@988: 
youshe@988:       <para id="x_1d8">Si je modifie un fichier et que vous le renommez, si
youshe@988:         ensuite nous fusionnons nos changements respectifs, mes modifications
youshe@988:         sur le fichier sous son nom originel seront propagés vers le même
youshe@988:         fichier sous son nouveau nom. (C'est quelque chose que vous pourriez
youshe@988:         espérer voir <quote>fonctionner simplement</quote>, mais tous les
youshe@988:         systèmes de gestion de version ne le font pas.)</para>
youshe@988: 
youshe@988:       <para id="x_1d9">Tandis qu'avoir des changements qui suivent une copie
youshe@988:         est une fonctionnalité où vous hocheriez sûrement la tête en disant
youshe@988:         <quote>oui, cela pourrait être utile</quote>, il est clair que les
andre@1018:         voir suivre un renommage est sans aucun doute important. Sans cette
andre@1018:         facilité, il serait vraiment trop facile d'avoir des changements
youshe@988:         qui deviennent orphelins lorsque des fichiers sont renommés.</para>
youshe@988:     </sect2>
youshe@988: 
youshe@988:     <sect2>
youshe@988:       <title>Renommages divergeants et fusion (merge)</title>
youshe@988: 
youshe@988:       <para id="x_1da">Le cas de noms divergeants a lieu lorsque deux
youshe@990:         développeurs commencent avec un fichier&emdash;appelons le
youshe@988:         <filename>foo</filename>&emdash;dans leurs dépôts respectifs.</para>
bos@559: 
bos@567:       &interaction.rename.divergent.clone;
bos@567: 
youshe@988:       <para id="x_1db">Anne renomme le fichier en
youshe@988:         <filename>bar</filename>.</para>
bos@567: 
bos@567:       &interaction.rename.divergent.rename.anne;
bos@567: 
youshe@988:       <para id="x_1dc">Pendant ce temps, Bob le renomme en
andre@1018:         <filename>quux</filename>. (Souvenez-vous que <command
youshe@988:           role="hg-cmd">hg mv</command> est un alias pour <command
youshe@988:           role="hg-cmd">hg rename</command>.)</para>
youshe@988:     
youshe@988:       &interaction.rename.divergent.rename.bob;
youshe@988: 
youshe@988:       <para id="x_1dd">J'aime à penser qu'il s'agit d'un conflit puisque
youshe@988:         chaque développeur a exprimé différentes intentions au sujet de ce
youshe@988:         que le nom de ce fichier aurait du être.</para>
youshe@988: 
andre@1018:       <para id="x_1de">Que pensez-vous qu'il devrait se produire lorsqu'ils
youshe@988:         fusionnent (merge) leurs travaux ? Le comportement actuel de
youshe@988:         Mercurial est qu'il préserve toujours les <emphasis>deux</emphasis>
youshe@988:         noms lorsqu'il fusionne (merge) des changesets qui contiennent des
youshe@988:         renommages divergeants.</para>
bos@567: 
bos@567:       &interaction.rename.divergent.merge;
bos@559: 
youshe@988:       <para id="x_1df">Remarquez que bien que Mercurial vous avertisse au
youshe@988:         sujet de la divergeance des renommages, il vous laisse faire quelque
andre@1018:         chose au sujet de la divergence après la fusion (merge).</para>
youshe@988:     </sect2>
youshe@988: 
youshe@988:     <sect2>
youshe@988:       <title>Renommages et fusion convergeants</title>
youshe@988: 
youshe@988:       <para id="x_1e0">Un autre type de conflit de renommage intervient
andre@1018:         lorsque deux personnes choisissent de renommer différents fichiers
youshe@988:         <emphasis>source</emphasis> vers la même
youshe@988:         <emphasis>destination</emphasis>. Dans ce cas, Mercurial exécute la
youshe@988:         machinerie normale de fusion (merge) et vous guide vers une
youshe@988:         solution convenable.</para>
youshe@988:     </sect2>
youshe@988: 
youshe@988:     <sect2>
andre@1018:       <title>Autres cas épineux relatifs aux noms</title>
youshe@988: 
youshe@988:       <para id="x_1e1">Mercurial possède un bug de longue date dans lequel il
andre@1018:         échoue à traiter une fusion (merge) où un côté a un fichier avec un
andre@1018:         nom donné, alors que l'autre côté possède un répertoire avec le même nom.
youshe@988:         Ceci est documenté dans l'<ulink role="hg-bug"
youshe@988:           url="http://www.selenic.com/mercurial/bts/issue29">issue
youshe@988:           29</ulink>.</para>
bos@567: 
bos@567:       &interaction.issue29.go;
bos@559: 
bos@559:     </sect2>
bos@559:   </sect1>
bos@559:   <sect1>
youshe@988:     <title>Récupération d'erreurs</title>
youshe@988: 
youshe@988:     <para id="x_1e2">Mercurial possède certaines commandes utiles qui vont
youshe@990:       vous aider à récupérer de certaines erreurs communes.</para>
youshe@988: 
youshe@988:     <para id="x_1e3">La commande <command role="hg-cmd">hg revert</command>
youshe@990:       vous permet d'annuler les changements que vous avez faits dans votre
youshe@988:       répertoire de travail. Par exemple, si vous faites un <command
youshe@988:         role="hg-cmd">hg add</command> sur un fichier par accident, exécutez
andre@1018:       juste <command role="hg-cmd">hg revert</command> avec le nom du fichier
youshe@990:       que vous avez ajouté et tandis que le fichier ne sera touché d'une
youshe@988:       quelconque manière, il ne sera plus suivi comme ajouté par Mercurial.
youshe@988:       Vous pouvez aussi utiliser la commande <command role="hg-cmd">hg
andre@1018:         revert</command> pour vous débarrasser de modifications erronées
youshe@988:       apportées à un fichier.</para>
youshe@988: 
youshe@988:     <para id="x_1e4">Il est utile de se souvenir que la commande <command
youshe@988:         role="hg-cmd">hg revert</command> est utile pour les modifications
youshe@990:       qui n'ont pas encore été committées. Une fois que vous avez committé un
youshe@988:       changement, si vous décidez qu'il s'agissait d'une erreur, vous pouvez
youshe@990:       toujours faire quelque chose à ce sujet, bien que vos options soient
youshe@988:       un peu plus limitées.</para>
youshe@988: 
youshe@988:     <para id="x_1e5">Pour plus d'informations au sujet de la commande
youshe@988:       <command role="hg-cmd">hg revert</command>, et des détails sur comment
youshe@988:       traiter les modifications que vous avez déjà committées, référez vous à
youshe@988:       <xref linkend="chap:undo"/>.</para>
bos@674:   </sect1>
bos@674: 
bos@674:   <sect1>
youshe@988:     <title>Traiter avec les fusions (merge) malicieuses</title>
youshe@988: 
youshe@988:     <para id="x_687">Dans des projets compliqués ou conséquents, il n'est pas
youshe@988:       rare qu'une fusion (merge) de deux changesets finisse par une migraine.
youshe@990:       Supposez qu'il y ait un gros fichier source qui ait été largement édité de
youshe@988:       chaque coté de la fusion (merge) : ceci va inévitablement résulter en
youshe@990:       conflits, dont certains peuvent prendre plusieurs essais pour s'en
youshe@988:       sortir.</para>
youshe@988: 
youshe@990:     <para id="x_688">Développons en un cas simple pour voir comment le gérer.
youshe@990:       Nous allons commencer avec un dépôt contenant un fichier, et le
youshe@988:       cloner deux fois.</para>
bos@674: 
bos@674:     &interaction.ch04-resolve.init;
bos@674: 
youshe@988:     <para id="x_689">Dans un des clones, nous allons modifier le fichier
youshe@988:       d'une façon.</para>
bos@674: 
bos@674:     &interaction.ch04-resolve.left;
bos@674: 
youshe@988:     <para id="x_68a">Dans un autre, nous allons modifier le fichier
youshe@990:       différemment.</para>
bos@674: 
bos@674:     &interaction.ch04-resolve.right;
bos@674: 
youshe@988:     <para id="x_68b">Ensuite, nous allons récupérer (pull) chaque ensemble de
youshe@988:       changement dans notre dépôt original.</para>
bos@674: 
bos@674:     &interaction.ch04-resolve.pull;
bos@674: 
youshe@988:     <para id="x_68c">Nous nous attendons à ce que notre dépôt contienne deux
youshe@990:       "heads".</para>
bos@674: 
bos@674:     &interaction.ch04-resolve.heads;
bos@674: 
youshe@988:     <para id="x_68d">Normalement, si nous lançons <command role="hg-cmd">hg
youshe@988:         merge</command> à ce point, il nous renverra vers une interface
youshe@988:       utilisateur qui nous permettra de résoudre manuellement les éditions
youshe@988:       conflictuelles sur le fichier <filename>myfile.txt</filename>.
youshe@990:       Cependant, pour simplifier ici les choses dans la présentation, nous
youshe@990:       aimerions plutôt que la fusion (merge) échoue immédiatement. Voici une
youshe@988:       façon de le faire.</para>
bos@674: 
bos@674:     &interaction.ch04-resolve.export;
bos@674: 
youshe@990:     <para id="x_68e">Nous avons dit au processus de fusion de Mercurial
youshe@988:       d'exécuter la commande <command>false</command> (qui échoue
youshe@988:       immédiatement, à la demande) s'il détecte une fusion (merge) qu'il ne
youshe@988:       peut pas arranger automatiquement.</para>
youshe@988: 
youshe@988:     <para id="x_68f">Si nous appelons maintenant <command role="hg-cmd">hg
youshe@990:         merge</command>, il devrait échouer et reporter une erreur.</para>
bos@674: 
bos@674:     &interaction.ch04-resolve.merge;
bos@674: 
youshe@988:     <para id="x_690">Même si nous ne remarquons pas qu'une fusion (merge) a
youshe@990:       échoué, Mercurial nous empêchera de committer le résultat d'une fusion
youshe@988:       ratée.</para>
bos@674: 
bos@674:     &interaction.ch04-resolve.cifail;
bos@674: 
youshe@988:     <para id="x_691">Lorsque <command role="hg-cmd">hg commit</command>
youshe@988:       échoue dans ce cas, il suggère que nous utilisons la commande peu
andre@1018:       connue <command role="hg-cmd">hg resolve</command>. Comme d'habitude,
youshe@988:       <command role="hg-cmd">hg help resolve</command> affichera une aide
youshe@988:       sommaire.</para>
bos@674: 
bos@674:     <sect2>
youshe@990:       <title>États de résolution des fichiers</title>
youshe@989:       <!-- TODO Vérifier traduction : File resolution states -->
youshe@989: 
youshe@990:       <para id="x_692">Lorsqu'une fusion intervient, la plupart des fichiers
youshe@989:         vont, la plupart du temps, rester sans modification. Pour chaque
youshe@989:         fichier sur lequel Mercurial doit faire quelque chose, il suit l'état
youshe@989:         de celui-ci.</para>
bos@674: 
bos@674:       <itemizedlist>
youshe@989:         <listitem><para id="x_693">Un fichier
youshe@989:             <quote><emphasis>resolved</emphasis></quote> a été fusionné
youshe@989:             (merge) avec succès, que ce soit automatiquement par Mercurial ou
youshe@989:             manuellement par une intervention humaine.</para></listitem>
youshe@989:         <listitem><para id="x_694">Un fichier
youshe@989:             <quote><emphasis>unresolved</emphasis></quote> n'a pas été
youshe@989:             fusionné (merge) correctement et a besoin de plus
youshe@989:             d'attention.</para>
youshe@989:         </listitem>
bos@674:       </itemizedlist>
bos@674: 
youshe@990:       <para id="x_695">Si Mercurial voit un fichier
youshe@990:         <emphasis>quelconque</emphasis> dans un état
youshe@990:         <quote>unresolved</quote> après une fusion (merge), il considère que
youshe@990:         la fusion (merge) a échoué. Heureusement, nous n'avons pas à
youshe@990:         recommencer la procédure à partir du début.</para>
youshe@989: 
youshe@989:       <para id="x_696">L'option <option role="hg-opt-resolve">--list</option>
youshe@989:         ou <option role="hg-opt-resolve">-l</option> passée à <command
youshe@989:           role="hg-cmd">hg resolve</command> liste l'état de chaque fichier
youshe@989:         fusionné (merge).</para>
bos@674: 
bos@674:       &interaction.ch04-resolve.list;
bos@674: 
youshe@989:       <para id="x_697">En sortie de <command role="hg-cmd">hg
andre@1018:           resolve</command>, un fichier <quote>resolved</quote> est marqué avec un
andre@1018:         <literal>R</literal>, alors qu'un fichier <quote>unresolved</quote> est marqué
youshe@989:         d'un <literal>U</literal>.  S'il existe un fichier listé avec un
youshe@989:         <literal>U</literal>, nous savons qu'essayer de committer le résultat
youshe@990:         de la fusion (merge) échouera.</para>
youshe@989:     </sect2>
youshe@989: 
youshe@989:     <sect2>
youshe@989:       <title>Résoudre une fusion de fichier</title>
youshe@989: 
youshe@989:       <para id="x_698">Nous avons plusieurs options pour changer l'état d'un
andre@1018:         fichier de <quote>unresolved</quote> à <quote>resolved</quote>.
andre@1018:         Le plus habituel est de relancer
youshe@989:         <command role="hg-cmd">hg resolve</command>. Si nous passons les noms
youshe@989:         des fichiers individuels ou des répertoires, ceci retentera la fusion
youshe@989:         de tous les fichiers présents à cet endroit. Nous pouvons aussi
youshe@989:         passer l'option <option role="hg-opt-resolve">--all</option> ou
youshe@989:         <option role="hg-opt-resolve">-a</option> qui tentera de fusionner
andre@1018:         <emphasis>tous</emphasis> les fichiers <quote>unresolved</quote>.</para>
youshe@989: 
youshe@989:       <para id="x_699">Mercurial nous laisse aussi modifier la résolution
andre@1018:         d'un fichier directement. Nous pouvons marquer un fichier <quote>resolved</quote>
youshe@989:         en utilisant l'option <option role="hg-opt-resolve">--mark</option>,
andre@1018:         ou <quote>unresolved</quote> en utilisant l'option <option
youshe@989:           role="hg-opt-resolve">--unmark</option>. Ceci nous autorise à
youshe@990:         nettoyer une fusion particulièrement compliquée à la main, et de
youshe@989:         garder un suivi de nos progrès avec chaque fichier pendant que nous
andre@1018:         avançons.</para>
bos@674:     </sect2>
bos@559:   </sect1>
bos@683: 
bos@683:   <sect1>
andre@1018:     <title>Des <quote>diffs</quote> plus utiles</title>
youshe@989: 
youshe@989:     <para id="x_6c7">La sortie par défaut de la commande <command
youshe@990:         role="hg-cmd">hg diff</command> est compatible rétrospectivement avec
youshe@990:       la commande régulière <command>diff</command>, mais ceci a quelques
youshe@990:       inconvénients.</para>
youshe@989: 
youshe@989:     <para id="x_6c8">Considérez le cas où nous utilisons <command role="hg-cmd">hg
youshe@989:         rename</command> pour renommer un fichier.</para>
bos@683: 
bos@683:     &interaction.ch04-diff.rename.basic;
bos@683: 
youshe@990:     <para id="x_6c9">La sortie de <command role="hg-cmd">hg diff</command>
youshe@990:       ci-dessus cache le fait que nous avons simplement renommé un fichier.
youshe@990:       La commande <command role="hg-cmd">hg diff</command> accepte l'option
youshe@989:       <option>--git</option> ou <option>-g</option> pour utiliser un nouveau
youshe@989:       format de diff qui montre ces informations sous une forme plus
youshe@989:       expressive.</para>
bos@683: 
bos@683:     &interaction.ch04-diff.rename.git;
bos@683: 
andre@1018:     <para id="x_6ca">Cette option peut aussi aider avec le cas qui peut être autrement
andre@1018:       perturbant : un fichier qui apparaît comme étant modifié en accord avec
youshe@989:       <command role="hg-cmd">hg status</command>, mais où <command
youshe@989:         role="hg-cmd">hg diff</command> n'affiche rien. Cette situation peut
youshe@989:       survenir si nous changeons les permissions d'exécution du
youshe@989:       fichier.</para>
bos@683: 
bos@683:     &interaction.ch04-diff.chmod;
bos@683: 
youshe@989:     <para id="x_6cb">La commande normale <command>diff</command> ne fait pas
youshe@989:       attention aux permissions des fichiers, ce qui explique pourquoi
youshe@989:       <command role="hg-cmd">hg diff</command> n'affiche rien du tout par
youshe@989:       défaut. Si nous lui passons l'option <option>-g</option>, ceci nous
andre@1018:       informe de ce qui s'est vraiment passé.</para>
bos@683: 
bos@683:     &interaction.ch04-diff.chmod.git;
bos@683:   </sect1>
bos@683: 
bos@683:   <sect1>
youshe@990:     <title>Quels fichiers suivre et lesquels éviter</title>
youshe@989: 
youshe@989:     <para id="x_6cc">Les systèmes de gestion de révisions sont en général
youshe@989:       meilleurs pour gérer les fichiers textes qui sont écrits par les
youshe@989:       humains, comme le code source, où les fichiers ne changent pas
youshe@989:       énormément d'une révision à l'autre. Certains systèmes de gestion de
youshe@990:       révisions centralisés peuvent aussi traiter très convenablement les
youshe@990:       fichiers binaires, tels que les images bitmap.</para>
youshe@989: 
youshe@989:     <para id="x_6cd">Par exemple, une équipe de développement de jeux va
youshe@990:       probablement gérer les deux types : ses codes source et tous ses binaires
youshe@989:       (ex. données géométriques, textures, schémas de cartes) dans un système
youshe@989:       de contrôle de révisions.</para>
youshe@989:     <!-- Vérifier la traduction de map layouts que j'ai traduit par schémas
youshe@989:     de cartes -->
youshe@989: 
youshe@989:     <para id="x_6ce">Puisqu'il est d'habitude impossible de fusionner (merge)
youshe@989:       deux modifications conflictuelles sur un fichier binaire, les systèmes
youshe@990:       de version centralisés offrent souvent un mécanisme de verrou (lock) qui
youshe@989:       permet à un utilisateur de dire <quote>Je suis la seule personne qui
youshe@989:         peut éditer ce fichier</quote>.</para>
youshe@989: 
youshe@990:     <para id="x_6cf">En comparaison avec un système centralisé, un système
youshe@989:       décentralisé de gestion de révision change certains facteurs qui
youshe@989:       guident les décisions sur quels fichiers gérer et comment.</para>
youshe@989: 
youshe@990:     <para id="x_6d0">Par exemple, un système distribué de gestion de révisions
andre@1018:       ne peut pas, par sa nature, offrir un système de verrou (lock) sur les
youshe@990:       fichiers. Il n'y a donc pas de mécanisme inclus pour empêcher deux
youshe@989:       personnes de faire des modifications conflictuelles sur un fichier
youshe@989:       binaire. Si vous avez une équipe où plusieurs personnes peuvent souvent
youshe@989:       éditer un fichier binaire, cela ne serait pas une très bonne idée
youshe@990:       d'utiliser Mercurial &emdash;ou tout autre système distribué de gestion
youshe@989:       de révisions&emdash;pour gérer ces fichiers.</para>
youshe@989: 
youshe@989:     <para id="x_6d1">Lorsque vous sauvegardez les modifications sur un
youshe@989:       fichier, Mercurial ne sauvegarde d'habitude que les différences entre
youshe@989:       la version précédente et la version actuelle d'un fichier. Pour la
youshe@989:       plupart des fichiers texte, ceci est très efficace. Cependant, certains
youshe@989:       fichiers (en particulier les fichiers binaires) sont construits d'une
youshe@989:       façon que même un petit changement sur un contenu logique résulte sur
youshe@989:       un changement de la plupart des octets du fichier. Par exemple, les
youshe@990:       fichiers compressés sont particulièrement sujets à ce comportement. Si
youshe@990:       les différences entre deux versions successives d'un fichier sont
youshe@990:       toujours très grandes, Mercurial ne sera pas capable de sauvegarder
youshe@990:       l'historique des révisions sur le fichier très efficacement. Ceci peut
youshe@990:       affecter aussi bien les besoins pour la sauvegarde locale que le temps
youshe@990:       nécessaire à cloner le dépôt.</para>
youshe@989: 
youshe@989:     <para id="x_6d2">Pour avoir une idée de comment ceci pourrait vous
youshe@989:       affecter en pratique, supposez que nous voulions que Mercurial gère des
youshe@989:       documents OpenOffice. OpenOffice sauvegarde les documents sur le disque
youshe@989:       comme des fichiers compressés zip. Même le fait d'éditer ces fichiers
youshe@989:       d'une seule lettre, changera les bits de la quasi totalité du fichier
youshe@989:       lorsque vous le sauvegarderez. Maintenant, supposez que ce fichier
andre@1018:       fasse une taille de 2 Mo. Puisque la plupart du fichier change à chaque
andre@1018:       fois que vous sauvegardez, Mercurial aura à sauvegarder tous les 2 Mo du
youshe@989:       fichier à chaque commit, alors que de votre point de vue, il n'y a
youshe@990:       que peu de mots qui changent à chaque fois. Un seul fichier
youshe@990:       souvent édité qui n'est pas bien traité par les hypothèses que Mercurial
youshe@989:       fait sur les sauvegardes peut facilement avoir un effet colossal sur la
youshe@989:       taille du dépôt.</para>
youshe@989: 
youshe@989:     <para id="x_6d3">Même pire, si vous et quelqu'un d'autre éditez le même
youshe@989:       document OpenOffice sur lequel vous travaillez, il n'y a pas de façon
youshe@989:       utile pour fusionner votre travail. En fait, il n'y a pas de moyen
youshe@989:       utile de montrer que les différences sont faites à partir de votre
youshe@989:       vision des modifications.</para>
youshe@989: 
youshe@990:     <para id="x_6d4">Il y a ainsi quelques recommandations claires sur les
youshe@989:       types de fichiers spécifiques avec lesquels faire très
youshe@989:       attention.</para>
bos@683: 
bos@683:     <itemizedlist>
youshe@989:       <listitem><para id="x_6d5">Les fichier qui sont très gros et
youshe@990:           incompressibles, comme les images ISO de CD-ROM, sont, par
youshe@989:           construction très gros et les cloner à travers un réseau sera très
youshe@989:           long.</para></listitem>
youshe@990:      <!-- TODO : Trouver une meilleure traduction pour : ISO CD-ROM images, will by
youshe@989:      virtue of sheer size make clones over a network very slow. -->
youshe@989:       <listitem><para id="x_6d6">Les fichiers qui changent beaucoup d'une
andre@1018:           révision à l'autre peuvent être très coûteux à sauvegarder si vous
youshe@990:           les éditez fréquemment, de même que les conflits entre deux éditions
youshe@989:           concurrentes peuvent être difficiles à résoudre.</para>
bos@683:       </listitem>
bos@683:     </itemizedlist>
bos@683:   </sect1>
bos@683: 
bos@683:   <sect1>
youshe@989:     <title>Sauvegardes et miroirs</title>
youshe@989: 
youshe@989:     <para id="x_6d7">Puisque Mercurial maintient une copie complète de
youshe@989:       l'historique de chaque clone, toute personne qui utilise Mercurial pour
youshe@989:       collaborer à un projet peut potentiellement agir comme une source de
youshe@990:       sauvegarde si une catastrophe survenait. Si un dépôt central devient
youshe@989:       indisponible, vous pouvez construire un remplaçant en clonant une copie
youshe@989:       du dépôt à partir d'un des contributeurs en récupérant (pull) tous les
youshe@989:       changements qui n'auraient pas été vus par les autres.</para>
youshe@989: 
youshe@989:     <para id="x_6d8">Il est simple d'utiliser Mercurial pour construire des
youshe@989:       serveurs hors site de sauvegarde et des miroirs distants. Initiez une
youshe@989:       tâche périodique (ex. via la commande <command>cron</command>) sur un
youshe@989:       serveur distant pour récupérer (pull) les changements de votre dépôt
youshe@990:       distant chaque heure. Ceci sera difficile seulement dans le cas
youshe@989:       improbable où le nombre des dépôts maîtres que vous maintenez change
youshe@989:       souvent, auquel cas vous aurez besoin de faire un peu de scripting pour
andre@1018:       rafraichir la liste des dépôts à sauvegarder.</para>
youshe@989: 
youshe@989:     <para id="x_6d9">Si vous exécutez des sauvegardes traditionnelles de
youshe@990:       votre dépôt maître sur bande ou disque, et que vous voulez sauvegarder
youshe@990:       un dépôt nommé <filename>myrepo</filename>, utilisez la commande
youshe@990:       <command>hg clone -U myrepo myrepo.bak</command> pour créer un clone de
youshe@990:       <filename>myrepo</filename> avant de commencer vos backups.
youshe@989:       L'option <option>-U</option> ne crée pas de répertoire de travail après
youshe@989:       que le clone soit accompli, puisque ceci serait superflu et ferait que
youshe@989:       la sauvegarde prenne plus de temps.</para>
youshe@989: 
youshe@989:     <para id="x_6da">Si vous voulez ensuite sauvegarder
youshe@989:       <filename>myrepo.bak</filename> au lieu de <filename>myrepo</filename>,
andre@1018:       vous aurez la garantie d'avoir une image (snapshot) cohérente de
youshe@990:       votre dépôt sur lequel un développeur insomniaque n'enverra (push) pas de
youshe@989:       changements en milieu de sauvegarde.</para>
bos@683:   </sect1>
bos@559: </chapter>
bos@559: 
bos@559: <!--
bos@559: local variables: 
bos@559: sgml-parent-document: ("00book.xml" "book" "chapter")
bos@559: end:
bos@559: -->