II. Subversion sous debian▲
Installation▲
L'installation de Subversion se fait simplement par la commande :
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 :
svnadmin create /var/subversion/depot/nomdemonprojetLe 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 :
svn co file:///var/subversion/depot/nomdemonprojetSi 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 :
nomdemonprojet
+ src
+ java
+ com
+ developpez
+ hikage
+ TestMain.java
+ Application.java
+ webapp
+ WEB-INF
+ web.xmlIl 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 :
svn add srcLe résultat de cette commande est :
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.javaInté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 :
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 :
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 :
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 :
svn resolved TestMain.java
Conflit sur 'TestMain.java' résoluEn 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 :
aptitude install apache2
Ensuite, il faut installer le module svn en lui même.
Sous debian Sarge :
aptitude install libapache2-mod-dav libapache2-svnTandis que sous debian Etch, cela se fait via :
aptitude install libapache2-mod-svnConfiguration▲
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 :
a2enmod dav_svnEnsuite, le fichier de configuration /etc/apache2/mod-available/dav_svn.conf doit être édité :
<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 :
htpasswd -c /var/subversion/conf/htpasswd hikagehikage 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 :
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 :
[groups]
developpez = hikage, utilisateur2
[nomdemonprojet:/]
@developpez = rw
* = r
[projetprivehikage:/]
hikage = rw
* = r
[projetprivehikage:/documentation/utilisateur]
auteurdoc = rwLa 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 :
/etc/init.d/apache2 restart