Manipuler des milliers de lignes de code, réparties entre plusieurs dizaines voire plusieurs centaines de développeurs, demande des outils spécifiques, tant pour le suivi de l’écriture que pour agréger les différentes parties du code. À l’origine, les développeurs se contentaient d’archiver les fichiers sources du logiciel. Mais cette méthode entraîne une importante perte de place et une lourdeur dans la gestion des développements. Aujourd’hui, on a recours à un gestionnaire de configurations logicielles, ou SCM (Software Configuration Manager), programme capable de manipuler un ensemble de fichiers contenant les codes en cours d’élaboration. Les SCM de première génération, apparus sous la forme d’utilitaires pour lignes de commande Unix, comme SCCS ou RCS (Revision Control System), enregistrent les différences entre les fichiers du programme après modification et un état initial de référence.
Le mécanisme de CVS s’inspire de la bibliothèque
CVS (Current Versions System) est un SCM de deuxième génération. Les projets sont enregistrés sous forme de modules dans la base CVS. Les commandes Add et Remove modifient la liste des fichiers constituant un mo-dule. La commande Commit archive les fichiers du module courant dans la base CVS, avec mise à jour automatique du numéro de version, indication de l’auteur et de la date des modifications. À chaque fois, le développeur doit saisir un commentaire décrivant les changements apportés au programme. Sauf commande spéciale, la mise à jour n’est possible que si l’utilisateur travaille sur la dernière version en date. Grâce à son système de branches, CVS offre un niveau de liberté supplémentaire pour faire évoluer différentes variantes d’un projet. Pour extraire une copie de travail d’un module depuis la base, le développeur utilise la commande Checkout.Les SCM fonctionnent selon la métaphore de la bibliothèque : un Checkout signifie que l’on emprunte un module (ou un fichier), lequel ne peut être modifié par personne d’autre jusqu’à sa restitution (Commit). Cela correspond à peu près au comportement de CVS en mode verrouillé, mais il est rarement utilisé ainsi. En général, plusieurs utilisateurs peuvent demander des copies indépendantes et un même utilisateur peut demander plusieurs copies pour travailler sur des modifications indépendantes. Par défaut, Checkout récupère la dernière version de la branche principale du projet, mais il est possible de changer de branche ou de revenir à une date ou à un numéro de version antérieurs, que ce soit pour l’ensemble du projet ou pour des fichiers précis. Si, au moment de l’archivage, CVS détecte qu’un autre utilisateur a modifié l’un des fichiers du module depuis le dernier Checkout, Commit échoue.La fonction Status indique l’état des fichiers : modifiés par d’autres utilisateurs, verrouillés, etc. Dans le cas le plus fréquent – fichiers en cours de mise à jour par d’autres utilisateurs -, la commande Update fusionne la copie de travail avec la version archivée. La fusion peut être automatique ou nécessiter une édition manuelle si elle porte sur la même portion du fichier, l’archivage n’étant alors possible qu’une fois la fusion terminée. Des mécanismes similaires permettent aussi de fusionner différentes branches d’un projet. Malgré un processus laborieux, le mode sans verrouillage de CVS pose peu de problèmes, à la condition que les tâches des divers développeurs soient coordonnées. Les projets importants avec de nombreuses contributions externes utilisent souvent un processus à deux niveaux pour pallier les défauts du mécanisme (lire encadré). Il existe aussi un mode pseudo-verrouillage, où les utilisateurs indiquent le fichier sur lequel ils travaillent, donnant ainsi une information accessible aux autres membres de l’équipe. Enfin, un mécanisme de notification permet d’avertir un utilisateur qu’un fichier surveillé est modifié.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
