1.1 --- a/fr/intro.tex	Mon Feb 16 18:13:41 2009 +0100
     1.2 +++ b/fr/intro.tex	Mon Feb 16 18:23:32 2009 +0100
     1.3 @@ -6,7 +6,7 @@
     1.4  La gestion de sources est un processus permettant de gérer différentes
     1.5  versions de la même information. Dans sa forme la plus simple, c'est
     1.6  ce que tout le monde fait manuellement : quand vous modifiez
     1.7 -un fichier, vous le sauvegarder sous un nouveau nom contenant un numéro,
     1.8 +un fichier, vous le sauvegardez sous un nouveau nom contenant un numéro,
     1.9  à chaque fois plus grand que celui de la version précédente.
    1.10  
    1.11  Ce genre de gestion de version manuelle est cependant facilement sujette 
    1.12 @@ -16,7 +16,7 @@
    1.13  des versions d'un seul fichier. Dans les dernières décades, cette cible 
    1.14  s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
    1.15  aident un grand nombre de personnes à travailler ensemble. Les outils les
    1.16 -plus modernes n'ont aucune difficultés à gérer plusieurs milliers de 
    1.17 +plus modernes n'ont aucune difficulté à gérer plusieurs milliers de 
    1.18  personnes travaillant ensemble sur des projets regroupant plusieurs 
    1.19  centaines de milliers de fichiers.
    1.20  
    1.21 @@ -33,9 +33,9 @@
    1.22  \item Quand vous travaillez avec d'autres personnes, les logiciels de 
    1.23  gestion de source facilitent le travail collaboratif. Par exemple, quand
    1.24  plusieurs personnes font, plus ou moins simultanément, des modifications
    1.25 -incompatibles, le logiciel vous aidera à identifier et résoudre les conflits.
    1.26 +incompatibles, le logiciel vous aidera à identifier et à résoudre les conflits.
    1.27  \item L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
    1.28 -qui se révèlera être une erreur, vous pourrez revenir à une version
    1.29 +qui se révèle être une erreur, vous pourrez revenir à une version
    1.30  antérieure d'un fichier ou même d'un ensemble de fichiers. En fait, un outil de
    1.31  gestion de source \emph{vraiment} efficace vous permettra d'identifier à quel
    1.32  moment le problème est apparu (voir la section~\ref{sec:undo:bisect} pour plus
    1.33 @@ -48,13 +48,13 @@
    1.34  personnes.
    1.35  
    1.36  Une question fondamentale à propos des outils de gestion de source, qu'il s'agisse
    1.37 -du projet d'une personne ou d'une grande équipe, est quelles sont ses  
    1.38 -\emph{avantages} par rapport à ses \emph{coût}. Un outil qui est difficile à 
    1.39 +du projet d'une personne ou d'une grande équipe, est quels sont ses  
    1.40 +\emph{avantages} par rapport à ses \emph{coûts}. Un outil qui est difficile à 
    1.41  utiliser ou à comprendre exigera un lourd effort d'adaptation.
    1.42  
    1.43  Un projet de cinq milles personnes s'effondrera très certainement de lui même
    1.44  sans aucun processus et outil de gestion de source. Dans ce cas, le coût 
    1.45 -d'utilisation d'un logiciel de gestion de source est dérisoire, puisque 
    1.46 +d'utilisation d'un logiciel de gestion de source est dérisoire puisque 
    1.47  \emph{sans}, l'échec est presque garanti.
    1.48  
    1.49  D'un autre coté, un ``rapide hack'' d'une personne peut sembler un contexte
    1.50 @@ -64,11 +64,11 @@
    1.51  Mercurial supporte ces \emph{deux} échelles de travail. Vous pouvez apprendre
    1.52  les bases en quelques minutes seulement, et, grâce à sa performance, vous pouvez
    1.53  l'utiliser avec facilité sur le plus petit des projets. Cette simplicité 
    1.54 -signifie que vous n'avez pas de concepts obscurs ou de séquence de commandes
    1.55 +signifie que vous n'avez pas de concept obscurs ou de séquence de commandes
    1.56  défiant l'imagination, sans aucune corrélation avec \emph{ce que vous êtes 
    1.57 -vraiment entrain de faire}. En même temps, ces mêmes performances et sa 
    1.58 -nature ``peer-to-peer'' vous permet d'augmenter, sans difficulté, son 
    1.59 -utilisation à de très grand projet.
    1.60 +vraiment en train de faire}. En même temps, ces mêmes performances et sa 
    1.61 +nature ``peer-to-peer'' vous permettent d'augmenter, sans difficulté, son 
    1.62 +utilisation à de très grands projets.
    1.63  
    1.64  Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un
    1.65  bon outil peut rendre beaucoup plus fluide votre travail.
    1.66 @@ -77,15 +77,15 @@
    1.67  
    1.68  La gestion de source\footnote{NdT: J'ai utilisé systématiquement le terme
    1.69  ``gestion de source'' à travers tout l'ouvrage. Ce n'est pas forcement la
    1.70 -meilleur traduction, et ceci peut rendre la lecture un peu lourde, mais je
    1.71 +meilleure traduction, et ceci peut rendre la lecture un peu lourde, mais je
    1.72  pense que le document y gagne en clarté et en précision.} est un domaine
    1.73  divers, tellement qu'il n'existe pas une seul nom ou acronyme pour le désigner.
    1.74  Voilà quelqu'uns des noms ou 
    1.75  acronymes que vous rencontrerez le plus souvent\footnote{NdT: J'ai conservé la
    1.76  liste des noms en anglais pour des raisons de commodité (ils sont plus
    1.77 -``googelable''). En outre, j'ai opté  conserver l'ensemble des opérations de
    1.78 +``googelable''). En outre, j'ai opté  pour conserver l'ensemble des opérations de
    1.79  Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en anglais, là
    1.80 -aussi pour faciliter la lecture d'autres documents en anglais, et aussi
    1.81 +aussi pour faciliter la lecture d'autres documents en anglais, ainsi que
    1.82  l'utilisation de Mercurial}.
    1.83  
    1.84  :
    1.85 @@ -97,18 +97,17 @@
    1.86  \item \textit{Version control (VCS)}.
    1.87  \end{itemize}
    1.88  
    1.89 -Certains personnes prétendent que ces termes ont en fait des sens
    1.90 +Certaines personnes prétendent que ces termes ont en fait des sens
    1.91  différents mais en pratique ils se recouvrent tellement qu'il n'y a pas
    1.92  réellement de manière pertinente de les distinguer.
    1.93  
    1.94  \section{Une courte histoire de la gestion de source}
    1.95  
    1.96  Le plus célèbre des anciens outils de gestion de source est \textit{SCCS
    1.97 -(Source Code Control System)}, que Marc Rochkind conçu dans les laboratoire de
    1.98 +(Source Code Control System)}, que Marc Rochkind conçu dans les laboratoires de
    1.99  recherche de Bell (\textit{Bell Labs}), dans le début des années 70.
   1.100 -\textit{SCCS} ne fonctionnait que sur des fichiers individuels, et obligeait à
   1.101 -chaque personne travaillant sur le projet d'avoir un accès à un répertoire de
   1.102 -travail commun, sur le même système.  Seulement une seule personne pouvait
   1.103 +\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
   1.104 +travail commun, sur le même système. Seulement une seule personne pouvait
   1.105  modifier un fichier au même moment, ce fonctionnement était assuré par
   1.106  l'utilisation de verrou (``lock''). Il était courant que des personnes
   1.107  verrouillent des fichiers, et plus tard, oublient de le déverrouiller;
   1.108 @@ -117,9 +116,9 @@
   1.109  
   1.110  Walter Tichy a développé une alternative libre à \textit{SCCS} au début des
   1.111  années 80, qu'il nomma \textit{RSC (Revison Control System)}.  Comme
   1.112 -\textit{SCCS}, \textit{RCS} demander aux développeurs de travailler sur le même
   1.113 +\textit{SCCS}, \textit{RCS} demandait aux développeurs de travailler sur le même
   1.114  répertoire partagé, et de verrouiller les
   1.115 -fichiers pour se prémunir de tout conflit issue de modifications concurrentes.
   1.116 +fichiers pour se prémunir de tout conflit issu de modifications concurrentes.
   1.117  
   1.118  Un peu plus tard dans les années 1980, Dick Grune utilisa \textit{RCS} comme
   1.119  une brique de base pour un ensemble de scripts \textit{shell} qu'il intitula
   1.120 @@ -133,14 +132,14 @@
   1.121  la ``fusion'' (\textit{``merge''}) de leurs fichiers, avant d'effectuer le
   1.122  ``commit'' de leur modifications sur le dépôt central.
   1.123  
   1.124 -Brian Berliner repris les scripts de Grune's et les réécris en~C, qu'il publia
   1.125 +Brian Berliner reprit les scripts de Grune's et les réécrit en~C, qu'il publia
   1.126  en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de
   1.127  CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, transformant son
   1.128  architecture en client/serveur. L'architecture de CVS est centralisée, seul le
   1.129  serveur a une copie de l'historique du projet. L'espace de travail client ne
   1.130  contient qu'une copie de la dernière version du projet, et quelques métadonnées
   1.131  pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui
   1.132 -c'est probablement l'outil de gestion de contrôle le plus utilisé au monde. 
   1.133 +il est probablement l'outil de gestion de contrôle le plus utilisé au monde. 
   1.134  
   1.135  Au début des années 1990, Sun Microsystmes développa un premier outil de
   1.136  gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare
   1.137 @@ -157,21 +156,21 @@
   1.138  lire et à maintenir, ce qui agrandit largement le ``niveau de souffrance''
   1.139  associé à la réparation de ces problèmes d'architecture de manière prohibitive. 
   1.140  
   1.141 -En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillés sur
   1.142 +En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé sur
   1.143  CVS, initièrent un projet pour le remplacer par un outil qui aurait une
   1.144 -meilleur architecture et un code plus propre. Le résultat, Subversion, ne
   1.145 +meilleure architecture et un code plus propre. Le résultat, Subversion, ne
   1.146  quitte pas le modèle centralisé et client/server de CVS, mais ajoute les
   1.147  opérations de ``commit'' atomique sur de multiples fichiers, une meilleure
   1.148  gestion des espaces de noms, et d'autres fonctionnalités qui en font un
   1.149  meilleur outil que CVS. Depuis sa première publication, il est rapidement
   1.150  devenu très populaire.
   1.151  
   1.152 -Plus ou moins de simultanément, Graydon Hoare a commencé sur l'ambitieux
   1.153 +Plus ou moins simultanément, Graydon Hoare a commencé sur l'ambitieux
   1.154  système de gestion distribué Monotone. Bien que Monotone corrige plusieurs
   1.155 -défaut de CVS's tout en offrant une architecture ``peer-to-peer'', il va aussi
   1.156 +défauts de CVS's tout en offrant une architecture ``peer-to-peer'', il va aussi
   1.157  plus loin que la plupart des outils de révision de manière assez innovante. Il
   1.158 -utilise des ``hash'' cryptographique comme identifiant, et il a une notion
   1.159 -complète de ``confiance'' du code issue de différentes sources.
   1.160 +utilise des ``hash'' cryptographiques comme identifiants, et il a une notion
   1.161 +complète de ``confiance'' du code issu des différentes sources.
   1.162  
   1.163  Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se
   1.164  concentre sur la facilité d'utilisation, les performances et la capacité à
   1.165 @@ -179,23 +178,23 @@
   1.166  
   1.167  \section{Tendances de la gestion de source}
   1.168  
   1.169 -Il y a eu une tendance évidente dans le développement et l'utilisation d'outil
   1.170 +Il y a eu une tendance évidente dans le développement et l'utilisation d'outils
   1.171  de gestion de source depuis les quatre dernières décades, au fur et à mesure
   1.172 -que les utilisateurs se sont habitués à leur outils et se sont sentis contraint
   1.173 -par leur limitations.
   1.174 +que les utilisateurs se sont habitués à leur outils et se sont sentis contraints
   1.175 +par leurs limitations.
   1.176  
   1.177  La première génération commença simplement par gérer un fichier unique sur un
   1.178  ordinateur individuel. Cependant, même si ces outils présentaient une grande
   1.179  avancée par rapport à la gestion manuelle des versions, leur modèle de
   1.180 -verrouillage et leur utilisation limitée à un seul ordinateur rendait leur
   1.181 +verrouillage et leur utilisation limitée à un seul ordinateur rendaient leur
   1.182  utilisation possible uniquement dans une très petite équipe. 
   1.183  
   1.184  La seconde génération a assoupli ces contraintes en adoptant une architecture
   1.185 -réseau et centralisé, permettant de gérer plusieurs projets entiers en même
   1.186 -temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveau
   1.187 +réseau et centralisée, permettant de gérer plusieurs projets entiers en même
   1.188 +temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveaux
   1.189  problèmes. Avec les clients discutant régulièrement avec le serveurs, la montée
   1.190  en charge devint un réel problème sur les gros projets. Une connexion réseau
   1.191 -peu fiable pouvant complètement empêcher les utilisateurs distant de dialoguer
   1.192 +peu fiable pouvait complètement empêcher les utilisateurs distants de dialoguer
   1.193  avec le serveur. Alors que les projets \textit{Open Source} commencèrent à
   1.194  mettre en place des accès en lecture seule disponible anonymement, les
   1.195  utilisateurs sans les privilèges de ``commit'' réalisèrent qu'ils ne pouvaient
   1.196 @@ -205,18 +204,18 @@
   1.197  La génération actuelle des outils de gestion de source est ``peer-to-peer'' par
   1.198  nature. Tout ces systèmes ont abandonné la dépendance à un serveur central, et
   1.199  ont permis à leur utilisateur de distribuer les données de leur gestion de
   1.200 -source à qui en a besoin. La collaboration à travers Internet a transformée la
   1.201 -contrainte technologique à une simple question de choix et de consencus. Les
   1.202 -outils moderne peuvent maintenant fonctionner en mode déconnecté sans limite et
   1.203 +source à qui en a besoin. La collaboration à travers Internet a transformé la
   1.204 +contrainte technologique en une simple question de choix et de consencus. Les
   1.205 +outils modernes peuvent maintenant fonctionner en mode déconnecté sans limite et
   1.206  de manière autonome, la connexion au réseau n'étant nécessaire que pour
   1.207  synchroniser les modifications avec les autres dépôts.
   1.208  
   1.209 -\section{Quelques avantages des gestionnaire de source distribué}
   1.210 +\section{Quelques avantages des gestionnaires de source distribués}
   1.211  
   1.212  Même si les gestionnaire de source distribués sont depuis plusieurs années
   1.213 -assez robustes et aussi utilisables que leur prédécesseurs, les utilisateurs
   1.214 +assez robustes et aussi utilisables que leurs prédécesseurs, les utilisateurs
   1.215  d'autres outils n'y ont pas encore été sensibilisés. Les gestionnaires
   1.216 -de sources distribués se distinguent particulièrement de leurs équivalents
   1.217 +de source distribués se distinguent particulièrement de leurs équivalents
   1.218  centralisés de nombreuses manières.
   1.219  
   1.220  Pour un développeur individuel, ils restent beaucoup plus rapides que les
   1.221 @@ -226,7 +225,7 @@
   1.222  central. Un outil distribué stocke toute ses métadonnées localement. À tâche
   1.223  égale, effectuer un échange avec le réseau ajoute un délai aux outils 
   1.224  centralisés. Ne sous-estimez pas la valeur d'un outil rapide : vous allez
   1.225 -passer beaucoup de temps à interagir avec un logiciel de gestion de sources.
   1.226 +passer beaucoup de temps à interagir avec un logiciel de gestion de source.
   1.227  
   1.228  Les outils distribués sont complètement indépendants des aléas de votre serveur,
   1.229  d'autant plus qu'ils répliquent les métadonnées à beaucoup d'endroits. Si
   1.230 @@ -241,8 +240,8 @@
   1.231  Avec un outil distribué, si votre connexion réseau tombe pendant que vous
   1.232  travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose
   1.233  que vous ne serez pas capable de faire sera de communiquer avec des dépôts
   1.234 -distants, opération somme toute assez rare par comparaison aux opérations
   1.235 -locales. Si vous avez une équipe de collaborateurs très dispersés ceci peut
   1.236 +distants, opération somme toute assez rare en comparaison aux opérations
   1.237 +locales. Si vous avez une équipe de collaborateurs très dispersée ceci peut
   1.238  être significatif.
   1.239  
   1.240  \subsection{Avantages pour les projets \textit{Open Source}}
   1.241 @@ -267,9 +266,9 @@
   1.242  posent un risque pour les projets \textit{Open Source} car ils 
   1.243  facilitent grandement la création de ``fork''\footnote{NdT:Création 
   1.244  d'une 
   1.245 -\url{version alternative du logiciel}{http://fr.wikipedia.org/wiki/Fork\#Embranchement\_d.27un\_projet\_informatique}.}
   1.246 +\url{version alternative du logiciel}{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}.}
   1.247  Un ``fork'' apparait quand il y des divergences d'opinion ou d'attitude
   1.248 -au sein d'un groupe de développeurs qui aboutit à la décision de ne 
   1.249 +au sein d'un groupe de développeurs qui aboutissent à la décision de ne 
   1.250  plus travailler ensemble. Chaque parti s'empare d'une copie plus ou moins
   1.251  complète du code source du projet et continue dans sa propre direction.
   1.252  
   1.253 @@ -279,13 +278,13 @@
   1.254  décider quelle modification est ``la gagnante'', et replacer, par un
   1.255  moyen ou un autre, les modifications de l'autre équipe dans l'arborescence
   1.256  du projet. Ceci implique généralement la perte d'une partie de l'historique 
   1.257 -d'un des partie, ou même des deux.
   1.258 +d'un des partis, ou même des deux.
   1.259  
   1.260  Ce que les outils distribués permettent à ce sujet est probablement
   1.261 -la \emph{meilleur} façon de développer un projet. Chaque modification
   1.262 +la \emph{meilleure} façon de développer un projet. Chaque modification
   1.263  que vous effectuez est potentiellement un ``fork''. La grande force de 
   1.264  cette approche est que les gestionnaires de source distribués doivent être
   1.265 -vraiment très efficasses pour \emph{fusionner}\footnote{NdT:j'ai choisi de
   1.266 +vraiment très efficaces pour \emph{fusionner}\footnote{NdT:j'ai choisi de
   1.267  traduire ici \textit{merging} par ``fusionner'' pour des raisons de clarté}
   1.268  des ``forks'', car les ``forks'', dans ce contexte, arrivent tout le
   1.269  temps.
   1.270 @@ -297,16 +296,15 @@
   1.271  les chances de ``fork'':
   1.272  \begin{itemize}
   1.273  \item Ils éliminent la distinction sociale qu'imposent les outils centralisés
   1.274 -	entre les membres du projets (ceux qui ont accès au ``commit'') et ceux de l'
   1.275 -	extérieur (ce qui ne l'ont pas).
   1.276 +	entre les membres du projets (ceux qui ont accès au ``commit'') et ceux de l'extérieur (ce qui ne l'ont pas).
   1.277  \item Ils rendent plus facile la réconciliation après un ``fork'' social, car
   1.278 -	tout ce qu'elle implique est juste une simple fusion.
   1.279 +	tout ce qu'elle implique est une simple fusion.
   1.280  \end{itemize}
   1.281  
   1.282  Certaines personnes font de la résistance envers les gestionnaires de source
   1.283 -distribués parce qu'ils veulent garder un contrôle ferme de leur projet, et
   1.284 +distribués parce qu'ils veulent garder un contrôle ferme sur leur projet, et
   1.285  ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins,
   1.286 -si c'est votre cas, sachez que si vous publier votre dépôt CVS ou Subversion
   1.287 +si c'est votre cas, sachez que si vous publiez votre dépôt CVS ou Subversion
   1.288  de manière publique, il existe une quantité d'outils disponibles pour récupérer
   1.289  entièrement votre projet et son historique (quoique lentement) et le récréer 
   1.290  ailleurs, sans votre contrôle. En fait, votre contrôle sur votre projet est 
   1.291 @@ -327,12 +325,12 @@
   1.292  Beaucoup de projets commerciaux sont réalisés par des équipes éparpillées
   1.293  à travers le globe. Les contributeurs qui sont loin du serveur central
   1.294  devront subir des commandes lentes et même parfois peu fiables. Les 
   1.295 -solutions propriétaires de gestion de source, tentent de palier ce problème 
   1.296 -avec des réplications de site distant qui sont à la fois coûteuses à mettre
   1.297 +solutions propriétaires de gestion de source tentent de palier ce problème 
   1.298 +avec des réplications de sites distants qui sont à la fois coûteuses à mettre
   1.299  en place et lourdes à administrer. Un système distribué ne souffre pas
   1.300  de ce genre de problèmes. En outre, il est très aisé de mettre en place
   1.301  plusieurs serveurs de références, disons un par site, de manière à ce qu'il
   1.302 -n'y est pas de communication redondante entre les dépôts, sur une connexion
   1.303 +n'y ait pas de communication redondante entre les dépôts, sur une connexion
   1.304  longue distance souvent onéreuse.
   1.305  
   1.306  Les systèmes de gestion de source supportent généralement assez mal la 
   1.307 @@ -347,10 +345,10 @@
   1.308  équipe, et la réplication pour balancer la charge devient le
   1.309  travail d'un simple script.
   1.310  
   1.311 -Si vous avez des employés sur le terrain, entrain de chercher à résoudre un soucis sur
   1.312 +Si vous avez des employés sur le terrain, en train de chercher à résoudre un souci sur
   1.313  le site d'un client, ils bénéficieront aussi d'un gestionnaire de source
   1.314 -distribués. Cet outil leur permettra de générer des versions personnalisées,
   1.315 -d'essayer différentes solutions, en les isolant aisément les une des autres,
   1.316 +distribué. Cet outil leur permettra de générer des versions personnalisées,
   1.317 +d'essayer différentes solutions, en les isolant aisément les unes des autres,
   1.318  et de rechercher efficacement à travers l'historique des sources, la cause
   1.319  des bugs ou des régressions, tout ceci sans avoir besoin de la moindre 
   1.320  connexion au réseau de votre compagnie.
   1.321 @@ -361,17 +359,17 @@
   1.322  pertinent pour la gestion de source:
   1.323  \begin{itemize}
   1.324  	\item Il est facile à apprendre et à utiliser ;
   1.325 -	\item il est léger et performant ;
   1.326 -	\item il monte facilement en charge ; 
   1.327 -	\item il est facile à personnaliser ;
   1.328 +	\item Il est léger et performant ;
   1.329 +	\item Il monte facilement en charge ; 
   1.330 +	\item Il est facile à personnaliser ;
   1.331  \end{itemize}
   1.332  
   1.333  Si vous êtes déjà familier d'un outil de gestion de source, vous serez
   1.334  capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup
   1.335  plus long\footnote{NdT: Pour appuyer le propos de l'auteur, je signale que 
   1.336  j'utilise Mercurial comme outil d'initiation à la gestion de contrôle dans
   1.337 -des travaux pratique à l'ESME Sudria (\url{http://www.esme.fr}) et que les
   1.338 -élèves le prennent en main sans difficulté majeur malgré l'approche distribuée.}. 
   1.339 +des travaux pratiques à l'ESME Sudria (\url{http://www.esme.fr}) et que les
   1.340 +élèves le prennent en main sans difficulté majeure malgré l'approche distribuée.}. 
   1.341  Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont 
   1.342  généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête 
   1.343  simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions.
   1.344 @@ -379,10 +377,10 @@
   1.345  Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en
   1.346  quelques instants. Ajouter des modifications ou des branches, transférer 
   1.347  ces modifications (localement ou via le réseau), et les opérations 
   1.348 -d'historique ou de statut sont aussi très rapide. Mercurial reste hors de 
   1.349 +d'historique ou de statut sont aussi très rapides. Mercurial reste hors de 
   1.350  votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution.
   1.351  
   1.352 -L'utilité de Mercurial ne se limite pas à des petits projets: il est 
   1.353 +L'utilité de Mercurial ne se limite pas à de petits projets: il est 
   1.354  aussi utilisé par des projets ayant des centaines ou même des milliers
   1.355  de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des
   1.356  centaines de méga de code source.
   1.357 @@ -392,8 +390,8 @@
   1.358  %TODO
   1.359  % For both spanish and english version, add the following examples:
   1.360  \begin{itemize}
   1.361 -	\item \url{Firefox}{https://developer.mozilla.org/en/Mozilla\_Source\_Code\_(Mercurial)} ;
   1.362 -	\item \url{OpenSolaris}{http://opensolaris.org/os/community/tools/scm/hg\_help/} ;
   1.363 +	\item \url{Firefox}{https://developer.mozilla.org/en/Mozilla_Source_Code_(Mercurial)} ;
   1.364 +	\item \url{OpenSolaris}{http://opensolaris.org/os/community/tools/scm/hg_help/} ;
   1.365  	\item \url{OpenJDK}{http://hg.openjdk.java.net/} (utilisant en outre l'extension 
   1.366  	``forest'' pour gérer ses sous modules);
   1.367  \end{itemize}
   1.368 @@ -401,7 +399,7 @@
   1.369  Si les fonctionnalités cœur de Mercurial ne sont pas suffisantes pour vous, 
   1.370  il est très aisé d'en construire d'autres. Mercurial est adapté à l'utilisation
   1.371  de scripts, et son implémentation interne en Python, propre et claire,
   1.372 -rend encore plus facile l'ajout de fonctionnalité sous forme d'extensions. Il
   1.373 +rend encore plus facile l'ajout de fonctionnalités sous forme d'extensions. Il
   1.374  en existe déjà un certain nombre de très populaires et très utiles, 
   1.375  dont le périmètre va de la recherche de bugs à l'amélioration des performances.
   1.376  
   1.377 @@ -410,26 +408,26 @@
   1.378  Avant que vous n'alliez plus loin, comprenez bien que cette section
   1.379  reflète mes propres expériences, et elle est donc (j'ose le dire)
   1.380  peu objective. Néanmoins, j'ai utilisé les outils de gestion de source
   1.381 -listé ci dessous, dans la plupart des cas, pendant plusieurs années.
   1.382 +listés ci dessous, dans la plupart des cas, pendant plusieurs années.
   1.383  %% TODO: Fussy translation.
   1.384  
   1.385  \subsection{Subversion}
   1.386  
   1.387 -Subversion est un outil de gestion de source les plus populaire, il fût 
   1.388 +Subversion est un des outils de gestion de source les plus populaire, il fût 
   1.389  développé pour remplacer CVS. Il a une architecture client/server centralisée.
   1.390  
   1.391  Subversion et Mercurial ont des noms de commandes très similaires pour 
   1.392  les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile
   1.393 -d'apprendre l'autre. Ces deux outils sont portable sur les systèmes 
   1.394 -d'exploitation les plus populaires\footnote{NdT:Mercurial fonctionne sans problèmes
   1.395 +d'apprendre l'autre. Ces deux outils sont portables sur les systèmes 
   1.396 +d'exploitation les plus populaires\footnote{NdT:Mercurial fonctionne sans problème
   1.397  sur OpenVMS à l'ESME Sudria \url{http://www.esme.fr}, compte tenu que Subversion a été 
   1.398  développé en C, je ne suis pas sûr que son portage aurait été aussi aisé.}.
   1.399  %TODO: Backport this statement in english and spanish 
   1.400  
   1.401  Avant la version 1.5, Subversion n'offrait aucune forme de support pour les fusions. Lors 
   1.402 -de l'écriture de ce livre, ces capacités de fusion étaient nouvelles, et réputés pour être
   1.403 +de l'écriture de ce livre, ses capacités de fusion étaient nouvelles, et réputées pour être
   1.404  \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complexes
   1.405 -et buggués}.
   1.406 +et bugguées}.
   1.407  
   1.408  Mercurial dispose d'un avantage substantiel en terme de performance par rapport à 
   1.409  Subversion sur la plupart des opérations que j'ai pu tester. J'ai mesuré
   1.410 @@ -439,13 +437,13 @@
   1.411  un déploiement plus réaliste, impliquant un stockage réseau, Subversion 
   1.412  serait encore plus désavantagé. Parce que la plupart des commandes Subversion
   1.413  doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme
   1.414 -de réplication, la capacité du serveur et la bande passante sont devenu des
   1.415 -goulots d'étranglement pour les projets de tailles moyennes ou grandes.
   1.416 +de réplication, la capacité du serveur et la bande passante sont devenues des
   1.417 +goulots d'étranglement pour les projets de taille moyenne ou grande.
   1.418  
   1.419  En outre, Subversion implique une surcharge substantielle dans le stockage local
   1.420  de certaines données, pour éviter des transactions avec le serveur, pour 
   1.421 -certaines opérations communes, tel que la recherche des fichier modifiées
   1.422 -(\texttt{status}) et l'affichage des modifications par rapport la révision 
   1.423 +certaines opérations communes, telles que la recherche des fichiers modifiés
   1.424 +(\texttt{status}) et l'affichage des modifications par rapport à la révision 
   1.425  courante (\texttt{diff}). En conséquence, un répertoire de travail Subversion
   1.426  a souvent la même taille, ou est plus grand, qu'un dépôt Mercurial et son
   1.427  espace de travail, et ceci bien que le dépôt Mercurial contienne l'intégralité 
   1.428 @@ -462,9 +460,9 @@
   1.429  de larges fichiers binaires et opaques. Si vous suivez une cinquantaine de
   1.430  versions d'un fichier incompressible de 10MB, l'occupation disque coté client
   1.431  d'un projet sous Subversion restera à peu près constante. A l'inverse, 
   1.432 -l'occupation disque du même projet sous n'importe lequel des gestionnaire
   1.433 +l'occupation disque du même projet sous n'importe lequel des gestionnaires
   1.434  de source distribués grandira rapidement, proportionnellement aux nombres
   1.435 -de versions, car les différences entre chaque révisions sera très grande.
   1.436 +de versions, car les différences entre chaque révisions seront très grandes.
   1.437  
   1.438  En outre, c'est souvent difficile ou, généralement, impossible de fusionner
   1.439  des différences dans un fichier binaire. La capacité de Subversion de 
   1.440 @@ -483,8 +481,8 @@
   1.441  \subsection{Git}
   1.442  
   1.443  Git est un outil de gestion de source distribué qui fût développé pour gérer
   1.444 -le code source de noyau de Linux. Comme Mercurial, sa conception initiale à 
   1.445 -était inspirée par Monotone.
   1.446 +le code source de noyau de Linux. Comme Mercurial, sa conception initiale a 
   1.447 +été inspirée par Monotone.
   1.448  
   1.449  Git dispose d'un ensemble conséquent de commandes, avec plus de~139 commandes
   1.450  individuelles pour la version~1.5.0. Il a aussi la réputation d'être difficile
   1.451 @@ -499,7 +497,7 @@
   1.452  
   1.453  Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git
   1.454  exige d'exécuter manuellement et régulièrement la commande ``repacks'' sur
   1.455 -ces métadonnées. Sans ceci, les performances de git se dégrade, et la 
   1.456 +ces métadonnées. Sans ceci, les performances de git se dégradent et la 
   1.457  consommation de l'espace disque augmente rapidement. Un serveur qui contient
   1.458  plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment ``repacked''
   1.459  deviendra un vrai problème lors des ``backups'' du disque, et il y eu des
   1.460 @@ -511,7 +509,7 @@
   1.461  sous forme de scripts Shell ou Perl, et la qualité de ces scripts varie
   1.462  grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient
   1.463  chargés en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
   1.464 -fatale.
   1.465 +fatal.
   1.466  
   1.467  Mercurial peut importer l'historique d'un dépôt Git.
   1.468  
   1.469 @@ -525,7 +523,7 @@
   1.470  modifications de fichiers dans une opération de ``commit'' atomique, ce
   1.471  qui permet à ses utilisateurs de ``casser le \textit{build}'' assez
   1.472  facilement : une personne peut effectuer une opération de ``commit'' 
   1.473 -sans problème puis être bloqué par besoin de fusion, avec comme conséquence
   1.474 +sans problème puis être bloquée par besoin de fusion, avec comme conséquence
   1.475  néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses
   1.476  modifications. Ce problème affecte aussi la manière de travailler avec 
   1.477  l'historique du projet. Si vous voulez voir toutes les modifications d'une
   1.478 @@ -533,23 +531,23 @@
   1.479  \textit{timestamps} des modifications de chacun des fichiers impliqués (si
   1.480  vous savez au moins quels sont ces fichiers).
   1.481  
   1.482 -CVS a une notion étrange des \textit{tags} et des branches que je n'essayerais
   1.483 +CVS a une notion étrange des \textit{tags} et des branches que je n'essayerai
   1.484  même pas de décrire ici. Il ne supporte pas bien les opérations de renommage d'un 
   1.485  fichier ou d'un répertoire, ce qui facilite la corruption de son dépôt. Il n'a
   1.486  presque pas pour ainsi dire de contrôle de cohérence interne, il est donc 
   1.487  pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je
   1.488 -ne recommanderais pas CVS pour un projet existant ou nouveau.
   1.489 +ne recommanderai pas CVS pour un projet existant ou nouveau.
   1.490  
   1.491  Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a 
   1.492  quelques principes à respecter; ce qui est vrai aussi pour les autres
   1.493  outils d'import de projet CVS. À cause de l'absence de ``commit'' atomique
   1.494  et gestion de version de l'arborescence, il n'est pas possible de reconstruire
   1.495  de manière précise l'ensemble de l'historique. Un travail de ``devinette''
   1.496 -est donc nécessaire, et les fichiers renommées ne sont pas détectés. Parce 
   1.497 +est donc nécessaire, et les fichiers renommés ne sont pas détectés. Parce 
   1.498  qu'une bonne part de l'administration d'un dépôt CVS est effectuée manuellement, 
   1.499  et est donc, sujette à erreur, il est courant que les imports CVS rencontrent 
   1.500 -de nombreux problèmes avec les dépôt corrompues (des \textit{timestamps} 
   1.501 -de révision complètement buggé et des fichiers verrouillés depuis des années 
   1.502 +de nombreux problèmes avec les dépôt corrompus (des \textit{timestamps} 
   1.503 +de révision complètement buggés et des fichiers verrouillés depuis des années 
   1.504  sont deux des problèmes les moins intéressants dont je me souvienne).
   1.505  
   1.506  Mercurial peut importer l'historique depuis un dépôt CVS.
   1.507 @@ -560,7 +558,7 @@
   1.508  mécanisme de mise en cache de données coté client. Contrairement à la plupart
   1.509  des outils modernes de gestion de source, Perforce exige de ses 
   1.510  utilisateurs d'exécuter une commande pour informer le serveur
   1.511 -central de tout fichier qu'il souhaite modifier.
   1.512 +central de tout fichier qu'ils souhaitent modifier.
   1.513  
   1.514  Les performances de Perforce sont plutôt bonnes pour des petites
   1.515  équipes, mais elles s'effondrent rapidement lorsque le nombre 
   1.516 @@ -573,7 +571,7 @@
   1.517  A l'exception de CVS, tous les outils listés ci-dessus ont des 
   1.518  forces qui leur sont propres et qui correspondent à certaines
   1.519  formes de projet. Il n'y a pas un seul meilleur outil de gestion
   1.520 -de source qui correspondent le mieux à toutes les situations.
   1.521 +de source qui correspondrait le mieux à toutes les situations.
   1.522  
   1.523  Par exemple, Subversion est un très bon choix lorsqu'on travaille
   1.524  avec beaucoup de fichiers binaires, qui évoluent régulièrement, grâce
   1.525 @@ -581,7 +579,7 @@
   1.526  
   1.527  Personnellement, je préfère Mercurial pour sa simplicité, ses 
   1.528  performances et sa bonne capacité de fusion, et il m'a très bien rendu service
   1.529 -depuis plusieurs années maintenant.
   1.530 +de plusieurs années maintenant.
   1.531  
   1.532  \section{Migrer depuis un outil à Mercurial}
   1.533  
   1.534 @@ -590,7 +588,7 @@
   1.535  autres outils de gestion de source. Par ``incrémental'', j'entends que
   1.536  vous pouvez convertir l'historique entier du projet en une seule fois,
   1.537  puis relancer l'outil d'import plus tard pour obtenir les modifications
   1.538 -effectués depuis votre import initial.
   1.539 +effectuées depuis votre import initial.
   1.540  
   1.541  Les outils de gestion de source supportés par \hgext{convert} sont :
   1.542  \begin{itemize}