POSS Chap 3 Part 3
Un article de Framalang Wiki.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Gaelix | GLX | Traduction | Terminé |
| Olivier | OLV | Traduction | Terminé |
| Olivier | OLV | Relecture | Terminé |
| ??? | Validation |
A version control system (or revision control system) is a combination of technologies and practices for tracking and controlling changes to a project's files, in particular to source code, documentation, and Web pages. If you have never used version control before, the first thing you should do is go find someone who has, and get them to join your project. These days, everyone will expect at least your project's source code to be under version control, and probably will not take the project seriously if it doesn't use version control with at least minimal competence.
Un logiciel de gestion de version (ou logiciel de gestion de révision) est la conjugaison de technologies et de bonnes pratiques pour traquer et contrôler les modifications apportées aux fichiers d'un projet, en particulier au code source, à la documentation et aux pages Web. Si vous n'avez jamais utilisé un logiciel de gestion de version, la première chose que vous devriez faire est de trouver quelqu'un qui en a déjà utilisé un et lui faire rejoindre le projet. De nos jours, tout le monde attend au minimum que le code source du projet soit sous la surveillance d'un logiciel de gestion de version et votre projet ne sera pas pris au sérieux s'il n'utilise pas un minimum efficacement un logiciel de gestion de version.
The reason version control is so universal is that it helps with virtually every aspect of running a project: inter-developer communications, release management, bug management, code stability and experimental development efforts, and attribution and authorization of changes by particular developers. The version control system provides a central coordinating force among all of these areas. The core of version control is change management: identifying each discrete change made to the project's files, annotating each change with metadata like the change's date and author, and then replaying these facts to whoever asks, in whatever way they ask. It is a communications mechanism where a change is the basic unit of information.
Les logiciels de gestion de version sont devenus des standards car ils fournissent une assistance dans quasiment chaque domaine d'un projet qui marche : la communication entre développeurs, la gestion des sorties, la gestion des bogues, la stabilité du code, le développement expérimental, les attributions et les autorisations de modification par des développeurs particuliers. La gestion de version vous fournit un contrôle centralisé sur tous ces domaines. Le cœur de la gestion de version est la gestion des modifications : l'identification de chaque petit changement apporté aux fichiers du projet, l'annotation de chaque modification par des méta-données comme la date du changement et son auteur et ensuite la possibilité de ressortir ces données à toute personne les demandant, de quelque manière que ce soit. C'est un mécanisme de communication pour lequel le changement est l'unité de base de l'information.
This section does not discuss all aspects of using a version control system. It's so all-encompassing that it must be addressed topically throughout the book. Here, we will concentrate on choosing and setting up a version control system in a way that will foster cooperative development down the road.
Nous n'aborderons pas tous les aspects de l'utilisation d'un logiciel de gestion de version dans cette partie. Comme la gestion de version englobe beaucoup d'aspects nous l'étudierons au fur et à mesure tout au long du livre. Ici nous allons nous intéresser plus particulièrement au choix et à l'installation d'un logiciel de gestion de version avec comme objectif la promotion du développement coopératif.
Version Control Vocabulary / Vocabulaire de la gestion de version
This book cannot teach you how to use version control if you've never used it before, but it would be impossible to discuss the subject without a few key terms. These terms are useful independently of any particular version control system: they are the basic nouns and verbs of networked collaboration, and will be used generically throughout the rest of this book. Even if there were no version control systems in the world, the problem of change management would remain, and these words give us a language for talking about that problem concisely.
Ce livre ne vous enseignera l'emploi de la gestion de version si vous ne l'avez pas déjà expérimenté auparavant, mais il serait impossible de parler de ce sujet sans quelques termes clés. Ces termes sont utiles, indépendamment de tout système de gestion de version : ce sont les noms et verbes de base de la collaboration en réseau et ils seront employés de manière générique tout au long de ce livre. Même s'il n'existait aucune système de gestion de version, le problème de gestion des modifications serait quand même présent et ces mots nous fournissent un langage pour parler de ce problème de manière concise.
« Version » Versus « Revision » / « Version » contre « Révision »
The word version is sometimes used as a synonym for « revision », but I will not use it that way in this book, because it is too easily confused with « version » in the sense of a version of a piece of software—that is, the release or edition number, as in « Version 1.0 ». However, since the phrase « version control » is already standard, I will continue to use it as a synonym for « revision control » and « change control ».
Le mot version est parfois employé comme un synonyme de « révision », mais je ne l'utiliserai pas de cette manière dans ce livre parce qu'on pourrait le confondre trop facilement avec « version » dans le sens de version d'un logiciel, c'est à dire le numéro de sortie ou d'édition comme dans « Version 1.0 ». Cependant, comme l'expression « gestion de version » est déjà devenue un standard je continuerai à l'utiliser comme un synonyme de « gestion de révision » et « gestion de modification ».
commit / commit
To make a change to the project; more formally, to store a change in the version control database in such a way that it can be incorporated into future releases of the project. « Commit » can be used as a verb or a noun. As a noun, it is essentially synonymous with « change ». For example: « I just committed a fix for the server crash bug people have been reporting on Mac OS X. Jay, could you please review the commit and check that I'm not misusing the allocator there? »
Apporter une modification au projet, ou, plus formellement, enregistrer un changement dans la base de données de gestion de version de telle manière à ce qu'il puisse être ajouté dans une version à venir du projet. « Commit » peut être utilisé comme un verbe ou un nom. En tant que nom il est surtout synonyme de « modification ». Par exemple : « Je viens juste d'enregistrer un correctif pour le bogue de crash de serveur que les gens ont rapporté sur Mac OS X. Jay, pourrais-tu s'il te plaît vérifier le commit et t'assurer que je ne me trompe pas avec l'allocation ? »
log message / messages enregistrés
A bit of commentary attached to each commit, describing the nature and purpose of the commit. Log messages are among the most important documents in any project: they are the bridge between the highly technical language of individual code changes and the more user-oriented language of features, bugfixes, and project progress. Later in this section, we'll look at ways to distribute log messages to the appropriate audiences; also, the section called “Codifying Tradition” in Chapter 6, Communications discusses ways to encourage contributors to write concise and useful log messages.
Quelques commentaires joints à chaque commit, décrivant la nature et le but du commit. Les messages enregistrés font parti des documents les plus importants pour un projet : ils font le lien entre le langage très technique des modifications du code et le langage plus parlant aux utilisateurs qui se rapporte aux fonctionnalités, aux corrections de bogues et à la progression du projet. Par la suite dans cette section nous étudierons les manières de distribuer les messages enregistrés au bon public, de plus, la section nommée « Codifier la tradition » dans la Chapitre 6, Communication, aborde les manières d'encourager les participants à écrire des messages enregistrés concis et utiles.
update / mise à jour
To ask that others' changes (commits) be incorporated into your local copy of the project; that is, to bring your copy « up-to-date ». This is a very common operation; most developers update their code several times a day, so that they know they're running roughly the same thing the other developers are running, and so that if they see a bug, they can be pretty sure it hasn't been fixed already. For example: « Hey, I noticed the indexing code is always dropping the last byte. Is this a new bug? » « Yes, but it was fixed last week—try updating, it should go away. »
Demander que les modifications (commit) des autres soient incorporées dans votre version propre du projet, c'est à dire, mettre votre copie à jour. C'est une opération de routine, la plupart des développeurs mettent à jour leur code plusieurs fois par jour. Comme cela, ils savent qu'ils utilisent plus ou moins la même chose que les autres développeurs et donc s'ils détectent un bogue il y a peu de chance qu'il ait été corrigé déjà. Par exemple : « Salut, j'ai remarqué que le code d'indexation oublie toujours le dernier nombre. Est-ce un nouveau bogue ? » « Oui, mais il a été réparé la semaine dernière, fais une mise à jour, il devrait disparaître. »
repository / dépôt
A database in which changes are stored. Some version control systems are centralized: there is a single, master repository, which stores all changes to the project. Others are decentralized: each developer has his own repository, and changes can be swapped back and forth between repositories arbitrarily. The version control system keeps track of dependencies between changes, and when it's time to make a release, a particular set of changes is approved for that release. The question of whether centralized or decentralized is better is one of the enduring holy wars of software development; try not to fall into the trap of arguing about it on your project lists.
Une base de données au sein de laquelle les modifications sont stockées. Certains logiciels de gestion de version sont centralisés : il y a un unique dépôt maître qui conserve toutes les modifications du projet. D'autres sont décentralisés : chaque développeur possède son propre dépôt et les modifications peuvent être partagées entre les dépôts de manière arbitraire. Le logiciel de gestion de version conserve un suivi des dépendances entre les modifications et quand il est temps de faire une nouvelle version, un ensemble particulier de modifications est approuvé pour la sortie. Quant à savoir quel système est le meilleur, centralisé ou décentralisé... Cette question est l'une des vieilles guerres du développement de logiciel, essayez de ne pas vous laisser entraîner dans ce débat dans l'une des listes du projet.
checkout / retrait
The process of obtaining a copy of the project from a repository.
A checkout usually produces a directory tree called a « working copy » (see below), from which changes may be committed back to the original repository. In some decentralized version control systems, each working copy is itself a repository, and changes can be pushed out to (or pulled into) any repository that's willing to accept them.L'obtention d'une copie du projet depuis le dépôt.
Un retrait produit en général une arborescence de répertoires appelée une « copie de travail » (voir ci-dessous), depuis lequel des changements peuvent être intégrés au dépôt originel. Pour certains logiciels de gestion de version décentralisés, chaque copie de travail est elle même un dépôt et les modifications peuvent être envoyées (ou aspirées) vers les dépôts qui veulent les accepter.working copy / copie de travail
A developer's private directory tree containing the project's source code files, and possibly its Web pages or other documents. A working copy also contains a little bit of metadata managed by the version control system, telling the working copy what repository it comes from, what « revisions » (see below) of the files are present, etc. Generally, each developer has his own working copy, in which he makes and tests changes, and from which he commits.
L' arborescence personnelle d'un développeur contient les fichiers du code source du projet et il peut également contenir les pages Web et d'autres documents. Une copie de travail contient également quelques méta-données prises en charge par le logiciel de gestion de version, indiquant à la copie de travail de quel dépôt elle provient, quelles « révisions » (voir ci-dessous) des fichiers sont présentes, etc. Généralement, chaque développeur possède sa propre copie de travail dans laquelle il fait et test les modifications et à partir de laquelle il commit.
revision, change, changeset / révision, modification et ensemble de modifications
A « revision » is usually one specific incarnation of a particular file or directory. For example, if the project starts out with revision 6 of file F, and then someone commits a change to F, this produces revision 7 of F. Some systems also use « revision », « change », or « changeset » to refer to a set of changes committed together as one conceptual unit.
Une « révision » est en général une incarnation précise d'un fichier ou dossier particulier. Par exemple, si le projet commence avec la révision 6 du fichier F et qu'ensuite quelqu'un modifie F on parlera alors de la révision 7 de F. Certains systèmes parlent aussi de « révision », « modification » ou « ensemble de modifications » pour se référer à un ensemble de modifications ajoutées en même temps comme une unité conceptuelle.
These terms occasionally have distinct technical meanings in different version control systems, but the general idea is always the same: they give a way to speak precisely about exact points in time in the history of a file or a set of files (say, immediately before and after a bug is fixed). For example: « Oh yes, she fixed that in revision 10 » or « She fixed that in revision 10 of foo.c. »
Ces termes ont parfois une signification technique distincte selon le logiciel de gestion de version, mais l'idée générale est toujours la même : ils fournissent un moyen de parler précisément d'un point précis dans l'histoire d'un fichier ou d'un ensemble de fichier (par exemple : immédiatement avant ou après qu'un bogue est corrigé). Par exemple : « Ah oui, elle a corrigé cela dans la révision 10 » ou « Elle a corrigé cela dans la révision 10 de foo.c. »
When one talks about a file or collection of files without specifying a particular revision, it is generally assumed that one means the most recent revision(s) available.
Quand quelqu'un parle d'un fichier ou d'un ensemble de fichiers sans préciser une révision particulière, on comprend généralement qu'il parle de la révision la plus récente.
diff / diff
A textual representation of a change. A diff shows which lines were changed and how, plus a few lines of surrounding context on either side. A developer who is already familiar with some code can usually read a diff against that code and understand what the change did, and even spot bugs.
Une représentation textuelle d'une modification. Un diff montre quelles lignes ont été modifiées et comment avec en plus quelques lignes de contexte d'un côté ou de l'autre. Un développeur déjà familier avec le code peut en général lire un diff à côté de ce code pour comprendre l'impact des modifications et même détecter des bogues.
tag / mot-clé
A label for a particular collection of files at specified revisions. Tags are usually used to preserve interesting snapshots of the project. For example, a tag is usually made for each public release, so that one can obtain, directly from the version control system, the exact set of files/revisions comprising that release. Common tag names are things like Release_1_0, Delivery_00456, etc.
Une étiquette pour un ensemble de fichiers donnés à une révision donnée. Les mots-clés sont en général utilisés pour résumer les idées majeurs du projet. Par exemple, un mot-clé est généralement utilisé pour chaque sortie publique afin qu'on puisse obtenir, directement depuis le logiciel de gestion de version, l'ensemble exact des fichiers/révisions compris dans cette version. Des mots-clés courants sont Release-1-0, Delivery_00456, etc.
branch / branche
A copy of the project, under version control but isolated, so that changes made to the branch don't affect the rest of the project, and vice versa, except when changes are deliberately « merged » from one side to the other (see below). Branches are also known as « lines of development ». Even when a project has no explicit branches, development is still considered to be happening on the « main branch », also known as the « main line » or « trunk ».
Une copie du projet, sous gestion de version mais isolée, afin que les modifications dans cette branche n'affectent pas le reste du projet et vice-versa, sauf quand les modifications sont « fusionnées » volontairement dans un sens ou l'autre (voir plus bas). Les branches sont aussi connues sous le nom de « lignes de développement ». Même quand un projet n'a pas explicitement de branches, on considère toujours que le développement se fait sur la « branche principale », également connue sous le nom de « ligne principale » ou « tronc ».
Branches offer a way to isolate different lines of development from each other. For example, a branch can be used for experimental development that would be too destabilizing for the main trunk. Or conversely, a branch can be used as a place to stabilize a new release. During the release process, regular development would continue uninterrupted in the main branch of the repository; meanwhile, on the release branch, no changes are allowed except those approved by the release managers. This way, making a release needn't interfere with ongoing development work. See the section called “Use branches to avoid bottlenecks” later in this chapter for a more detailed discussion of branching.
Les branches offrent la possibilité d'isoler différentes lignes de développement les unes des autres. Par exemple, une branche peut être employée pour faire du développement expérimental qui serait trop déstabilisant pour le tronc principal. Ou à l'inverse, une branche peut être utilisée pour stabiliser une nouvelle version. Au cours du processus de sortie, le développement normal continue sans interruption dans la branche principale du dépôt tandis que dans la branche de sortie aucun changement n'est accepté sauf ceux approuvés par les responsables parution. Ainsi, la conception de la nouvelle version n'interfère pas avec le travail de développement en cours. Voir la section « Utilisez les branches pour éviter les embouteillages » plus loin dans ce chapitre pour une discussion plus détaillée à propos des branches.
merge (a.k.a. port) / fusion (ou port)
To move a change from one branch to another. This includes merging from the main trunk to some other branch, or vice versa. In fact, those are the most common kinds of merges; it is rare to port a change between two non-main branches. See the section called “Singularity of information” for more about this kind of merging.
Transférer une modification d'une branche à une autre. Cela englobe la fusion du tronc principal vers d'autres branches ou vice-versa. En fait, ce sont les types de fusion les plus courants, il est rare de porter une modification entre deux branches secondaires. Voir la section appelée « Unicité de l'information » pour en savoir plus sur ce type de fusion.
"Merge » has a second, related meaning: it is what the version control system does when it sees that two people have changed the same file but in non-overlapping ways. Since the two changes do not interfere with each other, when one of the people updates their copy of the file (already containing their own changes), the other person's changes will be automatically merged in. This is very common, especially on projects where multiple people are hacking on the same code. When two different changes do overlap, the result is a « conflict"; see below.
« Fusion » a un deuxième sens proche : c'est ce que fait le logiciel de gestion de version quand il voit que deux personnes ont modifié le même fichier à des endroits différents. Puisque les deux modifications n'interfèrent pas entre elles, quand l'une des personnes met à jour sa copie du fichier (contenant déjà ses propres changements), les modifications de l'autre personne seront automatiquement fusionnées. C'est très courant, particulièrement dans les projets où plusieurs personnes travaillent sur le même code. Quand deux modifications différentes se chevauchent il en résulte un « conflit », voir ci-dessous.
conflict / conflit
What happens when two people try to make different changes to the same place in the code. All version control systems automatically detect conflicts, and notify at least one of the humans involved that their changes conflict with someone else's. It is then up to that human to resolve the conflict, and to communicate that resolution to the version control system.
C'est ce qui se passe quand deux personnes tentent de faire des changements au même endroit du code. Tous les systèmes de gestion de version détectent automatiquement les conflits et avertissent au moins l'un des humains responsable de ces modifications entrant en conflit avec celles d'un autre. C'est alors à l'humain de régler le conflit et d'envoyer la résolution au logiciel de gestion de version.
lock / verrouiller
A way to declare an exclusive intent to change a particular file or directory. For example, « I can't commit any changes to the Web pages right now. It seems Alfred has them all locked while he fixes their background images. » Not all version control systems even offer the ability to lock, and of those that do, not all require the locking feature to be used. This is because parallel, simultaneous development is the norm, and locking people out of files is (usually) contrary to this ideal.
Une manière de se réserver les modifications sur un fichier ou un dossier particulier. Par exemple : « Je ne peux pas envoyer de modifications des pages Web en ce moment. Il semblerait qu'Alfred les ait verrouillées pendant qu'il modifie leur image de fond. » Tous les systèmes de gestion de version ne permettent pas ceci et ceux qui le permettent n'imposent pas que cette fonctionnalité soit utilisée.
Version control systems that require locking to make commits are said to use the lock-modify-unlock model. Those that do not are said to use the copy-modify-merge model. An excellent in-depth explanation and comparison of the two models may be found at http://svnbook.red-bean.com/svnbook-1.0/ch02s02.html. In general, the copy-modify-merge model is better for Open Source development, and all the version control systems discussed in this book support that model.
On dit que les systèmes de gestion de version qui imposent le verrouillage avant d'enregistrer des modifications utilisent le modèle verrouillage-modification-déverrouillage. Ceux qui ne le font pas utilisent le modèle dit de copie-modification-fusion. Une excellente explication détaillée et une comparaison de ces deux modèles se trouve à l'adresse http://svnbook.red-bean.com/svnbook-1.0/ch02s02.html. En général, le modèle copie-modification-fusion est plus adapté au développeurs Open Source et tous les logiciels de gestion de version abordés dans ce livre gèrent ce modèle.
Choosing a Version Control System / Choisir un logiciel de gestion de version
As of this writing, the version control system of choice in the free software world is the Concurrent Versions System or CVS (http://www.cvshome.org/). CVS has been around for a long time. Most experienced developers are already familiar with it, it does more or less what you need, and since it's the default, you won't end up in any long debates about whether or not it was the right choice. CVS has some disadvantages, however. It doesn't provide an easy way to refer to multi-file changes; it doesn't allow you to rename or copy files under version control (so if you need to reorganize your code tree after starting the project, it can be a real pain); it has poor merging support; it doesn't handle large files or binary files very well; and some operations are slow when large numbers of files are involved.
Au moment de l'écriture de ces lignes, le logiciel de gestion de version de choix dans le monde du logiciel libre est le Concurrent Versions System ou CVS (http://www.cvshome.org/). Cela fait un moment maintenant que CVS existe. La plupart des développeurs expérimentés y sont déjà familiers, il fait plus ou moins ce que vous voulez et puisque c'est le choix par défaut vous ne tomberez pas dans de longs débats sur la validité de votre choix. CVS possède quelques inconvénients cependant. Il ne propose pas de manière simple de se référer à des modifications de plusieurs fichiers, il ne vous permet pas de renommer ou de copier des fichiers sous gestion de version (et donc si vous avez besoin de réorganiser l'arbre de votre code après avoir lancé le projet cela peut être très pénible), les possibilités de fusion laissent à désirer, il ne gère pas très bien les fichiers volumineux ou les fichiers binaires et certaines opérations sont lentes quand elles concernent un grand nombre de fichiers.
None of CVS's flaws is fatal, and it is still quite popular. However, in the last few years a number of new version control systems have appeared, and free software projects are beginning to try them out. Appendix A, Free Version Control Systems lists all the ones I know of. As that list makes clear, deciding on a version control system could easily become a lifelong research project. Possibly you will be spared the decision because it will be made for you by your hosting site. But if you must choose, consult with your other developers, ask around to see what people have experience with, then pick one and run with it. Any stable, production-ready version control system will do; you don't have to worry too much about making a drastically wrong decision. If you simply can't make up your mind, then go with CVS. It's still the standard, and will probably continue to be so for a few years. Also, many of the other systems support one-way conversion from CVS, so you can change your mind later anyway.
Aucun de ces défauts n'est insurmontable et il reste plutôt populaire. Cependant, durant ces dernières années un certain nombre de nouveaux logiciels de gestion de version sont apparus et les projets de logiciel libre commencent à les essayer. L'Annexe A, Logiciels de gestion de version libres fait une liste de tous ceux que je connais. Comme cette liste le montre clairement, le choix d'un logiciel de gestion de version peut facilement devenir une recherche sans fin. Il se peut que cette décision vous soit épargnée parce qu'elle sera prise par votre site d'hébergement. Mais si vous devez choisir, consulter vos développeurs, demandez leur avec quel système ils ont l'habitude de travailler puis choisissez en un et travaillez avec. N'importe quel logiciel de gestion de version stable et opérationnel fera l'affaire, ne vous faites pas trop de soucis à propos d'une décision irrémédiablement mauvaise. Si vous n'arrivez pas à vous décider, choisissez alors CVS. C'est toujours le standard et il le restera certainement encore pour des années. De plus, de nombreux systèmes supportent la conversion depuis CVS, donc vous pourrez toujours changer d'avis par après.
Using the Version Control System / Utilisation du logiciel de gestion de version
The recommendations in this section are not targeted toward a particular version control system, and should be simple to implement in any of them. Consult your specific system's documentation for details.
Les recommandations dans cette partie ne se concentrent pas sur un logiciel de gestion de version particulier et devraient être simples à mettre en oeuvre dans n'importe lequel d'entre eux. Référez vous à la documentation de votre système pour plus de détails.
Version everything / Tout versionner
Keep not only your project's source code under version control, but also its Web pages, documentation, FAQ, design notes, and anything else that people might want to edit. Keep them right next to the source code, in the same repository tree. Any piece of information worth writing down is worth versioning—that is, any piece of information that could change. Things that don't change should be archived, not versioned. For example, an e-mail, once posted, does not change; therefore, versioning it wouldn't make sense (unless it becomes part of some larger, evolving document).
Non seulement vous devez garder le code source de votre projet sous gestion de version mais aussi ses pages Web, la documentation, la FAQ et tout ce que les gens pourraient éditer. Conservez les proche du code source, dans le même arbre de dépôt. Tout ce qui suffisamment important pour être écrit est suffisamment important pour être « versionné », c'est-à-dire toute information qui pourrait être modifiée. Les choses qui ne changent pas devraient être archivées, pas « versionnées ». Par exemple, un e-mail une fois envoyé ne change pas, donc le « versionner » est inutile (à moins qu'il fasse partie d'un plus grand document en constante évolution).
The reason versioning everything together in one place is important is so people only have to learn one mechanism for submitting changes. Often a contributor will start out making edits to the Web pages or documentation, and move to small code contributions later, for example. When the project uses the same system for all kinds of submissions, people only have to learn the ropes once. Versioning everything together also means that new features can be committed together with their documentation updates, that branching the code will branch the documentation too, etc.
Il est important de tout « versionner » ensemble au même endroit afin que les gens n'aient à apprendre qu'un seul mécanisme pour envoyer des modifications. Il arrive souvent qu'un contributeur débute en faisant des modifications des pages Web ou de la documentation puis plus tard se mette à apporter de petites contributions au code. Si le projet emploie le même système pour toutes les différentes contributions les gens n'auront à en apprendre les ficelles qu'une fois. Tout « versionner » ensemble permet aussi de soumettre les nouvelles fonctionnalités accompagnées des mise-à-jour de la documentation correspondantes et implique également que la création d'une branche du code créera également une branche dans la documentation, etc.
Don't keep generated files under version control. They are not truly editable data, since they are produced programmatically from other files. For example, some build systems create configure based on the template configure.in. To make a change to the configure, one would edit configure.in and then regenerate; thus, only the template configure.in is an « editable file. » Just version the templates—if you version the result files as well, people will inevitably forget to regenerate when they commit a change to a template, and the resulting inconsistencies will cause no end of confusion.[13]
Ne gardez pas les fichiers générés sous gestion de version. Ce ne sont pas vraiment des données éditables puisqu'elles ont été produites automatiquement à partir d'autres fichiers. Par exemple, certains systèmes de construction créent des configurations basées sur le modèle configure.in. Pour modifier la configuration on devra alors éditer configure.in et ensuite re-générer et par conséquent seul le modèle configure.in est un « fichier éditable ». Ne « versionnez » que le modèle, si vous « versionnez » le fichier résultant également les gens oublieront inévitablement de le re-générer lorsqu'ils appliquent une modification au modèle et les incompatibilités causeront des confusions sans fin.[13]
The rule that all editable data should be kept under version control has one unfortunate exception: the bug tracker. Bug databases hold plenty of editable data, but for technical reasons generally cannot store that data in the main version control system. (Some trackers have primitive versioning features of their own, however, independent of the project's main repository.)
Il existe cependant une exception malheureuse à cette règle du « versionnage » de tout fichier éditable : le système de suivi de bogues. La base de données de bogues contient un grand nombre de données éditables, mais pour des raisons techniques ne peut pas ranger ces données dans le logiciel de gestion de version principal (Certains systèmes de suivi possèdent leur propre système de « versionnement » primitif, mais il est indépendant du dépôt principal du projet).
Browsability / Navigabilité
The project's repository should be browsable on the Web. This means not only the ability to see the latest revisions of the project's files, but to go back in time and look at earlier revisions, view the differences between revisions, read log messages for selected changes, etc.
Le dépôt du projet devrait être navigable sur le Web. Ce qui veut dire que vous devez fournir à vos visiteurs non seulement la possibilité de voir les dernières révisions des fichiers du projet, mais aussi la possibilité de remonter dans le temps et voir les révisions précédentes, les différences entre les révisions, lire les messages enregistrés pour certaines modifications, etc.
Browsability is important because it is a lightweight portal to project data. If the repository cannot be viewed through a Web browser, then someone wanting to inspect a particular file (say, to see if a certain bugfix had made it into the code) would first have to install version control client software locally, which could turn their simple query from a two-minute task into a half-hour or longer task.
La navigabilité est importante parce que c'est un portail accessible vers les données du projet. Si le dépôt ne peut pas être vu grâce à un navigateur, si quelqu'un veut voir un fichier particulier (pour voir si un certain correctif de bogue a été intégré par exemple) il devra d'abord installer le logiciel de gestion de version localement, ce qui transformerait sa petite recherche de deux minutes en une tâche d'une demi heure.
Browsability also implies canonical URLs for viewing specific revisions of files, and for viewing the latest revision at any given time. This can be very useful in technical discussions or when pointing people to documentation. For example, instead of saying « For tips on debugging the server, see the www/hacking.html file in your working copy, » one can say « For tips on debugging the server, see http://svn.collab.net/repos/svn/trunk/www/hacking.html, » giving a URL that always points to the latest revision of the hacking.html file. The URL is better because it is completely unambiguous, and avoids the question of whether the addressee has an up-to-date working copy.
La navigabilité implique également des URL pour voir des révisions spécifiques de fichiers et pour voir les dernières révisions à tout moment. Cela peut-être très utile dans des discussions techniques ou lorsqu'on oriente les gens vers la documentation. Par exemple, plutôt que de dire « Pour des conseils pour déboguer le serveur voir le fichier www/hacking.html dans votre copie de travail » on pourra dire « Pour des conseils pour débugguer le serveur voir http://svn.collab.net/repos/svn/trunk/www/hacking.html », donnant ainsi une URL qui renvoi toujours vers la dernière révision du fichier hacking.html. Il vaut mieux donner l'URL car ainsi vous levez toute ambiguïté et vous évitez de vous demander si la personne a qui vous vous adressez possède bien une copie mise-à-jour.
Some version control systems come with built-in repository-browsing mechanisms, while others rely on third-party tools to do it. Three such tools are ViewCVS (http://viewcvs.sourceforge.net/), CVSWeb (http://www.freebsd.org/projects/cvsWeb.html), and WebSVN (http://Websvn.tigris.org/). The first works with both CVS and Subversion, the second with CVS only, and the third with Subversion only.
Certains systèmes de gestion de version possèdent leurs propres mécanismes de navigation de dépôt intégrés alors que d'autres s'appuient sur des programmes tiers. Trois de ces outils sont ViewCVS (http://viewcvs.sourceforge.net/), CVSWeb (http://www.freebsd.org/projects/cvsWeb.html) et WebSVN (http://Websvn.tigris.org/). Le premier est compatible avec CVS et Subversion, le deuxième avec CVS seulement et le troisième avec Subversion seulement.
Commit e-mails / E-mails de commit
Every commit to the repository should generate an e-mail showing who made the change, when they made it, what files and directories changed, and how they changed. The e-mail should go to a special mailing list devoted to commit e-mails, separate from the mailing lists to which humans post. Developers and other interested parties should be encouraged to subscribe to the commits list, as it is the most effective way to keep up with what's happening in the project at the code level. Aside from the obvious technical benefits of peer review (see the section called “Practice Conspicuous Code Review”), commit e-mails help create a sense of community, because they establish a shared environment in which people can react to events (commits) that they know are visible to others as well.
Chaque ajout au dépôt devrait générer un e-mail précisant qui a fait les modifications, quand et quels fichiers et dossiers ont été affectés et de quelle manière. L'e-mail devrait être envoyé à une liste de diffusion spécialement faite pour les e-mails de commit, bien distincte des listes de diffusion où ce sont les humains qui écrivent. Les développeurs et toutes les personnes intéressées devraient être encouragés à souscrire à cette liste de diffusion comme c'est le moyen le plus efficace de suivre ce qui se passe dans le projet au niveau du code. En plus des avantages techniques évidents en matière de vérification par les collègues (voir la section « Effectuez une inspection visible du code »), les e-mails de commit participent au développement du sentiment de communauté parce qu'ils établissent un environnement partagé dans lequel les gens peuvent réagir à des évènements (les commits) qu'ils savent visibles par tous.
The specifics of setting up commit e-mails will vary depending on your version control system, but usually there's a script or other packaged facility for doing it. If you're having trouble finding it, try looking for documentation on hooks, specifically a post-commit hook, also called the loginfo hook in CVS. Post-commit hooks are a general means of launching automated tasks in response to commits. The hook is triggered by an individual commit, is fed all the information about that commit, and is then free to use that information to do anything—for example, to send out an e-mail.
Les spécificités de la mise en place d'e-mails de commit dépendront de votre logiciel de gestion de version, mais en général il existe un script ou d'autres outils sous forme de paquets pour le faire. Si vous avez du mal à le trouver, essayez de chercher de la documentation sur les mécanismes, en particulier sur les mécanismes post-commit, aussi appelés mécanismes loginfo dans CVS. Les mécanismes post-commit sont un moyen d'automatiser certaines tâches en réponse à un commit. Le mécanisme est déclenché par un commit, engrange toutes les informations à propos de ce commit et est ensuite libre d'utiliser ces informations pour faire n'importe quoi, comme par exemple envoyer un e-mail.
With pre-packaged commit e-mail systems, you may want to modify some of the default behaviors:
1. Some commit mailers don't include the actual diffs in the e-mail, but instead provide a URL to view the change on the Web using the repository browsing system. While it's good to provide the URL, so the change can be referred to later, it is also very important that the commit e-mail include the diffs themselves. Reading e-mail is already part of people's routine, so if the content of the change is visible right there in the commit e-mail, developers will review the commit on the spot, without leaving their mail reader. If they have to click on a URL to review the change, most won't do it, because that requires a new action instead of a continuation of what they were already doing. Furthermore, if the reviewer wants to ask something about the change, it's vastly easier to hit reply-with-text and simply annotate the quoted diff than it is to visit a Web page and laboriously cut-and-paste parts of the diff from Web browser to e-mail client.
(Of course, if the diff is huge, such as when a large body of new code has been added to the repository, then it makes sense to omit the diff and offer only the URL. Most commit mailers can do this kind of limiting automatically. If yours can't, then it's still better to include diffs, and live with the occasional huge e-mail, than to leave the diffs off entirely. Convenient reviewing and commenting is a cornerstone of cooperative development, much too important to do without.)
2. The commit e-mails should set their Reply-to header to the regular development list, not the commit e-mail list. That is, when someone reviews a commit and writes a response, their response should be automatically directed toward the human development list, where technical issues are normally discussed. There are a few reasons for this. First, you want to keep all technical discussion on one list, because that's where people expect it to happen, and because that way there's only one archive to search. Second, there might be interested parties not subscribed to the commit e-mail list. Third, the commit e-mail list advertises itself as a service for watching commits, not for watching commits and occasional technical discussions. Those who subscribed to the commit e-mail list did not sign up for anything but commit e-mails; sending them other material via that list would violate an implicit contract. Fourth, people often write programs that read the commit e-mail list and process the results (for display on a Web page, for example). Those programs are prepared to handle consistently-formatted commit e-mails, but not inconsistent human-written mails.
Avec un système d'e-mail de commit déjà prêt vous pouvez toujours modifier certaines options par défaut :
1. Certains systèmes d'envoi d'e-mail de commit n'incluent pas les diffs en eux-mêmes dans les e-mails mais proposent à la place une URL pour voir les changements sur le Web en utilisant le système de navigation du dépôt. Même s'il est acceptable de donner une URL, car ainsi on peut se référer à la modification par après, il est aussi très important que l'e-mail de commit comprenne les diffs eux-mêmes. La lecture de l'e-mail fait déjà parti de la routine des gens, donc si le contenu de la modification est visible directement dans l'e-mail de commit les développeurs peuvent examiner le commit directement, sans sortir de leur messagerie. S'ils doivent cliquer sur un lien pour examiner quelque chose, la plupart ne feront pas cet effort parce qu'une action supplémentaire est nécessaire par rapport à une lecture continue. De plus, si cette personne veut poser une question à propos de la modification, il est nettement plus simple d'appuyer sur le bouton « Répondre » et de simplement annoter le diff cité que de se rendre sur le site Web et de copier/coller laborieusement des parties du diff du navigateur Web vers messagerie.
(Évidemment, si le diff est très gros, comme par exemple quand un gros morceau de nouveau code est ajouté au dépôt, il paraît plus normal de ne pas inclure le diff mais de mettre un lien plutôt. La plupart des systèmes d'envoi d'e-mail de commit peuvent adopter ce genre de limitations automatiquement. Si le votre ne le fait pas, alors il vaut mieux inclure les diffs tout le temps et se faire aux mails énormes qui arrivent de temps en temps plutôt que de toujours laisser tomber les diffs. La possibilité de vérifier et commenter facilement est la base du développement coopératif, c'est bien trop important pour s'en passer.)
2. Par défaut, l'option « Répondre à » pour les e-mails de commit devrait renvoyer à la liste de développement normale, pas à la liste d'e-mails de commit. Dans la pratique, quand quelqu'un examine un commit et écrit une réponse, celle-ci devrait être automatiquement envoyée à la liste de développeurs, là où les problèmes techniques sont normalement débattus. Voici quelques raisons pour appuyer ce choix. En premier, il vaut mieux regrouper toutes les discussions techniques sur une même liste, parce que c'est là que les gens s'attendent à les voir et aussi parce qu'ainsi il n'y a qu'une archive dans laquelle faire les recherches. En deuxième, il se peut que des gens intéressés ne soient pas inscrits à la liste d'e-mails de commit. En troisième, la liste de commit se présente comme un service pour suivre les commits, pas pour suivre les commits et des discussions techniques occasionnelles. Ceux qui se sont inscrits sur la liste d'e-mails de commit ne se sont pas abonnés à autre chose qu'un liste d'e-mails de commit, en leur envoyant d'autres informations par le biais de cette liste vous violerez un contrat implicite. Et finalement, les gens écrivent souvent des programmes qui lisent les listes d'e-mails de commit et qui traitent les résultats (pour les afficher sur une page Web par exemple). Ces programmes sont fait pour gérer des e-mails de commit automatiquement générés, pas des e-mails écrits par main d'homme.
Note that this advice to set Reply-to does not contradict the recommendations in the section called “The Great Reply-to Debate” earlier in this chapter. It's always okay for the sender of a message to set Reply-to. In this case, the sender is the version control system itself, and it sets Reply-to in order to indicate that the appropriate place for replies is the development mailing list, not the commit list.
Remarquez que ces conseils sur le « Répondre à » ne sont pas en contradiction avec les recommandations de la section « Le grand débat du Répondre à » précédemment dans ce chapitre. Il vaut toujours mieux que l'expéditeur d'un message remplisse la case « Répondre à ». Ici, l'expéditeur est le logiciel de gestion de version lui même et il configure le « Répondre à » afin d'indiquer que l'endroit approprié pour répondre est la liste de diffusion de développement, pas la liste de commit.
CIA: Another Change Publication Mechanism / CIA : un autre mécanisme de publication des modifications
Commit e-mails are not the only way to propagate change news. Recently, another mechanism called CIA (http://cia.navi.cx/) has been developed. CIA is a real-time commit statistics aggregator and distributor. The most popular use of CIA is to send commit notifications to IRC channels, so that people logged into those channels see the commits happening in real time. Though of somewhat less technical utility than commit e-mails, since observers might or might not be around when a commit notice pops up in IRC, this technique is of immense social utility. People get the sense of being part of something alive and active, and feel that they can see progress being made right before their eyes.
Les e-mails de commit ne sont pas le seul moyen de faire suivre les nouvelles concernant des modifications. Récemment, un autre mécanisme appelé CIA (http://cia.navi.cx/) a été développé. CIA est un agrégateur et distributeur de statistiques en temps réel. La fonction la plus répandue de CIA est l'envoie de notifications de commit aux canaux IRC afin que les personnes présentes dans ces canaux soient informées du commit en temps réel. Bien que d'utilité technique moindre que les e-mails de commit, puisque les observateurs peuvent comme peuvent ne pas être présents quand l'information arrive dans IRC, cette technique a une utilité sociale énorme. Cela donne l'impression aux gens de faire partie de quelque chose de vivant et d'actif et ils sentent qu'ils peuvent en visualiser directement la progression.
The way it works is that you invoke the CIA notifier program from your post-commit hook. The notifier formats the commit information into an XML message, and sends to a central server (typically cia.navi.cx). That server then distributes the commit information to other forums.
Cela fonctionne grâce au déclenchement du programme de notification de CIA par le mécanisme post-commit. Le programme de notification met les informations du commit sous forme d'un message XML et l'envoie à un serveur central (généralement cia.navi.cx). Ce serveur distribue ensuite l'information de commit aux autres forums.
CIA can also be configured to send out RSS feeds. See the documentation at http://cia.navi.cx/ for details.
To see an example of CIA in action, point your IRC client at irc.freenode.net, channel #commits.CIA peut également être configuré pour envoyer des flux RSS. Voir la documentation à l'adresse http://cia.navi.cx/ pour en savoir plus.
Pour voir une démonstration de CIA, rendez-vous sur irc.freenode.net, canal #commits.Use branches to avoid bottlenecks / Utilisez les branches pour éviter les embouteillages
Non-expert version control users are sometimes a bit afraid of branching and merging. This is probably a side effect of CVS's popularity: CVS's interface for branching and merging is somewhat counterintuitive, so many people have learned to avoid those operations entirely.
Les utilisateurs non-expert en gestion de version ont parfois un peu peur de créer des branches et d'en fusionner. C'est certainement l'un des effets secondaire de la popularité de CVS : l'interface de CVS pour créer des branches et les fusionner est en quelque sorte contre-intuitive et beaucoup de personnes ont appris à complètement éviter ces opérations.
If you are among those people, resolve right now to conquer any fears you may have and take the time to learn how to do branching and merging. They are not difficult operations, once you get used to them, and they become increasingly important as a project acquires more developers.
Si vous faites parti de ces gens, prenez immédiatement la résolution de vaincre toutes les peurs que vous pourriez avoir et prenez le temps d'apprendre à créer des branches et à les fusionner. Ce ne sont pas des opérations difficiles une fois que vous y êtes habitué et elles deviennent de plus en plus importante à mesure que le projet gagne de nouveaux développeurs.
Branches are valuable because they turn a scarce resource—working room in the project's code—into an abundant one. Normally, all developers work together in the same sandbox, constructing the same castle. When someone wants to add a new drawbridge, but can't convince everyone else that it would be an improvement, branching makes it possible for her to go to an isolated corner and try it out. If the effort succeeds, she can invite the other developers to examine the result. If everyone agrees that the result is good, they can tell the version control system to move (« merge ») the drawbridge from the branch castle over to the main castle.
Les branches sont importantes parce qu'elles transforment une ressource rare, de l'espace pour travailler dans le code du projet, en une ressource abondante. Normalement, tous les développeurs travaillent ensemble dans le même bac à sable à construire le même château de sable. Quand quelqu'un veut ajouter un nouveau pont-levis, mais qu'il n'arrive pas à convaincre tout le monde que ce serait une amélioration, créer une branche lui permet de travailler dans son coin et de faire des essais. Si ses efforts sont couronnés de succès il peut inviter les autres développeurs à examiner le résultat. Si tout le monde s'accorde pour dire que ce résultat est bon ils peuvent dire au logiciel de gestion de version de déplacer (« fusionner ») le pont-levis du château image vers le château principal.
It's easy to see how this ability helps collaborative development. People need the freedom to try new things without feeling like they're interfering with others' work. Equally importantly, there are times when code needs to be isolated from the usual development churn, in order to get a bug fixed or a release stabilized (see the section called “Stabilizing a Release” and the section called “Maintaining Multiple Release Lines” in Chapter 7, Packaging, Releasing, and Daily Development) without worrying about tracking a moving target.
Il est facile de comprendre pourquoi cette possibilité est bénéfique au développement collaboratif. Les gens ont besoin de liberté pour essayer de nouvelles choses sans avoir peur d'interférer avec le travail des autres. De même, le code a parfois besoin d'être isolé de l'agitation du développement régulier pour qu'un bogue soit corrigé ou une version stabilisée (voir la section « Stabiliser une version » et la section « Maintenir plusieurs lignes de sortie » dans le Chapitre 7, Création de paquets, sorties et développement quotidien) sans avoir l'impression de viser une cible en mouvement perpétuel.
Use branches liberally, and encourage others to use them. But also make sure that a given branch is only active for exactly as long as needed. Every active branch is a slight drain on the community's attention. Even those who are not working in a branch still maintain a peripheral awareness of what's going on in it. Such awareness is desirable, of course, and commit e-mails should be sent out for branch commits just as for any other commit. But branches should not become a mechanism for dividing the development community. With rare exceptions, the eventual goal of most branches should be to merge their changes back into the main line and disappear.
Utilisez les branches librement et encouragez les autres à en faire de même. Mais assurez vous aussi qu'une branche donnée n'est active que pour le temps nécessaire, pas plus. Chaque branche active dilue l'attention de la communauté. Même ceux qui ne travaillent pas sur la branche gardent toujours un œil dessus pour savoir ce qu'il s'y passe. Une telle attention est bonne, bien sûr, et les e-mails de commit devraient être envoyés pour un commit dans une branche comme n'importe quel autre commit. Mais les branches ne devraient pas devenir un mécanisme qui disperse la communauté de développeurs. A de rares exceptions près, le destin final d'une branche est d'être fusionnée à la ligne principale et de disparaître.
Singularity of information / Unicité de l'information
Merging has an important corollary: never commit the same change twice. That is, a given change should enter the version control system exactly once. The revision (or set of revisions) in which the change entered is its unique identifier from then on. If it needs to be applied to branches other than the one on which it entered, then it should be merged from its original entry point to those other destinations—as opposed to committing a textually identical change, which would have the same effect in the code, but would make accurate bookkeeping and release management impossible.
Un corollaire important découle de la fusion : n'enregistrez jamais deux fois la même modification. Un changement donné ne devrait intégrer le logiciel de gestion de version qu'une seule fois. La révision (ou l'ensemble de révisions) par laquelle la modification est entrée est son unique identificateur à partir de ce moment. S'il doit être appliqué à d'autres branches que celle par laquelle il est entré, alors il devrait être fusionné aux autres destinations à partir de son point d'entrée d'origine plutôt qu'enregistré comme un changement parfaitement identique, ce qui a le même effet sur le code mais qui rendrait le suivi et la gestion impossible.
The practical effects of this advice differ from one version control system to another. In some systems, merges are special events, fundamentally distinct from commits, and carry their own metadata with them. In others, the results of merges are committed the same way other changes are committed, so the primary means of distinguishing a « merge commit » from a « new change commit » is in the log message. In a merge's log message, don't repeat the log message of the original change. Instead, just indicate that this is a merge, and give the identifying revision of the original change, with at most a one-sentence summary of its effect. If someone wants to see the full log message, she should consult the original revision.
Les effets pratiques de ce conseil diffèrent d'un logiciel de gestion de version à l'autre. Dans certains systèmes, les fusions sont des évènements spéciaux, fondamentalement distincts des commits et sont marqués par leurs propres méta-données. Dans d'autres, les résultats des fusions sont enregistrés de la même manière que les modifications, donc la première manière de distinguer un « commit fusionné » d'un « commit pour une nouvelle modification » est de regarder les messages enregistrés. Dans un message enregistré pour une fusion ne répétez pas le message enregistré du changement d'origine. Indiquez simplement que c'est une fusion et donnez l'identifiant de la révision du changement d'origine avec une phrase pour en résumer les effets tout au plus. Si quelqu'un désire voir le message enregistré en entier il devrait consulter l'original.
The reason it's important to avoid repeating the log message is that log messages are sometimes edited after they've been committed. If a change's log message were repeated at each merge destination, then even if someone edited the original message, she'd still leave all the repeats uncorrected—which would only cause confusion down the road.
Il est important d'éviter de répéter les messages enregistrés parce qu'il se peut qu'ils soient édités après avoir été enregistrés. Si un message enregistré est répété dans chaque cible de la fusion et que le message d'origine est modifié les copies ne le sont pas, ce qui ne peut que mener à des incompréhensions.
The same principle applies to reverting a change. If a change is withdrawn from the code, then the log message for the reversion should merely state that some specific revision(s) is being reverted, not describe the actual code change that results from the reversion, since the semantics of the change can be derived by reading the original log message and change. Of course, the reversion's log message should also state the reason why the change is being reverted, but it should not duplicate anything from the original change's log message. If possible, go back and edit the original change's log message to point out that it was reverted.
Il en va de même pour l'annulation d'un changement. Si une modification est retirée du code, alors le message enregistré pour ce retour en arrière devrait simplement annoncer que cette (ces) révision(s) particulière(s) est (sont) retirée(s), pas décrire le changement de code entraîné puisque ces informations peuvent être déduites de la lecture du message enregistré original. Évidemment, le message enregistré pour ce retour en arrière devrait également dire pourquoi ce changement a été retiré, mais il ne devrait rien copier du message enregistré originel. Si possible, éditez le message enregistré d'origine pour établir clairement qu'il a été retiré.
All of the above implies that you should use a consistent syntax for referring to revisions. This is helpful not only in log messages, but in e-mails, the bug tracker, and elsewhere. If you're using CVS, I suggest « path/to/file/in/project/tree:REV », where REV is a CVS revision number such as « 1.76 ». If you're using Subversion, the standard syntax for revision 1729 is « r1729 » (file paths are not needed because Subversion uses global revision numbers). In other systems, there is usually a standard syntax for expressing the changeset name. Whatever the appropriate syntax is for your system, encourage people to use it when referring to changes. Consistent expression of change names makes project bookkeeping much easier (as we will see in Chapter 6, Communications and Chapter 7, Packaging, Releasing, and Daily Development), and since a lot of the bookkeeping will be done by volunteers, it needs to be as easy as possible.
See also the section called “Releases and Daily Development” in Chapter 7, Packaging, Releasing, and Daily Development.Toutes ces instructions impliquent que vous devriez utiliser une syntaxe cohérente lorsque vous vous référez à des révisions. Vous en verrez les bienfaits non seulement pour les messages enregistrés, mais aussi dans les e-mails, le système de suivi de bogues, etc. Si vous utilisez CVS, je vous conseille « path/to/file/in/project/tree:REV », ou REV est un numéro de révision dans CVS, comme par exemple « 1.76 ». Si vous utilisez Subversion, la syntaxe standard pour la révision 1729 est « r1729 » (le chemin d'accès n'est pas indispensable puisque Subversion emploi des numéros de révisions généraux). Les autres systèmes emploient en général une syntaxe standard pour exprimer le nom de l'ensemble de modifications. Quelque soit la syntaxe appropriée à votre système encouragez les gens à l'utiliser lorsqu'ils parlent des modifications. La cohérence dans l'expression des noms des modifications permet un suivi du projet plus aisé (comme nous le verrons dans le Chapitre 6, Communication et le Chapitre 7, Création de paquets, sorties et développement quotidien) et comme une grande partie de ce suivi sera faite par des volontaires il doit être aussi simple que possible.
Voir aussi la section nommée « Sorties et développement quotidien » dans le Chapitre 7, Création de paquets, sorties et développement quotidien.Authorization / Autorisation
Most version control systems offer a feature whereby certain people can be allowed or disallowed from committing in specific sub-areas of the repository. Following the principle that when handed a hammer, people start looking around for nails, many projects use this feature with abandon, carefully granting people access to just those areas where they have been approved to commit, and making sure they can't commit anywhere else. (See the section called “Committers” in Chapter 8, Managing Volunteers for how projects decide who can commit where.)
La plupart des logiciels de gestion de versions proposent une fonctionnalité qui permet de donner ou non aux gens la possibilité d'enregistrer des modifications selon les domaines du dépôt. En suivant le principe qui veut que quand on donne un marteau à quelqu'un, ce quelqu'un va se mettre à chercher des clous, de nombreux projets utilisent cette fonctionnalité avec parcimonie, accordant ces droits d'accès seulement aux domaines où les personnes ont été autorisées à enregistrer des modifications et s'assurant qu'ils ne peuvent le faire nul part ailleurs. (Voir la séction « Committers » dans le Chapitre 8, Gérer les volontaires pour savoir comment les projets décident de qui peut enregistrer et où.)
There is probably little harm done by exercising such tight control, but a more relaxed policy is fine too. Some projects simply use an honor system: when a person is granted commit access, even for a sub-area of the repository, what they actually receive is a password that allows them to commit anywhere in the project. They're just asked to keep their commits in their area. Remember that there is no real risk here: in an active project, all commits are reviewed anyway. If someone commits where they're not supposed to, others will notice it and say something. If a change needs to be undone, that's simple enough—everything's under version control anyway, so just revert.
Un tel contrôle strict ne gênera sûrement personne, mais des règles plus souples conviendront aussi. Certains projets fonctionnent avec un système d'honneur : quand on accorde l'accès de commit à une personne, même pour une sous-partie du dépôt, cette personne reçoit en fait un mot de passe qui lui permet d'enregistrer des modifications n'importe où dans le projet. On leur demande juste de se limiter à leur domaine. N'oubliez pas qu'il n'y a pas vraiment de risque, tous les commits sont examinés de toute façon. Si quelqu'un enregistre quelque chose qu'il n'était pas censé enregistrer, d'autres le remarqueront et le signaleront. Si une modification doit être retirée c'est assez simple, tout est sous gestion de version de toute façon, donc annulez là tout simplement.
There are several advantages to the relaxed approach. First, as developers expand into other areas (which they usually will if they stay with the project), there is no administrative overhead to granting them wider privileges. Once the decision is made, the person can just start committing in the new area right away.
L'approche plus souple possède quelques avantages. D'abord les développeurs s'ouvrent à d'autres domaines (ce qu'ils feront de toute façon s'ils restent dans le projet), ça ne demande pas plus de travail administratif pour leur accorder des privilèges plus larges. Une fois que la décision est prise la personne peut commencer à enregistrer des modifications dans le nouveau domaine immédiatement.
Second, expansion can be done in a more fine-grained manner. Generally, a committer in area X who wants to expand to area Y will start posting patches against Y and asking for review. If someone who already has commit access to area Y sees such a patch and approves of it, they can just tell the submitter to commit the change directly (mentioning the reviewer/approver's name in the log message, of course). That way, the commit will come from the person who actually wrote the change, which is preferable from both an information management standpoint and from a crediting standpoint.
Ensuite, l'ouverture peut être faite de manière plus fine. En général, un committer dans le domaine X qui voudrait s'ouvrir au domaine Y commencera en envoyant des correctifs pour Y en demandant à les faire examiner. Si quelqu'un qui possédant déjà l'accès de commit dans le domaine Y voit ce correctif et l'approuve il peut simplement demander à celui qui l'a proposé de l'enregistrer directement (en mentionnant le nom de l'examinateur/celui qui approuve dans le message enregistré évidemment). Ainsi, le commit proviendra de la personne qui a effectivement fait la modification, ce qui est préférable à la fois du point de vue de la gestion de l'information et de celui de la reconnaissance.
Last, and perhaps most important, using the honor system encourages an atmosphere of trust and mutual respect. Giving someone commit access to a subdomain is a statement about their technical preparedness—it says: « We see you have expertise to make commits in a certain domain, so go for it. » But imposing strict authorization controls says: « Not only are we asserting a limit on your expertise, we're also a bit suspicious about your intentions. » That's not the sort of statement you want to make if you can avoid it. Bringing someone into the project as a committer is an opportunity to initiate them into a circle of mutual trust. A good way to do that is to give them more power than they're supposed to use, then inform them that it's up to them to stay within the stated limits.
Finalement, et ce n'est sûrement pas le moins important, l'utilisation du système d'honneur encourage une atmosphère de confiance et de respect mutuel. Obtenir l'accès de commit à un sous-domaine est la reconnaissance de compétences techniques, cela signifie : « Nous remarquons que tu as les compétences pour faire des commits dans un certain domaine, nous te donnons le feu vert ». Mais en imposant un contrôle strict sur les autorisations vous dites : « Non seulement nous pensons que tes compétences ont des limites mais nous sommes en plus suspicieux quand à tes intentions. » Ce n'est pas vraiment le message que vous voulez faire passer si vous pouvez l'éviter. Donner l'accès de commit à quelqu'un pour le faire entrer dans le projet est une chance de lui ouvrir l'accès à un cercle de confiance mutuelle. Une bonne façon de faire cela est de leur accorder plus de pouvoirs qu'ils ne sont censés avoir et leur dire ensuite que c'est à eux de respecter leurs limites.
The Subversion project has operated on the honor system way for more than four years, with 33 full and 43 partial committers as of this writing. The only distinction the system actually enforces is between committers and non-committers; further subdivisions are maintained solely by humans. Yet we've never had a problem with someone deliberately committing outside their domain. Once or twice there's been an innocent misunderstanding about the extent of someone's commit privileges, but it's always been resolved quickly and amiably.
Le projet Subversion fonctionne avec le système d'honneur depuis plus de quatre ans maintenant, avec 33 committers de plein droit et 43 committers ayant des droits restreints au moment où j'écris ces lignes. La seule différence que fait le système est entre ceux qui ont les droits de committers et ceux qui ne les ont pas, des sous-divisions plus précises ne sont établies que par les humains. Pourtant nous n'avons jamais eu de problème avec quelqu'un qui aurait dépassé les limites de son domaine. Une ou deux fois nous avons eu une légère incompréhension au niveau de l'étendue des privilèges de commit, mais ce problème a toujours été réglé rapidement et calmement.
Obviously, in situations where self-policing is impractical, you must rely on hard authorization controls. But such situations are rare. Even when there are millions of lines of code and hundreds or thousands of developers, a commit to any given code module should still be reviewed by those who work on that module, and they can recognize if someone committed there who wasn't supposed to. If regular commit review isn't happening, then the project has bigger problems to deal with than the authorization system anyway.
Évidemment, dans des situations ou l'auto-gestion n'est pas praticable vous devrez vous fier à un contrôle plus strict des autorisations. Mais de telles situations sont rares. Cependant, quand il y a des millions de lignes de code et des centaines ou des milliers de développeurs, un commit pour n'importe quelle partie du code devrait toujours être vérifié par ceux travaillant sur cette partie, ils pourront dire si quelqu'un a enregistré une modification alors qu'il n'aurait pas dû. Si une vérification régulière des commits n'est pas faite, le projet a alors à faire face à de plus gros problèmes que celui du système d'autorisation de toute façon.
In summary, don't spend too much time fiddling with the version control authorization system, unless you have a specific reason to. It usually won't bring much tangible benefit, and there are advantages to relying on human controls instead.
Pour résumer, ne perdez pas trop de temps avec les autorisations du logiciel de gestion de version, à moins que vous n'ayez des raisons particulières de le faire. Cela n'apporte en général pas d'amélioration tangible et il y a des avantages à se reposer sur les contrôles humains à la place.
None of this should be taken to mean that the restrictions themselves are unimportant, of course. It would be bad for a project to encourage people to commit in areas where they're not qualified. Furthermore, in many projects, full (unrestricted) commit access has a special status: it implies voting rights on project-wide questions. This political aspect of commit access is discussed more in the section called “Who Votes?” in Chapter 4, Social and Political Infrastructure.
Il ne faut pas comprendre ici que les restrictions en elles-mêmes ne sont pas importantes bien sûr. Il serait dommageable pour le projet d'encourager les gens à enregistrer des modifications dans des parties pour lesquelles ils n'ont pas les compétences requises. De plus, dans de nombreux projets, un accès de commit de plein droit (non restreint) possède un statut particulier : il implique le droit de vote sur les questions qui concernent le projet dans sa globalité. Cet aspect politique de l'accès de commit est discuté dans la section « Qui vote ? » du Chapitre 4, Infrastructure sociale et politique.
