Un gestionnaire de version ...

Comme l'indique le titre du chapitre, Subversion (que je nommerai souvent par son abréviation SVN) est un système de gestion de versions des fichiers.
Quoi ? Ça ne vous épate pas ? C'est vrai que présenté comme ça, le produit ne donne pas vraiment envie. C'est pourtant ce que c'est ! Mais, rassurez-vous, je n'aurais pas entamé un big-tuto juste pour vous présenter un bête gestionnaire de versions, j'aurais écrit deux lignes dans un mini-tuto qui n'aurait jamais été validé et puis il serait parti à la poubelle. Non, le but est donc bien de vous présenter un gestionnaire de versions intelligent.

Tout d'abord, une petite définition du système de gestion de versions. Faisons un petit tour sur Wikipedia, nous obtenons le résultat suivant :

Citation : Wikipedia


Soyons clair, comme gestionnaire de versions personnel sur votre ordinateur, SVN ne va probablement pas vous apporter grand chose.

Mais ne soyez pas déçu, il fait en fait bien plus que de la simple gestion de versions. Dès que vous serez plusieurs et/ou mobile(s), il va devenir très intéressant.

Premièrement, sachez qu'il est possible de l'utiliser en ligne. Les fichiers que l'on veut versionner peuvent donc être accessibles via un réseau (par exemple Internet). C'est là que les choses deviennent intéressantes ! Du fait que tout soit disponible à l'aide d'une connexion Internet, il est donc permis à plusieurs personnes d'utiliser ce système en même temps... Je ne sais pas si vous vous rendez compte, mais c'est extrêmement puissant pour le travail en équipe (surtout si l'équipe est dispersée).

Le principe de fonctionnement est très simple, il est basé sur un système client/serveur "basique". Nous allons passer en revue trois configurations standard.

Première configuration : un ordinateur client et serveur

Ce cas n'est pas souvent utilisé (personnellement, je ne l'ai jamais vu). Comme on peut le voir sur le dessin, le même ordinateur sert à la fois de serveur pour stocker toutes les données, et de client pour la présentation des données.

Deuxième configuration : deux ordinateurs en LAN

Ce cas est déjà plus courant, mais ce n'est pas non plus le plus utilisé. On peut tout de même se rendre compte qu'il n'est pas obligatoire de passer par Internet.

Troisième configuration : le serveur et le client sont tous les deux connectés à Internet

Ce cas est le plus fréquemment utilisé, et c'est d'ailleurs là que SVN montre toute sa puissance. Déjà, on voit que, du fait du passage par le net, le client peut utiliser ses données où qu'il soit, du moment qu'il possède une connexion Internet. Mais ce n'est pas tout ! Vous aurez compris que le serveur et le client ne sont pas au même endroit géographique... Le serveur agit donc également comme serveur de backup, des fois qu'une bombe atterrisse sur votre ordinateur personnel et que vous perdiez toutes vos données.

Si je vous ai présenté les trois configurations, c'est aussi pour vous montrer qu'on peut les fusionner (à partir de maintenant, à la place de fusionner, je vais employer le terme merger pour vous habituer au vocabulaire SVN - anglais en gros). Comme je vous l'ai dit, il est possible pour plusieurs personnes d'utiliser le système en même temps, ce qui peut nous donner (par exemple) le schéma suivant :



Ceci est bien sûr un exemple ! Tout dépend de qui doit pouvoir accéder aux fichiers et les lire et/ou les modifier.


Le principe est le suivant :

• le serveur garde en mémoire toutes les versions de tous les fichiers qui ont été utilisés sur lui. Ces fichiers utilisés sont les fichiers que l'on veut versionner.
  Il n'est pas possible de travailler directement sur les fichiers du serveur. C'est la raison pour laquelle il faut obligatoirement un client dans le système.
• Le client, lui, va télécharger les fichiers à jour sur le serveur afin de pouvoir travailler dessus localement. Une fois qu'il aura fini d'apporter ses modifications, il va envoyer la nouvelle version des fichiers au serveur qui va les stocker pour la personne suivante qui voudrait les utiliser.

Et voila, ce n'est pas plus compliqué que ça. Toute la théorie est là, si vous avez bien compris le rôle de chacun, alors vous avez tout compris. Pour ceux qui n'ont pas encore bien saisi, voici un petit schéma explicatif.





OLA !!! Une chose à la fois petit scarabée Zér0. Ce schéma n'est pas exhaustif et est aussi très simplifié et idéalisé pour bien comprendre. Je vais répondre aux questions une par une.

Les noms de fichiers ne changent pas en réalité, j'ai juste ajouté la version à coté pour bien comprendre que le fichier v1 (version 1) avait été changé par rapport à la v0 (version 0) (correction des fautes d'orthographe par exemple). Donc le nom de fichier ne change jamais (sauf si vous le demandez explicitement).

Comme je vous l'ai dit plus haut, le serveur sert de source de données alors que les clients ne sont là que pour afficher à l'utilisateur ce dont il a envie (donc besoin). Les clients ne possèdent donc que les derniers fichiers (ceux qui sont à jour) sauf demande explicite de leur part. Le serveur, en revanche, doit pouvoir envoyer au client n'importe quelle version s'il le demande. Il est donc normal qu'il possède toutes les versions de tous les fichiers.

Le Client2 récupère le fichier après que le Client1 l'a remis sur le serveur. Bien sûr ce n'est que la présentation du cas idéal, rassurez-vous, SVN gère le cas où le Client2 récupère le fichier avant que le Client1 ne le renvoie, mais on verra ce cas plus tard.

Il est vrai que pour le cas de figure que je vous ai présenté, un serveur FTP ferait l'affaire. Ce qui fait la puissance de SVN est sa gestion des conflits lorsque deux personnes modifient un même fichier chacune de leur côté et essaient de remettre les deux versions différentes sur le serveur (on appelle ça un conflit). Enfin bref, il est vrai que beaucoup de chose pourraient être faites par un serveur FTP, à une chose près, c'est que SVN fait ça automatiquement, il n'y a donc qu'à cliquer sur un seul bouton (allez peut-être deux) pour mettre tout le projet à jour.

On peut maintenant se poser la question des contraintes techniques.

Comme on l'a vu, il faut un serveur (une machine avec un serveur Subversion installé), mais aussi un client (une machine, éventuellement la même, avec un client Subversion installé).

Pour vous rassurer dès maintenant, comme vous avez pu le voir dans l'introduction du tuto, on peut faire fonctionner SVN sur Mac, Linux et Windows, comme ça il n'y aura pas de jaloux.


Non bien sûr que non, aucune contrainte entre le client et le serveur, si ce n'est qu'ils doivent être connectés l'un à l'autre (qu'importe le moyen).

Vous voyez donc qu'on peut faire cohabiter les trois systèmes d'exploitation sur le même projet.





Et pour le côté serveur, pas de jaloux non plus, Subversion fonctionne sur les trois.



Donc voila, bilan : pour l'instant, comme on ne touche pas encore au côté serveur, il n'y a pas de problème de compatibilité entre les systèmes d'exploitation ni entre les programmes. Chacun pourra donc faire ce qu'il veut sur sa machine sans affecter les autres si vous respectez la règle des accents et caractères spéciaux dans les noms de fichier.

Les outils sont nombreux, malheureusement pour vous, je ne vais en présenter que quelques-uns (un par système d'exploitation). Je présenterai ceux qui, je pense, sont les plus faciles d'utilisation pour tout le monde et les plus pédagogiques. La raison de ce raccourci est simple, il vous suffit d'aller sur cette page pour vous convaincre qu'il y a beaucoup de clients disponibles quel que soit le système d'exploitation. Ce à quoi j'ajouterai que le principe restera toujours le même, donc une fois que vous aurez compris le fonctionnement d'un client et acquis le vocabulaire, il vous sera très facile de passer d'un client à l'autre.

Alors mon choix vous semblera peut être bizarre :

• pour Windows : TortoiseSVN que vous pouvez récupérer ici. Je conseille de garder la version anglaise pour des questions de compréhension. Mes screenshots seront sur la version anglaise.
• Pour Mac : un terminal...
• Pour Linux : un terminal aussi !!!

Comme je vous l'ai dit, Subversion n'est pas quelque chose de compliqué à utiliser, et si je présente le client graphique seulement pour Windows c'est parce que je voulais en montrer un et que TortoiseSVN est extrèmement bien fait. Donc, voilà ! Ce à quoi j'ajouterai que :

1. pour avoir essayé un client graphique sous Mac, la ligne de commande est, je trouve, plus pratique et rapide ;
2. le but est avant tout pédagogique, et justement, le terminal est plus pédagogique et vous comprendrez mieux parce qu'il faudra utiliser les termes du milieu ;
3. c'est moi le boss ;
4. si vous savez utiliser la ligne de commande, vous savez utiliser un client graphique !