# HG changeset patch
# User Wilk
# Date 1252843680 -7200
# Node ID 0298bccbb8ee390072bd75aff32cf89cdda46547
# Parent c2e0f02634070fc226e9b1a777518323f0cae44c
french small corrections, gestion de révisions au lieu de gestion de sources ou gestion de versions.
diff -r c2e0f0263407 -r 0298bccbb8ee fr/ch01-intro.xml
--- a/fr/ch01-intro.xml Sun Sep 13 14:07:14 2009 +0200
+++ b/fr/ch01-intro.xml Sun Sep 13 14:08:00 2009 +0200
@@ -5,17 +5,18 @@
Comment en est on arrivé là ?
-À propos de la gestion source
-
- La gestion de sources est un processus permettant de gérer différentes
+À propos de la gestion de révisions. Pourquoi Mercurial ?
+
+ La gestion de révisions 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 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
+ Ce genre de gestion de révisions manuelle, ne serait-ce que
+ d'un seul fichier, est cependant facilement sujette
aux erreurs, ainsi, depuis longtemps, des logiciels existent pour
-résoudre cette problématique. Les premiers outils de gestion de sources
+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
s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
@@ -24,23 +25,23 @@
personnes travaillant ensemble sur des projets regroupant plusieurs
centaines de milliers de fichiers.
- L'arrivée de la gestion de révision distribuée est
+ L'arrivée de la gestion de révisions distribuée est
relativement récente, et, pour le moment, ce nouveau domaine a grandi
grâce à la volonté des gens d'explorer ces territoires encore inconnus.
- J'écris un livre sur la gestion de révision distribuée
+ J'écris un livre sur la gestion de révisions distribuée
parce que je pense qu'il s'agit d'un sujet important qui mérite un guide
- du terrain. J'ai choisi d'écrire un livre sur Mercurial car il est
+ de terrain. J'ai choisi d'écrire un livre sur Mercurial car il est
l'outil le plus facile pour découvrir ce nouveau domaine, tout en étant
un outil efficace qui répond aux demandes d'environnements réels et
- difficiles, là où d'autres outils de gestions de versions s'effondrent.
+ difficiles, là où d'autres outils de gestion de révisions s'effondrent.
- Pourquoi utiliser un gestionnaire de source ?
+ Pourquoi utiliser un gestionnaire de révisions ?
Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez
-utiliser un outil automatisant la gestion de version pour votre projet.
+utiliser un outil automatisant la gestion de révisions pour votre projet.
L'outil se chargera de suivre l'évolution de votre projet, sans
@@ -50,14 +51,14 @@
ce qu'il a modifié.
Quand vous travaillez avec d'autres personnes, les logiciels de
-gestion de source facilitent le travail collaboratif. Par exemple, quand
+gestion de révisions 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.
L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
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 vraiment efficace vous permettra d'identifier à quel
+gestion de révisions vraiment efficace vous permettra d'identifier à quel
moment le problème est apparu (voir la section pour plus
de détails).
@@ -65,27 +66,27 @@
de votre projet et de gérer l'écart entre chacune.
La plupart de ces raisons ont autant d'importances &emdash;du
- moins en théorie&emdash; que vous travailliez sur un projet pour vous, ou
+ moins en théorie&emdash; que vous travailliez seul sur un projet, ou
avec une centaine d'autres 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
- quels sont ses avantages par rapport à ses
- coûts. Un outil qui est difficile à utiliser ou à
+ 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 à
comprendre exigera un lourd effort d'adaptation.
-)Un projet de cinq milles personnes s'effondrera très
+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 sans, l'échec est presque
+ 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
garanti.
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
+ révisions, car, bien évidement le coût d'utilisation dépasse le coût total du
projet. N'est ce pas ?
@@ -93,7 +94,7 @@
é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 concept obscurs ou de séquence de
+ 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
@@ -101,7 +102,7 @@
difficulté, son utilisation à de très grands projets.
- Aucun outil de gestion de source ne peut sauver un
+ Aucun outil de gestion de révisions ne peut sauver un
projet mal mené, mais un bon outil peut rendre beaucoup plus fluide
votre travail.
@@ -113,7 +114,7 @@
La gestion de source
@@ -148,13 +149,13 @@
-A propos des exemples dans ce livre
-
- Ce livre prend une approche non usuel pour les exemples
+À 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
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
- est construite à partir des sources, tous les scripts d'exemple sont
+ 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.
@@ -185,7 +186,7 @@
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 consistent et reproductible
+ comportement que vous voyez est constant et reproductible
@@ -193,7 +194,7 @@
- Tendances de la gestion de source
+ Tendances de la gestion de révisions
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
@@ -213,7 +214,7 @@
adoptant une architecture 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
+ clients discutant régulièrement avec le serveur, la montée en charge
devint un réel problème sur les gros projets. Une connexion réseau peu
fiable pouvait complètement empêcher les utilisateurs distants de
dialoguer avec le serveur. Alors que les projets
- La génération actuelle des outils de gestion de source
+ La génération actuelle des outils de gestion de révisions
est peer-to-peer
par nature. Tous 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
+ abandonné la dépendance à un serveur central, et ont permis à leurs
+ utilisateurs de distribuer les données de leur gestion de révisions à qui
en a besoin. La collaboration à travers Internet a transformé la
contrainte technologique en une simple question de choix et de
consensus. Les outils modernes peuvent maintenant fonctionner en mode
@@ -238,12 +239,12 @@
- Quelques avantages des gestionnaires de source distribués
+ Quelques avantages des gestionnaires de révisions distribués
- Même si les gestionnaire de source distribués sont depuis
+ Même si les gestionnaire de révisions distribués sont depuis
plusieurs années 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 source distribués se distinguent
+ sensibilisés. Les gestionnaires de révisions distribués se distinguent
particulièrement de leurs équivalents centralisés de nombreuses
manières.
@@ -256,7 +257,7 @@
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 source.
+ beaucoup de temps à interagir avec un logiciel de gestion de révisions.
Les outils distribués sont complètement indépendants des
@@ -264,7 +265,7 @@
à 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
+ Avec un outil distribué, vous avez autant de backups
que
de contributeurs.
@@ -275,7 +276,7 @@
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
- en comparaison aux opérations locales. Si vous avez une équipe de
+ en comparaison des opérations locales. Si vous avez une équipe de
collaborateurs très dispersée ceci peut être significatif.
@@ -285,7 +286,7 @@
Si vous prenez goût à un projet 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
+ révisions distribué, vous êtes immédiatement un "pair" avec les
personnes formant le cœur
du projet. S'ils publient
leurs dépôts, vous pouvez immédiatement copier leurs historiques de
projet, faire des modifications, enregistrer votre travail en
@@ -303,7 +304,7 @@
Le non-problème du "fork"
Il a été souvent suggéré que les gestionnaires de
- source distribués posent un risque pour les projets Open Source car ils facilitent grandement la
création de fork
.