Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Tutoriel
Installer un serveur Subversion sur un serveur Linux
Enfin libre et indépendant !
Article mis en ligne le 18 avril 2012
dernière modification le 13 juin 2016

par Laurent Bloch
D’autres articles sur les applications des NAS :
Quelques définitions : NFS, SAN et NAS,
Configurer le NAS DS-106e de Synology,
Installer un serveur de boot sur un NAS DS-106e de Synology.

Après avoir décrit les systèmes de gestion de version (VCS) dans un premier article, puis un second, voici le passage à la pratique. Subversion est un VCS centralisé, sucesseur de CVS dont il reprend toutes les fonctions en en corrigeant les principales lacunes.

Se procurer un livre sur Subversion

Si les systèmes de gestion de version sont des logiciels utiles, et même indispensables, ils ne sont pas pour autant faciles à comprendre et simples à utiliser. Se procurer un livre où c’est bien expliqué n’est pas du luxe. Vous pouvez télécharger le Subversion Book sur le site http://svnbook.org/ : il a l’avantage d’être gratuit, l’inconvénient d’être en anglais, et personnellement je le trouve assez complet mais plutôt confus.

Aussi vous conseillerais-je le livre de Bernard Desgraupes Subversion – Contrôle de version des projets collaboratifs, chez Vuibert, beaucoup plus clair.

N’oubliez pas non plus de visiter le site officiel de Subversion.

Installer Subversion

La première chose à faire est bien sûr d’installer Subversion, qui dans la Debian dont je dispose vient en deux paquets : subversion et subversion-tools.

Choisir un type de serveur : Apache ou SSH ?

Un serveur Subversion peut fonctionner avec trois types de serveurs : svn, protocole maison avec serveur svnserve, serveur Web (Apache) ou serveur svn+ssh, le protocole maison encapsulé dans SSH. C’est cette dernière solution que j’ai choisie, plus sûre que svnserve tout seul, et peut-être plus légère qu’un serveur Web. En outre je disposais déjà du serveur SSH.

Configurer SSH sur les ordinateurs clients

Sur mes serveurs j’ai configuré les serveurs ssh de façon à ce qu’ils écoutent sur un port de numéro différent du standard qui est 22 : ceci limite considérablement le nombre d’attaques par scan de port. Cela se fait en écrivant dans le fichier /etc/ssh/sshd_config :

au lieu de Port 22 de la configuration par défaut.

Ceci va obliger les clients à s’adapter à ce numéro de port. Il est commode et élégant de créer dans son répertoire sur l’ordinateur client un fichier de configuration .ssh/config qui pourra comporter l’entrée suivante :

Ce sera toujours ça de moins à taper.

Créer le dépôt Subversion

Comme le dit fort bien le livre, il faut maintenant créer un goupe subversion et y enrôler les utilisateurs ; attention à la commande usermod, il faut répéter les noms des groupes auxquels chaque utilisateur appartient déjà, sinon il en sera retiré, et si c’était l’appartenance à ce groupe (admin par exemple) qui lui conférait dans /etc/sudoers les privilèges système pour utiliser sudo, il y aura du grabuge, et le livre n’a pas prévenu :

Création du dépôt, auquel on confère les appartenances et les permissions qui conviennent, en l’occurrence le groupe propriétaire est subversion, le dépôt est accessible en lecture et en écriture aux membres du groupe, le sticky bit (1 dans les arguments de chmod) est positionné pour éviter que soient créés dans le dépôt des fichiers qui n’appartiendraient pas au groupe :

Voilà, si tout s’est bien passé, le dépôt est fonctionnel et accessible, il n’y a plus qu’à l’utiliser.

Créer un projet Subversion

Je me place maintenant sur l’ordinateur client, dans le répertoire qui abrite les fichiers qui constituent le projet à déposer aux bons soins du serveur Subversion. Il est prudent de commencer par détruire tous les fichiers temporaires que l’on ne souhaite pas retrouver dans le dépôt, cela évitera d’avoir à les en retirer un par un ultérieurement. Et il n’y a plus qu’à agir ; si le projet s’appelle SecuritePratique (et en général le répertoire sera lui-même nommé SecuritePratique) cela donne (sur une seule ligne) :

Cette commande (sur une seule ligne) créera dans le dépôt Svn_Home sur la machine désignée par l’identifiant svn1 dans le fichier .ssh/config un projet SecuritePratique, et y archivera tous les fichiers du répertoire duquel est lancé la commande, y compris les sous-répertoires et leur contenu.

Une fois cela fait, la chose à faire est de renommer le répertoire d’origine de SecuritePratique en SecuritePratique.old et de créer à partir de l’archive une copie neuve et fraîche du projet, ainsi :

C’est le moyen d’avoir tout bien configuré comme il faut dans un sous-répertoire .svn.

Télécharger le contenu du projet

Sur une autre machine je souhaite installer une copie du projet SecuritePratique ; voici :

Cette commande crée, à l’endroit d’où elle est émise, un répertoire SecuritePratique qui contient les fichiers du projet.

Configurer Subversion

Le fichier global de configuration de Subversion est /etc/subversion/config, mais en général il n’y a rien à y modifier. Une chose à faire, c’est de programmer l’envoi à tous les membres du projet d’un message à chaque fois qu’une nouvelle version du projet est commise.
Cela peut se commander à partir du fichier /etc/svn-mailer.conf. Par exemple, toujours pour notre projet SecuritePratique (mais il est conseillé de regarder le fichier entier) :

La commande magique pour visionner les modifications

La seule vraie supériorité de Word/OpenOffice/LibreOffice sur LaTeX, c’est le mode révision, qui permet de visionner instantanément les modifications apportées par le dernier auteur.

Avec LaTeX, vi ou emacs et Subversion, il y a quand même un outil qui permet de visionner les modifications sans ambiguïté, et même à l’usage c’est supérieur au mode révision de Word, vite très confus s’il y a beaucoup de petites modifications : c’est tkdiff, qui s’utilise avec la commande magique ci-dessous (312 étant le numéro de la version à comparer avec la version courante, obtenu par svn status -v premiers-principes.tex) :

Voilà, Subversion est un système centralisé, avec les inconvénients signalés dans l’article précédent, mais ausi ses avantages ; en effet, sous réserve de pouvoir accéder au site qui l’héberge, le dépôt unique et central est commode, parce qu’avec les systèmes décentralisés on est quand même souvent en train de faire des synchronisations dans tous les sens, avec le risque de se tromper de sens, et ainsi de créer des situations délicates à réparer.

Bonne Subversion !