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é supplémentaires sont tout de même non négligeables.

Configuration:Subversion (privé)

Qu'est-ce que c'est SVN ?

Gestion de concurrence de versions

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.

Ainsi, un exemple concret est 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 simplemennt que CVS avec cependant quelques différences notables, en particulier la checkout utilise une syntaxe différente

La SVN gère également des branches qui permette 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 [destination]

en http :

svn co http://[user@]skinwel/nom_du_projet/parti_a_co [destination]

en svn+ssh :

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

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

Récupérer les modifications des autres

svn up [$fichiers$]

Récupère la dernière copie des fichiers spécifiés. Si aucun fichier n'est récupérer, 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 local, il faut résoudre les conflits.

Lors de l'update, une liste de nom 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 est ajouté
• 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. Ce 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 conflictuel sont faiclement identifiables cas délimités par :

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

Il suffit alors de choisir quelle modification 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.