Project:Omega.org

Par Kevin O’Malley

traduit par Quentin, le 17/07/2003

Note de l’éditeur: Dans un article précédent, Synchro avec CVS, James Duncan Davidson a expliqué comment partager de l’information entre vos Macs personnels avec CVS. Mais par essence, CVS et les autres outils de contrôle de version sont vitaux pour des projets qui impliquent plusieurs développeurs. Alors que le Mac continue de gagner la faveur de la communauté de développement, nous avons pensé qu’un survol complet du contrôle de version pourrait constituer une série utile sur le Mac DevCenter. Kevin O’Malley commence aujourd’hui cette esploration par une étude de ce qu’est le contrôle de version, sa terminologie, les systèmes disponibles sur Mac OS X, et quelques exemples de base.

Imaginez le scénario suivant. Vous faites partie d’une équipe de développement qui écrit un nouveau compilateur. L’équipe comprend deux développeurs: vous et Bart. Vous allez travailler sur l’avant du compilateur: analyseur lexical et syntaxique. Bart travaillera à l’arrière. Le projet comprend de nombreux fichiers qui effectuent des opérations de base, comme le déboguage et l’enregistrement des messages. Ces fichiers sont placés dans un répertoire public que les développeurs copient dans leur espace de travail si besoin est.

Supposez que Bart implémente une librairie partagée et la place dans l’espace partagé; d’autres développeurs le copient et utilisent la librairie. Au cours du temps, Bart ajoute de plus en plus de fonctionalités, chaque fois en copiant la nouvelle version dans l’espace partagé. Une nuit avant de rentrer chez lui, Bart corrige plusieurs bogues dans la librairie et, comme d’habitude, écrase la version dans l’espace partagé avec la nouvelle version. Bart s’en va pour la nuit. Plus tard dans la nuit, vous copiez la nouvelle librairie dans votre espace local en écrasant la version courante, et continuez le développement. Le problème est que Bart n’a pas testé ses changements et a introduit des bogues dans la librairie qui gênent votre code. Et maintenant vous avez un problème, parce que vous avez écrasé votre version précédente et que Bart est parti pour la nuit. A ce niveau, votre travail s’arrête jusqu’à ce que Bart revienne et corrige les bogues.

Maintenant, imaginez que Bart revient le jour d’après, découvre qu’il y a un problème et commence à corriger les bogues. Peu après, il se rend compte qu’il y a trop de problèmes, et décide de revenir à une version plus ancienne. Malheureusement, sa dernière sauvegarde date d’une semaine, et de nombreux changements ont eu lieu durant cette semaine. Il ne lui reste alors que deux choix, recommencer &agraver; partir de l’ancienne version ou déboguer la dernière copie.

Ceci ne correspond en aucun cas à la manière dont la plupart des projets sont gérés, mais il y a quelque vérité dans cet exemple (quand même fictif). En fait, je suis sûr que nous avons tous travaillé sur des projets où ceci est arrivé. Cet exemple illustre le fait que les projets gérés sans aucune sorte de management de logiciel peuvent se révéler coûteux, sources d’erreurs, et peu amusants.

Une réponse à le gestion de projet de cette manière est d’implémenter une forme de contrôle de version. Le contrôle de version est un processus simple et efficace qui supporte tout effort de développement — qu’il se fasse seul ou que ce soit un projet important. Si vous n’utilisez pas encore le contrôle de version actuellement, ou que vous ne l’avez jamais utilisé, voici votre chance.

Ceci constitue le premier d’une courte série d’articles destinés à vous donner toute l’information dont vous avez besoin pour comprendre les bases du contrôle de version et à vous montrer comment l’intégrer facilement dans votre processus de développement. Cette connaissance, non seulement vous aidera dans vos propres projets, mais aussi vous permettra de rejoindre et de contribuer à des projets open source et de créer des mises à jour.

Cet article présente les bases du contrôle de version en vous exposant ce que c’est, sa terminologie, les systèmes disponibles sur Mac OS X, et quelques exemples de base. Le second article appliquera cette connaissance en vous montrant comment utiliser Concurrent Versions System (CVS, Système de Versions Concurrentes) et ses commandes sous Project Builder, l’Environnement de Développement Intégré d’Apple (IDE) mis librement à disposition afin d’écrire des applications Mac OS X. Le dernier article présentera quelques sujets CVS avancés pour la création et la gestion de mises à jour logicielles, des astuces pour utiliser CVS avec Mac OS X, et concluera par une comparaison de l’interface en ligne de commande de CVS avec les interfaces graphiques utilisateurs Mac OS X telles que Project Builder et BBEdit.

Après la lecture de cette série, vous serez en bonne voie pour inclure le contrôle de version dans votre procesus de développement, et comprendre ce que l’utilisation de CVS sous Mac OS X demande.

Le Contrôle de Version, Qu’est-ce-que c’est ?

Commençons par regarder ce qu’est le contrôle de version. A la base, le contrôle de version est un processus, supporté par les logiciels, qui vous aide à enregistrer les changements apportés aux fichiers sources de votre projet, organiser les mises à jour, et contrôler l’accès aux fichiers partagés. La plupart des projets implémentent un quelconque contrôle de version, même s’il se réduit à tar-er vos répertoires de projets en des points définis de celui-ci. A la vérité, sans contrôle de version, votre projet peut facilement devenir un foutoir sans nom, de plus en plus difficile à gérer au fur et à mesure de son évolution

En utilisant des logiciels de contrôle de version,vous facilitez la gestion efficace de l’historique des modifications et révisions des fichiers au cours du cycle de vie d’un projet. Le contrôle de version est un sujet important dans une discipline de l’ingénierie logicielle appelée Software Configuration Management (SCM, Gestion de Configuration Logicielle). SCM est un mécanisme, institué au travers de processus définis, dont le but est de s’assurer de la classification, du contrôle, et de la traçbilité d’un système logiciel au cours de son cycle de vie. Il est implémenté en utilisant des outils et procédures logiciels destinés à remplir ces objectifs. La gestion de configuration était bien implantée dans l’industrie de la défense dès le début des années 1960, tentative précoce de contrôler par la gestion la complexité grandissante des designs et du processus de design.

Conceptuellement, pensez au contrôle de version en termes similaires à une analyse statique de code (alertes compilateur ou outils lint). Par exemple, le fait d’autoriser les messages d’alerte compilateur jusqu’à leur plus haut niveau demande au compilateur de vérifier les constructions de langage et de programmes potentiellement dangereuses ou qui pourraient provoquer des erreurs de runtime ou des résultats inattendus. Ceci place effectivement un filet sous votre cycle de création et vous offre une certaine assurance que des erreurs subtiles seront détectées à l’avant, à la compilation. L’ajout du contrôle de version apporte une assurance similaire à votre processus de développement en fournissant une aide à la gestion de nombreux éléments importants du cycle de vie de votre projet.

Par exemple, le contrôle de version vous permet de revenir à d’anciennes versions de votre code source, de créer et d’administrer les mises à jour de votre programme, et facilite les changements dans le code source intermédiaire sur des projets faisant intervenir plusieurs développeurs. Par essence, cela vous fournit un mécanisme ayant fait ses preuves dans la résolution de nombreux problèmes de gestion logicielle que, par le passé, la plupart d’entre nous résolvait avec des techniques d’origine différente, et parfois chaotiques.

L’un des premiers systèmes de contrôle de version disponible sur la plate-forme UNIX a été le Source Code Control System (SCCS, Système de Contrôle de Code Source), développé par Marc Rochkind aux Bell Telephone Laboratories en 1972. Actuellement, les deux systèmes de contrôle de version les plus populaires du monde UNIX fonctionnant sous Mac OS X sont le Revision Control System (RCS, Système de Contrôle de Révision), écrit par Walter F. Tichy au début des années 1980 alors qu’il était à la Purdue University, et le Concurrent Versions System (CVS, Système de Versions Concurrentes), construit sur RCS et qui utilise plusieurs programmes RCS pour agir. RCS et CVS sont tous les deux disponibles sur Mac OS X. Vous les installez avec les Outils de Développement d’Apple.

Une première différence entre RCS et CVS tient à leur manière d’interagir avec de multiples utilisateurs. RCS implémente le modèle bien nommé “verrouille-modifie-déverrouille” (consultez Open Source Development with CVS, 2nd Edition, par Karl Fogel et Moshe Bar), grâce auquel un simple développeur acquiert l’accès en écriture exclusif à une ressource par le verrouillage de fichiers. Quand un fichier est sorti, RCS place un verrou sur le fichier, qui empêche quelqu’un d’autre de le sortir et d’écrire sur le même fichier (bien qu’il puisse être sorti pour lecture). Quand le fichier est repassé par RCS, le verrou est enlevé, ce qui permet aux autres de sortir et d’éditer ce fichier. Ce modèle simplifie le contrôle de version et permet d’esquiver de nombreux problèmes non nécessaires. Par exemple, quand de nombreux développeurs éditent le même fichier simultanément, l’un peut en arriver à casser le code d’un autre. Une simple sortie les oblige à se parler et à résoudre tout conflit avant de changer le code.

CVS, par contre, utilise le “copie-modifie-fusionne” (consultez aussi Open Source Development with CVS, 2nd Edition, par Karl Fogel et Moshe Bar). Ici, les multiples développeurs sont autorisés à sortir, éditer et renvoyer le même fichier. Si des conflits se produisent, CVS les enregistre et tente de fusionner les changements dans le code de base de chaque développeur. Des conflits peuvent quand même persister, mais ils sont souvent simples à résoudre. Cette technique permet à de nombreuses personnes de travailler en parallèle et CVS incorporera les changements de chaque développeur si nécessaire.

CVS et RCS sont tous deux d’excellents choix de systèmes de contrôle de version. Les deux sont largement populaires, exceptionnellement stables, et disponibles sous Mac OS X. Pour cette série d’articles, nous utiliserons CVS comme système de contrôle de version.

Un Exemple CVS

Maintenant que vous comprenez les fondamentaux, étudions quelques bases de terminologie CVS. CVS conserve l’historique complet des modifications de votre projet dans un endroit central appelé un dépôt. Le dépôt agit comme une zone de stockage pour toutes les différentes versions de vos fichiers placés sous contrôle de version. En fait, un simple dépôt supporte souvent différents projets. Pour pouvoir suivre l’historique des modifications d’un fichier, CVS ne conserve pas la version complète de chaque fichier modifié, mais simplement les différences entre fichiers. Ces différences, ou révisions, sont juste les modifications entre chaque version successive d’un fichier. Ne conserver que les différences entre fichiers constitue un mécanisme compact et efficace d’enregistrement de l’historique des changements d’un fichier. La version la plus récente d’un fichier conservé sous CVS est appelée la head version. Chaque version différente d’un fichier est appelée une révision.

Regardons un exemple très simple illustrant la manière d’utiliser CVS sur un projet. Imaginons que vous envisagiez de développer un nouveau programme Cocoa. Tout d’abord, vous lancez Project Builder, sélectionnez New Project, et créez votre nouvelle application Cocoa. Après avoir créé votre projet, la première chose à faire est de dire à CVS de placer le projet sous contrôle de version. Pour cela, vous informez CVS de commencer à parcourir votre projet durant tout son cycle de vie. Pour placer votre projet sous contrôle de version, vous enregistrez, ou importez, votre nouveau projet dans CVS comme première version du programme. Puis vous contrôlez le projet, ce qui copie les fichiers du projet, ainsi que quelques fichiers d’administration CVS, sur votre espace de travail local. Les détails des fichiers d’administration ne sont pas importants; ils sont utilisés en interne par CVS pour chercher les changements dans votre projet. Vous avez maintenant la première version de votre programme sous contrôle de version et une copie locale pour le développement. La copie locale est votre copie de travail.

Une fois un projet placé sous contrôle de version, CVS se charge de chercher les changements dans vos fichiers et d’organiser l’historique conservé. Cependant, CVS est un système passif, non actif. Pour que CVS fasse son boulot, vous devez lui fournir des informations en chemin. Par exemple, comme vous commencez le développement, l’ajout de fonctionnalités à votre programme, vous voudrez sans doute parler à CVS des changements, afin qu’il les ajoute à l’historique de votre projet. Pour cela, vous remettez vos changements à CVS, et CVS les enregistre dans le dépôt du projet.

Comme le développement se poursuit, vous ajoutez des fichiers au projet et peut-être en retirez des fichiers. Ces informations doivent aussi être fournies à CVS. Pour ajouter un fichier à CVS, vous ajoutez d’abord le fichier pour que CVS le sache, puis vous remettez le fichier, ce qui dit à CVS de l’inclure dans l’historique de votre projet. CVS supporte aussi l’effacement de fichier par la commande remove.

Durant la construction du projet, vous pourriez vouloir obtenir des informations sur les différents fichiers sous contrôle de version. Par exempls, imaginez que vous souhaitez voir quels changements ont été faits entre deux révisions d’un fichier. Pour ce faire, vous utilisez la commande CVS diff, qui compare les fichiers spécifiés et affiche leurs différences.

Une fois la première version de votre programme prête à fonctionner, vous devez créer une sortie. CVS possède deux commandes qui vous aident à accomplir ceci: les commandes tag et branch . Je couvrirai les deux commandes en détail dans l’article final, mais rapidement, un “tag” est une étiquette associée à un ensemble de fichiers en relation dans votre projet. Le développement se poursuivant sur la copie de travail, et vous continuant à fournir les révisions à CVS, le tag reste fixé, ou accroché, aux fichiers qui lui sont associés. A tout moment, vous pouvez retirer tous les fichiers associés au tag avec une commande CVS. Les branches vous permettent de créer et de gérer différentes versions de vos logiciels (versions de sortie, de déboguage, versions optimisées, etc.) sans déranger le code que vous développez actuellement.

Comme je l’ai dit plus tôt, CVS est destiné à manipuler des éditions concurrentes de fichiers. Dans cet exemple, ce n’est pas un enjeu. Cependant, sur des projets faisant intervenir de multiples développeurs, une tâche commune est d’obtenir les fichiers que d’autres développeurs ont ajoutés au projet, et d’obtenir les changements de fichiers existants. Pour cela, vous dites à CVS de mettre à jour votre copie de travail. La commande update copie tout nouveau fichier du dépôt dans votre copie de travail, et met à jour tout fichier existant avec les dernières révisions du dépôt. Puisque CVS implémente le “copie-modifie-fusionne”, il tente de fusionner toute nouvelle version d’un fichier avec votre copie de travail. Si des conflits apparaissent, CVS les notera, et il ne vous reste plus qu’à les résoudre manuellement.

Conclusion

Cet article a tenté de vous transmettre les bases du contrôle de version en décrivant ce que c’est et comment cela peut vous aider sur un projet. CVS est un très bon système de contrôle de version, très puissant et librement disponible sur Mac OS X. Dans de futurs articles, je vous montrerai comment appliquer ce que vous savez au développement d’un programme Cocoa sous Project Builder, et comment utiliser CVS pour gérer les révisions et sorties de logiciels.

J’espère que vous avez apprécié cette brève introduction au contrôle de version et à CVS, et que vous attendez avec impatience d’en savoir plus. Assurez-vous d’aller voir la section Ressources pour plus d’informations sur SCM et les systèmes de contrôle de version.

Kevin O’Malley est un développeur Macintosh et UNIX de longue date. Ses articles sont parus dans Dr. Dobb’s Journal, IEEE Internet Computing, and The Perl Journal.

Textes originaux en anglais sur O’Reilly : Verion Control on Mac OS X, Part 1 par Kevin O’Malley

quentin Développer sur Mac OS X CVS, SubVersion, Versionning