# HG changeset patch # User Hugues Frachon # Date 1234805012 -3600 # Node ID eb01681e0bb8405b887ba4a0df2be6cce6707e9e # Parent 3344e9987bf2c92abfabdd1b9f95f9b7aa7067f2 Relecture orthographique diff -r 3344e9987bf2 -r eb01681e0bb8 fr/intro.tex --- a/fr/intro.tex Mon Feb 16 18:13:41 2009 +0100 +++ b/fr/intro.tex Mon Feb 16 18:23:32 2009 +0100 @@ -6,7 +6,7 @@ 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, +un fichier, vous le sauvegardez sous un nouveau nom contenant un numéro, à chaque fois plus grand que celui de la version précédente. Ce genre de gestion de version manuelle est cependant facilement sujette @@ -16,7 +16,7 @@ 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 +plus modernes n'ont aucune difficulté à gérer plusieurs milliers de personnes travaillant ensemble sur des projets regroupant plusieurs centaines de milliers de fichiers. @@ -33,9 +33,9 @@ \item Quand vous travaillez avec d'autres personnes, les logiciels de 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. +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 à une version +qui se révèle ê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 @@ -48,13 +48,13 @@ personnes. 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 à +du projet d'une personne ou d'une grande équipe, est quels sont ses +\emph{avantages} par rapport à ses \emph{coûts}. Un outil qui est difficile à utiliser ou à comprendre exigera un lourd effort d'adaptation. 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 +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 personne peut sembler un contexte @@ -64,11 +64,11 @@ Mercurial supporte ces \emph{deux} échelles de travail. Vous pouvez apprendre 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 obscurs ou de séquence de commandes +signifie que vous n'avez pas de concept 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. +vraiment en train de faire}. En même temps, ces mêmes performances et sa +nature ``peer-to-peer'' vous permettent d'augmenter, sans difficulté, son +utilisation à de très grands projets. Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un bon outil peut rendre beaucoup plus fluide votre travail. @@ -77,15 +77,15 @@ 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 +meilleure 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 +``googelable''). En outre, j'ai opté pour 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 +aussi pour faciliter la lecture d'autres documents en anglais, ainsi que l'utilisation de Mercurial}. : @@ -97,18 +97,17 @@ \item \textit{Version control (VCS)}. \end{itemize} -Certains personnes prétendent que ces termes ont en fait des sens +Certaines personnes prétendent que ces termes ont en fait des sens différents mais en pratique ils se recouvrent tellement qu'il n'y a pas réellement de manière pertinente de les distinguer. \section{Une courte histoire de la gestion de source} 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 +(Source Code Control System)}, que Marc Rochkind conçu dans les laboratoires de recherche de Bell (\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 +\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; @@ -117,9 +116,9 @@ 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 +\textit{SCCS}, \textit{RCS} demandait 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. +fichiers pour se prémunir de tout conflit issu 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 @@ -133,14 +132,14 @@ 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 +Brian Berliner reprit les scripts de Grune's et les réécrit 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. +il 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 @@ -157,21 +156,21 @@ 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 +En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé 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 +meilleure 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. -Plus ou moins de simultanément, Graydon Hoare a commencé sur l'ambitieux +Plus ou moins 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 +défauts 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. +utilise des ``hash'' cryptographiques comme identifiants, et il a une notion +complète de ``confiance'' du code issu des 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é à @@ -179,23 +178,23 @@ \section{Tendances de la gestion de source} -Il y a eu une tendance évidente dans le développement et l'utilisation d'outil +Il y a eu une tendance évidente dans le développement et l'utilisation d'outils 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. +que les utilisateurs se sont habitués à leur outils et se sont sentis contraints +par leurs 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é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 +verrouillage et leur utilisation limitée à un seul ordinateur rendaient 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 +réseau et centralisée, permettant de gérer plusieurs projets entiers en même +temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveaux 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 +peu fiable pouvait complètement empêcher les utilisateurs distants 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 @@ -205,18 +204,18 @@ 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 +source à qui en a besoin. La collaboration à travers Internet a transformé la +contrainte technologique en une simple question de choix et de consencus. Les +outils modernes 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é} +\section{Quelques avantages des gestionnaires de source distribués} 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 +assez robustes et aussi utilisables que leurs 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 +de source distribués se distinguent particulièrement de leurs équivalents centralisés de nombreuses manières. Pour un développeur individuel, ils restent beaucoup plus rapides que les @@ -226,7 +225,7 @@ 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 -passer beaucoup de temps à interagir avec un logiciel de gestion de sources. +passer beaucoup de temps à interagir avec un logiciel de gestion de source. 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 @@ -241,8 +240,8 @@ 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 équipe de collaborateurs très dispersés ceci peut +distants, opération somme toute assez rare en comparaison aux opérations +locales. Si vous avez une équipe de collaborateurs très dispersée ceci peut être significatif. \subsection{Avantages pour les projets \textit{Open Source}} @@ -267,9 +266,9 @@ posent un risque pour les projets \textit{Open Source} car ils facilitent grandement la création de ``fork''\footnote{NdT:Création d'une -\url{version alternative du logiciel}{http://fr.wikipedia.org/wiki/Fork\#Embranchement\_d.27un\_projet\_informatique}.} +\url{version alternative du logiciel}{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}.} 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 +au sein d'un groupe de développeurs qui aboutissent à la décision de ne plus travailler ensemble. Chaque parti s'empare d'une copie plus ou moins complète du code source du projet et continue dans sa propre direction. @@ -279,13 +278,13 @@ décider quelle modification est ``la gagnante'', et replacer, par un 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. +d'un des partis, 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 +la \emph{meilleure} façon de développer un projet. Chaque modification 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 +vraiment très efficaces 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. @@ -297,16 +296,15 @@ les chances de ``fork'': \begin{itemize} \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). + 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. + tout ce qu'elle implique est une simple fusion. \end{itemize} Certaines personnes font de la résistance envers les gestionnaires de source -distribués parce qu'ils veulent garder un contrôle ferme de leur projet, et +distribués parce qu'ils veulent garder un contrôle ferme sur leur projet, et ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins, -si c'est votre cas, sachez que si vous publier votre dépôt CVS ou Subversion +si c'est votre cas, sachez que si vous publiez votre dépôt CVS ou Subversion de manière publique, il existe une quantité d'outils disponibles pour récupérer entièrement votre projet et son historique (quoique lentement) et le récréer ailleurs, sans votre contrôle. En fait, votre contrôle sur votre projet est @@ -327,12 +325,12 @@ 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 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 +solutions propriétaires de gestion de source tentent de palier ce problème +avec des réplications de sites distants qui sont à la fois coûteuses à mettre 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, 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 +n'y ait 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 @@ -347,10 +345,10 @@ é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 un soucis sur +Si vous avez des employés sur le terrain, en train de chercher à résoudre un souci 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, +distribué. Cet outil leur permettra de générer des versions personnalisées, +d'essayer différentes solutions, en les isolant aisément les unes des autres, 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. @@ -361,17 +359,17 @@ pertinent pour la gestion de source: \begin{itemize} \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 ; + \item Il est léger et performant ; + \item Il monte facilement en charge ; + \item Il est facile à personnaliser ; \end{itemize} Si vous êtes déjà familier d'un outil de gestion de source, vous serez capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup plus long\footnote{NdT: Pour appuyer le propos de l'auteur, je signale que j'utilise Mercurial comme outil d'initiation à la gestion de contrôle dans -des travaux pratique à l'ESME Sudria (\url{http://www.esme.fr}) et que les -élèves le prennent en main sans difficulté majeur malgré l'approche distribuée.}. +des travaux pratiques à l'ESME Sudria (\url{http://www.esme.fr}) et que les +élèves le prennent en main sans difficulté majeure malgré l'approche distribuée.}. Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions. @@ -379,10 +377,10 @@ Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en quelques instants. Ajouter des modifications ou des branches, transférer ces modifications (localement ou via le réseau), et les opérations -d'historique ou de statut sont aussi très rapide. Mercurial reste hors de +d'historique ou de statut sont aussi très rapides. Mercurial reste hors de votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution. -L'utilité de Mercurial ne se limite pas à des petits projets: il est +L'utilité de Mercurial ne se limite pas à de petits projets: il est aussi utilisé par des projets ayant des centaines ou même des milliers de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des centaines de méga de code source. @@ -392,8 +390,8 @@ %TODO % For both spanish and english version, add the following examples: \begin{itemize} - \item \url{Firefox}{https://developer.mozilla.org/en/Mozilla\_Source\_Code\_(Mercurial)} ; - \item \url{OpenSolaris}{http://opensolaris.org/os/community/tools/scm/hg\_help/} ; + \item \url{Firefox}{https://developer.mozilla.org/en/Mozilla_Source_Code_(Mercurial)} ; + \item \url{OpenSolaris}{http://opensolaris.org/os/community/tools/scm/hg_help/} ; \item \url{OpenJDK}{http://hg.openjdk.java.net/} (utilisant en outre l'extension ``forest'' pour gérer ses sous modules); \end{itemize} @@ -401,7 +399,7 @@ Si les fonctionnalités cœur de Mercurial ne sont pas suffisantes pour vous, il est très aisé d'en construire d'autres. 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 +rend encore plus facile l'ajout de fonctionnalités 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. @@ -410,26 +408,26 @@ 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 objective. Néanmoins, j'ai utilisé les outils de gestion de source -listé ci dessous, dans la plupart des cas, pendant plusieurs années. +listés ci dessous, dans la plupart des cas, pendant plusieurs années. %% TODO: Fussy translation. \subsection{Subversion} -Subversion est un outil de gestion de source les plus populaire, il fût +Subversion est un des outils de gestion de source les plus populaire, il fût développé pour remplacer CVS. Il a une architecture client/server centralisée. Subversion et Mercurial ont des noms de commandes très similaires pour les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile -d'apprendre l'autre. Ces deux outils sont portable sur les systèmes -d'exploitation les plus populaires\footnote{NdT:Mercurial fonctionne sans problèmes +d'apprendre l'autre. Ces deux outils sont portables sur les systèmes +d'exploitation les plus populaires\footnote{NdT:Mercurial fonctionne sans problème sur OpenVMS à l'ESME Sudria \url{http://www.esme.fr}, compte tenu que Subversion a été 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'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 +de l'écriture de ce livre, ses capacités de fusion étaient nouvelles, et réputées pour être \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complexes -et buggués}. +et bugguées}. 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é @@ -439,13 +437,13 @@ 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 tailles moyennes ou grandes. +de réplication, la capacité du serveur et la bande passante sont devenues des +goulots d'étranglement pour les projets de taille moyenne ou grande. 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 +certaines opérations communes, telles que la recherche des fichiers modifiés +(\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, qu'un dépôt Mercurial et son espace de travail, et ceci bien que le dépôt Mercurial contienne l'intégralité @@ -462,9 +460,9 @@ 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 +l'occupation disque du même projet sous n'importe lequel des gestionnaires de source distribués grandira rapidement, proportionnellement aux nombres -de versions, car les différences entre chaque révisions sera très grande. +de versions, car les différences entre chaque révisions seront très grandes. 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 @@ -483,8 +481,8 @@ \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 initiale à -était inspirée par Monotone. +le code source de noyau de Linux. Comme Mercurial, sa conception initiale a +été inspirée par Monotone. 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 @@ -499,7 +497,7 @@ 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 +ces métadonnées. Sans ceci, les performances de git se dégradent et la consommation de l'espace disque augmente rapidement. Un serveur qui contient 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 @@ -511,7 +509,7 @@ 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és en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer -fatale. +fatal. Mercurial peut importer l'historique d'un dépôt Git. @@ -525,7 +523,7 @@ 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'' -sans problème puis être bloqué par besoin de fusion, avec comme conséquence +sans problème puis être bloquée par besoin de fusion, avec comme conséquence néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses modifications. Ce problème affecte aussi la manière de travailler avec l'historique du projet. Si vous voulez voir toutes les modifications d'une @@ -533,23 +531,23 @@ \textit{timestamps} des modifications de chacun des fichiers impliqués (si vous savez au moins quels sont ces fichiers). -CVS a une notion étrange des \textit{tags} et des branches que je n'essayerais +CVS a une notion étrange des \textit{tags} et des branches que je n'essayerai 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. +ne recommanderai pas CVS pour un projet existant ou nouveau. Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a 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'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 +est donc nécessaire, et les fichiers renommés ne sont pas détectés. Parce 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 verrouillés depuis des années +de nombreux problèmes avec les dépôt corrompus (des \textit{timestamps} +de révision complètement buggés 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. @@ -560,7 +558,7 @@ 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. +central de tout fichier qu'ils souhaitent modifier. Les performances de Perforce sont plutôt bonnes pour des petites équipes, mais elles s'effondrent rapidement lorsque le nombre @@ -573,7 +571,7 @@ 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. +de source qui correspondrait le mieux à toutes les situations. Par exemple, Subversion est un très bon choix lorsqu'on travaille avec beaucoup de fichiers binaires, qui évoluent régulièrement, grâce @@ -581,7 +579,7 @@ Personnellement, je préfère Mercurial pour sa simplicité, ses performances et sa bonne capacité de fusion, et il m'a très bien rendu service -depuis plusieurs années maintenant. +de plusieurs années maintenant. \section{Migrer depuis un outil à Mercurial} @@ -590,7 +588,7 @@ 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 initial. +effectuées depuis votre import initial. Les outils de gestion de source supportés par \hgext{convert} sont : \begin{itemize}