1.1 --- a/fr/intro.tex	Mon Feb 09 10:27:27 2009 +0100
     1.2 +++ b/fr/intro.tex	Mon Feb 09 14:41:04 2009 +0100
     1.3 @@ -1,84 +1,93 @@
     1.4  \chapter{Introduction}
     1.5  \label{chap:intro}
     1.6  
     1.7 -\section{A propros de la gestion source}
     1.8 -
     1.9 -La gestion de source est un processus permettant de gérer différentes
    1.10 -version de la même information. Dans sa forme la plus simple, c'est
    1.11 -quelquechose que tout le monde fait manuellement : quand vous modifiez
    1.12 +\section{À propos de la gestion source}
    1.13 +
    1.14 +La gestion de sources est un processus permettant de gérer différentes
    1.15 +versions de la même information. Dans sa forme la plus simple, c'est
    1.16 +ce que tout le monde fait manuellement : quand vous modifiez
    1.17  un fichier, vous le sauvegarder sous un nouveau nom contenant un numéro,
    1.18 -à chaque fois plus grand la précédente version.
    1.19 -
    1.20 -Ce genre de gestion de version manuel est cependant sujette facilement
    1.21 +à chaque fois plus grand que celui de la version précédente.
    1.22 +
    1.23 +Ce genre de gestion de version manuelle est cependant facilement sujette 
    1.24  à des erreurs, ainsi, depuis longtemps, des logiciels existent pour
    1.25 -adresser cette problématique. Les premiers outils de gestion de source
    1.26 +résoudre cette problématique. Les premiers outils de gestion de sources
    1.27  étaient destinés à aider un seul utilisateur, à automatiser la gestion
    1.28 -des versions d'un seulf fichier. Dans les dernières décades, cette cilble 
    1.29 -a largement était agrandie, ils gèrent désormais de multiple fichiers, et
    1.30 -aident un grand nombre de personnes à travailler ensemble. Le outils les
    1.31 +des versions d'un seul fichier. Dans les dernières décades, cette cible 
    1.32 +s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
    1.33 +aident un grand nombre de personnes à travailler ensemble. Les outils les
    1.34  plus modernes n'ont aucune difficultés à gérer plusieurs milliers de 
    1.35  personnes travaillant ensemble sur des projets regroupant plusieurs 
    1.36  centaines de milliers de fichiers.
    1.37  
    1.38  \subsection{Pourquoi utiliser un gestionnaire de source ?}
    1.39  
    1.40 -Il y a de nombreuse raisons pour que vous ou votre équipe souhaitiez
    1.41 +Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez
    1.42  utiliser un outil automatisant la gestion de version pour votre projet.
    1.43  \begin{itemize}
    1.44  \item L'outil se chargera de suivre l'évolution de votre projet, sans
    1.45 -que vous ayez à le faire. Pour chaque modification, vous aurez à votre
    1.46 -disposition un journal indiquant \emph{qui} a faient quoi, \emph{pourquoi}
    1.47 +que vous n'ayez à le faire. Pour chaque modification, vous aurez à votre
    1.48 +disposition un journal indiquant \emph{qui} a fait quoi, \emph{pourquoi}
    1.49  ils l'ont fait, \emph{quand} ils l'ont fait, et \emph{ce} qu'ils ont
    1.50  modifiés.
    1.51  \item Quand vous travaillez avec d'autres personnes, les logiciels de 
    1.52 -gestion de source facilite le travail collaboratif. Par exemple, quand
    1.53 -plusieurs personnes font, plus ou moins simultannéement, des modifications
    1.54 +gestion de source facilitent le travail collaboratif. Par exemple, quand
    1.55 +plusieurs personnes font, plus ou moins simultanément, des modifications
    1.56  incompatibles, le logiciel vous aidera à identifier et résoudre les conflits.
    1.57  \item L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
    1.58 -qui se révèlera être une erreur, vous pourrez revenir fiablement à une version
    1.59 -antérieur d'une fichier ou même d'un ensemble de fichier. En fait, un outil de
    1.60 +qui se révèlera être une erreur, vous pourrez revenir à une version
    1.61 +antérieure d'un fichier ou même d'un ensemble de fichiers. En fait, un outil de
    1.62  gestion de source \emph{vraiment} efficace vous permettra d'identifier à quel
    1.63  moment le problème est apparu (voir la section~\ref{sec:undo:bisect} pour plus
    1.64  de détails).
    1.65  \item L'outil vous permettra aussi de travailler sur plusieurs versions différentes
    1.66 -de votre projet et à gérer l'écart entre chaque.
    1.67 +de votre projet et à gérer l'écart entre chacune.
    1.68  \end{itemize}
    1.69 -La plupart de ces raisons ont autant d'importances---du moins en théorie--- que
    1.70 +La plupart de ces raisons ont autant d'importances ---du moins en théorie--- que
    1.71  vous travailliez sur un projet pour vous, ou avec une centaine d'autres
    1.72  personnes.
    1.73  
    1.74 -Une question fondamental à propos des outils de gestion de source, qu'il s'agisse
    1.75 +Une question fondamentale à propos des outils de gestion de source, qu'il s'agisse
    1.76  du projet d'une personne ou d'une grande équipe, est quelles sont ses  
    1.77  \emph{avantages} par rapport à ses \emph{coût}. Un outil qui est difficile à 
    1.78 -utiliser ou à comprendre exigera un effort d'adoption.
    1.79 -
    1.80 -Un projet de cinq milles personnnes s'effondrera très certainement de lui même
    1.81 +utiliser ou à comprendre exigera un gros effort d'adaptation.
    1.82 +
    1.83 +Un projet de cinq milles personnes s'effondrera très certainement de lui même
    1.84  sans aucun processus et outil de gestion de source. Dans ce cas, le coût 
    1.85  d'utilisation d'un logiciel de gestion de source est dérisoire, puisque 
    1.86  \emph{sans}, l'échec est presque garanti.
    1.87  
    1.88 -D'un autre coté, un ``rapide hack'' d'une personnne peut sembler un contexte
    1.89 +D'un autre coté, un ``rapide hack'' d'une personne peut sembler un contexte
    1.90  bien pauvre pour utiliser un outil de gestion de source, car, bien évidement
    1.91  le coût d'utilisation dépasse le coût total du projet. N'est ce pas ?
    1.92  
    1.93  Mercurial supporte ces \emph{deux} échelles de travail. Vous pouvez apprendre
    1.94 -les bases en juste quelques minutes, et, grâce à sa performance, vous pouvez
    1.95 +les bases en quelques minutes seulement, et, grâce à sa performance, vous pouvez
    1.96  l'utiliser avec facilité sur le plus petit des projets. Cette simplicité 
    1.97 -signifie que vous n'avez pas de concepts obscures ou de séquence de commandes
    1.98 -défiant l'imagination, complètement décorrelé de \emph{ce que vous êtes 
    1.99 +signifie que vous n'avez pas de concepts obscurs ou de séquence de commandes
   1.100 +défiant l'imagination, sans aucune corrélation avec \emph{ce que vous êtes 
   1.101  vraiment entrain de faire}. En même temps, ces mêmes performances et sa 
   1.102  nature ``peer-to-peer'' vous permet d'augmenter, sans difficulté, son 
   1.103  utilisation à de très grand projet.
   1.104  
   1.105  Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un
   1.106 -bon outil peut faire une grande différence dans la fluidité avec lequel 
   1.107 +bon outil peut faire une grande différence dans la fluidité avec laquelle
   1.108  vous pourrez travailler avec.
   1.109  
   1.110  \subsection{Les multiples noms de la gestion de source}
   1.111  
   1.112 -La gestion de source\footnote{NdT: J'ai utilisé systématiquement le terme ``gestion de source'' à travers tout l'ouvrage. Ce n'est pas forcement la meilleur traduction, et ceci peut rendre la lecture un peu lourde, mais je pense que le document y gagne en clarté et en précision.} est un domaine divers, tellement qu'il n'existe pas
   1.113 -une seul nom ou acronyme pour le désigner. Voilà quelqu'uns des noms ou 
   1.114 -acronymes que vous rencontrerez le plus souvent\footnote{NdT: J'ai conservé la liste des noms en anglais pour des raisons de commodité (ils sont plus ``googelable''). En outre, j'ai opté  conserver l'ensemble des opérations de Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en anglais, là aussi pour faciliter la lecture d'autres documents en anglais, et aussi l'utilisation de Mercurial}.
   1.115 +La gestion de source\footnote{NdT: J'ai utilisé systématiquement le terme
   1.116 +``gestion de source'' à travers tout l'ouvrage. Ce n'est pas forcement la
   1.117 +meilleur traduction, et ceci peut rendre la lecture un peu lourde, mais je
   1.118 +pense que le document y gagne en clarté et en précision.} est un domaine
   1.119 +divers, tellement qu'il n'existe pas une seul nom ou acronyme pour le désigner.
   1.120 +Voilà quelqu'uns des noms ou 
   1.121 +acronymes que vous rencontrerez le plus souvent\footnote{NdT: J'ai conservé la
   1.122 +liste des noms en anglais pour des raisons de commodité (ils sont plus
   1.123 +``googelable''). En outre, j'ai opté  conserver l'ensemble des opérations de
   1.124 +Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en anglais, là
   1.125 +aussi pour faciliter la lecture d'autres documents en anglais, et aussi
   1.126 +l'utilisation de Mercurial}.
   1.127  
   1.128  :
   1.129  \begin{itemize}
   1.130 @@ -97,81 +106,80 @@
   1.131  
   1.132  Le plus célèbre des anciens outils de gestion de source est \textit{SCCS (Source
   1.133  Code Control System)}, que Marc Rochkind conçu dans les laboratoire de recherche de Bell 
   1.134 -(\textit{Bell Labs}), dans le début des années 70. \textit{SCCS} ne fonctionner que sur des fichiers individuels, et demandait à personne travaillant sur le projet d'avoir un accès à un répertoire de travail commun, sur un unique système.
   1.135 -Seulement une personne pouvait modifier un fichier au même moment, ce fonctionnement était assuré par l'utilisation de verrou (``lock''). Il était courant que des personnes ne vérouille
   1.136 -des fichiers, et plus tard, oublie de le dévérouiller; empêchant  n'importe qui d'autre de 
   1.137 +(\textit{Bell Labs}), dans le début des années 70. \textit{SCCS} ne fonctionnait que sur des fichiers individuels, et obligeait à chaque personne travaillant sur le projet d'avoir un accès à un répertoire de travail commun, sur le même système.
   1.138 +Seulement une seule personne pouvait modifier un fichier au même moment, ce fonctionnement était assuré par l'utilisation de verrou (``lock''). Il était courant que des personnes verrouillent
   1.139 +des fichiers, et plus tard, oublient de le déverrouiller; empêchant n'importe qui d'autre de 
   1.140  travailler sur ces fichiers sans l'aide de l'administrateur...
   1.141  
   1.142  Walter Tichy a développé une alternative libre à \textit{SCCS} au début des années 80, qu'il
   1.143  nomma \textit{RSC (Revison Control System)}.  Comme \textit{SCCS}, \textit{RCS}
   1.144 -demander aux développeurs de travailler sur le même répertoire partagé, et de vérouiller les
   1.145 +demander aux développeurs de travailler sur le même répertoire partagé, et de verrouiller les
   1.146  fichiers pour se prémunir de tout conflit issue de modifications concurrentes.
   1.147  
   1.148 -Un peu plus tard dans les années 1980, Dick Grune utilisa \textit{RCS} comme une brique de base pour un ensemble de scripts \textit{shell} qu'il intitula cmt, avant de la renommer en \textit{CVS (Concurrent Versions System)}.  La grande innovation de CVS était que les développeurs pouvaient travailler simultanéement and indépendament dans leur propre espace de travail. Ces espaces de travail privés assuraient que les développeurs ne se marche mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS. Chaque développeur disposait donc de sa copie de tout les fichiers du projet, et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer la ``fusion'' (\textit{``merge''}) de leur fichiers, avant d'effectuer le ``commit'' de leur modification sur le dépôt central.
   1.149 -
   1.150 -Brian Berliner repris les scripts de Grune's et les réécris en~C, qu'il publia en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, le transformant son architecture en client/serveur. L'architecture de CVS est centralisée, seul le serveur a une copie de l'historique du projet. L'espace de travail client ne contient qu'une copie de la dernière version du projet, et quelques métadonnées pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui c'est probablement l'outil de gestion de contrôle le plus utilisé au monde. 
   1.151 -
   1.152 -Au début des années 1990, Sun Microsystmes développa un premier outil de gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare contient une copie complète de l'historique du projet. TeamWare n'a pas de notion de dépot central. (CVS utilisé RCS pour le stockage de l'historique, TeamWare utilisé SCCS).
   1.153 -
   1.154 -Alors que les années 1990 avancé, les utilisateurs ont pris conscience d'un certain nombre de problème avec CVS. Il enregistrait simultanéement des modifications sur différents fichier individuellement, au lieu de les regrouper dans une seule opération cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichier, il est donc assez aisé de créer le chaos en renommant les fichiers et les répertoires. Pire encore, son code source est difficile à lire et à maintenir, ce qui agrandit largement le ``niveau de souffrance'' associé à la réparation de ces problèmes d'architecture de manière prohibitive. 
   1.155 -
   1.156 -
   1.157 -En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé sur CVS, initialisèrent un projet pour le remplacer par un outil qui aurait une meilleur architecture et un code plus propre. Le résultat, Subversion, ne quitte pas le modèle centralisé et client/server de CVS, mais ajoute les opérations de ``commit'' atomique sur de multiples fichier, une meilleur gestion des espaces de noms, et d'autres fonctionnalités qui en font un meilleur outil que CVS. Depuis sa première publication, il est rapidement devenu très populaire.
   1.158 -
   1.159 -Plus ou moins de manière simultanné, Graydon Hoare a commencé sur l'ambitieux système de gestion distribué Monotone. Bien que Monotone corrige plusieurs défaut de CVS's tout en offrant une architecture ``peer-to-peer'', il va aussi plus loin que la plupart des outils de révision de manière assez innovante. Il utilise des ``hash'' cryptographique comme identifiant, et il a notion complète de ``confiance'' du code issues de différentes sources.
   1.160 -
   1.161 -Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se concentre sur la facilité d'utilisation, les performances et la capacité à monter en charge pour de très grand projets.
   1.162 +Un peu plus tard dans les années 1980, Dick Grune utilisa \textit{RCS} comme une brique de base pour un ensemble de scripts \textit{shell} qu'il intitula cmt, avant de la renommer en \textit{CVS (Concurrent Versions System)}.  La grande innovation de CVS était que les développeurs pouvaient travailler simultanément et indépendamment dans leur propre espace de travail. Ces espaces de travail privés assuraient que les développeurs ne se marchent pas mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS. Chaque développeur disposait donc de sa copie de tous les fichiers du projet, et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer la ``fusion'' (\textit{``merge''}) de leurs fichiers, avant d'effectuer le ``commit'' de leur modifications sur le dépôt central.
   1.163 +
   1.164 +Brian Berliner repris les scripts de Grune's et les réécris en~C, qu'il publia en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, transformant son architecture en client/serveur. L'architecture de CVS est centralisée, seul le serveur a une copie de l'historique du projet. L'espace de travail client ne contient qu'une copie de la dernière version du projet, et quelques métadonnées pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui c'est probablement l'outil de gestion de contrôle le plus utilisé au monde. 
   1.165 +
   1.166 +Au début des années 1990, Sun Microsystmes développa un premier outil de gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare contient une copie complète de l'historique du projet. TeamWare n'a pas de notion de dépôt central. (CVS utilisait RCS pour le stockage de l'historique, TeamWare utilisait SCCS).
   1.167 +
   1.168 +Alors que les années 1990 avançaient, les utilisateurs ont pris conscience d'un certain nombre de problèmes avec CVS. Il enregistrait simultanément des modifications sur différents fichiers individuellement, au lieu de les regrouper dans une seule opération cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichier, il est donc assez aisé de créer le chaos en renommant les fichiers et les répertoires. Pire encore, son code source est difficile à lire et à maintenir, ce qui agrandit largement le ``niveau de souffrance'' associé à la réparation de ces problèmes d'architecture de manière prohibitive. 
   1.169 +
   1.170 +En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillés sur CVS, initièrent un projet pour le remplacer par un outil qui aurait une meilleur architecture et un code plus propre. Le résultat, Subversion, ne quitte pas le modèle centralisé et client/server de CVS, mais ajoute les opérations de ``commit'' atomique sur de multiples fichiers, une meilleure gestion des espaces de noms, et d'autres fonctionnalités qui en font un meilleur outil que CVS. Depuis sa première publication, il est rapidement devenu très populaire.
   1.171 +
   1.172 +Plus ou moins de simultanément, Graydon Hoare a commencé sur l'ambitieux système de gestion distribué Monotone. Bien que Monotone corrige plusieurs défaut de CVS's tout en offrant une architecture ``peer-to-peer'', il va aussi plus loin que la plupart des outils de révision de manière assez innovante. Il utilise des ``hash'' cryptographique comme identifiant, et il a une notion complète de ``confiance'' du code issue de différentes sources.
   1.173 +
   1.174 +Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se concentre sur la facilité d'utilisation, les performances et la capacité à monter en charge pour de très gros projets.
   1.175  
   1.176  \section{Tendances de la gestion de source}
   1.177  
   1.178 -Il y a eu une tendance évidente dans le développement et l'utilisation d'outil de gestion de source depuis les quatre dernière décades, au fur et à mesure que les utilisateurs se sont habitués à leur outils et se sont sentis contraint par leur limitations.
   1.179 -
   1.180 -La première génération commença simplement par gérer un fichier unique sur un ordinateur individuel. Cependant, même si ces outils présentè-rent une grande avancée par rapport à la gestion manuel des versions, leur modèle de vérouillage et leur utilisation limité à un seul ordinateur rendaient leur utilisation possible uniquement dans une très petite équipe. 
   1.181 -
   1.182 -La seconde génération a assoupli ces contraintes en adoptant une architecture réseau et centralisé, permettant de gérer plusieurs projets entiers en même temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveau problèmes. Avec les clients discutant régulièrement avec le serveurs, la monte en charge devint un réellement problème sur les gros projets. Une connexion réseau peu fiable pouvant empêcher simplement les utilisateurs distant de discuter avec le serveur. Alors que les projets \textit{Open Source} commencèrent à mettre en place des accès en lecture seule disponible anonymement, les utilisateurs sans les privilèges de ``commit'' réalisèrent qu'ils ne pouvaient pas utiliser les outils pour collaboraient naturellement avec le projet, comme ils ne pouvaient pas non plus enregistrer leurs modifications.
   1.183 -
   1.184 -La génération actuelle des outils de gestion de source est ``peer-to-peer'' par nature. Tout ces systèmes ont abandonné la dépendance à un serveur central, et ont permis à leur utilisateur de distribué les données de leur gestion de source à qui en a besoin. La collaboration à travers Internet a transformée la contrainte technologique à une simple question de choix et de consencus. Les outils moderne peuvent maintenant fonctionner en mode déconnecté sans limite et de manière autonome, la connexion au réseau n'étant nécessaire que pour synchroniser les modifications avec les autres dépots.
   1.185 +Il y a eu une tendance évidente dans le développement et l'utilisation d'outil de gestion de source depuis les quatre dernières décades, au fur et à mesure que les utilisateurs se sont habitués à leur outils et se sont sentis contraint par leur limitations.
   1.186 +
   1.187 +La première génération commença simplement par gérer un fichier unique sur un ordinateur individuel. Cependant, même si ces outils présentaient une grande avancée par rapport à la gestion manuelle des versions, leur modèle de verrouillage et leur utilisation limitée à un seul ordinateur rendait leur utilisation possible uniquement dans une très petite équipe. 
   1.188 +
   1.189 +La seconde génération a assoupli ces contraintes en adoptant une architecture réseau et centralisé, permettant de gérer plusieurs projets entiers en même temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveau problèmes. Avec les clients discutant régulièrement avec le serveurs, la montée en charge devint un réel problème sur les gros projets. Une connexion réseau peu fiable pouvant complètement empêcher les utilisateurs distant de dialoguer avec le serveur. Alors que les projets \textit{Open Source} commencèrent à mettre en place des accès en lecture seule disponible anonymement, les utilisateurs sans les privilèges de ``commit'' réalisèrent qu'ils ne pouvaient pas utiliser les outils pour collaborer naturellement avec le projet, comme ils ne pouvaient pas non plus enregistrer leurs modifications.
   1.190 +
   1.191 +La génération actuelle des outils de gestion de source est ``peer-to-peer'' par nature. Tout ces systèmes ont abandonné la dépendance à un serveur central, et ont permis à leur utilisateur de distribuer les données de leur gestion de source à qui en a besoin. La collaboration à travers Internet a transformée la contrainte technologique à une simple question de choix et de consencus. Les outils moderne peuvent maintenant fonctionner en mode déconnecté sans limite et de manière autonome, la connexion au réseau n'étant nécessaire que pour synchroniser les modifications avec les autres dépôts.
   1.192  
   1.193  \section{Quelques avantages des gestionnaire de source distribué}
   1.194  
   1.195 -Même si les gestionnaire de source distribué sont depuis plusieurs années
   1.196 -assez robuste et aussi utilisable que leur prédécésseurs, les utilisateurs
   1.197 -d'autres outils n'ont pas encore étaient sensibilisé. Les gestionnaires
   1.198 -de sources distribué se distingue particulièrement de leurs équivalents
   1.199 -centralisé de nombreuse manière.
   1.200 -
   1.201 -Pour un développeur individuel, ils restent beaucoup plus rapide que les
   1.202 -outils centralisés. Cela pour une raison simple: un outil centralisé doit
   1.203 -toujours discuter à travers le réseau pour la plupart des opérations, car
   1.204 +Même si les gestionnaire de source distribués sont depuis plusieurs années
   1.205 +assez robustes et aussi utilisables que leur prédécesseurs, les utilisateurs
   1.206 +d'autres outils n'y ont pas encore été sensibilisés. Les gestionnaires
   1.207 +de sources distribués se distinguent particulièrement de leurs équivalents
   1.208 +centralisés de nombreuses manières.
   1.209 +
   1.210 +Pour un développeur individuel, ils restent beaucoup plus rapides que les
   1.211 +outils centralisés. Cela pour une raison simple : un outil centralisé doit
   1.212 +toujours dialoguer à travers le réseau pour la plupart des opérations, car
   1.213  presque toutes les métadonnées sont stockées sur la seule copie du serveur
   1.214  central. Un outil distribué stocke toute ses métadonnées localement. À tâche
   1.215  égale, effectuer un échange avec le réseau ajoute un délai aux outils 
   1.216 -centralisés. Ne sous estimez pas la valeur d'un outil rapide: vous allez
   1.217 +centralisés. Ne sous-estimez pas la valeur d'un outil rapide : vous allez
   1.218  passer beaucoup de temps à interagir avec un logiciel de gestion de sources.
   1.219  
   1.220 -Les outils distribué sont complètement indépendant des aléas de votre serveur,
   1.221 -encore une fois car ils répliquent les métadonnées à tellement d'endoit. Si
   1.222 -votre serveur central prend feu, vous avez intérêt à ce que les média de 
   1.223 -sauvegarde soient fiable, et que votre dernier ``backup'' soit récent et
   1.224 +Les outils distribués sont complètement indépendants des aléas de votre serveur,
   1.225 +d'autant plus qu'ils répliquent les métadonnées à beaucoup d'endroits. Si
   1.226 +votre serveur central prend feu, vous avez intérêt à ce que les médias de 
   1.227 +sauvegardes soient fiables, et que votre dernier ``backup'' soit récent et
   1.228  fonctionne sans problème. Avec un outil distribué, vous avez autant de 
   1.229  ``backup'' que de contributeurs.
   1.230  
   1.231  En outre, la fiabilité de votre réseau affectera beaucoup moins les
   1.232 -outils distribué. Vous ne pouvez même pas utiliser un outil centralisé
   1.233 -sans connexion réseau, à l'exception de quelques commandes, très limités. 
   1.234 -Avec un outil distribué, si vous connexion réseau tombe pendant que vous
   1.235 +outils distribués. Vous ne pouvez même pas utiliser un outil centralisé
   1.236 +sans connexion réseau, à l'exception de quelques commandes, très limitées. 
   1.237 +Avec un outil distribué, si votre connexion réseau tombe pendant que vous
   1.238  travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose
   1.239  que vous ne serez pas capable de faire sera de communiquer avec des dépôts
   1.240  distants, opération somme toute assez rare par comparaison aux opérations
   1.241 -locales. Si vous avez une (TODO:far-flung???) équipe de collaborateurs, 
   1.242 -ceci peut être significatif.
   1.243 +locales. Si vous avez une équipe de collaborateurs très dispersés ceci peut
   1.244 +être significatif.
   1.245  
   1.246  \subsection{Avantages pour les projets \textit{Open Source}}
   1.247  
   1.248  Si vous prenez goût à un projet \textit{Open Source} et que vous
   1.249  décidez de commencer à toucher à son code, et que le projet utilise
   1.250  un gestionnaire de source distribué, vous êtes immédiatement un "pair"
   1.251 -avec les personnes formant le ``coeur'' du projet. Si ils publient
   1.252 +avec les personnes formant le ``cœur'' du projet. Si ils publient
   1.253  leurs dépôts, vous pouvez immédiatement copier leurs historiques de
   1.254  projet, faire des modifications, enregistrer votre travail en utilisant
   1.255  les même outils qu'eux. Par comparaison, avec un outil centralisé, vous
   1.256 @@ -184,40 +192,40 @@
   1.257  
   1.258  \subsubsection{Le non-problème du \textit{fork}}
   1.259  
   1.260 -Il a été souvent suggeré que les gestionnaires de source distribués
   1.261 +Il a été souvent suggéré que les gestionnaires de source distribués
   1.262  posent un risque pour les projets \textit{Open Source} car ils 
   1.263  facilitent grandement la création de ``fork''\footnote{NdT:Création 
   1.264  d'une version alternative du logiciel}. %%% TODO: Link to Wikipedia
   1.265  Un ``fork'' apparait quand il y des divergences d'opinion ou d'attitude
   1.266  au sein d'un groupe de développeurs qui aboutit à la décision de ne 
   1.267 -plus travail ensemble. Chacun parti s'empare d'une copie plus ou moins
   1.268 +plus travailler ensemble. Chacun parti s'empare d'une copie plus ou moins
   1.269  complète du code source du projet et continue dans sa propre direction.
   1.270  
   1.271 -Parfois ces différents partis décide de se réconcilier. Avec un 
   1.272 +Parfois ces différents partis décident de se réconcilier. Avec un 
   1.273  serveur central, l'aspect \emph{technique} de cette réconciliation
   1.274  est un processus douloureux, et essentiellement manuel. Vous devez
   1.275  décider quelle modification est ``la gagnante'', et replacer, par un
   1.276 -moyen ou un autre, les modifications de l'autre équipe dans l'arboresence
   1.277 -du projet. Ceci implique généralement la perte d'une partie l'historique 
   1.278 +moyen ou un autre, les modifications de l'autre équipe dans l'arborescence
   1.279 +du projet. Ceci implique généralement la perte d'une partie de l'historique 
   1.280  d'un des partie, ou même des deux.
   1.281  
   1.282  Ce que les outils distribués permettent à ce sujet est probablement
   1.283  la \emph{meilleur} façon de développer un projet. Chaque modification
   1.284 -que vous effectué est potentiellement un ``fork''. La grande force de 
   1.285 -cette approche est que les gestionnaire de source distribué doit être
   1.286 -vraiment très efficase pour \emph{fusionner}\footnote{NdT:j'ai choisi de
   1.287 +que vous effectuez est potentiellement un ``fork''. La grande force de 
   1.288 +cette approche est que les gestionnaires de source distribués doivent être
   1.289 +vraiment très efficasses pour \emph{fusionner}\footnote{NdT:j'ai choisi de
   1.290  traduire ici \textit{merging} par ``fusionner'' pour des raisons de clarté}
   1.291  des ``forks'', car les ``forks'', dans ce contexte, arrivent tout le
   1.292  temps.
   1.293  
   1.294 -Si chaque altération que n'importe qui effectue, à tout moment, est vu
   1.295 +Si chaque altération que n'importe qui effectue, à tout moment, est vue
   1.296  comme un ``fork'' à fusionner, alors ce que le monde de l'\textit{Open 
   1.297  Source} voit comme un ``fork'' devient \emph{uniquement} une problématique 
   1.298 -social. En fait, les outils de gestion de source distribué \emph{réduisent} 
   1.299 +sociale. En fait, les outils de gestions de source distribués \emph{réduisent} 
   1.300  les chances de ``fork'':
   1.301  \begin{itemize}
   1.302 -\item Ils éliminent la distinction social qu'imposent les outils centralisés
   1.303 -	entre les membres du projets (ce qui ont accès au ``comit'') et ceux de l'
   1.304 +\item Ils éliminent la distinction sociale qu'imposent les outils centralisés
   1.305 +	entre les membres du projets (ceux qui ont accès au ``commit'') et ceux de l'
   1.306  	extérieur (ce qui ne l'ont pas).
   1.307  \item Ils rendent plus facile la réconciliation après un ``fork'' social, car
   1.308  	tout ce qu'elle implique est juste une simple fusion.
   1.309 @@ -234,6 +242,7 @@
   1.310  de manière fluide, en disposant d'un miroir ou d'un ``fork'' de votre
   1.311  historique.
   1.312  %%%TODO: Fussy, those last sentences are not really well translated:
   1.313 +%%%no problem for me (wilk)
   1.314  %However, if you're of this belief, and you publish your CVS or Subversion 
   1.315  %repositories publically, there are plenty of tools available that can pull 
   1.316  %out your entire project's history (albeit slowly) and recreate it somewhere 
   1.317 @@ -243,35 +252,35 @@
   1.318  
   1.319  \subsection{Avantages pour les projets commerciaux}
   1.320  
   1.321 -Beaucoup de projets commerciaux sont réalisé par des équipes éparpillées
   1.322 +Beaucoup de projets commerciaux sont réalisés par des équipes éparpillées
   1.323  à travers le globe. Les contributeurs qui sont loin du serveur central
   1.324 -devront subir des commandes lentes et même parfois peu fiable. Les 
   1.325 -solutions propriétaires gestion de source, tentent de palier ce problème 
   1.326 +devront subir des commandes lentes et même parfois peu fiables. Les 
   1.327 +solutions propriétaires de gestion de source, tentent de palier ce problème 
   1.328  avec des réplications de site distant qui sont à la fois coûteuses à mettre
   1.329 -en place et lourdes à administrer. A un système distribué ne souffre pas
   1.330 +en place et lourdes à administrer. Un système distribué ne souffre pas
   1.331  de ce genre de problèmes. En outre, il est très aisé de mettre en place
   1.332 -plusieurs serveurs de références, disont un par site, de manière à ce qu'il
   1.333 +plusieurs serveurs de références, disons un par site, de manière à ce qu'il
   1.334  n'y est pas de communication redondante entre les dépôts, sur une connexion
   1.335  longue distance souvent onéreuse.
   1.336  
   1.337  Les systèmes de gestion de source supportent généralement assez mal la 
   1.338 -monté en charge. Ce n'est pas rare pour un gestionnaire de source centralisé 
   1.339 -pourtant onéreux de s'effondrer sous la charge combinée de juste une douzaine 
   1.340 -d'utilisateurs concurrents. Une fois encore, la réponse à cette problématique 
   1.341 +montée en charge. Ce n'est pas rare pour un gestionnaire de source centralisé 
   1.342 +pourtant onéreux de s'effondrer sous la charge combinée d'une douzaine 
   1.343 +d'utilisateurs concurrents seulement. Une fois encore, la réponse à cette problématique 
   1.344  est généralement encore la mise en place d'un ensemble complexe de serveurs
   1.345 -synchronisé par un mécanisme de réplication. Dans le cas d'un gestionnaire
   1.346 -de source distribué, la charge du serveur central--- si vous avez un--- est
   1.347 -plusieurs fois inférieur (car toutes les données sont déjà répliqués ailleurs),
   1.348 -un simple server, pas très cher, peut gérer les besoins d'une plus grande
   1.349 -équipe, et la réplication pour balancer la charge devient simplement le
   1.350 +synchronisés par un mécanisme de réplication. Dans le cas d'un gestionnaire
   1.351 +de source distribué, la charge du serveur central --- si vous avez un--- est
   1.352 +plusieurs fois inférieure (car toutes les données sont déjà répliquées ailleurs),
   1.353 +un simple serveur, pas très cher, peut gérer les besoins d'une plus grande
   1.354 +équipe, et la réplication pour balancer la charge devient le
   1.355  travail d'un simple script.
   1.356  
   1.357 -Si vous avez des employés sur le terrain, entrain de chercher à résoudre sur
   1.358 +Si vous avez des employés sur le terrain, entrain de chercher à résoudre un soucis sur
   1.359  le site d'un client, ils bénéficieront aussi d'un gestionnaire de source
   1.360  distribués. Cet outil leur permettra de générer des versions personnalisées,
   1.361  d'essayer différentes solutions, en les isolant aisément les une des autres,
   1.362 -et de recherche efficasement à travers l'historique des sources, la cause
   1.363 -des bugs ou des régression, tout ceci sans avoir besoin de la moindre 
   1.364 +et de rechercher efficacement à travers l'historique des sources, la cause
   1.365 +des bugs ou des régressions, tout ceci sans avoir besoin de la moindre 
   1.366  connexion au réseau de votre compagnie.
   1.367  
   1.368  \section{Pourquoi choisir Mercurial?}
   1.369 @@ -279,7 +288,7 @@
   1.370  Mercurial a plusieurs caractéristiques qui en font un choix particulièrement
   1.371  pertinent pour la gestion de source:
   1.372  \begin{itemize}
   1.373 -	\item Il est facile à apprendre et à utiliser ;It is easy to learn and use.
   1.374 +	\item Il est facile à apprendre et à utiliser ;
   1.375  	\item il est léger et performant ;
   1.376  	\item il monte facilement en charge ; 
   1.377  	\item il est facile à personnaliser ;
   1.378 @@ -306,8 +315,8 @@
   1.379  de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des
   1.380  centaines de méga de code source.
   1.381  
   1.382 -Voici une liste non exhaustive des projets complexe ou critique utilisant 
   1.383 -mercurial :
   1.384 +Voici une liste non exhaustive des projets complexes ou critiques utilisant 
   1.385 +Mercurial :
   1.386  %TODO
   1.387  % For both spanish and english version, add the following examples:
   1.388  \begin{itemize}
   1.389 @@ -318,18 +327,18 @@
   1.390  \end{itemize}
   1.391  % TODO: Also add appropriate link.
   1.392  
   1.393 -Si les fonctionnalités coeur de Mercurial ne sont pas suffisantes pour vous, 
   1.394 -il est très aisé de construire dessus. Mercurial est adapté à l'utilisation
   1.395 -au sein de script, et son implémentation interne en python, propre et claire,
   1.396 -rend encore plus facile l'ajout de fonctionnalité sous forme d'extension. Il
   1.397 -en existe déjà un certains nombres de très populaires et très utiles, 
   1.398 +Si les fonctionnalités cœur de Mercurial ne sont pas suffisantes pour vous, 
   1.399 +il est très aisé d'en construire dessus. Mercurial est adapté à l'utilisation
   1.400 +de scripts, et son implémentation interne en Python, propre et claire,
   1.401 +rend encore plus facile l'ajout de fonctionnalité sous forme d'extensions. Il
   1.402 +en existe déjà un certain nombre de très populaires et très utiles, 
   1.403  dont le périmètre va de la recherche de bugs à l'amélioration des performances.
   1.404  
   1.405  \section{Mercurial comparé aux autres outils}
   1.406  
   1.407  Avant que vous n'alliez plus loin, comprenez bien que cette section
   1.408  reflète mes propres expériences, et elle est donc (j'ose le dire)
   1.409 -peu objectives. Néanmoins, j'ai utilisé les outils de gestion de source
   1.410 +peu objective. Néanmoins, j'ai utilisé les outils de gestion de source
   1.411  listé ci dessous, dans la plupart des cas, pendant plusieurs années.
   1.412  %% TODO: Fussy translation.
   1.413  
   1.414 @@ -346,68 +355,68 @@
   1.415  développé en C, je ne suis pas sûr que son portage aurait été aussi aisé.}.
   1.416  %TODO: Backport this statement in english and spanish 
   1.417  
   1.418 -Avant la version 1.5, Subversion n'offre aucune forme de support pour les fusions. Lors 
   1.419 -de l'écriture de ce livre, ces capacités de fusion sont nouvelle, et réputé pour être
   1.420 +Avant la version 1.5, Subversion n'offrait aucune forme de support pour les fusions. Lors 
   1.421 +de l'écriture de ce livre, ces capacités de fusion étaient nouvelles, et réputés pour être
   1.422  \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complexes
   1.423  et buggués}.
   1.424  
   1.425 -Mercurial dispose d'un avantages substantiel en terme de performance sur 
   1.426 -Subversion sur la plupart des opérations que j'ai pu testé. J'ai mesuré
   1.427 +Mercurial dispose d'un avantage substantiel en terme de performance par rapport à 
   1.428 +Subversion sur la plupart des opérations que j'ai pu tester. J'ai mesuré
   1.429  une différence de performance allant de deux à six fois plus rapide avec
   1.430  le système de stockage de fichier local de Subversion~1.4.3 
   1.431 -(\emph{ra\_local}), qui la méthode d'accès la plus rapide disponible. Dans
   1.432 +(\emph{ra\_local}), qui est la méthode d'accès la plus rapide disponible. Dans
   1.433  un déploiement plus réaliste, impliquant un stockage réseau, Subversion 
   1.434  serait encore plus désavantagé. Parce que la plupart des commandes Subversion
   1.435  doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme
   1.436  de réplication, la capacité du serveur et la bande passante sont devenu des
   1.437 -goulots d'étranglement pour les projets de taille moyenne ou grande.
   1.438 -
   1.439 -En outre, Subversion implique une surchage substantielle dans le stockage local
   1.440 +goulots d'étranglement pour les projets de tailles moyennes ou grandes.
   1.441 +
   1.442 +En outre, Subversion implique une surcharge substantielle dans le stockage local
   1.443  de certaines données, pour éviter des transactions avec le serveur, pour 
   1.444  certaines opérations communes, tel que la recherche des fichier modifiées
   1.445  (\texttt{status}) et l'affichage des modifications par rapport la révision 
   1.446  courante (\texttt{diff}). En conséquence, un répertoire de travail Subversion
   1.447 -a souvent la même taille, ou est plus grand, que un dépôt Mercurial et son
   1.448 +a souvent la même taille, ou est plus grand, qu'un dépôt Mercurial et son
   1.449  espace de travail, bien que le dépôt Mercurial contienne l'intégralité de
   1.450  l'historique.
   1.451  
   1.452 -Subversion est largement supportés par les outils tierses. Mercurial est
   1.453 +Subversion est largement supporté par les outils tierces. Mercurial est
   1.454  actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins,
   1.455 -et en effet certains des outils graphiques sont maintenant supérieur à leurs
   1.456 +et en effet certains des outils graphiques sont maintenant supérieurs à leurs
   1.457  équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent
   1.458  manuel utilisateur.
   1.459  
   1.460 -Parce que Subversion ne stocke par l'historique chez ses clients, il est 
   1.461 -parfaitement adapté à la gestion de projet qui doivent suivre un ensemble
   1.462 -de large fichier binaires et opaques. Si vous suivez une cinquantaine de
   1.463 +Parce que Subversion ne stocke pas l'historique chez ses clients, il est 
   1.464 +parfaitement adapté à la gestion de projets qui doivent suivre un ensemble
   1.465 +de larges fichiers binaires et opaques. Si vous suivez une cinquantaine de
   1.466  versions d'un fichier incompressible de 10MB, l'occupation disque coté client
   1.467  d'un projet sous Subversion restera à peu près constante. A l'inverse, 
   1.468  l'occupation disque du même projet sous n'importe lequel des gestionnaire
   1.469  de source distribués grandira rapidement, proportionnellement aux nombres
   1.470 -de versions, car les différences entre chaque révision sera très grande.
   1.471 -
   1.472 -En outre, c'est souvent difficle ou, généralement, impossible de fusionner
   1.473 +de versions, car les différences entre chaque révisions sera très grande.
   1.474 +
   1.475 +En outre, c'est souvent difficile ou, généralement, impossible de fusionner
   1.476  des différences dans un fichier binaire. La capacité de Subversion de 
   1.477 -vérouiller des fichiers, pour permettre à l'utilisateur d'être le seul
   1.478 -à le mettre à jour (``commit'') temporairement, est avantage significatif
   1.479 -dans un projet doté de beaucoup de fichiers binaire.
   1.480 +verrouiller des fichiers, pour permettre à l'utilisateur d'être le seul
   1.481 +à le mettre à jour (``commit'') temporairement, est un avantage significatif
   1.482 +dans un projet doté de beaucoup de fichiers binaires.
   1.483  
   1.484  Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut
   1.485  aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion.
   1.486 -Ceci rend très facile de ``tester l'eau'' et d'utiliser Mercurial et Subversion
   1.487 +Ceci rend très facile de ``prendre la température'' et d'utiliser Mercurial et Subversion
   1.488  en parallèle, avant de décider de migrer vers Mercurial. La conversion de 
   1.489 -l'historique est incrémental, donc vous pouvez effectuer une conversion 
   1.490 -initial, puis de petites additions par la suite pour ajouter les nouvelles
   1.491 +l'historique est incrémentale, donc vous pouvez effectuer une conversion 
   1.492 +initiale, puis de petites additions par la suite pour ajouter les nouvelles
   1.493  modifications.
   1.494  
   1.495  \subsection{Git}
   1.496  
   1.497  Git est un outil de gestion de source distribué qui fût développé pour gérer
   1.498 -le code source de noyau de Linux. Comme Mercurial, sa conception initial à 
   1.499 -était inspiré par Monotone.
   1.500 -
   1.501 -Git dispose d'un ensemble conséquent de command, avec plus de~139 commandes
   1.502 -individuels pour la version~1.5.0. Il a aussi la réputation d'être difficile
   1.503 +le code source de noyau de Linux. Comme Mercurial, sa conception initiale à 
   1.504 +était inspirée par Monotone.
   1.505 +
   1.506 +Git dispose d'un ensemble conséquent de commandes, avec plus de~139 commandes
   1.507 +individuelles pour la version~1.5.0. Il a aussi la réputation d'être difficile
   1.508  à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa 
   1.509  simplicité.
   1.510  
   1.511 @@ -415,33 +424,33 @@
   1.512  cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que 
   1.513  Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur
   1.514  Windows, les performances et le niveau de support général fourni par Git, 
   1.515 -au moment de l'écriture de cet ouvrage, bien derrière celui de Mercurial.
   1.516 +au moment de l'écriture de cet ouvrage, est bien derrière celui de Mercurial.
   1.517  
   1.518  Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git
   1.519  exige d'exécuter manuellement et régulièrement la commande ``repacks'' sur
   1.520  ces métadonnées. Sans ceci, les performances de git se dégrade, et la 
   1.521  consommation de l'espace disque augmente rapidement. Un serveur qui contient
   1.522 -plusieurs dépôt Git qui ne sont pas régulièrement et fréquement ``repacked''
   1.523 +plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment ``repacked''
   1.524  deviendra un vrai problème lors des ``backups'' du disque, et il y eu des
   1.525  cas, où un ``backup'' journalier pouvait durer plus de~24 heures. Un dépôt
   1.526 -fraichement ``repacked'' sera légèrement plus petit que un dépôt Mercurial,
   1.527 +fraichement ``repacked'' sera légèrement plus petit qu'un dépôt Mercurial,
   1.528  mais un dépôt non ``repacked'' est beaucoup plus grand.
   1.529  
   1.530 -Le coeur de Git est écrit en C. La plupart des commandes Git sont implémentés
   1.531 -sous forme de script Shell ou Perl, et la qualité de ces scripts varient
   1.532 +Le cœur de Git est écrit en C. La plupart des commandes Git sont implémentées
   1.533 +sous forme de scripts Shell ou Perl, et la qualité de ces scripts varie
   1.534  grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient
   1.535 -chargé en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
   1.536 -fatal.
   1.537 +chargés en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
   1.538 +fatale.
   1.539  
   1.540  Mercurial peut importer l'historique d'un dépôt Git.
   1.541  
   1.542  \subsection{CVS}
   1.543  
   1.544  CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui
   1.545 -dans le monde. À cause de son manque de properté interne, il n'est plus 
   1.546 +dans le monde. À cause de son manque de clarté interne, il n'est plus 
   1.547  maintenu depuis plusieurs années.
   1.548  
   1.549 -Il a une architecture client/serveur centralisé. Il ne groupe pas les
   1.550 +Il a une architecture client/serveur centralisée. Il ne regroupe pas les
   1.551  modifications de fichiers dans une opération de ``commit'' atomique, ce
   1.552  qui permet à ses utilisateurs de ``casser le \textit{build}'' assez
   1.553  facilement : une personne peut effectuer une opération de ``commit'' 
   1.554 @@ -454,30 +463,30 @@
   1.555  vous savez au moins quels sont ces fichiers).
   1.556  
   1.557  CVS a une notion étrange des \textit{tags} et des branches que je n'essayerais
   1.558 -même de décrire ici. Il ne supporte pas bien les opérations de renommage d'un 
   1.559 -fichier ou de répertoire, ce qui facilite la corruption de son dépôt. Il n'a
   1.560 +même pas de décrire ici. Il ne supporte pas bien les opérations de renommage d'un 
   1.561 +fichier ou d'un répertoire, ce qui facilite la corruption de son dépôt. Il n'a
   1.562  presque pas pour ainsi dire de contrôle de cohérence interne, il est donc 
   1.563  pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je
   1.564  ne recommanderais pas CVS pour un projet existant ou nouveau.
   1.565  
   1.566  Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a 
   1.567 -quelques princinpes à respecter; ce qui est vrai aussi pour les autres
   1.568 +quelques principes à respecter; ce qui est vrai aussi pour les autres
   1.569  outils d'import de projet CVS. À cause de l'absence de ``commit'' atomique
   1.570 -et gestion de version de l'arboresence, il n'est pas possible de reconstruire
   1.571 +et gestion de version de l'arborescence, il n'est pas possible de reconstruire
   1.572  de manière précise l'ensemble de l'historique. Un travail de ``devinette''
   1.573  est donc nécessaire, et les fichiers renommées ne sont pas détectés. Parce 
   1.574 -que une bonne part de l'administration d'un dépôt CVS est effectué manuellement, 
   1.575 -et est donc, sujette à erreur, il est courant que les impots CVS rencontre 
   1.576 +qu'une bonne part de l'administration d'un dépôt CVS est effectuée manuellement, 
   1.577 +et est donc, sujette à erreur, il est courant que les imports CVS rencontrent 
   1.578  de nombreux problèmes avec les dépôt corrompues (des \textit{timestamps} 
   1.579 -de révision complètement buggé et des fichiers vérouillés depuis des années 
   1.580 +de révision complètement buggé et des fichiers verrouillés depuis des années 
   1.581  sont deux des problèmes les moins intéressants dont je me souvienne).
   1.582  
   1.583  Mercurial peut importer l'historique depuis un dépôt CVS.
   1.584  
   1.585  \subsection{Commercial tools}
   1.586  
   1.587 -Perforce a une architecture client/server centralisée, sans aucun
   1.588 -mécanisme de cache de données coté client. Contrairement à la plupart
   1.589 +Perforce a une architecture client/serveur centralisée, sans aucun
   1.590 +mécanisme de mise en cache de données coté client. Contrairement à la plupart
   1.591  des outils modernes de gestion de source, Perforce exige de ses 
   1.592  utilisateurs d'exécuter une commande pour informer le serveur
   1.593  central de tout fichier qu'il souhaite modifier.
   1.594 @@ -485,32 +494,32 @@
   1.595  Les performances de Perforce sont plutôt bonnes pour des petites
   1.596  équipes, mais elles s'effondrent rapidement lorsque le nombre 
   1.597  d'utilisateurs augmente au delà de la douzaine. Des installations 
   1.598 -de Perforce assez large nécessite le déployement de proxies pour 
   1.599 +de Perforce assez larges nécessitent le déploiement de proxies pour 
   1.600  supporter la montée en charge associée.
   1.601  
   1.602 -\subsection{Choosing a revision control tool}
   1.603 -
   1.604 -A l'exception de CVS, tout les outils listés ci dessus ont des 
   1.605 +\subsection{Choisir un outil de gestion de source}
   1.606 +
   1.607 +A l'exception de CVS, tous les outils listés ci-dessus ont des 
   1.608  forces qui leur sont propres et qui correspondent à certaines
   1.609  formes de projet. Il n'y a pas un seul meilleur outil de gestion
   1.610  de source qui correspondent le mieux à toutes les situations.
   1.611  
   1.612 -Par exemple, Subversion est un très bon choix lorsque travailler
   1.613 -avec beaucoup de fichiers binaires, qui évolue régulièrement, grâce
   1.614 -à sa nature centraliser et sa capacité à vérouiller des fichiers.
   1.615 +Par exemple, Subversion est un très bon choix lorsqu'on travaille
   1.616 +avec beaucoup de fichiers binaires, qui évoluent régulièrement, grâce
   1.617 +à sa nature centralisée et sa capacité à verrouiller des fichiers.
   1.618  
   1.619  Personnellement, je préfère Mercurial pour sa simplicité, ses 
   1.620 -performances et son bonne capacité de fusion, et il me sert très bien
   1.621 +performances et sa bonne capacité de fusion, et il m'a très bien rendu service
   1.622  de plusieurs années maintenant.
   1.623  
   1.624  \section{Migrer depuis un outil à Mercurial}
   1.625  
   1.626  Mercurial est livré avec une extension nommée \hgext{convert}, qui
   1.627 -peut de manière incrémental importer des révision depuis différents
   1.628 -autres outils de gestion de source. Par ``incrémental'', j'entend que
   1.629 +peut de manière incrémentale importer des révisions depuis différents
   1.630 +autres outils de gestion de source. Par ``incrémental'', j'entends que
   1.631  vous pouvez convertir l'historique entier du projet en une seule fois,
   1.632  puis relancer l'outil d'import plus tard pour obtenir les modifications
   1.633 -effectués depuis votre import intial.
   1.634 +effectués depuis votre import initial.
   1.635  
   1.636  Les outils de gestion de source supportés par \hgext{convert} sont :
   1.637  \begin{itemize}
   1.638 @@ -521,14 +530,13 @@
   1.639  \end{itemize}
   1.640  
   1.641  En outre, \hgext{convert} peut exporter les modifications depuis Mercurial
   1.642 -vers Subversion. Ceci rend possible de d'essayer Subversion en parallèle 
   1.643 +vers Subversion. Ceci rend possible d'essayer Subversion en parallèle 
   1.644  avant de choisir une solution définitive, sans aucun risque de perte de
   1.645  données.
   1.646  
   1.647 -
   1.648  La commande \hgxcmd{conver}{convert} est très simple à utiliser. Simplement,
   1.649 -indiquer le chemin ou l'URL du dépôt de source, en lui indiquant, optionnellement
   1.650 -le nom du chemin de destination, et l'extension se met en route. Après cet
   1.651 +indiquez le chemin ou l'URL du dépôt de source, en lui indiquant éventuellement
   1.652 +le nom du chemin de destination, et la conversion se met en route. Après cet
   1.653  import initial, il suffit de relancer la commande encore une fois pour 
   1.654  importer les modifications effectuées depuis.
   1.655