Installer un serveur Subversion sur un serveur Linux

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.

#Sommaire-

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 :

Port 933

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 :

host svn1 Hostname serveur-nas.laurentbloch.org Port 933 ForwardAgent no ForwardX11 no User lbloch

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 :

sudo /usr/sbin/groupadd subversion sudo /usr/sbin/usermod -G admin,users,subversion lbloch sudo /usr/sbin/usermod -G users,subversion gontran

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 :

svnadmin create /users/lbloch/Svn_Home chgrp -R subversion /users/lbloch/Svn_Home chmod -R 1770 /users/lbloch/Svn_Home

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

svn import -m "Creation du projet SecuritePratique" svn+ssh://svn1/users/lbloch/Svn_Home/SecuritePratique/

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 :

svn co svn+ssh://svn1/users/lbloch/Svn_Home/SecuritePratique/

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 :

svn co svn+ssh://svn1/users/lbloch/Svn_Home/SecuritePratique/

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

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

svn diff -r312 --diff-cmd=tkdiff 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 !