hgbook
changeset 944:eb01681e0bb8
Relecture orthographique
author | Hugues Frachon <huguesfrachon@gmail.com> |
---|---|
date | Mon Feb 16 18:23:32 2009 +0100 (2009-02-16) |
parents | 3344e9987bf2 |
children | 5016d2b44950 |
files | fr/intro.tex |
line diff
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}