Utilisation de Subversion

Introduction du cours

Bienvenue dans ce cours sur l'utilisation basique du logiciel de versionning Subversion, considéré comme le successeur de CVS (Concurrent Versions System). Très basiquement, Subversion (que je surnommerai SVN dans le reste de ce tuto) est un logiciel permettant une gestion des versions.

Je peux comprendre que l'expression "gestion des versions" puisse paraître obscure à certains, mais tout va s'éclaircir une fois le premier chapitre lu et compris !

Je vais essayer de rester le plus clair possible, tout en n'étant pas exhaustif sur les possibilités que nous offre SVN (il faudrait un big-tuto d'une vingtaine de chapitres pour cela).

Je conseillerais à ceux à qui ce tuto va plaire, qui voudront en savoir plus et qui ne sont pas réfractaires à l'anglais d'aller lire le book SVN, très complet (360 pages) et qui vous expliquera toutes les facettes du logiciel, aussi bien l'utilisation que l'administration du serveur.

Finalement, je traiterai le côté ligne de commande de SVN, je n'aborderai nulle part les diverses interfaces graphiques qui existent, tel TortoiseSVN pour Windows par exemple.

Bonne chance !

Présentation de SubversionQu'est-ce que Subversion ?

Comme dit dans l'introduction, Subversion est un logiciel de contrôle de versions. En langage clair, il s'agit d'un logiciel qui enregistre tous les états d'une arborescence au fil du temps (par arborescence, j'entends à la fois la structure des dossiers, mais également le contenu des fichiers). C'est de là que vient le terme de "version" : le logiciel surveille les différentes versions d'un répertoire.

Subversion (tout comme son prédécesseur, CVS) est principalement utilisé dans le cadre du développement de logiciels, et j'espère qu'avec le paragraphe précédent, vous comprendrez rapidement pourquoi. Le développement d'un logiciel est composé de multiples modifications de fichiers au fil du temps ; SVN permet d'enregistrer tous ces changements pour, par exemple, pouvoir avoir une trace explicite et exhaustive de tous les changements faits au code source, ou pouvoir revenir au code tel qu'il était il y a 5 mois.

Basiquement, comment fonctionne Subversion ?

Sans rentrer dans les détails, dites-vous que Subversion réalise des snapshots de l'arborescence à chaque changement qui lui est fait. C'est-à-dire qu'il garde en mémoire tous les changements faits à l'arborescence au fil du temps.

Imaginez que vous faites un dessin sur une feuille de papier, et qu'à chaque fois que vous ajoutez une partie sur le dessin, vous photocopiez votre feuille et la rangez dans une archive. C'est exactement le même principe avec SVN.

Maintenant, imaginez qu'à la place de photocopier votre dessin, vous le scannez pour le mettre à disposition d'autres dessinateurs dans le monde via le réseau Internet, eh bien là vous avez tout à fait compris le principe de SVN. Il permet à plusieurs développeurs à travers le monde de travailler simultanément sur le même code source, grâce à différents procédés que nous mettrons en lumière plus loin.

Nota bene : je parle depuis tout à l'heure de code source, mais le principe est le même avec des fichiers binaires (images, vidéos, etc.).

Pardon, mais si SVN garde une copie de mon dessin à chaque changement, mon archive risque de devenir relativement grosse à la longue, non ? :euh:

Merci lapin malin, en effet sur mon exemple ça serait le cas, mais Subversion est plus intelligent que ça et, au lieu de "photocopier" comme un bourrin toute l'arborescence à chaque fois, il analyse tranquillement ce qui a changé et réalise ce que j'appellerais joliment un snapshot différentiel (je ne sais pas si ce terme existe, mais c'est la classe !). En gros, il ne sauvegardera que ce qui a changé d'un snapshot à l'autre, et tout de suite la masse de données à enregistrer est beaucoup moins importante, ce qui soulage à la fois les disques durs et les connexions.

Une histoire de révisions

Subversion, pour organiser les données qu'il enregistre, se base sur un système de révisions. Explicitons rapidement ce terme : pour SVN une révision correspond à un état de l'arborescence à un moment précis du temps. La révision 13 pourra être un snapshot du 22 juillet et la révision 14 le snapshot suivant.

SVN utilise un système de révisions global, c'est-à-dire qu'une révision correspond aux changements effectués sur l'arborescence entière depuis la dernière révision.

La première révision est la révision 0 (ou r0) et chaque nouvelle révision incrémente de 1 le nombre (la deuxième révision sera la révision 1 et ainsi de suite).

Dépôt et copie locale

Un système utilisant Subversion est à diviser en deux parties distinctes, le dépôt (ou repository en anglais) et la copie locale (ou local copy chez Shakespeare). J'utiliserai à partir de maintenant ces termes à la place d'arborescence, qui est trop long et trop importun à écrire.

Dépôt

Le dépot est le côté serveur d'un système utilisant Subversion, c'est "l'archive" dans laquelle seront envoyées les modifications faites à l'arborescence (appelées changeset* d'ailleurs). Celui-ci peut se trouver sur un serveur distant, sur un serveur situé dans le réseau local ou même sur votre propre machine.

* : un changeset est un ensemble de modifications qui formeront une nouvelle révision.

Un utilisateur "basique" (entendre un non-administrateur) de Subversion n'a pas besoin de savoir ce qui se passe dans le dépôt, ce sont les mécanismes internes du processus.

Copie locale

Voilà quelque chose qui concerne beaucoup plus les utilisateurs. Une copie locale est une copie de l'état du dépôt à un moment précis, située sur l'ordinateur d'un des utilisateurs. Reprenons mon exemple du dessin, ce que le dessinateur a est une copie locale ; et ce qu'un autre dessinateur va récupérer du dépôt sera aussi une copie locale.

C'est sur la copie locale que l'utilisateur travaille.

Actions de base sur SubversionCréer un dépôt

Une fois Subversion installé et en état de marche, la première étape est de créer un dépôt. C'est la seule action d'administration que nous verrons (très rapidement) pour les besoins du tuto. Je suis sous Linux et toutes les actions se produiront à l'intérieur de /home/apognu/svn. Pour créer un dépôt, ouvrez donc un terminal ou une invite de commande et tapez :

svnadmin create repository

Cela a eu pour conséquence d'utiliser le programme svnadmin pour créer (sous-programme create) un dépôt dans le répertoire repository.

Un rapide coup d'oeil dans le répertoire sus-cité nous fait voir son affreux contenu :

conf  dav  db  format  hooks  locks  README.txt

Et encore, je ne suis pas allé lister les répertoires ; comme je l'ai dis plus haut, l'utilisateur lambda doit faire abstraction du contenu du dépôt, celui-ci doit être aussi important pour vous que la première représentation sur scène de Mireille Mathieu (j'emploie les grands moyens) !

Nous voilà en possession d'un dépôt vide, maintenant peuplons-le !

Checkout

Du côté utilisateur, la première chose à faire est la création de sa copie locale. C'est à cela que sert le checkout. Basiquement, il crée une copie locale en téléchargeant le contenu du dépôt sur votre disque. Habituellement, le checkout est à faire une seule fois car avoir deux copies locales est rarement intéressant (quoiqu'il peut l'être, mais on n'abordera pas ça ici) et parce que le checkout télécharge à chaque fois tout le contenu du dépôt ce qui dans certains cas peut être assez lourd pour les connexions Internet.

Un dépôt est toujours appelé par son adresse sous forme d'URL, cela peut être :

• file:///chemin/vers/le/dépot ;

• http://server.web.com/repository ;

• svn://server.svn.com/repository ;

• etc.

Dans notre cas le dépôt est vide et situé sur notre machine, donc pas de problème de poids, procédons procédons ; tapez ceci dans un terminal ou une invite de commande :

svn checkout file:///home/apognu/svn/repository localcopy

Basiquement, on demande ici à SVN de procéder au checkout du dépôt situé dans le dossier /home/apognu/svn/repository et de créer la copie locale dans le dossier localcopy.

Si on ne précise pas, Subversion réalise toujours le checkout depuis la dernière révision existante (appelée révision HEAD), soit la dernière version du dépôt.

Voilà ce qu'on a :

Checked out revision 0.

Parfait.

Un coup d'oeil dans le dossier localcopy ne nous montre rien sauf (si on a activé l'affichage des fichiers et dossiers cachés) un dossier .svn. Tout comme le dépôt, ce dossier sert aux mécanismes de Subversion et n'est d'aucune utilité pour l'utilisateur que vous êtes. ;)

Update

L'action update de SVN est dans la lignée du checkout, dans le sens où elle télécharge des données depuis le dépôt, sauf que celle-ci ne créé pas de copie locale.

Lorsqu'un utilisateur lance une update de sa copie locale, Subversion va comparer cette dernière avec le contenu du dépôt et si celui-ci est à une révision supérieure que celle de la copie locale, SVN va télécharger le différentiel entre les deux.

Un exemple concret : vous êtes deux utilisateurs sur un même dépôt, à un temps t vous êtes à la révision 4, seulement là vous partez en vacances. Pendant votre absence votre collègue continue à travailler, et le dépôt passe à la révision 7. À votre retour vous avez envie de récupérer ce qui a changé depuis votre départ, donc vous lancez une update, votre copie locale est mise à jour de la révision 4 à la révision 7. Vous pouvez de nouveau travailler.

Il est très important d'avoir le réflexe de lancer des updates relativement souvent, pour toujours avoir une copie locale à jour. Nous verrons dans les sous-parties suivantes les conséquences sur le travail que pourrait avoir un oubli.

Pour réaliser une update, en imaginant que vous êtes dans /home/apognu/svn et que la copie locale se trouve dans un sous-répertoire localcopy, lancez simplement la commande :

svn update localcopy

Si vous vous trouvez déjà dans le répertoire localcopy, vous pouvez omettre de le préciser dans la ligne de commande.

Il est à noter que update ne téléchargera pas toujours des fichiers, il peut arriver (et plutôt souvent) que votre copie locale soit déjà à jour, et par conséquent le différentiel est nul : rien n'est téléchargé. Souvent, l'update est une mesure de précaution au cas où l'état du dépôt aurait changé.

Commit

Pour partir simplement, le commit est l'action contraire de l'update et en même temps sa soeur. Update et commit seront les deux actions que vous utiliserez le plus souvent dans votre utilisation de Subversion. En gros, commit compare les modifications que vous avez faites sur votre copie locale avec l'état du dépôt, puis envoie le différentiel du changeset à celui-ci, créant par la même occasion une nouvelle révision.

Pour réaliser un commit, créons déjà un fichier file.txt dans notre copie locale en lui mettant un contenu. Ensuite, deux étapes sont à réaliser. Tout d'abord, il faut versionner le fichier, en gros dire à SVN qu'il s'agit d'un fichier à prendre en compte dans le contrôle des versions ; et ensuite, lancer le commit de la copie locale. Voilà comment procéder (toujours dans /home/apognu/svn) :

svn add localcopy/file.txt svn commit localcopy

Voilà ce qui apparaît en sortie :

A         localcopy/file.txt   Adding         localcopy/file.txt Transmitting file data . Committed revision 1.

La première ligne indique que le fichier localcopy/file.txt a été prévu pour être ajouté au dépôt au prochain commit (signification de la lettre A), et les trois dernières symbolisent le commit. Comme prévu celui-ci ajoute le fichier, il transmet ensuite le différentiel puis nous informe que la révision 1 vient d'être créée.

Supprimer, copier, déplacer

Seul petit hic : pour déplacer, supprimer ou copier des fichiers ou dossiers, il ne suffit pas d'utiliser les fonctions fournies avec son système d'exploitation et de faire son commit, il faut utiliser les trois sous-programmes move, delete et copy.

Déplacer revient à copier un fichier puis à le supprimer de son emplacement d'origine.

Voici les trois commandes :

svn move FICHIER DESTINATION svn copy FICHIER DESTINATION svn delete FICHIER

Maintenant les fichiers sont dans une sorte de file d'attente où vont tous les fichiers "modifiés" en attendant le commit. Rappelez-vous qu'aucune modification n'est appliquée tant que le commit n'est pas lancé.

Exercices

À partir de là, vous connaissez les trois actions de base de SVN (checkout, update et commit), pour vous entraîner vous pouvez simuler l'utilisation du dépôt par plusieurs personnes, en répétant les opérations checkout / modification / commit / update, etc.

Pour commencer cela, vous pouvez dès lors créer une seconde copie locale, qui cette fois au lieu d'être à la révision 0 sera à la révision 1. Ensuite modifiez le fichier sur la copie locale 1, commitez, puis updatez la copie locale 2.

Entraînez-vous comme cela un petit temps pour avoir bien en tête le processus. Avec un peu de (mal)chance, vous tomberez sur un bel os que je vous expliquerai dans la prochaine sous-partie.

Conflits, merging et lockConflits

La première notion à assimiler dans cette sous-partie est celle de conflits. D'après un dictionnaire, un conflit est un choc, une lutte, une rivalité. Eh bien dans Subversion, c'est exactement la même chose : il y a une rivalité entre les utilisateurs à propos des fichiers versionnés. Comment cela ? me direz-vous. Comme ceci : vous répondrai-je.

Supposons deux utilisateurs (Joe et Bobby) devant travailler en même temps sur un fichier README, et que leurs modifications sur ce fichier soient prises en compte par SVN, on peut dès lors dresser le scénario suivant :

• Joe et Bobby font un checkout sur du dépôt et obtiennent à la révision 1 le fichier README ;

• ils commencent tous les deux à éditer le fichier ;

• Joe, content de lui, fait un commit avec ses modifications, le fichier est uploadé et la révision 2 est créée ;

• Bobby, une fois ses propres modifications terminées, va vouloir en faire un commit, sauf que là c'est le drame, un message...