1.1 --- a/fr/ch06-collab.xml	Sat Sep 12 17:58:56 2009 +0200
     1.2 +++ b/fr/ch06-collab.xml	Sun Sep 20 13:09:33 2009 +0200
     1.3 @@ -2,420 +2,449 @@
     1.4  
     1.5  <chapter id="cha:collab">
     1.6    <?dbhtml filename="collaborating-with-other-people.html"?>
     1.7 -  <title>Collaborating with other people</title>
     1.8 -
     1.9 -  <para id="x_44a">As a completely decentralised tool, Mercurial doesn't impose
    1.10 -    any policy on how people ought to work with each other.  However,
    1.11 -    if you're new to distributed revision control, it helps to have
    1.12 -    some tools and examples in mind when you're thinking about
    1.13 -    possible workflow models.</para>
    1.14 +  <title>Collaborer avec d'autres personnes</title>
    1.15 +
    1.16 +  <para id="x_44a">Comme tout outil complètement décentralisé, Mercurial
    1.17 +    n'impose pas de politique sur la façon dont les personnes devraient
    1.18 +    travailler ensemble. Cependant, si vous êtes nouveau dans les systèmes de
    1.19 +    gestion de révisions distribués, cela aide d'avoir des outils et exemples
    1.20 +    en tête lorsque vous réfléchissez à de possibles modèles de
    1.21 +    workflow.</para>
    1.22 +  <!--TODO : workflow peut éventuellement être traduit ici par travail -->
    1.23  
    1.24    <sect1>
    1.25 -    <title>Mercurial's web interface</title>
    1.26 -
    1.27 -    <para id="x_44b">Mercurial has a powerful web interface that provides several
    1.28 -      useful capabilities.</para>
    1.29 -
    1.30 -    <para id="x_44c">For interactive use, the web interface lets you browse a
    1.31 -      single repository or a collection of repositories.  You can view
    1.32 -      the history of a repository, examine each change (comments and
    1.33 -      diffs), and view the contents of each directory and file.  You
    1.34 -      can even get a view of history that gives a graphical view of
    1.35 -      the relationships between individual changes and merges.</para>
    1.36 -
    1.37 -    <para id="x_44d">Also for human consumption, the web interface provides
    1.38 -      Atom and RSS feeds of the changes in a repository.  This lets you
    1.39 -      <quote>subscribe</quote> to a repository using your favorite
    1.40 -      feed reader, and be automatically notified of activity in that
    1.41 -      repository as soon as it happens.  I find this capability much
    1.42 -      more convenient than the model of subscribing to a mailing list
    1.43 -      to which notifications are sent, as it requires no additional
    1.44 -      configuration on the part of whoever is serving the
    1.45 -      repository.</para>
    1.46 -
    1.47 -    <para id="x_44e">The web interface also lets remote users clone a repository,
    1.48 -      pull changes from it, and (when the server is configured to
    1.49 -      permit it) push changes back to it.  Mercurial's HTTP tunneling
    1.50 -      protocol aggressively compresses data, so that it works
    1.51 -      efficiently even over low-bandwidth network connections.</para>
    1.52 -
    1.53 -    <para id="x_44f">The easiest way to get started with the web interface is to
    1.54 -      use your web browser to visit an existing repository, such as
    1.55 -      the master Mercurial repository at <ulink
    1.56 -	url="http://www.selenic.com/repo/hg">http://www.selenic.com/repo/hg</ulink>.</para>
    1.57 -
    1.58 -    <para id="x_450">If you're interested in providing a web interface
    1.59 -      to your own repositories, there are several good ways to do
    1.60 -      this.</para>
    1.61 -
    1.62 -    <para id="x_69d">The easiest and fastest way to get started in an informal
    1.63 -      environment is to use the <command role="hg-cmd">hg
    1.64 -	serve</command> command, which is best suited to short-term
    1.65 -      <quote>lightweight</quote> serving.  See <xref
    1.66 -	linkend="sec:collab:serve"/> below for details of how to use
    1.67 -      this command.</para>
    1.68 -
    1.69 -    <para id="x_69e">For longer-lived repositories that you'd like to
    1.70 -      have permanently available, there are several public hosting
    1.71 -      services available.  Some are free to open source projects,
    1.72 -      while others offer paid commercial hosting.  An up-to-date list
    1.73 -      is available at <ulink
    1.74 -	url="http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting">http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting</ulink>.</para>
    1.75 -
    1.76 -    <para id="x_6a0">If you would prefer to host your own repositories, Mercurial
    1.77 -      has built-in support for several popular hosting technologies,
    1.78 -      most notably CGI (Common Gateway Interface), and WSGI (Web
    1.79 -      Services Gateway Interface).  See <xref
    1.80 -	linkend="sec:collab:cgi"/> for details of CGI and WSGI
    1.81 -      configuration.</para>
    1.82 +    <title>Interface web de Mercurial</title>
    1.83 +
    1.84 +    <para id="x_44b">Mercurial possède une interface web puissante qui
    1.85 +      propose plusieurs capacités utiles.</para>
    1.86 +
    1.87 +    <para id="x_44c">Pour une utilisation intensive, l'interface web vous
    1.88 +      permet de naviguer dans un ou une collection de dépôt. Vous pouvez voir
    1.89 +      l'historique d'un dépôt, examiner chaque modification (commentaires et
    1.90 +      "diffs"), et voir le contenu de chaque répertoire et fichier. Vous
    1.91 +      pouvez même accéder à une vue de l'historique qui vous donne une vue
    1.92 +      graphique de la relation entre les modifications individuelles et les
    1.93 +      fusions (merge).</para>
    1.94 +
    1.95 +    <para id="x_44d">De plus, pour la consommation humaine, l'interface web
    1.96 +      fournit des flux Atom et RSS des changements dans un dépôt. Ceci vous
    1.97 +      permet de <quote>souscrire</quote> à un dépôt en utilisant votre
    1.98 +      lecteur de flux favori, et être automatiquement avertis de l'activité
    1.99 +      dans ce dépôt aussi tôt qu'elle change. Je trouve cette fonctionnalité
   1.100 +      bien plus commode que le modèle qui consiste à souscrire à une mailing
   1.101 +      list à laquelle les avertissements sont envoyés, puisque cela demande
   1.102 +      aucune configuration supplémentaire de la part de la personne qui
   1.103 +      publie un dépôt.</para>
   1.104 +
   1.105 +    <para id="x_44e">L'interface web permet aussi aux utilisateurs distants
   1.106 +      de cloner un dépôt, récupérer (pull) les changement à partir de celui
   1.107 +      ci, et (lorsque le serveur est configuré pour l'autoriser) lui envoyer
   1.108 +      (push) des changements. Le protocole de tunnel HTTP de Mercurial
   1.109 +      compresse agressivement les données, ainsi, il fonctionne efficacement,
   1.110 +      même au dessus des réseaux avec une bande passante faible.</para>
   1.111 +
   1.112 +    <para id="x_44f">La plus simple façon de démarrer avec l'interface
   1.113 +      utilisateur est d'utiliser votre navigateur web pour visiter un dépôt
   1.114 +      existant, tel que le dépôt principal de Mercurial à l'adresse <ulink
   1.115 +        url="http://www.selenic.com/repo/hg">http://www.selenic.com/repo/hg</ulink>.</para>
   1.116 +
   1.117 +    <para id="x_450">Si vous êtes intéressés pour proposer une interface web
   1.118 +      de vos propres dépôts, il y a plusieurs façons de le faire.</para>
   1.119 +    
   1.120 +    <para id="x_69d">La façon la plus simple et la plus rapide pour commencer
   1.121 +      dans un environnement informel est d'utiliser la commande <command
   1.122 +        role="hg-cmd">hg serve</command> qui est la plus adaptée à un service
   1.123 +      à court terme et <quote>léger</quote>. Référez vous à <xref
   1.124 +        linkend="sec:collab:serve"/> plus pas pour les détails d'utilisation
   1.125 +      de cette commande.</para>
   1.126 +
   1.127 +    <para id="x_69e">Pour des dépôts dont la durée de vie est plus longue, où
   1.128 +      vous voudriez un service accessible en permanence, il existe plusieurs
   1.129 +      services publics d'hébergement qui sont accessibles. Certains sont
   1.130 +      libres et gratuits pour les projets Open Source, alors que d'autres
   1.131 +      offrent un hébergement commercial et payant. Une lise à jour est
   1.132 +      disponible à l'adresse : <ulink
   1.133 +        url="http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting">http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting</ulink>.</para>
   1.134 +
   1.135 +    <para id="x_6a0">Si vous préférez héberger vos propres dépôts, Mercurial
   1.136 +      possède un support intégré pour plusieurs technologies pupulaires
   1.137 +      d'hébergement, plus particulièrement CGI (Common Gateway Interface) et
   1.138 +      WSGI (Web Services Gateway Interface). Référez vous à <xref
   1.139 +        linkend="sec:collab:cgi"/> pour des détails sur la configuration CGI
   1.140 +      et WSGI.</para>
   1.141    </sect1>
   1.142  
   1.143    <sect1>
   1.144 -    <title>Collaboration models</title>
   1.145 -
   1.146 -    <para id="x_451">With a suitably flexible tool, making decisions about
   1.147 -      workflow is much more of a social engineering challenge than a
   1.148 -      technical one. Mercurial imposes few limitations on how you can
   1.149 -      structure the flow of work in a project, so it's up to you and
   1.150 -      your group to set up and live with a model that matches your own
   1.151 -      particular needs.</para>
   1.152 -
   1.153 -    <sect2>
   1.154 -      <title>Factors to keep in mind</title>
   1.155 -
   1.156 -      <para id="x_452">The most important aspect of any model that you must keep
   1.157 -	in mind is how well it matches the needs and capabilities of
   1.158 -	the people who will be using it.  This might seem
   1.159 -	self-evident; even so, you still can't afford to forget it for
   1.160 -	a moment.</para>
   1.161 -
   1.162 -      <para id="x_453">I once put together a workflow model that seemed to make
   1.163 -	perfect sense to me, but that caused a considerable amount of
   1.164 -	consternation and strife within my development team.  In spite
   1.165 -	of my attempts to explain why we needed a complex set of
   1.166 -	branches, and how changes ought to flow between them, a few
   1.167 -	team members revolted.  Even though they were smart people,
   1.168 -	they didn't want to pay attention to the constraints we were
   1.169 -	operating under, or face the consequences of those constraints
   1.170 -	in the details of the model that I was advocating.</para>
   1.171 -
   1.172 -      <para id="x_454">Don't sweep foreseeable social or technical problems under
   1.173 -	the rug. Whatever scheme you put into effect, you should plan
   1.174 -	for mistakes and problem scenarios.  Consider adding automated
   1.175 -	machinery to prevent, or quickly recover from, trouble that
   1.176 -	you can anticipate.  As an example, if you intend to have a
   1.177 -	branch with not-for-release changes in it, you'd do well to
   1.178 -	think early about the possibility that someone might
   1.179 -	accidentally merge those changes into a release branch.  You
   1.180 -	could avoid this particular problem by writing a hook that
   1.181 -	prevents changes from being merged from an inappropriate
   1.182 -	branch.</para>
   1.183 -    </sect2>
   1.184 -
   1.185 -    <sect2>
   1.186 -      <title>Informal anarchy</title>
   1.187 -
   1.188 -      <para id="x_455">I wouldn't suggest an <quote>anything goes</quote>
   1.189 -	approach as something sustainable, but it's a model that's
   1.190 -	easy to grasp, and it works perfectly well in a few unusual
   1.191 -	situations.</para>
   1.192 -
   1.193 -      <para id="x_456">As one example, many projects have a loose-knit group of
   1.194 -	collaborators who rarely physically meet each other.  Some
   1.195 -	groups like to overcome the isolation of working at a distance
   1.196 -	by organizing occasional <quote>sprints</quote>.  In a sprint,
   1.197 -	a number of people get together in a single location (a
   1.198 -	company's conference room, a hotel meeting room, that kind of
   1.199 -	place) and spend several days more or less locked in there,
   1.200 -	hacking intensely on a handful of projects.</para>
   1.201 -
   1.202 -      <para id="x_457">A sprint or a hacking session in a coffee shop are the perfect places to use the
   1.203 -	<command role="hg-cmd">hg serve</command> command, since
   1.204 -	<command role="hg-cmd">hg serve</command> does not require any
   1.205 -	fancy server infrastructure.  You can get started with
   1.206 -	<command role="hg-cmd">hg serve</command> in moments, by
   1.207 -	reading <xref linkend="sec:collab:serve"/> below.  Then simply
   1.208 -	tell the person next to you that you're running a server, send
   1.209 -	the URL to them in an instant message, and you immediately
   1.210 -	have a quick-turnaround way to work together.  They can type
   1.211 -	your URL into their web browser and quickly review your
   1.212 -	changes; or they can pull a bugfix from you and verify it; or
   1.213 -	they can clone a branch containing a new feature and try it
   1.214 -	out.</para>
   1.215 -
   1.216 -      <para id="x_458">The charm, and the problem, with doing things
   1.217 -	in an ad hoc fashion like this is that only people who know
   1.218 -	about your changes, and where they are, can see them.  Such an
   1.219 -	informal approach simply doesn't scale beyond a handful
   1.220 -	people, because each individual needs to know about
   1.221 -	<emphasis>n</emphasis> different repositories to pull
   1.222 -	from.</para>
   1.223 -    </sect2>
   1.224 -
   1.225 -    <sect2>
   1.226 -      <title>A single central repository</title>
   1.227 -
   1.228 -      <para id="x_459">For smaller projects migrating from a centralised revision
   1.229 -	control tool, perhaps the easiest way to get started is to
   1.230 -	have changes flow through a single shared central repository.
   1.231 -	This is also the most common <quote>building block</quote> for
   1.232 -	more ambitious workflow schemes.</para>
   1.233 -
   1.234 -      <para id="x_45a">Contributors start by cloning a copy of this repository.
   1.235 -	They can pull changes from it whenever they need to, and some
   1.236 -	(perhaps all) developers have permission to push a change back
   1.237 -	when they're ready for other people to see it.</para>
   1.238 -
   1.239 -      <para id="x_45b">Under this model, it can still often make sense for people
   1.240 -	to pull changes directly from each other, without going
   1.241 -	through the central repository.  Consider a case in which I
   1.242 -	have a tentative bug fix, but I am worried that if I were to
   1.243 -	publish it to the central repository, it might subsequently
   1.244 -	break everyone else's trees as they pull it.  To reduce the
   1.245 -	potential for damage, I can ask you to clone my repository
   1.246 -	into a temporary repository of your own and test it.  This
   1.247 -	lets us put off publishing the potentially unsafe change until
   1.248 -	it has had a little testing.</para>
   1.249 -
   1.250 -      <para id="x_45c">If a team is hosting its own repository in this
   1.251 -	kind of scenario, people will usually use the
   1.252 -	<command>ssh</command> protocol to securely push changes to
   1.253 -	the central repository, as documented in <xref
   1.254 -	  linkend="sec:collab:ssh"/>.  It's also usual to publish a
   1.255 -	read-only copy of the repository over HTTP, as in
   1.256 -	<xref linkend="sec:collab:cgi"/>. Publishing over HTTP
   1.257 -	satisfies the needs of people who don't have push access, and
   1.258 -	those who want to use web browsers to browse the repository's
   1.259 -	history.</para>
   1.260 -    </sect2>
   1.261 -
   1.262 -    <sect2>
   1.263 -      <title>A hosted central repository</title>
   1.264 -
   1.265 -      <para id="x_6a1">A wonderful thing about public hosting services like
   1.266 -	<ulink url="http://bitbucket.org/">Bitbucket</ulink> is that
   1.267 -	not only do they handle the fiddly server configuration
   1.268 -	details, such as user accounts, authentication, and secure
   1.269 -	wire protocols, they provide additional infrastructure to make
   1.270 -	this model work well.</para>
   1.271 -
   1.272 -      <para id="x_6a2">For instance, a well-engineered hosting service will let
   1.273 -	people clone their own copies of a repository with a single
   1.274 -	click.  This lets people work in separate spaces and share
   1.275 -	their changes when they're ready.</para>
   1.276 -
   1.277 -      <para id="x_6a3">In addition, a good hosting service will let people
   1.278 -	communicate with each other, for instance to say <quote>there
   1.279 -	  are changes ready for you to review in this
   1.280 -	  tree</quote>.</para>
   1.281 -    </sect2>
   1.282 -
   1.283 -    <sect2>
   1.284 -      <title>Working with multiple branches</title>
   1.285 -
   1.286 -      <para id="x_45d">Projects of any significant size naturally tend to make
   1.287 -	progress on several fronts simultaneously.  In the case of
   1.288 -	software, it's common for a project to go through periodic
   1.289 -	official releases.  A release might then go into
   1.290 -	<quote>maintenance mode</quote> for a while after its first
   1.291 -	publication; maintenance releases tend to contain only bug
   1.292 -	fixes, not new features.  In parallel with these maintenance
   1.293 -	releases, one or more future releases may be under
   1.294 -	development.  People normally use the word
   1.295 -	<quote>branch</quote> to refer to one of these many slightly
   1.296 -	different directions in which development is
   1.297 -	proceeding.</para>
   1.298 -
   1.299 -      <para id="x_45e">Mercurial is particularly well suited to managing a number
   1.300 -	of simultaneous, but not identical, branches.  Each
   1.301 -	<quote>development direction</quote> can live in its own
   1.302 -	central repository, and you can merge changes from one to
   1.303 -	another as the need arises.  Because repositories are
   1.304 -	independent of each other, unstable changes in a development
   1.305 -	branch will never affect a stable branch unless someone
   1.306 -	explicitly merges those changes into the stable branch.</para>
   1.307 -
   1.308 -      <para id="x_45f">Here's an example of how this can work in practice.  Let's
   1.309 -	say you have one <quote>main branch</quote> on a central
   1.310 -	server.</para>
   1.311 +    <title>Modèles de collaboration</title>
   1.312 +
   1.313 +    <para id="x_451">Avec un outil convenablement flexible, faire des
   1.314 +      décisions sur les workflow est plus un problème d'ingénierie sociale
   1.315 +      qu'un problème technique. Mercurial n'impose que peu de limitations sur
   1.316 +      la façon dont vous pouvez structurer le flux de travail dans un projet,
   1.317 +      donc, c'est à vous et votre groupe de fixer et vivre avec un modèle qui
   1.318 +      convient à vos besoins particuliers.</para>
   1.319 +
   1.320 +    <sect2>
   1.321 +      <title>Facteurs à garder en tête</title>
   1.322 +
   1.323 +      <para id="x_452">L'aspect le plus important de tout modèle que vous
   1.324 +        devez garder en tête est la façon dont il subvient aux besoins et
   1.325 +        capacités des personnes qui l'utiliseront. Ceci pourrait sembler
   1.326 +        évident en soi ; pourtant, vous ne pouvez pas vous permettre de
   1.327 +        l'oublier à un seul moment.</para>
   1.328 +
   1.329 +      <para id="x_453">Une fois, j'ai mis en place un modèle de workflow qui
   1.330 +        m'apparaissait comme parfait, mais il a causé la consternation et des
   1.331 +        conflits au sein de mon équipe de développement. En dépit de mes
   1.332 +        tentatives pour expliquer pourquoi nous avions besoin d'un ensemble
   1.333 +        complexe de branches, et comment les changements devaient couler
   1.334 +        entre eux, certains membres de l'équipe se révoltèrent. Alors qu'ils
   1.335 +        étaient pourtant des personnes sympathiques, ils ne voulaient pas
   1.336 +        prêter attention aux contraintes sur lesquelles nous étions en train
   1.337 +        d'opérer, ou, face aux conséquences de ces contraintes dans les
   1.338 +        détails du modèle que je préconisais.</para>
   1.339 +
   1.340 +      <para id="x_454">Ne balayez pas les problèmes sociaux ou techniques de
   1.341 +        la main. Quelquesoit le schéma que vous promulguez, vous devriez
   1.342 +        plannifier un protocole pour prévenir, ou rapidement vous relever de
   1.343 +        troubles que vous pouvez anticiper. Par exemple, si vous vous
   1.344 +        attentez à avoir une branche pour les changements pas-pour-release,
   1.345 +        vous devriez penser très tôt sur la possibilité qu'une personne
   1.346 +        fusionne (merge) accidentellement ces changements avec une branche de
   1.347 +        release. Vous pouvez empécher ce problème particulier en écrivant un
   1.348 +        hook qui prévient les changements d'être fusionnés à partir d'une
   1.349 +        branche inapropriée.</para>
   1.350 +    </sect2>
   1.351 +
   1.352 +    <sect2>
   1.353 +      <title>Anarchie informelle</title>
   1.354 +
   1.355 +      <para id="x_455">Je ne voudrais pas suggérer qu'une approche
   1.356 +        <quote>tout peut arriver</quote> comme quelque chose de durable, mais
   1.357 +        il s'agit d'un modèle qui est simple à saisir et qui fonctionne
   1.358 +        parfaitement dans quelques situations inhabituelles.</para>
   1.359 +
   1.360 +      <para id="x_456">Par exemple, beaucoup de projets ont un groupe distant
   1.361 +        de collaborateurs qui ne se rencontre physiquement que très rarement.
   1.362 +        Certains groupes aiment vaincre l'isolation du travail à distance en
   1.363 +        organisant occasionnellement des <quote>sprints</quote>. Dans un
   1.364 +        sprint, le nombre de personne qui viennent ensemble dans un même
   1.365 +        localité (la salle de conférence d'une companie, la salle de réunion
   1.366 +        d'un hotel, ce type d'endroit) et y passe plusieurs jours, plus ou
   1.367 +        moins enfermés, et hackant intensément sur une poignée de
   1.368 +        projets.</para>
   1.369 +
   1.370 +      <para id="x_457">Un "sprint" ou une session de "hacking" dans un café
   1.371 +        sont les endroits parfaits pour utiliser la commande <command
   1.372 +          role="hg-cmd">hg serve</command> puisque <command role="hg-cmd">hg
   1.373 +          serve</command> n'a pas besoin d'une infrastructure extraordinaire
   1.374 +        de serveurs. Vous pouvez commencer avec la commande <command
   1.375 +          role="hg-cmd">hg serve</command> en un moment, en lisant <xref
   1.376 +          linkend="sec:collab:serve"/> plus bas  Ensuite, dites simplement à
   1.377 +        la personne à coté de vous que vous exécutez un serveur, envoyez lui
   1.378 +        l'URL par un message instantané, et vous avez immédiatement un moyen
   1.379 +        simple et rapide de travailler ensemble. Ils peuvent taper votre URL
   1.380 +        dans leur navigateur web et rapidement avoir une revue des
   1.381 +        changements ; ou ils peuvent récupérer chez vous un bugfix et le
   1.382 +        vérifier ; ou ils peuvent cloner une branche contenant une nouvelle
   1.383 +        fonctionnalité et la tester.</para>
   1.384 +        
   1.385 +      <para id="x_458">Le charme et le problème en faisant les choses ainsi,
   1.386 +        dans une mode ad-hoc est que seules les personnes qui sont au courant
   1.387 +        de vos changements, et de leur emplacement, peuvent les voir. Une
   1.388 +        telle approche informelle ne passe simplement pas à l'échelle au delà
   1.389 +        d'une poignée de personnes, puisque chacun a besoin de connaître
   1.390 +        <emphasis>n</emphasis> différents dépôts à partir des quels récupérer
   1.391 +        les changements (pull).</para>
   1.392 +    </sect2>
   1.393 +
   1.394 +    <sect2>
   1.395 +      <title>Un simple dépôt central</title>
   1.396 +
   1.397 +      <para id="x_459">Pour de plus petits projets qui migrent depuis un
   1.398 +        outil de gestion de révision centralisé, la façon la
   1.399 +        plus simple de commencer est certainement d'avoir un flux de
   1.400 +        changement à partir d'un unique dépôt central. Il s'agit aussi du
   1.401 +        <quote>bloc de construction</quote> pour des schémas de workflow plus
   1.402 +        ambitieux.</para>
   1.403 +
   1.404 +      <para id="x_45a">Les contributeurs commencent par cloner une copie de
   1.405 +        ce dépôt. Ils peuvent récupérer les changements à n'importe quel
   1.406 +        moment où ils en ressentent le besoin, et certains (sûrement tous)
   1.407 +        développeurs ont les persmissions qui leur permettent d'envoyer leurs
   1.408 +        modifications (push) en retour lorsqu'elles sont prêtes pour que les
   1.409 +        autres personnes puissent les voir.</para>
   1.410 +
   1.411 +      <para id="x_45b">Dans ce modèle, il peut encore être sensé pour les
   1.412 +        gens de récupérer les changements directement entre eux, sans passer
   1.413 +        par le dépôt central. Considérez le cas où j'ai une tentative de bug
   1.414 +        fix, mais je m'inquiète de savoir si, dans le cas où je la publiais,
   1.415 +        cela ne casserait pas l'arbre des autres contributeurs s'ils la
   1.416 +        récupèrerais. Pour réduire les dommages potentiels, je peux vous
   1.417 +        demander de cloner mon dépôt dans un dépôt temporaire qui vous
   1.418 +        appartient et de le tester. Ceci nous permet de ne pas publier les
   1.419 +        modification potentiellement dangereuses tant qu'elles n'ont pas
   1.420 +        encore été un peu testées.</para>
   1.421 +
   1.422 +      <para id="x_45c">Si une équipe héberge son propre dépôt dans ce type de
   1.423 +        scénario, les personnes qui utilisent habituellement le protocole
   1.424 +        <command>ssh</command> pour envoyer (push) en toute sécurité leurs
   1.425 +        changements au dépôt central, comme docummenté dans <xref
   1.426 +          linkend="sec:collab:ssh"/>. Il est aussi usuel de publier une copie
   1.427 +        en lecture seule du dépôt sur HTTP comme dans <xref
   1.428 +          linkend="sec:collab:cgi"/>. Publier sur HTTP satisfait le besoin
   1.429 +        des personnes qui n'ont pas d'accès en écriture, et ceux qui veulent
   1.430 +        utiliser leur navigateur web pour explorer l'historique du
   1.431 +        dépôt.</para>
   1.432 +    </sect2>
   1.433 +
   1.434 +    <sect2>
   1.435 +      <title>Un dépôt central hébergé</title>
   1.436 +
   1.437 +      <para id="x_6a1">Une chose magnifique au sujet des services
   1.438 +        d'hébergement comme <ulink
   1.439 +          url="http://bitbucket.org/">Bitbucket</ulink> est qu'ils ne font
   1.440 +        pas seulement gérer les détails minutieux de la configuration du
   1.441 +        serveur, tels que les comptes utilisateur, l'authentification, les
   1.442 +        protocoles sécurisés, ils fournissent aussi une infrastructure
   1.443 +        additionnelle pour faire en sorte que ce modèle fonctionne
   1.444 +        bien.</para>
   1.445 +
   1.446 +      <para id="x_6a2">Par exemple, un service d'hébergement bien conçu
   1.447 +        laissera les personnes cloner leurs copies d'un dépôt à l'aide d'un
   1.448 +        simple click. Ceci laisse les personnes travailler dans des espaces
   1.449 +        séparés et partager leurs changements lorsqu'ils sont prêts.</para>
   1.450 +
   1.451 +      <para id="x_6a3">De plus, un bon service d'hébergement laissera les
   1.452 +        personnes communiquer ensemble, par exemple pour dire <quote>Il y a
   1.453 +          des changements prêts pour toi pour relecture dans cet
   1.454 +          arbre</quote>.</para>
   1.455 +        
   1.456 +    </sect2>
   1.457 +
   1.458 +    <sect2>
   1.459 +      <title>Travailler avec plusieurs branches</title>
   1.460 +
   1.461 +      <para id="x_45d">Les projets d'une taille significative ont tendance à
   1.462 +        avancer sur plusieurs fronts en même temps. Dans le cas de logiciel,
   1.463 +        il est commun qu'un projet sorte périodiquement des releases
   1.464 +        officielles. Une release devrait ensuite aller dans le <quote>mode de
   1.465 +          maintenance</quote> pour un moment après sa première publication ;
   1.466 +        les releases de maintenance tendent à contenir seulement des
   1.467 +        corrections de bugs, et non de nouvelles fonctionnalités. En
   1.468 +        parallèle de ces releases de maintenance, une ou plusieurs futures
   1.469 +        releases doivent être en cours de développement. Les gens utilisent
   1.470 +        en général le mot <quote>branche</quote> pour référer à l'une de ces
   1.471 +        nombreuses directions légèrement différentes dans lesquelles le
   1.472 +        développement évolue.</para>
   1.473 +
   1.474 +      <para id="x_45e">Mercurial est particulièrement bien adapté pour gérer
   1.475 +        plusieurs branches simultanées mais non identiques. Chaque
   1.476 +        <quote>direction de développement</quote> peut vivre dans son propre
   1.477 +        dépôt central, et vous pouvez récupérez les changements de l'un ou
   1.478 +        l'autre lorsque le besoin s'en fait sentir. Parce que les dépôts sont
   1.479 +        indépendant les un des autres, les modifications instables dans une
   1.480 +        branche de développement n'affecteront jamais une branche stable,
   1.481 +        sauf si quelqu'un fusionne (merge) explicitement ces changements dans
   1.482 +        la branche stable.</para>
   1.483 +
   1.484 +      <para id="x_45f">Voici un exemple sur comment cela peut se passer en
   1.485 +        pratique. Disons que vous avez une <quote>branche principale</quote>
   1.486 +        sur un serveur central.</para>
   1.487  
   1.488        &interaction.branching.init;
   1.489  
   1.490 -      <para id="x_460">People clone it, make changes locally, test them, and push
   1.491 -	them back.</para>
   1.492 -
   1.493 -      <para id="x_461">Once the main branch reaches a release milestone, you can
   1.494 -	use the <command role="hg-cmd">hg tag</command> command to
   1.495 -	give a permanent name to the milestone revision.</para>
   1.496 -
   1.497 -	&interaction.branching.tag;
   1.498 -
   1.499 -      <para id="x_462">Let's say some ongoing
   1.500 -	development occurs on the main branch.</para>
   1.501 +      <para id="x_460">Les contributeurs le clonent, y apportent localement
   1.502 +        des modifications, les testent et envoient (push) en retour leurs
   1.503 +        changements.</para>
   1.504 +
   1.505 +      <para id="x_461">Une fois que la branche principale atteint une étape
   1.506 +        assez importante pour une release, vous pouvez utiliser la commande
   1.507 +        <command role="hg-cmd">hg tag</command> pour donner un nom permanent
   1.508 +        à cette étape de révision.</para>
   1.509 +    
   1.510 +      &interaction.branching.tag;
   1.511 +
   1.512 +      <para id="x_462">Disons que du developpement continue a lieu sur la
   1.513 +        branche principale.</para>
   1.514  
   1.515        &interaction.branching.main;
   1.516  
   1.517 -      <para id="x_463">Using the tag that was recorded at the milestone, people
   1.518 -	who clone that repository at any time in the future can use
   1.519 -	<command role="hg-cmd">hg update</command> to get a copy of
   1.520 -	the working directory exactly as it was when that tagged
   1.521 -	revision was committed.</para>
   1.522 +      <para id="x_463">En utilisant le tag qui enregistre l'étape importante,
   1.523 +        les gens qui clonenent ce dépôt peuvent à tout moment dans le futur
   1.524 +        utiliser la commande <command role="hg-cmd">hg update</command> pour
   1.525 +        avoir une copie du répertoire de travail exactement comme il était
   1.526 +        lorsque cette révision "tag" a été committée.</para>
   1.527  
   1.528        &interaction.branching.update;
   1.529  
   1.530 -      <para id="x_464">In addition, immediately after the main branch is tagged,
   1.531 -	we can then clone the main branch on the server to a new
   1.532 -	<quote>stable</quote> branch, also on the server.</para>
   1.533 +      <para id="x_464">De plus, immédiatement après que la branche principale
   1.534 +        soit taggée, nous pouvons maintenant cloner la branche principale sur
   1.535 +        le serveur vers une nouvelle branche <quote>stable</quote> sur le
   1.536 +        même serveur.</quote>
   1.537  
   1.538        &interaction.branching.clone;
   1.539  
   1.540 -      <para id="x_465">If we need to make a change to the stable
   1.541 -	branch, we can then clone <emphasis>that</emphasis>
   1.542 -	repository, make our changes, commit, and push our changes
   1.543 -	back there.</para>
   1.544 +      <para id="x_465">Si nous avons besoin d'effectuer des modifications à
   1.545 +        la branche stable, nous pouvons alors cloner <emphasis>ce</emphasis>
   1.546 +        dépôt, effectuer nos modifications, committer, et envoyer nos
   1.547 +        changements en retour là bas.</para>
   1.548  
   1.549        &interaction.branching.stable;
   1.550  
   1.551 -      <para id="x_466">Because Mercurial repositories are independent, and
   1.552 -	Mercurial doesn't move changes around automatically, the
   1.553 -	stable and main branches are <emphasis>isolated</emphasis>
   1.554 -	from each other.  The changes that we made on the main branch
   1.555 -	don't <quote>leak</quote> to the stable branch, and vice
   1.556 -	versa.</para>
   1.557 -
   1.558 -      <para id="x_467">We'll often want all of our bugfixes on the stable
   1.559 -	branch to show up on the main branch, too.  Rather than
   1.560 -	rewrite a bugfix on the main branch, we can simply pull and
   1.561 -	merge changes from the stable to the main branch, and
   1.562 -	Mercurial will bring those bugfixes in for us.</para>
   1.563 +      <para id="x_466">Puisque les dépôts Mercurial sont indépendants, et que
   1.564 +        Mercurial ne déplace pas les changements automatiquement, les
   1.565 +        branches stable et principale sont <emphasis>isolées</emphasis> l'une
   1.566 +        de l'autre. Les changements qui sont faits à la branche principale ne
   1.567 +        <quote>fuient</quote> pas vers la branche stable, et vice
   1.568 +        versa.</para>
   1.569 +
   1.570 +      <para id="x_467">Nous allons souvent avoir envie que toutes nos
   1.571 +        correction de bugs sur la branche stable soient reportées sur la
   1.572 +        branche principale. Plutôt que de réécrire une correction de bug pour
   1.573 +        la branche principale, nous pouvons simplement récupérer (pull) et
   1.574 +        fusionner (merge) les changements de la branche stable vers la
   1.575 +        branche principal, et Mercurial se débrouillera pour rapporter ces
   1.576 +        corrections de bugs pour nous.</para>
   1.577  
   1.578        &interaction.branching.merge;
   1.579  
   1.580 -      <para id="x_468">The main branch will still contain changes that
   1.581 -	are not on the stable branch, but it will also contain all of
   1.582 -	the bugfixes from the stable branch.  The stable branch
   1.583 -	remains unaffected by these changes, since changes are only
   1.584 -	flowing from the stable to the main branch, and not the other
   1.585 -	way.</para>
   1.586 +      <para id="x_468">La branche principale contiendra toujours des
   1.587 +        changements qui ne sont pas dans la branche stable, mais elle
   1.588 +        contiendra aussi les corrections de bugs de la branche stable. La
   1.589 +        branche stable restera non affectée par ces changements, tant qu'ils
   1.590 +        coulent de la branche stable vers la branche principale, et non dans
   1.591 +        l'autre sens.</para>
   1.592      </sect2>
   1.593  
   1.594      <sect2>
   1.595        <title>Feature branches</title>
   1.596  
   1.597 -      <para id="x_469">For larger projects, an effective way to manage change is
   1.598 -	to break up a team into smaller groups.  Each group has a
   1.599 -	shared branch of its own, cloned from a single
   1.600 -	<quote>master</quote> branch used by the entire project.
   1.601 -	People working on an individual branch are typically quite
   1.602 -	isolated from developments on other branches.</para>
   1.603 +      <para id="x_469">Pour de plus gros projets, une façon efficace de gérer
   1.604 +        les changements est de casser l'équipe en plus pettis groupes. Chaque
   1.605 +        groupe a une branche partagée qui lui est attitrée, clonée à partir
   1.606 +        d'une unique branche <quote>principale</quote> utilisée pour le
   1.607 +        projet entier. Les personnes travaillant sur une branche individuelle
   1.608 +        sont typiquement isolées des développements sur les autres
   1.609 +        branches.</para>
   1.610  
   1.611        <figure id="fig:collab:feature-branches">
   1.612 -	<title>Feature branches</title>
   1.613 -	<mediaobject>
   1.614 -	  <imageobject><imagedata width="100%" fileref="figs/feature-branches.png"/></imageobject>
   1.615 -	  <textobject><phrase>XXX add text</phrase></textobject>
   1.616 -	</mediaobject>
   1.617 +        <title>Feature branches</title>
   1.618 +        <mediaobject>
   1.619 +          <imageobject><imagedata width="100%" fileref="figs/feature-branches.png"/></imageobject>
   1.620 +          <textobject><phrase>XXX add text</phrase></textobject>
   1.621 +        </mediaobject>
   1.622        </figure>
   1.623  
   1.624 -      <para id="x_46b">When a particular feature is deemed to be in suitable
   1.625 -	shape, someone on that feature team pulls and merges from the
   1.626 -	master branch into the feature branch, then pushes back up to
   1.627 -	the master branch.</para>
   1.628 -    </sect2>
   1.629 -
   1.630 -    <sect2>
   1.631 -      <title>The release train</title>
   1.632 -
   1.633 -      <para id="x_46c">Some projects are organized on a <quote>train</quote>
   1.634 -	basis: a release is scheduled to happen every few months, and
   1.635 -	whatever features are ready when the <quote>train</quote> is
   1.636 -	ready to leave are allowed in.</para>
   1.637 -
   1.638 -      <para id="x_46d">This model resembles working with feature branches.  The
   1.639 -	difference is that when a feature branch misses a train,
   1.640 -	someone on the feature team pulls and merges the changes that
   1.641 -	went out on that train release into the feature branch, and
   1.642 -	the team continues its work on top of that release so that
   1.643 -	their feature can make the next release.</para>
   1.644 -    </sect2>
   1.645 -
   1.646 -    <sect2>
   1.647 -      <title>The Linux kernel model</title>
   1.648 -
   1.649 -      <para id="x_46e">The development of the Linux kernel has a shallow
   1.650 -	hierarchical structure, surrounded by a cloud of apparent
   1.651 -	chaos.  Because most Linux developers use
   1.652 -	<command>git</command>, a distributed revision control tool
   1.653 -	with capabilities similar to Mercurial, it's useful to
   1.654 -	describe the way work flows in that environment; if you like
   1.655 -	the ideas, the approach translates well across tools.</para>
   1.656 -
   1.657 -      <para id="x_46f">At the center of the community sits Linus Torvalds, the
   1.658 -	creator of Linux.  He publishes a single source repository
   1.659 -	that is considered the <quote>authoritative</quote> current
   1.660 -	tree by the entire developer community. Anyone can clone
   1.661 -	Linus's tree, but he is very choosy about whose trees he pulls
   1.662 -	from.</para>
   1.663 -
   1.664 -      <para id="x_470">Linus has a number of <quote>trusted lieutenants</quote>.
   1.665 -	As a general rule, he pulls whatever changes they publish, in
   1.666 -	most cases without even reviewing those changes.  Some of
   1.667 -	those lieutenants are generally agreed to be
   1.668 -	<quote>maintainers</quote>, responsible for specific
   1.669 -	subsystems within the kernel.  If a random kernel hacker wants
   1.670 -	to make a change to a subsystem that they want to end up in
   1.671 -	Linus's tree, they must find out who the subsystem's
   1.672 -	maintainer is, and ask that maintainer to take their change.
   1.673 -	If the maintainer reviews their changes and agrees to take
   1.674 -	them, they'll pass them along to Linus in due course.</para>
   1.675 -
   1.676 -      <para id="x_471">Individual lieutenants have their own approaches to
   1.677 -	reviewing, accepting, and publishing changes; and for deciding
   1.678 -	when to feed them to Linus.  In addition, there are several
   1.679 -	well known branches that people use for different purposes.
   1.680 -	For example, a few people maintain <quote>stable</quote>
   1.681 -	repositories of older versions of the kernel, to which they
   1.682 -	apply critical fixes as needed.  Some maintainers publish
   1.683 -	multiple trees: one for experimental changes; one for changes
   1.684 -	that they are about to feed upstream; and so on.  Others just
   1.685 -	publish a single tree.</para>
   1.686 -
   1.687 -      <para id="x_472">This model has two notable features.  The first is that
   1.688 -	it's <quote>pull only</quote>.  You have to ask, convince, or
   1.689 -	beg another developer to take a change from you, because there
   1.690 -	are almost no trees to which more than one person can push,
   1.691 -	and there's no way to push changes into a tree that someone
   1.692 -	else controls.</para>
   1.693 -
   1.694 -      <para id="x_473">The second is that it's based on reputation and acclaim.
   1.695 -	If you're an unknown, Linus will probably ignore changes from
   1.696 -	you without even responding.  But a subsystem maintainer will
   1.697 -	probably review them, and will likely take them if they pass
   1.698 -	their criteria for suitability. The more <quote>good</quote>
   1.699 -	changes you contribute to a maintainer, the more likely they
   1.700 -	are to trust your judgment and accept your changes.  If you're
   1.701 -	well-known and maintain a long-lived branch for something
   1.702 -	Linus hasn't yet accepted, people with similar interests may
   1.703 -	pull your changes regularly to keep up with your work.</para>
   1.704 -
   1.705 -      <para id="x_474">Reputation and acclaim don't necessarily cross subsystem
   1.706 -	or <quote>people</quote> boundaries.  If you're a respected
   1.707 -	but specialised storage hacker, and you try to fix a
   1.708 -	networking bug, that change will receive a level of scrutiny
   1.709 -	from a network maintainer comparable to a change from a
   1.710 -	complete stranger.</para>
   1.711 -
   1.712 -      <para id="x_475">To people who come from more orderly project backgrounds,
   1.713 -	the comparatively chaotic Linux kernel development process
   1.714 -	often seems completely insane.  It's subject to the whims of
   1.715 -	individuals; people make sweeping changes whenever they deem
   1.716 -	it appropriate; and the pace of development is astounding.
   1.717 -	And yet Linux is a highly successful, well-regarded piece of
   1.718 -	software.</para>
   1.719 -    </sect2>
   1.720 -
   1.721 -    <sect2>
   1.722 -      <title>Pull-only versus shared-push collaboration</title>
   1.723 +      <para id="x_46b">Lorsqu'une fonctionnalité particulière est réputée
   1.724 +        pour être dans une forme adaptée, quelqu'un de l'équipe qui s'occupe
   1.725 +        de cette fonctionnalité récupère les changements (pull) à partir de
   1.726 +        la branche principale vers la branche de cette fonctionnalité,
   1.727 +        fusionne (merge) et renvoie (push) le tout vers la branche
   1.728 +        principale.</para>
   1.729 +    </sect2>
   1.730 +
   1.731 +    <sect2>
   1.732 +      <title>Le train des releases</title>
   1.733 +<!-- J'ai laissé train en traduction à train mais peut être que suite, file,
   1.734 +... sont des mots qui conviennent mieux ? A méditer -->
   1.735 +
   1.736 +      <para id="x_46c">Certains projets sont organisés comme un
   1.737 +        <quote>train</quote> basique : une release est planifiée tous les
   1.738 +        quelques mois, et, toutes les fonctionnalités disponibles lorsque le
   1.739 +        <quote>train</quote> est prêt à s'arrêter sont autorisées ici.
   1.740 +
   1.741 +      <para id="x_46d">Ce modèle ressemble à travailler avec des branches de
   1.742 +        fonctionnalités. La différence est que lorsqu'une branche de
   1.743 +        fonctionnalité rate le train, quelqu'un de l'équipe qui travaille sur
   1.744 +        cette fonctionnalité récupère (pull) et fusionne (merge) ce qui a été
   1.745 +        ajouté à la release du train dans la branche de la fonctionnalité,
   1.746 +        puis, l'équipe continue son travail au dessus de cette release afin
   1.747 +        que leur fonctionnalité puisse être ajoutée à la prochaine
   1.748 +        release.</para>
   1.749 +    </sect2>
   1.750 +
   1.751 +    <sect2>
   1.752 +      <title>Le modèle du Noyau Linux</title>
   1.753 +
   1.754 +      <para id="x_46e">Le développement du noyau Linux est doté d'une
   1.755 +        structure hiérarchique superficielle, entourée par un nuage de chaos
   1.756 +        apparent. Parce que la plupart des développeurs Linux utilisent
   1.757 +        <command>git</command>, un outil distribué de gestion de révisions
   1.758 +        avec des capacités similaires à celles de Mercurial, il est utile de
   1.759 +        décrire comment le travail se déroule dans cet environnement ; si
   1.760 +        vous aimez ces idées, l'approche se traduit correctement à travers
   1.761 +        les outils.</para>
   1.762 +
   1.763 +      <para id="x_46f">Au centre de la communauté siège Linux Torvalds, le
   1.764 +        créateur de Linux. Il publie un unique dépôt de sources qui est
   1.765 +        considéré comme faisant <quote>authorité</quote> sur l'arborescence
   1.766 +        par la communauté entière de développeurs. Tout le monde peut cloner
   1.767 +        l'arbre de Linus, mais il est très difficile d'être choisi pour que
   1.768 +        ses changements soient intégrés à l'arbre principal.</para>
   1.769 +
   1.770 +      <para id="x_470">Linus a plusieurs <quote>leutenants de
   1.771 +          confiance</quote>. Comme règle générale, il récupère (pull) tous
   1.772 +        les changements qu'ils publient, dans la plupart des cas sans même
   1.773 +        relire ces modifications. Certains de ces lieutenants sont
   1.774 +        généralement autorisés à être <quote>mainteneurs</quote>,
   1.775 +        responsables pour un sous-système spécifique du noyau. Si un kernel
   1.776 +        hacker aléatoire veut apporter des modification au sous-système
   1.777 +        qu'ils veut voir intégré à l'arbre de Linus, il doit trouver qui est
   1.778 +        le mainteneur du sous-système, et lui demander de récupérer ses
   1.779 +        changements. Si le mainteneur relit ses changements et les accepte,
   1.780 +        ils seront transmis à Linus le moment venu.</para>
   1.781 +
   1.782 +      <para id="x_471">Les lieutenants individuels ont leur propre approche
   1.783 +        pour relire, accepter et publier les changements ; et pour décider
   1.784 +        quand les apporter à Linus. De plus, il y a plusieurs branches
   1.785 +        connues que les personnes utilisent pour différentes choses.
   1.786 +        Par exemple, quelques personnes maintiennent des dépôts
   1.787 +        <quote>stables</quote> de leurs versions du noyau, pour lesquels ils
   1.788 +        apportent des corrections critiques lorsque nécessaire. Certains
   1.789 +        mainteneurs publient plusieurs arbres : l'un pour les changements
   1.790 +        expérimentaux, l'un pour les changements qu'ils vont faire remonter,
   1.791 +        etc. D'autres ne publient qu'un unique arbre.</para>
   1.792 +
   1.793 +      <para id="x_472">Ce modèle a deux caractéristiques remarquables. La
   1.794 +        première est qu'il s'agit de <quote>pull seulement</quote>. Vous
   1.795 +        devez demander, convaincre, ou mendier au près d'un autre développeur
   1.796 +        pour prendre vos modifications, puiqu'il n'y a vraissemblablement pas
   1.797 +        d'abre où plus d'une personne peut envoyer des changement (push), et
   1.798 +        qu'il n'y a pas de possibilité d'envoyer des changements (push) vers
   1.799 +        un arbre que quelqu'un d'autre contrôle.</para>
   1.800 +
   1.801 +      <para id="x_473">La seconde est que c'est basé sur la réputation et
   1.802 +        l'acclamation. Si vous êtes un inconnu, Linus va probablement ignorer
   1.803 +        vos changement sans même répondre. Cependant, un mainteneur de
   1.804 +        sous-système les relira probablement, et les acceptera sûrement s'ils
   1.805 +        passent ses critaires d'acceptation. Plus vous contriburez du
   1.806 +        <quote>bon</quote> code à un mainteneur, et plus celui ci aura
   1.807 +        confiance en votre jugement pour accepter vos changements. Si vous
   1.808 +        êtes bien connu et maintenez une branche ancienne pour quelque chose
   1.809 +        que Linus n'a pas encore accepté, les gens avec un intérêt similaire
   1.810 +        devraient récupérer vos changements régulièrement pour rester à jour
   1.811 +        vis à vis de votre travail.</para>
   1.812 +
   1.813 +      <para id="x_474">La réputation et l'acclamation ne nécessite pas de
   1.814 +        système croisé ou de limites <quote>personnelles</quote>. Si vous
   1.815 +        êtes respectés mais que vous êtes un hacker spécialisé dans la
   1.816 +        sauvegarde, et que vous tentez de corriger un bug réseau, ce
   1.817 +        changement recevra un examen approfondu de la part du mainteneur
   1.818 +        responsable du réseau comparable à celui d'un total étranger.</para>
   1.819 +
   1.820 +      <para id="x_475">Pour les personnes qui viennent d'un projet dont
   1.821 +        l'arrière plan est plus ordonné, le processus chaotique de
   1.822 +        développement du noyau Linux en comparaison apparaît totalement
   1.823 +        dément. C'est le sujet de bien des caprices d'individualistes ;
   1.824 +        des personnes qui balayent les changements même s'ils croient que
   1.825 +        c'est approprié ; et l'allure du développement de Linux est
   1.826 +        ahurissant. Et pourtant, Linux est un bout de logiciel d'une grande
   1.827 +        réussite et bien considéré.</para>
   1.828 +    </sect2>
   1.829 +<!-- TODO : part 1/4 -->
   1.830 +    <sect2>
   1.831 +      <title>Collaboration pull seulement versus pull partagé</title>
   1.832  
   1.833        <para id="x_476">A perpetual source of heat in the open source community is
   1.834  	whether a development model in which people only ever pull
   1.835 @@ -777,7 +806,7 @@
   1.836  	on (usually 22).  Don't worry about more exotic possibilities
   1.837  	for misconfiguration until you've checked these two
   1.838  	first.</para>
   1.839 -
   1.840 +<!-- TODO : part 2/4 -->
   1.841        <para id="x_4a7">If you're using an authentication agent on the client side
   1.842  	to store passphrases for your keys, you ought to be able to
   1.843  	log into the server without being prompted for a passphrase or
   1.844 @@ -1152,7 +1181,7 @@
   1.845  	  <literal>lighttpd</literal>.</para>
   1.846        </sect3>
   1.847      </sect2>
   1.848 -
   1.849 +<!-- TODO : part 3/4 -->
   1.850      <sect2>
   1.851        <title>Sharing multiple repositories with one CGI script</title>
   1.852  
   1.853 @@ -1557,7 +1586,7 @@
   1.854      </sect2>
   1.855    </sect1>
   1.856  </chapter>
   1.857 -
   1.858 +<!-- TODO : part 4/4 -->
   1.859  <!--
   1.860  local variables: 
   1.861  sgml-parent-document: ("00book.xml" "book" "chapter")