belaran@964: <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
belaran@964:
bos@559: <chapter id="chap:concepts">
bos@572: <?dbhtml filename="behind-the-scenes.html"?>
youshe@993: <title>Derrière le décor</title>
youshe@993:
wilk@1008: <para id="x_2e8">À la différence de beaucoup d'outils de gestion de révisions,
youshe@993: les concepts sur lesquels se base Mercurial sont assez simples pour
youshe@993: qu'il soit facile de comprendre comment le logiciel fonctionne.
wilk@1008: Bien que leur connaissance ne soit pas indispensable, je trouve utile
youshe@993: d'avoir un <quote>modèle mental</quote> de ce qui se passe.</para>
youshe@993:
youshe@993: <para id="x_2e9">En effet, cette compréhension m'apporte la confiance que
youshe@993: Mercurial a été développé avec soin pour être à la fois
youshe@993: <emphasis>sûr</emphasis> et <emphasis>efficace</emphasis>. De surcroît,
wilk@1008: s'il m'est facile de garder en tête ce que le logiciel fait lorsque
andre@1017: j'accomplis des tâches de révision, j'aurai moins de risques d'être
youshe@993: surpris par son comportement.</para>
youshe@993:
youshe@993: <para id="x_2ea">Dans ce chapitre, nous décrirons tout d'abord les concepts
youshe@993: essentiels de l'architecture de Mercurial, pour ensuite discuter quelques
andre@1017: détails intéressants de son implémentation.</para>
bos@559:
bos@559: <sect1>
youshe@993: <title>Conservation de l'historique sous Mercurial</title>
youshe@993: <sect2>
youshe@993: <title>Suivi de l'historique pour un seul fichier</title>
youshe@993:
youshe@993: <para id="x_2eb">Lorsque Mercurial effectue un suivi des modifications
youshe@993: faites à un fichier, il conserve l'historique pour ce fichier dans un
youshe@993: <emphasis>filelog</emphasis> sous forme de métadonnées. Chaque entrée
wilk@1008: dans le <quote>filelog</quote> contient assez d'informations pour reconstituer une
wilk@1008: révision du fichier correspondant. Les <quote>filelogs</quote> sont des fichiers
youshe@993: stockés dans le répertoire <filename role="special"
wilk@1008: class="directory">.hg/store/data</filename>. Un <quote>filelog</quote> contient
andre@1017: des informations de deux types : les données de révision, et un index
youshe@993: pour permettre à Mercurial une recherche efficace d'une révision
youshe@993: donnée.</para>
youshe@993:
youshe@993: <para id="x_2ec">Lorsqu'un fichier devient trop gros ou a un long
wilk@1008: historique, son <quote>filelog</quote> se voit stocké dans un fichier de données
youshe@993: (avec un suffixe <quote><literal>.d</literal></quote>) et un fichier
youshe@993: index (avec un suffixe<quote><literal>.i</literal></quote>)
youshe@993: distincts. La relation entre un fichier dans le répertoire de travail
wilk@1008: et le <quote>filelog</quote> couvrant le suivi de son historique dans le dépôt est
youshe@993: illustré à la figure <xref linkend="fig:concepts:filelog"/>.</para>
bos@559:
bos@591: <figure id="fig:concepts:filelog">
youshe@993: <title>Relations entre les fichiers dans le répertoire de travail et
wilk@1008: leurs <quote>filelogs</quote> dans le dépôt</title>
youshe@993: <mediaobject> <imageobject><imagedata
youshe@993: fileref="figs/filelog.png"/></imageobject>
youshe@993: <textobject><phrase>XXX add text</phrase></textobject>
youshe@993: </mediaobject> </figure>
youshe@993:
youshe@993: </sect2>
youshe@993: <sect2>
youshe@993: <title>Gestion des fichiers suivis</title>
youshe@993:
youshe@993: <para id="x_2ee">Mercurial a recours à une structure nommée
youshe@993: <emphasis>manifest</emphasis> pour rassembler les informations sur
wilk@1008: les fichiers dont il gère le suivi. Chaque entrée dans ce <quote>manifest</quote>
youshe@993: contient des informations sur les fichiers présents dans une révision
youshe@1001: donnée. Une entrée enregistre la liste des fichiers faisant partie de la
youshe@993: révision, la version de chaque fichier, et quelques autres
youshe@993: métadonnées sur ces fichiers.</para>
bos@559:
bos@559: </sect2>
bos@559: <sect2>
wilk@1008: <title>Enregistrer les informations des <quote>changesets</quote></title>
youshe@1001:
youshe@1001: <para id="x_2ef">Le <emphasis>changelog</emphasis> contient les
wilk@1008: informations sur chaque <quote>changeset</quote>. Chaque révision enregistre qui a
wilk@1008: <quote>committé</quote> un changement, le commentaire du <quote>changeset</quote>, d'autres
wilk@1008: morceaux d'information relatives au <quote>changeset</quote> et la révision du
wilk@1008: <quote>manifest</quote> à utiliser.</para>
youshe@1001:
youshe@1001: </sect2>
youshe@1001: <sect2>
youshe@1001: <title>Relations entre les révisions</title>
youshe@1001:
andre@1017: <para id="x_2f0">À l'intérieur d'un <quote>changelog</quote>, d'un <quote>manifest</quote>, ou d'un
wilk@1008: <quote>filelog</quote>, chaque révision enregistre un pointeur vers son parent
youshe@1001: immédiat (ou à ses deux parents s'il s'agit d'une révision
youshe@1001: correspondant à une fusion (merge)). Comme mentionné plus haut, il y
youshe@1001: a aussi des relations entre les révisions <emphasis>à
youshe@1001: travers</emphasis> ces structures, qui sont de nature
youshe@1001: hiérarchique.</para>
youshe@1001:
wilk@1008: <para id="x_2f1">Pour chaque <quote>changeset</quote> dans un dépôt, il y a exactement
wilk@1008: une révision stockée dans le <quote>changelog</quote>. Chaque révision du <quote>changelog</quote>
wilk@1008: contient un pointeur vers une unique révision du <quote>manifest</quote>. Une
wilk@1008: révision du <quote>manifest</quote> garde un pointeur vers une unique révision pour
wilk@1008: chaque <quote>filelog</quote> suivi lorsque le <quote>changeset</quote> est créé. Ces relations
youshe@1001: sont illustrées dans <xref linkend="fig:concepts:metadata"/>.</para>
bos@559:
bos@591: <figure id="fig:concepts:metadata">
youshe@1001: <title>Metadata relationships</title>
youshe@1001: <mediaobject> <imageobject><imagedata
youshe@1001: fileref="figs/metadata.png"/></imageobject>
youshe@1001: <textobject><phrase>XXX add text</phrase></textobject>
youshe@1001: </mediaobject>
bos@591: </figure>
bos@559:
wilk@1008: <para id="x_2f3">Comme l'illustration le montre, il
youshe@1001: <emphasis>n'</emphasis>y a <emphasis>pas</emphasis> de relation
wilk@1008: <quote>un à un</quote> entre les révisions dans un <quote>changelog</quote>,
wilk@1008: <quote>manifest</quote> ou <quote>filelog</quote>. Si un fichier que Mercurial suit n'a pas changé
wilk@1008: entre deux <quote>changesets</quote>, l'entrée pour ce fichier dans les deux
wilk@1008: révisions du <quote>manifest</quote> pointera vers la même révision de son <quote>filelog</quote>
youshe@1001: <footnote> <para id="x_725">Il est possible (bien qu'inhabituel)
wilk@1008: qu'un <quote>manifest</quote> reste le même entre deux <quote>changesets</quote>, auquel cas
wilk@1008: l'entrée du <quote>changelog</quote> pour ces <quote>changesets</quote> pointera vers la même
wilk@1008: révision du <quote>manifest</quote>.</para>
youshe@1001: </footnote>.</para>
bos@559:
bos@559: </sect2>
bos@559: </sect1>
bos@559: <sect1>
youshe@1001: <title>Stockage sûr et efficace</title>
youshe@1001:
wilk@1008: <para id="x_2f4">Les fondements des <quote>changelogs</quote>, des <quote>manifests</quote> et des
wilk@1008: <quote>filelogs</quote> sont fournis par une unique structure appelée le
bos@559: <emphasis>revlog</emphasis>.</para>
bos@559:
bos@559: <sect2>
andre@1017: <title>Stockage efficace</title>
youshe@1001:
wilk@1008: <para id="x_2f5">Le <quote>revlog</quote> fournit un stockage efficace des révisions en
andre@1017: utilisant un mécanisme <emphasis>delta</emphasis>. Au lieu de stocker
youshe@1001: une copie complète d'un fichier à chaque révision, il stocke les
wilk@1008: changements requis pour transformer une révision plus ancienne en une
andre@1017: nouvelle révision. Pour plusieurs types de données, ces deltas sont
youshe@1001: typiquement une fraction de pourcentage de la taille de la copie
youshe@1001: complète d'un fichier.</para>
youshe@1001:
wilk@1008: <para id="x_2f6">Certains systèmes de gestion de révisions obsolètes
youshe@1001: peuvent seulement travailler avec les deltas de fichiers texte. Il
youshe@1001: doivent d'ailleurs stocker les fichiers binaires comme des images
youshe@1001: complètes ou encodées avec une représentation texte, chacune de ces
youshe@1001: approches étant gaspilleuse. Mercurial peut traiter les deltas de
youshe@1001: fichiers avec du contenu binaire arbitraire ; il n'a pas besoin de
youshe@1001: traiter spécialement du texte.</para>
bos@559:
bos@559: </sect2>
bos@559: <sect2 id="sec:concepts:txn">
youshe@1001: <title>Opérations sûres</title>
youshe@1001:
youshe@1001: <para id="x_2f7">Mercurial <emphasis>empile</emphasis> toujours les
wilk@1008: données à la fin d'un fichier <quote>revlog</quote>. Il ne modifie jamais la section
wilk@1008: d'un fichier après qu'il l'ait écrite. C'est à la fois plus robuste
youshe@1001: et efficace que les schémas qui ont besoin de modifier ou réécrire
youshe@1001: les données.</para>
youshe@1001:
wilk@1008: <para id="x_2f8">De plus, Mercurial traite chaque écriture comme la
youshe@1001: partie d'une <emphasis>transaction</emphasis> qui peut comprendre
youshe@1001: plusieurs fichiers. Une transaction est <emphasis>atomique</emphasis>
andre@1017: : soit la transaction entière réussit et ses effets sont tous
youshe@1001: visibles aux lecteurs en une étape, soit la totalité est annulée.
youshe@1001: Cette garantie de l'atomicité signifie que si vous exécutez deux
youshe@1001: copies de Mercurial, où une lit les données et l'autre les écrit, le
youshe@1001: lecteur ne verra jamais un résultat partiellement écrit qui pourrait
youshe@1001: le perturber.</para>
youshe@1001:
youshe@1001: <para id="x_2f9">Le fait que Mercurial ne fasse qu'ajouter aux fichiers
youshe@1001: fait qu'il est facile de fournir cette garantie de transaction. Plus
youshe@1001: les choses sont faites simplement comme ça, plus vous pouvez être
youshe@1001: rassurés qu'elles sont bien faites.</para>
youshe@1001:
youshe@1001: </sect2>
youshe@1001: <sect2>
youshe@1001: <title>Récupération rapide</title>
youshe@1001:
youshe@1001: <para id="x_2fa">Mercurial évite habillement un piège commun à tous les
youshe@1001: vieux systèmes de gestion de révisions : le problème de la
andre@1017: <emphasis>récupération inefficace</emphasis>. La plupart des systèmes
youshe@1001: de gestion de révisions stockent le contenu d'une révision comme une
youshe@1001: série incrémentale de modifications faites à un
wilk@1008: <quote>snapshot</quote>. (Certains basent le <quote>snapshot</quote> sur la plus
youshe@1001: vieille révision, d'autres sur la plus récente.) Pour reconstruire
wilk@1008: une révision spécifique, vous devez d'abord lire le <quote>snapshot</quote>, et
wilk@1008: ensuite toutes les révisions entre le <quote>snapshot</quote> et votre révision
youshe@1001: cible. Plus vous avez d'historique accumulé dans un fichier, plus de
youshe@1001: révisions vous avez à lire, d'où la longueur que cela prend à
youshe@1001: reconstruire une révision particulière.</para>
bos@559:
bos@591: <figure id="fig:concepts:snapshot">
wilk@1008: <title><quote>Snapshot</quote> d'un <quote>revlog</quote>, avec des deltas incrémentaux</title>
youshe@1001: <mediaobject> <imageobject><imagedata
youshe@1001: fileref="figs/snapshot.png"/></imageobject>
youshe@1001: <textobject><phrase>XXX add text</phrase></textobject>
youshe@1001: </mediaobject>
bos@591: </figure>
bos@559:
andre@1017: <para id="x_2fc">L'innovation que Mercurial apporte à ce problème est
andre@1017: simple mais efficace. Une fois que la quantité cumulée de deltas
youshe@1001: d'informations stockées depuis le dernier snapshot excède un seuil
wilk@1008: fixé, il stocke un nouveau <quote>snapshot</quote> (compressé bien sûr), plutôt qu'un
youshe@1001: nouveau delta. Ceci rend possible la reconstruction de
youshe@1001: <emphasis>toute</emphasis> révision d'un fichier rapidement. Cette
youshe@1001: approche fonctionne si bien que depuis, elle a été copiée par
youshe@1001: plusieurs autres systèmes de gestion de révisions.</para>
youshe@1001:
youshe@1001: <para id="x_2fd"><xref linkend="fig:concepts:snapshot"/> illustre
wilk@1008: l'idée. Dans une entrée d'un fichier d'index de <quote>revlog</quote>, Mercurial
wilk@1008: stocke l'intervalle des entrées depuis le fichier de données qu'il doit
youshe@1001: lire pour reconstruire une révision particulière.</para>
bos@559:
bos@559: <sect3>
andre@1017: <title>Aparté : l'influence de la compression vidéo</title>
youshe@1001:
youshe@1001: <para id="x_2fe">Si vous êtes familiés de la compression vidéo ou
andre@1017: avez déjà regardé un programme TV par câble ou par un service
youshe@1001: satellite, vous devez savoir que la plupart des schémas de
andre@1017: compression vidéo stockent chaque trame de vidéo comme un delta
andre@1017: vis-à-vis de la trame précédente.</para>
youshe@1001:
youshe@1001: <para id="x_2ff">Mercurial emprunte cette idée pour rendre possible
youshe@1001: la reconstruction d'une révision à partir d'un snapshot et d'un
youshe@1001: petit nombre de deltas.</para>
bos@559:
bos@559: </sect3>
bos@559: </sect2>
bos@559: <sect2>
youshe@1001: <title>Identification et intégrité forte</title>
youshe@1001:
youshe@1001: <para id="x_300">Avec les deltas ou l'information du snapshot, une
youshe@1001: entrée d'un revlog contient un hash cryptographique des données qu'il
youshe@1001: représente. Ceci fait qu'il est difficile de construire les données
youshe@1001: d'une révision, mais facile de détecter une corruption
youshe@1001: accidentelle.</para>
youshe@1001:
youshe@1001: <para id="x_301">Les hash fournissent plus qu'un bon moyen de
youshe@1001: vérification contre la corruption ; il sont aussi utilisés comme
wilk@1008: identifiants pour les révisions. Les <quote>hashs</quote> d'identifications d'un
wilk@1008: <quote>changeset</quote> que vous voyez comme utilisateur final proviennent des
wilk@1008: révisions du <quote>changelog</quote>. Bien que les <quote>filelogs</quote> et le <quote>manifest</quote>
andre@1017: utilisent aussi des <quote>hashs</quote>, Mercurial ne les utilise qu'en
andre@1017: arrière-plan.</para>
youshe@1001:
wilk@1008: <para id="x_302">Mercurial vérifie que les <quote>hashs</quote> sont corrects lorsqu'il
youshe@1001: récupère les révisions de fichiers et lorsqu'il récupère (pull) les
youshe@1001: changements d'un autre dépôt. S'il rencontre un problème d'intégrité,
wilk@1008: il se plaindra et arrêtera tout ce qu'il est en train de faire.</para>
youshe@1001:
youshe@1001: <para id="x_303">En plus de l'effet qu'il a sur l'efficacité des
wilk@1008: récupérations, l'utilisation par Mercurial de <quote>snapshots</quote> périodiques
youshe@1001: fait qu'il est plus robuste contre la corruption partielle de
wilk@1008: données. Si un <quote>revlog</quote> devient partiellement corrompu à cause d'une
youshe@1001: erreur matérielle ou d'un bug système, il est souvent possible de
youshe@1001: reconstruire certaines ou la plupart des révisions à partir des
wilk@1008: sections non corrompues du <quote>revlog</quote>, avant et après la section
youshe@1001: corrompue. Ceci ne serait pas possible à partir d'un modèle de
wilk@1008: stockage de deltas seul.</para>
bos@559: </sect2>
bos@559: </sect1>
bos@701:
bos@559: <sect1>
youshe@1001: <title>Historique des révisions, branches et fusions (merge)</title>
youshe@1001:
wilk@1008: <para id="x_304">Chaque entrée dans un <quote>revlog</quote> Mercurial connaît
wilk@1008: l'identité de l'ancêtre immédiat de la révision, habituellement désignée
youshe@1001: comme son <emphasis>parent</emphasis>. En fait, une révision contient
youshe@1001: de la place pour non pas un parent, mais deux. Mercurial utilise un
wilk@1008: <quote>hash</quote> spécial, appelé le <quote>null ID</quote> pour représenter l'idée
wilk@1008: qu'<quote>il n'y a pas de parent ici</quote>. Ce <quote>hash</quote> est simplement
youshe@1001: une chaîne de zéros.</para>
youshe@1001:
youshe@1001: <para id="x_305">Dans <xref linkend="fig:concepts:revlog"/>, vous pouvez
wilk@1008: voir un exemple de la structure conceptuelle d'un <quote>revlog</quote>. Les <quote>filelogs</quote>,
wilk@1008: <quote>manifests</quote> et <quote>changelogs</quote> ont tous cette même structure ; ils diffèrent
youshe@1001: simplement dans le type de donnée stockée dans chaque delta ou
wilk@1008: <quote>snapshot</quote>.</para>
wilk@1008:
wilk@1008: <para id="x_306">La première révision d'un <quote>revlog</quote> (au bas de l'image) a
wilk@1008: le <quote>null ID</quote> dans chacune de ses cases parent. Pour une révision
youshe@1001: <quote>normale</quote>, sa première case parent contient l'ID de sa
wilk@1008: révision parent et la seconde contient le <quote>null ID</quote>, indiquant que cette
youshe@1001: révision n'a qu'un seul vrai parent. Si deux révisions ont le même
youshe@1001: parent, il s'agit de branches. Une révision qui représente une fusion
youshe@1001: (merge) entre deux branches a deux identifiants de révision normaux
youshe@1001: dans ses cases parents.</para>
bos@559:
bos@591: <figure id="fig:concepts:revlog">
wilk@1008: <title>Le concept de la structure d'un <quote>revlog</quote></title>
youshe@1001: <mediaobject> <imageobject><imagedata
youshe@1001: fileref="figs/revlog.png"/></imageobject> <textobject><phrase>XXX
youshe@1001: add text</phrase></textobject>
bos@591: </mediaobject>
bos@591: </figure>
bos@559:
bos@559: </sect1>
bos@559: <sect1>
youshe@1001: <title>Le répertoire de travail</title>
youshe@1001:
wilk@1008: <para id="x_307">Dans un répertoire de travail, Mercurial stocke une image
wilk@1008: des fichiers du dépôt à un <quote>changeset</quote> particulier.</para>
youshe@1001:
youshe@1001: <para id="x_308">Le répertoire de travail <quote>sait</quote> quel
wilk@1008: <quote>changeset</quote> il contient. Lorsque vous mettez à jour (update) le
wilk@1008: répertoire de travail à un certain <quote>changeset</quote>, Mercurial regarde la
wilk@1008: révision appropriée du <quote>manifest</quote> pour trouver quels fichiers il suivait
wilk@1008: au moment où le <quote>changeset</quote> a été <quote>committé</quote>, et quelle révision de chaque
youshe@1001: fichier était alors courante. Il recrée ensuite une copie de chacun de
wilk@1008: ces fichiers, avec le même contenu qu'ils avaient lorsque le <quote>changeset</quote>
wilk@1008: a été <quote>committé</quote>.</para>
youshe@1001:
youshe@1001: <para id="x_309">La structure spéciale <emphasis>dirstate</emphasis>
youshe@1001: contient la connaissance de Mercurial sur le répertoire de travail.
youshe@1001: Elle est maintenue par un fichier appelé
youshe@1001: <filename>.hg/dirstate</filename> dans un dépôt. Les détails du
wilk@1008: dirstate sont le <quote>changeset</quote> vers lequel le répertoire de travail se met
youshe@1001: à jour (update), et tous les fichiers que Mercurial suit dans le
wilk@1008: répertoire de travail. Il permet aussi à Mercurial de connaître
wilk@1008: rapidement les fichiers modifiés, en enregistrant l'heure de
wilk@1008: dernière modification et la taille de chacun.</para>
wilk@1008:
wilk@1008: <para id="x_30a">Puisqu'une révision de <quote>revlog</quote> a des emplacements pour
youshe@1001: deux parents et peut représenter aussi bien une révision normale (avec
wilk@1008: un parent) ou une fusion de deux révisions anciennes, le <quote>dirstate</quote> a des
youshe@1001: emplacements pour deux parents. Lorsque vous utilisez la commande
wilk@1008: <command role="hg-cmd">hg update</command>, le <quote>changeset</quote> que vous
youshe@1001: mettez à jour est stocké dans l'emplacement du <quote>premier
wilk@1008: parent</quote>, et le <quote>null ID</quote> l'est dans le second. Lorsque vous
youshe@1001: utilisez la commande <command role="hg-cmd">hg merge</command> avec un
youshe@1001: autre changeset, le premier parent reste inchangé, et le second est
wilk@1008: rempli avec le <quote>changeset</quote> à partir duquel vous êtes en train de
youshe@1001: fusionner. La commande <command role="hg-cmd">hg parents</command> vous
youshe@1001: donne les parents du dirstate.</para>
youshe@1001:
youshe@1001: <sect2>
andre@1017: <title>Que se passe-t-il lorsque vous <quote>committez</quote></title>
wilk@1008:
wilk@1008: <para id="x_30b">Le <quote>dirstate</quote> stocke les informations sur les parents
andre@1017: pour plus qu'une simple comptabilité. Mercurial utilise les
andre@1017: parents du <quote>dirstate</quote> comme <emphasis>les parents d'un nouveau
wilk@1008: <quote>changeset</quote></emphasis> lorsque vous <quote>committez</quote>.</para>
youshe@1001:
youshe@1001: <figure id="fig:concepts:wdir">
youshe@1001: <title>Le répertoire de travail peut avoir deux parents</title>
youshe@1001: <mediaobject>
youshe@1001: <imageobject><imagedata fileref="figs/wdir.png"/></imageobject>
youshe@1001: <textobject><phrase>XXX add text</phrase></textobject></mediaobject>
bos@591: </figure>
bos@559:
youshe@1001: <para id="x_30d"><xref linkend="fig:concepts:wdir"/> montre l'état
wilk@1008: normal d'un répertoire de travail, où il n'y a qu'un seul <quote>changeset</quote>
wilk@1008: comme parent. Ce <quote>changeset</quote> est le <emphasis>tip</emphasis>, le
wilk@1008: <quote>changeset</quote> le plus récent dans le dépôt n'a pas d'enfant.</para>
bos@559:
bos@591: <figure id="fig:concepts:wdir-after-commit">
youshe@1001: <title>Le répertoire de travail gagne de nouveaux parents après un
wilk@1008: <quote>commit</quote></title>
youshe@1001: <mediaobject>
youshe@1001: <imageobject><imagedata
youshe@1001: fileref="figs/wdir-after-commit.png"/></imageobject>
youshe@1001: <textobject><phrase>XXX add text</phrase></textobject>
youshe@1001: </mediaobject>
bos@591: </figure>
bos@559:
wilk@1008: <para id="x_30f">On peut se représenter le répertoire de travail comme
wilk@1008: <quote>le changeset que je vais committer</quote>. Chaque fichier
wilk@1008: que vous demandez à Mercurial d'ajouter, de supprimer, de renommer ou de
wilk@1008: copier va être intégré dans ce changeset, tout comme les
youshe@1001: modifications de n'importe quel fichier que Mercurial est déjà en
wilk@1008: train de suivre ; le nouveau <quote>changeset</quote> aura les mêmes parents que le
youshe@1001: répertoire de travail.</para>
youshe@1001:
youshe@1001: <para id="x_310">Après un commit, Mercurial va mettre à jour les
wilk@1008: parents du répertoire de travail, ainsi, le premier parent est l'ID
wilk@1008: du nouveau <quote>changeset</quote>, et le second, le <quote>null ID</quote>. Ceci est illustré dans
youshe@1001: <xref linkend="fig:concepts:wdir-after-commit"/>. Mercurial ne touche
wilk@1008: à aucun des fichiers du répertoire de travail lorsque vous <quote>committez</quote>
youshe@1001: ; il modifie simplement le dirstate pour noter ses nouveaux
youshe@1001: parents.</para>
youshe@1001:
youshe@1001: </sect2>
youshe@1001: <sect2>
youshe@1001: <title>Création d'une nouvelle <quote>head</quote></title>
youshe@1001:
wilk@1008: <para id="x_311">Il est parfaitement normal de faire un <quote>update</quote> du
wilk@1008: répertoire de travail à un <quote>changeset</quote> autre que le <quote>tip</quote> courant. Par
wilk@1008: exemple, vous pourriez vouloir savoir à quoi votre projet
wilk@1008: ressemblait mardi dernier, ou regarder le <quote>changeset</quote> qui a
youshe@1001: introduit un bug. Dans des cas comme ça, la chose naturelle à faire
wilk@1008: est de faire un <quote>update</quote> du répertoire de travail au <quote>changeset</quote> qui vous
youshe@1001: intéresse, et ensuite d'en examiner les fichiers pour regarder leurs
andre@1017: contenus comme ils l'étaient lorsque vous avez <quote>committé</quote> ce <quote>changeset</quote>.
youshe@1001: L'effet de ceci est montré dans <xref
youshe@1001: linkend="fig:concepts:wdir-pre-branch"/>.</para>
bos@559:
bos@591: <figure id="fig:concepts:wdir-pre-branch">
wilk@1008: <title>Le répertoire de travail, <quote>updaté</quote> pour un <quote>changeset</quote> plus
youshe@1001: ancien</title>
youshe@1001: <mediaobject> <imageobject><imagedata
youshe@1001: fileref="figs/wdir-pre-branch.png"/></imageobject>
youshe@1001: <textobject><phrase>XXX add text</phrase></textobject>
youshe@1001: </mediaobject>
bos@591: </figure>
bos@559:
wilk@1008: <para id="x_313">En ayant fait un <quote>update</quote> du répertoire de travail vers
andre@1017: un <quote>changeset</quote> plus ancien, que se passe-t-il si vous faites des
wilk@1008: changements et ensuite <quote>committez</quote> ? Mercurial se comporte comme je
youshe@1001: l'ai fait remarqué plus haut. Les parents du répertoire de travail
wilk@1008: deviennent les parents du nouveau <quote>changeset</quote>. Ce nouveau <quote>changeset</quote> n'a
wilk@1008: pas d'enfant, donc il devient le nouveau <quote>tip</quote>. Le dépôt contient
wilk@1008: maintenant deux <quote>changesets</quote> qui n'ont pas d'enfant ; on appelle ceci
wilk@1008: des <emphasis>heads</emphasis>. Vous pouvez voir la structure que
youshe@1001: cela crée dans <xref linkend="fig:concepts:wdir-branch"/>.</para>
bos@559:
bos@591: <figure id="fig:concepts:wdir-branch">
wilk@1008: <title>Après un <quote>commit</quote> fait pendant la synchronisation avec un ancien
wilk@1008: <quote>changeset</quote></title>
youshe@1001: <mediaobject> <imageobject><imagedata
youshe@1001: fileref="figs/wdir-branch.png"/></imageobject>
youshe@1001: <textobject><phrase>XXX add text</phrase></textobject>
youshe@1001: </mediaobject>
bos@591: </figure>
bos@559:
bos@559: <note>
andre@1017: <para id="x_315">Si vous êtes un nouvel utilisateur de Mercurial, vous devez garder
youshe@1001: à l'esprit une <quote>erreur</quote> commune, qui est d'utiliser la
youshe@1001: commande <command role="hg-cmd">hg pull</command> sans aucune
youshe@1001: option. Par défaut, la commande <command role="hg-cmd">hg
wilk@1008: pull</command> <emphasis>ne fait pas</emphasis> d'<quote>update</quote> sur le
youshe@1001: répertoire de travail, ainsi, vous allez récupérer les nouveaux
youshe@1001: changesets dans votre dépôt, mais le répertoire de travail va
wilk@1008: rester synchronisé au même <quote>changeset</quote> qu'il l'était avant le <quote>pull</quote>.
wilk@1008: Si vous faites des changements et <quote>committez</quote> ensuite, vous allez
wilk@1008: créer une nouvelle <quote>head</quote> puisque votre répertoire de travail n'est
wilk@1008: pas synchronisé au <quote>tip</quote> actuel. Pour combiner les
wilk@1008: opérations d'un <quote>pull</quote> suivi d'un <quote>update</quote>, exécutez <command>hg
youshe@1001: pull -u</command>.</para>
youshe@1001:
youshe@1001: <para id="x_316">Je place le mot <quote>erreur</quote> entre
andre@1017: guillemets parce que tout ce dont vous avez besoin de faire pour
wilk@1008: rectifier la situation où vous avez créé une nouvelle <quote>head</quote> par
youshe@1001: accident est un <command role="hg-cmd">hg merge</command> suivi
youshe@1001: d'un <command role="hg-cmd">hg commit</command>. En d'autres mots,
youshe@1001: ceci n'a presque jamais de conséquences négatives ; il s'agit juste
youshe@1001: d'une surprise pour les nouveaux arrivants. Je discuterai d'autres
youshe@1001: moyens d'éviter ce comportement, et pourquoi Mercurial agit de
youshe@1001: cette façon surprenante plus tard.</para>
bos@559: </note>
bos@559:
bos@559: </sect2>
bos@559: <sect2>
youshe@1001: <title>Fusionner (merge) les changements</title>
youshe@1001:
youshe@1001: <para id="x_317">Lorsque vous exécutez la commande <command
youshe@1001: role="hg-cmd">hg merge</command>, Mercurial laisse le premier
youshe@1001: parent du répertoire de travail inchangé et fixe le second au
wilk@1008: <quote>changeset</quote> avec lequel vous fusionnez (merge), comme montré dans <xref
youshe@1001: linkend="fig:concepts:wdir-merge"/>.</para>
bos@559:
bos@591: <figure id="fig:concepts:wdir-merge">
wilk@1008: <title>Fusionner (merge) deux <quote>heads</quote></title>
youshe@1001: <mediaobject>
youshe@1001: <imageobject> <imagedata fileref="figs/wdir-merge.png"/>
youshe@1001: </imageobject> <textobject><phrase>XXX add text</phrase></textobject>
youshe@1001: </mediaobject>
bos@591: </figure>
bos@559:
youshe@1001: <para id="x_319">Mercurial doit aussi modifier le répertoire de
wilk@1008: travail pour fusionner les fichiers gérés dans les deux <quote>changesets</quote>.
youshe@1001: Un peu simplifié, le processus de fusion fonctionne comme ça : pour
wilk@1008: chaque fichier dans le <quote>manifest</quote> de chaque <quote>changeset</quote>.</para>
youshe@1001:
bos@559: <itemizedlist>
wilk@1008: <listitem><para id="x_31a">Si aucun <quote>changeset</quote> n'a modifié un fichier,
youshe@1001: ne rien faire avec ce fichier.</para> </listitem>
wilk@1008: <listitem><para id="x_31b">Si un <quote>changeset</quote> a modifié un fichier et
youshe@1001: que l'autre ne l'a pas fait, créer une copie modifiée du fichier
youshe@1001: dans le répertoire de travail.</para> </listitem>
wilk@1008: <listitem><para id="x_31c">Si un <quote>changeset</quote> a modifié un fichier, et
youshe@1001: que l'autre ne l'a pas fait (ou l'a supprimé), supprimer le
youshe@1001: fichier du répertoire de travail.</para> </listitem>
wilk@1008: <listitem><para id="x_31d">Si un <quote>changeset</quote> a supprimé un fichier,
youshe@1001: mais que l'autre a modifié le fichier, demander à l'utilisateur
youshe@1001: quoi faire : garder le fichier modifié ou le supprimer ?</para>
youshe@1001: </listitem>
andre@1017: <listitem><para id="x_31e">Si chacun des <quote>changesets</quote> a modifié un
youshe@1001: fichier, invoquer le programme externe de fusion pour choisir les
youshe@1001: nouveaux contenus pour le fichier fusionné. Ceci peut demander
andre@1017: une intervention de l'utilisateur.</para></listitem>
wilk@1008: <listitem><para id="x_31f">Si un <quote>changeset</quote> a modifié un fichier, et
youshe@1001: que l'autre a renommé ou copié le fichier, être sûr que les
youshe@1001: changements suivent le nouveau nom du fichier.</para></listitem>
youshe@1001: </itemizedlist>
youshe@1001:
youshe@1001: <para id="x_320">Il y a plus de détails&emdash;fusionner a beaucoup de
andre@1017: <quote>corner cases</quote>&emdash;mais ceux-ci sont des choix plus communs qui sont
andre@1017: liés à une fusion (merge). Comme vous pouvez le voir, la
youshe@1001: plupart des cas sont entièrement automatiques, et effectivement, la
andre@1017: plupart des fusions (merge) se terminent automatiquement, sans nécessiter
andre@1017: votre intervention pour résoudre un conflit.</para>
youshe@1001:
youshe@1001: <para id="x_321">Lorsque vous pensez à ce qu'il se passe lorsque vous
wilk@1008: <quote>committez</quote> après un <quote>merge</quote>, une fois encore, le répertoire de travail
youshe@1001: est <quote>le changeset que je suis sur le point de
youshe@1001: committer</quote>. Après que la commande <command role="hg-cmd">hg
andre@1017: merge</command> soit terminée, le répertoire de travail a deux
youshe@1001: parents ; ceux ci vont devenir les parents du nouveau
wilk@1008: <quote>changeset</quote>.</para>
youshe@1001:
youshe@1001: <para id="x_322">Mercurial vous permet d'exécuter de multiples fusions,
wilk@1008: mais vous devez <quote>committer</quote> le résultat de chaque fusion individuellement
wilk@1008: au fur et à mesure. Ceci est nécessaire puisque Mercurial ne stocke
youshe@1001: que deux parents pour chaque révision et le répertoire de travail.
wilk@1008: Alors qu'il serait techniquement faisable de fusionner de multiples
andre@1017: <quote>changesets</quote> en même temps, Mercurial interdit cela pour être plus simple. Avec
wilk@1008: des fusions multiples, les risques de confusion pour l'utilisateur, de
andre@1017: mauvaie résolution de conflits, et de pagaille dans les fusions
andre@1017: augmenteraient de façon intolérable.</para>
youshe@1001:
youshe@1001: </sect2>
youshe@1001:
youshe@1001: <sect2>
youshe@1001: <title>Fusions et renommages</title>
youshe@1001:
youshe@1001: <para id="x_69a">Un nombre surprenant de systèmes de gestion de
andre@1017: révisions fait peu ou pas attention à un <emphasis>nom</emphasis> de fichier au
youshe@1001: cours du temps. Par exemple, il était habituel que si un fichier
youshe@1001: était renommé d'un coté de la fusion, les changements à partir de
youshe@1001: l'autre coté étaient supprimés silencieusement.</para>
youshe@1001:
youshe@1001: <para id="x_69b">Mercurial enregistre les metadata lorsque vous lui
andre@1017: dites d'exécuter un renommage ou une copie. Il utilise ces metadatas
youshe@1001: durant une fusion pour faire les bonnes choses dans le cas d'un
wilk@1008: <quote>merge</quote>. Par exemple, si je renomme un fichier et que vous l'éditez
youshe@1001: sans le renommer, lorsque l'on fusionne, le fichier sera renommé et
wilk@1008: aura les changements appliqués.</para>
youshe@1001:
bos@620: </sect2>
bos@559: </sect1>
bos@620:
bos@559: <sect1>
youshe@1001: <title>D'autres fonctionnalités intéressantes</title>
youshe@1001:
wilk@1008: <para id="x_323">Dans les sections au-dessus, j'ai tenté de mettre
youshe@1001: l'accent sur certains aspects importants du design de Mercurial pour
youshe@1001: illustrer l'attention particulière qui a été portée à la fiabilité et à
wilk@1008: la performance. Cependant, l'attention aux détails ne s'arrête pas ici.
youshe@1001: Il y a de nombreux aspects sur la construction de Mercurial que je
andre@1017: trouve personnellement intéressants. J'en détaillerai quelques-uns
wilk@1008: ici, séparément des éléments du <quote>big ticket</quote> ci-dessus,
youshe@1001: ainsi, si vous êtes intéressés, vous pourrez avoir une meilleure idée
wilk@1008: de la quantité d'ingéniosité qu'il y a derrière un système bien
wilk@1008: conçu.</para>
youshe@1001:
youshe@1001: <sect2>
andre@1017: <title>Compression astucieuse</title>
youshe@1001:
youshe@1001: <para id="x_324">Lorsque cela est approprié, Mercurial stocke les
wilk@1008: <quote>snapshots</quote> et deltas sous une forme compressée. Il le fait en
wilk@1008: <emphasis>essayant</emphasis> toujours de compresser un <quote>snapshot</quote> ou
wilk@1008: un delta, mais en ne stockant la version compressée que si celle-ci
youshe@1001: est plus petite que la version non compressée.</para>
youshe@1001:
youshe@1001: <para id="x_325">Ceci signifie que Mercurial fait <quote>la bonne
youshe@1001: chose</quote> lorsqu'il stocke un fichier dont la forme native est
youshe@1001: compressée, comme une archive <literal>zip</literal> ou une image
youshe@1001: JPEG. Lorsque ces types de fichiers sont compressés une seconde fois,
youshe@1001: le fichier obtenu est habituellement plus gros que la forme
youshe@1001: compressée une seule fois et Mercurial stockera alors le
youshe@1001: <literal>zip</literal> ou JPEG.</para>
youshe@1001:
andre@1017: <para id="x_326">Les deltas entre les révisions d'un fichier compressé
youshe@1001: sont habituellement plus gros que les snapshots du fichier, et
youshe@1001: Mercurial fait à nouveau <quote>la bonne chose</quote> dans ces cas.
youshe@1001: Il trouve qu'un delta dépasse le seuil auquel il devrait stocker un
wilk@1008: <quote>snapshot</quote> complet du fichier, alors il stocke le <quote>snapshot</quote>, en gagnant
wilk@1008: encore de la place en comparaison d'une approche naïve avec un delta
youshe@1001: seulement.</quote>
bos@559:
bos@559: <sect3>
andre@1017: <title>Recompression sur le réseau</title>
youshe@1001:
youshe@1001: <para id="x_327">Lors du stockage des révisions sur le disque,
youshe@1001: Mercurial utilise l'algorithme de compression
andre@1017: <quote>deflate</quote> (le même que celui utilisé pour le format populaire
andre@1017: d'archive <literal>zip</literal>), qui est un bon
wilk@1008: compromis entre la vitesse et le taux de compression. Cependant,
youshe@1001: lors de la transmission d'une révision de données par une connexion
youshe@1001: réseau, Mercurial décompresse les données de révision
youshe@1001: compressées.</para>
youshe@1001:
wilk@1008: <para id="x_328">Si la connexion passe par HTTP, Mercurial
youshe@1001: recompresse le flux entier de données en utilisant un algorithme de
youshe@1001: compression qui donne un meilleur taux de compression (l'algorithme
wilk@1008: Burrows-Wheeler utilisé principalement par le logiciel de
youshe@1001: compression <literal>bzip2</literal>). Cette combinaison de
andre@1017: l'algorithme et de la compression du flux entier (plutôt que pour une
wilk@1008: révision à la fois) réduit substantiellement le nombre de bits qui
wilk@1008: sont transférés, résultant en une performance réseau accrue sur
youshe@1001: la plupart des supports.</para>
youshe@1001:
wilk@1008: <para id="x_329">Si la connexion passe par
youshe@1001: <command>ssh</command>, Mercurial <emphasis>ne</emphasis>
youshe@1001: recompresse <emphasis>pas</emphasis> le flux puisque
andre@1017: <command>ssh</command> peut déjà le faire par lui-même. Vous pouvez
youshe@1001: demander à Mercurial de toujours utiliser la compression
youshe@1001: <command>ssh</command> en éditant le fichier
wilk@1008: <filename>.hgrc</filename> de votre répertoire personnel comme ci-dessous.
wilk@1008: </para>
youshe@1001:
youshe@1001: <programlisting>[ui]
bos@701: ssh = ssh -C</programlisting>
bos@559:
bos@559: </sect3>
bos@559: </sect2>
bos@559: <sect2>
andre@1017: <title>Ordre de lecture/écriture et atomicité</title>
youshe@1001:
wilk@1008: <para id="x_32a">L'histoire ne se résume pas à ajouter à la fin des fichiers
wilk@1008: lorsque l'on cherche à garantir que le lecteur ne verra
youshe@1001: pas qu'une écriture partielle. Si vous relisez <xref
wilk@1008: linkend="fig:concepts:metadata"/>, les révisions dans le <quote>changelog</quote>
wilk@1008: pointent vers les révisions dans le <quote>manifest</quote>, et les révisions du
wilk@1008: <quote>manifest</quote> pointent vers les révisions du <quote>filelog</quote>. Cette hiérarchie est
youshe@1001: délibérée.</para>
youshe@1001:
wilk@1008: <para id="x_32b">L'écriture commence par une transaction en écrivant dans
wilk@1008: le <quote>filelog</quote> et dans les données du <quote>manifest</quote>, et n'écrit aucune donnée
wilk@1008: du <quote>changelog</quote> tant que ce n'est pas terminé. La lecture commence en
wilk@1008: lisant les données du <quote>changelog</quote>, puis les données du <quote>manifest</quote>, et
wilk@1008: enfin les données du <quote>filelog</quote>.</para>
youshe@1001:
youshe@1001: <para id="x_32c">Puisque que l'écriture ne finit pas d'écrire les
wilk@1008: données du <quote>filelog</quote> et du <quote>manifest</quote> avant d'écrire dans le <quote>changelog</quote>,
wilk@1008: la lecture ne verra jamais un pointeur vers une révision du <quote>manifest</quote>
wilk@1008: partiellement écrite à partir du <quote>changelog</quote>, et ne lira jamais un
wilk@1008: pointeur vers une révision du <quote>filelog</quote> partiellement écrite dans le
wilk@1008: <quote>manifest</quote>.</para>
youshe@1001:
youshe@1001: </sect2>
youshe@1001: <sect2>
youshe@1001: <title>Accès concurrent</title>
youshe@1001:
youshe@1001: <para id="x_32d">La garantie de l'ordre de lecture/écriture et
wilk@1008: de l'atomicité signifie que Mercurial n'a jamais besoin de poser de
youshe@1001: <emphasis>lock</emphasis> sur un dépôt lorsqu'il lit des données,
youshe@1001: même si le dépôt est en train d'être écrit au même moment que la
wilk@1008: lecture a lieu. Ceci a un grand impact sur la fiabilité ; vous
youshe@1001: pouvez avoir un nombre arbitraire de processus Mercurial qui lisent
wilk@1008: sans risque les données d'un dépôt en même temps, peu importe s'il
youshe@1001: est en train d'être lu ou non.</para>
youshe@1001:
youshe@1001: <para id="x_32e">La nature sans <quote>lock</quote> de la lecture
youshe@1001: signifie que si vous partagez un dépôt sur un système
youshe@1001: multi-utilisateurs, vous n'avez pas besoin de donner aux autres
youshe@1001: utilisateurs locaux la permission d'<emphasis>écrire</emphasis> sur
wilk@1008: votre dépôt pour qu'ils soient capable de faire un clone ou un <quote>pull</quote>
andre@1017: des changements à partir de celui-ci ; ils ont seulement besoin de la
youshe@1001: permission en <emphasis>lecture</emphasis>. (Il
youshe@1001: <emphasis>ne</emphasis> s'agit <emphasis>pas</emphasis> d'une
wilk@1008: fonctionnalité commune à travers les systèmes de gestion de révisions,
andre@1017: donc ne prenez pas ça pour argent comptant ! La plupart ont besoin que les
youshe@1001: lecteurs soient capables de mettre un lock sur le dépôt pour y
youshe@1001: accéder en toute sécurité, et ceci demande des permissions en
wilk@1008: écriture, sur au moins un répertoire, ce qui provoque bien sûr toutes
andre@1017: sortes de problèmes pénibles et agaçants relatifs à la sécurité et à
youshe@1001: l'administration.)</para>
youshe@1001:
wilk@1008: <para id="x_32f">Mercurial utilise des <quote>locks</quote> pour assurer qu'un seul
youshe@1001: processus peut écrire dans le dépôt à un moment donné (le mécanisme
wilk@1008: de <quote>lock</quote> est sûr, même sur des systèmes de fichiers qui sont connus
wilk@1008: pour être hostiles aux <quote>locks</quote>, comme NFS). Si un dépôt dispose d'un
wilk@1008: <quote>lock</quote>, un processus qui cherche à écrire va attendre un peu avant de
wilk@1008: retenter pour voir si le dépôt perd son <quote>lock</quote>, mais si le dépôt garde
wilk@1008: trop longtemps son <quote>lock</quote>, le processus qui tente d'écrire va expirer
wilk@1008: (time out) après un moment. Cela veut dire par exemple que vos
wilk@1008: scripts lancés quotidiennement n'attendront pas toujours et boucleront
wilk@1008: si un système plantait sans avertissement, par exemple. (Oui, le
youshe@1001: timeout est configurable, de zéro à l'infini.)</para>
bos@559:
bos@559: <sect3>
wilk@1008: <title>Accès <quote>dirstate</quote> sûr</title>
wilk@1008:
wilk@1008: <para id="x_330">Comme avec les données de révision, Mercurial n'utilise pas
wilk@1008: de <quote>lock</quote> pour lire le fichier <quote>dirstate</quote> ; il n'acquiert pas un <quote>lock</quote> pour
wilk@1008: y écrire. Pour empêcher la possibilité de lire une copie partiellement
wilk@1008: écrite du fichier <quote>dirstate</quote>, Mercurial écrit sur un fichier avec un nom
wilk@1008: unique dans le même répertoire que le fichier <quote>dirstate</quote>, ensuite renomme
youshe@1001: le fichier temporaire automatiquement en <filename>dirstate</filename>.
youshe@1001: Le fichier nommé <filename>dirstate</filename> est ainsi garanti d'être
youshe@1001: écrit totalement, et non partiellement.</para>
bos@559:
bos@559: </sect3>
bos@559: </sect2>
bos@559: <sect2>
wilk@1008: <title>Empêcher les recherches</title>
youshe@1001:
youshe@1001: <para id="x_331">L'absence de recherche sur les têtes de disques est
youshe@1001: critique pour la performance de Mercurial, puisque toute recherche
youshe@1001: est beaucoup plus coûteuse comparativement à une grosse opération de
youshe@1001: lecture.</para>
youshe@1001:
wilk@1008: <para id="x_332">C'est pour ça, par exemple, que le <quote>dirstate</quote> est stocké
wilk@1008: dans un fichier unique. S'il y avait eu un <quote>dirstate</quote> par répertoire
wilk@1008: que Mercurial suivrait, le disque aurait recherché une fois par
wilk@1008: répertoire. Au lieu de ça, Mercurial lit entièrement un
wilk@1008: fichier unique, en une étape.</para>
youshe@1001:
youshe@1001: <para id="x_333">Mercurial utilise aussi un schéma <quote>copie à
youshe@1001: l'écriture</quote> lorsqu'il clone un dépôt sur un stockage local.
wilk@1008: Au lieu de copier chaque <quote>fichier</quote> revlog depuis l'ancien dépôt vers le
youshe@1001: nouveau dépôt, il crée un <quote>lien physique</quote>, qui est le
youshe@1001: plus court chemin pour dire <quote>Ces deux noms pointent vers le
youshe@1001: même fichier</quote>. Lorsque Mercurial est sur le point d'écrire
youshe@1001: sur l'un des revlogs de ces fichiers, il vérifie si le nombre de noms
youshe@1001: pointant sur ce fichier est plus grand que un. Si c'est le cas, plus
youshe@1001: d'un dépôt utilise le fichier, donc Mercurial crée une nouvelle copie
youshe@1001: du fichier qui est privée à ce dépôt.</para>
youshe@1001:
youshe@1001: <para id="x_334">Quelques développeurs de systèmes de gestion de
wilk@1008: révisions ont montré que cette idée de faire une copie privée complète
wilk@1008: d'un fichier n'est pas vraiment efficace au niveau du
youshe@1001: stockage. Bien que ce soit vrai, le stockage est peu onéreux, et
youshe@1001: cette méthode donne la plus grande performance lorsque l'on reporte
youshe@1001: la plupart des journalisations au système d'exploitation. Un schéma
youshe@1001: alternatif réduirait certainement la performance tout en augmentant
wilk@1008: la complexité du logiciel, mais la vitesse et la simplicité sont les
wilk@1008: clefs du <quote>confort</quote> de l'utilisation
youshe@1001: quotidienne.</para>
youshe@1001:
youshe@1001: </sect2>
youshe@1001: <sect2>
wilk@1008: <title>Autres contenus du <quote>dirstate</quote></title>
wilk@1008:
wilk@1008: <para id="x_335">Puisque Mercurial ne vous force pas à signaler que
wilk@1008: vous modifiez un fichier, il utilise le <quote>dirstate</quote> pour stocker
youshe@1001: certaines informations supplémentaires pour déterminer efficacement
youshe@1001: si vous avez ou non modifié un fichier. Pour chaque fichier du
youshe@1001: répertoire de travail, il stocke l'heure à laquelle il a été modifié,
youshe@1001: ainsi que la taille du fichier à cette heure.</para>
youshe@1001:
youshe@1001: <para id="x_336">Lorsque vous faites explicitement un <command
youshe@1001: role="hg-cmd">hg add</command>, <command role="hg-cmd">hg
youshe@1001: remove</command>, <command role="hg-cmd">hg rename</command> ou
youshe@1001: <command role="hg-cmd">hg copy</command> sur des fichiers, Mercurial
andre@1017: met à jour le <quote>dirstate</quote> afin de savoir que faire lorsque vous
wilk@1008: effectuez un <quote>commit</quote>.</para>
wilk@1008:
wilk@1008: <para id="x_337">Le <quote>dirstate</quote> aide Mercurial à vérifier efficacement le
wilk@1008: statut des fichiers dans un dépôt.</para>
bos@701:
bos@701: <itemizedlist>
youshe@1001: <listitem> <para id="x_726"> Lorsque Mercurial vérifie l'état d'un
youshe@1001: fichier du répertoire de travail, il compare d'abord la date de
youshe@1001: dernière modification du fichier avec celle enregistrée dans le
wilk@1008: <quote>dirstate</quote> qui correspond à celle que Mercurial a écrit en dernier sur ce
andre@1017: fichier. Si la date de dernière modification correspond à la date
youshe@1001: où Mercurial a écrit le fichier, celui ci n'a pas été modifié,
andre@1017: donc Mercurial n'a pas besoin de revérifier.</para> </listitem>
wilk@1008: <listitem> <para id="x_727"> Si la taille du fichier a changé, celui-ci
wilk@1008: a été modifié. Si la date de modification a changé mais que la
youshe@1001: taille est restée inchangée, seulement à ce moment là Mercurial
youshe@1001: doit vérifier le contenu du fichier pour savoir s'il a été
youshe@1001: modifié.</para> </listitem>
bos@701: </itemizedlist>
bos@701:
youshe@1001: <para id="x_728">Enregistrer la date de modification et la taille
youshe@1001: réduit grandement le nombre d'opérations de lecture que Mercurial
youshe@1001: doit effectuer lorsque l'on utilise une commande comme <command>hg
youshe@1001: status</command>. Le résultat est un grand gain de
youshe@1001: performance.</para>
bos@559: </sect2>
bos@559: </sect1>
belaran@964: </chapter>
belaran@964:
belaran@964: <!--
belaran@964: local variables:
belaran@964: sgml-parent-document: ("00book.xml" "book" "chapter")
belaran@964: end:
bos@559: -->