Histoire et concepts essentiels des systèmes de gestion de sources, du local au distribué en passant par le centralisé

Tous les projets logiciels sérieux ont recours à un système de gestion de code source, parfois appelé logiciel de gestion de versions. Ces systèmes permettent à une équipe de conduire l’élaboration du code source dans de bonnes conditions de collaboration, de communication et de sécurité. Ce n’est pas un hasard si ces trois notions, fondamentales pour la gestion de projet, sont également au cœur de la plateforme collaborative AtikTeam.

RCS

Dans les années 1980 est apparu le premier système de gestion de version, appelé RCS, conçu pour qu’un utilisateur puisse contrôler les révisions d’un fichier.

CVS

Le concept était important, mais encore inadapté dans le cadre d’un projet logiciel impliquant un arbre de fichiers et toute une équipe projet. C’est pourquoi, au début des années 1990 s’est développé le célèbre CVS, logiciel destiné à permettre à des équipes de développer des projets complets. Techniquement, CVS s’appuie sur son prédécesseur RCS, en lui ajoutant une couche de transmission de fichiers par le réseau, et une autre de gestion de plusieurs fichiers (toutefois indépendants les uns des autres). Voici ce que dit l’auteur original des premières lignes de CVS :

I created CVS to be able to cooperate with my students, Erik Baalbergen and Maarten Waage, on the ACK (Amsterdam Compiler Kit) C compiler. The three of us had vastly different schedules (one student was a steady 9-5 worker, the other was irregular, and I could work on the project only in the evenings). Their project ran from July 1984 to August 1985. CVS was initially called cmt, for the obvious reason that it allowed us to commit versions independently.

– Dick Grune

Subversion

Le déploiement de CVS a grande échelle a révélé de nombreuses faiblesses dans son modèle :

• la base de données, simple dossier dans le système de fichiers, n’était pas atomique et présentait donc le risque d’être dans un état non-déterminé ;
• le modèle de gestion des collections de fichiers ne pousse pas à considérer l’ensemble du projet comme une seule et même œuvre, et permet donc de suivre indépendamment les modifications de chaque fichier. La conséquence courante est une incohérence dans les versions des fichiers du projet ;
• les opérations du système de fichiers ne sont pas versionnées (déplacement, suppression, etc.).

C’est précisément pour combler ces lacunes qu’est né en 2000 le projet Subversion. Le modèle reste proche de celui de CVS, mais solutionne ses graves limitations, en particulier grâce à :

• des commits (livraison de modifications) atomiques ;
• une notion de projet (composé d’une collection de fichiers) suivi dans sa globalité ;
• un suivi des opérations du système de fichiers sans perdre l’historique de chaque élément.

Aujourd’hui, Subversion est un système de gestion de sources très répandu, mature et intégré à de nombreux outils. En activant le module correspondant, AtikTeam inclut un dépôt Subversion dans le projet, permettant ainsi d’intégrer parfaitement gestion de sources et gestion de projet.

Mercurial et Git

Si le modèle de Subversion se prête bien aux projets de taille raisonnable, conduits par une équipe organisée dont les responsabilités sont pré-établies, il trouve rapidement ses limites dans le cas de grands projets open-source conduits par des milliers de contributeurs potentiels :

• le dépôt, central par conception, est fortement sollicité et il faut parfois faire la queue pour y envoyer son travail ;
• le dépôt central contraint les développeurs à disposer d’une connexion internet pour créer une nouvelle version (par un commit) ;
• les branches thématiques, groupées en un unique dépôt, deviennent rapidement trop nombreuses donc difficiles à gérer ;
• l’attribution des autorisations pour livrer (commit) est un travail compliqué pour des projets logiciels de plusieurs milliers de développeurs.

Face a ce constat sont apparus deux nouveaux outils, très proches par conception, proposant un nouveau modèle distribué (décentralisé) pour la collaboration : Git et Mercurial. Dans ce nouveau modèle, il n’y a plus de dépôt central dans lequel livrer, et chaque développeur devient responsable de son propre dépôt personnel. Dans ce dépôt, il peut :

• livrer son travail, sans que cela ne nécessite de connexion internet, ni d’autorisation particulière, par l’opération commit ;
• intégrer le travail de ses collaborateurs, par l’opération pull.

Rien de spectaculaire à première vue, pourtant le changement de modèle est radical. On passe d’un système organisé pour que les développeurs poussent leur travail dans un unique dépôt commun à un système sans unique dépôt de référence, sans possibilité de pousser, mais avec seulement la possibilité de tirer, c’est à dire de récupérer le travail d’un collaborateur en l’intégrant au sien. Autrement dit, l’initiative de l’intégration change de main, passant de celle de l’auteur à celle de l’utilisateur des modifications. Le déploiement le plus célèbre d’un tel modèle est certainement celui du noyau Linux. En consultant le journal du dépôt de Linus Torvald, on constate que son activité principale consiste à intégrer le travail de quelques proches collaborateurs, qui font de même avec leurs propres collaborateurs de confiance.

Bilan

Le modèle distribué, dernier né des modèles de gestion de code source, présente de nombreux avantages, au prix d’une complexité conceptuelle plus élevée. L’outil de travail collaboratif AtikTeam fonctionne par conception comme un référentiel de travail pour les équipes des projets, ce qui explique le choix de fournir une intégration avec Subversion.