1.1 --- a/fr/intro.tex	Sun Feb 08 15:38:18 2009 +0100
     1.2 +++ b/fr/intro.tex	Sun Feb 08 17:01:30 2009 +0100
     1.3 @@ -76,9 +76,11 @@
     1.4  
     1.5  \subsection{Les multiples noms de la gestion de source}
     1.6  
     1.7 -La gestion de source est un domaine divers, tellement qu'il n'existe pas
     1.8 +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
     1.9  une seul nom ou acronyme pour le désigner. Voilà quelqu'uns des noms ou 
    1.10 -acronymes que vous rencontrerez le plus souvent:
    1.11 +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}.
    1.12 +
    1.13 +:
    1.14  \begin{itemize}
    1.15  \item \textit{Revision control (RCS)} ;
    1.16  \item Software configuration management (SCM), ou \textit{configuration management} ;
    1.17 @@ -87,13 +89,6 @@
    1.18  \item \textit{Version control (VCS)}.
    1.19  \end{itemize}
    1.20  
    1.21 -\notebox {
    1.22 -Note du traducteur : J'ai conservé la liste des noms en anglais pour des raisons de commodité (ils sont plus ``googelable''). J'ai choisi de conserver le terme ``gestion de sources'' comme traduction unique dans l'ensemble du document.
    1.23 -
    1.24 -En outre, j'ai opté pour conserver l'ensemble des opérations de Mercurial (commit, push, pull,...) en anglais, là aussi pour faciliter la lecture d'autres documents en anglais, et 
    1.25 -aussi son utilisation.
    1.26 -}
    1.27 -
    1.28  Certains personnes prétendent que ces termes ont en fait des sens
    1.29  différents mais en pratique ils se recouvrent tellement qu'il n'y a pas
    1.30  réellement de manière pertinente de les distinguer.
    1.31 @@ -330,148 +325,154 @@
    1.32  en existe déjà un certains nombres de très populaires et très utiles, 
    1.33  dont le périmètre va de la recherche de bugs à l'amélioration des performances.
    1.34  
    1.35 -\section{Mercurial compared with other tools}
    1.36 -
    1.37 -Before you read on, please understand that this section necessarily
    1.38 -reflects my own experiences, interests, and (dare I say it) biases.  I
    1.39 -have used every one of the revision control tools listed below, in
    1.40 -most cases for several years at a time.
    1.41 -
    1.42 +\section{Mercurial comparé aux autres outils}
    1.43 +
    1.44 +Avant que vous n'alliez plus loin, comprenez bien que cette section
    1.45 +reflète mes propres expériences, et elle est donc (j'ose le dire)
    1.46 +peu objectives. Néanmoins, j'ai utilisé les outils de gestion de source
    1.47 +listé ci dessous, dans la plupart des cas, pendant plusieurs années.
    1.48 +%% TODO: Fussy translation.
    1.49  
    1.50  \subsection{Subversion}
    1.51  
    1.52 -Subversion is a popular revision control tool, developed to replace
    1.53 -CVS.  It has a centralised client/server architecture.
    1.54 -
    1.55 -Subversion and Mercurial have similarly named commands for performing
    1.56 -the same operations, so if you're familiar with one, it is easy to
    1.57 -learn to use the other.  Both tools are portable to all popular
    1.58 -operating systems.
    1.59 -
    1.60 -Prior to version 1.5, Subversion had no useful support for merges.
    1.61 -At the time of writing, its merge tracking capability is new, and known to be
    1.62 -\href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complicated
    1.63 -  and buggy}.
    1.64 -
    1.65 -Mercurial has a substantial performance advantage over Subversion on
    1.66 -every revision control operation I have benchmarked.  I have measured
    1.67 -its advantage as ranging from a factor of two to a factor of six when
    1.68 -compared with Subversion~1.4.3's \emph{ra\_local} file store, which is
    1.69 -the fastest access method available.  In more realistic deployments
    1.70 -involving a network-based store, Subversion will be at a substantially
    1.71 -larger disadvantage.  Because many Subversion commands must talk to
    1.72 -the server and Subversion does not have useful replication facilities,
    1.73 -server capacity and network bandwidth become bottlenecks for modestly
    1.74 -large projects.
    1.75 -
    1.76 -Additionally, Subversion incurs substantial storage overhead to avoid
    1.77 -network transactions for a few common operations, such as finding
    1.78 -modified files (\texttt{status}) and displaying modifications against
    1.79 -the current revision (\texttt{diff}).  As a result, a Subversion
    1.80 -working copy is often the same size as, or larger than, a Mercurial
    1.81 -repository and working directory, even though the Mercurial repository
    1.82 -contains a complete history of the project.
    1.83 -
    1.84 -Subversion is widely supported by third party tools.  Mercurial
    1.85 -currently lags considerably in this area.  This gap is closing,
    1.86 -however, and indeed some of Mercurial's GUI tools now outshine their
    1.87 -Subversion equivalents.  Like Mercurial, Subversion has an excellent
    1.88 -user manual.
    1.89 -
    1.90 -Because Subversion doesn't store revision history on the client, it is
    1.91 -well suited to managing projects that deal with lots of large, opaque
    1.92 -binary files.  If you check in fifty revisions to an incompressible
    1.93 -10MB file, Subversion's client-side space usage stays constant The
    1.94 -space used by any distributed SCM will grow rapidly in proportion to
    1.95 -the number of revisions, because the differences between each revision
    1.96 -are large.
    1.97 -
    1.98 -In addition, it's often difficult or, more usually, impossible to
    1.99 -merge different versions of a binary file.  Subversion's ability to
   1.100 -let a user lock a file, so that they temporarily have the exclusive
   1.101 -right to commit changes to it, can be a significant advantage to a
   1.102 -project where binary files are widely used.
   1.103 -
   1.104 -Mercurial can import revision history from a Subversion repository.
   1.105 -It can also export revision history to a Subversion repository.  This
   1.106 -makes it easy to ``test the waters'' and use Mercurial and Subversion
   1.107 -in parallel before deciding to switch.  History conversion is
   1.108 -incremental, so you can perform an initial conversion, then small
   1.109 -additional conversions afterwards to bring in new changes.
   1.110 -
   1.111 +Subversion est un outil de gestion de source les plus populaire, il fût 
   1.112 +développé pour remplacer CVS. Il a une architecture client/server centralisée.
   1.113 +
   1.114 +Subversion et Mercurial ont des noms de commandes très similaires pour 
   1.115 +les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile
   1.116 +d'apprendre l'autre. Ces deux outils sont portable sur les systèmes 
   1.117 +d'exploitation les plus populaires\footnote{NdT:Mercurial fonctionne sans problèmes
   1.118 +sur OpenVMS à l'ESME Sudria \url{http://www.esme.fr}, compte tenu que Subversion a été 
   1.119 +développé en C, je ne suis pas sûr que son portage aurait été aussi aisé.}.
   1.120 +%TODO: Backport this statement in english and spanish 
   1.121 +
   1.122 +Avant la version 1.5, Subversion n'offre aucune forme de support pour les fusions. Lors 
   1.123 +de l'écriture de ce livre, ces capacités de fusion sont nouvelle, et réputé pour être
   1.124 +\href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complexes
   1.125 +et buggués}.
   1.126 +
   1.127 +Mercurial dispose d'un avantages substantiel en terme de performance sur 
   1.128 +Subversion sur la plupart des opérations que j'ai pu testé. J'ai mesuré
   1.129 +une différence de performance allant de deux à six fois plus rapide avec
   1.130 +le système de stockage de fichier local de Subversion~1.4.3 
   1.131 +(\emph{ra\_local}), qui la méthode d'accès la plus rapide disponible. Dans
   1.132 +un déploiement plus réaliste, impliquant un stockage réseau, Subversion 
   1.133 +serait encore plus désavantagé. Parce que la plupart des commandes Subversion
   1.134 +doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme
   1.135 +de réplication, la capacité du serveur et la bande passante sont devenu des
   1.136 +goulots d'étranglement pour les projets de taille moyenne ou grande.
   1.137 +
   1.138 +En outre, Subversion implique une surchage substantielle dans le stockage local
   1.139 +de certaines données, pour éviter des transactions avec le serveur, pour 
   1.140 +certaines opérations communes, tel que la recherche des fichier modifiées
   1.141 +(\texttt{status}) et l'affichage des modifications par rapport la révision 
   1.142 +courante (\texttt{diff}). En conséquence, un répertoire de travail Subversion
   1.143 +a souvent la même taille, ou est plus grand, que un dépôt Mercurial et son
   1.144 +espace de travail, bien que le dépôt Mercurial contienne l'intégralité de
   1.145 +l'historique.
   1.146 +
   1.147 +Subversion est largement supportés par les outils tierses. Mercurial est
   1.148 +actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins,
   1.149 +et en effet certains des outils graphiques sont maintenant supérieur à leurs
   1.150 +équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent
   1.151 +manuel utilisateur.
   1.152 +
   1.153 +Parce que Subversion ne stocke par l'historique chez ses clients, il est 
   1.154 +parfaitement adapté à la gestion de projet qui doivent suivre un ensemble
   1.155 +de large fichier binaires et opaques. Si vous suivez une cinquantaine de
   1.156 +versions d'un fichier incompressible de 10MB, l'occupation disque coté client
   1.157 +d'un projet sous Subversion restera à peu près constante. A l'inverse, 
   1.158 +l'occupation disque du même projet sous n'importe lequel des gestionnaire
   1.159 +de source distribués grandira rapidement, proportionnellement aux nombres
   1.160 +de versions, car les différences entre chaque révision sera très grande.
   1.161 +
   1.162 +En outre, c'est souvent difficle ou, généralement, impossible de fusionner
   1.163 +des différences dans un fichier binaire. La capacité de Subversion de 
   1.164 +vérouiller des fichiers, pour permettre à l'utilisateur d'être le seul
   1.165 +à le mettre à jour (``commit'') temporairement, est avantage significatif
   1.166 +dans un projet doté de beaucoup de fichiers binaire.
   1.167 +
   1.168 +Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut
   1.169 +aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion.
   1.170 +Ceci rend très facile de ``tester l'eau'' et d'utiliser Mercurial et Subversion
   1.171 +en parallèle, avant de décider de migrer vers Mercurial. La conversion de 
   1.172 +l'historique est incrémental, donc vous pouvez effectuer une conversion 
   1.173 +initial, puis de petites additions par la suite pour ajouter les nouvelles
   1.174 +modifications.
   1.175  
   1.176  \subsection{Git}
   1.177  
   1.178 -Git is a distributed revision control tool that was developed for
   1.179 -managing the Linux kernel source tree.  Like Mercurial, its early
   1.180 -design was somewhat influenced by Monotone.
   1.181 -
   1.182 -Git has a very large command set, with version~1.5.0 providing~139
   1.183 -individual commands.  It has something of a reputation for being
   1.184 -difficult to learn.  Compared to Git, Mercurial has a strong focus on
   1.185 -simplicity.
   1.186 -
   1.187 -In terms of performance, Git is extremely fast.  In several cases, it
   1.188 -is faster than Mercurial, at least on Linux, while Mercurial performs
   1.189 -better on other operations.  However, on Windows, the performance and
   1.190 -general level of support that Git provides is, at the time of writing,
   1.191 -far behind that of Mercurial.
   1.192 -
   1.193 -While a Mercurial repository needs no maintenance, a Git repository
   1.194 -requires frequent manual ``repacks'' of its metadata.  Without these,
   1.195 -performance degrades, while space usage grows rapidly.  A server that
   1.196 -contains many Git repositories that are not rigorously and frequently
   1.197 -repacked will become heavily disk-bound during backups, and there have
   1.198 -been instances of daily backups taking far longer than~24 hours as a
   1.199 -result.  A freshly packed Git repository is slightly smaller than a
   1.200 -Mercurial repository, but an unpacked repository is several orders of
   1.201 -magnitude larger.
   1.202 -
   1.203 -The core of Git is written in C.  Many Git commands are implemented as
   1.204 -shell or Perl scripts, and the quality of these scripts varies widely.
   1.205 -I have encountered several instances where scripts charged along
   1.206 -blindly in the presence of errors that should have been fatal.
   1.207 -
   1.208 -Mercurial can import revision history from a Git repository.
   1.209 -
   1.210 +Git est un outil de gestion de source distribué qui fût développé pour gérer
   1.211 +le code source de noyau de Linux. Comme Mercurial, sa conception initial à 
   1.212 +était inspiré par Monotone.
   1.213 +
   1.214 +Git dispose d'un ensemble conséquent de command, avec plus de~139 commandes
   1.215 +individuels pour la version~1.5.0. Il a aussi la réputation d'être difficile
   1.216 +à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa 
   1.217 +simplicité.
   1.218 +
   1.219 +En terme de performance, Git est extrêmement rapide. Dans la plupart des
   1.220 +cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que 
   1.221 +Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur
   1.222 +Windows, les performances et le niveau de support général fourni par Git, 
   1.223 +au moment de l'écriture de cet ouvrage, bien derrière celui de Mercurial.
   1.224 +
   1.225 +Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git
   1.226 +exige d'exécuter manuellement et régulièrement la commande ``repacks'' sur
   1.227 +ces métadonnées. Sans ceci, les performances de git se dégrade, et la 
   1.228 +consommation de l'espace disque augmente rapidement. Un serveur qui contient
   1.229 +plusieurs dépôt Git qui ne sont pas régulièrement et fréquement ``repacked''
   1.230 +deviendra un vrai problème lors des ``backups'' du disque, et il y eu des
   1.231 +cas, où un ``backup'' journalier pouvait durer plus de~24 heures. Un dépôt
   1.232 +fraichement ``repacked'' sera légèrement plus petit que un dépôt Mercurial,
   1.233 +mais un dépôt non ``repacked'' est beaucoup plus grand.
   1.234 +
   1.235 +Le coeur de Git est écrit en C. La plupart des commandes Git sont implémentés
   1.236 +sous forme de script Shell ou Perl, et la qualité de ces scripts varient
   1.237 +grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient
   1.238 +chargé en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
   1.239 +fatal.
   1.240 +
   1.241 +Mercurial peut importer l'historique d'un dépôt Git.
   1.242  
   1.243  \subsection{CVS}
   1.244  
   1.245 -CVS is probably the most widely used revision control tool in the
   1.246 -world.  Due to its age and internal untidiness, it has been only
   1.247 -lightly maintained for many years.
   1.248 -
   1.249 -It has a centralised client/server architecture.  It does not group
   1.250 -related file changes into atomic commits, making it easy for people to
   1.251 -``break the build'': one person can successfully commit part of a
   1.252 -change and then be blocked by the need for a merge, causing other
   1.253 -people to see only a portion of the work they intended to do.  This
   1.254 -also affects how you work with project history.  If you want to see
   1.255 -all of the modifications someone made as part of a task, you will need
   1.256 -to manually inspect the descriptions and timestamps of the changes
   1.257 -made to each file involved (if you even know what those files were).
   1.258 -
   1.259 -CVS has a muddled notion of tags and branches that I will not attempt
   1.260 -to even describe.  It does not support renaming of files or
   1.261 -directories well, making it easy to corrupt a repository.  It has
   1.262 -almost no internal consistency checking capabilities, so it is usually
   1.263 -not even possible to tell whether or how a repository is corrupt.  I
   1.264 -would not recommend CVS for any project, existing or new.
   1.265 -
   1.266 -Mercurial can import CVS revision history.  However, there are a few
   1.267 -caveats that apply; these are true of every other revision control
   1.268 -tool's CVS importer, too.  Due to CVS's lack of atomic changes and
   1.269 -unversioned filesystem hierarchy, it is not possible to reconstruct
   1.270 -CVS history completely accurately; some guesswork is involved, and
   1.271 -renames will usually not show up.  Because a lot of advanced CVS
   1.272 -administration has to be done by hand and is hence error-prone, it's
   1.273 -common for CVS importers to run into multiple problems with corrupted
   1.274 -repositories (completely bogus revision timestamps and files that have
   1.275 -remained locked for over a decade are just two of the less interesting
   1.276 -problems I can recall from personal experience).
   1.277 -
   1.278 -Mercurial can import revision history from a CVS repository.
   1.279 -
   1.280 +CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui
   1.281 +dans le monde. À cause de son manque de properté interne, il n'est plus 
   1.282 +maintenu depuis plusieurs années.
   1.283 +
   1.284 +Il a une architecture client/serveur centralisé. Il ne groupe pas les
   1.285 +modifications de fichiers dans une opération de ``commit'' atomique, ce
   1.286 +qui permet à ses utilisateurs de ``casser le \textit{build}'' assez
   1.287 +facilement : une personne peut effectuer une opération de ``commit'' 
   1.288 +sans problème puis être bloqué par besoin de fusion, avec comme conséquence
   1.289 +néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses
   1.290 +modifications. Ce problème affecte aussi la manière de travailler avec 
   1.291 +l'historique du projet. Si vous voulez voir toutes les modifications d'une
   1.292 +personne du projet, vous devrez injecter manuellement les descriptions et les
   1.293 +\textit{timestamps} des modifications de chacun des fichiers impliqués (si
   1.294 +vous savez au moins quels sont ces fichiers).
   1.295 +
   1.296 +CVS a une notion étrange des \textit{tags} et des branches que je n'essayerais
   1.297 +même de décrire ici. Il ne supporte pas bien les opérations de renommage d'un 
   1.298 +fichier ou de répertoire, ce qui facilite la corruption de son dépôt. Il n'a
   1.299 +presque pas pour ainsi dire de contrôle de cohérence interne, il est donc 
   1.300 +pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je
   1.301 +ne recommanderais pas CVS pour un projet existant ou nouveau.
   1.302 +
   1.303 +Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a 
   1.304 +quelques princinpes à respecter; ce qui est vrai aussi pour les autres
   1.305 +outils d'import de projet CVS. À cause de l'absence de ``commit'' atomique
   1.306 +et gestion de version de l'arboresence, il n'est pas possible de reconstruire
   1.307 +de manière précise l'ensemble de l'historique. Un travail de ``devinette''
   1.308 +est donc nécessaire, et les fichiers renommées ne sont pas détectés. Parce 
   1.309 +que une bonne part de l'administration d'un dépôt CVS est effectué manuellement, 
   1.310 +et est donc, sujette à erreur, il est courant que les impots CVS rencontre 
   1.311 +de nombreux problèmes avec les dépôt corrompues (des \textit{timestamps} 
   1.312 +de révision complètement buggé et des fichiers vérouillés depuis des années 
   1.313 +sont deux des problèmes les moins intéressants dont je me souvienne).
   1.314 +
   1.315 +Mercurial peut importer l'historique depuis un dépôt CVS.
   1.316  
   1.317  \subsection{Commercial tools}
   1.318