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.
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.
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.
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 :
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.
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.
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.
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.
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.
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 d'erreur lui dit qu'il ne peut pas le faire !
Comment cela se fait-il ? Rappelez-vous, je vous avais dit qu'il était important de toujours avoir une copie locale à jour, or celle de Bobby ne l'était plus au moment de son hypothétique commit : sa copie locale était encore à la révision 1 alors que le dépôt était à la révision 2. Par mesure de sécurité, Subversion bloquera le commit pour éviter qu'il ne détruise les modifications de Joe. Il y a conflit !
Mais alors, le travail du pauvre Bobby est réduit à néant ?
Que nenni ! Subversion propose plusieurs moyens de résoudre et prévenir les conflits, que nous allons étudier dans cette sous-partie.
Merging
Pour résoudre un conflit, Subversion propose une solution de merging, terme signifiant ici mélange. Basiquement, cela consiste en un mélange des deux fichiers pour en obtenir un nouveau. Il y a deux types de merging pour résoudre les conflits, les voici les voilà :
Merging "automatique"
Subversion étant un être doué d'intelligence, il est capable de réaliser certaines opérations tout seul comme un grand.
Reprenons notre exemple de conflit entre Joe et Bobby : ce dernier se retrouve comme un con avec son commit défectueux, la première chose à faire est un update, afin de mettre sa copie locale à jour. Pas de panique, cela ne supprimera pas ses modifications : SVN sait qu'il y a conflit, et va donc agir !
Le cas du merging "automatique" est efficace lorsque les modifications effectuées par les deux utilisateurs ne se "recoupent" pas, par exemple s'ils ont modifié chacun deux parties distinctes du fichier. Dans ce cas, Subversion repère ce non-recoupement et peut mélanger intelligemment les deux fichier. Voici une mise en pratique avec un fichier contenant "Bonjour !" avant toute modification :
Citation : Joe (commit réussi)
J'ajoute ce texte au dessus de bonjour...
Bonjour !
Citation : Bobby (commit foireux)
Bonjour !
Moi, je veux ajouter du texte en dessous !
Comme vous le voyez ici, les modifications de l'un n'annulent pas celles de l'autre, et elles peuvent être distinctement séparées. Donc lorsque Bobby fera son update, SVN laissera le fichier README contenant :
Citation : Bobby (après l'update)
Je rajoute ce texte au dessus de bonjour...
Bonjour !
Moi, je veux rajouter du texte en dessous !
Il suffit alors de faire son commit du fichier créé par Subversion pour le réussir et créer la révision 3 !
Merging "manuel"
Il arrive parfois (même plutôt souvent) que les modifications effectuées par deux utilisateurs se recoupent, et dans ce cas Subversion ne peut pas prendre le risque d'effectuer lui-même le merging. C'est donc à l'utilisateur responsable du conflit de le corriger lui-même ! Je vais reprendre l'exemple du book SVN qui est facile à comprendre.
Imaginez qu'un fichier versionné soit une liste de ce que deux collaborateurs veulent pour leurs sandwiches, voici ce fichier à la révision 1 :
Citation : Fichier à la révision 1
4 tranches de jambon 3 tomates 9 cornichons
Maintenant, imaginons que Joe aime la viande, et ajoute une tranche de jambon (il y en aura donc cinq), il commit, et juste après Bobby (toujours malchanceux avec ses commits), tente d'envoyer son commit pour les deux tranches de jambon supplémentaires :
Sending sandwiches.txt
svn: Commit failed (details follow):
svn: Out of date: 'sandwiches.txt' in transaction '5-1'
Il tente de faire son update comme la dernière fois, sauf que là ça ne fonctionne pas, et voilà avec quoi il se retrouve dans sa copie locale :
Décortiquons un peu cela ! sandwiches.txt.mine contient le fichier qu'il a tenté de commiter, sandwiches.txt.r4 contient le fichier à la révision précédente (avant tout changement donc) et sandwiches.txt.r5 contient le fichier avec les modifications de Joe. Mais ce qui est intéressant est le fichier sandwiches.txt, si on l'édite voilà ce qu'il y a dedans :
<<<<<<< .mine
6 tranches de jambon
=======
5 tranches de jambon
>>>>>>> .r5
3 tomates
9 cornichons
Et c'est là que vous prenez votre tube d'aspirine et que vous commencez à pleurer ! Sans raison, parce que ce n'est vraiment pas compliqué... Il y a deux choses à retenir, la signification des signes qu'on peut résumer à cela :
<<<<<<< .mine
CE QUE J'AI MODIFIE
=======
CE QUE L'AUTRE A MODIFIE
>>>>>>> .rX
Tout ce qu'il y a en dehors des signes est ce qui n'a pas été modifié. Il suffit ici de faire réfléchir un peu ses méninges : on sait qu'il y avait 4 tranches de jambon avant (le fichier sandwiches.txt.r4 en témoigne), Joe en demande une de plus, moi deux. Un peu de maths, ça fait qu'il en faut trois de plus. On retire donc les marques en laissant la ligne, mais en mettant sept tranches de jambon.
Tout ce qu'il nous reste à faire est de déclarer le conflit comme résolu, puis à réaliser le commit :
Resolved conflicted state of 'sandwiches.txt'
Sending sandwiches.txt
Transmitting file data .
Committed revision 6.
Le conflit a aussi été résolu, mais avec plus de peine.
Lock
Après avoir vu comment résoudre un conflit, j'espère vous avoir à vie dégouté de ces petites choses-là. Je vous ai déjà dit à plusieurs reprises dans ce tuto de faire des updates régulières pour essayer d'être à jour le plus souvent possible, mais cela ne suffira pas toujours. Il ne s'agit pas seulement de prier pour qu'un conflit ne se produise pas, il faut également les empêcher. L'expression mieux vaut prévenir que guérir prend ici tout son sens.
Bien sûr vous pourriez courir après vos collaborateurs pour leur dire que vous allez modifier ce fichier dans les prochaines heures, mais ce n'est ni pratique ni productif. Non, pour cela vous allez utiliser la fonction de lock de Subversion.
Là le nom est explicite, il s'agira de verrouiller un fichier pendant que vous l'utiliserez, pour être certain que personne ne sera en mesure de le modifier à son tour. Mais ici encore, l'adoption d'une routine, d'une procédure d'utilisation de Subversion est requise ! En effet, demander un lock sur un fichier avant modification doit devenir une habitude ! Cela permet deux choses : d'abord d'obtenir le lock, et donc que personne ne gâche notre boulot ; mais également de s'assurer que personne n'a pris de lock sur ce fichier, et donc qu'on n'est pas sur le point de gâcher le boulot de quelqu'un.
Le lock doit donc devenir une institution, que dis-je ? on doit vénérer le lock. Le lock est le patron, le lock c'est la vie, répétez après moi !
Pour demander un lock, entrez la commande suivante :
svn lock sandwiches.txt
Ce qui donne :
'sandwiches.txt' locked by user 'apognu'.
À partir de ce moment, n'importe qui demandant un lock sur ce fichier se verra gratifié d'un majestueux :
svn: warning: Path '/sandwiches.txt' is already locked by user 'apognu' in filesystem '/home/apognu/svn/repository/db'
Il est à noter que demander un lock sur un fichier situé dans une copie locale non à jour provoquera également un message d'erreur. Demander un lock permet aussi de s'assurer de travailler sur une base saine.
Surtout, ne pas oublier de déverrouiller le fichier une fois qu'on a fini de travailler dessus, grâce au sous-programme unlock :
svn unlock sandwiches.txt
Une fois compris le fait que le lock est le Bien, et pris l'habitude d'en demander un chaque fois que l'on désire travailler sur un fichier, le risque de création de conflits est minime, voire inexistant. Et ça c'est réjouissant !
Le premier sous-programme permettant de contrôler ses commit est status, celui-ci permet de fouiller la copie locale pour donner des informations sur ses éléments constitutifs (fichiers et dossiers). Appelée sans argument, elle affiche le(s) fichier(s) prévus pour modification au prochain commit, c'est-à-dire les fichiers ou dossiers modifiés, déplacés, supprimés, etc.
Si je modifie le fichier sandwiches.txt et que je lance :
svn status
Voilà ce qui s'affichera :
M sandwiches.txt
Le M signifie "modifié", on sait donc qu'au prochain commit les modifications apportées au fichier sandwiches.txt seront prises en compte. La lettre changera en fonction du type d'actions réalisées sur le fichier ou dossier. Vous pouvez trouver plus d'informations à ce sujet grâce à la commande svn help status.
En gros, cette commande vous donne une vue d'ensemble de ce que vous avez fait pour vous aider à vous représenter le commit qui va suivre.
Diff
Ça, c'est une sous-commande qu'elle est intéressante !
En gros, le principe reste le même que status : elle donne des informations sur les modifications effectuées sur la copie locale, mais cette fois-ci à une échelle plus petite. Elle va vous donner, pour chaque fichier modifié, un détail des ajouts, retraits et modifications apportés, à la ligne près.
Si j'ajoute une ligne au fichier sandwiches.txt, et que je lance svn diff, j'aurai cette sortie :
Index: sandwiches.txt
===================================================================
--- sandwiches.txt (revision 6)
+++ sandwiches.txt (working copy)
@@ -1,3 +1,4 @@
7 tranches de jambon
3 tomates
9 cornichons
+1 pot de mayonnaise
Dans ce capharnaüm, je vois qu'entre le fichier de la révision 6 et ma copie locale, il y a eu une ligne ajoutée (le signe + en début de ligne) disant 1 pot de mayonnaise. Il va sans dire qu'un signe - indique un retrait de ligne. Je signale au passage que, puisque l'unité est la ligne, la correction d'un caractère provoquera la suppression de l'ancienne ligne et l'ajout de la ligne corrigée ! ;)
Sans paramètre, la commande renvoie tous les fichiers modifiés, on peut bien entendu préciser un fichier en particulier :
Comme je vous l'ai déjà dit plus haut, le serveur Subversion conserve une trace de toutes les modifications faites aux fichiers soumis au contrôle des versions. Cela a notamment pour avantage de permettre de visualiser le dépôt tel qu'il était à une révision donnée.
Pour faire cela, on utilise une option de la commande update qui permet de spécifier à quel moment dans le temps on veut aller. Par défaut, cette option est définie à HEAD (la dernière révision), et finalement cette option est -r. Ainsi :
svn update -r 3
U foobar
Checked out revision 3.
Les fichier marqués U sont les fichiers qui ont été modifiés par l'update. Ensuite, vous pouvez parcourir, utiliser et modifier les fichiers de votre dépôt comme d'habitude.
Rappelez-vous simplement que les fichiers que vous modifierez ne seront pas à jour, vous ne pourrez donc pas les envoyer sur le serveur sans action de résolution de conflit.
Ressusciter des fichiers
Il arrive souvent qu'on supprime un fichier du dépôt, puis qu'on veuille s'en resservir par la suite. Il existe plusieurs méthodes pour cela, je vais exposer la plus pratique à mon goût. Tout d'abord, il faut identifier le moment de la suppression, pour cela on utilisera la commande svn log. L'option -v permet d'afficher plus d'informations.
svn log -v
(...)
------------------------------------------------------------------------
r7 | apognu | 2007-10-26 18:49:01 +0200 (Fri, 26 Oct 2007) | 1 line
Suppression du fichier foobar.
------------------------------------------------------------------------
(...)
Ici, on apprend que le fichier a été supprimé le 26 octobre 2007 par apognu à 18h49 (ce qui nous fait une belle jambe), mais surtout que le fichier a été supprimé à la révision 7, ce qui signifie qu'il existait à la révision 6 ! Maintenant, on peut le copier depuis la révision 6 :
svn copy -r 6 file:///home/apognu/svn/repository/foobar ./foobar
A foobar
Le fichier vient d'être récupéré, puis "prévu pour commit" dans la copie locale, il ne reste plus qu'à commiter pour finir le travail !
Bon, eh bien nous voici au terme de ce tutoriel, je pense avoir atteint mon but, à savoir vous apprendre le fonctionnement du logiciel Subversion. Mais ne vous méprenez pas, connaître ce fonctionnement ne suffit pas à pouvoir gérer un projet de grosse envergure : même avec SVN une grande organisation est nécessaire, et dans ce cas la lecture du book SVN dont je parlais au début de mon cours est pratiquement indispensable.
Je pense notamment à l'organisation des versions en trunk, branches et tags (et tout ce qui en découle), ou tout simplement à l'administration du dépôt.
Foncez, et ne vous demandez plus pourquoi des projets tels que Wordpress, KDE, GCC ou encore Apache utilisent maintenant Subversion (avec parfois l'utilisation conjointe de l'application Trac, permettant de gérer la collaboration et l'organisation au sein du projet), la réponse est toute trouvée !