Subversion

La SVN (petit nom de SubVersion) a pour but de remplacer la CVS. Pour l'utilisateur lambda, l'utilisation en est quasiment identique, mais les fonctionnalités supplémentaires sont tout de même non négligeables.

Qu'est-ce que c'est SVN ?

Gestion de versions concurrentes

Comme l'indique le nom du très cher ancêtre de SVN, Subversion est un système de gestion de version concurrente. C'est à dire un outil qui permet de programmer à plusieurs sur un projet. Chaque développeur pour travailler sereinement sur sa copie du projet car SVN se chargera de la fusion des modifications apportées par chacun des utilisateurs.

Un outil comme SVN s'avère donc un très bon moyen de centraliser le développement d'un programme. Ca permet en effet de conserver de manière sûre une copie du projet sur le serveur avec la possibilité d'organiser le développement, la certitude de pouvoir retrouver les versions entérieures grace au principe de versionning et de stockage des modifications sous forme de patchs.

Structure d'un projet sur la SVN

Les projets de développement (donc on exclu les modules de configuration) ont tous à peu près la même structure. Cette structure reflette le développement :

• trunk : la branche principale du projet.
• branches : répertoire qui contient les autres branches sous la forme de sous répertoire
• tags : répertoire que contient les versions tagguées sous la forme de sous répertoire.

Prennons l'exemple concret de l'arborescence du projet qRezix :

svn://swl/qrezix/
  + trunk
  + branches
  |   + qrezix--qt4
  |   + qrezix--release--1.2
  |   + qrezix--release--1.6.2
  |   \ qrezix--release--1.6.3
  \ tags
      + qrezix--1.3
      + qrezix--1.6.2
      + qrezix--1.6.2-rc1
      + qrezix--1.6.2-rc2
      \ qrezix--1.6.3

Utilisation de svn

SVN s'utilise aussi simplement que CVS avec cependant quelques différences notables, principalement la syntaxe différente pour un checkout.

La SVN gère également des branches qui permettent de continuer à développer sur une branche 'instable' pendant qu'on décide de 'releaser' une version stable.

Chaque projet est appelé un module.

Récupérer un module

La commande diffère selon que le module est accessible via le svnserver ou svn+ssh :

en svn :

svn co svn://[user@]skinwel/nom_du_projet/partie_a_co [dest_locale]

en http :

svn co http://[user@]skinwel/nom_du_projet/partie_a_co [dest_locale]

en svn+ssh :

svn co svn+ssh://user@skinwel/home/svn/nom_du_projet/partie_a_co [destination]

Pour la plupart des utilisateurs la branche à récupérer sera trunk, mais ça peut être aussi branches/nom_de_la_branche, ou Tag/nom_du_tag... ou n'importe quel sous répertoire ou fichier...

Récupérer les modifications des autres

svn up [$fichiers$]

MEt à jour votre copie locale, en prenant en compte les dernières versions des fichiers spécifiés. Si aucun fichier n'a été modifié sur le serveur, le programme mettra à jour tout le répertoire et ce récursivement. En cas de modification conflictuelle entre celle du serveur et celle de la copie locale, il faut résoudre les conflits.

Lors de l'update, une liste de noms de fichier s'affiche précédés par une lettre. Ces fichiers sont les fichiers affectés par l'update, et chaque lettre a une signification particulière :

• A : Le fichier a été ajouté en local
• M : Le fichier est localement modifié (le contenu n'est pas touché par SVN)
• U : Le fichier est mis à jour
• G : Le fichier est patché (le fichier est modifié à la fois localement et sur la SVN et les modifications de la SVN sont fusionnées à la copie locale).
• C : La copie locale du fichier entre en conflit avec la version du serveur.
• I : Le fichier est ignoré
• D : Le fichier est supprimé
• ! : Le fichier est manquant
• ? : Le fichier n'est pas géré par SVN

Valider ses modifications

svn ci [$fichiers$]

Cette commande envoie au serveur les fichiers modifiés. Si aucun conflit n'est détecté la modification est validée.

Il faut toujous updater la copie locale avant de commiter ses modifications.

Avant d'envoyer le commit, SVN vous demandera un message expliquant le travail effectué. Ce message est suivi de la liste des fichiers ave les tags comme expliqué dans la section précédente. Dans le pire des cas, l'utilisation de la commande diff permet de voir l'ensemble des modifications :

svn diff [$fichiers$]

Annuler ses modification

svn revert [$fichiers$]

Supprime toutes les modifications apportées au fichier spécifié depuis le dernière update.

Cette commande est la seule qui ne soit pas récursive avec SVN. Pour utiliser la commande sur un répertoire de façon récursive, il faut ajouter l'option -R

svn revert -R [$répertoire$]

Ajouter un fichier/répertoire

svn add $fichiers$
svn mkdir $repertoire$

Ajoute les fichiers spécifiés à la CVS. Les répertoires sont ajoutés immédiatement, par contre il faut commiter les fichiers ajoutés pour valider l'ajout. L'utilisation de mkdir nécessite que le répertoire n'existe pas encore.

Supprimer un fichier/répertoire

svn remove $fichiers$
svn rmdir $repertoire$

Supprime un fichier du module. La suppression sera effective après un commit.

Déplacer un fichier/répertoire

svn move $fichier$ $destination$

Déplace le fichier ou répertoire vers sa destination. Se comporte comme mv.

Créer une version tagguée

Une version tagguée est un snapshot du projet, une photographie à un instant présent. Sur svn, un snapshot est donc une copie de l'instant présent dans l'arborescence. Le plus souvent on utilise un répertoire tag :

svn copy trunk tag/$montag$

Créer une branche

De la même manière que les tags, les branches sont une séparation du projet. C'est donc également une copie, mais celle-ci destinée à évoluer... On stock habituellement les branches dans un répertoire branches :

svn copy trunk branches/$mabranche$

Backporter

Backporter consiste à transposer les modifications d'une branche sur une autre.

svn merge -r version1:version2 $brancheorigine$ [$branchedest$]
svn ci

Cette syntaxe applique les modifications de la branche $brancheorigine$ effectuées entre la révision version1 et version2 (dans cet ordre là) ) la branche branchedest. Si branchedest n'est pas spécifié, l'application sera réalisée sur le répertoire courant.

Attention à mettre version1 et version2 dans le bon sens, sinon on supprime les modifications au lieu de les appliquer.

Résoudre les conflits

Après un update il est possible que certaines modifications locales soit en conflit avec les modifications des autres développeurs (dans le cas en particuliers ou une même ligne a été modifiée). Il faut alors faire une fusioin à la main, c'est la résultion du confit.

Pour ceci il faut éditer le fichier concerné. Les points conflictuels sont facilement identifiables car délimités par :

=========== .mine
... ma version du code
===========
... la version SVN du code
=========== .r849

Il suffit alors de choisir quelles modifications doivent être concervées... et d'enregister le fichier. Il ne faut tout de même pas oublier de marquer le conflit comme résolu :

svn resolved $fichier$

Installation de la SVN sous Windows

Un bon client SVN sous Windows est TortoiseSVN qui s'intègre à l'explorateur Windows et permet de réaliser toutes les comamndes grace au menus contextuels associés aux répertoires.

Installation de SVN sous Mac OS X

Comme pour de nombreux packages portés depuis linux, fink est une solution relativement simple, même si elle n'a pas que des qualités. Vous pouvez installer fink depuis fink.sourceforge.net. Une fois fink installé, vous pouvez installer svn en entrant

fink install svn

dans une console. Il existe aussi des packages précompilés sur internet.

Il y a ensuite un certain nombre de client graphiques pour svn (comme svnX par exemple), si nécessaire, pour visualiser les évolutions du projet par exemple, ou bien voir sa structure.