La gestion de versions Vitthagna Barnier Paul Clément 1
Gestion de versions La ges tion de versions : en anglais: version control ou revision control activité qui consiste à maintenir l'ensemble des versions ou révisions d'un logiciel ou autre document. utilisée dans le domaine de la création de logiciels : code source en particulier applicable à tout type de document informatique activité fastidieuse et complexe intérêt d'un logiciel de type gestion de versions existence de différents logiciels de gestion de versions concepts essentiels communs vocabulaire et usages propres 2
Gestion de versions Les vers ions : Evolution d'un logiciel une étape d'avancement est appelée vers ion les différentes versions sont liées à travers des m odific a tions. Une modification peut correspondre à : ajouts, modifications, suppressions ou une combinaison des trois sur une version donnée. Schématiquement : passage de la version N à la version N + 1 en appliquant une modification M. Possibilité de revenir à la version N grâce à un logiciel de gestion de versions. Les concepteurs du logiciel de gestion de versions RCS ont choisi de parler de «révisions» (revisions) afin de ne pas confondre la version du logiciel avec les «révisions» de ses fichiers sources. Pour des raisons pratiques, on associe généralement un «numéro» à une version. 3
Gestion de versions M odific a tions et ens em ble de m odific a tions : Modification : é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. Gestion de versions sur un ensemble de fichiers : projet. De manière générale, on parle de : modifications pour un seul fichier d'ensemble de modifications (change set) pour un projet (plusieurs fichiers). Evolution asynchrone entre un projet et ses fichiers. 4
Gestion de versions M odific a tions et ens em ble de m odific a tions : 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. 5
Gestion de versions B ra nc hes : Branches : modifications divergentes sur un ensemble de fichiers. Fus ion de bra nc hes : convergence des 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. 6
Gestion de versions C onflit de m odific a tions : Contexte : développement en équipe Solution : chacun travaille de façon indépendante système de gestion de version nécessité de fusions régulières pour l'avancement global du logiciel. Problème possible : modifications contradictoires courantes (par exemple : 2 personnes apportent des modifications propres à la même partie d'un fichier). on parle alors de conflit (de modifications) : incapacité pour le logiciel de gestion de versions de savoir quels changements opérés utilisation d'une 3è version? 7
Gestion de versions Fonctionnalités notoires des log iciels de g es tion de vers ions : Étiquetage ou marquage : 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. Comparaison : Comparer plusieurs versions pour en extraire les modifications. Verrouillage et notifications : Outils de communication pour le travail en équipe grâce à certains logiciels Exemple : verrouillage : interdire la modification d'un fichier notification : envoie d'un avertissement à tous les autres membres lorsqu'un fichier est modifié. 8
Gestion de versions Tronc, branches et taillis inextricable : Développement progressif d'un logiciel formé d'un très grand nombre de fichiers, puis de corriger les bogues, d'ajouter les nouvelles fonctionnalités, de développer des variantes incompatibles, etc. Une équipe trop nombreuse, trop dispersée, travaillant sur trop de versions simultanées du même logiciel rencontrera vite des problèmes apparemment techniques Au-delà d'une certaine complexité : règlementé l'utilisation du logiciel de contrôle par de nombreuses bonnes pra tiques complété par d'intenses activités de communication et de test. En fonction du volume, d'autres outils peuvent alors devenir nécessaires pour structurer, encadrer et archiver ces activités. 9
Gestion de versions S ys tèm es c entra lis és et déc entra lis és : CVS et Subversion sont des logiciels c entra lis és : un seul dépôt des fichiers (référence). Cela peut simplifier le modèle mais peut être contraignant pour certains usages (travail sans connexion au réseau ou tout simplement travail sur des branches expérimentales ou bien contestées). Il existe donc également des logiciels déc entra lis és comme Mercurial, darcs, Bazaar ou Git : plusieurs dépôts dont aucun n'a de statut privilégié. 10
Gestion de versions Log ic iels de g es tion de vers ions Loc a l Libre : RCS SCCS Modèle client-s erveur Libre : CVS JediVCS MECASP, So6 Subversion (SVN) 11
Gestion de versions Logiciels de gestion de vers ions Modèle client serveur Propriétaire : ALDON Lifecycle Manager : Société ALDON ClearCase : Société Rational Software/IBM MKS Integrity Perforce SCM Surround : Société Seapine Telelogic Synergy Vault : Société SourceGear Visual SourceSafe : Société Microsoft 12
Gestion de versions Logiciels de gestion de vers ions Dis tribué Libre : Bazaar Propriétaire : DaRCS git : utilisé entre autres pour le noyau GNU/linux GNU Arch Mercurial Monotone PVCS SVK, basé sur le système de fichier de Subversion BitKeeper Liste plus complète sur : http://en.wikipedia.org/wiki/list_of_revision_control_software 13
Un Système de gestion de versions: Subversion 14
Très répandu Successeur de CVS Reprend sa syntaxe Possibilités de supprimer, renommer des répertoires Les méta-informations associées aux fichiers et répertoires peuvent être elles-mêmes versionnées Utilisation des ports 80 et 443, non bloqués par les firewalls Les c om m its, ou publications des modifications sont atomiques. Un serveur Subversion utilise de façon sous-jacente une base de données capable de gérer les transactions atomiques (le plus souvent Berkeley DB) ; Plus d'infos sur les différences entre CVS et SVN sur http://svnbook.red-bean.com/en/1.0/apa.html Grand nombre d'outils disponibles Adaptation des EDI grâce à des plugs-in (Eclipse, NetBeans, Emacs,...) 15
Documentation en ligne : Site de Subversion : http://subversion.tigris.org Livre en ligne sur SVN : http://svnbook.red-bean.com Tutoriel SVN : http://www.fil.univ-lille1.fr/~durif/svn/svn.html Refcard SVN : http://www.cs.put.poznan.pl/csobaniec/papers/svn-refcard.pdf Bonnes pratiques SVN : http://subversion.open.collab.net/articles/best-practices.html 16
Concepts et opérations de base 17
Organis ation s ous S VN : 3 branches /trunk : arbre de développement. C'est dans ce répertoire que vous développerez normalement votre projet. Référentiel. /branch : stocke les branches conséquences de la création d'un correctif sur les versions antérieures à celle en cours de développement. /tag : stocke les différentes versions officielles de votre projet. Il ne doit jamais y avoir de développement ici car ce répertoire ne recevra que des copies de trunk ou des branches. Développement de l'application et aboutissement à une première version 1.0. 18
Afin de ne pas laisser dormir le projet, les développeurs continuent le développement du projet pour préparer la future version majeure: la 2.0 Le projet ayant beaucoup de succès, des bogues sont remontés dans le gestionnaire de bogues (bugtracker). Comme il n'est pas possible de sortir pour le moment la version 2.0, qui n'est encore qu'en phase de développement, les développeurs chargés de maintenir la version 1.0 vont récupérer celle-ci dans le référentiel de Subversion (/tag 1.0) pour commencer le développement d'une version mineure 1.1. Pour cela, ils créent une branche comme indiqué ci-dessous: 19
Ils effectuent les modifications nécessaires et appliquent les patchs (correctifs) envoyés par les utilisateurs de la version 1.0. Lorsque tout semble bon, ils versionnent cette correction et l'étiquettent 1.1 => disponibilité d'une nouvelle version: Dès que tout semble bon, les développeurs reprennent le développement de la version majeure 2.0. Lorsque tout semble bon, ils la versionnent et la publient en 2.0 en la copiant dans le /tag 20
Fus ion de branches : MERGE Répercutions des modifications d'une branche à une autre grâce à la commande «svn merge» Exemple : fusion de la dernière révision de la version 1.1 sur le tronc (/trunk) sur lequel le développement s'est poursuivit. Mots-clés d'accès aux révisions : HEAD : dernière révision (version) d'un projet dans le repository. BASE : révision initiale ("pristine") lors de l'import dans la copie de travail locale COMMITTED : dernière révision de la copie locale validée dans le repository (>=BASE). PREV : révision juste avant la validation dans le repository (COMMITTED- 1) 21
Importation : IMPOR T Import du projet dans le dépôt Ne jamais travailler directement dans le dépôt, privilégier une copie locale 22
Copie locale : CHECKOUT (ou CO) Récupération via numéro de révision ou par date (option -r) Logiquement, chaque développeur ne fait cette opération qu'une fois par projet. 23
Etat de la copie locale : S TATUS Connaître l'état de la copie locale Fichiers ajoutés/modifiés/supprimés Numéros de révision Origine de copie locale : INFO 24
Mis e à jour de la copie locale : UPDATE (ou UP) Ajout d'une res s ource au référentiel : ADD 25
S uppres s ion d'un fichier de la copie locale : DELETE (ou DEL, ou REMOVE ou RM) Copie d'un fichier d'un répertoire à un autre dans la copie locale : COPY (ou CP) Est également utilisée pour créer des branches ou des tags 26
Déplacer/Renommer une res s ource dans la copie locale : MOVE (ou MV ou RENAME ou REN) Annuler des modifications dans la copie locale : R E VER T 27
Connaître les différences d'un fichier de la copie locale avec la révision de ce même fichier s ur le référentiel : DIFF Permet de créer des patchs 28
S uivre l'évolution dans le temps d'une res s ource de la copie locale ou du référentiel : LOG Obtenir de l'aide s ur les commandes S VN: HELP 29
Valider les modifications de la copie locale et les répercuter s ur le référentiel : COMMIT Un commentaire permet d'identifier les modifications 30
Ges tion des conflits : Si le conflit ne correspond pas à la même ligne, les deux fichiers sont fusionnés (merge) Si le conflit correspond à la même ligne, on résout le problème à la main et on utilise «svn resolved» pour retirer l'état de conflit de la copie locale. 31
Cycle de travail typique: 1. M.à.j. de la copie de travail : svn update 2. Apporter des modifications svn add copy delete move 3. Visualiser les modifications svn status (-u) diff revert 4. Fusionner les modifications svn merge resolved 5. Enregistrer les modifications svn commit 32
TP1 33
Opérations avancées 34
Les propriétés sont: Des méta-données Associées à un fichier ou à un répertoire Composées d'un nom et d'une valeur Définies et manipulées par les developpeurs Versionnées Les commandes sont: svn propset (ou pset ou ps) svn propget (ou pget ou pg) svn proplist (ou plist ou pl) svn propdel (ou pdel ou pd) svn propedit (ou pedit ou pe) 35
Il existe des propriétés automatiques placées par subversion sur les fichiers : svn:executable : nouveau fichier dont le bit exécutable est défini. Et des propriétés standardisées à placer manuellement: svn:mime-type : type mime du fichier Configuration de svn pour mapper des propriétés automatiquement avec des types de fichier : http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html svn:keyword : infos sur la personne, la date, le numero de revision, et l'url du fichier du dernier «commit» svn:ignore : permet de ne pas soumettre un fichier au contrôle de version svn:eol-style svn:exernals svn:special svn:need-locks 36
C onfig uration: /.subversion/config Exemple: [miscellany] global-ignores = *.o *.lo *.la.ds_store enable-auto-props = yes [auto-props] *.c = svn:eol-style=native *.cpp = svn:eol-style=native *.h = svn:eol-style=native *.dsp = svn:eol-style=crlf *.dsw = svn:eol-style=crlf *.sh = svn:eol-style=native;svn:keywords=id *.pl = svn:eol-style=native;svn:keywords=id *.txt = svn:eol-style=native;svn:keywords=id *.png = svn:mime-type=image/png *.jpg = svn:mime-type=image/jpeg *.gif = svn:mime-type=image/gif *.svg = svn:mime-type=image/svg+xml *.html = svn:eol-style=native;svn:keywords=id *.php = svn:eol-style=native;svn:keywords=id 37
Utilis ation de s cripts : Configuré au niveau du server Enrichit le comportement de subversion Déclenchable lors d'une action sur le référentiel (avant, pendant ou après un commit) Exemples de scripts as s ociés : envoi d un email de notification après chaque commit interdire les messages de journaux vides obliger à mentionner un numéro de bogue pour les messages de journaux d une certaine branche enrichir les règles de contrôle d accès déclencher une copie de sauvegarde du référentiel après chaque commit permettre la modification d un message de journal sauvegarder les valeurs des propriétés non versionnées 38
Ges tion des conflits : le verrouillage Verrouillage optimiste car dans la pratique courante, deux développeurs peuvent travailler sur un même fichier, mais rarement sur les mêmes parties svn lock Fichier verrouillé avec status 'K' ou 'O' Un commit réussi retire tous les verrous svn unlock : utilisable par tous les développeurs 39
Protocoles d'accès : svn:// svn+ssh:// http:// https:// file:// 40
Différents outils pour une utilisation de subversion plus confortable : http://www.labo-linux.org/articles-fr/subversion-le-travail-communautaire-sur-fichier/les-outils-pour-subversion TurtoiseSVN : http://tortoisesvn.tigris.org/ Client graphique Subversion intégré à l'environnement Windows SCPlugin : http://scplugin.tigris.org/ Equivalent Subversion pour Mac OS X (finder) Subclipse : http://subclipse.tigris.org/ Plug-in SVN pour Eclipse 41
ClearCase 42
ClearCase Vendu et développé par IBM sous le nom de Rational ClearCase Gestion de versions de fichiers Offre les mécanismes de base pour gérer une configuration d'un logiciel. C est-à-dire qu'il permet d'identifier l'ensemble des versions de fichiers qui constituent une version d'un produit logiciel. 43
ClearCase ClearCase permet : travailler en parallèle sur le code source logiciel. si on considère que le code source de référence est sur une branche principale, alors le développeur, qui souhaite faire des modifications sans pour autant interférer sur celle-ci, a la possibilité de créer une branche parallèle de développement et ainsi avoir sa propre configuration logicielle. Seuls lui et les personnes qui le souhaitent peuvent voir son travail. Une fois son développement finalisé et testé, il a la possibilité de fusionner son travail depuis sa branche parallèle vers la branche principale afin que tous les développeurs puissent avoir accès au nouveau code source logiciel. 44
ClearCase ClearCase permet : développement en multi-site. C est-à-dire que des développeurs de plusieurs villes ou pays peuvent travailler en parallèle sur le code source logiciel comme décrit ci-dessus. Pour cela, le code source logiciel est dupliqué (on parle de réplication) : autant de copies que de sites et chaque équipe travaille sur sa copie du logiciel. Le mécanisme de synchronisation permet aux différentes copies de récupérer les modifications effectuées par les autres. La synchronisation peut être manuelle ou bien automatique, et sa fréquence peut être programmée (en général toutes les 15 minutes si l'entreprise dispose d'une bonne connexion réseau entre tous ses sites). Pour éviter que les modifications des différents sites n'entrent en conflit sur un même fichier, chaque site ne peut créer de version de ce fichier que dans les branches de version lui appartenant. 45
ClearCase ClearCase ne permet pas : faire des enregistrements (commit) atomiques ni transactionnels. Ainsi, si un problème survient sur le réseau lors du commit, alors le repository cible sera corrompu et il faudra manuellement revenir en arrière ; et la vitesse d'enregistrement des fichiers est bien supérieure à subversion, par exemple. Pour toutes ces raisons, son utilisation est fortement déconseillée dans le cadre de gros projets et/ou impliquant de nombreux collaborateurs. 46
TP2 47