Utilisation de Subversion

Qu'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 par là à la fois la structure des dossiers, mais également le contenu des fichiers). C'est de là que vient le terme de "version", il surveille les différentes versions d'un répertoire.

Subversion (tout comme son prédécesseur, CVS) est principalement utilisé dans le cadre de 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 expplicite 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 aucun détail, dites-vous que Subversion réalice 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 devez faire un dessin sur une feuille de papier, et qu'à chaque fois que vous ajouter 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 à dispoitions 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éveloppeur à 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.).



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 tout l'arborescence à chaque fois, il analyse tranquillement ce qui a changé et réalise ce que j'appelerais 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, une révisions, pour SVN, 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évisions.

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 2 et ainsi de suite).

Dépôt et copie locale

Un système utilisant Subversion est à diviser en deux partie dinstincte, le dépôt (ou repository en Anglais) et la copie locale (ou local copy chez Shakespear). 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 sera envoyée 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 sa 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épot, 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é 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.

Cré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. Donc pour créer un dépôt, ouvrez un terminal ou une invite de commande et tapez :

Code : Console

Cela a eu pour conséquences 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 :

Code : Console

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éé une copie locale en téléchargeant le contenu du dépot à l'intérieur. 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épot 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 :

Code : Console

Basiquement, on demande ici à SVN de procéder au checkout de 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 :

Code : Console

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. A votre retour, vous avez envie de récupérer ce qui a changé depuis votre départ, donc vous lancez une update, votre dépôt est mis à jour de la révision 4 à la révision 7. Vous pouvez de nouveau travailler.



Pour réaliser un 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 :

Code : Console

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 inverse 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 Subverson. 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) :

Code : Console

Voilà ce qui apparait en sortie :

Code : Console

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.



Voici les trois lignes de commandes :

Code : Console

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

A partir de là, vous connaissez les trois actions de base de SVN (checkout, update et commit), pour vous entrainer, 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.

Entrainez-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

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é. Et 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épondrais-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 pris en compte par SVN, on peut dès lors dresser le scénario suivant :

• Joe et Bobby font un checkout sur le dépot 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 drâme, 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 !



Que nenni ! Subversion propose plusieurs moyens de résoudre et prévenir les conflits, que nous allons étudier dans cette sous-partie.

Merging

Subversion propose, pour résoudre un conflit, une solution de merging, terme signifiant ici mélange. Basiquement, cela consisite en un mélange des deux fichiers pour en obtenir un nouveau. Il y a deux type 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 vos 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 "coupent" 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)

Citation : Bobby (commit foireux)



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)

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 Subversion, dans ce cas, 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

Maintenant, imaginons que Joe aime la viande, et rajoute une tranche de jambon (cinq donc), 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 :

Code : Console

Il tente de faire son update, comme la dernière fois, sauf que là, ça ne marche pas, et voilà avec quoi il se retrouve dans sa copie locale :

Code : Console

Décortiquons un peu cela ! sandwiches.txt.mine contient le fichier que j'ai 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 :

Code : Console

Et c'est là que vous prenez votre tube d'aspirine et que vous commencez à pleurer ! Sans raison, vraiment parce que ce n'est vraiment pas compliqué... Il y a deux choses à retenir, la signification des signes, on peut les résumer à cela :

Code : Console

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 :

Code : Console

La sortie devrait être :

Code : Console

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 toujours pas. 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 veut 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 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 :

Code : Console

Ce qui donne :

Code : Console

A partir de ce moment, n'importe qui demandant un lock sur ce fichier ce verra gratifié d'un majestueux :

Code : Console

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 un 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 :

Code : Console

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 !

Status

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 affichent 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 :

Code : Console

Voilà ce qui s'affichera :

Code : Console

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'action 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

Ca, 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 au fichier à la ligne près.

Si j'ajoute une ligne au fichier sandwiches.txt, et que je lance svn diff, j'aurai cette sortie :

Code : Console

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 :

Code : Console

Grand-père, comment c'était de ton temps ?

Comme je vous l'ai déjà dit plus haut, le serveur Subversion conserve une trace de touted les modifications faites au 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 :

Code : Console

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.

Ressuciter des fichiers

Il arrive souvent qu'on supprime un fichier du dépôt, puis qu'on veuille y retourner par la suite. Il existe plusieurs méthodes pour cela, je vais exposer la plus pratique à mon goût. Tout d'abord, il faut localiser la moment de la suppression, pour cela, on utilisera la commande svn log. L'option -v permet d'afficher plus d'informations.

Code : Console

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 signifique qu'il existait à la révision 6 ! Maintenant, on peut le copier depuis la révision :

Code : Console

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 !