# HG changeset patch # User André Sintzoff # Date 1259068383 -3600 # Node ID 4650cddc0c27dcc7eea02ab7ce0f3b764d0f5c2f # Parent 44946b10a4b321fa7419637a1af20918f81389f7 some typo and better french translation diff -r 44946b10a4b3 -r 4650cddc0c27 fr/ch01-intro.xml --- a/fr/ch01-intro.xml Tue Nov 24 11:44:49 2009 +0100 +++ b/fr/ch01-intro.xml Tue Nov 24 14:13:03 2009 +0100 @@ -2,7 +2,7 @@ - Comment en est on arrivé là ? + Comment en est-on arrivé là ? À propos de la gestion de révisions. Pourquoi Mercurial ? @@ -18,7 +18,7 @@ aux erreurs, ainsi, depuis longtemps, des logiciels existent pour résoudre cette problématique. Les premiers outils de gestion de révisions étaient destinés à aider un seul utilisateur, à automatiser la gestion -des versions d'un seul fichier. Dans les dernières décades, cette cible +des versions d'un seul fichier. Durant les dernières décennies, 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é à gérer plusieurs milliers de @@ -73,21 +73,21 @@ Une question fondamentale à propos des outils de gestion de révisions, qu'il s'agisse du projet d'une personne ou d'une grande équipe, est quels sont ses gains par rapport à ses - coût. Un outil qui est difficile à utiliser ou à + 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 +Un projet de cinq mille personnes s'effondrera très certainement de lui même sans aucun processus et outil de gestion de révisions. Dans ce cas, le coût d'utilisation d'un logiciel de gestion de - révisions est dérisoire puisque sans, l'échec est presque + révisions est dérisoire puisque sans celui-ci, l'échec est presque garanti. D'un autre coté, un rapide hack d'une personne peut sembler un contexte bien pauvre pour utiliser un outil de gestion de révisions, car, bien évidement le coût d'utilisation dépasse le coût total du - projet. N'est ce pas ? + projet. N'est-ce pas ? Mercurial supporte ces deux @@ -96,8 +96,8 @@ avec facilité sur le plus petit des projets. Cette simplicité signifie que vous n'avez pas de concept obscur ou de séquence de commandes défiant l'imagination, sans aucune corrélation avec - ce que vous êtes entrain de faire. En même - temps, ces mêmes performances et sa nature + ce que vous êtes réellement en train de faire. En même + temps, ses mêmes performances et sa nature peer-to-peer vous permettent d'adapter, sans difficulté, son utilisation à de très grands projets. @@ -152,17 +152,17 @@ À propos des exemples dans ce livre Ce livre prend une approche non usuelle pour les exemples - de code. Tous les exemples sont en live &emdash; Chacun + de code. Tous les exemples sont en live &emdash; chacun est actuellement le résultat d'un script shell qui exécute les - commandes Mercurial que vous voyez. A chaque fois qu'une image du livre + commandes Mercurial que vous voyez. Chaque fois qu'une image du livre est construite à partir des sources, tous les scripts d'exemples sont lancés automatiquement, et leurs résultats effectifs sont comparés aux résultats attendus. - L'avantage de dette approche est que les exemples sont + L'avantage de cette approche est que les exemples sont toujours précis ; ils décrivent exactement la - conduite de la version de Mercurial qui est mentionnée en entête du - livre. Si je met à jour la version de Mercurial que je suis en train de + comportement de la version de Mercurial qui est mentionnée en entête du + livre. Si je mets à jour la version de Mercurial que je suis en train de documenter, et que la sortie de certaines commandes change, la construction du livre échoue. @@ -171,12 +171,12 @@ heures que vous verrez dans les exemples tendent à être écrasés ensemble, dans le sens où elles ne sont pas celles qu'elles auraient été si un humain avait tapé les commandes. En - effet, humain ne peut pas taper plus d'une commande toutes les quelques + effet, un humain ne peut pas taper plus d'une commande toutes les quelques secondes, avec le temps qui s'écoule, mes scripts d'exemples exécutent plusieurs commandes en une seconde. - Une circonstance de ceci est que plusieurs commits + Comme exemple de ceci, plusieurs commits consécutifs dans un exemple peuvent apparaître comme ayant eu lieu durant la même seconde. Vous pouvez observer le phénomène dans l'exemple Donc, lorsque vous lisez ces exemples, ne prêtez pas trop d'importance aux dates et heures que vous voyez dans la sortie des commandes. Cependant, soyez confiants que le - comportement que vous voyez est constant et reproductible + comportement que vous voyez est cohérent et reproductible. @@ -198,7 +198,7 @@ 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 à + décennies, au fur et à mesure que les utilisateurs se sont habitués à leur outils et se sont sentis contraints par leurs limitations. @@ -398,9 +398,9 @@ Les systèmes de gestion de révisions supportent - généralement assez mal la monté en charge. Il n'est pas rare pour un + généralement assez mal la montée en charge. Il n'est pas rare pour un gestionnaire de révisions centralisé pourtant onéreux de s'effondrer - sous la charge combinée d'une douzaine d'utilisateurs concurrents + sous la charge combinée de quelques dizaines 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és par un mécanisme de réplication. Dans le cas @@ -408,7 +408,7 @@ &emdash; si vous en avez un&emdash; est largement inférieure (car toutes les données sont déjà répliquées ailleurs), un simple serveur, peu onéreux, peut gérer les besoins d'une plus grande équipe, et la - réplication pour balancer la charge devient le travail d'un simple + réplication pour répartir la charge devient le travail d'un simple script. @@ -419,7 +419,7 @@ 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. + moindre connexion au réseau de votre société. @@ -442,7 +442,7 @@ ça ne sera pas beaucoup plus long. Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont généralement uniformes et cohérentes, et vous pouvez ainsi garder en tête simplement quelques - règles générales, plutôt qu'un lot complexe d'exceptions. + règles générales, plutôt que de nombreuses exceptions. Sur un petit projet, vous pouvez commencer à travailler @@ -454,7 +454,7 @@ L'utilité de Mercurial ne se limite pas à de petits - projets: il est aussi utilisé par des projets ayant des centaines ou + 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 octets de code source. @@ -483,14 +483,14 @@ Subversion Subversion est un des outils de gestion de révisions les - plus populaire, il fût développé pour remplacer CVS. Il a une - architecture client/server centralisée. + plus populaire, développé pour remplacer CVS. Il a une + architecture client/serveur 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 - portables sur les systèmes d'exploitation les plus populaires. + portables sur tous les systèmes d'exploitation populaires. Avant la version 1.5, Subversion n'offrait aucune forme @@ -527,7 +527,7 @@ Subversion est largement supporté par les outils - tierces. Mercurial est actuellement encore en retrait de ce point de + tiers. Mercurial est actuellement encore en retrait de ce point de vue. L'écart se réduit néanmoins, en effet, certains des outils graphiques sont maintenant supérieurs à leurs équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent manuel @@ -539,10 +539,10 @@ 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 + restera à peu près constante. À l'inverse, l'occupation disque du même projet sous n'importe lequel des gestionnaires de révisions distribués grandira rapidement, proportionnellement aux nombres de - versions, car les différences entre chaque révisions seront très + versions, car les différences entre chaque révision seront très grandes. @@ -569,7 +569,7 @@ Git - Git est un outil de gestion de révisions distribué qui fût + Git est un outil de gestion de révisions distribué qui a été développé pour gérer le code source de noyau de Linux. Comme Mercurial, sa conception initiale a été inspirée par Monotone. @@ -646,7 +646,7 @@ Mercurial peut importer l'historique d'un projet CVS. - Néanmoins, il y a quelques principes à respecter; ce qui est vrai + 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 versions de l'arborescence, il n'est pas possible de reconstruire de manière @@ -670,7 +670,7 @@ Outils propriétaires Perforce a une architecture client/serveur centralisée, - sans aucun mécanisme de mise en cache de données coté client. + sans aucun mécanisme de mise en cache de données côté client. Contrairement à la plupart des outils modernes de gestion de révisions, Perforce exige de ses utilisateurs d'exécuter une commande pour informer le serveur central de tout fichier qu'ils souhaitent @@ -679,7 +679,7 @@ 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 + nombre d'utilisateurs augmente au delà de quelques dizaines. Des installations de Perforce assez larges nécessitent le déploiement de proxies pour supporter la montée en charge associée. @@ -688,7 +688,7 @@ Choisir un outil de gestion de révisions - A l'exception de CVS, tous les outils listés ci-dessus + À l'exception de CVS, tous les outils listés ci-dessus ont des forces qui leurs sont propres et qui correspondent à certaines formes de projet. Il n'y a pas un seul meilleur outil de gestion de révisions qui correspondrait le mieux à toutes les situations. @@ -708,7 +708,7 @@ - Migrer depuis un outil à Mercurial + Migrer depuis un outil vers Mercurial Mercurial est livré avec une extension nommée convert, qui peut, de manière incrémentale @@ -789,7 +789,7 @@ central. - Brian Berliner reprit les scripts de Grune's et les réécrit en C, + 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. @@ -801,37 +801,37 @@ utilisé au monde. - Au début des années 1990, Sun Microsystems développa un premier + Au début des années 1990, Sun Microsystems développa un premier outil de gestion de révisions 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 avançaient, les utilisateurs ont pris + 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 + cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichiers, 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 + maintenir, ce qui augmente 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 + 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 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 + client/serveur 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 simultanément, Graydon Hoare a commencé sur + Plus ou moins simultanément, Graydon Hoare a commencé sur l'ambitieux système de gestion distribuée Monotone. Bien que Monotone corrige plusieurs défauts de CVS tout en offrant une architecture peer-to-peer, il va aussi plus loin que la plupart des @@ -841,7 +841,7 @@ différentes sources. - Mercurial est né en 2005. Bien que très influencé par Monotone, + 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 sur de très gros projets.