Les Systèmes de Gestion de Versions

Les logiciels contiennent un ensemble de programmes [MEY 00] et évoluent constamment selon les besoins des utilisateurs dans le but de les améliorer. Le résultat après chaque amélioration du programme est appelé version ou révision. Les différentes versions sont nécessairement liées à travers des modifications (une modification est un ensemble d’ajouts, de suppressions, ou de modifications de données). Une modification constitue 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, et le passage d’une version à une version antérieure est établi en supprimant les dernières modifications appliquées au code source du programme [ALT 08] [GUE 11]. Mais avec un nombre important de versions, la récupération du code source d’un programme déterminé devenait de plus en plus difficile et l’existence de plusieurs versions du code source d’un programme obligeait les développeurs à implémenter un système qui permet la gestion de ces versions : c’est le « Système de Gestion de Versions » [HOC 10].

Définition des Systèmes de Gestion de Versions

Un Système de Gestion de Versions, en anglais Version Control System (VCS) ou Source Code Management (SCM) appelé aussi Versionnage (Versionning) est un logiciel contenant un ensemble d’outils qui permettent de stocker et de manipuler un fichier ainsi que toutes les révisions qu’il a subies depuis sa création [BRE 06]. Par exemple, lorsqu’un développeur modifie son code source et par prudence il enregistre régulièrement le code source, ensuite, il quitte l’éditeur du code pour compiler et tester la nouvelle version, puis il se rend compte que ça ne fonctionne pas comme il le désirait et qu’il faut retourner à la version précédente. S’il a ajouté des lignes de code il serait facile de retourner à la version précédente du code en supprimant les lignes ajoutées mais s’il a supprimé des lignes du code ça devient difficile de retrouver la version précédente du code. Pour ce faire, l’utilisation d’un VCS permet au développeur de revenir à un état stable s’il se trompe ou perd des fichiers [PET 10]. Le système de gestion de versions permet de récupérer un fichier ou un projet complet à des états précédents afin de pouvoir les corriger [WHI 04], de comparer les modifications au fil du temps, de détecter le responsable d’une modification erronée causant un problème au niveau d’un fichier, et de détecter la date de la modification. Il permet ainsi de conserver la chronologie historique de toutes les modifications qui ont été effectuées sur un fichier informatique, lorsqu’il est accompagné d’un commentaire contenant toutes les informations nécessaires de la création de la version. Ces systèmes donnent aux utilisateurs la possibilité de travailler en parallèle, tout en gérant les conflits dus au travail en équipe sur les mêmes documents qui contiennent le code source du programme, afin d’éviter le blocage, et ils contrôlent l’accès et la disponibilité des documents tout en respectant la confidentialité du contenu. Un commentaire dans les systèmes de gestion de versions est généralement rédigé par le responsable de la modification, où il explique les raisons de cette modification. Il est fortement conseillé d’écrire un commentaire ce qui facilitera la relecture future des modifications passées.

Ce type de système permet de gérer un code à la fois à travers :
• Le temps : Possibilité d’archiver l’ensemble des versions du code source et d’inverser (reversion) les modifications pour revenir à une version particulière,
• L’espace : Possibilité de faire partir le code dans plusieurs directions séparées (branching), et éventuellement de les rassembler.

Le système de gestion de versions s’applique principalement au code source, mais également à la documentation, aux bases de données, à tout fichier texte et parfois aussi aux logiciels. Les systèmes de gestion de versions sont utilisés notamment en ingénierie du logiciel pour conserver leur code source relatif aux différentes versions d’un logiciel. De ce fait, il est courant de parler de modifications pour un seul document (contenant le code source du programme) et d’ensemble de modifications lorsqu’il s’agit d’un logiciel (un ensemble de programmes), et les deux n’évoluent pas au même rythme. Chaque modification faite constitue une révision.

La gestion de versions est indispensable dans les environnements où plusieurs utilisateurs coexistent; elle leur permet d’accéder facilement et de manière concurrente dans de bonnes conditions à l’ensemble des versions des fichiers pour manipuler et modifier cette même base de ressources. Et un système de gestion de versions permet à un utilisateur de travailler sur une version d’un code et de développer par la suite une nouvelle version indépendamment des autres utilisateurs du système, ou de la rassembler avec une version d’un autre utilisateur tout en gérant les conflits. Un tel système permet à un groupe de développeurs de travailler autour d’un même développement et de stocker toute évolution du code source [WHI 04].

Pour garder l’historique des changements, les VCS introduisent la notion de branche, de tag, et d’arbre de version.

• La branche
La branche est en général créée lorsqu’un développement secondaire est mis en route, que ce soit pour ajouter une nouvelle fonctionnalité ou parce que certains développeurs souhaitent essayer de prendre une autre direction pour certains aspects du développement. Le concept de branches offre la possibilité de dupliquer le code de base dans un point particulier dans le temps   et permet de maintenir ces deux usuelles branches de développement [JGE 05]. Par exemple, lorsqu’une version d’un logiciel est distribuée, il est possible de créer une branche dans laquelle seront faites les corrections des bugs de cette version. Les corrections peuvent ensuite être répercutées dans le tronc si elles s’appliquent aussi aux développements en cours. Ceci permet de fournir une version corrective de la version distribuée. Remarque : le tronc (trunk) est la version originale du fichier code source d’un programme.

• Le tag
Les systèmes de gestion de versions marquent les événements importants dans le cycle de vie d’un code du projet par des étiquettes connues sous le nom de tag [DON 09].

• L’arbre de version
Afin de suivre l’évolution d’un fichier donné, ces systèmes produisent un arbre de version. Ils génèrent la hiérarchie de l’arborescence des versions d’une manière automatique pour chaque fichier qu’ils contiennent. Le numéro de version (renommage) identifie la progression des différents nœuds de l’arbre de version au fil du temps. Plus le nombre est grand, plus la version est récente, et les chiffres apparaissent comme une extension pour montrer l’évolution [BAR 03] [AIX 10].

L’Historique des Systèmes de Gestion de Versions 

Pendant les années 70 les systèmes de gestion de versions ont été utilisés pour stocker et gérer les différentes versions des fichiers en particulier les codes sources. La réalisation du premier système de gestion de versions était le SCCS (Source Code Control System) en 1972. Le SCCS [ROC 75] a été développé pour gérer le code source, la configuration des fichiers, ou des documentations. Il s’est focalisé sur la gestion des fichiers et des utilisateurs. Le SCCS a apporté des mécanismes qui permettent aux développeurs de garder la trace de l’historique d’un fichier, en utilisant le contrôle « checksums » pour détecter la corruption de données [BUR 98]. Le RCS (Revision Control System) [NGU 11] [TIC 85] est un autre système de gestion de versions développé dans les années 1980. Le RCS comme le SCCS supporte un seul utilisateur qui stocke simplement les différentes versions des fichiers dans un fichier système. Mais contrairement à SCCS, le RCS ne conserve aucune trace de l’historique d’un fichier. Cet outil fonctionne en conservant des ensembles de patch (la différence entre les versions d’un fichier) dans un format spécial sur le disque; il peut alors restituer l’état de n’importe quel fichier à n’importe quel instant en ajoutant toutes les différences. En 1989 le célèbre CVS (Concurrent Version System) [BAR 03] [CED 93] a été développé afin d’améliorer le RCS. Ce système apporte plusieurs ajouts, étant donné qu’il supporte de multiples fichiers et de multiples utilisateurs, mais l’avantage majeur de CVS était le support de fusions concurrent des fichiers au lieu d’utiliser un mécanisme de verrouillage; ceci permettait aux développeurs de collaborer dans leurs projets. Cependant le CVS avait certaines limitations concernant la manipulation des répertoires et des fichiers binaires. Avec l’extension de l’Internet, les utilisateurs de CVS critiquaient le manque de support à l’accès à distance; pour cela un groupe de développeurs a mis en œuvre une extension en 1994, afin d’utiliser le CVS sur TCP, en lui permettant d’être utilisé plus facilement sur Internet.

Ensuite dans l’année 2000, la société CollabNet a décidé de développer un système remplaçant le CVS. Ainsi, Ben Collins-Sussman, Brian Behlendorf et Jason Robbins de CollabNet ont débuté le projet de Subversion (SVN) [COL 08] [COL 11]. Le système Subversion est considéré comme un standard de l’industrie. C’est un logiciel Open Source en conformité avec le Debian Free Software Guidelines (DFSG), qui a apporté de nombreux avantages pour les développeurs par une meilleure gestion des fichiers, y compris une structure de répertoire, mettant l’accent sur le projet au lieu que sur les fichiers seulement. Le SVN fournit une interface abstraite du dépôt pour une élaboration facile de différentes méthodes d’accès, tout en garantissant la cohérence [MAS 05].

Avec le développement de Bitkeeper [WOL 04] en 1997 il est apparu une nouvelle approche de gestion de versions, c’est les systèmes de gestion de versions décentralisés. Ces systèmes sont devenus de plus en plus populaires avec le développement de Git [LOE 09] [ZAC 12], Mercurial [SUL 09], Bazaar [BAZ 10] et Darcs [HOC 10]. Le système Git, est développé depuis 2005 comme un projet open source initié par Linus Torvalds. Le projet Git a été lancé dans le but de remplacer le système propriétaire BitKeeper, utilisé pour maintenir le noyau linux et utilisable pour les projets open-source [HOC 10].