1

La gestion de versions

Vitthagna BarnierPaul Clément

2

Gestion de versions

▶ La gestion de vers ions  :

▶ 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

3

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

4

Gestion de versions

▶ M odific a tions et ens emble de modific 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.

5

Gestion de versions

▶ M odific a tions et ens emble de modific 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 .

6

Gestion de versions

▶ B ranc hes  :

▶ Branches : modifications divergentes sur un ensemble de fichiers.

▶ Fus ion de branc 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.

7

Gestion de versions

▶ C onflit de modific a tions  :

▶ Contexte :▶ développement en équipe▶ chacun travaille de façon indépendante

▶ Solution : ▶ 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 ?

8

Gestion de versions

▶ Fonctionnalités notoires des logiciels de ges 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é.

9

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.

10

Gestion de versions

▶ S ys tèmes 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é.

11

Gestion de versions

▶ Log ic iels de g es tion de vers ions

▶ Loca l

▶ Libre :▶ RCS▶ SCCS

▶ Modèle client-serveur

▶ Libre :▶ CVS▶ JediVCS▶ MECASP,▶ So6▶ Subversion (SVN)

12

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

13

Gestion de versions

▶ Logiciels de gestion de vers ions

▶ 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

14

Un Système de gestion de versions:Subversion

15

Subversion

▶ 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 ommits , 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, ...)

16

Subversion

▶ 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

17

Concepts et opérations de base

Subversion

18

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.

19

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:

20

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 => 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

21

Subversion

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

22

Subversion

▶ Importation : IMPORT

▶ Import du projet dans le dépôt▶ Ne jamais travailler directement dans le dépôt, privilégier une copie locale

23

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.

24

Subversion

▶ 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

25

Subversion

▶ Mise à jour de la copie locale : UPDATE (ou UP)

▶ Ajout d'une ressource au référentiel : ADD

26

Subversion

▶ S uppress 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

27

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

28

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

29

Subversion

▶ S uivre 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 S VN: HELP

30

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

31

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.

32

Subversion

▶ 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

33

TP1

Subversion

34

Opérations avancées

Subversion

35

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)

36

Subversion

▶ 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

37

Subversion

▶ Configuration: ∞ /.subversion/config

▶ Exemple:

[miscellany]global-ignores = *.o *.lo *.la .DS_Storeenable-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

38

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

39

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▶ Fichier verrouillé avec status 'K' ou 'O'▶ Un commit réussi retire tous les verrous▶ svn unlock : utilisable par tous les développeurs

40

Subversion

▶ Protocoles d'accès:

▶ svn://▶ svn+ssh://▶ http://▶ https://▶ file://

41

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

42

ClearCase

43

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.

44

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.

45

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.

46

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.

47

TP2

Subversion