Installation de Subversion sous Debian.

L'installation de Subversion se fait simplement par la commande :

Sélectionnez

aptitude install subversion

Cette commande installe le client Subversion, différentes commandes de gestion de dépôt ainsi qu'un exécutable serveur.
Sur une distribution Debian Etch, la version est 1.4.2.

Cela fait, il est nécessaire de créer un premier dépôt.
Dans le cadre de cet article, le répertoire de base des dépôts sera /var/subversion/depot/

La création d'un dépôt pour un projet nomdemonprojet se fait via la commande :

Sélectionnez

svnadmin create /var/subversion/depot/nomdemonprojet

Le résultat devrait être un répertoire nomdemonprojet créé dans /var/subversion/depot/.

Dès lors, il est déjà possible de travailler sur celui-ci localement (sur la même machine que le dépôt lui-même). L'accès à distance nécessitant un peu de configuration, cela sera expliqué par après.

En attendant, voici un petit descriptif des commandes de base du client Subversion.

Check out▲

La première étape dans l'utilisation de Subversion est de récupérer une copie locale du dépôt :

Sélectionnez

svn co file:///var/subversion/depot/nomdemonprojet

Si tout s'est bien déroulé, un répertoire nomdemonprojet a dû être créé dans le répertoire courant.

Ce répertoire doit contenir les fichiers de la dernière révision disponible sur le dépôt.
Dans ce cas-ci, le projet venant d'être créé, ce répertoire est vide.

Ajout de fichiers/répertoires▲

Dans ce répertoire, vous êtes libre de travailler normalement : création de répertoire, ajout de fichier.
Dans le cadre de cet article, la hiérarchie de fichiers/répertoires suivante a été créée :

Sélectionnez

nomdemonprojet
  + src
    + java
      + com
        + developpez
            + hikage
                + TestMain.java
                + Application.java
    + webapp
      + WEB-INF
        + web.xml

Il est ensuite nécessaire d'informer Subversion que ces fichiers doivent être pris en compte lors de la prochaine publication des modifications sur le dépôt :

Sélectionnez

svn add src

Le résultat de cette commande est :

Sélectionnez

debian:~/nomdemonprojet# svn add src
A         src
A         src/webapp
A         src/webapp/WEB-INF
A         src/webapp/WEB-INF/web.xml
A         src/java
A         src/java/com
A         src/java/com/developpez
A         src/java/com/developpez/hikage
A         src/java/com/developpez/hikage/TestMain.java
A         src/java/com/developpez/hikage/Application.java

Intégration des modifications sur le serveur▲

La dernière commande n'a fait que mettre une « étiquette » sur des fichiers, mais ceux-ci n'ont pas encore été envoyés vers le dépôt.
Cette action est réalisée via la commande :

Sélectionnez

svn commit src -m "Message expliquant la modification effectuée"
Ajout          src
Ajout          src/java
Ajout          src/java/com
Ajout          src/java/com/developpez
Ajout          src/java/com/developpez/hikage
Ajout          src/java/com/developpez/hikage/Application.java
Ajout          src/java/com/developpez/hikage/TestMain.java
Ajout          src/webapp
Ajout          src/webapp/WEB-INF
Ajout          src/webapp/WEB-INF/web.xml
Transmission des données ...
Révision 1 propagée.

Le paramètre -m « Mon Message » spécifie un message qui sera associé à la publication (et donc à la nouvelle révision).
Il est courant d'expliquer comme message le but des modifications réalisées : ajout d'une fonctionnalité, correction d'un bug…

Intégration, le retour▲

Imaginons maintenant que du code a été ajouté dans le fichier TestMain.java (qui était jusqu'ici un simple fichier vide), et que lors de la publication des modifications, le résultat affiche :

Sélectionnez

debian:~/nomdemonprojet/src/java/com/developpez/hikage# svn commit TestMain.java -m "Ajout du code par développeur 1"
Envoi          TestMain.java
svn: Échec de la propagation (commit), détails :
svn: Le chemin '/src/java/com/developpez/hikage/TestMain.java' est obsolète dans la transaction '3-1'

Le message informe que le fichier du dépôt est plus récent (une révision supérieure) que celle disponible en locale.
Il est donc nécessaire de mettre à jour cette dernière grâce à la commande :

Sélectionnez

svn update TestMain.java
C    TestMain.java
Actualisé à la révision 3.

La mise à jour a été effectuée, mais un conflit (le C à côté du nom du fichier) est apparu.
Lors d'un conflit, Subversion crée trois nouveaux fichiers dans le répertoire, ici TestMain.java.mine (qui est une copie de la version modifiée localement), TestMain.java.r1 (qui est la version locale avant modification, c'est-à-dire celle récupérée lors du check out ou de la dernière mise à jour), et TestMain.java.r3 qui est la dernière version sur le serveur.

Le fichier TestMain.java quant à lui possède des informations sur les différences entre chaque fichier.
Il est donc nécessaire de réaliser la fusion manuellement, en gardant les bonnes lignes.

Dans le cas de la ligne de commande, la fusion doit être réellement faite à la main.

Lors de l'utilisation de client graphique, il est fréquent d'avoir une fenêtre qui affiche les différences entre les fichiers et propose une interface simple pour réaliser la fusion.

Une fois la fusion effectuée, il faut dire à Subversion que le problème a été résolu :

Sélectionnez

svn resolved TestMain.java
Conflit sur 'TestMain.java' résolu

En plus de supprimer l'étiquette 'Conflit' (qui empêche le fichier d'être envoyé sur le dépôt), cette commande supprime les trois fichiers temporaires cités plus haut.

Le cas du « conflit » est le seul qui nécessite l'intervention manuelle. Lors d'une mise à jour de la copie locale (svn update), les informations possibles associées au fichier peuvent être :

Drapeau	Description
C	Conflit, c'est le cas présenté dans cet article
A	Ajout, un nouveau fichier a été ajouté sur le dépôt et est donc récupéré dans la copie locale
D	Supression, un fichier a été marqué comme supprimé, et donc la copie locale est supprimée aussi
G	Fusion, des modifications ont été réalisées sur un fichier qui a été modifié dans la copie locale, mais les modifications ne sont pas conflictuelles. Subversion intègre donc ces modifications dans la copie locale
M	Modification, des modifications ont été réalisées sur un fichier qui n'a pas été modifié localement, les modifications sont donc intégrées dans la version locale

Voilà qui finit la présentation des commandes de base de Subversion. Il en existe beaucoup d'autres afin de créer des patchs entre versions (svn diff), annuler des modifications locales (svn revert), et bien d'autres encore qui nécessiteraient un article à part afin d'être présentées correctement.

Jusqu'ici le serveur était accessible uniquement en local et son utilité est donc restreinte.
Pour mettre à disposition les dépôts à des clients distants, il existe différents moyens possédant chacun leurs avantages et leurs inconvénients.

SVNServe▲

La première méthode est d'utiliser SVNServe, un démon fourni dans le package Subversion. Celui-ci peut être configuré en serveur Standalone ou via InetD.

L'avantage de cette méthode est qu'elle ne nécessite pas d'autre dépendance.

L'inconvénient est qu'elle écoute sur un port propre (qui est bien sûr configurable), et qu'elle risque donc d'être bloquée par des pare-feux.

SSH▲

Il est aussi possible d'accéder au dépôt via un tunnel SSH. Cela nécessite bien sûr un serveur SSH installé sur la machine qui héberge le dépôt, mais c'est souvent le cas sur des machines Linux.

Du côté du client, il est nécessaire que celui-ci gère ce type d'accès. Parmi ceux-ci, citons Tortoise SVN, SmartSVN ou encore Subclipse.

Module Apache▲

La dernière méthode, et la plus intéressante est d'utiliser un module Apache pour Subversion.

Le principal intérêt par rapport à l'accès via SvnServe ou SSH est que le port HTTP est très rarement filtré par les pare-feux, et donc est accessible de partout.
De plus l'authentification étant effectuée via les modules d'Apache, les moyens d'authentification de celui-ci (fichier d'utilisateur, annuaire LDAP, base de données) sont disponibles.

Comme il a été dit au début de cet article, l'intégration Apache/Subversion fournit un dispositif de gestion des droits d'accès plus fine.

Dans le cadre de ce tutoriel, c'est cette méthode qui sera expliquée.

Installation▲

La première chose à faire est d'installer Apache si ce n'est pas encore le cas :

Sélectionnez

aptitude install apache2

Ensuite, il faut installer le module svn en lui-même.
Sous debian Sarge :

Sélectionnez

aptitude install libapache2-mod-dav libapache2-svn

Tandis que sous debian Etch, cela se fait via :

Sélectionnez

aptitude install libapache2-mod-svn

Configuration▲

Une fois le module installé, il faut configurer Apache afin d'intégrer le dépôt.
Pour ce faire, nous allons configurer Apache afin que l'URL de type http://monserveur/svn fournisse un accès au dépôt.

Tout d'abord, il faut informer Apache qu'il doit prendre en compte le module SVN :

Sélectionnez

a2enmod dav_svn

Ensuite, le fichier de configuration /etc/apache2/mod-available/dav_svn.conf doit être édité :

Sélectionnez

<Location /svn>
    DAV svn
    Require valid-user
    SVNParentPath /var/subversion/depot/
    AuthType Basic
    AuthName "Mon dépôt"
    AuthUserFile /var/subversion/conf/htpasswd
    AuthzSVNAccessFile /var/subversion/conf/access
</Location>

Ligne	Description
Location /svn	Spécifie que le dépôt sera accessible via http://ip/svn où ip représente l'adresse ip du serveur
DAV svn	Active la gestion SVN sur ce répertoire
Require valid-user	Nécessite un utilisateur valide afin d'accéder à ce répertoire
SVNParentPath	Configure le chemin vers le répertoire parent des dépôts
AuthType	Spécifie le type d'authentification
AuthName	Spécifie le nom qui sera affiché dans la boite de demande de mot de passe
AuthUserFile	Spécifie le fichier des utilisateurs
AuthzSVNAccessFile	Spécifie le fichier de gestion des accès

Gestion des utilisateurs▲

Cela fait, l'étape suivante est de créer le fichier /var/subversion/conf/htpasswd qui contiendra les utilisateurs et leurs mots de passe.
La création du premier utilisateur est réalisée via la commande :

Sélectionnez

     htpasswd -c /var/subversion/conf/htpasswd hikage

hikage représente le nom de l'utilisateur, et son mot de passe sera demandé par la commande.
Le paramètre -c spécifie qu'il est nécessaire de créer le fichier. L'ajout des prochains utilisateurs se fera donc via la commande :

Sélectionnez

     htpasswd /var/subversion/conf/htpasswd utilisateur2

Une fois les utilisateurs créés, il reste encore à configurer leurs accès. Cela est réalisé dans le fichier /var/subversion/conf/access.
Le contenu de ce fichier dans le cadre de cet article pourrait être :

Sélectionnez

[groups]
developpez  = hikage, utilisateur2

[nomdemonprojet:/]
@developpez = rw
* = r

[projetprivehikage:/]
hikage = rw
* = r

[projetprivehikage:/documentation/utilisateur]
auteurdoc = rw

La section [groups], comme son nom le laisse sous-entendre, permet de définir des groupes. Ici un seul groupe ( developpez ), dont les membres sont hikage et utilisateur2, est créé

La deuxième section ([nomdemonprojet:/] ) définit les accès globaux au projet nomdeprojet. Ici le groupe développezcom (@developpezcom) possède un droit en lecture/écriture, tandis que tous les autres (représenté par *) ont un accès en lecture seule.

La troisième section définit les accès globaux à un deuxième projet (projetprivehikage), accessible en écriture uniquement par hikage mais lisible par tous.

Remarquez que le fichier de configuration des droits d'accès peut être commun à plusieurs projets.

La dernière section redéfinit les droits d'accès au répertoire documentation/utilisateur du projet projetprivehikage. Celui-ci sera accessible en écriture par auteurdoc.

Relancement du serveur▲

Ces étapes réalisées, il est nécessaire de relancer Apache afin qu'il prenne ces changements en compte :

Sélectionnez

/etc/init.d/apache2 restart

Installation de Subversion sous Debian

I. Subversion sous debian▲

Installation▲

Gestion d'un dépôt▲

I-B. Utilisation du client▲

Check out▲

Ajout de fichiers/répertoires▲

Intégration des modifications sur le serveur▲

Intégration, le retour▲

Utilisation en réseau▲

SVNServe▲

SSH▲

Module Apache▲

Installation▲

Configuration▲

Gestion des utilisateurs▲

Relancement du serveur▲