IMB > cellule > Environnement informatique > Travail collaboratif

Emploi du logiciel Subversion

[sommaire]
Cet article détaille l’emploi du logiciel Subversion.

DÉPÔT désigne le répertoire central contenant les documents partagés (programmes par ex.),
sur une machine serveur distante, et COPIE désigne une copie locale de ce répertoire, en cours de modification sur votre ordinateur.

Subversion permet de faciliter la gestion d’une telle structure de partage de travail.

On décrit ici le cas où certains utilisateurs possèdent les permissions étendues pour gérer le dépot, ils seront désignés par le terme d’administrateur du dépot. Eux seuls ont le droit d’ecrire dans le dépot.

On se place aussi dans le cas où Subversion est déjà installé, et le dépôt est créé (mais non rempli).

Actions de base avec Subversion

Les actions sur le dépôt peuvent se regrouper en 5 classes :
– création du dépôt initial (administrateur seulement)
– obtention du dépôt initial
– resynchronisation d’une copie locale avec le dépôt LOCALEMENT
– modifications d’une copie locale
– resynchronisation d’une copie locale avec le dépôt DANS LE DÉPÔT

ADRS désigne l’URL du dépot : par exemple : https://svn.math.cnrs.fr/le_projet

ATTENTION : les commandes globales "update", "commit", "checkout" doivent être effectuées
dans le répertoire racine de la copie locale, pas dans un des sous-répertoires

I. Création du dépôt initial

L’administrateur du dépôt, après avoir demandé les ouvertures du dépot et des comptes pour les utilisateurs autorisés à accéder à ce dépôt, se place dans un répertoire s’appelant "le_projet" qui contient tout ce qu’il souhaite déposer initialement, et exécute la commande :

svn import ADRS

II. Obtention du dépot initial

Dans le répertoire où il souhaite placer sa copie de travail, l’utilisateur exécute la commande :

svn checkout ADRS

cela lui crée un répertoire "le_projet", qui contient, outre les fichiers courant du dépot central, des répertoires .svn qui doivent en aucune façon être modifiés ou retirés par l’utilisateur ; c’est Subversion qui les gère.

III. Synchronisation d’une copie locale avec le dépôt, LOCALEMENT

Toute session de travail sur la copie locale devrait commencer par la resynchronisation éventuelle des modifications apportées au dépôt central (par exemple l’extension de fonctionnalités, la correction de bogues, le travail d’un collègue, ...)
avec la copie locale.

Cela COMMENCE par commande suivante :

svn update

La liste des fichiers modifiés est fournie, les codes suivants sont les plus fréquents (liste non exhaustive) :
– A : ajouté
– D : retiré
– U : contient une ou des modifications importées du dépôt central
– G : fusionné
– C : contient une ou des modification(s) locale(s) en conflit avec les modifications apportées au dépot

Le mécanisme de fusion des modifications est automatisé.
Il fonctionne schématiquement comme suit :
Notons "A" la version du dépôt central qui a servi à obtenir la version de départ de la copie locale (cet ensemble A est changé à chaque fois qu’un svn update a lieu) ;
Notons "B" l’ensemble des modifications entre la version "A" et la version courante sur le dépot central ;
Notons "C" l’ensemble des modifications entre la version "A" et la version courante de la copie locale ;
Alors après le "svn update", la copie locale contient "A" + "B" + "C".

2 cas peuvent se produire pour un fichier modifié :
– l’intersection de B et C est vide, Subversion considère que le fichier est maintenant à jour (code G) ;
Remarque : cela n’est peut être pas le cas, c’est à l’utilisateur de vérifier, optionnellement.
– l’intersection de B et C est non vide, il y a conflit, code C
l’utilisateur DOIT alors terminer à la main, via son éditeur, la modification du fichier (description plus bas)
puis signaler à Subversion que le problème est réglé :
svn resolved fichier

Les conflits dans un fichier sont signalés de la façon suivante :

IV. Modifications d’une copie locale

IV.1 Modifications

On peut :
– ajouter des fichiers :
svn add fichier
– retirer des fichiers :
svn delete fichier
– renommer des fichiers :
svn move ancien nouveau
– copier des fichiers
svn copy ancien nouveau
– créer des répertoires :
svn mkdir repertoire
– modifier des fichiers :
vi fichier ...
emacs fichier ...

Les modifications de structure dans la copie locale doivent absolument être faites via des commandes svn ;
un "mkdir" ne sera pas pris en compte par Subversion, l’ajout d’un nouveau fichier, en particulier par création directe
à partir de l’éditeur, ne sera pas pris en compte sans un "svn add ...".

IV.2 Revue des modifications

Avant de proposer les modifications à l’administrateur du dépot, il est souhaitable d’effectuer les actions suivantes :
– a) vérifier que tout compile, que les tests de base fonctionnent
– b) vérifier l’état de ce qui est proposé :
svn status
svn status -v
svn status -v -u
par ordre croissant de détails fournis

Les fichiers de la copie (et/ou du dépôt dans le dernier cas) sont éventuellement précédés de marqueurs ;
le premier marqueur peut être (liste non exhaustive) :
– A : à ajouter
– D : à retirer
– M : contient une modification locale
– C : contient une ou des modification(s) locale(s) en conflit avec les modifications apportées au dépot

le second marqueur indique par une ’*’ que le fichier doit être mis à jour localement (une version modifiée depuis la dernière récupération

– c) faire une revue de ce qui a été modifié :
dans le répertoire racine de la copie locale, faire la commande :
svn diff >patch_file

puis éditer le fichier patch_file, qui est au standard "unified diff format" :

IV.3 Envoi des modifications à l’administrateur du dépôt

Envoi du fichier de patch (patch_file) à l’administrateur du dépôt.

V. Resynchronisation d’une copie locale avec le dépôt, DANS LE DÉPÔT

L’administrateur, à réception d’un patch, peut l’appliquer à sa propre copie locale du dépot :

patch -p0 <patch_file

La résolution des conflits, signalés par des "Hunks", s’exécute de la même façon que décrite précédemment pour les conflits lors des "update".

Ensuite il propage cette modification au dépot par

svn commit

VI. Quelques rattrapages d’erreur

VI.1 Destruction locale d’un répertoire ou d’un fichier

svn update nom_du_repertoire_ou_du_fichier

VI.2 Destruction d’un répertoire .svn

– a) Faire une copie locale du répertoire qui contenait ce .svn dans "autre"
– b) svn update nom_du_repertoire
– c) remettre en place le reste du répertoire à partir de "autre"

VI.3 Interruption d’une commande svn (par crash machine, crash réseau ou tout autre problème.)

svn cleanup

relance les commandes qui étaient restées en attente non finies