Installation de Subversion sous Debian


précédentsommairesuivant

II. Subversion sous debian

Installation

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.

Gestion d'un dépôt

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ée dans /var/subversion/depot/

II-C. Utilisation du client

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 bases 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 c'est bien déroulé, un répertoire nomdemonprojet a du ê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é vers le dépôt.
Cette action est réalisée via la commande :

 
Sélectionnez

svn commit src -m "Message expliquant le modification effectuées"
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 fonctionalité, 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 developpeur 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 à coté 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écuperé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 quand à lui possède des informations sur les différences entre chaque fichiers.
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 à é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 :

   
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 conflictuelle.
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

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

Utilisation en réseau

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'il ne nécessite pas d'autre dépendance.

L'inconvénient est qu'il écoute sur un port propre ( qui est bien sur configurable ), et qu'il risque donc d'être bloqué 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 fourni 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 Ou 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ée 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ée 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 tout 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

précédentsommairesuivant

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.