1.1 --- a/fr/intro.tex	Fri Feb 06 15:31:26 2009 +0100
     1.2 +++ b/fr/intro.tex	Fri Feb 06 20:49:16 2009 +0100
     1.3 @@ -34,89 +34,85 @@
     1.4  gestion de source facilite le travail collaboratif. Par exemple, quand
     1.5  plusieurs personnes font, plus ou moins simultannéement, des modifications
     1.6  incompatibles, le logiciel vous aidera à identifier et résoudre les conflits.
     1.7 -\item It can help you to recover from mistakes.  If you make a change
     1.8 -  that later turns out to be in error, you can revert to an earlier
     1.9 -  version of one or more files.  In fact, a \emph{really} good
    1.10 -  revision control tool will even help you to efficiently figure out
    1.11 -  exactly when a problem was introduced (see
    1.12 -  section~\ref{sec:undo:bisect} for details).
    1.13 -\item It will help you to work simultaneously on, and manage the drift
    1.14 -  between, multiple versions of your project.
    1.15 +\item L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
    1.16 +qui se révèlera être une erreur, vous pourrez revenir fiablement à une version
    1.17 +antérieur d'une fichier ou même d'un ensemble de fichier. En fait, un outil de
    1.18 +gestion de source \emph{vraiment} efficace vous permettra d'identifier à quel
    1.19 +moment le problème est apparu (voir la section~\ref{sec:undo:bisect} pour plus
    1.20 +de détails).
    1.21 +\item L'outil vous permettra aussi de travailler sur plusieurs versions différentes
    1.22 +de votre projet et à gérer l'écart entre chaque.
    1.23  \end{itemize}
    1.24 -Most of these reasons are equally valid---at least in theory---whether
    1.25 -you're working on a project by yourself, or with a hundred other
    1.26 -people.
    1.27 -
    1.28 -A key question about the practicality of revision control at these two
    1.29 -different scales (``lone hacker'' and ``huge team'') is how its
    1.30 -\emph{benefits} compare to its \emph{costs}.  A revision control tool
    1.31 -that's difficult to understand or use is going to impose a high cost.
    1.32 -
    1.33 -A five-hundred-person project is likely to collapse under its own
    1.34 -weight almost immediately without a revision control tool and process.
    1.35 -In this case, the cost of using revision control might hardly seem
    1.36 -worth considering, since \emph{without} it, failure is almost
    1.37 -guaranteed.
    1.38 -
    1.39 -On the other hand, a one-person ``quick hack'' might seem like a poor
    1.40 -place to use a revision control tool, because surely the cost of using
    1.41 -one must be close to the overall cost of the project.  Right?
    1.42 -
    1.43 -Mercurial uniquely supports \emph{both} of these scales of
    1.44 -development.  You can learn the basics in just a few minutes, and due
    1.45 -to its low overhead, you can apply revision control to the smallest of
    1.46 -projects with ease.  Its simplicity means you won't have a lot of
    1.47 -abstruse concepts or command sequences competing for mental space with
    1.48 -whatever you're \emph{really} trying to do.  At the same time,
    1.49 -Mercurial's high performance and peer-to-peer nature let you scale
    1.50 -painlessly to handle large projects.
    1.51 -
    1.52 -No revision control tool can rescue a poorly run project, but a good
    1.53 -choice of tools can make a huge difference to the fluidity with which
    1.54 -you can work on a project.
    1.55 -
    1.56 -\subsection{The many names of revision control}
    1.57 -
    1.58 -Revision control is a diverse field, so much so that it doesn't
    1.59 -actually have a single name or acronym.  Here are a few of the more
    1.60 -common names and acronyms you'll encounter:
    1.61 +La plupart de ces raisons ont autant d'importances---du moins en théorie--- que
    1.62 +vous travailliez sur un projet pour vous, ou avec une centaine d'autres
    1.63 +personnes.
    1.64 +
    1.65 +Une question fondamental à propos des outils de gestion de source, qu'il s'agisse
    1.66 +du projet d'une personne ou d'une grande équipe, est quelles sont ses  
    1.67 +\emph{avantages} par rapport à ses \emph{coût}. Un outil qui est difficile à 
    1.68 +utiliser ou à comprendre exigera un effort d'adoption.
    1.69 +
    1.70 +Un projet de cinq milles personnnes s'effondrera très certainement de lui même
    1.71 +sans aucun processus et outil de gestion de source. Dans ce cas, le coût 
    1.72 +d'utilisation d'un logiciel de gestion de source est dérisoire, puisque 
    1.73 +\emph{sans}, l'échec est presque garanti.
    1.74 +
    1.75 +D'un autre coté, un ``rapide hack'' d'une personnne peut sembler un contexte
    1.76 +bien pauvre pour utiliser un outil de gestion de source, car, bien évidement
    1.77 +le coût d'utilisation dépasse le coût total du projet. N'est ce pas ?
    1.78 +
    1.79 +Mercurial supporte ces \emph{deux} échelles de travail. Vous pouvez apprendre
    1.80 +les bases en juste quelques minutes, et, grâce à sa performance, vous pouvez
    1.81 +l'utiliser avec facilité sur le plus petit des projets. Cette simplicité 
    1.82 +signifie que vous n'avez pas de concepts obscures ou de séquence de commandes
    1.83 +défiant l'imagination, complètement décorrelé de \emph{ce que vous êtes 
    1.84 +vraiment entrain de faire}. En même temps, ces mêmes performances et sa 
    1.85 +nature ``peer-to-peer'' vous permet d'augmenter, sans difficulté, son 
    1.86 +utilisation à de très grand projet.
    1.87 +
    1.88 +Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un
    1.89 +bon outil peut faire une grande différence dans la fluidité avec lequel 
    1.90 +vous pourrez travailler avec.
    1.91 +
    1.92 +\subsection{Les multiples noms de la gestion de source}
    1.93 +
    1.94 +La gestion de source est un domaine divers, tellement qu'il n'existe pas
    1.95 +une seul nom ou acronyme pour le désigner. Voilà quelqu'uns des noms ou 
    1.96 +acronymes que vous rencontrerez le plus souvent:
    1.97  \begin{itemize}
    1.98 -\item Revision control (RCS)
    1.99 -\item Software configuration management (SCM), or configuration management
   1.100 -\item Source code management
   1.101 -\item Source code control, or source control
   1.102 -\item Version control (VCS)
   1.103 +\item \textit{Revision control (RCS)} ;
   1.104 +\item Software configuration management (SCM), ou \textit{configuration management} ;
   1.105 +\item \textit{Source code management} ;
   1.106 +\item \textit{Source code control}, ou \textit{source control} ;
   1.107 +\item \textit{Version control (VCS)}.
   1.108  \end{itemize}
   1.109 -Some people claim that these terms actually have different meanings,
   1.110 -but in practice they overlap so much that there's no agreed or even
   1.111 -useful way to tease them apart.
   1.112 -
   1.113 -\section{A short history of revision control}
   1.114 -
   1.115 -The best known of the old-time revision control tools is SCCS (Source
   1.116 -Code Control System), which Marc Rochkind wrote at Bell Labs, in the
   1.117 -early 1970s.  SCCS operated on individual files, and required every
   1.118 -person working on a project to have access to a shared workspace on a
   1.119 -single system.  Only one person could modify a file at any time;
   1.120 -arbitration for access to files was via locks.  It was common for
   1.121 -people to lock files, and later forget to unlock them, preventing
   1.122 -anyone else from modifying those files without the help of an
   1.123 -administrator.  
   1.124 -
   1.125 -Walter Tichy developed a free alternative to SCCS in the early 1980s;
   1.126 -he called his program RCS (Revison Control System).  Like SCCS, RCS
   1.127 -required developers to work in a single shared workspace, and to lock
   1.128 -files to prevent multiple people from modifying them simultaneously.
   1.129 -
   1.130 -Later in the 1980s, Dick Grune used RCS as a building block for a set
   1.131 -of shell scripts he initially called cmt, but then renamed to CVS
   1.132 -(Concurrent Versions System).  The big innovation of CVS was that it
   1.133 -let developers work simultaneously and somewhat independently in their
   1.134 -own personal workspaces.  The personal workspaces prevented developers
   1.135 -from stepping on each other's toes all the time, as was common with
   1.136 -SCCS and RCS.  Each developer had a copy of every project file, and
   1.137 -could modify their copies independently.  They had to merge their
   1.138 -edits prior to committing changes to the central repository.
   1.139 +
   1.140 +\notebox {
   1.141 +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.142 +
   1.143 +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.144 +aussi son utilisation.
   1.145 +}
   1.146 +
   1.147 +Certains personnes prétendent que ces termes ont en fait des sens
   1.148 +différents mais en pratique ils se recouvrent tellement qu'il n'y a pas
   1.149 +réellement de manière pertinente de les distinguer.
   1.150 +
   1.151 +\section{Une courte histoire de la gestion de source}
   1.152 +
   1.153 +Le plus célèbre des anciens outils de gestion de source est \textit{SCCS (Source
   1.154 +Code Control System)}, que Marc Rochkind conçu dans les laboratoire de recherche de Bell 
   1.155 +(\textit{Bell Labs}), dans le début des années 70. \textit{SCCS} ne fonctionner que sur des fichiers individuels, et demandait à personne travaillant sur le projet d'avoir un accès à un répertoire de travail commun, sur un unique système.
   1.156 +Seulement une 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 ne vérouille
   1.157 +des fichiers, et plus tard, oublie de le dévérouiller; empêchant  n'importe qui d'autre de 
   1.158 +travailler sur ces fichiers sans l'aide de l'administrateur...
   1.159 +
   1.160 +Walter Tichy a développé une alternative libre à \textit{SCCS} au début des années 80, qu'il
   1.161 +nomma \textit{RSC (Revison Control System)}.  Comme \textit{SCCS}, \textit{RCS}
   1.162 +demander aux développeurs de travailler sur le même répertoire partagé, et de vérouiller les
   1.163 +fichiers pour se prémunir de tout conflit issue de modifications concurrentes.
   1.164 +
   1.165 +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.166  
   1.167  Brian Berliner took Grune's original scripts and rewrote them in~C,
   1.168  releasing in 1989 the code that has since developed into the modern