1.1 --- a/fr/intro.tex	Fri Feb 06 20:49:16 2009 +0100
     1.2 +++ b/fr/intro.tex	Sun Feb 08 15:38:18 2009 +0100
     1.3 @@ -114,244 +114,221 @@
     1.4  
     1.5  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 cmt, avant de la renommer en \textit{CVS (Concurrent Versions System)}.  La grande innovation de CVS était que les développeurs pouvaient travailler simultanéement and indépendament dans leur propre espace de travail. Ces espaces de travail privés assuraient que les développeurs ne se marche mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS. Chaque développeur disposait donc de sa copie de tout les fichiers du projet, et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer la ``fusion'' (\textit{``merge''}) de leur fichiers, avant d'effectuer le ``commit'' de leur modification sur le dépôt central.
     1.6  
     1.7 -Brian Berliner took Grune's original scripts and rewrote them in~C,
     1.8 -releasing in 1989 the code that has since developed into the modern
     1.9 -version of CVS.  CVS subsequently acquired the ability to operate over
    1.10 -a network connection, giving it a client/server architecture.  CVS's
    1.11 -architecture is centralised; only the server has a copy of the history
    1.12 -of the project.  Client workspaces just contain copies of recent
    1.13 -versions of the project's files, and a little metadata to tell them
    1.14 -where the server is.  CVS has been enormously successful; it is
    1.15 -probably the world's most widely used revision control system.
    1.16 -
    1.17 -In the early 1990s, Sun Microsystems developed an early distributed
    1.18 -revision control system, called TeamWare.  A TeamWare workspace
    1.19 -contains a complete copy of the project's history.  TeamWare has no
    1.20 -notion of a central repository.  (CVS relied upon RCS for its history
    1.21 -storage; TeamWare used SCCS.)
    1.22 -
    1.23 -As the 1990s progressed, awareness grew of a number of problems with
    1.24 -CVS.  It records simultaneous changes to multiple files individually,
    1.25 -instead of grouping them together as a single logically atomic
    1.26 -operation.  It does not manage its file hierarchy well; it is easy to
    1.27 -make a mess of a repository by renaming files and directories.  Worse,
    1.28 -its source code is difficult to read and maintain, which made the
    1.29 -``pain level'' of fixing these architectural problems prohibitive.
    1.30 -
    1.31 -In 2001, Jim Blandy and Karl Fogel, two developers who had worked on
    1.32 -CVS, started a project to replace it with a tool that would have a
    1.33 -better architecture and cleaner code.  The result, Subversion, does
    1.34 -not stray from CVS's centralised client/server model, but it adds
    1.35 -multi-file atomic commits, better namespace management, and a number
    1.36 -of other features that make it a generally better tool than CVS.
    1.37 -Since its initial release, it has rapidly grown in popularity.
    1.38 -
    1.39 -More or less simultaneously, Graydon Hoare began working on an
    1.40 -ambitious distributed revision control system that he named Monotone.
    1.41 -While Monotone addresses many of CVS's design flaws and has a
    1.42 -peer-to-peer architecture, it goes beyond earlier (and subsequent)
    1.43 -revision control tools in a number of innovative ways.  It uses
    1.44 -cryptographic hashes as identifiers, and has an integral notion of
    1.45 -``trust'' for code from different sources.
    1.46 -
    1.47 -Mercurial began life in 2005.  While a few aspects of its design are
    1.48 -influenced by Monotone, Mercurial focuses on ease of use, high
    1.49 -performance, and scalability to very large projects.
    1.50 -
    1.51 -\section{Trends in revision control}
    1.52 -
    1.53 -There has been an unmistakable trend in the development and use of
    1.54 -revision control tools over the past four decades, as people have
    1.55 -become familiar with the capabilities of their tools and constrained
    1.56 -by their limitations.
    1.57 -
    1.58 -The first generation began by managing single files on individual
    1.59 -computers.  Although these tools represented a huge advance over
    1.60 -ad-hoc manual revision control, their locking model and reliance on a
    1.61 -single computer limited them to small, tightly-knit teams.
    1.62 -
    1.63 -The second generation loosened these constraints by moving to
    1.64 -network-centered architectures, and managing entire projects at a
    1.65 -time.  As projects grew larger, they ran into new problems.  With
    1.66 -clients needing to talk to servers very frequently, server scaling
    1.67 -became an issue for large projects.  An unreliable network connection
    1.68 -could prevent remote users from being able to talk to the server at
    1.69 -all.  As open source projects started making read-only access
    1.70 -available anonymously to anyone, people without commit privileges
    1.71 -found that they could not use the tools to interact with a project in
    1.72 -a natural way, as they could not record their changes.
    1.73 -
    1.74 -The current generation of revision control tools is peer-to-peer in
    1.75 -nature.  All of these systems have dropped the dependency on a single
    1.76 -central server, and allow people to distribute their revision control
    1.77 -data to where it's actually needed.  Collaboration over the Internet
    1.78 -has moved from constrained by technology to a matter of choice and
    1.79 -consensus.  Modern tools can operate offline indefinitely and
    1.80 -autonomously, with a network connection only needed when syncing
    1.81 -changes with another repository.
    1.82 -
    1.83 -\section{A few of the advantages of distributed revision control}
    1.84 -
    1.85 -Even though distributed revision control tools have for several years
    1.86 -been as robust and usable as their previous-generation counterparts,
    1.87 -people using older tools have not yet necessarily woken up to their
    1.88 -advantages.  There are a number of ways in which distributed tools
    1.89 -shine relative to centralised ones.
    1.90 -
    1.91 -For an individual developer, distributed tools are almost always much
    1.92 -faster than centralised tools.  This is for a simple reason: a
    1.93 -centralised tool needs to talk over the network for many common
    1.94 -operations, because most metadata is stored in a single copy on the
    1.95 -central server.  A distributed tool stores all of its metadata
    1.96 -locally.  All else being equal, talking over the network adds overhead
    1.97 -to a centralised tool.  Don't underestimate the value of a snappy,
    1.98 -responsive tool: you're going to spend a lot of time interacting with
    1.99 -your revision control software.
   1.100 -
   1.101 -Distributed tools are indifferent to the vagaries of your server
   1.102 -infrastructure, again because they replicate metadata to so many
   1.103 -locations.  If you use a centralised system and your server catches
   1.104 -fire, you'd better hope that your backup media are reliable, and that
   1.105 -your last backup was recent and actually worked.  With a distributed
   1.106 -tool, you have many backups available on every contributor's computer.
   1.107 -
   1.108 -The reliability of your network will affect distributed tools far less
   1.109 -than it will centralised tools.  You can't even use a centralised tool
   1.110 -without a network connection, except for a few highly constrained
   1.111 -commands.  With a distributed tool, if your network connection goes
   1.112 -down while you're working, you may not even notice.  The only thing
   1.113 -you won't be able to do is talk to repositories on other computers,
   1.114 -something that is relatively rare compared with local operations.  If
   1.115 -you have a far-flung team of collaborators, this may be significant.
   1.116 -
   1.117 -\subsection{Advantages for open source projects}
   1.118 -
   1.119 -If you take a shine to an open source project and decide that you
   1.120 -would like to start hacking on it, and that project uses a distributed
   1.121 -revision control tool, you are at once a peer with the people who
   1.122 -consider themselves the ``core'' of that project.  If they publish
   1.123 -their repositories, you can immediately copy their project history,
   1.124 -start making changes, and record your work, using the same tools in
   1.125 -the same ways as insiders.  By contrast, with a centralised tool, you
   1.126 -must use the software in a ``read only'' mode unless someone grants
   1.127 -you permission to commit changes to their central server.  Until then,
   1.128 -you won't be able to record changes, and your local modifications will
   1.129 -be at risk of corruption any time you try to update your client's view
   1.130 -of the repository.
   1.131 -
   1.132 -\subsubsection{The forking non-problem}
   1.133 -
   1.134 -It has been suggested that distributed revision control tools pose
   1.135 -some sort of risk to open source projects because they make it easy to
   1.136 -``fork'' the development of a project.  A fork happens when there are
   1.137 -differences in opinion or attitude between groups of developers that
   1.138 -cause them to decide that they can't work together any longer.  Each
   1.139 -side takes a more or less complete copy of the project's source code,
   1.140 -and goes off in its own direction.
   1.141 -
   1.142 -Sometimes the camps in a fork decide to reconcile their differences.
   1.143 -With a centralised revision control system, the \emph{technical}
   1.144 -process of reconciliation is painful, and has to be performed largely
   1.145 -by hand.  You have to decide whose revision history is going to
   1.146 -``win'', and graft the other team's changes into the tree somehow.
   1.147 -This usually loses some or all of one side's revision history.
   1.148 -
   1.149 -What distributed tools do with respect to forking is they make forking
   1.150 -the \emph{only} way to develop a project.  Every single change that
   1.151 -you make is potentially a fork point.  The great strength of this
   1.152 -approach is that a distributed revision control tool has to be really
   1.153 -good at \emph{merging} forks, because forks are absolutely
   1.154 -fundamental: they happen all the time.  
   1.155 -
   1.156 -If every piece of work that everybody does, all the time, is framed in
   1.157 -terms of forking and merging, then what the open source world refers
   1.158 -to as a ``fork'' becomes \emph{purely} a social issue.  If anything,
   1.159 -distributed tools \emph{lower} the likelihood of a fork:
   1.160 +Brian Berliner repris les scripts de Grune's et les réécris 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, le 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. 
   1.161 +
   1.162 +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 contient une copie complète de l'historique du projet. TeamWare n'a pas de notion de dépot central. (CVS utilisé RCS pour le stockage de l'historique, TeamWare utilisé SCCS).
   1.163 +
   1.164 +Alors que les années 1990 avancé, les utilisateurs ont pris conscience d'un certain nombre de problème avec CVS. Il enregistrait simultanéement des modifications sur différents fichier 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 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 souffrance'' associé à la réparation de ces problèmes d'architecture de manière prohibitive. 
   1.165 +
   1.166 +
   1.167 +En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé sur CVS, initialisèrent un projet pour le remplacer par un outil qui aurait une meilleur 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 fichier, une meilleur 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.
   1.168 +
   1.169 +Plus ou moins de manière simultanné, 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 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 notion complète de ``confiance'' du code issues de différentes sources.
   1.170 +
   1.171 +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 pour de très grand projets.
   1.172 +
   1.173 +\section{Tendances de la gestion de source}
   1.174 +
   1.175 +Il y a eu une tendance évidente dans le développement et l'utilisation d'outil de gestion de source depuis les quatre dernière décades, au fur et à mesure que les utilisateurs se sont habitués à leur outils et se sont sentis contraint par leur limitations.
   1.176 +
   1.177 +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ésentè-rent une grande avancée par rapport à la gestion manuel des versions, leur modèle de vérouillage et leur utilisation limité à un seul ordinateur rendaient leur utilisation possible uniquement dans une très petite équipe. 
   1.178 +
   1.179 +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 problèmes. Avec les clients discutant régulièrement avec le serveurs, la monte en charge devint un réellement problème sur les gros projets. Une connexion réseau peu fiable pouvant empêcher simplement les utilisateurs distant de discuter 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 pas utiliser les outils pour collaboraient naturellement avec le projet, comme ils ne pouvaient pas non plus enregistrer leurs modifications.
   1.180 +
   1.181 +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 distribué 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 de manière autonome, la connexion au réseau n'étant nécessaire que pour synchroniser les modifications avec les autres dépots.
   1.182 +
   1.183 +\section{Quelques avantages des gestionnaire de source distribué}
   1.184 +
   1.185 +Même si les gestionnaire de source distribué sont depuis plusieurs années
   1.186 +assez robuste et aussi utilisable que leur prédécésseurs, les utilisateurs
   1.187 +d'autres outils n'ont pas encore étaient sensibilisé. Les gestionnaires
   1.188 +de sources distribué se distingue particulièrement de leurs équivalents
   1.189 +centralisé de nombreuse manière.
   1.190 +
   1.191 +Pour un développeur individuel, ils restent beaucoup plus rapide que les
   1.192 +outils centralisés. Cela pour une raison simple: un outil centralisé doit
   1.193 +toujours discuter à travers le réseau pour la plupart des opérations, car
   1.194 +presque toutes les métadonnées sont stockées sur la seule copie du serveur
   1.195 +central. Un outil distribué stocke toute ses métadonnées localement. À tâche
   1.196 +égale, effectuer un échange avec le réseau ajoute un délai aux outils 
   1.197 +centralisés. Ne sous estimez pas la valeur d'un outil rapide: vous allez
   1.198 +passer beaucoup de temps à interagir avec un logiciel de gestion de sources.
   1.199 +
   1.200 +Les outils distribué sont complètement indépendant des aléas de votre serveur,
   1.201 +encore une fois car ils répliquent les métadonnées à tellement d'endoit. Si
   1.202 +votre serveur central prend feu, vous avez intérêt à ce que les média de 
   1.203 +sauvegarde soient fiable, et que votre dernier ``backup'' soit récent et
   1.204 +fonctionne sans problème. Avec un outil distribué, vous avez autant de 
   1.205 +``backup'' que de contributeurs.
   1.206 +
   1.207 +En outre, la fiabilité de votre réseau affectera beaucoup moins les
   1.208 +outils distribué. Vous ne pouvez même pas utiliser un outil centralisé
   1.209 +sans connexion réseau, à l'exception de quelques commandes, très limités. 
   1.210 +Avec un outil distribué, si vous connexion réseau tombe pendant que vous
   1.211 +travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose
   1.212 +que vous ne serez pas capable de faire sera de communiquer avec des dépôts
   1.213 +distants, opération somme toute assez rare par comparaison aux opérations
   1.214 +locales. Si vous avez une (TODO:far-flung???) équipe de collaborateurs, 
   1.215 +ceci peut être significatif.
   1.216 +
   1.217 +\subsection{Avantages pour les projets \textit{Open Source}}
   1.218 +
   1.219 +Si vous prenez goût à un projet \textit{Open Source} et que vous
   1.220 +décidez de commencer à toucher à son code, et que le projet utilise
   1.221 +un gestionnaire de source distribué, vous êtes immédiatement un "pair"
   1.222 +avec les personnes formant le ``coeur'' du projet. Si ils publient
   1.223 +leurs dépôts, vous pouvez immédiatement copier leurs historiques de
   1.224 +projet, faire des modifications, enregistrer votre travail en utilisant
   1.225 +les même outils qu'eux. Par comparaison, avec un outil centralisé, vous
   1.226 +devez utiliser un logiciel en mode ``lecture seule'' à moins que 
   1.227 +quelqu'un ne vous donne les privilèges de ``commit'' sur le serveur
   1.228 +central. Avant ça, vous ne serez pas capable d'enregistrer vos 
   1.229 +modifications, et vos propres modifications risqueront de se 
   1.230 +corrompre chaque fois que vous essayerez de mettre à jour à votre
   1.231 +espace de travail avec le serveur central.
   1.232 +
   1.233 +\subsubsection{Le non-problème du \textit{fork}}
   1.234 +
   1.235 +Il a été souvent suggeré que les gestionnaires de source distribués
   1.236 +posent un risque pour les projets \textit{Open Source} car ils 
   1.237 +facilitent grandement la création de ``fork''\footnote{NdT:Création 
   1.238 +d'une version alternative du logiciel}. %%% TODO: Link to Wikipedia
   1.239 +Un ``fork'' apparait quand il y des divergences d'opinion ou d'attitude
   1.240 +au sein d'un groupe de développeurs qui aboutit à la décision de ne 
   1.241 +plus travail ensemble. Chacun parti s'empare d'une copie plus ou moins
   1.242 +complète du code source du projet et continue dans sa propre direction.
   1.243 +
   1.244 +Parfois ces différents partis décide de se réconcilier. Avec un 
   1.245 +serveur central, l'aspect \emph{technique} de cette réconciliation
   1.246 +est un processus douloureux, et essentiellement manuel. Vous devez
   1.247 +décider quelle modification est ``la gagnante'', et replacer, par un
   1.248 +moyen ou un autre, les modifications de l'autre équipe dans l'arboresence
   1.249 +du projet. Ceci implique généralement la perte d'une partie l'historique 
   1.250 +d'un des partie, ou même des deux.
   1.251 +
   1.252 +Ce que les outils distribués permettent à ce sujet est probablement
   1.253 +la \emph{meilleur} façon de développer un projet. Chaque modification
   1.254 +que vous effectué est potentiellement un ``fork''. La grande force de 
   1.255 +cette approche est que les gestionnaire de source distribué doit être
   1.256 +vraiment très efficase pour \emph{fusionner}\footnote{NdT:j'ai choisi de
   1.257 +traduire ici \textit{merging} par ``fusionner'' pour des raisons de clarté}
   1.258 +des ``forks'', car les ``forks'', dans ce contexte, arrivent tout le
   1.259 +temps.
   1.260 +
   1.261 +Si chaque altération que n'importe qui effectue, à tout moment, est vu
   1.262 +comme un ``fork'' à fusionner, alors ce que le monde de l'\textit{Open 
   1.263 +Source} voit comme un ``fork'' devient \emph{uniquement} une problématique 
   1.264 +social. En fait, les outils de gestion de source distribué \emph{réduisent} 
   1.265 +les chances de ``fork'':
   1.266  \begin{itemize}
   1.267 -\item They eliminate the social distinction that centralised tools
   1.268 -  impose: that between insiders (people with commit access) and
   1.269 -  outsiders (people without).
   1.270 -\item They make it easier to reconcile after a social fork, because
   1.271 -  all that's involved from the perspective of the revision control
   1.272 -  software is just another merge.
   1.273 +\item Ils éliminent la distinction social qu'imposent les outils centralisés
   1.274 +	entre les membres du projets (ce qui ont accès au ``comit'') et ceux de l'
   1.275 +	extérieur (ce qui ne l'ont pas).
   1.276 +\item Ils rendent plus facile la réconciliation après un ``fork'' social, car
   1.277 +	tout ce qu'elle implique est juste une simple fusion.
   1.278  \end{itemize}
   1.279  
   1.280 -Some people resist distributed tools because they want to retain tight
   1.281 -control over their projects, and they believe that centralised tools
   1.282 -give them this control.  However, if you're of this belief, and you
   1.283 -publish your CVS or Subversion repositories publically, there are
   1.284 -plenty of tools available that can pull out your entire project's
   1.285 -history (albeit slowly) and recreate it somewhere that you don't
   1.286 -control.  So while your control in this case is illusory, you are
   1.287 -forgoing the ability to fluidly collaborate with whatever people feel
   1.288 -compelled to mirror and fork your history.
   1.289 -
   1.290 -\subsection{Advantages for commercial projects}
   1.291 -
   1.292 -Many commercial projects are undertaken by teams that are scattered
   1.293 -across the globe.  Contributors who are far from a central server will
   1.294 -see slower command execution and perhaps less reliability.  Commercial
   1.295 -revision control systems attempt to ameliorate these problems with
   1.296 -remote-site replication add-ons that are typically expensive to buy
   1.297 -and cantankerous to administer.  A distributed system doesn't suffer
   1.298 -from these problems in the first place.  Better yet, you can easily
   1.299 -set up multiple authoritative servers, say one per site, so that
   1.300 -there's no redundant communication between repositories over expensive
   1.301 -long-haul network links.
   1.302 -
   1.303 -Centralised revision control systems tend to have relatively low
   1.304 -scalability.  It's not unusual for an expensive centralised system to
   1.305 -fall over under the combined load of just a few dozen concurrent
   1.306 -users.  Once again, the typical response tends to be an expensive and
   1.307 -clunky replication facility.  Since the load on a central server---if
   1.308 -you have one at all---is many times lower with a distributed
   1.309 -tool (because all of the data is replicated everywhere), a single
   1.310 -cheap server can handle the needs of a much larger team, and
   1.311 -replication to balance load becomes a simple matter of scripting.
   1.312 -
   1.313 -If you have an employee in the field, troubleshooting a problem at a
   1.314 -customer's site, they'll benefit from distributed revision control.
   1.315 -The tool will let them generate custom builds, try different fixes in
   1.316 -isolation from each other, and search efficiently through history for
   1.317 -the sources of bugs and regressions in the customer's environment, all
   1.318 -without needing to connect to your company's network.
   1.319 -
   1.320 -\section{Why choose Mercurial?}
   1.321 -
   1.322 -Mercurial has a unique set of properties that make it a particularly
   1.323 -good choice as a revision control system.
   1.324 +Certaines personnes font de la résistance envers les gestionnaires de source
   1.325 +distribués parce qu'ils veulent garder un contrôle ferme de leur projet, et
   1.326 +ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins,
   1.327 +si c'est votre cas, sachez que si vous publier votre dépôt CVS ou Subversion
   1.328 +de manière publique, il existe une quantité d'outils disponibles pour récupérer
   1.329 +entièrement votre projet et son historique (quoique lentement) et le récréer 
   1.330 +ailleurs, sans votre contrôle. En fait, votre contrôle sur votre projet est 
   1.331 +illusoire, vous ne faites qu'interdire à vos collaborateurs de travailler
   1.332 +de manière fluide, en disposant d'un miroir ou d'un ``fork'' de votre
   1.333 +historique.
   1.334 +%%%TODO: Fussy, those last sentences are not really well translated:
   1.335 +%However, if you're of this belief, and you publish your CVS or Subversion 
   1.336 +%repositories publically, there are plenty of tools available that can pull 
   1.337 +%out your entire project's history (albeit slowly) and recreate it somewhere 
   1.338 +%that you don't control.  So while your control in this case is illusory, you are
   1.339 +%forgoing the ability to fluidly collaborate with whatever people feel
   1.340 +%compelled to mirror and fork your history.
   1.341 +
   1.342 +\subsection{Avantages pour les projets commerciaux}
   1.343 +
   1.344 +Beaucoup de projets commerciaux sont réalisé par des équipes éparpillées
   1.345 +à travers le globe. Les contributeurs qui sont loin du serveur central
   1.346 +devront subir des commandes lentes et même parfois peu fiable. Les 
   1.347 +solutions propriétaires gestion de source, tentent de palier ce problème 
   1.348 +avec des réplications de site distant qui sont à la fois coûteuses à mettre
   1.349 +en place et lourdes à administrer. A un système distribué ne souffre pas
   1.350 +de ce genre de problèmes. En outre, il est très aisé de mettre en place
   1.351 +plusieurs serveurs de références, disont un par site, de manière à ce qu'il
   1.352 +n'y est pas de communication redondante entre les dépôts, sur une connexion
   1.353 +longue distance souvent onéreuse.
   1.354 +
   1.355 +Les systèmes de gestion de source supportent généralement assez mal la 
   1.356 +monté en charge. Ce n'est pas rare pour un gestionnaire de source centralisé 
   1.357 +pourtant onéreux de s'effondrer sous la charge combinée de juste une douzaine 
   1.358 +d'utilisateurs concurrents. Une fois encore, la réponse à cette problématique 
   1.359 +est généralement encore la mise en place d'un ensemble complexe de serveurs
   1.360 +synchronisé par un mécanisme de réplication. Dans le cas d'un gestionnaire
   1.361 +de source distribué, la charge du serveur central--- si vous avez un--- est
   1.362 +plusieurs fois inférieur (car toutes les données sont déjà répliqués ailleurs),
   1.363 +un simple server, pas très cher, peut gérer les besoins d'une plus grande
   1.364 +équipe, et la réplication pour balancer la charge devient simplement le
   1.365 +travail d'un simple script.
   1.366 +
   1.367 +Si vous avez des employés sur le terrain, entrain de chercher à résoudre sur
   1.368 +le site d'un client, ils bénéficieront aussi d'un gestionnaire de source
   1.369 +distribués. Cet outil leur permettra de générer des versions personnalisées,
   1.370 +d'essayer différentes solutions, en les isolant aisément les une des autres,
   1.371 +et de recherche efficasement à travers l'historique des sources, la cause
   1.372 +des bugs ou des régression, tout ceci sans avoir besoin de la moindre 
   1.373 +connexion au réseau de votre compagnie.
   1.374 +
   1.375 +\section{Pourquoi choisir Mercurial?}
   1.376 +
   1.377 +Mercurial a plusieurs caractéristiques qui en font un choix particulièrement
   1.378 +pertinent pour la gestion de source:
   1.379  \begin{itemize}
   1.380 -\item It is easy to learn and use.
   1.381 -\item It is lightweight.
   1.382 -\item It scales excellently.
   1.383 -\item It is easy to customise.
   1.384 +	\item Il est facile à apprendre et à utiliser ;It is easy to learn and use.
   1.385 +	\item il est léger et performant ;
   1.386 +	\item il monte facilement en charge ; 
   1.387 +	\item il est facile à personnaliser ;
   1.388  \end{itemize}
   1.389  
   1.390 -If you are at all familiar with revision control systems, you should
   1.391 -be able to get up and running with Mercurial in less than five
   1.392 -minutes.  Even if not, it will take no more than a few minutes
   1.393 -longer.  Mercurial's command and feature sets are generally uniform
   1.394 -and consistent, so you can keep track of a few general rules instead
   1.395 -of a host of exceptions.
   1.396 -
   1.397 -On a small project, you can start working with Mercurial in moments.
   1.398 -Creating new changes and branches; transferring changes around
   1.399 -(whether locally or over a network); and history and status operations
   1.400 -are all fast.  Mercurial attempts to stay nimble and largely out of
   1.401 -your way by combining low cognitive overhead with blazingly fast
   1.402 -operations.
   1.403 -
   1.404 -The usefulness of Mercurial is not limited to small projects: it is
   1.405 -used by projects with hundreds to thousands of contributors, each
   1.406 -containing tens of thousands of files and hundreds of megabytes of
   1.407 -source code.
   1.408 -
   1.409 -If the core functionality of Mercurial is not enough for you, it's
   1.410 -easy to build on.  Mercurial is well suited to scripting tasks, and
   1.411 -its clean internals and implementation in Python make it easy to add
   1.412 -features in the form of extensions.  There are a number of popular and
   1.413 -useful extensions already available, ranging from helping to identify
   1.414 -bugs to improving performance.
   1.415 +Si vous êtes déjà familier d'un outil de gestion de source, vous serez
   1.416 +capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup
   1.417 +plus long\footnote{NdT: Pour appuyer le propos de l'auteur, je signale que 
   1.418 +j'utilise Mercurial comme outil d'initiation à la gestion de contrôle dans
   1.419 +des travaux pratique à l'ESME Sudria (\url{http://www.esme.fr}) et que les
   1.420 +élèves le prennent en main sans difficulté majeur malgré l'approche distribuée.}. 
   1.421 +Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont 
   1.422 +généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête 
   1.423 +simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions.
   1.424 +
   1.425 +Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en
   1.426 +quelques instants. Ajouter des modifications ou des branches, transférer 
   1.427 +ces modifications (localement ou via le réseau), et les opérations 
   1.428 +d'historique ou de statut sont aussi très rapide. Mercurial reste hors de 
   1.429 +votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution.
   1.430 +
   1.431 +L'utilité de Mercurial ne se limite pas à des petits projets: il est 
   1.432 +aussi utilisé par des projets ayant des centaines ou même des milliers
   1.433 +de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des
   1.434 +centaines de méga de code source.
   1.435 +
   1.436 +Voici une liste non exhaustive des projets complexe ou critique utilisant 
   1.437 +mercurial :
   1.438 +%TODO
   1.439 +% For both spanish and english version, add the following examples:
   1.440 +\begin{itemize}
   1.441 +	\item Firefox ;
   1.442 +	\item OpenSolaris ;
   1.443 +	\item OpenJDK (utilisant en outre l'extension ``forest'' pour gérer
   1.444 +	ses sous modules);
   1.445 +\end{itemize}
   1.446 +% TODO: Also add appropriate link.
   1.447 +
   1.448 +Si les fonctionnalités coeur de Mercurial ne sont pas suffisantes pour vous, 
   1.449 +il est très aisé de construire dessus. Mercurial est adapté à l'utilisation
   1.450 +au sein de script, et son implémentation interne en python, propre et claire,
   1.451 +rend encore plus facile l'ajout de fonctionnalité sous forme d'extension. Il
   1.452 +en existe déjà un certains nombres de très populaires et très utiles, 
   1.453 +dont le périmètre va de la recherche de bugs à l'amélioration des performances.
   1.454  
   1.455  \section{Mercurial compared with other tools}
   1.456