La gestion de versions. Vitthagna Barnier Paul Clément

Transcription

1 La gestion de versions Vitthagna Barnier Paul Clément 1

2 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, elle est surtout concernée par le code source ; mais elle peut être utilisée pour tout type de document informatique. activité étant fastidieuse et relativement complexe, un appui logiciel est presque indispensable. À cet effet, il existe différents logiciels de gestion de versions qui, bien qu'ayant des concepts essentiels communs, apportent chacun son propre vocabulaire et ses propres usages. 2

3 Gestion de versions Les vers ions : Les logiciels évoluant, chaque étape d'avancement est appelée vers ion. Les différentes versions sont nécessairement liées à travers des m odific a tions. Une modification peut correspondre à des ajouts, modifications, suppressions ou une combinaison des trois sur une version donnée. Schématiquement, on passera de la version N à la version N + 1 en appliquant une modification M. Un logiciel de gestion de versions nous aidera alors à soustraire la modification M de la version N + 1 pour retrouver la version N. 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

4 Gestion de versions M odific a tions et ens em ble de m odific a tions : Une modification constitue donc 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. On utilise généralement la gestion de versions à un ensemble de fichiers qui constitue un projet. De ce fait, il est courant de parler de modifications pour un seul fichier et d'ensemble de modifications (change set) lorsqu'il s'agit du projet (et donc de plusieurs fichiers). En effet, les deux n'évoluent pas au même rythme. Pour illustrer, prenons l'exemple d'un logiciel nommé «Toto». Il est constitué des fichiers A, et. À 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. 4

5 Gestion de versions B ra nc hes : Des modifications divergentes peuvent intervenir sur un ensemble de fichiers. On parle alors de branches. Parfois il s'agit aussi de faire converger des branches. On parle alors de fus ion de bra nc hes. 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. 5

6 Gestion de versions C onflit de m odific a tions : Dans le cas d'un développement en équipe, et surtout en équipes répartie dans le monde entier, chacun travaille de façon indépendante et c'est tout l'intérêt du système de gestion de version que de rendre cela possible. Toutefois, des fusions régulières sont nécessaires à un avancement global du logiciel. Il n'est pas rare que certaines modifications soient contradictoires (par exemple lorsque deux personnes ont apporté des modifications différentes à la même partie d'un fichier). On parle alors de conflit (de modifications) puisque le logiciel de gestion de versions n'est pas en mesure de savoir laquelle des deux modifications appliquer. Parfois ce n'est même ni l'une ni l'autre et il est nécessaire de reprendre une troisième fois le logiciel pour que ces modifications puissent finalement coexister harmonieusement. 6

7 Gestion de versions Fonctionnalités notoires des log iciels de g es tion de vers ions : Étiquetage ou marquage : Cela consiste à 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 : Il est possible de comparer plusieurs versions pour en extraire les modifications. Verrouillage et notifications : Pour le travail en équipe, certains logiciels de gestion de versions apportent des outils pour communiquer. Par exemple, le verrouillage permet d'interdire la modification d'un fichier, tandis que la notification émet un avertissement à tous les autres membres lorsqu'un fichier est modifié. 7

8 Gestion de versions Tronc, branches et taillis inextricable : Un système de gestion de versions permet à une équipe répartie dans le monde entier de développer progressivement 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é, l'usage du système de gestion de version devra être règlementé par de nombreuses bonnes pra tiques et 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. 8

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, ce qui veut dire qu'il n'existe qu'un seul dépôt des fichiers, dépôt qui fait référence. Cela peut simplifier le modèle mais cela est 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. Avec ceux-ci, il existe plusieurs dépôts dont aucun n'a de statut privilégié. 9

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) 10

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 11

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 : 12

13 Un Système de gestion de versions: Subversion 13

14 Système de gestion de version 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 Un grand nombre d'outils disponibles Adaptation des EDI grâce à des plugs-in (Eclipse, NetBeans, Emacs,...) 14

15 Documentation en ligne : Site de Subversion : Livre en ligne sur SVN : Tutoriel SVN : Refcard SVN : Bonnes pratiques SVN : 15

16 Concepts et opérations de base 16

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

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: 18

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 afin que les utilisateurs puissent maintenant télécharger cette 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 19

20 Fus ion de branches : MERGE Permet de répercuter les modifications faites sur une branche sur une autre branche grâce à la commande «svn merge» On fusionne par exemple 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) 20

21 Importation : IMPOR T Import du projet dans le dépôt On ne travaille jamais directement dans le dépôt, on travaille sur une copie locale 21

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. 22

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 copine locale : INFO 23

24 Mis e à jour de la copie locale : UPDATE (ou UP) Ajout d'une res s ource au référentiel : ADD 24

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 25

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 26

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 27

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 28

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 29

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. 30

31 Cycle de travail typique: 1. M.à.j. 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 31

32 Opérations avancées 32

33 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) 33

34 Il existe des propriétés automatique placées par subversion sur les fichiers: svn:executable : nouveau fichier dont le bit executable 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 : 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 34

35 C onfig ura tion: /.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 35

36 U tilis a tion de s c ripts : 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 E xem ples de s c ripts a s s oc iés : envoi d un 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 36

37 G es tion des c onflits : le verrouilla g e 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 37

38 P rotoc oles d'a c c ès : svn:// svn+ssh:// file:// 38

39 TP1 39

40 Différents outils pour une utilisation de subversion plus confortable : TurtoiseSVN : Client graphique Subversion intégré à l'environnement Windows SCPlugin : Equivalent Subversion pour Mac OS X (finder) Subclipse : Plug-in SVN pour Eclipse 40

41 ClearCase 41

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. 42

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. 43

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) en autant de copies que de sites existants, 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. 44

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. 45

46 TP2 46