CVS - indico in2p3

Transcription

CVS - indico in2p3

Tutorial SUBVERSION
FORMATION à l’utilisation de
SUBVERSION
Frédéric MELOT – LPSC / IN2P3 / CNRS (Grenoble)
[email protected]
PLAN

1 Présentation générale - Fonctions et avantages

2 Concepts fondamentaux

3 Description des commandes de base

4 Description des autres commandes courantes

5 Utilisation avancée de svn

Conclusion
2
1 Présentation générale
Fonctions et avantages

1.1 Ce qu’est Subversion

1.2 Pourquoi utiliser Subversion ?

1.3 D’où vient Subversion ?

1.4 Améliorations par rapport à CVS

1.5 Ce cours
3
1.1 Ce qu’est Subversion (ou svn)

Subversion est un système de gestion de versions
Il gère les fichiers et les répertoires, ainsi que leurs
modifications à travers le temps.
Principale utilisation : gérer les modifications de code source
mais également toute sorte d’information : documentation,
images, bases de données, …
Pour Subversion une données est une données quelle soit
binaire (illisible humainement) ou non

Logiciel gratuit et ‘open source’

Fonctionne sous Linux, Windows, Mac OS, …
4

Permet de conserver l’historique d’une hiérarchie de fichiers :

garde une trace de toute les modifications (qui, où, pourquoi)
l’ancien code reste disponible => récupération des versions anciennes de
vos données et retour en arrière possible
on peut examiner l’historique des modifications (ex : consulter les
différences entre révisions de fichiers)
Permet de développer du code de façon collaborative par
plusieurs personnes, équipes, …
car Subversion peut agir à travers le réseau et ainsi permettre son
utilisation à différentes échelles : un service, une laboratoire, une
collaboration nationale ou internationale

les modifications effectuées par une personne sont accessibles à tous
un ou plusieurs développeur peut modifier un même fichier (les
modifications d’un fichier peuvent provenir de plusieurs sources)
5

Peut servir de système de sauvegarde

remplace très avantageusement les ‘zip’ :

classement plus simple
Ne sauvegarde que les différences entre révisions => gain de place
Permet la gestion globale de l’historique de projet et permet l’interrogation

remplace très avantageusement les échanges de versions par mail

Utile aussi bien pour les collaborations que pour les individus

Subversion n’est pas un outil de gestion de configuration !
Ces systèmes sont spécialement conçus pour gérer du code source et
ont donc des fonctionnalités propres au développement d’applications
Ex : CMT (http://www.cmtsite.org/), tag collector, …
6
1.3 D’où vient Subversion ?

Dans le monde du logiciel libre, CVS (Concurrent Versions System) a été la référence pendant
des années

Corriger ses problèmes était très compliqué : conception et modèle de développement à revoir

Début 2000 la société CollabNet (http://www.collab.net) a décidé d’écrire un nouveau
système de gestion de versions :

En ré écrivant tout
En utilisant les idées de base de CVS mais en éliminant ses bugs et en comblant ses lacunes
Assez similaire à CVS pour permettre une transition aisée

Mi 2001 première version

Développé pour être le successeur de CVS, SVN a deux ambitions :

Être un système ‘free’ et ‘open source’ au design similaire à CVS
Éviter la plupart de ses défauts
Maintenant presque tous les nouveaux utilisateurs de logiciels de gestion de Versions
choisissent SVN et non CVS
7
1.4 Améliorations par rapport à
CVS
CVS

Gestion des versions des répertoires
CVS ne gère que l’historique des fichiers individuellement. Subversion implémente un
système de fichier “virtuel” qui permet de détecter tout changement dans la hiérarchie
toute entière de fichiers à travers le temps.
⇒
⇒

Plus aucune modification directe dans le repository
Les répertoires et leur historique sont désormais gérés
Historique ‘total’ des versions
Comme CVS ne gérait que les fichiers indépendamment les uns des autres, des opérations
comme les copies, le renommage ou le déplacement de fichiers n’étaient pas supportées
par CVS. De plus la création d’un nouveau fichier avec le nom d’un fichier ayant déjà existé
ne permet de repartir sur un fichier sans historique. Avec Subversion, vous pouvez ajouter,
détruire, copier, déplacer et renommer à la fois les fichiers et les répertoires. De plus tout
nouveau fichier aura son propre historique, quelque soit son nom.
Les commits sont atomiques
Un ensemble de modifications sera soit entièrement validé dans le repository soit pas du
tout. Dans CVS les commits n’étaient pas atomiques, ce qui pouvait laisser le repository
dans un état non désirable.
Gestion des métadata
Il est possible de définir pour chaque fichier et répertoire un l’ensemble de propriétés
voulues — des clés et leurs valeurs. Les différentes valeurs de ces méta données sont
gérées à travers le temps.
8
1.4 Améliorations par rapport à
CVS
CVS

Choix des couches de communication

Subversion peut s’intégrer à un serveur Web apache, ce qui lui permet de profiter des propriétés
(stabilité, interopérabilité, …) et des couches logicielles d’apache déjà existantes (authentification,
autorisations, compression, … )
Subversion possède également un serveur indépendant. Celui-ci possède son propre protocole et
peut être facilement accessible à travers un tunnel ssh.
Subversion a une notion abstraite d’accès au repository, ce qui permet d’en développer facilement de
nouveaux.
Gestion des fichiers binaires
Subversion exprime les différences de contenu de version les fichiers à l’aide d’un
algorithme spécifique, qui fonctionne de la même façon pour les fichiers texte que pour les
fichiers binaires. Ces deux types de fichiers sont stockés avec la même compression dans le
repository.
Branches et tags revisités (et plus efficaces)
Le coût des opérations de branches et de tag ne sont plus proportionnels à la taille du
projet. Avec Subversion la création de branche et de tag s’effectuent à l’aide d’une simple
copie du projet, ce qui revient à créer sur le repository un lien symbolique.
=> temps de l’opération faible et constant
=> plus de sticky tags !
…
9
1.5 Ce cours

La première interface utilisateur de Subversion est la ligne de
commande, c’est elle qui sera le plus détaillée dans ce cours
(commande svn et quelques programmes auxiliaires)
Les exemples correspondront au cas de Linux mais seront
transposables à quelques exceptions près (\ et non / pour Windows par
exemple)
En raison du lien entre CVS et SVN, il est presque impossibles de traiter
de SVN sans parler de CVS
Ce cours a été écrit pour un public ne connaissant aucun outil de
gestion de versions mais de temps en temps les différences avec CVS
peuvent être évoquer afin de faciliter son utilisation pour les anciens
CVS
utilisateurs de CVS. Un logo
est présent dans les
diapositives traitant de concepts où CVS et SVN différent
Concept similaire pour les autres logiciels de gestion de versions (RCS,
10
clear case, VSS, CVS, …)
PLAN

Conclusion
11

2.1 Architecture (repository, working copy et communication)

2.2 Principe de fonctionnement

2.3 Différents modèles de systèmes de gestion de versions

La solution lock – modify - unlock
La solution copy – modify - merge

2.4 Accès au repository

2.5 Précisions sur la working copy

2.6 Révisions

2.7 Commandes SVN - généralités
12
2.1 Architecture
L’installation de Subversion permet l’utilisation de plusieurs programmes :

svn : le programme client en ligne de commande
svnversion : un programme permettant de connaître l’état d’une
working copy
svnlook : un outil d’interrogation directe du repository
svnadmin : un outil permettant de créer, de paramétrer et de réparer
le repository
svndumpfilter : un programme de filtrage des dumps de repository svn
mod_dav_svn : un plug-in pour le serveur apache, afin de rendre votre
repository disponible sur le réseau
svnserve : un serveur svn, lançable comme un démon ou invocable par
ssh
svnsync : un programme de recopie incrémentale de repository
13
2.1 Architecture

Subversion est un système de gestion de versions de type “centralisé”. Son système central
de données de référence s’appelle le repository
Il contient toute la hiérarchie de fichiers et tout l’historique des modifications
De l’autre côte se trouve votre client subversion qui gère une version locale d’une partie de
ces données, la “working copy”

Tout ou partie de la hiérarchie
Une seule version à un instant donné
Entre les deux, de nombreuses possibilités de communication existent à travers différentes
couches d’accès. Certaines empreinte le réseau et à travers de servers accèdent au
repository alors que d’autre ne se servent pas du réseau et accèdent directement au
repository.
Quand les clients se connectent au repository :

En écrivant, ils rendent leurs modifications disponibles pour les autres
En lisant, ils reçoivent les informations des autres
Ils peuvent aussi récupérer les états anciens du système de fichiers
Ils peuvent questionner le repository (ex : que contenait le repository lundi dernier ? , quels fichiers
ont été modifiés depuis 2 mois ? , qui a effectuer les dernières modifications dans le repository pour
un fichier donné ?, … )
14
2.1 Architecture
Working copy
Commande SVN en ligne
Application graphique
Accès au repository
DAV
SVN
Local
Réseau
RéseauTCP/IP
TCP/IP
apache
svnserve
Repository
Berkeley DB
FSFS
15
Hiérarchie de fichiers avec
tout son historique
Développeur 1
Repository
Version commune du projet
A un instant donné, chaque personne possède
une version et une seule de chaque fichier
Développeur 2
Chacun a sa propre
version sur son poste
(working copy)
16
Exemple d’un cas d’utilisation
Plus de connexion nécessaire
avec le repository !
Modification du
fichier A
Renvoie le projet
Demande le projet Développeur 1
Repository
Développeur 2
17
Valide les modifications
du fichier A
Développeur 1
Repository
Il peut demander une
mise à jour
Et le développeur 2
qui possédait déjà le
fichier A ?
Développeur 2
18
2.3 Différents modèles de
systèmes de gestion de versions

Un système de gestion de versions permet :

L’édition collaborative
Le partage d’information
Tous les systèmes de gestion de versions ont le
problème fondamental : permettre le partage
d’informations sans que personne n’écrase les
données des autres
A ce problème deux solutions :

La solution lock – modify – unlock
La solution copy – modify - merge
19
Les 2 développeurs récupèrent le même projet
=> Ils ont la même hiérarchie de fichiers
Développeur 1
Repository
Développeur 2
20
Modification du
fichier A
=> A’
Développeur 1
Repository
Modification du
fichier A
=> A’’
Fichier A
Développeur 2
Les fichiers A’ et A’’ sont incompatibles
21
du fichier A
Développeur 1
Repository
Fichier A’
Développeur 2
22
Développeur 1
Repository
Fichier A’’
du fichier A
Développeur 2
Si aucun système de vérification n’existe le développeur 2 écrase les
modifications du développeur 1 !
23
2.3 La solution lock – modify –
unlock
Le développeur 1 désire modifier le fichier A
=> Il ne peut pas le modifier directement
1°) Il verrouille l’accès au fichier A
=> Il en obtient la version la plus récente
=> Le développeur 2 ne peut pas verrouiller ce fichier
Développeur 1
Repository
Développeur 2
2°) Il modifie le contenue du fichier A
3°) Il valide ses modifications
4°) Il déverrouille l’accès au fichier A
=> le développeur 2 peut verrouiller ce fichier et ainsi récupérer sa version
la plus récente
24
2.3 La solution lock – modify –
unlock

Solution la plus restrictive : une seule personne à la fois peut
modifier un fichier

Peut être bloquant

On doit attendre, peut être pour rien
Si quelqu’un oublie de déverrouiller …
Donne une fausse sensation de sécurité

Deux personnes peuvent effectuer simultanément des
modifications incompatibles sur des fichiers différents
Rien n’empêche un utilisateur de supprimer les modifications d’un
autre
=> Ce n’est pas le système de gestion de versions qui remplace la
communication
25
2.3 La solution copy – modify merge
Les 2 développeurs récupèrent le même projet
=> Ils ont la même hiérarchie de fichiers
Développeur 1 , A
Repository
Développeur 2, A
26
Modification du
fichier A
=> A’
Développeur 1 , A’
Repository
Modification du
fichier A
=> A’’
Fichier A
Développeur 2, A’’
27
du fichier A
Erreur ‘out of date’
Repository
du fichier A
Fichier A’
Développeur 2, A’’
La version la plus récente du repository a
changé depuis la création de la working copy
du développeur 2
28
Récupère la dernière version
Repository
Fichier A’
=> merge du fichier
fA’ + fA’’ = fA’’’
En fait Δ = A’’ – A
A’’’ = A’ + Δ
Développeur 2, A’’’
2 cas :
Modifications compatibles => merge automatique
Modifications concurrentes => situation de conflit
=> merge manuel
29
Repository
Fichier A’’’
du fichier A
30
Récupère la dernière
version
Développeur 1 , A’’’
Repository
Fichier A’’’
31

Solution proposée par CVS, Subversion, …
Chacun a sa propre working copy et peut y travailler indépendamment
et simultanément. A la fin les versions sont mergées ensemble dans
une version finale (de façon automatique ou manuelle)
Peut sembler chaotique mais fonctionne extrêmement bien :

Pas besoin d’attendre
La plupart des modifications sur un même fichier ne donne pas lieues à un
conflit
De plus résoudre un conflit est souvent plus rapide qu’attendre un
déverrouillage

Les conflits peuvent être évités en améliorant la communication entre
utilisateurs

Mais ne convient pas aux fichiers non ‘mergeable’ => mécanisme de
lock toujours disponible
32
Avec une méthode
de lock
centralisés
Avec une méthode
de merge
Systèmes de gestion de versions
décentralisés
33
CVS
2.4 Accès au repository

SVN utilise des URL pour identifier les fichiers et les répertoires gérés dans le repository

Ex : https://lpsc.in2p3.fr:80/svn/test/web/index.html
Ex : file:///Z:/repository/SVN/test
Ex : svn info ‘https://lpsc.in2p3.fr/tests pour Planck/dev’
Différentes méthodes d’accès au repository :
Préfixe de l’url
Méthode d’accès au repository
file://
Accès direct
http://
Via apache
https://
Via apache avec une encryption ssl
svn://
Via un protocole spécifique vers un svnserve
démon
svn+ssh://
Via un protocole spécifique vers un svnserve
démon à travers un tunnel ssh
C’est votre administrateur SVN qui vous donnera cette URL
34
2.5 Précisions sur la Working
copy

Une working copy est une hiérarchie de fichiers ordinaire dans votre
système de fichiers
Vous pouvez éditer, modifier l’intérieur d’une working copy comme si
elle n’en était pas une, avec n’importe quel outil (vi, nedit, emacs,
word, excel, gimp, …). On peut aussi le compiler, debogguer, tester, …
avec ou sans connexion réseau
Votre working copy est un ‘espace privé’. Vous n’obtiendrez ni les
modifications des autres ni ne soumettrez les vôtres si vous ne le
demandez pas explicitement à l’aide de commandes SVN dédiées à cela
Vous pouvez posséder autant de working copy que vous le désirez
mais attention pas une working copy pour plusieurs utilisateurs !!
35
copy

Une working copy contient également des fichiers
‘supplémentaires’, créés et maintenus par SVN. Ils se trouvent
dans des répertoires .svn, créés dans chaque répertoire de la
hiérarchie.
NE JAMAIS LES MODIFIER !
Ils servent à SVN pour connaître l’état des fichiers, permettre
l’exécution de commande SVN sans avoir à spécifier l’URL du
repository, …
Souvent un repository héberge plusieurs projets. Dans ce cas
une working copy ne correspond souvent qu’à une partie du
repository.
36
copy
Récupération du projet
Développeur 1
Valide ses modifications
Récupération du projet
Récupère la dernière version
Repository
Révision la plus haute
du repository (HEAD) :
17
18
19
Développeur 2
Révision de référence
du développeur 1 :
17
18
Révision de référence
du développeur 2 :
17
19
19
37
copy

Pour chacun des fichiers, Subversion enregistre deux informations
importantes dans les répertoires .svn:

Sur quelle révision est basée votre working copy (version de référence), Vref
L’heure et la date à laquelle votre copie locale a été mise à jour par le
repository Tref
A partir de ces informations ainsi que de la version la plus haute dans le
repository, Vrep et de la date de dernière modification Tmod, SVN peut
trouver 4 états différents pour chacun de vos fichiers :
Observation
Inchangé localement
et à jour
Tref = Tmod et
Changé localement et
à jour
Tref ≠ Tmod et
Inchangé localement
et ‘out of date’
Tref =Tmod et
Changé localement et
‘out of date’
Tref ≠ Tmod et
Que fait une validation de
modification ?
Que fait une mise à jour de
working copy ?
Rien
Rien
Met à jour le repository
Rien
Rien
Met à jour votre working copy
Réclame une mise à jour de
working copy
Met à jour votre working copy
Vref = Vrep
Vref = Vrep
Vref ≠ Vrep
Vref ≠ Vrep
38
CVS
2.6 Révisions

Une validation de modifications (commit) sur le repository
provoque une transaction atomique qui concerne un certain
nombre de fichiers et/ou répertoires (modification, ajout,
suppression, renommage, déplacement, …)

A chaque commit, un nouvel état du repository est créé, nommé
révision

A chaque révision est assigné un numéro entier, incrémenté de
1 vis-à-vis de la révision précédente

Un repository tout juste créé (cad vide) a pour numéro de
révision 0
39
CVS
2.6 Révisions
0
1
2
‘‘
‘‘
‘‘
‘‘‘‘
3
40
CVS
2.6 Révisions

Les numéros de révisions sont globaux

contrairement aux autres systèmes de gestion de versions, les numéros de
révision de SVN s’appliquent à toute la hiérarchie de fichiers et non pas
fichier par fichier

Une révision correspond à un état global de tout le repository, après un
commit

La révision 5 correspond donc à l’état du repository après le 5ème commit

La révision 5 du fichier λ correspond donc à l’état du fichier λ à la révision 5

Le contenu de deux révisions différentes d’un même fichier ne diffère pas
nécessairement
41
CVS
2.6 Révisions

Dans une working copy on a souvent un mixage de numéros de
révisions
A:14
B:14
C:14

A:14
B:14
C:14
A:14
B:15
C:14
A:14
B:15
C:14
A:16
B:15
C:14
A:16
B:16
C:16
Après une mise à jour, tous les fichiers ont le même numéro de
révision de dernière synchronisation
Après une validation de modifications, généralement il y a
différents numéros de révision de dernière synchronisation
Les mises à jour et les validation de modifications sont des
opérations totalement indépendantes
42
2.7 Commandes SVN – généralités

Syntaxe générale : svn commande [options ] [arguments ]

L’ordre où apparaissent les options n’est pas important

La plupart des options ont plusieurs syntaxes (ex : --message ou -m)

Hors d’une working copy il est obligatoire de spécifier l’URL du repository
Dans une working copy, il n’est plus nécessaire de la préciser
Les commandes peuvent agir sur :

L’URL d’un repository,

un fichier,

un ensemble de fichiers,

Un lien symbolique (sauf sous windows)

un répertoire,

ou encore être sans cible
=> le répertoire courant (‘.’) est la cible par défaut
Si une commande agit sur un répertoire, elle agit récursivement sur tous les sous
répertoires et fichiers qu’il contient (sauf quelques exceptions)
43

Pour obtenir de l’aide :

svn help => pour obtenir la liste des commandes
svn help commande => pour connaître les arguments et les options d’une
commande particulière

Les commandes ont souvent des alias (ex : svn checkout = svn co)

Le nom des commandes est à interpréter en se plaçant du côté du
repository (ex : import, export, …)

Quand vous effectuez une opération qui requière une authentification,
subversion utilise un cache pour les sauvegarder. Pour inhiber ce
comportement :

Pour une commande donnée, utiliser l’option --no-auth-cache
De façon permanente, modifier les paramètres store-passwords et store-authcreds de votre fichier de configuration config (situé dans $HOME/.subversion)
44

La plupart des options de commande sont communes à toutes les
commandes

L’option --non-recursive (-N) permet de supprimer le caractère récursif
d’une commande

Vous pouvez spécifier vos paramètres d’authentification en utilisant
dans la ligne de commande : --username xxx --password xxx

Certaines commandes permettent de spécifier une date
=> agit sur les révisions les plus récentes non postérieures à d1
ex :
’2003-12-09 22:00:00’
2003-12-09 équivaut à ’2003-12-09 00:00:00’ et ’2003-12-08
24:00:00
45

Il est souvent nécessaire d’identifier des révisions particulières dans une
commande :

Une particulière : --revision REV ou -r REV
Un intervalle : --revision REV1:REV2 ou -r REV1:REV2
-c REV équivaut à -r REV-1:REV
REV peut être :

Un numéro de révision : --revision 3
Un mot clé :

HEAD, la plus haute révision du repository
BASE, la révision de référence de votre working copy
COMMITTED, la version la plus récente, antérieure ou égale à BASE, dans laquelle un élément
a changé
PREV, COMMITTED – 1
BASE, COMMITTED et PREV sont relatifs à une working copy
Une date : ‘‘{2007-04-23}’’, ‘‘{2005-12-17 15:36}’’
Exemples :

--revision BASE:HEAD
--revision ‘‘{2005-11-03}’’:4010
-r PREV:‘‘{2005-12-17 15:36}’’
46
PLAN

Conclusion
47
3 Description des commandes de
base

3.1 Qui fait quoi ?

3.2 Commande checkout

3.3 Comment SVN effectue ses comparaisons (rappel)

3.4 Commande update

Exemples d’update

3.5 Checkout versus Update

3.6 Commande commit
48
3.1 Qui fait quoi ?
Action
Modification du Modification de
repository
la working copy
Checkout
(co)
Récupérer localement un projet
depuis le repository, pour le
modifier (Working Copy)
NON
OUI
Update
(up)
Mettre à jour localement un
projet à partir du repository
(Synchronisation)
=> Récupérer les modifications
des autres
NON
OUI
Commit
(ci)
Valider des modifications
locales dans le repository
=> Rend disponible les
modifications pour les autres
OUI
NON
49
Repository

Working copy
Afin d’utiliser un repository la plupart du temps, on récupère un projet
déjà existant :
svn co https://lpsc.in2p3.fr/svn/projetA
=> création d’une working copy à partir de la version la plus récente du projet

Cela produit un répertoire projetA, la working copy, à l’intérieur de
laquelle les commandes SVN vont fonctionner
Ce répertoire est alors entièrement modifiable, avec n’importe quel
éditeur ou outil (vi, nedit, emacs, word, excel, gimp, …). On peut aussi
le compiler, tester, … avec ou sans connexion réseau. On peut même
le supprimer !
50
Repository
Working copy

Cette commande peut agir sur n’importe quel répertoire du repository

On peut renommer le répertoire obtenu :
svn co https://lpsc.in2p3.fr/svn/projetA/trunk projetA

Pour obtenir une working copy de la révision 1017 du projet projetA :
svn co –r 1017 https://lpsc.in2p3.fr/svn/projetA projetA-1017

Checkout est exécuté rarement : une seule fois pour chaque projet
=> pour se mettre à jour (récupérer les modifications des autres utilisateurs),
il faut utiliser la commande update
51
3.3 Comment SVN effectue
ses comparaisons (rappel)

3 origines de comparaisons pour chaque fichier :

CVS
La version courante dans la working copy
La révision de dernière synchronisation avec le repository
(checkout ou update) – ou révision ou référence
La révision la plus récente du repository (la HEAD révision)
SVN calcule deux types de changement :

entre le second et le troisième, il trouve les changements
dans le repository => ceux des autres utilisateurs
entre le premier et le second, il trouve vos changements
en local
52
3.4 Commande update
Repository

Working copy
Pour mettre à jour votre working copy avec la version la plus récente du repository :
svn up
=> Se synchroniser avec la version du repository
=> Pour obtenir les modifications apportées par les autres
=> On ne spécifie plus l’url du repository

Car SVN ne va vous laisser modifier que la HEAD révision d’un fichier et non pas une
version ancienne
=> obligatoire avant de valider vos modifications dans le repository
Il s’agit d’un merge (combinaison) des modifications des autres avec votre
version courante (changements dans le repository et changements en local)
=> possible automatiquement ou non
53
3.4 Commande update
Repository

Working copy
Quand le serveur effectue des mises à jour dans votre working copy, il vous
l’indique à l’aide de la convention suivante :

U toto : le fichier toto a été mis à jour sans merge (Update)
A toto : le fichier ou le répertoire toto a été ajouté à votre working copy (Added)
D toto : le fichier ou le répertoire toto a été supprimé de votre working copy (Deleted)
G toto : le fichier toto a été mis à jour avec un merge (merGed)
C toto : le fichier toto n’a pas pu être mis à jour à cause d’un conflit (Conflict)
…

Les ‘nouveaux’ dossiers dans le repository sont automatiquement récupérés

Mettre à jour avec la révision 1017 :
svn up –r 1017
ne pas oublier qu’il s’agit d’un merge !
54
3.4 Exemple d’update (1)
svn update
svn ci
8
Etat actuel dans la
working copy
7
?
…
Etat actuel dans la
working copy
8
7
6
6
5
5
Au départ
svn ci
La commande
Aprés
55
svn ci
Etat actuel dans la
working copy
Etat actuel dans la
working copy
Etat actuel dans la
working copy
svn update
svn ci
?
modifications
modifications
7
7
6
6
5
5
56
8
svn ci
Etat actuel dans la
working copy
Etat actuel dans la
working copy
svn ci
Etat actuel dans la
working copy
svn update
?
modifications
8
modifications
7
7
6
6
5
5
57
Etat actuel dans la
working copy
svn update –r 5
?
modifications
8
7
Etat actuel dans la
working copy
6
5
svn ci
modifications
5
58
3.5 Checkout versus Update

Pour mettre à jour une working copy, toujours utiliser svn up
et non svn co

La commande n’utilise pas de répertoire .svn, on doit donc spécifier
l’url du repository => fastidieux

Si une working copy existe déjà cela est équivalent à svn up en
plus compliqué

Sinon

On ne peut pas facilement mettre à jour un seul répertoire
Que se passe t-il si l’url est différente de celle spécifiée dans les
répertoires .svn ?
Perte des modifications locales
Temps beaucoup plus long pour récupérer tous les fichiers
On ne peut pas mettre à jour un seul fichier
(svn co ne prend en argument que des répertoires)
59
3.6 Commande commit
Repository

Working copy
Vous mettre à jour :
svn update
obligatoire si d’autres personnes ont modifié le code

Valider vos modifications locale :
svn commit => ouvrira votre éditeur préféré
ou svn commit --message ’’message’’ pour un message court
ou svn commit --file logmessage sinon
=> Envoie vos modifications au repository, quel que soit leur signification
=> Renvoie un message ‘out of date’ si vous n’êtes pas à jour
=> Cela rend vos modifications disponible pour les autres
=> Le message doit décrire vos modifications
60
3.6 Commande commit
Repository

Working copy
Règle importante : aucun changement en local n’est jamais effectué
dans le repository avant un commit

Commit n’entraîne pas update
Et update n’entraîne pas commit

Remarque : possibilité d’envoi automatique de mail lors des commit

Fréquence des ‘svn ci’ : très dépendant du projet

Fichiers binaires ou non
Langage compilé ou interprété
Nombre de personnes impliquées
…
61
PLAN

Conclusion
62
4 Description des autres
commandes courantes

4.1 Commande import

4.2 Modifications de la working copy –commandes add, delete, copy,
move et mkdir

4.3 Examiner vos modifications - commandes status et diff

4.4 Commande revert

4.5 Résoudre les conflits - commande resolved

4.6 Connaître l’historique du repository - commandes log, diff, list et cat

4.7 Commandes export et cleanup

4.8 Test d’une connexion à un repository svn

4.9 Récapitulatif
63
4.1 Commande import

Copier une hiérarchie de fichiers non gérés par svn dans un repository
(ne nécessite pas de working copy) :
svn import –m ’mes’ projet https://lpsc.in2p3.fr/svn/web
=> pas de commit nécessaire (car agit sur une URL)
=> Ne transforme pas le répertoire d’origine en working copy !
=> pour travailler, effectuer ensuite un svn checkout :
svn co https://lpsc.in2p3.fr/svn/web/projet new
Puis rm –rf projet

Il est recommandé de prévoir dès ce stade une organisation :

URL_repository/trunk
URL_repository/tags
URL_repository/branches
64
4.2 Modifications de la working
CVS
copy

2 types :

Modification du contenu de fichiers déjà gérés par svn :
édition / commit

Modification de la hiérarchie de fichiers :

addition,
suppression,
copie
ou déplacement de fichiers et/ou de répertoires
Pour modifier la hiérarchie de fichiers, toujours utiliser des
commandes svn et non des commandes systèmes !
65
CVS
copy

Modification de la hiérarchie de fichiers
=> dans ce cas vous devez lancer une
commande :

Soit dans une working copy

elle va effectuer l’action dans la working copy
et la planifier dans vos fichiers d’administration svn (dans les
répertoires .svn) afin de l’effectuer dans le repository au
prochain commit
Soit directement dans le repository (sauf pour le svn add)

Elle va effectuer les modifications directement sans commit
Les modifications seront récupérables depuis une working
copy à l’aide d’un svn update
66
copy

svn add toto
=> Planifie l’ajout de fichier, répertoire ou lien symbolique dans le
repository
=> Si toto est un répertoire, l’ajout va concerner toute la potentielle
hiérarchie sous lui
svn delete toto (del, remove, rm)
=> Planifie la suppression de fichier, répertoire ou lien symbolique
dans le repository
=> Si toto n’est pas un répertoire la suppression est immédiate dans la
working copy et est effectuée dans le repository lors d’un commit
=> Si toto est un répertoire, sa suppression n’est pas immédiate dans
la working copy et a lieue en même temps dans celle-ci et dans le
repository lors d’un commit
=> Bien sûr toto n’est supprimé que de la HEAD révision et reste
disponible dans l’historique
67
CVS
copy

svn copy toto tata (cp)
=> Crée un nouveau fichier ou répertoire tata identique à toto dans la
working copy et planifie cette copy dans le repository
=> Lors de son ajout dans le repository, au commit suivant, son
origine est sauvegardée dans son historique (il provient d’une copie de
toto)
Cette commande, très utilisée, est très peu coûteuse en temps et en
espace disque (équivalent d’un lien symbolique)
tata
toto

svn move toto tata (mv, rename, ren)
=> Équivalent à svn copy toto tata puis svn del toto
svn mkdir toto
=> Équivalent à mkdir toto puis svn add toto
68
CVS
copy

Ajout d’un fichier préalablement supprimé:
Svn rm toto
Svn ci
Vi toto
Svn add toto
Svn ci
=> Bien qu’ayant le même nom il ne s’agira pas du
même fichier pour svn (et donc pas le même
historique)

69
CVS
copy
Working Copy 1
cd resa
svn mv doc document
svn ci
cd img
svn up
svn: REPORT request failed on ‘/svn….’
svn: Target path does not exist
Working Copy 2
cd resa
svn up
D doc
A document
A document/specs.doc
svn mv img image
svn ci
svn switch https://xxxxx/resa/image
Attention aux svn mv de répertoire en haut d’une hiérarchie !
70
CVS
4.3 Examiner vos modifications

Avant d’effectuer un svn commit, vous pouvez vouloir vérifier vos
modifications
Pour voir ce qui a été modifié : svn status

Pour voir les modifications en détail : svn diff
=> Permet de voir par exemple qu’un fichier a été modifié par inadvertance
=> Permet d’affiner le message de log

Ces opérations sont possibles sans connexion au repository si elles ne
concernent que vos modifications en local

Car svn conserve une version cachée de votre révision de référence
=> cela lui permet également lors d’un commit de n’envoyer que les
modifications et non tous les contenus
Svn diff peut également agir sur tout l’historique du repository et svn
status vérifier l’état de votre working copy vis-à-vis de celui du
repository
71
CVS
4.3 Commande status

Après svn checkout, svn update et svn commit, la commande la plus
utile !

Pour avoir un aperçu des modifications des fichiers ou de l’arborescence
de fichiers que vous avez effectuer :
svn status

Pour obtenir une information sur tous les fichiers et répertoires :
svn status --verbose ou svn status -v

N’affiche que les objets modifiés
Ne contacte pas le serveur
Affiche tous les fichiers avec plus d’information
Ne contacte pas le serveur
Pour ajouter une information ‘out-of-date’
svn status --show-updates ou svn status -u

Contacte le serveur
72
4.3 Commande status

Le résultat est affiché sur 6 colonnes :

1 : L’état du contenu du fichier ou du répertoire

2
3
4
5
6
:
:
:
:
:
‘ ’ pas de modification
‘A’ ajouté (ex : svn add ou svn cp)
‘C’ conflit
‘D’ suppression (ex : svn mv ou svn del)
‘I’ ignoré
‘M’ modifié
‘R’ remplacé (svn del puis svn add)
‘?’ non géré
…
L’état des propriétés du fichier ou du répertoire (‘ ’, ‘C’ ou ‘M’)
Si le répertoire de la working copy est verrouillé ou non (‘ ’ ou ‘L’)
Si le prochain commit contiendra l’historique ou non (‘ ’ ou ‘+’)
relatif à la commande switch
relatif aux verrous du repository
73
4.3 Commande status

Avec svn st -v, on obtient également le numéro de la révision de référence de la
working copy, le numéro de révision du dernier commit puis son auteur

Avec svn st –u, on obtient également l’information out-of-date (‘ ’ ou ‘*’) puis le
numéro de la révision de la working copy

Ex :

Svn st
A + toto (ne provient pas d’un svn add, mais plutôt d’un svn cp ou svn mv)
M
tata

Svn st –v
A +
M
17 5 Paul toto
17 12 Alex tata
17 5 André tutu
Status against revision: 23

Svn st –u
A +
17 toto
M
* 17 tata (un svn update est nécessaire avant un svn commit)
Status against revision: 23
74
4.3 Commande diff

Voir en détail ce que vous avez modifié :
svn diff
=> affiche à l’écran les différences dans le format diff unifié
=> cela compare la version courante à la version de référence
=> ne nécessite pas d’accès au réseau (si pas d’option)

Pour faire un fichier de patch :
svn diff > patch

Svn utilise son propre utilitaire de recherche de différence,
l’option --cmd-diff permet d’en utiliser un autre
Ex : svn diff --cmd-diff /usr/bin/diff –x ‘-i’ src
75
4.3 Commande diff

Exemple de réponse :
Index: src/test.c
===================================================
--- src/test.c (revision 12)
+++ src/test.c (working copy)
@@ -1 +1 @@
- If (var == 27){
+If (var == 15){
Index: src/proto.h
===================================================
--src/proto.h (revision 3)
+++ src/proto.h (working copy)
@@ -193,3 +193,4 @@
+ # Please do not remove these definitions
76
CVS
4.4 Commande revert
(perdre les modifications en local)
Etat actuel dans la
working copy
modifications
?
8
Svn update commun.php ?
7
Non
=> Svn revert commun.php
6
5
commun.php
77
CVS
4.4 Commande revert

Pour annuler vos modifications en local :
svn revert xxx
=> ne contacte pas le repository, donc pas d’accès réseau
=> permet d’annuler toute commande planifiée
ex :
svn add toto ou svn del toto
svn revert toto
=> la cible doit être spécifié et n’est pas récursif par défaut (sinon
utiliser --recursive ou -R)
=> svn revert XXX est équivalent à rm XXX puis svn up -r BASE XXX
mais sans contacter le repository
différent de rm XXX puis svn up !
78
4.5 Résoudre les conflits

Rappel (modèle copy – modify - merge) :
svn up

Modifications sur le serveur
U globus.h
Non
Oui
G globus.c
Oui
Oui
C server.c
Oui
Oui
Les conflits, dus à des modifications sur une même portion de
code, sont rares :

Modifications locales
Une seule personne travaille sur un morceau particulier de code
Les personnes travaillant sur la même fonctionnalité devraient se parler
SVN gère les révisions de hiérarchie de fichiers, il ne remplace
ni la gestion de projet ni la communication
79
CVS

Quand un conflit survient, SVN ne peut pas savoir quoi faire tout seul.

C’est à vous de le résoudre manuellement. Pour vous y aider :

Il affiche un ‘C’ durant l’update, et se souvient de cet état

Si le fichier n’est pas de type binaire :

il délimite les zones conflictuelles à l’aide de marqueurs de conflits dans le fichier
d’origine
il créé 3 nouveaux fichiers non gérés par svn dans votre working copy :

Fichier.mine, votre fichier avant l’update (n’est pas créé pour les fichiers binaires)
Fichier.rOLD_REV, la révision de référence de votre fichier
Fichier.rNEW_REV, la HEAD révision au moment de l’update
=> test.c, test.c.mine, test.c.r17, test.c.r19

Si le fichier est de type binaire :

il conserve votre fichier d’origine
il créé 2 nouveaux fichiers non gérés par svn dans votre working copy :

Fichier.rOLD_REV, la révision de référence de votre fichier
Fichier.rNEW_REV, la HEAD révision au moment de l’update
=> test.c, test.c.r17, test.c.r19
80
CVS

Ex : svn update
C
ls -l
server.c
server.c
=> avec des marqueurs de conflit
server.c.mine
server.c.r17
server.c.r23

A partir de là, SVN ne vous laissera plus faire de commit avant d’avoir
débloquer cette situation

3 solutions :

Résoudre le conflit à la main, à l’aide des marqueurs de conflit
Utiliser un des fichiers de référence
Utiliser svn revert
Puis dire à svn que l’on a résolu le conflit : svn resolved filename
=> Cela va effacer les fichiers temporaires et enlever l’état de conflit

Puis svn ci
81
CVS

Première solution : Résoudre le conflit à la main, à l’aide des
marqueurs de conflits
<<<<<<<<<<<<<<<<< .mine
One content
=================
Other content
>>>>>>>>>>>>>>>>> .r23
Marqueurs de conflits

L’utilisateur doit éditer ce fichier en sélectionnant une des deux versions, en
les combinant ou encore en changeant complètement le texte

Surtout en discuter avec l’auteur de la modification conflictuelle !

Puis

svn resolved xxx
svn ci -m ’message’ xxx
82
CVS

Deuxième solution : Utiliser un des fichiers de référence
svn update
C
ls
server.c
server.c server.c.mine server.c.r17 server.c.r23
cp server.c.mine server.c => perd les modifications de l’autre
cp server.c.r17 server.c => perd vos modifications et celles de l’autre
cp server.c.r23 server.c => perd vos modifications
si vous le désirez vous pouvez également modifier ces fichiers
svn resolved server.c
svn commit -m ’message’ server.c

Troisième solution : Utiliser svn revert => perd vos modifications

Revient à faire cp server.c.r23 server.c
mais svn resolved n’est pas nécessaire
83
4.6 Connaître l’historique du
repository

Le repository conserve toutes les modifications
validées par chaque commit
Il vous permet de ‘remonter le temps’ et d’examiner
toutes les révisions :

En récupérant une révision donnée (svn co -r REV ou svn
update -r REV)
En questionnant l’historique du repository :

svn
svn
svn
svn
log => affiche tous les messages des log
diff => affiche le détail des modifications
cat => affiche le contenu d’un fichier pour une révision
list => liste le contenu d’un répertoire pour une révision
84
repository – commande svn log

Pour obtenir des informations sur l’historique d’un fichier ou
d’un répertoire :
svn log
=> affiche la liste des informations relatives à chaque commit
pour l’entité voulue :

Le numéro de révision
L’auteur du commit
La date
Le message de log
=> Les informations proviennent uniquement du repository

svn log == svn log -r BASE:1
85

Ex :
svn log
-------------------------------------------------------------------------------------r1197 | paul | 2006-10-13 12:45:52 +0200 (Fri, 13 Oct 2006) | 1 line
Harmonisation des commentaires
-------------------------------------------------------------------------------------r1190 | jean | 2006-10-12 17:51:05 +0200 (Thu, 12 Oct 2006) | 1 line
Modification du format de date pour les années : 06 -> 2006
--------------------------------------------------------------------------------------
…

svn log --revision 1017:1212
svn log generateur.cpp -r 1212:1017
svn log https://lpsc.in2p3.fr/svn/Web/resa/trunk -r 17
svn log –r 17 => n’affichera rien si dans le répertoire courant aucune
modification n’a affecté la révision 17 du repository
86

Afin de connaître la liste des fichiers modifiés :
svn log -r 816 -v
-------------------------------------------------------------------------------------r816 | melot | 2005-08-22 16:51:25 +0200 (Mon, 22 Aug 2005) | 1 line
Changed paths:
M /trunk/commun/commun.php
M /trunk/reservation.php
A /trunk/config/commun/interface.php
*** empty log message ***
--------------------------------------------------------------------------------------

Importance du message de log lors de chaque commit !
Il doit être utile
Ex : svn –m ’ajout de valeurs par défaut pour toutes les
variables’ commit
87
repository – commande svn diff

3 usages :

Connaître vos modifications en local (pas d’accès au réseau) :

Comparer votre working copy au repository (un numéro de révision
en argument) :

svn diff
=> Entre la révision courante et celle de référence
svn diff –r BASE
=> Entre la révision courante et celle de référence
svn diff –r HEAD
=> Entre la révision courante et la HEAD révision
svn diff –r 1017
=> Entre la révision courante et la révision 1017
Comparer deux versions du repository (deux numéros de révision
en argument) :

svn diff –r BASE:HEAD
=> Entre la révision de référence et la HEAD révision
svn diff https://lpsc.in2p3.fr/svn/projetA/src -r 1012:HEAD
88
repository – commandes cat et list
CVS

Pour afficher le contenu d’un fichier pour une révision donnée :
svn cat -r 12 compare.php
svn cat https://lpsc.in2p3.fr/svn/new.txt
=> les affiche à l’écran

Pour lister le contenu d’un répertoire pour une révision donnée (sans
les télécharger) :
svn list https://lpsc.in2p3.fr/svn/Web/resa
branches/
tags/
trunk/
svn list -v https://lpsc.in2p3.fr/svn/Web/resa
346
206
278
113
andre
paul
alain
paul
1339
Nov 19
Jun 22
Sep 03
Jan 17
19:55 README
17:20 branches/
10:25 tags/
15:04 trunk/
89
4.7 Commandes export et
cleanup

CVS
Pour obtenir une copie de la hiérarchie de fichiers :
svn export https://lpsc.in2p3.fr/svn/Web/resa/trunk reservation
pas de création de working copy !

Exporte la HEAD révision par défaut sinon -r REV
=> pour mettre en production ou diffuser un logiciel

Quand svn modifie votre working copy :

Il commence par noter son intention dans un fichier de log (dans .svn)
Il exécute la commande
Il détruit le fichier de log

Si l’opération est suspendue (process tué, arrêt du PC, …) la commande n’est
pas exécutée mais le fichier le log reste

Pour finir toute opération inachevée :
svn cleanup
=> votre working copy retourne dans un état cohérent
=> supprime les éventuels lock des working copy
=> mais ne fonctionne pas toujours !!! => attention à Ctrl-C sur svn ci !
90
4.8 Test d’une connexion à un
repository svn

Installer la dernière version de svn et mettre l’exécutable dans le PATH

Demander à votre administrateur svn l’url du repository

Vous authentifier avec la méthode adéquate (mises au point préalables
souvent nécessaires)
Essayer une commande d’interrogation non liée à une working copy
ex :
svn list https://xxx
svn info https://xxx
Installer une interface graphique
91
4.9 Récapitulatif
Commande
Nécessite une
Working copy
Peut prendre une URL comme
argument (=> pas de commit)
Modifie le
repository
Peut être lancé sans
connexion au
repository
Checkout
Non
Toujours
Non
Non
Update
Oui
Non
Non
Non
Commit
Oui
Non
Oui
Non
Import
Non
Toujours
Oui
Non
Add
Oui
Non
Non
Oui
Delete
Non
Oui
Oui ou non
Oui
Mkdir
Non
Oui
Oui ou non
Oui
Copy
Non
Oui
Oui ou non
Oui
Move
Non
Oui
Oui ou non
Oui
92
4.9 Récapitulatif
Commande
Nécessite une
Working copy
Peut prendre une URL comme
argument (=> pas de commit)
Modifie le
repository
Peut être lancé sans
connexion au
repository
Status
Oui
Non
Non
Oui
Diff
Non
Oui
Non
Oui
Revert
Oui
Non
Non
Oui
Resolved
Oui
Non
Non
Oui
Log
Non
Oui
Non
Non
List
Non
Oui
Non
Oui
Cat
Non
Oui
Non
Oui
Export
Non
Toujours
Non
Non
Cleanup
Oui
Non
Non
Oui
93
PLAN

Conclusion
94
CVS

5.1 Gestion des méta données

Utilisation
Utilisation
Utilisation
Utilisation
des
des
des
des
méta
méta
méta
méta

5.2
5.3
5.4
5.5
5.6

5.7 Branches et tags

données
données
données
données
:
:
:
:
portabilité de fichiers
fichiers non gérés par svn
mots clés de substitution
définitions externes
Mécanismes de verrouillage
Identification absolue de révision
Svn et les authentifications
Configuration du client svn
Localisation
Branches
Branches
Branches
Branches
Tags
Branches
–
–
–
–
définition et utilité
création
svn merge
svn switch
– cas usuels
95

En plus de la gestion de versions des fichiers et des répertoires, svn
gère :

Une propriété est un couple (nom de propriété , valeur de propriété)
Ex : (‘copyright’, ‘Paul et André’),
(‘tests unitaires effectués’,’partiellement’), …
Un nom de la propriété doit :

les méta données (ou propriétés) sur ces fichiers et répertoires
leur gestion de versions
Être de type non binaire
Commencer par une lettre, ‘:’ ou ‘_’
Ne pas commencer par ‘svn:’
Une valeur de propriété est totalement libre. Elle peut même être
binaire.
96

svn utilise également de façon interne des méta données :

Elles ont les mêmes caractéristiques que les vôtres sauf :

Pour sauvegarder des caractéristiques de fichiers ou de répertoires
ex : svn:executable, svn:mime-type, svn:ignore, svn:needs-lock, svn:eolstyle, svn:keywords, …
Pour conserver les caractéristiques des commit, des méta données
associées à chaque révision
ex : svn:author, svn:date, svn:log, …
Leur nom commence par ‘svn:’
Aucune gestion de versions ne leur est associée dans le cas des méta
données de révision
=> toute modification entraîne la perte de la valeur précédente
=> à modifier avec prudence
Vous pouvez également modifier ces méta données, si vous savez ce
que vous faites !
97
Classification :
Méta données Méta données gérées par svn
utilisateur
Versionnées
Non versionnées
(méta données de révision)
Exemple : copyright
svn:executable svn:log
98

Pour ajouter une nouvelle méta donnée :
svn propset svn:executable ‘*‘ functions/spacecraft.exe
svn propset copyright –F /usr/local/file_copyright.txt pg.c
=> pour les valeurs sur plusieurs lignes ou pour les fichiers binaires

Pour ajouter ou modifier une méta donnée :
svn propedit copyright functions/spacecraft.c
=> ouvre votre éditeur par défaut avec un contenu nul en cas d’ajout ou avec
l’ancienne valeur en cas de modification

Toutes les commandes de manipulation de méta données ne
sont pas récursives par défaut, utiliser l’option ‘-R’ pour qu’elles
le soient
Ces commandes agissent dans la working copy, les valider à
l’aide d’un svn commit => création d’une nouvelle révision
99

Les commandes propset et propedit permettent également la
manipulation des méta données non versionnées de révision,
elles agissent alors directement dans le repository :

svn propset svn:log --revprop -r HEAD ‘passage à la norme XHTML 1.1’
svn propedit svn:log --revprop -r 1017
=> cela est possible ou non en fonction de la configuration du repository
(impossible par défaut)
=> pas de svn commit nécessaire et perte de l’historique !

Pour obtenir la liste des méta données d’un élément :

svn proplist -R functions/*
svn proplist -v => pour obtenir également les valeurs
svn proplist --revprop -r HEAD => pour obtenir les propriétés de révision
Pour obtenir la valeur d’une méta donnée :

svn propget copyright
svn propget -R svn:mime-type
svn propget --revprop -r 1032 svn:author https://...
100

Pour supprimer une méta donnée :
svn propdel copyright functions/calc.h
=> car svn propset copyright ‘’ functions/calc.h ne supprime pas la
méta donnée

Préférer utiliser propedit plutôt que propset, afin de toujours partir de
la valeur précédente

Les modifications de méta données sont gérées de la même façon que
celle des fichiers et des répertoires :

Merge lors d’update
Conflits possibles
svn status les notifie
svn revert permet d’annuler vos modifications en local
…
Remarque : il n’existe pas de méthode particulière pour rechercher une
valeur particulière de méta donnée
101
5.1 Utilisation des méta données :

Portabilité des fichiers

La séquence de caractères permettant de repérer les fins de lignes
est différente sous Windows (CRLF) et sous Linux (LF)
Linux utilise les liens symboliques, pas Windows
L’exécutabilité d’un fichier est défini par un bit dans le système de
fichiers sous linux, par une extension de nom de fichier différente
sous Windows
…
Svn gère ces différences et donc la portabilité des fichiers à l’aide
des méta données :

svn:executable (existe ou non)
svn:mime-type (rien, ‘application/octet-stream’ ou mime-type plus
précis : ‘image/png’, ‘application/x-shockwave-flash’, ‘text/plain’, … )
svn:eol-style (‘native’, ‘CRLF’ ou ‘LF’)
svn:special (renseigné pour repérer les liens symboliques, rien sinon)
102

C’est lors de l’utilisation de svn add et svn import que svn ajoute ses
méta données de fichiers :
svn:executable est positionné si le fichier a le bit d’exécution activé
(pas géré avec Windows)
svn:mime-type est positionné par svn à ‘application/octet-stream’ si
son algorithme lui indique un fichier non texte
Ces méta données sont très importantes car elles conditionnent de
nombreux comportements de svn (diff textuel, merge, …)
=> d’où l’intérêt de la validité de leur valeur
Afin d’améliorer le comportement par défaut (corriger les erreurs,
suivre les évolutions ou être plus précis) :
On peut définir ses propres préférences dans son fichier de
configuration (~/.subversion/config)
On peut éditer les méta données à la main
103
fichiers non gérés pas svn

Dans une working copy, tous les fichiers ne doivent pas être gérés par svn :

svn add et svn import sont récursifs par défaut => risque de les importer par
erreur
Ces fichiers vont être listé à chaque svn status
=> on peut demander à svn de les ignorer définitivement
Pour cela :

Fichiers intermédiaires de compilation
Fichiers dépendant de l’environnement de l’utilisateur (utiliser des templates)
Backups des éditeurs
…
Utilisation de l’option global-ignores de votre fichier de configuration
(~/.subversion/config)
=> affecte les opérations d’un utilisateur d’un ordinateur (backup d’éditeur, …)
Utilisation de la méta donnée svn:ignore
=> affecte des éléments d’un repository (fichiers de compilation, …)
Si les deux sont renseignés, leur concaténation est utilisée
Ex : ‘*.o *.exe *~’
104

Svn permet de substituer des mots clés à l’intérieur du contenu de
fichiers

Le plupart de ces mots clés décrit des caractéristique de la HEAD révision

Ex : si vous désirez obtenir en haut de chaque fichier la date de sa
révision, vous pouvez demander à tous les utilisateurs de la saisir
manuellement mais c’est une mauvaise solution :

Le format risque de fluctuer
Les oublis sont inévitables
=> mieux vaut demander à svn de le faire !

Méthode : placer $keyword$ dans un fichier, là où vous voulez effectuer
cette substitution et activer la substitution à l’aide de la méta donnée
correspondante
=> A chaque nouvelle révision, il sera remplacé par $keyword: valeur $
105

Différents mots clés possibles :

Précautions :

$Date$ => $Date: 2006-07-22 21:42:37 -0700 (Sat, 22 Jul 2006) $
$Revision$ => $Revision: 165 $ (révision de dernier changement)
$Author$ => $Author: melot $
$URL$ => $URL: https://lpsc.in2p3.fr/svn/Web/reservation.java $
$Id$ => $Id: index.php 15 2004-10-18 15:48 melot $
Bien respecter la casse
Placer ces mots clés dans des zones ne gênant pas la compilation ou
l’interprétation des fichiers (en zone commentée par exemple)
Ne fonctionne pas avec les fichiers binaires
Pour dire à svn de substituer un mot clé pour certains éléments :

svn propset svn:keywords ‘Date Revision’ functions/*
106

Dans un projet vous pouvez avoir besoin d’inclure une
bibliothèque provenant d’un autre repository

Pour cela vous pouvez utiliser différents checkout dans une
même working copy mais tout le monde devra en faire autant

Les définitions externes permettent d’inclure des liens vers
d’autres projets dans le repository et donc pour tout le monde

Ex :
svn co https://lpsc.in2p3.fr/svn/planck/spacecraft
cd spacecraft/communication
svn co https://svn-lal.in2p3.fr/planck-hfi/cm
svn co https://planck.in2p3.fr/com/rooter
107

Méthode :

Utiliser la méta donnée svn:externals
Cela va effectuer le lien entre le répertoire local et l’url d’une révision d’un
projet géré par svn
Ex :
svn co https://lpsc.in2p3.fr/svn/planck/spacecraft
cd spacecraft
svn propedit svn:externals communication
cm https://svn-lal.in2p3.fr/planck-hfi/cm
appli/rooter -r23 https://planck.in2p3.fr/com/rooter
=>
spacecraft / …
/ communication / cm …
/ appli / rooter / …
/ …
108

Une fois qu’un utilisateur a définit des définitions externes, tous les autres
utilisateurs vont récupérer les arborescences de fichiers des repository spécifiés,
lors de checkout ou d’update

Définir la méta donnée svn:externals toujours avec propedit et non propset car
elle est sur plusieurs lignes

Le nom d’une définition externe ne doit pas exister dans le repository d’origine

Il est recommandé d’utiliser des numéros de révision lors de la définition de ces
liens externes car

On ne maîtrise pas l’évolution des repository distants et svn update agira sur toute la
hiérarchie
=> il mettra à jour les définitions externes avec la HEAD révision
un svn update -r REV agira sur toute la hiérarchie et dans les repository externes ce
numéro de révision n’est pas pertinent
Mais attention les working copy créées sont déconnectées de la working copy
d’origine
=> un svn commit en haut de la hiérarchie ne sera pas récursif dans les
109
5.2 Mécanismes de verrouillage
photo.jpg
svn co
svn ci
Développeur 1
svn co svn up
Repository
svn ci
Développeur 2
Out-of-date !
=> photo.jpg, photo.jpg.r26, photo.jpg.r27
=> Un des deux développeurs a perdu son temps
110

Mécanisme de verrouillage pour :

Sérialiser dans le temps l’accès en écriture à certains fichiers

Aider la communication

En prévenant que certains fichiers sont verrouillés
Permet d’éviter d’effectuer des modifications qui ne pourront pas être
validées
Opérations possibles :

Permet de réclamer le droit exclusif de les modifier
Le commit sera possible et le temps de modification jamais perdu
Verrouiller/ déverrouiller
Voir quels fichiers sont verrouiller
Spécifier pour quels fichiers le mécanisme de verrouillage est
recommandé
Remarque : verrou d’exclusion sur le serveur ≠ verrou de
working copy (empêcher des accès concurrents sur 1 wc)
111

Pour créer un verrou :
svn lock photo.jpg –m ’changement de la couleur de fond’
=> que si le fichier est à jour dans la working copy

svn status affichera un ‘K’ (locKed) en sixième colonne pour l’auteur du
verrou, un ‘O’ (Other) pour les autres s’ils ont utilisé l’option -u

Le verrou est protégé par un jeton, qui est contenu dans la working
copy

L’auteur du verrou et lui seul, depuis sa working copy, peut effectuer
un svn commit, qui va supprimer le verrou ou s’il veut supprimer le
verrou :
svn unlock photo.jpg
112

Pour avoir des informations sur un fichier en particulier :
…
Lock
Lock
Lock
Lock
svn info https://lpsc.in2p3.fr/svn/Web/README
Token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Owner: Henry
Created: 2004-02-17 19:56:43
Comment: j’en ai pour 5 minutes

L’administrateur peut supprimer les locks (svnadmin lslocks et svnadmin
rmlocks) mais également tous les utilisateurs !

Pour supprimer le verrou d’un autre :
svn unlock --force photo.jpg

Pour ‘voler’ le verrou d’un autre :
svn lock --force photo.jpg

Supprimer ou voler un verrou peut être ponctuellement utile mais si cela arrive
trop souvent il y a un souci de communication
113

Celui qui s’est fait supprimer son verrou verra après un svn status -u
un ‘B’ (Broken) ou un ‘T’ (sTolen)

Une politique de verrou plus stricte peut être appliquée par
l’administrateur (à l’aide des hooks pre-lock et pre-unlock)

Le mécanisme de verrou seul ne résout pas le problème initial de perte
de temps
Si un utilisateur ne lance pas la commande svn st –u avant d’effectuer
des modifications …
La solution consiste à proposer un mécanisme rappelant aux
utilisateurs que pour certains fichiers ils doivent effectuer un
verrouillage / déverrouillage :

Positionnement de la méta donnée : svn:needs-lock
Attachée à un fichier, subversion va changer ses permissions dans le
système de fichiers afin de le rendre accessible en lecture seul
La commande svn lock changera cet état dans la working copy
114
5.3 Identification absolue de
révision

svn rm test.h
svn commit
…
svn add test.h
svn commit

=> les deux fichiers test.h sont différents pour svn ! Ils ne
partagent pas le même historique

=> comment faire pour accéder à l’un ou à l’autre ?

Utiliser un numéro de révision supplémentaire :
test.h@REV est le fichier test.h à moment de la révision REV
115
5.3 Identification absolue de
révision
librairies.php
functions.php
Révision 13
commun.php

svn
svn
svn
svn
svn
cat
cat
cat
cat
cat
-r
-r
-r
-r
-r
10
10
10
10
33
commun.php
commun.php@34
commun.php@17
commun.php@3
commun.php@2
Révision 23
commun.php
=> Unable to find repository location
for ‘commun@17’ in revision 10
svn cat commun.php Ù svn cat commun.php@BASE dans une wc
svn cat https://xxx/commun.php Ù svn cat https://xxx/commun.php@HEAD
hors wc
116
svn cat commun.php@REV Ù svn cat -r REV commun.php@REV
5.4 Svn et les authentifications

svn --version permet de connaître :

La version du client svn
Les protocoles de communication que svn connaît (http, https, svn ou file)

Pour la plupart des opérations svn n’a pas besoin de contacter le serveur
=> pas d’authentification nécessaire

svn ne demande de s’authentifier que lors d’opérations le nécessitant

Après une authentification, svn met en cache (dans des fichiers dans
~/.subversion/auth) vos paramètres d’authentification et ne vous les
redemandera pas
=> sauf en cas d’authentification par certificat
=> sauf si vous utilisez --no-auth-cache ou store-auth-creds (voir après)

Sous windows, protection par encryption avec une clé par utilisateur
Sous linux, protection par droits sur les fichiers
117
5.5 Configuration du client svn

Les utilisateurs peuvent vouloir utiliser de façon systématique de
nombreuses options des commandes svn

Ex : --no-auth-cache pour chaque commande
Pour cela svn permet de stocker vos ‘préférences’ dans des fichiers de
configuration

Fichier servers
Fichier config
Stockés dans la zone de configuration de svn

Une propre à chaque machine
Une propre à chaque utilisateur

Ces fichiers sont modifiables à l’aide de n’importe quel éditeur et ne
sont pas versionnés !

Ils contiennent une liste de couples (clé / valeur) contenue dans
différentes sections
118

La première fois qu’une commande svn est exécutée, la zone de
configuration de subversion par utilisateur est créée (avec des valeurs
par défaut) :

La zone de configuration de svn par machine n’est pas créée
automatiquement. Elle se situe :

Dans $HOME/.subversion sous linux
Dans C:\Documents and Settings\user\Application Data\Subversion sous
Windows (répertoire caché et la localisation dépend de la version)
Dans /etc/subversion sous linux
Dans C:\Documents and Settings\All Users\Application Data\Subversion
sous Windows (répertoire caché et la localisation dépend de la version)
Ordre de priorité des options :
1.
2.
3.
Options de commande
Options de configuration par utilisateur
Options de configuration par machine
119

La zone de configuration par utilisateur contient également un répertoire Auth
qui sauvegarde les authentifications mises en cache, protégé par des droits
d’accès
Pour réinitialiser la zone de configuration par utilisateur, rm -rf
$HOME/.subversion puis svn --version par exemple mais perte du répertoire
Auth
Sous Windows, la configuration peut également être sauvée dans la base de
registre

C’est à l’initiative de l’utilisateur
HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion pour la configuration par
machine
HKEY_CURRENT_USER\Software\Tigris.org\Subversion pour la configuration par
utilisateur
Ordre de priorité :
1.
2.
3.
4.
5.
Options
Options
Options
Options
Options
de
de
de
de
de
commande
configuration
configuration
configuration
configuration
par
par
par
par
utilisateur du fichier de configuration
utilisateur de la base de registre
machine du fichier de configuration
machine de la base de registre
120
Fichier servers

Ce fichier est relatif aux couches réseau

Il contient 2 sections :

Groups

Permet de définir des noms de machines ou de domaines pour définir
des comportements propres à des serveurs svn
Ex :
[groups]
lpsc=lpsc.in2p3.fr
tigris = tigris.org
[lpsc]
…
[tigris]
…
Global

Permet de définir des comportements par défaut, pour tous les
serveurs n’étant pas trouvés dans une des sections de [groups]
121
Fichier servers

Principales options :

http-proxy-host, http-proxy-port, http-proxyusername, http-proxy-password, http-proxyexceptions
http-timeout
http-compression
neon-debug-mask
ssl-authority-files
ssl-trust-default-ca
ssl-client-cert-file
ssl-client-cert-password
122
Fichier config

Tout ce qui ne concerna pas le réseau !

Section [auth] pour gérer les authentification et autorisations :

store-passwords par défaut yes
store-auth-creds par défaut yes (toute information d’authentification)
Section [helpers] pour gérer les applications externes

editor-cmd l’éditeur pour saisir les logs durant les commit ou les valeurs de
propriété

Ordre de pritorité : option --editor- en ligne de commande, variable
d’environnement SVN_EDITOR, option editor-cmd, variables d’environnement
VISUAL, EDITOR
diff-cmd le chemin absolue vers un programme de diff pour générer la
sortie des svn diff
diff3-cmd le chemin absolue vers un programme de diff pour effectuer le
diff entre 3 versions
Si diff-cmd et diff3-cmd ne sont pas spécifiés, svn utilise des librairies
internes, différentes de diff et diff3 de GNU
Si vous désirez utilisez d’autres exécutables que ceux de GNU, il est
nécessaire de regarder les interfaces
123
Fichier config

Section [tunnels] pour gérer les tunnels ssh

Section [miscellany] pour tout le reste

global-ignores utilisé par svn status, svn add et svn import, à ajouter à la
valeur de la méta donnée svn:ignore
enable-auto-props pour utiliser les valeurs définis dans la section auto-props
pour les nouveaux éléments ajoutés au repository (svn add et svn import)
log-encoding définit l’encodage par défaut des messages de log (toujours
sauvegardés en UTF-8) – nécessaire si différent de la locale du système
d’exploitation
use-commit-times permet de positionner le timestamp des fichiers et
répertoires d’une working copy non pas à celui de dernière modification
dans la working copy mais dans le repository
Section [auto-props]

Ex :
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
*.sh = svn:eol-style=native;svn:executable
*.jpg = svn:mime-type=image/jpeg
124
5.6 Localisation

Permet d’obtenir une internationalisation de svn :

Pour tous les messages émis par svn

Pour les données saisis vers svn

En fonction de la variable d’environnement LC_MESSAGES
affiche tous les messages dans une langue donnée
Cela n’est possible que si subversion possède le fichier de
traduction pour la langue spécifique
ex : /usr/share/locale/de/LC_MESSAGES/subversion.mo
svn convertit les noms de fichiers, les chemins et les messages
de log depuis votre langue vers de l’unicode, en UTF-8
Pour le français : setenv LC_ALL fr_FR
125
5.6 Localisation
Rappel concernant les locales (région ou pays où les
conventions de localisation s’appliquent)

Sous linux, commande locale :

$ locale:
LANG=
LC_COLLATE="C "
LC_CTYPE="C"
LC_MESSAGES="C "
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL="C"
Si LC_ALL est positionnée toutes les autres variables ont sa valeur

Si LANG est positionnée toute autre variable non initialisée a sa valeur
$ locale -a => permet de connaître la liste des locales disponibles sur le système

Sous windows, panneau de configuration, options régionales
126
5.7 Branches – définition et utilité

Une branche est une ligne de développement indépendante des autres
mais qui partage un historique commun
Elle est toujours créée à partir d’une copie d’un répertoire déjà existant
et possède ensuite son propre historique
On créé des branches afin de :

maintenir plusieurs versions très similaires en même temps du même
logiciel => branches de fonctionnalité
Ex : un programme de gestion de ventes de PC et d’imprimantes partageant
90% de code commun
corriger des erreurs sur des versions anciennes
développer temporairement dans un environnement différent de celui des
autres développeurs
À l’extrême de ne développer que dans des branches et n’utiliser la branche
principale que pour y appliquer les modifications de branches
127

À chaque branche correspond un répertoire à la
racine du projet (et non du repository)
Trunk est une branche particulière : c’est la branche
d’origine, qui reste souvent la branche ‘principale’
Svn vous permet de :

créer des branches de fichiers et de répertoires
les maintenir en parallèle
vous informer de leur origine
appliquer les modifications d’une branche dans une autre
mixer plusieurs branches dans une même working copy
128
Revenir à la branche principale
Appliquer cette correction
à la branche principale
32
30
28
Δ
33
27
18
19
16
15
9
3
Corriger un bug sur une
version ancienne (3)
2
Créer deux versions
différentes du produit (avec
des fichiers en commun)
1
simulation.cpp
129
5.7 Branches – création

/
/
resa
resa

trunk
trunk

branches
branches
RMS
RMS
Vous désirez écrire une nouvelle
fonctionnalité, qui va affecter tous les
fichiers du projet pendant plusieurs
semaines
Vous ne voulez pas déranger vos collègues
qui développent d’autres fonctionnalités
Vous désirez effectuer des svn commit
régulièrement sans pour autant finaliser vos
modifications

trunk
trunk

branches
branches
113
Car vos modifications sont très importante en
taille
Vous désirez pouvoir sauvegarder vos
modifications et les diffuser (avec vos
collègues ou si vous avez plusieurs working
copy)
Vous désirez pouvoir récupérer les
modifications effectuées par les autres dans
la branche principale
=> création d’une branche
130

Pour créer une branche, vous effectuez une copie de la partie du repository qui
vous intéresse, en utilisant la commande svn copy

Cette copie peut s’effectuer n’importe où mais il est de coutume de l’effectuer
dans le répertoire ‘branches’

Vous allez donc créer un nouveau répertoire ‘multiresa’ dans le répertoire
resa/branches, qui va commencer d’exister en tant que copie du répertoire
resa/trunk
2 façons de le faire :

cd resa
svn copy trunk branches/multiresa
svn status
A + branches/multiresa
(c’est une copie de quelque chose pas une nouveauté)
svn commit –m’création de la branche multiresa pour les réservations multi objets’
svn copy https://xxx/resa/trunk https://xxx/resa/branches/multiresa –m’création de la
branche multiresa pour les réservations multi objets’
Attention, en shell : le résultat de cp rep1 rep2 dépend de l’existence de rep2 131
/
Branche principale
/
resa
resa
Branche pour le développement
parallèle
trunk
trunk
branches
branches
RMS
RMS
multiresa
multiresa
trunk
trunk
branches
branches
113
114
svn copy trunk branches/multiresa
svn commit -m ’création de la
branche multiresa’
Vous allez donc créer un nouveau répertoire
‘multiresa’ dans le répertoire resa/branches,
qui va commencer d’exister en tant que
copie du répertoire resa/trunk
132

Les branches ne partagent pas le même emplacement dans la
hiérarchie de fichiers du repository mais partagent le même référentiel
de temps : les mêmes numéros de révision
Les autres utilisateurs qui travaillent dans le trunk, lors de leurs ‘svn
update’ ne récupéreront pas vos mises à jour effectuées dans la
branche
Concepts clé : svn n’a pas de concept interne de branche.

Le résultat d’une copie est une branche car vous lui associez cette
signification
Une branche est en fait un répertoire comme les autres, que svn gère
comme n’importe quel répertoire
Cela est contraire aux autres systèmes de gestion de versions qui utilisent
une dimension supplémentaire
Une copie est une opération à temps et espace disque constant
=> Vous pouvez en créer aussi souvent que vous le désirez
133
118
110
114
branches/multiresa
120
trunk
cd resa/branches/multiresa
svn log –v calendar.php
cd resa/trunk
svn log –v calendar.php
-------------------------------------------------------------------------------------r118 | melot | 2005-08-22 16:51:25 +0200 (Mon, 22 Aug 2005) | 22 lines
Changed paths:
M resa/branches/multiresa/calendar.php
changes in the headers variable to respect standards
-------------------------------------------------------------------------------------r114 | melot | 2005-08-20 11:15:08 +0200 (Sat, 20 Aug 2005) | 2 lines
Changed paths:
A + resa/branches/multiresa/calendar.php
création de la branche multiresa pour les réservations multi objets
-----------------------------------------’--------------------------------------------r110 | dupond | 2005-08-17 16:58:43 +0200 (Wed, 17 Aug 2005) | 1 line
Changed paths:
M resa/trunk/calendar.php
Application du XHTML 4.0
-------------------------------------------------------------------------------------…
-------------------------------------------------------------------------------------r120 | dupond | 2005-08-22 18:50:15 +0200 (Mon, 22 Aug 2005) | 1 line
Changed paths:
changes in the headers variable to respect standards
-------------------------------------------------------------------------------------r110 | dupond | 2005-08-17 16:58:43 +0200 (Wed, 17 Aug 2005) | 1 line
Changed paths:
Application du XHTML 4.0
-------------------------------------------------------------------------------------…
134
5.7 Branches – svn merge
118
110
114
Δ
119 120
branches/multiresa
trunk

Afin de ne pas trop diverger, il peut être utile de récupérer de temps en temps
les modifications des autres d’une branche à une autre

Pour voir les différences :
svn diff -r 119:120 https://xxx/resa/trunk

Pour les récupérer :
cd resa/branches/multiresa
svn merge -r 119:120 https://xxx/resa/trunk
Cette commande est très similaire à svn diff mais au lieu d’afficher les
différences, elle les applique à votre working copy, en tant que modifications
locales :
svn status
M calendar.php
135

La commande merge compare deux arbres du repository et les
applique à une working copy

La commande merge requière 3 arguments :

Une version initiale du repository
Une version finale du repository
Une working copy qui va accueillir les différences en tant que modifications
locales (par défaut le répertoire courant)
ex :

svn merge -r 112:143 https://xxx/resa/trunk
svn merge https://xxx/branches/b1@153 https://xxx/branches/b2@176
branches/b3
Les modifications sont apportées dans des fichiers de même nom
Il existe une différence entre appliquer le résultat d’un diff et exécuter
un merge car le merge gère beaucoup plus de type de différences
(changement de méta données, modification d’arborescence, …)
136

svn update permet de se déplacer dans le temps alors que svn merge

S’il n’y a pas de modifications locales :
permet de se déplacer dans le temps et dans l’espace (de la hiérarchie
de fichiers) !

La résolution de conflit est similaire à celle résultant d’un svn update, à
part le nom des fichiers générés :

svn update n’implique jamais de conflit
svn merge peut en générer
file.mine, file.rOLD_rev et file.rNEW_rev pour svn update
file.working, file.merge-left et file.merge-right pour svn merge
Avant d’effectuer un svn merge, il est recommandé de commencer par
pré visualiser son résultat :

avec svn diff …
avec svn --dry-run merge …
car si vous aviez des modifications locales, svn revert vous les supprimera
137

Après un svn merge il est également recommandé de vérifier manuellement les
modifications => svn diff et svn status
Si les modifications ne vous conviennent pas => svn revert
(attention si modifications locales)
Si les modifications vous conviennent => svn commit en n’oubliant surtout pas
de spécifier dans le message l’origine des modifications (issues d’un merge de
branche)

Car si vous importez les modifications d’une branche à une autre de temps en temps, il
est nécessaire de garder une trace fiable afin de ne pas réimporter les mêmes
modifications plusieurs fois
Attention svn merge se soucie du lien de ‘parenté’ entre différentes révisions
d’un même fichier
Ce n’est pas le cas pour svn diff !
librairies.php
functions.php
commun.php
Révision 13
Révision 23
commun.php
138
Δ
118
110

114
124
Δ
120
trunk
Cas d’utilisation : merger tout le contenu d’une branche dans une autre
trunk
cd resa
svn merge https://xxx/multiresa@HEAD https://xxx/trunk@HEAD
cd resa
svn merge -r 114:HEAD https://xxx/multiresa trunk
cd resa/trunk
svn merge -r 114:124 https://.../multiresa

branches/multiresa
+ svn ci
+ svn ci
Méthode pour retrouver la révision de création de la branche :
svn log –v --stop-on-copy resa/multiresa
139
Δ
Δ
118
110

114
159 branches/multiresa
124
120
125
trunk
Cas d’utilisation : merger tout le contenu d’une branche dans une autre
en plusieurs fois
cd resa
svn ci -m’merge la branche multiresa –r114:124 dans le trunk’
=> car on a déjà récupéré les modifications de r114 à r124
svn ci -m ’merge la branche multiresa –r125:159 dans le trunk’

Les messages de log sont dans ce cas extrêmement importants car
sans eux on ne peut plus savoir où on en est !
140
(perdre les modifications en local)
Etat actuel dans la
working copy
modifications
?
8
Svn update commun.php ?
7
Non
=> Svn revert commun.php
6
5
commun.php
141
Dans la working copy
9
svn update –r 6
8
svn commit
7
? du repository)
8
(perdre des modifications
6
7
svn merge –r 8:6 https://xxx 6
svn commit
5
5
Cette commande a enlevé un ‘delta’ entre deux révisions et a
effectué le merge avec la version de la working copy
142

svn merge peut servir à ‘dévalider’ des modifications validées dans le
repository, que vous n’auriez sûrement jamais dû valider

Cela permet de revenir à l’état voulu mais l’historique reste toujours
inchangeable : la modification n’affecte que le HEAD

La commande :
svn merge -r 8:6 https://xxx
svn commit -m ’undoing changes committed in 8 and 7’

Il existe cependant des méthodes pour supprimer définitivement du
repository des révisions non voulues

Par des commandes d’administration => pas l’utilisateur
Utile par exemple en cas d’ajout non désiré de documents confidentiels
143

Récupérer un fichier détruit dans le repository :

cd resa/commun
svn rm init_config.php
svn commit -m ’init_config.php ne sert plus’
…
On commence par rechercher l’emplacement et la révision du fichier que l’on
recherche à l’aide de la commande svn log –v
r1197 | paul | 2006-10-13 12:45:52 +0200 (Fri, 13 Oct 2006) | 1 line
Changed paths:
D commun/init_config.php
…

Première méthode :
svn merge -r HEAD:1196 https://xxx/commun
mais attention récupérera toutes les autres modifications (=> svn revert)

Méthode à préférer :
svn copy -r 1196 https://xxx/commun/init_config.php commun/init_config.php

Et toujours un commit avec un commentaire utile :
svn commit -m ’récupération du fichier supprimé commun/init_config.php depuis la
révision 1196’
144
5.7 Branches – svn switch

La commande svn switch, bien que utile, n’est pas nécessaire pour travailler
avec des branches, mais permet un gain de temps pour certaines opérations

Elle transforme une working copy d’une hiérarchie de fichiers à une autre

Ex :

On aurait obtenu la même chose avec
cd resa/trunk
svn switch https://xxx/resa/branches/multiresa
U commun.php
U config.php
svn co https://xxx/resa/branches/multiresa

Mais souvent le trunk et les branches ne différent que de quelques fichiers dans
une partie limitée de l’arborescence
=> seuls les différences sont envoyées
=> gain de temps
145

On peut utiliser --revision pour ne pas récupérer la HEAD
révision

svn update permet de se déplacer dans le temps à l’intérieur

Une working copy peut ainsi contenir un mixte de numéros de
révisions mais également un mixte de hiérarchies de fichiers

Dans un tel cas, svn update et svn commit agiront
récursivement dans chaque portion de la hiérarchie
d’une hiérarchie de fichiers donnée
svn switch permet de se déplacer dans le temps et dans la
hiérarchie de fichiers
svn update est en fait un cas particulier de svn switch
146

Cas d’utilisation :

En général en copie l’entièreté du trunk pour créer la branche
On switch seulement une partie pour gérer la branche (un répertoire ou un
fichier)
Cela permet de continuer de recevoir les modifications du trunk, sans les
appliquer dans la branche

Lors d’un svn switch les modifications en local sont gardées (merge),
comme lors d’un svn update

Cas d’utilisation : vous avez effectué des modifications dans le trunk et
vouliez en fait les effectuer dans une branche :

vous switchez vers la branche
effectuez le commit dans la branche
switchez vers le trunk
svn switch met à jour une working copy en pointant vers une autre
URL du même repository et svn switch --relocate en pointant vers le
même repertoire d’une autre URL (ex : changement de serveur)
147
5.7 Tags

Un tag est un snapshot du repository à un instant donné

Une révision est déjà un snapshot de la hiérarchie de fichiers à un
instant donné

Mais un tag permet de lui donner un nom plus attractif qu’un entier et
peut ne concerner qu’une partie de la hiérarchie de fichiers
Ex : il est plus simple de se souvenir du tag ‘release-1.9’ que de retenir
que la version finalisée est un répertoire particulier de la révision 8842
Pour créer un tag :

svn copy https://xxx/resa/trunk https://xxx/resa/tag/version-1.1 -m ‘tag de
la version 1.1 de resa’
svn copy –r 2062 https://xxx/resa/trunk https://xxx/resa/tag/version-1.1 -m
‘tag de la version 1.1 de resa’
148
5.7 Tags

Il s’agit de la même méthode que pour créer une branche !!!

Pour subversion une branche ou un tag sont des répertoires comme les
autres, créés par une copie

Il n’existe pas de ‘dimension’ supplémentaire pour les représenter

La différence entre les deux, c’est vous qui la faites !

Si vous ne modifiez pas un répertoire copié, il s’agit d’un tag

Dés que vous modifiez pas un répertoire copié, il s’agit d’une branche

C’est pour les distinguer que l’on créé des répertoires trunk, tags et
branches dans les repository
149
5.7 Tags

On peut également créer un tag ‘complexe’, en créant dans une
working copy un mixte de numéros de révisions (avec svn
update) et de hiérarchies de fichiers (avec svn switch) puis :
svn copy trunk https://xxx/resa/tags/versionTest -m ‘création de
tag avec la révision 3924 du trunk mixé avec la révision 4808 de
la branche multiresa’
=> vos modifications locales, non validées, seront copiées

Il n’est pas recommandé d’utiliser cette méthode pour créer une
branche car on ne sait plus après avec exactitude d’où provient
la branche, surtout s’il y avait des modifications locales
150
5.7 Branches – cas usuels

Dans le cas de développement d’applications, il existe deux cas ‘classiques’
d’utilisation de branches :

Branche de release
=> cas des logiciels distribués sous forme de release
Δ
tags/1.0.0
117 118
110
114
124
120
128
125
tags/1.0.1
139
branches/1.0
trunk
branches/2.0
Fin des développements de la version 1.0 du code dans le trunk, en 114
=> Il faut la tester et commencer à développer la version 2.0
Création d’une branche de release

Correction de bug
Développement de la version 2.0
Portage(s) des corrections de bugs dans la branche principale
La branche est taggée 1.0.0 et délivrée
Elle est par la suite maintenue et peut donner lieu à d’autres releases
Création d’une nouvelle branche de release pour la version 2.0
151
5.7 Branches – cas usuels

Branche de fonctionnalité
=> branche temporaire créée pour des développements complexes pouvant
‘nuire’ à la stabilité du trunk
Δ
118
121

114
126
Δ
branches/multiresa
Δ
Δ
110
124
120
125
127
trunk
Créer une branche de fonctionnalité : multiresa
Effectuer des modifications dans le trunk et dans la branches
Effectuer des merges du trunk vers la branche régulièrement (ex : toutes les semaines)
svn merge -r 114:120 https://xxx/trunk branches/multuresa + ci
svn merge -r 121:125 https://xxx/trunk branches/multuresa + ci
svn merge -r https://xxx/trunk@HEAD https://xxx/branches/multuresa@hEAD trunk + ci

Remarque : dans certains cas on cherche à effectuer le merge de la branche vers le trunk
152
et dans d’autres cas du trunk vers la branche
5.7 Branches
svn update, svn merge, svn switch, …
=> imaginez vos fichiers dans un espace à deux
dimensions :
hiérarchie de fichiers / numéros de révisions
Hiérarchie de fichiers
…
trunk/init
trunk/config
trunk/img
branches/multiresa
branches
trunk/commun
trunk
Numéros de révisions
1
2
3
4
5
6
7
8
9
10 11 12 13
14 15 16
153
PLAN

Conclusion
154
Utilisation d’interface graphique

TkSVN

Utilisable sous Linux, Windows et Mac/OS
Basé sur Tcl/Tk
TortoiseSVN

Pour Windows

TRAC

…

Un grand avantage des GUI : la visualisation graphique du résultat d’un diff

avec TkSVN : TkDiff
il existe des logiciels permettant de visualiser des différences entre fichiers word,
excel, …
Mais les interfaces graphiques ne permettent pas de tout faire

toutes les options des commandes ne sont généralement pas implémentées
bugs
155
Conclusion

Documentation disponible :

http://subversion.tigris.org et http://svnbook.red-bean.com
http://svn.haxx.se/users
http://www.svnforum.org
Groupe de discussion sur http://lpsc.in2p3.fr/elog/SVN

Ce cours est à adapter en fonction de votre environnement

Aucun code ne devrait être développé sans un outil de gestion de
versions

Si on est tout seul, l’utilisation en est simplifié => jamais d’update
nécessaire, ni de conflit mais on peut créer des branches

SVN est censé vous faire gagner du temps, pas en perdre

Questions
156
Sommaire
1 Présentation générale - Fonctions et avantages………………………………………………………………..
1.1 Ce qu’est Subversion………………………………………………………………………………………………..
1.2 Pourquoi utiliser Subversion ?......................................................................................
1.3 D’où vient Subversion ?...............................................................................................
1.4 Améliorations par rapport à CVS………………………………………………………………………………..
1.5 Ce cours………………………………………………………………………………………………………............
3
4
5
7
8
10
2 Concepts fondamentaux………………………………………………………………………………………...........
2.1 Architecture (repository, working copy et communication)………………………………............
2.2 Principe de fonctionnement……………………………………………………………………………..........
2.3 Différents modèles de systèmes de gestion de versions……………………………………..........
La solution lock – modify – unlock………………………………………………………………………………
La solution copy - modify – merge……………………………………………………………………….......
2.4 Accès au repository………………………………………………………………………………………………..
2.5 Précisions sur la working copy………………………………………………………………………………...
2.6 Révisions……………………………………………………………………………………………………….........
2.7 Commandes SVN – généralités………………………………………………………………………………...
11
13
16
19
24
26
34
35
39
43
3 Description des commandes de base……………………………………………………………………………….
3.1 Qui fait quoi ?............................................................................................................
3.2 Commande checkout……………………………………………………………………………………….........
3.3 Comment SVN effectue ses comparaisons (rappel)……………………………………………………
3.4 Commande update………………………………………………………………………………………...........
Exemples d’update……………………………………………………………………………………………………
3.5 Checkout versus Update………………………………………………………………………………............
3.6 Commande commit………………………………………………………………………………………………..
47
49
50
52
53
55
59
60
Sommaire
4 Description des autres commandes courantes……………………………………………………………………
4.1 Commande Import…………………………………………………………………………………………………….
4.2 Modifications de la working copy - commandes add, delete, copy, move et mkdir…………..
4.3 Examiner vos modifications - commandes status et diff……………………………………………….
4.4 Commande revert……………………………………………………………………………………………………..
4.5 Résoudre les conflits - commande resolved…………………………………………………………………
4.6 Connaître l’historique du repository - commandes log, diff, list et cat…………………………….
4.7 Commandes export et cleanup……………………………………………………………………………………
4.8 Test d’une connexion à un repository svn……………………………………………………………………
4.9 Récapitulatif……………………………………………………………………………………………………………..
62
64
65
71
77
79
84
90
91
92
5 Utilisation avancée de svn………………………………………………………………………………………………..
5.1 Gestion des méta données…………………………………………………………………………………………
Utilisation des méta données : portabilité de fichiers………………………………………………………
Utilisation des méta données : fichiers non gérés par svn……………………………………………….
Utilisation des méta données : mots clés de substitution………………………………………….......
Utilisation des méta données : définitions externes………………………………………………………..
5.2 Mécanismes de verrouillage……………………………………………………………………………………….
5.3 Identification absolue de révision……………………………………………………………………………….
5.4 Svn et les authentifications ……………………………………………………………………………………….
5.5 Configuration du client svn………………………………………………………………………………………..
5.6 Localisation………………………………………………………………………………………………………………
94
96
101
104
105
107
110
115
117
118
125
Sommaire
5.7 Branches et tags………………………………………………………………………………………………………
Branches – définition et utilité……………………………………………………………………………………..
Branches – création…………………………………………………………………………………………………….
Branches – svn merge…………………………………………………………………………………………………
Branches – svn switch…………………………………………………………………………………………………
Tags………………………………………………………………………………………………………………………….
Branches – cas usuels………………………………………………………………………………………………..
127
127
130
135
145
148
151
Conclusion……………………………………………………………………………………………………………………….
154