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

Présentation au sujet: "1 La gestion de versions Vitthagna Barnier Paul Clément."— Transcription de la présentation:

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

2 2 Gestion de versions ▶ La gestion 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.

3 3 Gestion de versions ▶ Les versions : ▶ Les logiciels évoluant, chaque étape d'avancement est appelée version. Les différentes versions sont nécessairement liées à travers des modifications. ▶ 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.

4 4 Gestion de versions ▶ Modifications et ensemble de modifications : ▶ 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.

5 5 Gestion de versions ▶ Branches : ▶ 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 fusion de 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 6 Gestion de versions ▶ Conflit de modifications : ▶ 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.

7 7 Gestion de versions ▶ Fonctionnalités notoires des logiciels de gestion de versions : ▶ É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é.

8 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 pratiques 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.

9 9 Gestion de versions ▶ Systèmes centralisés et décentralisés : ▶ CVS et Subversion sont des logiciels centralisé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écentralisés comme Mercurial, darcs, Bazaar ou Git. Avec ceux-ci, il existe plusieurs dépôts dont aucun n'a de statut privilégié.

10 10 Gestion de versions ▶ Logiciels de gestion de versions ▶ Local ▶ Libre : ▶ RCS ▶ SCCS ▶ Modèle client-serveur ▶ Libre : ▶ CVS ▶ JediVCS ▶ MECASP, ▶ So6 ▶ Subversion (SVN)

11 11 Gestion de versions ▶ Logiciels de gestion de versions ▶ 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 12 Gestion de versions ▶ Logiciels de gestion de versions ▶ Distribué ▶ Libre : ▶ Bazaar ▶ 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 ▶ Propriétaire : ▶ BitKeeper Liste plus complète sur : http://en.wikipedia.org/wiki/List_of_revision_control_software http://en.wikipedia.org/wiki/List_of_revision_control_software

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

14 14 Subversion ▶ 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 commits, 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.htmlhttp://svnbook.red- bean.com/en/1.0/apa.html ▶ Un grand nombre d'outils disponibles ▶ Adaptation des EDI grâce à des plugs-in (Eclipse, NetBeans, Emacs,...)

15 15 Subversion ▶ Documentation en ligne : ▶ Site de Subversion : http://subversion.tigris.orghttp://subversion.tigris.org ▶ Livre en ligne sur SVN : http://svnbook.red-bean.comhttp://svnbook.red-bean.com ▶ Tutoriel SVN : http://www.fil.univ-lille1.fr/~durif/svn/svn.htmlhttp://www.fil.univ-lille1.fr/~durif/svn/svn.html ▶ Refcard SVN : http://www.cs.put.poznan.pl/csobaniec/Papers/svn-refcard.pdfhttp://www.cs.put.poznan.pl/csobaniec/Papers/svn-refcard.pdf ▶ Bonnes pratiques SVN : http://subversion.open.collab.net/articles/best-practices.htmlhttp://subversion.open.collab.net/articles/best-practices.html

16 16 Concepts et opérations de base Subversion

17 17 Subversion ▶ Organisation sous SVN : 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 18 Subversion ▶ 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 19 Subversion ▶ 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

20 20 Subversion ▶ Fusion 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)

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

22 22 Subversion ▶ 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 23 Subversion ▶ Etat de la copie locale: STATUS ▶ 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

24 24 Subversion ▶ Mise à jour de la copie locale : UPDATE (ou UP) ▶ Ajout d'une ressource au référentiel : ADD

25 25 Subversion ▶ Suppression 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 26 Subversion ▶ Déplacer/Renommer une ressource dans la copie locale: MOVE (ou MV ou RENAME ou REN) ▶ Annuler des modifications dans la copie locale : REVERT

27 27 Subversion ▶ Connaître les différences d'un fichier de la copie locale avec la révision de ce même fichier sur le référentiel : DIFF ▶ Permet de créer des patchs

28 28 Subversion ▶ Suivre l'évolution dans le temps d'une ressource de la copie locale ou du référentiel : LOG ▶ Obtenir de l'aide sur les commandes SVN: HELP

29 29 Subversion ▶ Valider les modifications de la copie locale et les répercuter sur le référentiel : COMMIT ▶ Un commentaire permet d'identifier les modifications

30 30 Subversion ▶ Gestion 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 31 Subversion ▶ 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

32 32 Opérations avancées Subversion

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

34 34 Subversion ▶ 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. svn:executable ▶ Et des propriétés standardisées à placer manuellement: ▶ svn:mime-type : type mime du fichier svn:mime-type ▶ 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 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:keyword ▶ svn:ignore : permet de ne pas soumettre un fichier au contrôle de version svn:ignore ▶ svn:eol-style svn:eol-style ▶ svn:exernals svn:exernals ▶ svn:special svn:special ▶ svn:need-locks svn:need-locks

35 35 Subversion ▶ Configuration: ∞/.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

36 36 Subversion ▶ Utilisation de scripts: ▶ 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 associé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

37 37 Subversion ▶ Gestion 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 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 svn unlock

38 38 Subversion ▶ Protocoles d'accès: ▶ svn:// ▶ svn+ssh:// ▶ http:// ▶ https:// ▶ file://

39 39 TP1 Subversion

40 40 Subversion ▶ 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-subversionhttp://www.labo- linux.org/articles-fr/subversion-le-travail-communautaire-sur-fichier/les-outils-pour-subversion ▶ TurtoiseSVN : http://tortoisesvn.tigris.org/http://tortoisesvn.tigris.org/ ▶ Client graphique Subversion intégré à l'environnement Windows ▶ SCPlugin : http://scplugin.tigris.org/http://scplugin.tigris.org/ ▶ Equivalent Subversion pour Mac OS X (finder) ▶ Subclipse : http://subclipse.tigris.org/http://subclipse.tigris.org/ ▶ Plug-in SVN pour Eclipse

41 41 ClearCase

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

45 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 46 TP2 Subversion