Commits

Wilk  committed 4934b0c

review french intro.tex

  • Participants
  • Parent commits 53ca44b

Comments (0)

Files changed (1)

File fr/intro.tex

 \chapter{Introduction}
 \label{chap:intro}
 
-\section{A propros de la gestion source}
+\section{À propos de la gestion source}
 
-La gestion de source est un processus permettant de gérer différentes
-version de la même information. Dans sa forme la plus simple, c'est
-quelquechose que tout le monde fait manuellement : quand vous modifiez
+La gestion de sources est un processus permettant de gérer différentes
+versions de la même information. Dans sa forme la plus simple, c'est
+ce que tout le monde fait manuellement : quand vous modifiez
 un fichier, vous le sauvegarder sous un nouveau nom contenant un numéro,
-à chaque fois plus grand la précédente version.
+à chaque fois plus grand que celui de la version précédente.
 
-Ce genre de gestion de version manuel est cependant sujette facilement
+Ce genre de gestion de version manuelle est cependant facilement sujette 
 à des erreurs, ainsi, depuis longtemps, des logiciels existent pour
-adresser cette problématique. Les premiers outils de gestion de source
+résoudre cette problématique. Les premiers outils de gestion de sources
 étaient destinés à aider un seul utilisateur, à automatiser la gestion
-des versions d'un seulf fichier. Dans les dernières décades, cette cilble 
-a largement était agrandie, ils gèrent désormais de multiple fichiers, et
-aident un grand nombre de personnes à travailler ensemble. Le outils les
+des versions d'un seul fichier. Dans les dernières décades, cette cible 
+s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
+aident un grand nombre de personnes à travailler ensemble. Les outils les
 plus modernes n'ont aucune difficultés à gérer plusieurs milliers de 
 personnes travaillant ensemble sur des projets regroupant plusieurs 
 centaines de milliers de fichiers.
 
 \subsection{Pourquoi utiliser un gestionnaire de source ?}
 
-Il y a de nombreuse raisons pour que vous ou votre équipe souhaitiez
+Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez
 utiliser un outil automatisant la gestion de version pour votre projet.
 \begin{itemize}
 \item L'outil se chargera de suivre l'évolution de votre projet, sans
-que vous ayez à le faire. Pour chaque modification, vous aurez à votre
-disposition un journal indiquant \emph{qui} a faient quoi, \emph{pourquoi}
+que vous n'ayez à le faire. Pour chaque modification, vous aurez à votre
+disposition un journal indiquant \emph{qui} a fait quoi, \emph{pourquoi}
 ils l'ont fait, \emph{quand} ils l'ont fait, et \emph{ce} qu'ils ont
 modifiés.
 \item Quand vous travaillez avec d'autres personnes, les logiciels de 
-gestion de source facilite le travail collaboratif. Par exemple, quand
-plusieurs personnes font, plus ou moins simultannéement, des modifications
+gestion de source facilitent le travail collaboratif. Par exemple, quand
+plusieurs personnes font, plus ou moins simultanément, des modifications
 incompatibles, le logiciel vous aidera à identifier et résoudre les conflits.
 \item L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
-qui se révèlera être une erreur, vous pourrez revenir fiablement à une version
-antérieur d'une fichier ou même d'un ensemble de fichier. En fait, un outil de
+qui se révèlera être une erreur, vous pourrez revenir à une version
+antérieure d'un fichier ou même d'un ensemble de fichiers. En fait, un outil de
 gestion de source \emph{vraiment} efficace vous permettra d'identifier à quel
 moment le problème est apparu (voir la section~\ref{sec:undo:bisect} pour plus
 de détails).
 \item L'outil vous permettra aussi de travailler sur plusieurs versions différentes
-de votre projet et à gérer l'écart entre chaque.
+de votre projet et à gérer l'écart entre chacune.
 \end{itemize}
-La plupart de ces raisons ont autant d'importances---du moins en théorie--- que
+La plupart de ces raisons ont autant d'importances ---du moins en théorie--- que
 vous travailliez sur un projet pour vous, ou avec une centaine d'autres
 personnes.
 
-Une question fondamental à propos des outils de gestion de source, qu'il s'agisse
+Une question fondamentale à propos des outils de gestion de source, qu'il s'agisse
 du projet d'une personne ou d'une grande équipe, est quelles sont ses  
 \emph{avantages} par rapport à ses \emph{coût}. Un outil qui est difficile à 
-utiliser ou à comprendre exigera un effort d'adoption.
+utiliser ou à comprendre exigera un gros effort d'adaptation.
 
-Un projet de cinq milles personnnes s'effondrera très certainement de lui même
+Un projet de cinq milles personnes s'effondrera très certainement de lui même
 sans aucun processus et outil de gestion de source. Dans ce cas, le coût 
 d'utilisation d'un logiciel de gestion de source est dérisoire, puisque 
 \emph{sans}, l'échec est presque garanti.
 
-D'un autre coté, un ``rapide hack'' d'une personnne peut sembler un contexte
+D'un autre coté, un ``rapide hack'' d'une personne peut sembler un contexte
 bien pauvre pour utiliser un outil de gestion de source, car, bien évidement
 le coût d'utilisation dépasse le coût total du projet. N'est ce pas ?
 
 Mercurial supporte ces \emph{deux} échelles de travail. Vous pouvez apprendre
-les bases en juste quelques minutes, et, grâce à sa performance, vous pouvez
+les bases en quelques minutes seulement, et, grâce à sa performance, vous pouvez
 l'utiliser avec facilité sur le plus petit des projets. Cette simplicité 
-signifie que vous n'avez pas de concepts obscures ou de séquence de commandes
-défiant l'imagination, complètement décorrelé de \emph{ce que vous êtes 
+signifie que vous n'avez pas de concepts obscurs ou de séquence de commandes
+défiant l'imagination, sans aucune corrélation avec \emph{ce que vous êtes 
 vraiment entrain de faire}. En même temps, ces mêmes performances et sa 
 nature ``peer-to-peer'' vous permet d'augmenter, sans difficulté, son 
 utilisation à de très grand projet.
 
 Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un
-bon outil peut faire une grande différence dans la fluidité avec lequel 
+bon outil peut faire une grande différence dans la fluidité avec laquelle
 vous pourrez travailler avec.
 
 \subsection{Les multiples noms de la gestion de source}
 
-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
-une seul nom ou acronyme pour le désigner. Voilà quelqu'uns des noms ou 
-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}.
+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 une seul nom ou acronyme pour le désigner.
+Voilà quelqu'uns des noms ou 
+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}.
 
 :
 \begin{itemize}
 
 Le plus célèbre des anciens outils de gestion de source est \textit{SCCS (Source
 Code Control System)}, que Marc Rochkind conçu dans les laboratoire de recherche de Bell 
-(\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.
-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
-des fichiers, et plus tard, oublie de le dévérouiller; empêchant  n'importe qui d'autre de 
+(\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.
+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
+des fichiers, et plus tard, oublient de le déverrouiller; empêchant n'importe qui d'autre de 
 travailler sur ces fichiers sans l'aide de l'administrateur...
 
 Walter Tichy a développé une alternative libre à \textit{SCCS} au début des années 80, qu'il
 nomma \textit{RSC (Revison Control System)}.  Comme \textit{SCCS}, \textit{RCS}
-demander aux développeurs de travailler sur le même répertoire partagé, et de vérouiller les
+demander aux développeurs de travailler sur le même répertoire partagé, et de verrouiller les
 fichiers pour se prémunir de tout conflit issue de modifications concurrentes.
 
-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.
+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.
 
-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. 
+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. 
 
-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).
+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).
 
-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. 
+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. 
 
+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.
 
-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.
+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.
 
-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.
-
-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.
+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.
 
 \section{Tendances de la gestion de source}
 
-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.
+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.
 
-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. 
+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. 
 
-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.
+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.
 
-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.
+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.
 
 \section{Quelques avantages des gestionnaire de source distribué}
 
-Même si les gestionnaire de source distribué sont depuis plusieurs années
-assez robuste et aussi utilisable que leur prédécésseurs, les utilisateurs
-d'autres outils n'ont pas encore étaient sensibilisé. Les gestionnaires
-de sources distribué se distingue particulièrement de leurs équivalents
-centralisé de nombreuse manière.
+Même si les gestionnaire de source distribués sont depuis plusieurs années
+assez robustes et aussi utilisables que leur prédécesseurs, les utilisateurs
+d'autres outils n'y ont pas encore été sensibilisés. Les gestionnaires
+de sources distribués se distinguent particulièrement de leurs équivalents
+centralisés de nombreuses manières.
 
-Pour un développeur individuel, ils restent beaucoup plus rapide que les
-outils centralisés. Cela pour une raison simple: un outil centralisé doit
-toujours discuter à travers le réseau pour la plupart des opérations, car
+Pour un développeur individuel, ils restent beaucoup plus rapides que les
+outils centralisés. Cela pour une raison simple : un outil centralisé doit
+toujours dialoguer à travers le réseau pour la plupart des opérations, car
 presque toutes les métadonnées sont stockées sur la seule copie du serveur
 central. Un outil distribué stocke toute ses métadonnées localement. À tâche
 égale, effectuer un échange avec le réseau ajoute un délai aux outils 
-centralisés. Ne sous estimez pas la valeur d'un outil rapide: vous allez
+centralisés. Ne sous-estimez pas la valeur d'un outil rapide : vous allez
 passer beaucoup de temps à interagir avec un logiciel de gestion de sources.
 
-Les outils distribué sont complètement indépendant des aléas de votre serveur,
-encore une fois car ils répliquent les métadonnées à tellement d'endoit. Si
-votre serveur central prend feu, vous avez intérêt à ce que les média de 
-sauvegarde soient fiable, et que votre dernier ``backup'' soit récent et
+Les outils distribués sont complètement indépendants des aléas de votre serveur,
+d'autant plus qu'ils répliquent les métadonnées à beaucoup d'endroits. Si
+votre serveur central prend feu, vous avez intérêt à ce que les médias de 
+sauvegardes soient fiables, et que votre dernier ``backup'' soit récent et
 fonctionne sans problème. Avec un outil distribué, vous avez autant de 
 ``backup'' que de contributeurs.
 
 En outre, la fiabilité de votre réseau affectera beaucoup moins les
-outils distribué. Vous ne pouvez même pas utiliser un outil centralisé
-sans connexion réseau, à l'exception de quelques commandes, très limités. 
-Avec un outil distribué, si vous connexion réseau tombe pendant que vous
+outils distribués. Vous ne pouvez même pas utiliser un outil centralisé
+sans connexion réseau, à l'exception de quelques commandes, très limitées. 
+Avec un outil distribué, si votre connexion réseau tombe pendant que vous
 travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose
 que vous ne serez pas capable de faire sera de communiquer avec des dépôts
 distants, opération somme toute assez rare par comparaison aux opérations
-locales. Si vous avez une (TODO:far-flung???) équipe de collaborateurs, 
-ceci peut être significatif.
+locales. Si vous avez une équipe de collaborateurs très dispersés ceci peut
+être significatif.
 
 \subsection{Avantages pour les projets \textit{Open Source}}
 
 Si vous prenez goût à un projet \textit{Open Source} et que vous
 décidez de commencer à toucher à son code, et que le projet utilise
 un gestionnaire de source distribué, vous êtes immédiatement un "pair"
-avec les personnes formant le ``coeur'' du projet. Si ils publient
+avec les personnes formant le ``cœur'' du projet. Si ils publient
 leurs dépôts, vous pouvez immédiatement copier leurs historiques de
 projet, faire des modifications, enregistrer votre travail en utilisant
 les même outils qu'eux. Par comparaison, avec un outil centralisé, vous
 
 \subsubsection{Le non-problème du \textit{fork}}
 
-Il a été souvent suggeré que les gestionnaires de source distribués
+Il a été souvent suggéré que les gestionnaires de source distribués
 posent un risque pour les projets \textit{Open Source} car ils 
 facilitent grandement la création de ``fork''\footnote{NdT:Création 
 d'une version alternative du logiciel}. %%% TODO: Link to Wikipedia
 Un ``fork'' apparait quand il y des divergences d'opinion ou d'attitude
 au sein d'un groupe de développeurs qui aboutit à la décision de ne 
-plus travail ensemble. Chacun parti s'empare d'une copie plus ou moins
+plus travailler ensemble. Chacun parti s'empare d'une copie plus ou moins
 complète du code source du projet et continue dans sa propre direction.
 
-Parfois ces différents partis décide de se réconcilier. Avec un 
+Parfois ces différents partis décident de se réconcilier. Avec un 
 serveur central, l'aspect \emph{technique} de cette réconciliation
 est un processus douloureux, et essentiellement manuel. Vous devez
 décider quelle modification est ``la gagnante'', et replacer, par un
-moyen ou un autre, les modifications de l'autre équipe dans l'arboresence
-du projet. Ceci implique généralement la perte d'une partie l'historique 
+moyen ou un autre, les modifications de l'autre équipe dans l'arborescence
+du projet. Ceci implique généralement la perte d'une partie de l'historique 
 d'un des partie, ou même des deux.
 
 Ce que les outils distribués permettent à ce sujet est probablement
 la \emph{meilleur} façon de développer un projet. Chaque modification
-que vous effectué est potentiellement un ``fork''. La grande force de 
-cette approche est que les gestionnaire de source distribué doit être
-vraiment très efficase pour \emph{fusionner}\footnote{NdT:j'ai choisi de
+que vous effectuez est potentiellement un ``fork''. La grande force de 
+cette approche est que les gestionnaires de source distribués doivent être
+vraiment très efficasses pour \emph{fusionner}\footnote{NdT:j'ai choisi de
 traduire ici \textit{merging} par ``fusionner'' pour des raisons de clarté}
 des ``forks'', car les ``forks'', dans ce contexte, arrivent tout le
 temps.
 
-Si chaque altération que n'importe qui effectue, à tout moment, est vu
+Si chaque altération que n'importe qui effectue, à tout moment, est vue
 comme un ``fork'' à fusionner, alors ce que le monde de l'\textit{Open 
 Source} voit comme un ``fork'' devient \emph{uniquement} une problématique 
-social. En fait, les outils de gestion de source distribué \emph{réduisent} 
+sociale. En fait, les outils de gestions de source distribués \emph{réduisent} 
 les chances de ``fork'':
 \begin{itemize}
-\item Ils éliminent la distinction social qu'imposent les outils centralisés
-	entre les membres du projets (ce qui ont accès au ``comit'') et ceux de l'
+\item Ils éliminent la distinction sociale qu'imposent les outils centralisés
+	entre les membres du projets (ceux qui ont accès au ``commit'') et ceux de l'
 	extérieur (ce qui ne l'ont pas).
 \item Ils rendent plus facile la réconciliation après un ``fork'' social, car
 	tout ce qu'elle implique est juste une simple fusion.
 de manière fluide, en disposant d'un miroir ou d'un ``fork'' de votre
 historique.
 %%%TODO: Fussy, those last sentences are not really well translated:
+%%%no problem for me (wilk)
 %However, if you're of this belief, and you publish your CVS or Subversion 
 %repositories publically, there are plenty of tools available that can pull 
 %out your entire project's history (albeit slowly) and recreate it somewhere 
 
 \subsection{Avantages pour les projets commerciaux}
 
-Beaucoup de projets commerciaux sont réalisé par des équipes éparpillées
+Beaucoup de projets commerciaux sont réalisés par des équipes éparpillées
 à travers le globe. Les contributeurs qui sont loin du serveur central
-devront subir des commandes lentes et même parfois peu fiable. Les 
-solutions propriétaires gestion de source, tentent de palier ce problème 
+devront subir des commandes lentes et même parfois peu fiables. Les 
+solutions propriétaires de gestion de source, tentent de palier ce problème 
 avec des réplications de site distant qui sont à la fois coûteuses à mettre
-en place et lourdes à administrer. A un système distribué ne souffre pas
+en place et lourdes à administrer. Un système distribué ne souffre pas
 de ce genre de problèmes. En outre, il est très aisé de mettre en place
-plusieurs serveurs de références, disont un par site, de manière à ce qu'il
+plusieurs serveurs de références, disons un par site, de manière à ce qu'il
 n'y est pas de communication redondante entre les dépôts, sur une connexion
 longue distance souvent onéreuse.
 
 Les systèmes de gestion de source supportent généralement assez mal la 
-monté en charge. Ce n'est pas rare pour un gestionnaire de source centralisé 
-pourtant onéreux de s'effondrer sous la charge combinée de juste une douzaine 
-d'utilisateurs concurrents. Une fois encore, la réponse à cette problématique 
+montée en charge. Ce n'est pas rare pour un gestionnaire de source centralisé 
+pourtant onéreux de s'effondrer sous la charge combinée d'une douzaine 
+d'utilisateurs concurrents seulement. Une fois encore, la réponse à cette problématique 
 est généralement encore la mise en place d'un ensemble complexe de serveurs
-synchronisé par un mécanisme de réplication. Dans le cas d'un gestionnaire
-de source distribué, la charge du serveur central--- si vous avez un--- est
-plusieurs fois inférieur (car toutes les données sont déjà répliqués ailleurs),
-un simple server, pas très cher, peut gérer les besoins d'une plus grande
-équipe, et la réplication pour balancer la charge devient simplement le
+synchronisés par un mécanisme de réplication. Dans le cas d'un gestionnaire
+de source distribué, la charge du serveur central --- si vous avez un--- est
+plusieurs fois inférieure (car toutes les données sont déjà répliquées ailleurs),
+un simple serveur, pas très cher, peut gérer les besoins d'une plus grande
+équipe, et la réplication pour balancer la charge devient le
 travail d'un simple script.
 
-Si vous avez des employés sur le terrain, entrain de chercher à résoudre sur
+Si vous avez des employés sur le terrain, entrain de chercher à résoudre un soucis sur
 le site d'un client, ils bénéficieront aussi d'un gestionnaire de source
 distribués. Cet outil leur permettra de générer des versions personnalisées,
 d'essayer différentes solutions, en les isolant aisément les une des autres,
-et de recherche efficasement à travers l'historique des sources, la cause
-des bugs ou des régression, tout ceci sans avoir besoin de la moindre 
+et de rechercher efficacement à travers l'historique des sources, la cause
+des bugs ou des régressions, tout ceci sans avoir besoin de la moindre 
 connexion au réseau de votre compagnie.
 
 \section{Pourquoi choisir Mercurial?}
 Mercurial a plusieurs caractéristiques qui en font un choix particulièrement
 pertinent pour la gestion de source:
 \begin{itemize}
-	\item Il est facile à apprendre et à utiliser ;It is easy to learn and use.
+	\item Il est facile à apprendre et à utiliser ;
 	\item il est léger et performant ;
 	\item il monte facilement en charge ; 
 	\item il est facile à personnaliser ;
 de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des
 centaines de méga de code source.
 
-Voici une liste non exhaustive des projets complexe ou critique utilisant 
-mercurial :
+Voici une liste non exhaustive des projets complexes ou critiques utilisant 
+Mercurial :
 %TODO
 % For both spanish and english version, add the following examples:
 \begin{itemize}
 \end{itemize}
 % TODO: Also add appropriate link.
 
-Si les fonctionnalités coeur de Mercurial ne sont pas suffisantes pour vous, 
-il est très aisé de construire dessus. Mercurial est adapté à l'utilisation
-au sein de script, et son implémentation interne en python, propre et claire,
-rend encore plus facile l'ajout de fonctionnalité sous forme d'extension. Il
-en existe déjà un certains nombres de très populaires et très utiles, 
+Si les fonctionnalités cœur de Mercurial ne sont pas suffisantes pour vous, 
+il est très aisé d'en construire dessus. Mercurial est adapté à l'utilisation
+de scripts, et son implémentation interne en Python, propre et claire,
+rend encore plus facile l'ajout de fonctionnalité sous forme d'extensions. Il
+en existe déjà un certain nombre de très populaires et très utiles, 
 dont le périmètre va de la recherche de bugs à l'amélioration des performances.
 
 \section{Mercurial comparé aux autres outils}
 
 Avant que vous n'alliez plus loin, comprenez bien que cette section
 reflète mes propres expériences, et elle est donc (j'ose le dire)
-peu objectives. Néanmoins, j'ai utilisé les outils de gestion de source
+peu objective. Néanmoins, j'ai utilisé les outils de gestion de source
 listé ci dessous, dans la plupart des cas, pendant plusieurs années.
 %% TODO: Fussy translation.
 
 développé en C, je ne suis pas sûr que son portage aurait été aussi aisé.}.
 %TODO: Backport this statement in english and spanish 
 
-Avant la version 1.5, Subversion n'offre aucune forme de support pour les fusions. Lors 
-de l'écriture de ce livre, ces capacités de fusion sont nouvelle, et réputé pour être
+Avant la version 1.5, Subversion n'offrait aucune forme de support pour les fusions. Lors 
+de l'écriture de ce livre, ces capacités de fusion étaient nouvelles, et réputés pour être
 \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complexes
 et buggués}.
 
-Mercurial dispose d'un avantages substantiel en terme de performance sur 
-Subversion sur la plupart des opérations que j'ai pu testé. J'ai mesuré
+Mercurial dispose d'un avantage substantiel en terme de performance par rapport à 
+Subversion sur la plupart des opérations que j'ai pu tester. J'ai mesuré
 une différence de performance allant de deux à six fois plus rapide avec
 le système de stockage de fichier local de Subversion~1.4.3 
-(\emph{ra\_local}), qui la méthode d'accès la plus rapide disponible. Dans
+(\emph{ra\_local}), qui est la méthode d'accès la plus rapide disponible. Dans
 un déploiement plus réaliste, impliquant un stockage réseau, Subversion 
 serait encore plus désavantagé. Parce que la plupart des commandes Subversion
 doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme
 de réplication, la capacité du serveur et la bande passante sont devenu des
-goulots d'étranglement pour les projets de taille moyenne ou grande.
+goulots d'étranglement pour les projets de tailles moyennes ou grandes.
 
-En outre, Subversion implique une surchage substantielle dans le stockage local
+En outre, Subversion implique une surcharge substantielle dans le stockage local
 de certaines données, pour éviter des transactions avec le serveur, pour 
 certaines opérations communes, tel que la recherche des fichier modifiées
 (\texttt{status}) et l'affichage des modifications par rapport la révision 
 courante (\texttt{diff}). En conséquence, un répertoire de travail Subversion
-a souvent la même taille, ou est plus grand, que un dépôt Mercurial et son
+a souvent la même taille, ou est plus grand, qu'un dépôt Mercurial et son
 espace de travail, bien que le dépôt Mercurial contienne l'intégralité de
 l'historique.
 
-Subversion est largement supportés par les outils tierses. Mercurial est
+Subversion est largement supporté par les outils tierces. Mercurial est
 actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins,
-et en effet certains des outils graphiques sont maintenant supérieur à leurs
+et en effet certains des outils graphiques sont maintenant supérieurs à leurs
 équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent
 manuel utilisateur.
 
-Parce que Subversion ne stocke par l'historique chez ses clients, il est 
-parfaitement adapté à la gestion de projet qui doivent suivre un ensemble
-de large fichier binaires et opaques. Si vous suivez une cinquantaine de
+Parce que Subversion ne stocke pas l'historique chez ses clients, il est 
+parfaitement adapté à la gestion de projets qui doivent suivre un ensemble
+de larges fichiers binaires et opaques. Si vous suivez une cinquantaine de
 versions d'un fichier incompressible de 10MB, l'occupation disque coté client
 d'un projet sous Subversion restera à peu près constante. A l'inverse, 
 l'occupation disque du même projet sous n'importe lequel des gestionnaire
 de source distribués grandira rapidement, proportionnellement aux nombres
-de versions, car les différences entre chaque révision sera très grande.
+de versions, car les différences entre chaque révisions sera très grande.
 
-En outre, c'est souvent difficle ou, généralement, impossible de fusionner
+En outre, c'est souvent difficile ou, généralement, impossible de fusionner
 des différences dans un fichier binaire. La capacité de Subversion de 
-vérouiller des fichiers, pour permettre à l'utilisateur d'être le seul
-à le mettre à jour (``commit'') temporairement, est avantage significatif
-dans un projet doté de beaucoup de fichiers binaire.
+verrouiller des fichiers, pour permettre à l'utilisateur d'être le seul
+à le mettre à jour (``commit'') temporairement, est un avantage significatif
+dans un projet doté de beaucoup de fichiers binaires.
 
 Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut
 aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion.
-Ceci rend très facile de ``tester l'eau'' et d'utiliser Mercurial et Subversion
+Ceci rend très facile de ``prendre la température'' et d'utiliser Mercurial et Subversion
 en parallèle, avant de décider de migrer vers Mercurial. La conversion de 
-l'historique est incrémental, donc vous pouvez effectuer une conversion 
-initial, puis de petites additions par la suite pour ajouter les nouvelles
+l'historique est incrémentale, donc vous pouvez effectuer une conversion 
+initiale, puis de petites additions par la suite pour ajouter les nouvelles
 modifications.
 
 \subsection{Git}
 
 Git est un outil de gestion de source distribué qui fût développé pour gérer
-le code source de noyau de Linux. Comme Mercurial, sa conception initial à 
-était inspiré par Monotone.
+le code source de noyau de Linux. Comme Mercurial, sa conception initiale à 
+était inspirée par Monotone.
 
-Git dispose d'un ensemble conséquent de command, avec plus de~139 commandes
-individuels pour la version~1.5.0. Il a aussi la réputation d'être difficile
+Git dispose d'un ensemble conséquent de commandes, avec plus de~139 commandes
+individuelles pour la version~1.5.0. Il a aussi la réputation d'être difficile
 à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa 
 simplicité.
 
 cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que 
 Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur
 Windows, les performances et le niveau de support général fourni par Git, 
-au moment de l'écriture de cet ouvrage, bien derrière celui de Mercurial.
+au moment de l'écriture de cet ouvrage, est bien derrière celui de Mercurial.
 
 Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git
 exige d'exécuter manuellement et régulièrement la commande ``repacks'' sur
 ces métadonnées. Sans ceci, les performances de git se dégrade, et la 
 consommation de l'espace disque augmente rapidement. Un serveur qui contient
-plusieurs dépôt Git qui ne sont pas régulièrement et fréquement ``repacked''
+plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment ``repacked''
 deviendra un vrai problème lors des ``backups'' du disque, et il y eu des
 cas, où un ``backup'' journalier pouvait durer plus de~24 heures. Un dépôt
-fraichement ``repacked'' sera légèrement plus petit que un dépôt Mercurial,
+fraichement ``repacked'' sera légèrement plus petit qu'un dépôt Mercurial,
 mais un dépôt non ``repacked'' est beaucoup plus grand.
 
-Le coeur de Git est écrit en C. La plupart des commandes Git sont implémentés
-sous forme de script Shell ou Perl, et la qualité de ces scripts varient
+Le cœur de Git est écrit en C. La plupart des commandes Git sont implémentées
+sous forme de scripts Shell ou Perl, et la qualité de ces scripts varie
 grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient
-chargé en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
-fatal.
+chargés en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
+fatale.
 
 Mercurial peut importer l'historique d'un dépôt Git.
 
 \subsection{CVS}
 
 CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui
-dans le monde. À cause de son manque de properté interne, il n'est plus 
+dans le monde. À cause de son manque de clarté interne, il n'est plus 
 maintenu depuis plusieurs années.
 
-Il a une architecture client/serveur centralisé. Il ne groupe pas les
+Il a une architecture client/serveur centralisée. Il ne regroupe pas les
 modifications de fichiers dans une opération de ``commit'' atomique, ce
 qui permet à ses utilisateurs de ``casser le \textit{build}'' assez
 facilement : une personne peut effectuer une opération de ``commit'' 
 vous savez au moins quels sont ces fichiers).
 
 CVS a une notion étrange des \textit{tags} et des branches que je n'essayerais
-même de décrire ici. Il ne supporte pas bien les opérations de renommage d'un 
-fichier ou de répertoire, ce qui facilite la corruption de son dépôt. Il n'a
+même pas de décrire ici. Il ne supporte pas bien les opérations de renommage d'un 
+fichier ou d'un répertoire, ce qui facilite la corruption de son dépôt. Il n'a
 presque pas pour ainsi dire de contrôle de cohérence interne, il est donc 
 pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je
 ne recommanderais pas CVS pour un projet existant ou nouveau.
 
 Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a 
-quelques princinpes à respecter; ce qui est vrai aussi pour les autres
+quelques principes à respecter; ce qui est vrai aussi pour les autres
 outils d'import de projet CVS. À cause de l'absence de ``commit'' atomique
-et gestion de version de l'arboresence, il n'est pas possible de reconstruire
+et gestion de version de l'arborescence, il n'est pas possible de reconstruire
 de manière précise l'ensemble de l'historique. Un travail de ``devinette''
 est donc nécessaire, et les fichiers renommées ne sont pas détectés. Parce 
-que une bonne part de l'administration d'un dépôt CVS est effectué manuellement, 
-et est donc, sujette à erreur, il est courant que les impots CVS rencontre 
+qu'une bonne part de l'administration d'un dépôt CVS est effectuée manuellement, 
+et est donc, sujette à erreur, il est courant que les imports CVS rencontrent 
 de nombreux problèmes avec les dépôt corrompues (des \textit{timestamps} 
-de révision complètement buggé et des fichiers vérouillés depuis des années 
+de révision complètement buggé et des fichiers verrouillés depuis des années 
 sont deux des problèmes les moins intéressants dont je me souvienne).
 
 Mercurial peut importer l'historique depuis un dépôt CVS.
 
 \subsection{Commercial tools}
 
-Perforce a une architecture client/server centralisée, sans aucun
-mécanisme de cache de données coté client. Contrairement à la plupart
+Perforce a une architecture client/serveur centralisée, sans aucun
+mécanisme de mise en cache de données coté client. Contrairement à la plupart
 des outils modernes de gestion de source, Perforce exige de ses 
 utilisateurs d'exécuter une commande pour informer le serveur
 central de tout fichier qu'il souhaite modifier.
 Les performances de Perforce sont plutôt bonnes pour des petites
 équipes, mais elles s'effondrent rapidement lorsque le nombre 
 d'utilisateurs augmente au delà de la douzaine. Des installations 
-de Perforce assez large nécessite le déployement de proxies pour 
+de Perforce assez larges nécessitent le déploiement de proxies pour 
 supporter la montée en charge associée.
 
-\subsection{Choosing a revision control tool}
+\subsection{Choisir un outil de gestion de source}
 
-A l'exception de CVS, tout les outils listés ci dessus ont des 
+A l'exception de CVS, tous les outils listés ci-dessus ont des 
 forces qui leur sont propres et qui correspondent à certaines
 formes de projet. Il n'y a pas un seul meilleur outil de gestion
 de source qui correspondent le mieux à toutes les situations.
 
-Par exemple, Subversion est un très bon choix lorsque travailler
-avec beaucoup de fichiers binaires, qui évolue régulièrement, grâce
-à sa nature centraliser et sa capacité à vérouiller des fichiers.
+Par exemple, Subversion est un très bon choix lorsqu'on travaille
+avec beaucoup de fichiers binaires, qui évoluent régulièrement, grâce
+à sa nature centralisée et sa capacité à verrouiller des fichiers.
 
 Personnellement, je préfère Mercurial pour sa simplicité, ses 
-performances et son bonne capacité de fusion, et il me sert très bien
+performances et sa bonne capacité de fusion, et il m'a très bien rendu service
 de plusieurs années maintenant.
 
 \section{Migrer depuis un outil à Mercurial}
 
 Mercurial est livré avec une extension nommée \hgext{convert}, qui
-peut de manière incrémental importer des révision depuis différents
-autres outils de gestion de source. Par ``incrémental'', j'entend que
+peut de manière incrémentale importer des révisions depuis différents
+autres outils de gestion de source. Par ``incrémental'', j'entends que
 vous pouvez convertir l'historique entier du projet en une seule fois,
 puis relancer l'outil d'import plus tard pour obtenir les modifications
-effectués depuis votre import intial.
+effectués depuis votre import initial.
 
 Les outils de gestion de source supportés par \hgext{convert} sont :
 \begin{itemize}
 \end{itemize}
 
 En outre, \hgext{convert} peut exporter les modifications depuis Mercurial
-vers Subversion. Ceci rend possible de d'essayer Subversion en parallèle 
+vers Subversion. Ceci rend possible d'essayer Subversion en parallèle 
 avant de choisir une solution définitive, sans aucun risque de perte de
 données.
 
-
 La commande \hgxcmd{conver}{convert} est très simple à utiliser. Simplement,
-indiquer le chemin ou l'URL du dépôt de source, en lui indiquant, optionnellement
-le nom du chemin de destination, et l'extension se met en route. Après cet
+indiquez le chemin ou l'URL du dépôt de source, en lui indiquant éventuellement
+le nom du chemin de destination, et la conversion se met en route. Après cet
 import initial, il suffit de relancer la commande encore une fois pour 
 importer les modifications effectuées depuis.