国家圆梦女孩志愿行动儿童剧《雏菊花》创作...
La gestion de versions (en anglais : version control ou revision control) consiste à gérer l'ensemble des versions d'un ou plusieurs fichiers (généralement en texte). Essentiellement utilisée dans le domaine de la création de logiciels, elle concerne surtout la gestion des codes source.
Cette activité étant fastidieuse et relativement complexe, un appui logiciel est presque indispensable. à cet effet, il existe différents logiciels de gestion de versions qui, bien qu'ayant des concepts communs, apportent chacun leur propre vocabulaire et leurs propres usages. à titre d'exemple, on trouve un mécanisme rudimentaire de gestion de versions dans Wikipédia : pour chaque article, l'historique est disponible en cliquant sur le lien Afficher l'historique ; chaque ligne est une version de l'article. Ce système a plusieurs caractéristiques: il est linéaire et chronologique, par opposition à une gestion de contenu élaborée selon une structure arborescente; une version d'une page est indépendante des versions des autres pages, par opposition à une étiquette qui permette de désigne une version d'un ensemble de pages.
Historique
[modifier | modifier le code]Historique des systèmes de version centralisés
[modifier | modifier le code]L' outil de mise à jour logiciel IEBUPDTE pour OS/360 d'IBM remonte à 1962, un précurseur des outils systèmes de contr?le de version. Deux gestionnaires de source et papquets de contr?le de version qui sont lourdement utilisés par des installations IBM 360/370 sont The Librarian et Panvalet[1],[2].
Un système complètement con?u pour le contr?le de code source commence en 1972: le Source Code Control System (SCCS), aussi pour l'OS/360. Le manuel utilisateur de SCCS, et en particulier son introduction, sont publiés le décembre 1975, suggère qu'il est le premier système de contr?le de révision délibéré[3]. Le Revision Control System (RCS) suit en 1982[4] et, plus tard, le logiciel Concurrent Versions System (CVS) ajoute le réseau et le développement de fonctionnalités concurrentes sur RCS. Après CVS, un successeur dominant est Subversion[5]. Par la suite, sont arrivés des distributed version control tels que Git[6].
Historique des systèmes de version distribués
[modifier | modifier le code]Les premiers systèmes de version distribués (DVCS) incluent Arch, Monotone, et Darcs. Les DVCS open source n'ont jamais été très utilisés jusqu'à la publication de Git et Mercurial.
BitKeeper est utilisé dans le développement du noyau Linux de 2002 à 2005[7]. Le développement de Git, le système open source de contr?le de version le plus utilisé [8], est accéléré par la décision de la société autrice de BitKeeper de reconsidérer la licence libre que Linus Torvalds et d'autres développeurs du noyau Linux ont initialiement profité[7].
Versions
[modifier | modifier le code]Les logiciels évoluant, chaque étape d'avancement est appelée version (ou revision). Les différentes versions sont nécessairement liées à travers des modifications (diff ou patch) : une modification est un ensemble d'ajouts, de modifications, et de suppressions de données.
Schématiquement, on passera de la version N à la version N + 1 en appliquant une modification M. Un logiciel de gestion de versions applique ou retire ces modifications une par une pour fournir la version du fichier voulue.
On préfère parfois le terme ? révision ? afin de ne pas confondre la version d'un fichier et la version d'un logiciel, qui est une étape de distribution sous forme ?finie?, c'est-à-dire principalement binaire.
Modifications et ensemble de modifications
[modifier | modifier le code]Une modification constitue donc l'évolution entre deux versions. On peut donc aussi bien parler de la différence entre deux versions que de modifications ayant amené à une nouvelle version.
On utilise généralement la gestion de versions à un ensemble de fichiers qui constitue un projet. De ce fait, il est courant de parler de modifications pour un seul fichier et d'ensemble de modifications (change set) lorsqu'il s'agit du projet (et donc de plusieurs fichiers). En effet, les deux n'évoluent pas au même rythme.
Pour illustrer, prenons l'exemple d'un logiciel nommé ? Toto ?. Il est constitué des fichiers A, B et C. à la version 1.0 de ? Toto ? correspondent les versions 1.0 de chacun des fichiers. Admettons que l'ajout d'une fonctionnalité à ? Toto ? impose la modification de A et de C. Présentons la situation à l'aide d'un tableau
| versions de ? Toto ? | versions de A | versions de B | versions de C |
|---|---|---|---|
| 1.0 | 1.0 | 1.0 | 1.0 |
| 1.1 | 1.1 | 1.1 |
Du point de vue du projet, les modifications apportées à A et à C font partie du même ensemble.
Dép?t et copies locales
[modifier | modifier le code]Les fichiers ainsi versionnés sont mis à dispositions sur un dép?t, c'est-à-dire un espace de stockage géré par un logiciel de gestion de versions.
Pour pouvoir effectuer des modifications, le développeur doit d'abord faire une copie locale des fichiers qu'il souhaite modifier, ou de tout le dép?t. Selon les systèmes de gestion de version, certains fichiers peuvent être verrouillés ou protégés en écriture pour tout le monde, ou pour certaines personnes.
Le développeur fait ses modifications et effectue ses premiers tests localement, indépendamment des modifications faites sur le dép?t du fait du travail simultané d'autres développeurs. Il doit ensuite faire un commit (une ?soumission?), c'est-à-dire soumettre ses modifications, afin qu'elles soient enregistrées sur le dép?t. C'est là que peuvent appara?tre des conflits entre ce que le développeur souhaite soumettre et les modifications effectuées depuis la dernière copie locale effectuée. Ces conflits doivent être résolus (merge) pour que le patch soit accepté sur le dép?t.
Branches
[modifier | modifier le code]Lorsque des modifications divergentes interviennent hors conflit, il se crée des branches. Le fait de vouloir rassembler deux branches est une fusion de branches.
Les branches sont utilisées pour permettre :
- la maintenance d'anciennes versions du logiciel (sur les branches) tout en continuant le développement des futures versions (sur le tronc) ;
- le développement parallèle de plusieurs fonctionnalités volumineuses sans bloquer le travail quotidien sur les autres fonctionnalités.
Les correctifs de la dernière version doivent être faits sur le trunk.
Conflit de modifications
[modifier | modifier le code]Dans le cas d'un développement en équipe, surtout si elles sont réparties dans le monde entier, il est nécessaire de partager une base commune de travail, et c'est tout l'intérêt des systèmes de gestion de version. Mais, il faut aussi veiller à coordonner les équipes de développement grace à des outils de communication, un logiciel de suivi de problèmes, un générateur de documentation et/ou un logiciel de gestion de projets.
Il n'est pas rare que certaines modifications soient contradictoires (par exemple lorsque deux personnes ont apporté des modifications différentes à la même partie d'un fichier). On parle alors de conflit de modifications car le logiciel de gestion de versions n'est pas en mesure de savoir laquelle des deux modifications il faut appliquer.
Le contr?le de la concurrence (en), pour éviter ces conflits de modifications, est un problème classique en informatique : on le retrouve par exemple dans les systèmes de gestion de base de données ou en programmation système. Il peut être géré de deux manières différentes[9], qui ont toutes deux été appliquées à la gestion de version :
- Le contr?le de concurrence pessimiste impose à chaque utilisateur de demander un verrou avant de modifier une ressource ; ce verrou lui garantit qu'il sera le seul à modifier la ressource. Ce modèle s'impose quand on considère que le co?t de résolution des conflits de modification (co?t unitaire pondéré par leur probabilité d'occurrence) est plus important que celui de la gestion du verrou. En gestion de version, il correspond au modèle ?verrouiller-modifier-déverrouiller?[10] qui était utilisé par les systèmes les plus anciens. Il s'est avéré que la gestion manuelle des verrous par les utilisateurs n'était pas toujours satisfaisante : les outils de diff/merge s'améliorant, il est progressivement devenu moins pénalisant de corriger les conflits d'éditions simultanées que de traiter les problèmes de fichiers verrouillés en écriture.
- Le contr?le de concurrence optimiste permet à chaque utilisateur de modifier les données sans contrainte. Au moment d'appliquer ces modifications le système vérifie si un autre utilisateur n'a pas déjà posté des modifications pour ces mêmes données : il demande alors à l'utilisateur de résoudre le conflit avant de re-soumettre ses données. En gestion de configuration, c'est le modèle ?copier-modifier-fusionner? qui a été popularisé par CVS. Il est devenu le paradigme de base des systèmes de gestion décentralisés.
Systèmes centralisés et décentralisés
[modifier | modifier le code]Gestion de versions centralisée
[modifier | modifier le code]Avec les logiciels de gestion de versions centralisée, comme CVS et Subversion (SVN), il n'existe qu'un seul dép?t des versions qui fait référence. Historiquement, cela correspond par exemple à un développement dans une équipe organisation simple, par exemple dans un réseau local (université, entreprise, etc.)
L'unicité du dép?t simplifie la gestion des versions mais a des limites. Une contrainte concerne certains usages comme le travail sans connexion au réseau. Une autre contrainte concerne le travail sur des branches expérimentales ou contestées.
Gestion de versions décentralisée
[modifier | modifier le code]L'outil de gestion de versions décentralisée peut être vu comme permettant à chacun des développeurs ou à chacune des équipes de développeurs de travailler à un rythme indépendant, désynchronisée, puis d'offrir un moyen d'échange des travaux respectifs.
Dans la gestion de versions décentralisée, de fait, et par définition, il existe plusieurs dép?ts pour un même logiciel. Ce système est très utilisé par les logiciels libres qui ne se limitent pas à une organisation ou un organisme centralisé.
Par exemple, GNU Arch, Git et Mercurial sont des logiciels de gestion de versions décentralisée.
En 2010, l'auteur de développement logiciel Joel Spolsky décrit la gestion de version décentralisée comme ? probablement la plus grande avancée dans les technologies de développement logiciel dans les 10 [dernières] années. ?[11], c'est-à-dire entre 2000 et 2010.
Fonctionnalités particulières
[modifier | modifier le code]étiquetage ou marquage
[modifier | modifier le code]Cela consiste à associer un nom à une version donnée. Pour certains outils de gestion de versions (comme CVS) qui gèrent les versions à une faible granularité (beaucoup de modifications non significatives), c'est un moyen de retrouver facilement une version significative.
Verrouillage et notifications
[modifier | modifier le code]Pour le travail en équipe, certains logiciels de gestion de versions apportent des outils pour communiquer.
Par exemple, le verrouillage permet d'interdire la modification d'un fichier, tandis que la notification émet un avertissement à tous les autres membres lorsqu'un fichier est modifié.
Proposition de révision
[modifier | modifier le code]La proposition de révision (PR) est l'action qui consiste à demander au détenteur du dép?t de référence de prendre en compte les modifications que vous avez apportées sur votre dép?t de fork ou votre dép?t local et que vous souhaitez partager au dép?t de référence.
Exemples de logiciels de gestion de versions
[modifier | modifier le code]Les logiciels de contr?le de versions sont nombreux. Sous UNIX, il y a eu SCCS qui a suscité un autre logiciel libre : GNU RCS devenu un standard de fait. CVS, qui gère mieux les arborescences de fichiers que RCS, est devenu extrêmement répandu dans le monde du logiciel libre et dans les entreprises, de par sa simplicité.
Ils ont été progressivement remplacés par des alternatives plus modernes, comme Subversion puis Git, qui sont désormais plus utilisés que leurs prédécesseurs[12]. D'autres logiciels, comme Bazaar ou Mercurial sont des alternatives à Git qui disposent de bases d'utilisateurs conséquentes.
Dans le monde propriétaire, ClearCase, Synergy (d'IBM) et Dimensions (de Serena Software (en)) sont les plus répandus[réf. nécessaire]. Il y a aussi Visual Source Safe et Team Foundation Server (de Microsoft) qui s'intègrent avec Visual Studio. Il existe également AlienBrain, souvent utilisé dans le monde du jeu vidéo car particulièrement adapté à la gestion de ressources graphiques et sonores. L'AGL WinDev (de PCSoft) utilise sa propre implémentation de gestion de versions.
Voir aussi
[modifier | modifier le code]Articles connexes
[modifier | modifier le code]Références
[modifier | modifier le code]- ↑ Martin Goetz, interview par Jeffrey R. Yost, An Interview with Martin Goetz,
- ↑ Joseph Piscipo, interview par Thomas Haigh, An Interview with Joseph Piscopo,
- ↑ Marc J. Rochkind, ? The Source Code Control System ?, IEEE Transactions on Software Engineering, vol. SE-1, no 4, , p. 364–370 (DOI 10.1109/TSE.1975.6312866, S2CID 10006076, lire en ligne)
- ↑ Walter F. Tichy, ? Rcs — a system for version control ?, Software: Practice and Experience, vol. 15, no 7, , p. 637–654 (ISSN 0038-0644, DOI 10.1002/spe.4380150703, S2CID 2605086, lire en ligne [archive du ]
, consulté le )
- ↑ Ben Collins-Sussman, BW Fitzpatrick et CM Pilato, Version Control with Subversion, O'Reilly, (ISBN 0-596-00448-6, lire en ligne
)
- ↑ Jon Loeliger et Matthew McCullough, Version Control with Git: Powerful Tools and Techniques for Collaborative Software Development, O'Reilly Media, , 2–5 p. (ISBN 978-1-4493-4504-4, lire en ligne [archive du ])
- (en) Neil McAllister, ? Linus Torvalds' BitKeeper blunder ?, InfoWorld, (lire en ligne, consulté le )
- ↑ ? Version Control Systems Popularity in 2016 ?, sur www.rhodecode.com (consulté le )
- ↑ ? Types de contr?les de concurrence ?, sur microsoft.com via Wikiwix (consulté le ).
- ↑ ? Modèles de gestion de version ?, sur tortoisesvn.net (consulté le ).
- ↑ (en) Joel Spolsky, ? Distributed Version Control is here to stay, baby ?, sur Joel on Software, (consulté le )
- ↑ ? Eclipse Community Survey 2014 Results ?, sur Ian Skerrett, (consulté le )
