Une introduction à la gestion de configurations. Pascal Molli web: molli September 25, 2006

Transcription

1 Une introduction à la gestion de configurations Pascal Molli web: molli September 25,

2 Pascal Molli 2 LORIA

3 Section 1. Introduction 1 Introduction Une introduction à la gestion de configuration Pascal Molli molli@loria.fr web: molli September 25, 2006 Slide 1 Pascal Molli 3 Équipe ECOO

4 1.1 Définitions Section 1. Objectifs Avoir des connaissances générales les gestionnaires de configuration : les problèmes, les fonctionnalités, les concepts... Manipuler des (petits) outils pour un peu démystifier (RCS,CVS... ) Situer la place d un CM dans l organisation générale d un développement. Vous convaincre d utiliser ce type d outils... Slide 2 Cette présentation s adresse à des personnes qui ne connaissent pas les gestionnaires de configuration. Nous introduisons la problématique de la gestion de configuration à partir d un exemple concret : plusieurs personnes veulent travailler au développement d un logiciel Définitions Pascal Molli (molli@loria.fr) 4 LORIA

5 Section Définitions Définition Standard Définition (IEEE ) Identification : des composants. ex: Quelles versions des composants sont dans la dernière release? Contrôle : des changements. ex: Quels changements ont été effectués sur cette release? Accounting : traces, rapport d état. ex: Quels est l état des changements proposés Audit et review : validation. ex: Est ce que la dernière release contient des versions correctes? Slide 3 Définition étendue Construction : gérer la construction du logiciel (make par exemple) Modélisation du procédé : Assurer le respect du cycle de vie. Travail d équipe : Contrôler les interactions dans une équipe (coordination, synchronisation, concurrence d accès...). Slide 4 Pascal Molli 5 Équipe ECOO

6 1.2 Un progrès n existe que si il est mesurable... Section 1. Points de vue sur le CM CCC: Corporation Configuration Management. Release externes, bug report... PCM: Project Configuration Management: travail en équipe, notification, rôles. DCM: Developper Configuration Management: accéder les composants pour apporter des changements, espace de travail, travail en isolation. ACM: Application Configuration Management: Distribution, tolérance de pannes Slide Un progrès n existe que si il est mesurable... Situer quelle est l avancée dans la mise en place d un procédé de l utilisation d un gestionnaire de conf. Pascal Molli (molli@loria.fr) 6 LORIA

7 Section Un progrès n existe que si il est mesurable... Slide 6 Slide 7 Pascal Molli 7 Équipe ECOO

8 1.3 Spectre des fonctionnalités d un gestionnaire de configuration Section Spectre des fonctionnalités d un gestionnaire de configuration Spectre des fonctionalités (S. Dart) Slide 8 Finalement, comme je l avais signalé au début de ce document, nous n avons couvert qu une petite partie du domaine de la gestion de configuration : Pascal Molli (molli@loria.fr) 8 LORIA

9 Section Spectre des fonctionnalités d un gestionnaire de configuration Contrôle Comment et quand les changements sont opérés: Contrôle d accès Requêtes de changement: conduite du procédé de changement Suivi d erreurs: suivi des erreurs et des corrections Propagation des changements Partitionnement: limiter les effets d un changement Slide 9 Construction Supporter la construction d un produit: Construction: système de construction Snapshot: geler l état d un produit Optimisation: réduire les temps de compilation et la place disque. Analyse d impact: prédire les effets d un changement Régénération. Slide 10 Pascal Molli 9 Équipe ECOO

10 1.3 Spectre des fonctionnalités d un gestionnaire de configuration Section 1. Audit Maintenir une trace des produits et des procédés: Historique: maintenir l historique des changements Traçabilité. Logging: enregistrement des détail des changements pour audit de la trace. Slide 11 Travail d équipe Synchroniser et coordonner le travail d équipe: Espace de travail : travail en isolation Résolution de conflit : fusion... Famille : développement de produits interdépendant. Slide 12 Pascal Molli (molli@loria.fr) 10 LORIA

11 Section Spectre des fonctionnalités d un gestionnaire de configuration Accounting Corréler les faits entre les produits et le procédé: Statistiques: enregistrer et générer des statistiques Détermination d état. Rapport d avancement. Slide 13 Procédé de fabrication Gestion de l évolution du produit: Support au cycle de vie: assurer le respect d un procédé de fabrication Gestion des tâches: Suivit des tâches de développement Gestion des communications entre les tâches (en respect avec le procédés) Documentation: enregistrement du savoir-faire... Slide 14 Pascal Molli 11 Équipe ECOO

12 Problématique Section 2. Plan Problématique Modèles de gestion de configuration Modèle Checkin/Checkout : RCS Modèle par composition : CVS Conclusions - perspectives Slide 15 2 Problématique Pascal Molli (molli@loria.fr) 12 LORIA

13 Section 2. Problématique Figure 1: Thèmes abordés en gestion de configuration Problématique Plusieurs personnes veulent coopérer pour développer *ENSEMBLE* un logiciel. Comment faire? Tout le monde travaille dans un repertoire UNIX? mais comment travailler sans être gêné par les autres... Tous les participants ont chacun une copie? mais comment propager les changements chez les autres? comment se synchroniser en évitant des mises à jour perdues? Slide 16 Nous abordons les problèmes de gestion de configuration en partant de problèmes de travail coopératif. Il faut bien se rendre compte que cela ne constitue qu un des thèmes abordés en gestion de configuration parmi d autres tout aussi importants (cf figure 1 : mécanismes de construction du logiciel (Make et consort), traçabilité (versions, variant...), procédés de fabrication du logiciel... Le travail coopératif est en fait un biais intéressant pour présenter une des facettes de ce que l on peut trouver dans le domaine de la gestion de configuration. Le lecteur pourra Pascal Molli 13 Équipe ECOO

14 Modèles de gestion de configuration Section 3. se reporter à la bibliographie si il s intéresse à l ensemble du domaine. 3 Modèles de gestion de configuration Modèles CM 4 grands modèles [3]: Checkin/Checkout Composition Transactions longues Change Sets Slide 17 La définition de ces modèles est en fait le fruit d un travail réalisé au Software Engineering Institute. Ils ont tous un point commun : les utilisateurs travaillent sur des copies obtenues auprès d un référentiel commun. Pour travailler de manière coopérative, il faut pouvoir propager les modifications effectuées sur un copie vers les autres copies Modèle des Checkin/Checkout Pascal Molli (molli@loria.fr) 14 LORIA

15 Section Modèle des Checkin/Checkout Modèle Checkin/Checkout Slide 18 Le modèle [4] est construit autour d un référentiel avec des espaces de travail (cf figure??). Le référentiel stocke un ensemble de fichiers multi-versionnés. Les versions sont organisées selon un graphe direct acyclique (cf figure 2). Ce graphe comporte toujours un branche principale et des branches annexes. Figure 2: Un graphe de versions Un espace de travail est un sous-ensemble mono-versionné du référentiel ; plus concrètement ce peut-être un répertoire UNIX peuplé de fichiers. Pascal Molli 15 Équipe ECOO

16 3.1 Modèle des Checkin/Checkout Section 3. Checkin/Checkout L utilisateur dispose de 2 opérations: Checkout(id-objet,id-version) : id-objet référence un objet dans le référentiel. id-version référence la version de cet objet. La valeur de l objet ainsi déterminée est copiée dans l espace de travail de l utilisateur. Checkin(id-objet) : Si id-objet appartient à l espace de travail de l utilisateur alors une nouvelle version de id-objet est créée dans le référentiel avec pour valeur la valeur de id-objet dans l espace de travail. Slide 19 Gestion de la concurrence En fait, le Checkout peut se faire en lecture ou en écriture + table de verrouillage. Checkout(id-objet,id-version,READ) : a priori, il n y aura pas de checkin... Checkout(id-objet,id-version.WRITE) : seul l utilisateur aura le droit de créer la prochaine version. Attention! ce n est pas la sémantique habituelle d un verrou en écriture... Illustration : scénario du Quick bug fix... Slide 20 Pascal Molli (molli@loria.fr) 16 LORIA

17 Section Modèle des Checkin/Checkout La accès concurrents sont gérés en utilisant des verrous en lecture/écriture. Si un fichier est extrait du référentiel en écriture alors son utilisateur est assuré de pouvoir créer la prochaine version du fichier dans la même branche. Ce mode de fonctionnement permet : le développement en parallèle En effet il est possible de développer un même fichier selon deux voies différentes dans deux branches séparées. Une branche peut être ultérieurement fusionnée avec une autre ou abandonnée. La gestion des mises à jour conflictuelles Supposons qu un fichier soit en cours de modification. Cette modification est longue, le fichier est verrouillé. Un autre utilisateur désire effectuer rapidement un changement mineur. Il peut accéder au fichier, le modifier et créer une nouvelle version dans une autre branche. Cette nouvelle version peut être fusionnée à la version principale ultérieurement. La fusion de deux branches de développement peut devenir une tache complexe. En effet, cette fusion peut être vue comme une tache d intégration des différentes versions du fichier. Son issue est incertaine, elle peut être anodine ou impossible et remettre tout le développement initial en cause. Des outils sont disponibles pour assister cette tâche mais ne peuvent l automatiser. Quick bug fix (1) Slide 21 Pascal Molli 17 Équipe ECOO

18 3.1 Modèle des Checkin/Checkout Section 3. Quick bug fix (2) Slide 22 Quick bug fix (3) Slide 23 Pascal Molli 18 LORIA

19 Section Modèle des Checkin/Checkout Quick bug fix (4) Slide 24 Voilà une des raisons pour lesquelles il faut un gestion de version non-linéaire... Pascal Molli 19 Équipe ECOO

20 3.1 Modèle des Checkin/Checkout Section 3. Gestion des branches À quoi ça sert? Développement en parallèle Représentation de variantes (unix,pc..) Développement expérimental Fusion... Slide 25 Bon. Il faut se faire un peu au vocabulaire : baseline c est une branche privilégiée du développement. Attention les fusions, c est pas automatique... Pascal Molli (molli@loria.fr) 20 LORIA

21 Section Composition Conclusion Gestion de version fichier par fichier Identification : composant fichier Contrôle : checkin, checkout + protocole de contrôle de la concurrence (préserve des mises-à-jour perdues) État/accounting/audit : graphe direct acyclique des versions Ex: SCCS, RCS, Razor... Slide 26 Ce modèle supporte le développement en parallèle. Ceci est possible dans le mesure où les utilisateurs prennent eux-même en charge la gestion des versions. Par contre, la correction des exécutions concurrentes n est pas prise en compte. Par exemple, prenons l exemple suivant : deux utilisateurs travaillent sur deux fichiers x.c et y.c. Le premier fait du développement, le second de la revue de code. Nous pouvons obtenir l exécution suivante : Produire(x.c, y.c) checkout(x.c) checkout(y.c) edit(x.c) edit(y.c) checkin(x.c) checkin(y.c) Vérifier(x.c, y.c) checkout(x.c) checkout(y.c) lire(x.c, y.c) Dans ce cas, la revue se fait avec des valeurs incohérentes de x.c et y.c. Cette exécution montre en fait une lecture impropre de l activité de revue. Ce modèle permet effectivement de travailler en parallèle sur un même objet en utilisant plusieurs versions d un même objet mais ne contrôle pas la correction proprement dite des exécutions concurrentes. Toutefois il faut remarquer que dans ce modèle, les objets sont toujours disponibles en lecture. 3.2 Composition Ce modèle s inscrit comme une suite logique du premier. Il est construit lui-aussi autour d un référentiel et d espaces de travail mais avec la notion de configuration. Une configuration Pascal Molli 21 Équipe ECOO

22 3.2 Composition Section 3. est sous-ensemble nommé, cohérent et mono-versionné du référentiel. Les opérateurs de transferts entre le référentiel et les espaces de travail restent les mêmes mais peuvent s appliquer sur une configuration (cf figure??). Dans ce cas la configuration est transférée de manière atomique. Modèle par composition Slide 27 Le transparent 27 montre comment deux utilisateurs travaillent sur deux configurations différentes du même ensemble d objets. Il faut remarquer que les utilisateurs ont transféré non plus un fichier comme dans le modèle précédent, mais une configuration dans leurs espaces de travail respectifs. Pascal Molli (molli@loria.fr) 22 LORIA

23 Section Composition Configuration configuration : un sous-ensemble nommé, mono-versionné, cohérent d objets. checkin, checkout sur une configuration! oui mais comment obtenir cette configuration?? Slide 28 Détermination d une configuration En deux temps : Agrégation des composants (basée sur le modèle d objet) Selection de la version appropriée de chaque composant de l agrégation finalement ça ressemble à une requête... Slide 29 Pascal Molli 23 Équipe ECOO

24 3.2 Composition Section 3. Agrégation des composants agrégation basée sur les dépendances entre les composants. Comment déterminer ces dépendances? : Les dépendances entre objets sont déclarés explicitement pourquoi pas dans une base de données. Évidemment, plus le modèle d objet du référentiel est riche plus il est facile de représenter directement les dépendances entre objets. Slide 30 Selection des versions (de l agrégat) chemin de recherche dans les branches de version : branche de développement sun3, autres espaces de travail... basée sur des propriétés (attributs sur les objets) : windowsystem==x11 and WSrelease > R3 & (status == tested or reserved=me) Slide 31 Pascal Molli (molli@loria.fr) 24 LORIA

25 Section Composition Gestion de la concurrence Finalement comme dans le checkin/checkout model... Mais en gérant cette fois des configurations Slide 32 Conclusions Identification: Agrégation + selection de version Contrôle: checkin/checkout + graphe de versions Accounting/Audit: graphe de versions Ex: La plupart des outils de CM actuel : clearcase, continuus... Slide 33 Pascal Molli 25 Équipe ECOO

26 3.3 Transactions longues Section 3. Les différents acteurs d un développement peuvent coopérer en publiant des configurations successives d une configuration. Mais le protocole même de coopération reste entre les mains des utilisateurs. Quand faut-il publier ses résultats, quand faut-il absolument les relire, tout cela n est pas défini dans ce modèle. Il faut tout de même remarquer que dans ce modèle, un espace de travail se comporte comme une sphère d isolation où tout changement ne peut être opéré que de l intérieur. L utilisateur d un espace de travail est donc protégé des actions effectuées au sein des autres espaces mais peut à tout moment se resynchroniser avec le référentiel à son initiative. 3.3 Transactions longues Dans ce modèle [2, 1], le référentiel est vu comme une base de données. Une activité de développement s effectue au sein d une transaction et fait passer la base d un état cohérent dans un autre. Les états cohérents sont représentés comme des configurations. Le modèle adopte la stratégie suivante : 1. Chaque transaction à sa création copie dans un espace de travail une configuration d objets. Elle est alors en mesure de travailler librement sur ces objets. La transaction fournit à l utilisateur une sphère de stabilité où tous les changements sont faits à son initiative. Il est important de noter que les changements opérés dans la transaction ne seront visibles qu à sa terminaison. 2. À sa terminaison, la transaction produit une nouvelle configuration des objets à partir des valeurs présentes dans son contexte. Rappels transactionnels Transactions ACID: Atomicité : tout ou rien Consistance : Si la transaction individuellement fait passer la base d un état correct dans un autre alors l exécution concurrente n introduit pas d inconsistance (sérialisabilité). Isolation : pas de visibilité sur les résultats partiels Durabilité : les résultats validés ne sont pas remis en cause. Slide 34 Pascal Molli (molli@loria.fr) 26 LORIA

27 Section Transactions longues Modèle des transactions longues Encapsuler une activité de développement dans une transaction Voir un développement comme une transaction imbriquée. PB: Durée indéterminée transaction plus longue qu une session. PB: Isolation trop forte... Slide 35 Ce modèle permet également d emboîter les transactions. Le référentiel peut être considéré comme la mémoire locale d une transaction racine. Les transactions s organisent alors selon un arbre ; l espace de travail d une transaction constitue le référentiel de ses sous-transactions. Cette approche permet de structurer le développement en décomposant une activité en sous-activités, chaque activité s exécutant au sein d une transaction. Par exemple, il est possible de décomposer l activité projet selon l arbre d activité décrit dans la figure??. Pascal Molli 27 Équipe ECOO

28 3.3 Transactions longues Section 3. Slide 36 Idée Représenter les états corrects de la base comme une configuration Représenter la transaction et sa mémoire locale comme un espace de travail. Slide 37 Pascal Molli 28 LORIA

29 Section Transactions longues Slide 38 Gestion de la concurrence Les résultats d une transaction sont produits à la fin de la transaction. (pas de publication de résultats avant la fin!!). Possibilité de gestion de la concurrence optimiste : paradigme du copier-modifier-fusionner. Slide 39 Pascal Molli 29 Équipe ECOO

30 3.3 Transactions longues Section 3. Figure 3: Copier-modifier-fusionner: copier et modifier Figure 4: Copier-modifier-fusionner: fusionner Le modèle propose un protocole de contrôle des accès concurrents optimiste. Prenons un exemple : Soit deux transactions ayant démarrées avec la même configuration R1 (cf figure 3). Elles développent en parallèle deux nouvelles configurations (R2 et R3 sur notre figure). La première transaction termine et rend la configuration R2 durable. La seconde transaction ne peut alors terminer sous peine d écraser R2. Elle est obligée de relire R2 et de fusionner avec R3 pour pouvoir terminer sur une configuration R4 (cf figure 4). Il faut remarquer que cette stratégie de contrôle des accès concurrents évite les mises à jour perdues et ne fait pas appel à un procédé de fabrication particulier. Il ne peut exister non plus de lectures impropres dans la mesure où toute transaction termine en produisant une configuration cohérente. Le référentiel est donc toujours dans un état cohérent. Pascal Molli (molli@loria.fr) 30 LORIA

31 Section Transactions longues Slide 40 Slide 41 Pascal Molli 31 Équipe ECOO

32 3.4 Change sets Section 3. Conclusions Identification: read/write dans le référentiel, transparente Contrôle: Transactions (begin, terminate). Accounting/audit: graphe de versions. Ex: NSE [1]. Slide Change sets Pascal Molli 32 LORIA

33 Section Change sets Change sets Au lieu de nommer les versions, on nomme les deltas Orienté changement vs Orienté version. Un Change-Set : l ensemble des deltas entre deux configurations. Pour déterminer une configuration, on part d une configuration de base et an applique des change-sets. Slide 43 R2 = R1 + {δ A1, δ C1 } Slide 44 Pascal Molli 33 Équipe ECOO

34 3.4 Change sets Section 3. Change Sets La connaissance des change-set permet de déduire beaucoup d information : Déterminer quels composants ont été modifiés comme partie d un même changement logique : exprime les dépendances entre composants Déterminer la collection des change sets dont un composant fait partie : information sur la stabilité des composants Déterminer quels change set sont inclus dans une configuration (infos sur les capacités de la configuration... ) Déterminer quelles configurations incluent un changement particulier (infos sur la propagation d un changement) Slide 45 Composition consistantes Création de nouvelles configurations. par compositions de change set. Toutes les combinaisons de change set ne sont pas consistantes. Certains change set sont incompatibles avec d autres ou bien dépendent de la présence d autres. La consistance d une composition peut être déterminée en analysant les read-set et write-set de chaque change set. même read-set et write-set différent : un conflit, d où une fusion nécessaire. Trouver un ordre de composition où les read-set, write-set sont compatibles une sorte de sérialisation a posteriori des activités de changement. Slide 46 Pascal Molli (molli@loria.fr) 34 LORIA

35 Section Conclusion Conclusions Identification: baseline + change-sets Contrôle: création de change-sets. Pas vraiment de gestion de concurrence dans le modèle. C est un problème orthogonal. Accounting/review: analyse des change-sets Ex: Aide-de-camp. Slide Conclusion Pascal Molli 35 Équipe ECOO

36 3.5 Conclusion Section 3. Conclusions Pour l instant, les modèles utilisés : Checkin/checkout et composition. Attention, ces modèles ne constitue qu un petite partie de ce que l on peut dans le domaine de la gestion de configuration : modèles d objets, systèmes de construction, suivi de problèmes... Technologie en pleine évolution. perspectives: gestion des procédés de fabrication (continuus), gestion du travail d équipe (coopération) et gestion de la distribution à large échelle. Maintenant, RCS pour checkin/checkout et CVS pour composition. Slide 48 Attention, on ne peut pas vraiment parler de gestionnaire de configuration pour CVS, il manque trop de fonctionnalités de bases que l on peut trouver dans un vrai gestionnaire de configuration comme Clearcase ou Continuus... On peut tout de même aborder une certaine classe de problèmes qui sont déjà très intéressant et notamment le travail à plusieurs... Pascal Molli (molli@loria.fr) 36 LORIA

37 Section 4. RCS : Revision Control System 4 RCS : Revision Control System RCS: checkin/checkout model Objectifs. Connaître les fonctionnalités de outils fonctionnant sur ce modèle et surtout la surcharge de travail lié a leur utilisation (coût/gain). Environnement de développement. RCS + Emacs. Documentation man rcsintro et [5] Slide 49 Gère des révisions multiples de fichiers. automatise le stockage, la récupération, l historique, l identification, et la fusion de révision. 4.1 Architecture générale Pascal Molli 37 Équipe ECOO

38 4.2 Fonctionnalités Section 4. Architecture Générale Slide 50 Bon, on instancie le modèle avec un système de fichier. Les référentiel est en fait un répertoire contenant des fichiers au format RCS (extension,v). Ce format permet d archiver (de manière efficace) plusieurs versions d un fichier dans un fichier. Les espaces de travail sont de simples repertoire UNIX contenant des fichiers ordinaires. Un lien UNIX relie les espaces de travail au référentiel. Ce lien doit impérativement s appeler RCS. Il est possible de stocker à la fois les fichiers RCS et les fichiers de travail dans le même répertoire, mais il me semble que la première façon de procéder est bien meilleure pour travailler en multi-utilisateur. 4.2 Fonctionnalités Pascal Molli (molli@loria.fr) 38 LORIA

39 Section Fonctionnalités Fonctionnalités Stocker et récupérer. Des opérateurs (co, ci). Des identificateurs de version. Un référentiel pour le stockage proprement dit (f.c f.c,v soit dans le repertoire courant, soit dans un sous répertoire RCS). Historique. à chaque checkin qui a fait (auteur)? quoi (msg)? quand (date:time)? pourquoi... stocker l historique où dans le fichier Résoudre les conflits d accès. Alerter deux programmeurs qui veulent modifier la même version en même temps. Maintenir des branches de développement. Slide 51 Fonctionnalités Fusionner des révisions. deux fichiers avec deux lignes différente au même endroit sont marquée comme conflictuelles et l utilisateur est alerté. Contrôler des révisions. nom symbolique pour un ensemble de fichiers (flat). Identification des révisions. par le nom, l id, la date de création... minimiser la taille du stockage. Gestion de deltas vitesse de récupération. Slide 52 Pascal Molli 39 Équipe ECOO

40 4.2 Fonctionnalités Section 4. Mise sous RCS d un fichier de travail Création de f.c,v avec f.c 1.1, destruction de f.c: % edit f.c % mkdir RCS % ci f.c RCS/f.c,v <-- f.c enter description, terminated with single. or end of file: NOTE: This is NOT the log message! >> first version >>. initial revision: 1.1 done Slide 53 Extraction d un fichier RCS extraction de f.c:1.1 dans un fichier de travail en lecture % co f.c RCS/f.c,v --> f.c revision 1.1 done extraction de f.c:1.1 dans un fichier de travail en écriture % co -l f.c RCS/f.c,v --> f.c revision 1.1 (locked) done Slide 54 Pascal Molli (molli@loria.fr) 40 LORIA

41 Section Fonctionnalités Travail sur le fichier On travaille sur le fichier de travail de manière tout fait normale... % emacs f.c On dispose tout de même d informations supplémentaires, par exemple le diff % rcsdiff f.c =================================================================== RCS file: RCS/f.c,v retrieving revision 1.1 diff -r1.1 f.c 0a1 > pouet Slide 55 Rlog statut d un fichier RCS : rlog % rlog f.c RCS file: RCS/f.c,v Working file: f.c head: 1.2 branch: locks: strict access list: symbolic names: comment leader: " * " keyword substitution: kv total revisions: 2; selected revisions: 2 description: first version Slide 56 Pascal Molli 41 Équipe ECOO

42 4.2 Fonctionnalités Section revision 1.2 date: 1997/04/21 16:40:12; author: molli; state: Exp; lines: +1-0 yo ============================================================================= Slide 57 Slide 58 Pascal Molli 42 LORIA

43 Section Fonctionnalités On peut tout de même travailler avec des outils un peu plus évolué que les commandes en lignes... RCS est remarquablement intégré dans emacs (No de version dans la modeline, appel au package ediff pour voir les différences entre deux versions, checkin/checkout depuis emacs... ) Slide 59 l opération la plus complexe reste le checkin. Le transparent 59 illustre les différents scénario possible. au moment du checkin, il peut y avoir deux cas de figure : 1. soit l utilisateur possède un verrou en écriture sur f.c : dans ce cas, c est très simple, il y a création d un nouvelle version de f.c et la version de travail est détruite. 2. soit l utilisateur ne possède pas de verrou en écriture et dans ce cas il lui faut essayer de l acquérir a posteriori : (a) Si f.c n est pas verrouillé, alors retour au checkin normal (b) sinon 3 cas de figure : i. RCS donne le nom de la personne propriétaire du verrou, on peut donc envoyer un mail et tenter de négocier... ii. La modification est urgente est prioritaire. Dans ce cas, il est possible de voler le verrou. Un mail est envoyé à l innocente victime de ce vol qualifié pour l avertir de l effraction. iii. Dernier cas de figure : créer une nouvelle branche de développement, et nous retombons dans le modèle du checkin/checkout. Quelques remarques avant de passer à la gestion de branches dans RCS : Pascal Molli 43 Équipe ECOO

44 4.2 Fonctionnalités Section 4. Verrouillage Comportement différent pour la personne possédant le fichier off pas de test de lock pour le propriétaire en cas de checkin % rcs -U f.c on : test de lock pour le propriétaire en cas de checkin % rcs -L f.c Slide 60 Verrouillage Pour empêcher la destruction du fichier pendant le checkin checkin suivi immédiatement de co avec lock. % ci -l f.c checkin suivi immédiatement de co sans lock. % co -u f.c Slide 61 Pascal Molli (molli@loria.fr) 44 LORIA

45 Section Gestion des branches 4.3 Gestion des branches Numérotation RCS nombre pair de chiffres : numéro de révision nombre impair : numéro de branche Slide 62 Pascal Molli 45 Équipe ECOO

46 4.3 Gestion des branches Section 4. Gestion des branches dans la baseline 2.1, 2.2, % ci -r2 f.c Démarrage d une nouvelle branche à partir de la révision 1.3. % ci -r2.1 f.c % co -r2 f.c % ci -r1.3.1 f.c Slide 63 Scénario du Quick Bug fix au début: 1.1 -> 1.2 -> 1.3 -> 2.1 -> distribuée au client! bug fix demandé : co -r1.3 f.c edit f.c ci -l -r1.3.1 f.c edit f.c ci -l -r1.3.1 f.c > 1.2 -> 1.3 -> 2.1 -> 2.2 \-> > Slide 64 Pascal Molli (molli@loria.fr) 46 LORIA

47 Section Gestion des branches Intégration des deux branches En fait sortir les deux dernières révision de chaque branche et appeler l opération de fusion semi-automatique : % co -j1.3.1 f.c revision 2.2 revision 1.3 revision merging... merge warning: overlaps during merge done % edit f.c Slide 65 Cette syntaxe est maintenant obsolète depuis l apparition de rcsmerge : rcsmerge -p -r r2.2 f.c >f.merged.c edit f.merged.c mv f.merged.c f.c; ci f.c Mais ça marche toujours et je la trouve plus agréable que le rcsmerge... Pascal Molli 47 Équipe ECOO

48 4.4 Gestion des deltas Section 4. Exemple de résultat d une fusion more f.c riri <<<<<<< 2.2 fifi ======= loulou >>>>>>> Slide Gestion des deltas Pascal Molli (molli@loria.fr) 48 LORIA

49 Section Trace Gestion des deltas Minimiser la taille de stockage sans trop pénaliser le co. reverse deltas vs delta. <1.1 -> <1.2 -> 1.3 -> 2.1 -> 2.2 \> > Slide Trace Pascal Molli 49 Équipe ECOO

50 4.5 Trace Section 4. Trace Macro expansion de symboles RCS au ci Par exemple /* dans un code C ou C++ */ static char rcsid[]"$id$"; Slide 68 $Author$ The login name of the user who checked in the revision. $Date$ The date and time (UTC) the revision was checked in. $Header$ A standard header containing the full pathname of the RCS file, the revision number, the date (UTC), the author, the state, and the locker (if locked). $Id$ Same as $Header$, except that the RCS filename is without a path. $Locker$ The login name of the user who locked the revision (empty if not locked). $Log$ The log message supplied during checkin, preceded by a header containing the RCS filename, the revision number, the author, and the date (UTC). Existing log messages are not replaced. Instead, the new log mes- sage is inserted after Log :... This is useful for accumulating a complete change log in a source file. $RCSfile$ The name of the RCS file without a path. $Revision$ The revision number assigned to the revision. $Source$ The full pathname of the RCS file. $State$ The state assigned to the revision with the -s option of rcs(1) or ci(1). Pascal Molli (molli@loria.fr) 50 LORIA

51 Section Trace Entêtes de fichiers % $Source$ % $Revision$ % $Date$ % $Author$ % $State$ % CONTENU-DESCRIPTION <...> % Change History % % $Log$ % Slide 69 % $Source: /local/genielog/cvspres/cvs.tex,v $ % $Revision: $ % $Date: 1993/12/23 14:48:10 $ % $Author: molli $ % $State: Exp $ % CONTENU-DESCRIPTION % Transparents et commentaires de présentation % de cvs pour la journée de présentation des % moyens informatiques CRIN-INRIA % Change History % % $Log: cvs.tex,v $ % Revision /12/23 14:48:10 molli % expo CVS % % Revision /12/02 14:42:06 garti % Version de la presentation pour la "vrai" % installation du CRIN Slide 70 Pascal Molli 51 Équipe ECOO

52 4.6 Contrôle d accès Section Contrôle d accès liste d accès gestion nominative des accès au fichier RCS. chaque fichier rcs contient une liste des utilisateur qui ont le droit de faire des mises à jour: rcs -alogins rcs -elogins... Slide Intégration avec Make Pascal Molli (molli@loria.fr) 52 LORIA

53 Section Intégration avec Make Make et RCS auto-checkout des fichiers nécessaire à la compilation (avec gnu-make) gregory [19:31] 135 tam -> gmake co RCS/TamArmor.hh,v TamArmor.hh RCS/TamArmor.hh,v --> TamArmor.hh revision 1.2 done <...> co RCS/TamMap.icc,v TamMap.icc RCS/TamMap.icc,v --> TamMap.icc revision 1.2 done g++ -g -I/usr/local/X11R5/include \ -c TamMap.cc -o TamMap.o Slide 72 <...> Slide 73 Pascal Molli 53 Équipe ECOO

54 4.8 Autres commandes Section Autres commandes Autres commandes ident extract ident marker rcs set/unset RCS file attributes rcsclean remove unchanged files from working dir rcsdiff compare rev. rcsmerge merge revision rlog read log message Slide Conclusions Pascal Molli 54 LORIA

55 Section Conclusions Conclusions Modèle Checkin/Checkout. utile pour la gestion de quelques fichiers faiblesse dans la gestion d un ensemble de fichiers eparpillés dans un arbre de directory CVS. Slide 75 Pascal Molli 55 Équipe ECOO

56 CVS : Concurrent Version System Section 5. 5 CVS : Concurrent Version System 5.1 Qu est ce que CVS? CVS est un outil de contrôle de révision destiné à des groupes de développeurs travaillant sur les mêmes fichiers. CVS leur permet de travailler en isolement et de se resynchroniser les uns par rapport aux autres quand ils le désirent. Travailler à plusieurs sur les même objets en même temps. La différence majeure de CVS par rapport à d autres outils plus vieux comme RCS ou SCCS est de permettre à plusieurs développeurs de travailler sur les mêmes fichiers en même temps. Chaque développeur travaille isolément dans son espace de travail (un répertoire UNIX). Un répertoire partagé est utilisé comme point de rendez-vous pour rendre publics des fichiers locaux ou pour inclure le travail effectué en parallèle par les autres développeurs. Gérer les versions des sources d un développement. Jusqu alors des outils comme RCS ou SCCS se limitaient à la gestion de version d un seul fichier. CVS réutilise RCS pour sa gestion de version de fichiers mais permet aussi la gestion de version d un répertoire. Suivre les versions d un logiciel externe. L installation de logiciels externes demande très souvent des modifications locales au site. Un travail pénible consiste a répercuter ces modifications lorsqu une nouvelle version du logiciel arrive. CVS permet à l installateur de détecter quelles modifications il avait effectué, quels sont les changements apportés par la nouvelle version, fichier par fichier et donc, de se rendre compte si les modifications locales ont toujours lieu d être ou pas. Gestion des branches de développement. RCS permet une gestion non linéaire des versions pour un fichier. CVS offre la même possibilité mais pour un répertoire. Un groupe de développeurs peut travailler dans chacune des branches. CVS fournit des primitives pour fusionner deux branches. 5.2 Ce que CVS ne fait pas CVS est un outil de contrôle de révision, ce n est pas un système de gestion de configuration. 5.3 CVS : un modèle par composition Pascal Molli (molli@loria.fr) 56 LORIA

57 Section CVS : un modèle par composition CVS : un modèle par composition Slide 76 C est une instanciation du modèle par composition sur un système de fichier. Une configuration est un aggrégat d objets mono-versionnés. L aggrégat apparait à travers la notion de modules! Un module est soit un nom de fichier, soit un nom de repertoire, soit une liste de nom de modules. Les carrés gris représentent des sous-types de répertoire. Les carrés blancs, des soustypes de fichier. Les fléches fines représentent une relation 1-1, les fléches doubles une relation 1-n (pas de relation n-n dans ce schéma). La flèche épaisse représente une relation de sous-typage. Enfin, les carrés aux bords arrondis représentent les méthodes associées aux types. La partie administrateur représente les objets présents dans le repository, la partie util- Pascal Molli 57 Équipe ECOO

58 5.3 CVS : un modèle par composition Section 5. isateur les objets présents dans une copie de travail. CVS : un modèle par composition Une configuration : un aggrégat d objets mono-versionnés. Il faut donc : 1. déterminer l aggrégat puis, 2. sélectionner une version pour chaque composant de l aggrégat. Sous CVS, un aggrégat est représenté par un module : module := [module]+ répertoire fichier Slide 77 Pascal Molli (molli@loria.fr) 58 LORIA

59 Section Créer un référentiel CVS : un modèle par composition CVS ne dispose pas d un mécanisme de selection de version perfectionné. Pour un module : Configuration : la dernière version de chaque composant du module Étiquette symboliques : nommage explicite par l utilisateur (rcs tag...) Slide Créer un référentiel Pascal Molli 59 Équipe ECOO

60 5.5 Travailler dans les espaces de travail Section 5. Créer le référentiel % setenv CVSROOT /local/lang/script/cvs} % cvs init % cvs import -m "CVS 1.9 distribution" cvs CVS CVS1_9 N cvs/readme N cvs/changes <...> No conflicts created by this import Slide 79 La première tâche de l administrateur est bien sûr de créer le repository grâce à la commande cvs init. cvsinit crée un référentiel CVS à l endroit précisé dans la variable d environnement CV SROOT. Ensuite, c est à lui de créer les modules grâce à la commande import. Ensuite l administrateur importe, par exemple, la distribution de CVS dans le repository. 5.5 Travailler dans les espaces de travail Pascal Molli (molli@loria.fr) 60 LORIA

61 Section Travailler dans les espaces de travail Travailler sur un module 1. setenv CVSROOT /local/lang/script/cvs 2. cvs checkout cvs; cd cvs 3. emacs README 4. cvs diff README; cvs status README 5. cvs commit README Slide 80 La première chose à faire pour un utilisateur CVS est un checkout du module sur lequel il désire travailler. Cette commande crée une copie locale du module. Il a désormais un nouveau répertoire (généralement du nom du module) dans le répertoire courant. Il peut alors travailler dans son nouvel espace de travail sans que les modifications des autres développeurs viennent le perturber. Il peut a tout moment rendre public tout ou partie de son travail en utilisant la commande commit. CVS peut être configuré de telle sorte que tous les utilisateurs du module soient prévenus par mail lorsque l un d entre eux effectue un commit. Ainsi, lorsqu une modification vient d être rendue publique, chaque utilisateur du module peut décider de se resynchroniser avec la nouvelle version du module grâce à la commande update. Pour créer son espace de travail, l utilisateur précise le référentiel qu il veut utiliser (CVSROOT), puis effectue un checkout du module qu il veut éditer. On peut remarquer qu un répertoire CVS est créé dans chaque répertoire de la copie locale. Ce répertoire est à l usage de CVS, il ne faut ni le détruire, ni modifier les fichiers qui s y trouve (sauf si on est un guru CVS... ). L utilisateur peut ensuite travailler comme d habitude sur ses fichiers. CVS est tout de même capable de lui donner des information supplémentaires... Pascal Molli 61 Équipe ECOO

62 5.5 Travailler dans les espaces de travail Section 5. Diff cvs diff README =============================================== RCS file: /local/lang/script/cvs/cvs/readme,v retrieving revision 1.2 diff -r1.2 README 4,5d3 < AAAAYYYOUUUUto!! < Slide 81 Si il demande un status : Pascal Molli (molli@loria.fr) 62 LORIA

63 Section Travailler avec les autres Status cvs status README ======================================================== File: README Status: Locally Modified Version: 1.2 Wed Dec 15 11:47: RCS Version: 1.2 /local/lang/script/cvs/cvs/readme,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Slide Travailler avec les autres Pour gérer le travail coopératif avec les autres utilisateurs, CVS utilise le paradigme du copier-modifier fusionner (à l image de ce que l on peut trouver le modèle des transactions longues... ) Pascal Molli 63 Équipe ECOO

64 5.6 Travailler avec les autres Section 5. Travailler avec les autres Paradigme du copier-modifier-fusionner (copy-modify-merge) : Chaque utilisateur prend un module dans un espace de travail où il est à l abri des problèmes de concurrence d accès Chaque utilisateur modifie librement les copies dont il dispose Chaque utilisateur se resynchronise avec la dernière version du référentiel avant de publier ses modifications. Il peut y avoir fusion suite à la resynchronisation. Slide 83 Supposons que l utilisateur veut rendre sa version de README publique... Pascal Molli (molli@loria.fr) 64 LORIA

65 Section Travailler avec les autres Commit Si il n y a pas de problèmes de changements concurrent, rendre publique un module est très simple : cvs commit -m "tout est bon" README Checking in README; /local/lang/script/cvs/cvs/readme,v <-- README new revision: 1.3; previous revision: 1.2 done Slide 84 Travailler avec les autres Si il y a eu des changements concurrents alors : cvs commit -m "tout est bon?". cvs commit: Examining. cvs commit: Up-to-date check failed for README cvs [commit aborted]: correct above errors first! Slide 85 Pascal Molli 65 Équipe ECOO

66 5.6 Travailler avec les autres Section 5. Il faut noter qu ici le Up-to-date check est effectué sur TOUS les composants du module. Si il échoue pour un seul des composants, alors toute la publication de résultats est annulée. Se resynchroniser : cvs update. pour chaque composant de l espace de travail, cvs essaye de déterminer si il est dans l un des états suivants : (?) unknown Le fichier en question n est pas connu dans CVS. Pour l ajouter, l utilisateur peut utiliser la commande cvs add [nom du fichier]. Le fichier passe alors dans l état (A)dded. (A)dded L utilisateur a ajouté un nouveau fichier (commande add) mais le fichier n est pas encore rendu public. Il sera ajouté au repository lors du prochain commit. (U)pdated Le fichier n existait pas dans la copie privée ou n avait pas été modifié localement. La nouvelle version remplace alors l ancienne. Slide 86 Pascal Molli (molli@loria.fr) 66 LORIA

67 Section Travailler avec les autres Se resynchroniser : cvs update. (R)emoved Dans la nouvelle version du module (dans le repository), le fichier en question n existe plus. Il est donc détruit de la copie locale. (M)odified Le fichier a été modifié localement, mais pas encore rendu public. Slide 87 CVS update (suite) (M)erged Le fichier a été modifié par un autre utilisateur mais aussi localement. Cependant CVS a réussit a effectuer un RCS merge sans détection de conflits. Une copie de sauvegarde est créée dans la copie privée. (C)onflict Le fichier a été modifié par un autre utilisateur mais aussi localement. CVS a détecté un conflit lors de la fusion. Une copie de sauvegarde du fichier local est créée. Le nouveau fichier contient des indications sur la position des conflits dans le fichier lui-même. Slide 88 Pascal Molli 67 Équipe ECOO

68 5.6 Travailler avec les autres Section 5. On peut bien sur avoir un compte-rendu plus agréable à regarder que le résultat de la commande en ligne, que ce soit avec une interface graphique ou encore mieux, une interface emacs : Slide 89 Pascal Molli (molli@loria.fr) 68 LORIA

69 Section Travailler avec les autres Slide 90 Point d entrée : M-X cvs-update [return] [chemin vers la copie locale]. Emacs lance alors un update sur le répertoire précisé en paramètre. Le résultat de update est alors présenté dans un buffer emacs. Toutes les commandes usuelles : commit, remove, add, diff,..., sont alors accessibles simplement. L interface Emacs ne propose pas certaines commandes (tag, import,...), mais elle reste très pratique pour les mises à jour quotidiennes. Pascal Molli 69 Équipe ECOO