Une introduction `a la gestion de configurations

Transcription

Une introduction à la gestion de configurations
Pascal Molli
email: [email protected]
web: http://www.loria.fr/˜molli
September 25, 2006
1
Pascal Molli ([email protected])
2
LORIA
Section 1.
1
Introduction
Introduction
Une introduction à la gestion de configuration
Pascal Molli
email: [email protected]
web: http://www.loria.fr/m̃olli
September 25, 2006
Slide 1
Pascal Molli
3
Équipe ECOO
1.1
Définitions
Section 1.
Objectifs
• Avoir des connaissances générales les gestionnaires de configuration : les
problèmes, les fonctionnalités, les concepts ...
• Manipuler des (petits) outils pour un peu démystifier (RCS,CVS . . . )
• Situer la place d’un CM dans l’organisation générale d’un développement.
• Vous convaincre d’utiliser ce type d’outils . . .
Slide 2
Cette présentation s’adresse à des personnes qui ne connaissent pas les gestionnaires de
configuration. Nous introduisons la problématique de la gestion de configuration à partir
d’un exemple concret : plusieurs personnes veulent travailler au développement d’un logiciel
...
1.1
Définitions
4
LORIA
Section 1.
1.1
Définitions
Définition
Standard Définition (IEEE 729-1983)
Identification : des composants. ex: Quelles versions des composants sont dans
la dernière release ?
Contrôle : des changements. ex: Quels changements ont été effectués sur cette
release ?
Accounting : traces, rapport d’état. ex: Quels est l’état des changements proposés
Audit et review : validation. ex: Est ce que la dernière release contient des
versions correctes ?
Slide 3
Définition étendue
Construction : gérer la construction du logiciel (make par exemple)
Modélisation du procédé : Assurer le respect du cycle de vie.
Travail d’équipe : Contrôler les interactions dans une équipe (coordination,
synchronisation, concurrence d’accès ...).
Slide 4
Pascal Molli
5
Équipe ECOO
1.2
Un progrè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 équipe, notification, rôles.
• DCM: Developper Configuration Management: accéder les composants pour
apporter des changements, espace de travail, travail en isolation.
• ACM: Application Configuration Management: Distribution, tolérance de pannes
Slide 5
1.2
Situer quelle est l’avancée dans la mise en place d’un procédé de l’utilisation d’un gestionnaire de conf.
6
LORIA
Section 1.
1.2
Slide 6
Slide 7
Pascal Molli
7
Équipe ECOO
1.3
1.3
Spectre des fonctionnalités d’un gestionnaire de configuration
Section 1.
Spectre des fonctionalités (S. Dart)
Slide 8
Finalement, comme je l’avais signalé au début de ce document, nous n’avons couvert
qu’une petite partie du domaine de la gestion de configuration :
8
LORIA
Section 1.
1.3
Contrôle
Comment et quand les changements sont opérés:
• Contrôle d’accès
• Requêtes de changement: conduite du procédé 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: système de construction
• Snapshot: geler l’état d’un produit
• Optimisation: réduire les temps de compilation et la place disque.
• Analyse d’impact: prédire les effets d’un changement
• Régénération.
Slide 10
Pascal Molli
9
Équipe ECOO
1.3
Section 1.
Audit
Maintenir une trace des produits et des procédés:
• Historique: maintenir l’historique des changements
• Traçabilité.
• Logging: enregistrement des détail des changements pour audit de la trace.
Slide 11
Travail d’équipe
Synchroniser et coordonner le travail d’équipe:
• Espace de travail : travail en isolation
• Résolution de conflit : fusion ...
• Famille : développement de produits interdépendant.
Slide 12
10
LORIA
Section 1.
1.3
Accounting
Corréler les faits entre les produits et le procédé:
• Statistiques: enregistrer et générer des statistiques
• Détermination d’état.
• Rapport d’avancement.
Slide 13
Procédé de fabrication
Gestion de l’évolution du produit:
• Support au cycle de vie: assurer le respect d’un procédé de fabrication
• Gestion des tâches: Suivit des tâches de développement
• Gestion des communications entre les tâches (en respect avec le procédés)
• Documentation: enregistrement du savoir-faire ...
Slide 14
Pascal Molli
11
Équipe ECOO
Problématique
Section 2.
Plan
• Problématique
• Modèles de gestion de configuration
• Modèle Checkin/Checkout : RCS
• Modèle par composition : CVS
• Conclusions - perspectives
Slide 15
2
Problématique
12
LORIA
Section 2.
Problématique
Figure 1: Thèmes abordés en gestion de configuration
Problématique
Plusieurs personnes veulent coopérer pour développer *ENSEMBLE* un logiciel.
Comment faire ?
• Tout le monde travaille dans un repertoire UNIX ? mais comment travailler sans
être gêné par les autres . . .
• Tous les participants ont chacun une copie ? mais comment propager les
changements chez les autres ? comment se synchroniser en évitant des mises
à jour perdues ?
Slide 16
Nous abordons les problèmes de gestion de configuration en partant de problèmes de travail coopératif. Il faut bien se rendre compte que cela ne constitue qu’un des thèmes abordés
en gestion de configuration parmi d’autres tout aussi importants (cf figure 1 : mécanismes
de construction du logiciel (Make et consort), traçabilité (versions, variant ...), procédés de
fabrication du logiciel. . .
Le travail coopératif est en fait un biais intéressant pour pré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
Équipe ECOO
Modèles de gestion de configuration
Section 3.
se reporter à la bibliographie si il s’intéresse à l’ensemble du domaine.
3
Modèles de gestion de configuration
Modèles CM
4 grands modèles [3]:
• Checkin/Checkout
• Composition
• Transactions longues
• Change Sets
Slide 17
La définition de ces modèles est en fait le fruit d’un travail réalisé au Software Engineering
Institute. Ils ont tous un point commun : les utilisateurs travaillent sur des copies obtenues
auprès d’un référentiel commun. Pour travailler de manière coopérative, il faut pouvoir
propager les modifications effectuées sur un copie vers les autres copies . . .
3.1
Modèle des Checkin/Checkout
14
LORIA
Section 3.
3.1
Modèle Checkin/Checkout
Slide 18
Le modèle [4] est construit autour d’un référentiel avec des espaces de travail (cf figure ??). Le référentiel stocke un ensemble de fichiers multi-versionnés. Les versions sont
organisé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-versionné du référentiel ; plus concrètement
ce peut-être un répertoire UNIX peuplé de fichiers.
Pascal Molli
15
Équipe ECOO
3.1
Section 3.
Checkin/Checkout
L’utilisateur dispose de 2 opérations:
Checkout(id-objet,id-version) : id-objet référence un objet dans le référentiel.
id-version référence la version de cet objet. La valeur de l’objet ainsi déterminée
est copiée dans l’espace de travail de l’utilisateur.
Checkin(id-objet) : Si id-objet appartient à l’espace de travail de l’utilisateur alors
une nouvelle version de id-objet est créée dans le réfé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 é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 créer la
prochaine version. Attention ! ce n’est pas la sémantique habituelle d’un verrou
en écriture ...
Illustration : scénario du “Quick bug fix” . . .
Slide 20
16
LORIA
Section 3.
3.1
La accès concurrents sont gérés en utilisant des verrous en lecture/écriture. Si un fichier
est extrait du référentiel en écriture alors son utilisateur est assuré de pouvoir créer la
prochaine version du fichier dans la même branche. Ce mode de fonctionnement permet :
le développement en parallèle En effet il est possible de développer un même fichier
selon deux voies différentes dans deux branches séparées. Une branche peut être
ultérieurement fusionnée avec une autre ou abandonnée.
La gestion des mises à jour conflictuelles Supposons qu’un fichier soit en cours de
modification. Cette modification est longue, le fichier est verrouillé. Un autre utilisateur désire effectuer rapidement un changement mineur. Il peut accéder au fichier, le
modifier et créer une nouvelle version dans une autre branche. Cette nouvelle version
peut être fusionnée à la version principale ultérieurement.
La fusion de deux branches de développement peut devenir une tache complexe. En
effet, cette fusion peut être vue comme une tache d’intégration des différentes versions
du fichier. Son issue est incertaine, elle peut être anodine ou impossible et remettre
tout le développement initial en cause. Des outils sont disponibles pour assister cette
tâche mais ne peuvent l’automatiser.
Quick bug fix (1)
Slide 21
Pascal Molli
17
Équipe ECOO
3.1
Section 3.
Quick bug fix (2)
Slide 22
Quick bug fix (3)
Slide 23
18
LORIA
Section 3.
3.1
Quick bug fix (4)
Slide 24
Voilà une des raisons pour lesquelles il faut un gestion de version non-linéaire ...
Pascal Molli
19
Équipe ECOO
3.1
Section 3.
Gestion des branches
À quoi ça sert ?
• Développement en parallèle
• Représentation de variantes (unix,pc ..)
• Développement expérimental
• Fusion ...
Slide 25
Bon. Il faut se faire un peu au vocabulaire : “baseline” c’est une branche privilégiée du
développement. Attention les fusions, c’est pas automatique . . .
20
LORIA
Section 3.
3.2
Composition
Conclusion
• Gestion de version fichier par fichier
• Identification : composant → fichier
• Contrôle : checkin, checkout + protocole de contrôle de la concurrence
(préserve des mises-à-jour perdues)
• État/accounting/audit : graphe direct acyclique des versions
• Ex: SCCS, RCS, Razor ...
Slide 26
Ce modèle supporte le développement en parallèle. Ceci est possible dans le mesure
où les utilisateurs prennent eux-même en charge la gestion des versions. Par contre, la
correction des exé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 développement, le second de la revue de code. Nous pouvons obtenir l’exécution
suivante :
Produire(x.c, y.c) Vérifier(x.c, y.c)
checkout(x.c)
checkout(y.c)
edit(x.c)
edit(y.c)
checkin(x.c)
checkout(x.c)
checkout(y.c)
lire(x.c, y.c)
checkin(y.c)
Dans ce cas, la revue se fait avec des valeurs incohérentes de x.c et y.c. Cette exécution
montre en fait une lecture impropre de l’activité de revue. Ce modèle permet effectivement
de travailler en parallèle sur un même objet en utilisant plusieurs versions d’un même objet
mais ne contrôle pas la correction proprement dite des exécutions concurrentes.
Toutefois il faut remarquer que dans ce modèle, les objets sont toujours disponibles en
lecture.
3.2
Composition
Ce modèle s’inscrit comme une suite logique du premier. Il est construit lui-aussi autour d’un
référentiel et d’espaces de travail mais avec la notion de configuration. Une configuration
Pascal Molli
21
Équipe ECOO
3.2
Composition
Section 3.
est sous-ensemble nommé, cohérent et mono-versionné du référentiel.
Les opérateurs de transferts entre le référentiel et les espaces de travail restent les mêmes
mais peuvent s’appliquer sur une configuration (cf figure ??). Dans ce cas la configuration
est transférée de manière atomique.
Modèle par composition
Slide 27
Le transparent 27 montre comment deux utilisateurs travaillent sur deux configurations
différentes du même ensemble d’objets. Il faut remarquer que les utilisateurs ont transféré
non plus un fichier comme dans le modèle précédent, mais une configuration dans leurs
espaces de travail respectifs.
22
LORIA
Section 3.
3.2
Composition
Configuration
• configuration : un sous-ensemble nommé, mono-versionné, cohérent d’objets.
• checkin, checkout sur une configuration !
• oui mais comment obtenir cette configuration ??
Slide 28
Détermination d’une configuration
En deux temps :
• Agrégation des composants (basée sur le modèle d’objet)
• Selection de la version appropriée de chaque composant de l’agrégation
• finalement ça ressemble à une requête ...
Slide 29
Pascal Molli
23
Équipe ECOO
3.2
Composition
Section 3.
Agrégation des composants
• agrégation basée sur les dépendances entre les composants. Comment
déterminer ces dépendances ? :
– Les dépendances entre objets sont déclarés explicitement pourquoi pas
dans une base de données.
– Évidemment, plus le modèle d’objet du référentiel est riche plus il est facile
de représenter directement les dépendances entre objets.
Slide 30
Selection des versions (de l’agrégat)
• chemin de recherche dans les branches de version : branche de
développement sun3, autres espaces de travail ...
• basée sur des propriétés (attributs sur les objets) :
windowsystem==x11 and
WSrelease > R3 &
(status == tested or
reserved=me)
Slide 31
24
LORIA
Section 3.
3.2
Composition
• Finalement comme dans le checkin/checkout model . . .
• Mais en gérant cette fois des configurations
Slide 32
Conclusions
• Identification: Agrégation + selection de version
• Contrô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
Équipe ECOO
3.3
Transactions longues
Section 3.
Les différents acteurs d’un développement peuvent coopérer en publiant des configurations successives d’une configuration. Mais le protocole même de coopération reste entre
les mains des utilisateurs. Quand faut-il publier ses résultats, quand faut-il absolument les
relire, tout cela n’est pas défini dans ce modèle.
Il faut tout de même remarquer que dans ce modèle, un espace de travail se comporte
comme une sphère d’isolation où tout changement ne peut être opéré que de l’intérieur.
L’utilisateur d’un espace de travail est donc protégé des actions effectuées au sein des autres
espaces mais peut à tout moment se resynchroniser avec le référentiel à son initiative.
3.3
Dans ce modèle [2, 1], le référentiel est vu comme une base de données. Une activité de
développement s’effectue au sein d’une transaction et fait passer la base d’un état cohérent
dans un autre. Les états cohérents sont représentés comme des configurations.
Le modèle adopte la stratégie suivante :
1. Chaque transaction à sa cré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 à l’utilisateur une sphère de stabilité où tous les changements sont faits à son
initiative. Il est important de noter que les changements opérés dans la transaction
ne seront visibles qu’à sa terminaison.
2. À sa terminaison, la transaction produit une nouvelle configuration des objets à partir
des valeurs présentes dans son contexte.
Rappels transactionnels
Transactions ACID:
Atomicité : tout ou rien
Consistance : Si la transaction individuellement fait passer la base d’un état
correct dans un autre alors l’exécution concurrente n’introduit pas
d’inconsistance (sérialisabilité).
Isolation : pas de visibilité sur les résultats partiels
Durabilité : les résultats validés ne sont pas remis en cause.
Slide 34
26
LORIA
Section 3.
3.3
Modèle des transactions longues
• Encapsuler une activité de développement dans une transaction
• Voir un développement comme une transaction imbriquée.
• PB: Durée indéterminée → transaction plus longue qu’une session.
• PB: Isolation trop forte ...
Slide 35
Ce modèle permet également d’emboı̂ter les transactions. Le référentiel peut être considéré comme la mémoire locale d’une transaction racine. Les transactions s’organisent
alors selon un arbre ; l’espace de travail d’une transaction constitue le référentiel de ses
sous-transactions.
Cette approche permet de structurer le développement en décomposant une activité en
sous-activités, chaque activité s’exécutant au sein d’une transaction. Par exemple, il est
possible de décomposer l’activité “projet” selon l’arbre d’activité décrit dans la figure ??.
Pascal Molli
27
Équipe ECOO
3.3
Section 3.
Slide 36
Idée
• Représenter les états corrects de la base comme une configuration
• Représenter la transaction et sa mémoire locale comme un espace de travail.
Slide 37
28
LORIA
Section 3.
3.3
Slide 38
• Les résultats d’une transaction sont produits à la fin de la transaction. (pas de
publication de résultats avant la fin !!).
• Possibilité de gestion de la concurrence optimiste : paradigme du
copier-modifier-fusionner.
Slide 39
Pascal Molli
29
Équipe ECOO
3.3
Section 3.
Figure 3: Copier-modifier-fusionner: copier et modifier
Figure 4: Copier-modifier-fusionner: fusionner
Le modèle propose un protocole de contrôle des accès concurrents optimiste. Prenons
un exemple : Soit deux transactions ayant démarrées avec la même configuration R1 (cf
figure 3). Elles développent en parallèle deux nouvelles configurations (R2 et R3 sur notre
figure). La première transaction termine et rend la configuration R2 durable.
La seconde transaction ne peut alors terminer sous peine d’écraser R2. Elle est obligée
de relire R2 et de fusionner avec R3 pour pouvoir terminer sur une configuration R4 (cf
figure 4).
Il faut remarquer que cette stratégie de contrôle des accès concurrents évite les mises à
jour perdues et ne fait pas appel à un procédé de fabrication particulier. Il ne peut exister
non plus de lectures impropres dans la mesure où toute transaction termine en produisant
une configuration cohérente. Le référentiel est donc toujours dans un état cohérent.
30
LORIA
Section 3.
3.3
Slide 40
Slide 41
Pascal Molli
31
Équipe ECOO
3.4
Change sets
Section 3.
Conclusions
• Identification: read/write dans le référentiel, transparente
• Contrôle: Transactions (begin, terminate).
• Accounting/audit: graphe de versions.
• Ex: NSE [1].
Slide 42
3.4
Change sets
32
LORIA
Section 3.
3.4
Change sets
Change sets
• Au lieu de nommer les versions, on nomme les deltas
• Orienté changement vs Orienté version.
• Un “Change-Set” : l’ensemble des deltas entre deux configurations.
• Pour dé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
Équipe ECOO
3.4
Change sets
Section 3.
Change Sets
La connaissance des change-set permet de déduire beaucoup d’information :
• Déterminer quels composants ont été modifiés comme partie d’un même
changement logique : exprime les dépendances entre composants
• Déterminer la collection des change sets dont un composant fait partie :
information sur la stabilité des composants
• Déterminer quels “change set” sont inclus dans une configuration (infos sur les
capacités de la configuration . . . )
• Déterminer quelles configurations incluent un changement particulier (infos sur
la propagation d’un changement)
Slide 45
Composition consistantes
• Cré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 dépendent de la
présence d’autres.
• La consistance d’une composition peut être déterminée en analysant les
read-set et write-set de chaque change set.
• même read-set et write-set différent : un conflit, d’où une fusion nécessaire.
• Trouver un ordre de composition où les read-set, write-set sont compatibles →
une sorte de sérialisation a posteriori des activités de changement.
Slide 46
34
LORIA
Section 3.
3.5
Conclusion
Conclusions
• Identification: baseline + change-sets
• Contrôle: création de change-sets. Pas vraiment de gestion de concurrence
dans le modèle. C’est un problème orthogonal.
• Accounting/review: analyse des change-sets
• Ex: Aide-de-camp.
Slide 47
3.5
Conclusion
Pascal Molli
35
Équipe ECOO
3.5
Conclusion
Section 3.
Conclusions
• Pour l’instant, les modèles utilisés : Checkin/checkout et composition.
• Attention, ces modèles ne constitue qu’un petite partie de ce que l’on peut dans
le domaine de la gestion de configuration : modèles d’objets, systèmes de
construction, suivi de problèmes ...
• Technologie en pleine évolution.
• perspectives: gestion des procédés de fabrication (continuus), gestion du travail
d’équipe (coopération) et gestion de la distribution à large é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 fonctionnalités de bases que l’on peut trouver dans un vrai gestionnaire de
configuration comme Clearcase ou Continuus . . . On peut tout de même aborder une certaine
classe de problèmes qui sont déjà très intéressant et notamment le travail à plusieurs . . .
36
LORIA
Section 4.
4
RCS : Revision Control System
RCS : Revision Control System
RCS: checkin/checkout model
Objectifs . Connaı̂tre les fonctionnalités de outils fonctionnant sur ce modèle et
surtout la surcharge de travail lié a leur utilisation (coût/gain).
Environnement de développement . RCS + Emacs.
Documentation man rcsintro et [5]
Slide 49
Gère des révisions multiples de fichiers. automatise le stockage, la récupération, l’historique,
l’identification, et la fusion de révision.
4.1
Architecture générale
Pascal Molli
37
Équipe ECOO
4.2
Fonctionnalités
Section 4.
Architecture Générale
Slide 50
Bon, on instancie le modèle avec un système de fichier. Les référentiel est en fait un
répertoire contenant des fichiers au format RCS (extension ,v). Ce format permet d’archiver
(de maniè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 référentiel. Ce lien doit impérativement s’appeler
RCS.
Il est possible de stocker à la fois les fichiers RCS et les fichiers de travail dans le même
répertoire, mais il me semble que la première façon de procéder est bien meilleure pour
travailler en multi-utilisateur.
4.2
Fonctionnalités
38
LORIA
Section 4.
4.2
Fonctionnalités
Fonctionnalités
Stocker et récupérer. Des opérateurs (co, ci). Des identificateurs de version. Un
référentiel pour le stockage proprement dit (f.c → f.c,v soit dans le repertoire
courant, soit dans un sous répertoire RCS).
Historique. à chaque checkin qui a fait (auteur) ? quoi (msg) ? quand (date:time) ?
pourquoi ... stocker l’historique où → dans le fichier
Résoudre les conflits d’accès. Alerter deux programmeurs qui veulent modifier la
même version en même temps.
Maintenir des branches de développement.
Slide 51
Fonctionnalités
Fusionner des révisions. deux fichiers avec deux lignes différente au même
endroit sont marquée comme conflictuelles et l’utilisateur est alerté.
Contrôler des révisions. nom symbolique pour un ensemble de fichiers (flat).
Identification des révisions. par le nom, l’id, la date de création ...
minimiser la taille du stockage. Gestion de deltas → vitesse de récupération.
Slide 52
Pascal Molli
39
Équipe ECOO
4.2
Fonctionnalités
Section 4.
Mise sous RCS d’un fichier de travail
Cré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 -->
revision 1.1
done
f.c
• extraction de f.c:1.1 dans un fichier de travail en écriture
% co -l f.c
RCS/f.c,v --> f.c
revision 1.1 (locked)
done
Slide 54
40
LORIA
Section 4.
4.2
Fonctionnalités
Travail sur le fichier
On travaille sur le fichier de travail de manière tout fait normale. . .
% emacs f.c
On dispose tout de même d’informations supplé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
Équipe ECOO
4.2
Fonctionnalités
Section 4.
---------------------------revision 1.2
date: 1997/04/21 16:40:12; author: molli; state: Exp; lines: +1 -0
yo
=============================================================================
Slide 57
Slide 58
42
LORIA
Section 4.
4.2
Fonctionnalités
On peut tout de même travailler avec des outils un peu plus évolué que les commandes en
lignes . . . RCS est remarquablement intégré dans emacs (No de version dans la “modeline”,
appel au package “ediff” pour voir les différences entre deux versions, checkin/checkout
depuis emacs . . . )
Slide 59
l’opération la plus complexe reste le “checkin”. Le transparent 59 illustre les différents
scénario possible.
au moment du checkin , il peut y avoir deux cas de figure :
1. soit l’utilisateur possède un verrou en écriture sur f.c : dans ce cas, c’est très simple,
il y a création d’un nouvelle version de f.c et la version de travail est détruite.
2. soit l’utilisateur ne possède pas de verrou en écriture et dans ce cas il lui faut essayer
de l’acquérir a posteriori :
(a) Si f.c n’est pas verrouillé, alors retour au checkin normal
(b) sinon 3 cas de figure :
i. RCS donne le nom de la personne propriétaire du verrou, on peut donc
envoyer un mail et tenter de négocier . . .
ii. La modification est urgente est prioritaire. Dans ce cas, il est possible de
voler le verrou. Un mail est envoyé à l’innocente victime de ce vol qualifié
pour l’avertir de l’effraction.
iii. Dernier cas de figure : créer une nouvelle branche de développement, et nous
retombons dans le modèle du checkin/checkout.
Quelques remarques avant de passer à la gestion de branches dans RCS :
Pascal Molli
43
Équipe ECOO
4.2
Fonctionnalités
Section 4.
Verrouillage
Comportement différent pour la personne possédant le fichier
• off pas de test de lock pour le propriétaire en cas de checkin
% rcs -U f.c
• on : test de lock pour le propriétaire en cas de checkin
% rcs -L f.c
Slide 60
Verrouillage
Pour empêcher la destruction du fichier pendant le checkin
• checkin suivi immédiatement de co avec lock.
% ci -l f.c
• checkin suivi immédiatement de co sans lock.
% co -u f.c
Slide 61
44
LORIA
Section 4.
4.3
4.3
Numérotation RCS
• nombre pair de chiffres : numéro de révision
• nombre impair : numéro de branche
Slide 62
Pascal Molli
45
Équipe ECOO
4.3
Section 4.
• dans la baseline 2.1, 2.2, 2.3 ...
% ci -r2 f.c
• Démarrage d’une nouvelle branche à partir de la révision 1.3.
% ci -r2.1 f.c
% co -r2 f.c
% ci -r1.3.1 f.c
Slide 63
Scénario du Quick Bug fix
• au début:
1.1 -> 1.2 -> 1.3 -> 2.1 -> 2.2
• 1.3 distribuée au client ! bug fix demandé :
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.1 -> 1.2 -> 1.3 -> 2.1 -> 2.2
\-> 1.3.1.1 -> 1.3.1.2
Slide 64
46
LORIA
Section 4.
4.3
Intégration des deux branches
En fait sortir les deux dernières révision de chaque branche et appeler l’opération
de fusion semi-automatique :
% co -j1.3.1 f.c
revision 2.2
revision 1.3
revision 1.3.1.2
merging...
merge warning: overlaps during merge
done
% edit f.c
Slide 65
Cette syntaxe est maintenant obsolète depuis l’apparition de rcsmerge :
rcsmerge -p -r1.3.1.2 -r2.2
edit f.merged.c
mv f.merged.c f.c; ci f.c
f.c
>f.merged.c
Mais ça marche toujours et je la trouve plus agréable que le rcsmerge . . .
Pascal Molli
47
Équipe ECOO
4.4
Gestion des deltas
Section 4.
Exemple de résultat d’une fusion
more f.c
riri
<<<<<<< 2.2
fifi
=======
loulou
>>>>>>> 1.3.1.2
Slide 66
4.4
Gestion des deltas
48
LORIA
Section 4.
4.5
Trace
Gestion des deltas
• Minimiser la taille de stockage sans trop pénaliser le co.
• reverse deltas vs delta.
<1.1 -> <1.2 -> 1.3 -> 2.1 -> |2.2|
\> 1.3.1.1 -> 1.3.1.2
Slide 67
4.5
Trace
Pascal Molli
49
Équipe ECOO
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 message 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).
50
LORIA
Section 4.
4.5
Trace
Entêtes de fichiers
%
%
%
%
%
%
%
%
%
%
$Source$
$Revision$
$Date$
$Author$
$State$
CONTENU-DESCRIPTION <...>
Change History
$Log$
Slide 69
%
%
%
%
%
$Source: /local/genielog/cvspres/cvs.tex,v $
$Revision: 1.1.1.1 $
$Date: 1993/12/23 14:48:10 $
$Author: molli $
$State: Exp $
% CONTENU-DESCRIPTION
% Transparents et commentaires de présentation
% de cvs pour la journée de présentation des
% moyens informatiques CRIN-INRIA
%
%
%
%
%
%
%
%
%
Change History
$Log: cvs.tex,v $
Revision 1.1.1.1 1993/12/23
expo CVS
14:48:10
molli
Revision 1.9 1993/12/02 14:42:06 garti
Version de la presentation pour la "vrai"
installation du CRIN
Slide 70
Pascal Molli
51
Équipe ECOO
4.6
4.6
Contrôle d’accès
Section 4.
Contrôle d’accès
liste d’accès
• gestion nominative des accès au fichier RCS.
• chaque fichier rcs contient une liste des utilisateur qui ont le droit de faire des
mises à jour:
rcs -alogins
rcs -elogins ...
Slide 71
4.7
Intégration avec Make
52
LORIA
Section 4.
4.7
Intégration avec Make
Make et RCS
auto-checkout des fichiers nécessaire à 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
Équipe ECOO
4.8
4.8
Autres commandes
Section 4.
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 74
4.9
Conclusions
54
LORIA
Section 4.
4.9
Conclusions
Conclusions
• Modèle Checkin/Checkout.
• utile pour la gestion de quelques fichiers
• faiblesse dans la gestion d’un ensemble de fichiers eparpillés dans un arbre de
directory → CVS.
Slide 75
Pascal Molli
55
Équipe ECOO
CVS : Concurrent Version System
5
5.1
Section 5.
CVS : Concurrent Version System
Qu’est ce que CVS ?
CVS est un outil de contrôle de révision destiné à des groupes de développeurs travaillant
sur les mêmes fichiers. CVS leur permet de travailler en isolement et de se resynchroniser
les uns par rapport aux autres quand ils le désirent.
Travailler à plusieurs sur les même objets en même temps. La différence majeure
de CVS par rapport à d’autres outils plus vieux comme RCS ou SCCS est de permettre à plusieurs développeurs de travailler sur les mêmes fichiers en même temps.
Chaque développeur travaille isolément dans son espace de travail (un répertoire
UNIX). Un répertoire partagé est utilisé comme point de rendez-vous pour rendre
publics des fichiers locaux ou pour inclure le travail effectué en parallèle par les autres
développeurs.
Gérer les versions des sources d’un développement. Jusqu’alors des outils comme RCS
ou SCCS se limitaient à la gestion de version d’un seul fichier. CVS réutilise RCS pour
sa gestion de version de fichiers mais permet aussi la gestion de version d’un répertoire.
Suivre les versions d’un logiciel externe. L’installation de logiciels externes demande
très souvent des modifications locales au site. Un travail pénible consiste a répercuter
ces modifications lorsqu’une nouvelle version du logiciel arrive. CVS permet à l’installateur
de détecter quelles modifications il avait effectué, quels sont les changements apportés
par la nouvelle version, fichier par fichier et donc, de se rendre compte si les modifications locales ont toujours lieu d’être ou pas.
Gestion des branches de développement. RCS permet une gestion non linéaire des
versions pour un fichier. CVS offre la même possibilité mais pour un répertoire. Un
groupe de dé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 contrôle de révision, ce n’est pas un système de gestion de configuration.
5.3
CVS : un modèle par composition
56
LORIA
Section 5.
5.3
Slide 76
C’est une instanciation du modèle par composition sur un système de fichier. Une
configuration est un aggrégat d’objets mono-versionnés. L’aggrégat apparait à 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 carrés gris représentent des sous-types de répertoire. Les carrés blancs, des soustypes de fichier. Les fléches fines représentent une relation 1-1, les fléches doubles une
relation 1-n (pas de relation n-n dans ce schéma). La flèche épaisse représente une relation
de sous-typage. Enfin, les carrés aux bords arrondis représentent les méthodes associées aux
types.
La partie administrateur représente les objets présents dans le repository, la partie util-
Pascal Molli
57
Équipe ECOO
5.3
Section 5.
isateur les objets présents dans une copie de travail.
Une configuration : un aggrégat d’objets mono-versionnés. Il faut donc :
1. déterminer l’aggrégat puis,
2. sélectionner une version pour chaque composant de l’aggrégat.
Sous CVS, un aggrégat est représenté par un module :
module := [module]+ | répertoire | fichier
Slide 77
58
LORIA
Section 5.
5.4
Créer un référentiel
CVS ne dispose pas d’un mécanisme de selection de version perfectionné. Pour un
module :
• Configuration : la dernière version de chaque composant du module
• Étiquette symboliques : nommage explicite par l’utilisateur (rcs tag ...)
Slide 78
5.4
Créer un référentiel
Pascal Molli
59
Équipe ECOO
5.5
Travailler dans les espaces de travail
Section 5.
Créer le réfé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 première tâche de l’administrateur est bien sûr de créer le repository grâce à la
commande cvs init. cvsinit crée un référentiel CVS à l’endroit précisé dans la variable
d’environnement CV SROOT .
Ensuite, c’est à lui de créer les modules grâce à la commande import.
Ensuite l’administrateur importe, par exemple, la distribution de CVS dans le repository.
5.5
60
LORIA
Section 5.
5.5
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 première chose à faire pour un utilisateur CVS est un checkout du module sur lequel
il désire travailler. Cette commande crée une copie locale du module. Il a désormais un
nouveau répertoire (généralement du nom du module) dans le répertoire courant.
Il peut alors travailler dans son nouvel espace de travail sans que les modifications des
autres développeurs viennent le perturber.
Il peut a tout moment rendre public tout ou partie de son travail en utilisant la commande
commit.
CVS peut être configuré de telle sorte que tous les utilisateurs du module soient prévenus
par mail lorsque l’un d’entre eux effectue un commit. Ainsi, lorsqu’une modification vient
d’être rendue publique, chaque utilisateur du module peut décider de se resynchroniser avec
la nouvelle version du module grâce à la commande update.
Pour créer son espace de travail, l’utilisateur précise le référentiel qu’il veut utiliser
(CVSROOT), puis effectue un checkout du module qu’il veut éditer.
On peut remarquer qu’un répertoire CVS est créé dans chaque répertoire de la copie
locale. Ce répertoire est à l’usage de CVS, il ne faut ni le dé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
même capable de lui donner des information supplémentaires . . .
Pascal Molli
61
Équipe ECOO
5.5
Section 5.
Diff
cvs diff README
===============================================
RCS file: /local/lang/script/CVS/cvs/README,v
diff -r1.2 README
4,5d3
< AAAAYYYOUUUUto !!
<
Slide 81
Si il demande un status :
62
LORIA
Section 5.
5.6
Travailler avec les autres
Status
cvs status README
========================================================
File: README
Status: Locally Modified
Version:
RCS Version:
Sticky Tag:
Sticky Date:
Sticky Options:
1.2 Wed Dec 15 11:47:59 1993
1.2 /local/lang/script/CVS/cvs/README,v
(none)
(none)
(none)
Slide 82
5.6
Pour gérer le travail coopératif avec les autres utilisateurs, CVS utilise le paradigme du
copier-modifier fusionner (à l’image de ce que l’on peut trouver le modèle des transactions
longues . . . )
Pascal Molli
63
Équipe ECOO
5.6
Section 5.
Paradigme du copier-modifier-fusionner (copy-modify-merge) :
• Chaque utilisateur prend un module dans un espace de travail où il est à l’abri
des problèmes de concurrence d’accès
• Chaque utilisateur modifie librement les copies dont il dispose
• Chaque utilisateur se resynchronise avec la dernière version du référentiel avant
de publier ses modifications. Il peut y avoir fusion suite à la resynchronisation.
Slide 83
Supposons que l’utilisateur veut rendre sa version de README publique . . .
64
LORIA
Section 5.
5.6
Commit
Si il n’y a pas de problèmes de changements concurrent, rendre publique un
module est trè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
Si il y a eu des changements concurrents alors :
cvs
cvs
cvs
cvs
commit -m "tout est bon ?" .
commit: Examining .
commit: Up-to-date check failed for ‘README’
[commit aborted]: correct above errors first!
Slide 85
Pascal Molli
65
Équipe ECOO
5.6
Section 5.
Il faut noter qu’ici le “Up-to-date check” est effectué sur TOUS les composants du
module. Si il échoue pour un seul des composants, alors toute la publication de résultats
est annulée.
Se resynchroniser : cvs update .
pour chaque composant de l’espace de travail, cvs essaye de déterminer si il est
dans l’un des é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’état (A)dded.
(A)dded L’utilisateur a ajouté un nouveau fichier (commande add) mais le fichier
n’est pas encore rendu public. Il sera ajouté au repository lors du prochain
commit.
(U)pdated Le fichier n’existait pas dans la copie privée ou n’avait pas été modifié
localement. La nouvelle version remplace alors l’ancienne.
Slide 86
66
LORIA
Section 5.
5.6
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 détruit de la copie locale.
(M)odified Le fichier a été modifié localement, mais pas encore rendu public.
Slide 87
CVS update (suite)
(M)erged Le fichier a été modifié par un autre utilisateur mais aussi localement.
Cependant CVS a réussit a effectuer un RCS merge sans détection de conflits.
Une copie de sauvegarde est créée dans la copie privée.
(C)onflict Le fichier a été modifié par un autre utilisateur mais aussi localement.
CVS a détecté un conflit lors de la fusion. Une copie de sauvegarde du fichier
local est créée. Le nouveau fichier contient des indications sur la position des
conflits dans le fichier lui-même.
Slide 88
Pascal Molli
67
Équipe ECOO
5.6
Section 5.
On peut bien sur avoir un compte-rendu plus agréable à regarder que le résultat de la
commande en ligne, que ce soit avec une interface graphique ou encore mieux, une interface
emacs :
Slide 89
68
LORIA
Section 5.
5.6
Slide 90
Point d’entrée : M-X cvs-update [return] [chemin vers la copie locale]. Emacs lance alors un
update sur le répertoire précisé en paramètre. Le résultat de update est alors présenté 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
très pratique pour les mises à jour quotidiennes.
Pascal Molli
69
Équipe ECOO
5.6
Section 5.
Se resynchroniser
Sur notre exemple avec notre README, “cvs update .” donne ceci :
cvs update: Updating .
RCS file: /ens/stage/molli/cvsrep/essai/README,v
retrieving revision 1.1.1.1
Merging differences between 1.1.1.1 and 1.2 into README
rcsmerge warning: overlaps during merge
cvs update: conflicts found in README
C README
Slide 91
Conflit
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char **argv)
{
<...>
else
fprintf(stderr, "No code generated.\n");
<<<<<<< driver.c
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
=======
exit(!!nerr);
>>>>>>> 1.6
Slide 92
70
LORIA
Section 5.
5.7
Gestion de branches
L’utilisateur peut savoir quelles sont les différences entre sa copie locale et la dernière
version existante dans le repository par la commande diff. Il peut savoir l’état précis de son
fichier (révision RCS, étiquettes symboliques ...) par la commande status. Si l’utilisateur a
mis des entêtes RCS dans chacun de ses fichiers alors, CVS les gère et peut les extraire par
la commande status.
On peut se faciliter la tâche toujours avec le fabuleux package ediff d’emacs pour faire
de la fusion interactive . . .
5.7
Gestion de branches
Étiquettes symboliques
file1
file2
1.1
1.1
1.2*- 1.2
1.3 \-1.3*1.4
\
file3
file4
file5
1.1
1.1 /--1.1*
1.2
-1.2*1.3
/ 1.3
1.4 / 1.4
\-1.5*
1.5
1.6
<-*-
<tag>
Slide 93
CVS permet de donner une étiquette symbolique à un état du développement. Par
exemple, lorsque l’on veut délivrer une première version du logiciel, on peut lui attribuer une
étiquette symbolique REV-1.0. C’est l’objectif des commandes tag et rtag. La commande
checkout peut alors être utilisée avec cette étiquette.
Pascal Molli
71
Équipe ECOO
5.7
Gestion de branches
Section 5.
Étiquettes symboliques et branches
1. Étiquettes symboliques : fixer une état du module.
2. cvs rtag REV 1 4 cvs / cvs checkout -r REV 1 4 cvs
3. Branche de développement : développement concurrent du même module par
deux groupe de développeurs.
4. cvs rtag -b -r REV 1 3 FIX 1 3 cvs
5. cvs checkout -r FIX 1 3
6. Réunir les deux branches : cvs checkout -j FIX 1 3 dans une copie locale de la
branche principale (scénarion du Quick bug Fix).
Slide 94
• Supposons que la version 1.0 soit délivrée chez un client et que celui-ci trouve un bug
sérieux. Avant de s’en rendre compte, la version 1.1 avec de nouvelles fonctionnalités
est en cours de développement. CVS permet dans ce cas, de créer une seconde branche
de développement à partir de l’etiquette REV-1.0, par exemple FIX-1.0. Un second
groupe de développeurs peut alors travailler sur FIX-1.0 pendant que le premier groupe
continue à travailler sur la version principale. Les utilisateurs de FIX-1.0 doivent
simplement préciser qu’ils veulent effectuer un checkout de FIX-1.0. Tous leurs commit
et update ultérieurs seront effectués sur FIX-1.0. Le groupe travaillant sur la version
principale ne verra aucun des changements effectués par le groupe FIX-1.0.
• Lorsque le groupe principal veut intégrer les changements effectués dans FIX-1.0 alors
il peut utiliser la commande join (cvs -j) de CVS. Cette commande permet de faire
un update de la copie locale avec une version étiquetée du module. Cela se déroule
comme un update ordinaire.
5.7.1
Administrater CVS
72
LORIA
Section 5.
5.7
Gestion de branches
Administrer CVS
Un *MODULE* d’administration, composé des fichiers de configurations suivants :
loginfo : commande de fin de commit
editinfo : test de cohérence du message de commit
commitinfo : commande exécutée avant le commit
rcsinfo : entête générique d’un message de commit
modules : spécification des modules
cvsignore : spécification des fichiers à ignorer.
Slide 95
L’administrateur CVS peut personnaliser le comportement de CVS grâce à un système
de triggers définis dans les fichiers de configuration suivant :
loginfo. Ce fichier contient deux colonnes : une expression régulière destinée à être confronté à des chemins contenus dans le repository et une commande à exécuter dans
ce cas. Ce fichier est lu lorsqu’une comnmande commit réussit. On peut utiliser ce
déclencheur de fin de commit pour envoyer un mail aux utilisateurs du module.
editinfo. Même composition que loginfo. La commande est exécutée avant la commande
de loginfo. Elle a pour objectif de faire quelques tests de cohérence sur le message
de commit. Par exemple, si c’est la correction d’une erreur, le message contient-il un
numéro d’erreur ?
commitinfo. Même composition que loginfo. Cette commande est exécutée avant de
procéder au commit proprement dit. On peut utiliser ce déclencheur pour faire des
tests de qualité. Par exemple, vérifier que le module peut encore être compilé sans
erreurs.
rcsinfo. La seconde colonne contient le nom d’un fichier contenant un formulaire à remplir
à chaque commit.
modules. Contient la specification des modules.
cvsignore. Contient les expressions régulières des fichiers que CVS ne doit pas prendre en
compte (*.o, * , ...).
Pascal Molli
73
Équipe ECOO
5.7
Gestion de branches
Section 5.
Configurer la notification pour un module
Les fichiers de configuration font partie du module CVSROOT :
%
U
U
U
U
U
U
U
U
U
cvs checkout CVSROOT
CVSROOT/checkoutlist
CVSROOT/commitinfo
CVSROOT/cvswrappers
CVSROOT/editinfo
CVSROOT/loginfo
CVSROOT/modules
CVSROOT/notify
CVSROOT/rcsinfo
CVSROOT/taginfo
Slide 96
Ajouter un module
fichier “modules” du module CVSROOT
# P-Root Obsolete schemas
proot_process
proot_process
demotest
demotest
administration administration
# P-Root Operations packaging ..
operations
-d schemas operations &proot &proot_lib &process &trigger
schemas
-a operations
# nouveau schéma
CVS
cvs
Slide 97
74
LORIA
Section 5.
5.8
Conclusion
Le fichier modules stocke la déclaration des modules. C’est un fichier à deux colonnes :
1. La première colonne contient les déclarations de nom de modules
2. La seconde décrit la composition du module. C’est soit un nom de fichier (aucun
sur notre exemple), un nom de repertoire (module CVS), soit une liste de modules
(module operation)
Mettre en place la notification
fichier “loginfo” du module CVSROOT
DEFAULT
ˆPROOT
$CVSROOT/CVSROOT/mfpipe.pl -f mycommitlog [email protected]
$CVSROOT/CVSROOT/mfpipe.pl -f mycommitlog [email protected]
Slide 98
C’est encore un fichier à deux colonnes :
1. La première colonne est un nom de module.
2. La seconde colonne est un programme à exécuter. Ici “mfpipe” permet d’envoyer du
mail à partir d’information extraites de CVS . . .
Je renvoie à la documentation (un peu difficile à lire sur ce point) pour tout ce qui est
syntaxe, paramètres etc ... sur ce sujet . . .
5.8
Conclusion
Pascal Molli
75
Équipe ECOO
5.9
Documentation
Section 5.
Conclusion
• CVS : Ca Vous Simplifie la vie de groupe : update
• CVS : Ca Vous Sauve la vie : gestion de version
• CVS : Ca Vous Signale ce qui se passe : update notice
• CVS : C’est Vraiment Super >; − >
• CVS : (Censured ...)
Slide 99
Nous utilisons CVS depuis environ 1 an dans notre équipe, pour le développement du
projet P-Root. CVS s’est révélé d’un grand secours :
• Le paradigme copier-modifier-fusionner est réellement un paradigme viable pour un
groupe de développeurs. Les problèmes de fusion sont rares et faciles à résoudre.
• La gestion de version, souvent transparente pour l’utilisateur, est très sécurisante pour
les développeurs. Elle permet toujours de faire un checkout sur une version qui marche
avant une démo 8).
• La gestion des messages de commit par mail, des entêtes de fichiers permet après de
se rendre compte de l’avancement des autres développeurs. Elle permet aussi de se
rendre compte de l’avancement (ou de la stagnation, mais c’est aussi une information)
du projet après une période d’absence.
• Subrepticement, CVS incite les développeurs à planifier le développement. C’est peutêtre là une explication au nombre réduit de conflits ...
5.9
Documentation
76
LORIA
Section 5.
5.9
Documentation
doc
Dans http://www.loria.fr/˜molli
• man 1 cvs (commandes)
• man 5 cvs (fichiers)
• Les Frequently Asked Question (FAQ)
• CVS en texinfo sous emacs (C-h i).
• pcl-cvs (le mode emacs) sous emacs en texinfo.
• CVS-tutorial sous emacs en texinfo.
• CVS II: Parallelizing Software Development, Brian Berliner.
Slide 100
Pascal Molli
77
Équipe ECOO
Conclusions
6
Section 6.
Conclusions
Conclusions
• CM: un premier pas vers une organisation de la production du logiciel
(ISO9000, CMM).
• Difficile à mettre en oeuvre :
– limites technologiques (gestion du procédé, intégration des outils, gestion de
l’hétérogénéité ...),
– aspects psychologiques,
– secteur en évolution (application, environnements)
Slide 101
78
LORIA
REFERENCES
REFERENCES
Conclusions générales
• Faire un premier pas du niveau 1 du CMM vers une organisation du logiciels
• Pour l’instant: des systèmes plus ou moins propriétaires ...
• Évolution des CM : Procédés de fabrication, travail coopératif.
Slide 102
References
[1] W. Courington. The Network Software Environment. Technical Report FE197-0, Sun
Microsystems Inc., February 1989.
[2] P. Feiler and G. Downey. Transaction-Oriented Configuration Management: A Case
Study. Technical Report CMU/SEI-90-TR-23 ESD-90/TR-224, Software Engineering
Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213, November 1990.
[3] Peter H. Feiler. Configuration management models in commercial environments. Technical Report 7 CMU/SEI-91-TR-7 ESD-9-TR-7, Software Engineering Institute, 1991.
[4] Tichy and F. Walter. RCS — A system for version control. Software — Practice and
Experience, 15(7):637–654, July 1989.
[5] Walter F. Tichy. RCS – a system for version control. Software–Practice and Experience,
15(7):637–654, July 1985.
Pascal Molli
79
Équipe ECOO

Une introduction `a la gestion de configurations

Transcription

Documents pareils

CASQUE STEREO SLIDE NOIR

ORGANIGRAMME DE LA DIRECTION DU CASH DE NANTERRE

Les indicateurs de suivi de la qualité

Poste FST / LORIA - Département Informatique

Le Logiciel « Elle

MON CV - Antoine DURET

Tutoriel Webstef : Abal et CVS Résumé Introduction Qu`est

Electric slide (D)

ranking battle.indd - forum 3 Hit Combo

Etape Infos n°45 Février 2013