hgbook
changeset 928:c85c4c5bee0b
Work in progress in translating intro.tex
author | Romain PELISSE <romain.pelisse@atosorigin.com> |
---|---|
date | Sun Feb 08 17:01:30 2009 +0100 (2009-02-08) |
parents | d2e041bef460 |
children | 06e65014e3eb |
files | fr/intro.tex |
line diff
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