Guide dutilisation de Subversion

D. Renault
20 septembre 2011

Rsum
Le but de ce document est de donner une introduction sur Subversion, un systme
de gestion de version. Il dfinit les notions lies au contrle de version, puis dtaille
lutilisation de ce programme pour grer un projet.

Quest-ce quun systme de gestion de version ?

La ralisation dun projet bas sur un ensemble de fichiers source, quil sagisse du
code dun programme en langage C ou du source dun rapport rdig en LATEX, passe
invitablement par de nombreuses versions successives. Une version du projet, appele
aussi rvision, reprsente lensemble des fichiers appartenant au projet un moment fix
de son dveloppement, telle une photographie de son tat instantan. Le projet volue ainsi
partir de sa rvision initiale vers une rvision propre sa mise en production (release).
Un systme de gestion de version, en anglais version control system (VCS) ou source
code management (SCM) est un ensemble doutils permettant de stocker et de manipuler
un code source ainsi que toutes les rvisions quil a subies depuis sa cration. Un tel systme
permet de grer le code la fois :
travers le temps (possibilit darchiver des versions du code et dinverser (reversion)
des modifications) ;
travers lespace (possibilit de faire partir le code dans plusieurs directions spares
(branching), et ventuellement de les rassembler (merging)).
Le fait de pouvoir accder facilement lensemble des versions dun code permet ainsi
de faciliter certaines phases de son dveloppement. Cependant, la proprit fondamentale
dun tel systme est le fait quil permette de travailler plusieurs sur le code de manire
concurrente dans de bonnes conditions : chaque programmeur peut travailler partir dune
version du code, en dvelopper une nouvelle version indpendante, et/ou dcider de la
rassembler avec la rvision dun autre programmeur, en grant les conflits.
Ce document explique les concepts gnraux et les modalits de fonctionnement dun
systme de gestion de version particulier nomm Subversion (et parfois abrg en svn),
notamment utilis lENSEIRB pour la gestion des projets en 1re anne.

Processus de travail

Lorsque lon travaille seul sur un projet sans utiliser de systme de gestion de version,
le processus de travail (workflow ) consiste gnralement crer un rpertoire de travail,
puis modifier graduellement les donnes dans ce rpertoire en faisant des modifications
successives, jusqu obtenir (dans le meilleur des cas) une version finale (release).

Init

Rev. 2

Rev. 1

Rev. n

Release

Lorsque lon travaille plusieurs sur le mme projet, ce workflow atteint ses limites.
En effet, partir dune rvision donne, plusieurs personnes peuvent travailler et crer des
rvisions diffrentes. Lensemble des rvisions prend alors une forme plus complexe :

Rev. 1a

Init

Rev. 2a

Rev. 2b

Rev. 3

Rev. n

Release

Rev. 1b
Rev. 2c

Plusieurs questions viennent se poser :

Problme n 1 : Quelle est la rvision courante (de rfrence) des sources du projet ?
Cette question se pose naturellement pour un dveloppeur extrieur au projet qui
dsire contribuer, ou pour dcider de la rvision devant tre communique au client
lors de la release. Une faon de rpondre ce problme consiste dsigner une suite de
rvisions particulire pour tre la version de rfrence. Concrtement, il peut sagir
dun rpertoire particulier dsign au dpart comme le rpertoire devant contenir
toutes les rvisions de rfrence. Toute rvision extrieure ce rpertoire devra alors
tre fusionne (merging) avec les donnes de rfrence. Mais alors :
Problme n 2 : Comment grer la fusion de deux rvisions distinctes ?
Ce problme est plus pineux, dans la mesure o deux versions des donnes peuvent
avoir des diffrences non triviales menant des conflits. Il devient alors ncessaire aux
responsables du projet de grer ces conflits la main, ce qui consiste construire une
rvision des donnes partir de deux rvisions distinctes et qui prennent au mieux
en compte les modifications apparaissant dans ces rvisions.
Lutilisation dun systme de gestion de version comme Subversion va permettre de fournir
une rponse ces problmes.
2

Fonctionnement de Subversion

Subversion (http://subversion.tigris.org) est un systme de gestion de version

open-source, dvelopp partir de 2000 pour remplacer le vieillissant CVS (Concurrent
Version System, http://www.nongnu.org/cvs, dbut la fin des annes 80), qui hritait
lui-mme de RCS (Revision Control System, http://www.gnu.org/software/rcs).

2.1

Dpts

Subversion est un systme centralis : les donnes sont ranges dans un espace de
stockage particulier appel dpt (repository). Le dpt prend la forme dun rpertoire
ayant la structure suivante :
README.txt
conf/
dav/
db/
format
hooks/
locks/

Fichiers de configuration
Rpertoire ddi au serveur web (Apache)
Emplacement des donnes
Numro de rvision courant
Scripts personnaliss
Informations concernant les fichiers vrouills

Lexistence du dpt est une rponse lun des problmes voqus au paragraphe
prcdent : le dpt sert de rfrence pour les donnes, ce qui assure que cette rfrence
soit unique. Laccs aux donnes se fait uniquement travers le dpt, la manire dune
architecture client/serveur : toute personne (le client) participant au projet peut rcuprer
une rvision des donnes partir du dpt (le serveur), les modifier localement, pour enfin
transmettre une nouvelle rvision au dpt, afin que celui-ci puisse les redistribuer.
Les donnes sont stockes dans le dpt lintrieur dun systme de fichiers particulier
appel FSFS, et stock dans le rpertoire db/. Ce systme de fichiers diffre des systmes
de fichiers usuels (NTFS, Ext3 . . .) dans la mesure o il stocke la fois les donnes et les
diffrentes rvisions quelles ont subies depuis la cration du dpt.
En pratique, pour chaque rvision des donnes, Subversion cre un fichier delta, cest-dire un fichier contenant toutes les modifications faites aux donnes lintrieur du dpt
par rapport la rvision prcdente. Ce fichier delta est ensuite stock dans un des sousrpertoires du rpertoire db/, lintrieur du dpt.
Ainsi, Subversion permet un stockage efficace des donnes : le poids dune rvision ne
dpend que des modifications faites lors de cette rvision. Par exemple, les dplacements,
renommages ou suppressions de fichiers ont un poids ngligeable.
La cration dun dpt se fait avec la commande suivante : svnadmin create hnom_depoti o
reprsente le nom du rpertoire dans lequel sera stock le dpt. En gnral,
les dpts sont stocks sur des serveurs accessibles par Internet, comme sourceforge.net,
mais il est aussi possible de crer des dpts sur un serveur de fichier local.
hnom_depoti

2.2

Rpertoire de travail

Les personnes utilisant Subversion ont rarement besoin de naviguer lintrieur du

dpt pour en examiner les fichiers, pour la simple raison que les donnes ne sont pas
directement lisibles lintrieur du dpt. Pour travailler sur les donnes, on utilise un
rpertoire de travail (workspace ou working copy) dans lequel les donnes sont accessibles
sous la forme dune arborescence de fichiers.
La cration dun rpertoire de travail se fait gnralement en effectuant un retrait
(checkout ) partir dun dpt existant. Par exemple, si le dpt est accessible dans le
systme de fichiers courant, il faut utiliser la commande svn checkout file ://hchemini hnom_repi
o hchemini est le chemin daccs complet au dpt et hnom_repi reprsente le nom du
rpertoire de travail (cf. paragraphe 3 pour plus dinformations).
Le rpertoire obtenu partir dun dpt nouvellement cr est initialement vide,
lexception dun rpertoire .svn/ contenant des donnes "administratives" sur le rpertoire,
comme le nom du dpt li ce rpertoire de travail ou les numros de rvision des fichiers
dans le rpertoire. Par la suite, chaque sous-rpertoire du rpertoire de travail contiendra
un rpertoire .svn/, ce qui en fait un moyen sr de reconnatre un rpertoire de travail
Subversion.

2.3

Travailler en utilisant Subversion

Comment travaille-ton concrtement avec Subversion ? Le workflow est prsent dans

le diagramme suivant et mis face face au mme workflow sans systme de gestion de
version.
Workflow simple

mkdir

Workflow avec Subversion

Initialisation du rpertoire de travail

Mise jour du rpertoire de travail

emacs

Modification des donnes

Rsolution des conflits (si ncessaire)

Dpt de la rvision

svn checkout

svn update

emacs, svn add

svn del, svn move

svn update,
svn resolved

svn commit

Globalement, le processus de travail, selon que lon travaille avec ou sans gestionnaire
de version, est le mme : il faut dabord initialiser un rpertoire de travail, puis crer des
rvisions successives par modification des donnes. Nanmoins, il existe plusieurs subtilits.
Premirement, avec Subversion, il faut communiquer avec le dpt chaque fois que lon
dsire obtenir ou transmettre des rvisions des donnes. Ensuite, au moment de transmettre
des donnes, il est possible quune personne ait dj modifi la mme partie du code que
celle que lon dsire communiquer. Il faut alors fusionner ses modifications avec la rvision
courante existant dans le dpt.
Do deux rgles de bonne conduite pour lutilisation de Subversion :
Rgle n 1 : Il faut systmatiquement mettre jour le rpertoire de travail,
en particulier avant toute communication avec le dpt.
Puisque le dpt contient la version de rfrence des sources, il est ncessaire de
se mettre jour avant de modifier les sources, mais aussi avant de les transmettre
afin de sassurer que lon na pas fait de modification en mme temps quune autre
personne. Cela permet de minimiser les risques de conflits
Rgle n 2 : Deux personnes doivent (autant que possible) travailler sur des
fichiers diffrents.
Avec Subversion, Les conflits napparaissent que lorsque deux personnes modifient
une mme zone de code dans le mme fichier au mme moment. Toutes les modifications dans des endroits distincts du rpertoire de travail (fichiers spars / zones du
code clairement loignes dans un mme fichier) sont gres automatiquement par
Subversion. Pour viter les conflits, il suffit donc de ne pas travailler en mme temps
sur une mme zone de code.

Dans les paragraphes suivants sont dcrites les principales commandes offertes par
Subversion, dans le cadre dune utilisation raisonnable du systme de gestion de version.

changes avec le dpt

Retrait du dpt :

svn checkout

, svn co

Permet de crer un rpertoire de travail partir de ladresse dun dpt donne sous la
forme dune URL.
svn checkout hprotocolei ://hchemini hnom_repi
% s v n co h t t p s : / / t h o r . e n s e i r b . f r / d e p o t l o c a l _ d i r

hprotocolei

hchemini

hnom_repi

Peut prendre la valeur file pour un dpt local, http pour un dpt
accessible par WebDAV 1 , svn ou svn+ssh pour un dpt accessible
travers un serveur Subversion.
Le chemin complet daccs au dpt. Par chemin complet, on entend lURL dans le cas dun serveur distant et le chemin absolu
pour des ressources locales.
Le nom du rpertoire de travail.

Mise jour du rpertoire de travail :

svn update

, svn up

Permet damener un rpertoire de travail la rvision actuelle dans le dpt. Si le rpertoire

de travail contient des modifications par rapport la rvision quil est suppos contenir,
cette opration peut mener des conflits.
svn update
svn update -r hrevisioni

hrevisioni

% svn update
U
code . c
Updated t o r e v i s i o n 3 .

Le numro de rvision que lon veut atteindre. Sans cet argument,

Subversion mettra jour le rpertoire la rvision la plus rcente.

1. Web Distributed Authoring and Versioning, un protocole utilis pour sauthentifier sur un serveur
distant.

 Communication dune rvision au dpt :

svn commit

, svn ci

Permet de crer une nouvelle rvision lintrieur du dpt. De manire semi-automatique,

Subversion encourage associer un commentaire lors de tout ajout dune rvision dans le
dpt. Si lon ne passe pas de commentaire en paramtre la commande, Subversion va
excuter un diteur de texte dans lequel on pourra diter ledit commentaire.

svn commit
svn commit -m hcommentairei

hcommentairei

% s v n commit
/ E c r i t u r e du c o m m e n t a i r e a v e c emacs /
Sending
code . c
Transmitting f i l e data .
Committed r e v i s i o n 4 .

Le commentaire li cette nouvelle rvision.

Usuellement, le commentaire dcrit les modifications apportes par la rvision. Il dcrit les
tests raliss pour assurer un fonctionnement correct du code, et il donne des informations
sur ltat du code aprs la rvision (Le programme compile til ? Gnre til des erreurs ?)
Import de donnes dans le dpt :

svn import

Permet dajouter directement toute une arborescence lintrieur dun dpt. Cette commande prend son utilit lorsque lon dispose dun ensemble de sources que lon dsire
intgrer lintrieur du dpt Subversion.
svn import hnom_repi hprotocolei ://hchemini -m hcommentairei
% svn import l o c a l _ d i r h t t p s :// t h or . e n s e i r b . f r / depot / l o c a l

hprotocolei
hchemini
hnom_repi
hcommentairei

Se rfrer la commande svn checkout

Le nom du rpertoire local que lon dsire importer.

Le commentaire associ cet import de donnes.

Concrtement, cette commande correspond un commit de lensemble des fichiers dans

le rpertoire hnom_repi, et il convient de lui faire correspondre un commentaire dcrivant
cet ajout massif de fichiers.

 Extraction du dpt sans les fichiers lis Subversion :

svn export

Permet dobtenir un rpertoire contenant la dernire rvision des sources, mais ne contenant aucune information relative au systme de gestion de version (en particulier, aucun
rpertoire .svn). Cette commande trouve son utilit lorsque lon dsire produire une release,
une archive destine un public extrieur lquipe de dveloppement.
svn export hnom_sourcei hnom_desti
% svn e xp ort l o c a l _ d i r r e l e a s e _ d i r

Informations sur le dpt

Etat courant dun fichier dans le rpertoire de travail :

svn status

, svn st

Permet dobtenir des informations concernant les fichiers dcrivant leur raison dtre sous
contrle de version. Cette information est code sous la forme dun caractre, suivi du nom
du fichier.

svn status hfichieri

% svn s t a t u s
A
code . c
U
type . c
U
Makefile

La liste des codes utiliss par Subversion est :

?
A
C
D
I
M
R

La version du fichier correspond la rvision courante.

Le fichier nest pas contrl par Subversion.
Le fichier va tre ajout lors du prochain dpt.
Le fichier est en conflit avec la version de rfrence.
Le fichier va tre supprim lors du prochain dpt.
Subversion est configur pour ignorer ce fichier..
Le fichier a t modifi par rapport la dernire mise jour.
Le fichier va tre remplac lors du prochain dpt.

Les caractres indiquant le statut dun fichier peuvent aussi apparatre lors de lutilisation
dautres commandes de Subversion. Cest en particulier le cas lors des mises jour (update),
pendant lesquelles peuvent apparatre les codes suivants :
C
G

Le fichier est en conflit avec la version de rfrence.

Le fichier a t mis jour par rapport au dpt, il contenait des modifications par rapport la version de rfrence, mais ces modifications ont
t intgres automatiquement.
Le fichier a t mis jour la dernire version prsente dans le dpt
sans avoir grer de modifications locales.

 Liste des messages de commentaires :

svn log

Fournit lhistorique complet des rvisions associes un fichier ou un rpertoire du dpt,

ainsi que les commentaires associs.

svn log hfichieri

% s v n l o g code . c

r 1 8 | r e n a u l t | 20080323 | 2 l i n e s

svn log -r hrevisioni hfichieri

svn log -r hr1i :hr2i hfichieri

hfichieri

hrevisioni
hrev1i :hrev2i

C o r r e c t i o n du bug de l a mangouste .

(Optionnel) Le fichier dans le dpt que lon souhaite analyser. Si

aucune rvision nest donne, affiche les diffrences avec la dernire
version dans le dpt.
Indique la rvision du dpt laquelle on veut comparer la version
de travail.
Indique les deux rvisions du dpt entre lesquelles on dsire calculer les diffrences.

Par exemple, la commande svn log r 1:HEAD permet dobtenir lensemble des rvisions
associes au dpt.
Affichage des diffrences entre rvisions :

svn diff

Cette commande permet de visualiser les diffrences entre deux rvisions dans le dpt,
voir entre une rvision du dpt et les fichiers actuellement dans le rpertoire de travail
(cf. paragraphe 6.1 pour plus dinformations).

svn diff hfichieri

svn diff -r hrevisioni hfichieri
svn diff -r hrev1i :hrev2i hfichieri

hfichieri

hrevisioni
hrev1i :hrev2i

% s v n d i f f code . c
code . d e p o t . c
+++ code . l o c a l . c
@@ 1 , 1 0 +1 ,7 @@
#i n c l u d e <s t d i o . h>
#i n c l u d e <s t d l i b . h>
+#i n c l u d e <math . h>

(Optionnel) Le fichier dans le dpt que lon souhaite analyser. Si

aucune rvision nest donne, affiche les diffrences avec la dernire
version dans le dpt.
Indique la rvision du dpt laquelle on veut comparer la version
de travail.
Indique les deux rvisions du dpt entre lesquelles on dsire calculer les diffrences.

Manipulation des fichiers

Ajout dun fichier :

svn add

Suppression dun fichier :

svn delete

, svn del , svn remove , svn rm

Lajout et la suppression dlments dans le dpt se fait naturellement avec les commandes
suivantes. Ces commandes ne modifient que le rpertoire de travail. Pour les transmettre
au dpt, il est impratif de les faire suivre dun svn commit.
svn add hfichieri
svn del hfichieri

% s v n add README. t x t
A
README. t x t

Dplacement dun fichier :

svn move

, svn mv , svn rename , svn ren

Copie dun fichier :

svn copy

, svn cp

La modification des fichiers lintrieur de cet espace de travail se fait la plupart du temps
avec les outils usuels, comme emacs. Nanmoins, il existe des cas particuliers qui sont la
copie, le dplacement, ou le renommage des fichiers. Si lon utilise les commandes usuelles
cp ou mv, on va crer de nouveaux fichiers qui ne sont pas dans le dpt. Et ces nouveaux
fichiers nauront pas lhistorique des fichiers partir desquels ils ont t crs. A la place,
on utilise des commandes pratiquement homonymes propres Subversion
svn mv hsourcei hdesti
svn cp hsourcei hdesti

% s v n move b a r r e . c choc . c
A
choc . c
D
barre . c

Noter que Subversion affiche ct de chaque fichier un caractre dcrivant ltat courant
de ce fichier dans le dpt (cf. la commande svn status).

10

Gestion dun conflit

Lorsque plusieurs personnes travaillent de manire indpendante sur les mmes fichiers
source, il arrive parfois que leurs modifications soient conflictuelles : dans le dpt coexistent deux versions diffrentes dun mme fichier. Dans les dernires versions de Subversion, un conflit est annonc de la manire suivante lors de lappel la commande svn update :
C o n f l i c t d i s c o v e r e d i n code . c .
S e l e c t : ( p ) p o s t p o n e , ( d f ) d i f f f u l l , ( e ) e d i t ,
(mc) minec o n f l i c t , ( t c ) t h e i r sc o n f l i c t ,
( s ) show a l l o p t i o n s :

Dans la mesure o il nest pas trivial de rassembler ces modifications en une seule et
unique nouvelle rvision du code, il existe un certain nombre de possibilit pour rsoudre
les conflits. En fait, Subversion est capable de grer automatiquement un certain nombre
de conflits (cf. la commande svn status, codes U et G). Lorsque le menu prcdent apparat,
il est possible de prendre plusieurs dcisions :
Repousser la dcision (p) : lutilisateur dsire grer le conflit manuellement. Il sagit
de la procdure la plus libre, et elle est dtaille dans les paragraphes suivants.
Afficher les conflits et diter la vole (df, dc, e,r) : lutilisateur peut vouloir grer
directement le conflit la main lintrieur mme du processus de mise jour. Si
lon manque de pratique, ce choix est dconseill, dans la mesure o les commandes
fournies sont limites.
Choisir une version automatiquement (mc, tc) : lutilisateur peut choisir de prfrer
une version directement sans rsoudre le conflit, la sienne (mc) ou celle du dpt
(tc). Le conflit est alors automatiquement rsolu
Dans les paragraphes suivants, nous montrons comment rsoudre un conflit manuellement,
en ayant choisi loption de repousser la dcision (p).

6.1

Diffrences entre deux fichiers

Supposons lexistence dun fichier de code existant dans le dpt Subversion. Actuellement, voici la version actuelle dun fichier du dpt :
Rvision initiale (code.init.c) :
1

#i n c l u d e <s t d i o . h>

2
3
4
5
6

i n t main ( v o i d ) {
p r i n t f ( " V a l u e o f P i : %.10 f \n" ,
3.1415926);
}

Ce fichier a subi des modifications de la part dun dveloppeur dans son rpertoire de
travail, et en mme temps de la part dun autre dveloppeur distant qui a communiqu ses
modifications personnelles dans le dpt. Au final, la situation est la suivante :
11

 Rvision distante (code.depot.c) :

1
2

#i n c l u d e <s t d i o . h>
#i n c l u d e <s t d l i b . h>

5
6
7

1
2

#i n c l u d e <s t d i o . h>
#i n c l u d e <math . h>

3
4

Fichier local (code.local.c) :

i n t main ( v o i d ) {
/ P r i n t t h e v a l u e o f p i /
p r i n t f ( " V a l u e o f P i : %.10 f \n " ,
3.1415926);

4
5
6
7

i n t main ( v o i d ) {
p r i n t f ( " V a l u e o f P i : %.10 f \n" ,
4 a t a n ( 1 ) ) ;
}

r e t u r n ( EXIT_SUCCESS ) ;

9
10

Manifestement, ces deux fichiers sont dans des tats diffrents. Une manire de reprsenter les diffrences entre ces deux versions consiste utiliser la commande diff entre les
deux fichiers avec la commande suivante : diff u code.depot.c code.local.c >diff.txt
Le rsultat obtenu est le fichier diff.txt suivant :
1
2
3
4
5
6

code . d e p o t . c
+++ code . l o c a l . c
@@ 1 , 1 0 +1 ,7 @@
#i n c l u d e <s t d i o . h>
#i n c l u d e <s t d l i b . h>
+#i n c l u d e <math . h>

7
8
9
10
11
12
13
14
15

i n t main ( v o i d ) {
/ P r i n t the v a l u e of p i /
p r i n t f ( " V a l u e o f P i : %.10 f \n " ,

3.1415926);

r e t u r n (EXIT_SUCCESS ) ;
+
4 atan ( 1 ) ) ;
}

Ce fichier reprsente les diffrences entre les deux codes. Les deux premires lignes
indiquent quels sont les fichiers dont on inspecte les diffrences, et quel symbole leur est
associ (ici + pour le fichier code.local.c et - pour le fichier code.depot.c). Les diffrences entre les deux fichiers sont alors listes sous la forme suivante :
Ligne de localisation (ligne 3) :
@@ 1,10 +1,7 @@
Cette ligne permet de localiser lendroit o se situe la diffrence. Ici, elle se situe
entre les lignes 1 et 9 du fichier -, et entre les lignes 1 et 6 du ficher +.
Lignes prcdes dun + ou dun - (lignes 5, 6, 9, 11, 12, 13, 14) :
Ces lignes sont les lignes prsentes dans un seul des deux fichiers.
Lignes non prcdes dun symbole (lignes 4, 7, 10) :
Ces lignes sont les lignes communes aux deux fichiers.
12

Si lon possde le fichier diff.txt, il est alors possible de passer dune version lautre
du fichier code.c en utilisant la commande patch (loption -b permet de faire un fichier
de sauvegarde) :
pour faire passer le fichier de dpt la version locale :
pour transformer la version locale en celle du dpt :

patch code.depot.c diff.txt

patch R code.local.c diff.txt

Cest le principe la base du systme de fichiers utilis par Subversion : ne stocker que
les diffrences entre les rvisions du code. Cest aussi le mcanisme la base du processus
de gestion des conflits de Subversion.
Remarque : la commande svn diff permet dafficher les diffrences entre les fichiers actuellement dans le rpertoire de travail et une rvision donne lintrieu du dpt, voire entre
deux rvisions du dpt.

6.2

Apparition dun conflit

Le scnario dapparition dun conflit le plus courant est le suivant : aprs avoir travaill
sur les fichiers dans le rpertoire local, lopration de commit renvoie un message derreur
annonant que les fichiers locaux sont prims (out of date) 2 . Cela signifie que la version
locale est diffrente de la version distante. La commande update affiche alors le statut
suivant pour un fichier :
% svn update
C
code . c
Updated t o r e v i s i o n 2 .

La lettre C indique quil existe un conflit pour le fichier code.c. De plus, Subversion a
cr un certain nombre de fichiers dans le rpertoire de travail, savoir :
code.c.mine : la version locale avant mise jour ;
code.c.rOLD : la rvision du fichier avant les modifications locales ;
code.c.rNEW : la rvision du fichier la plus jour.
En plus de cela, Subversion a ajout un certain nombre de modifications au fichier initial :
2. Subversion privilgie systmatiquement la version du dpt par rapport la version locale.

13

1
2
3
4
5
6

#i n c l u d e
<<<<<<<
#i n c l u d e
=======
#i n c l u d e
>>>>>>>

<s t d i o . h>
. mine
<math . h>
<s t d l i b . h>
. r2

7
8

Fichier conflictuel :
(code.c)

9
10
11
12
13
14

i n t main ( v o i d ) {
/ P r i n t t h e v a l u e o f p i /
p r i n t f ( " V a l u e o f P i : %.10 f \n " ,
<<<<<<< . mine
4 atan ( 1 ) ) ;
=======
3.1415926);

15
16
17
18

r e t u r n ( EXIT_SUCCESS ) ;
>>>>>>> . r 2
}

Ces modifications peuvent se regrouper en blocs (chunks) dlimits par :

Marqueurs de dbut (lignes 2,11) :
<<<<<<<.mine
Puis viennent les lignes de code modifies localement, suivies par :
=======
Lignes de sparation (lignes 4, 13) :
Ensuite se trouvent les lignes de code modifies dans le dpt, termines par :

Marqueurs de fin (lignes 6, 17) :

6.3

>>>>>>>.r2

Rsolution du conflit

Tant que le conflit nest pas rsolu, Subversion ne permettra pas denvoyer le fichier
dans le dpt. Afin dliminer le conflit, il est ncessaire de replacer les donnes lintrieur
du rpertoire de travail dans un tat propice un svn commit. Pour ce faire, il existe plusieurs
solutions :
1. Recopier lun des fichiers code.c.rOLD ou code.c.rNEW sur le fichier code.c. Naturellement, ceci supprimera toutes les modifications locales.
2. Grer les conflits la main : ceci consiste modifier le fichier code.c de manire
obtenir une version finale qui rassemble lensemble des modifications du code. Ce
travail est facilit par le fait que les diffrences entre les deux fichiers sont encadres
par les caractres <<<<<<< et >>>>>>>, et les deux versions sont spares par =======.

14

1
2
3

#i n c l u d e <s t d i o . h>
#i n c l u d e <math . h>
#i n c l u d e <s t d l i b . h>

4
5

Fichier final :
(code.c)

6
7
8

i n t main ( v o i d ) {
/ P r i n t the v a l u e of p i /
p r i n t f ( " V a l u e o f P i : %.10 f \n " ,
4 atan ( 1 ) ) ;

r e t u r n (EXIT_SUCCESS ) ;

10
11

Lorsque lon a obtenu une version finale correcte, la rsolution du conflit se fait laide
de la commande : svn resolved code.c . Cette commande supprime les fichiers prcdemment
rajouts 3 , et prpare le rpertoire de travail pour permettre ensuite de transmettre les
modifications. Si aucune autre modification conflictuelle na t apporte au dpt entre
temps, la commande svn commit peut alors sexcuter sans encombres.

7
7.1

Complments
Ignorer des fichiers

Dans un rpertoire de travail, il existe des fichiers qui sont gnrs naturellement mais
qui nont pas vocation tre mis sous contrle de version. Un exemple naturel est celui
des excutables lorsque lon gre le code source dun programme. Nanmoins, il nest pas
pratique de les supprimer avant chaque commit du code.
La bonne solution consiste demander Subversionde les ignorer. Pour cela, chaque
rpertoire est configurable laide de la commande svn propedit svn:ignore . . Cette commande
ouvre un fichier dans un diteur de texte, fichier dans lequel il est possible dinsrer une
liste de patterns de fichiers ignorer. Pour un programme compil en C, il est par exemple
intressant dajouter la ligne " . o " dans la liste des fichiers ignorer.

7.2

Crer des tags et des branches

Au cours dun dveloppement logiciel, certaines situations demandent mettre lensemble du code dans un tat particulier. Lexemple concret est celui dun dlivrable (release), pour lequel le code doit vrifier des contraintes dutilisabilit, de stabilit, de documentation . . .Il est possible de fixer certaines rvisions comme tant ddies ces releases,
mais alors il nest plus trs pratique dy accder.
3. Attention : lors de lapplication de cette commande, Subversion ne vrifie pas si le fichier contient
encore des modifications faire ou pas.

15

La bonne pratique pour un dpt Subversion consiste le dcouper la racine en trois

sous-rpertoires diffrents :
trunk/
tags/
branches/

Le rpertoire trunk contient tout le code actuellement en dveloppement. Si jamais

lon dsire faire une sauvegarde de ltat courant du code, il suffit de crer une tiquette
(tag) dans le rpertoire tags en utilisant la commande svn copy . Par exemple, depuis le
rpertoire racine :
% s v n copy t r u n k t a g s / r e l e a s e1 . 0

Le fait dutiliser la commande svn copy permet Subversion de ne pas recopier entirement
les fichiers, mais simplement un identifiant les reliant leur rvision dans le rpertoire
trunk. Par convention, on ne fait pas dautre commit dans un tag aprs lavoir cr.
Le rpertoire branches fonctionne quant lui de manire similaire, mais permet de crer
une nouvelle branche de dveloppement du code diffrente de trunk. Cette branche peut
vivre une vie indpendante du rpertoire principal, quitte tre ultrieurement fusionne
(merged) avec le code initial en utilisant la commande svn merge :
% s v n merge b r a n c h e s / b r a n c h 1 t r u n k r 3 :HEAD

Remarquer que les fusions de code amnent souvent rsoudre des conflits.

Bibliographie
La documentation de Subversion, accessible lURL suivante :
http://svnbook.red-bean.com/en/1.5/index.html.
Le livre correspondant, Version Control with Subversion
par C Pilato, Ben Collins-Sussman, et Brian Fitzpatrick, aux ditions OReilly.

A voir aussi . . .
Dautres systmes de gestion de versions :
CVS :
Git :
Bazaar :

http://www.nongnu.org/cvs/
http://git-scm.com/
http://bazaar.canonical.com/en/
16