Vous venez de voir différentes méthodes d'accès à un dépôt. Est-il possible — et sans danger — d'accéder simultanément à un dépôt par différentes méthodes ? La réponse est oui, à condition d'être un petit peu prévoyant.
À un instant donné, les processus suivants peuvent avoir besoin de l'accès en lecture ou en écriture au dépôt :
des utilisateurs classiques du système se connectant à
l'aide d'un client Subversion à des URL
file:// ;
des utilisateurs classiques du système se connectant à des processus svnserve privés générés par SSH (dont le propriétaire est l'utilisateur lui-même) et accédant au dépôt ;
un processus svnserve — soit un serveur autonome, soit un processus lancé par inetd — dont le propriétaire est un utilisateur dédié ;
un processus httpd Apache, dont le propriétaire est un utilisateur dédié.
Les problèmes les plus courants rencontrés par les
administrateurs sont des problèmes de droits et de propriété pour
le dépôt. Chaque processus de la liste précédente a-t-il les
droits de lecture et d'écriture sur les fichiers sous-jacents du
dépôt ? En supposant que vous ayez un système d'exploitation
de type Unix, une approche naïve de ce problème serait de placer
chaque utilisateur potentiel du dépôt dans un groupe
svn unique et de faire posséder le dépôt tout
entier par ce groupe. Mais cela ne suffit même pas, car un
processus risque de modifier les fichiers de la base de données en
utilisant un umask inadapté qui va interdire l'accès aux autres
utilisateurs.
L'étape suivante consiste donc, après avoir mis en place un
groupe commun pour les utilisateurs du dépôt, à forcer tout
processus qui accède au dépôt à utiliser un umask correct. Pour
les utilisateurs qui accèdent directement au dépôt, vous pouvez
« envelopper » le programme svnserve dans un script
(wrapper en anglais) qui commence
par lancer la commande umask 002
et qui, seulement ensuite, appelle
le véritable programme client svn.
Vous pouvez également écrire un script similaire pour le programme
svnserve et ajouter la commande
umask 002 au script de démarrage d'Apache,
apachectl. Par exemple :
$ cat /usr/bin/svn #!/bin/sh umask 002 /usr/bin/le-vrai-svn "$@"
Sur les systèmes de type Unix, on rencontre souvent un autre
problème classique. Si vous avez un dépôt Berkeley DB, par
exemple, il crée de temps en temps de nouveaux fichiers pour la
journalisation. Même si le dépôt Berkeley DB est entièrement
possédé par le groupe svn, ces nouveaux
journaux ne seront pas nécessairement possédés par le même groupe,
ce qui crée des problèmes de droits supplémentaires pour vos
utilisateurs. Une bonne façon de contourner ce problème est
d'activer le bit SUID du groupe sur le répertoire
db du dépôt, ce qui a pour résultat que tous
les nouveaux fichiers journaux créés ont le même propriétaire que
le répertoire parent.
Une fois ces manipulations effectuées, vos dépôts devraient être accessibles par tous les processus nécessaires. Tout ceci peut sembler un petit peu confus et compliqué, mais les problèmes d'accès en écriture par plusieurs utilisateurs à des fichiers partagés sont des problèmes très classiques, qui ne sont pas souvent résolus avec élégance.
Heureusement, la plupart des administrateurs
n'auront jamais besoin d'une configuration
aussi complexe. Les utilisateurs qui désirent accéder aux dépôts
résidant sur une même machine ne sont pas limités aux URL d'accès
file:// — ils peuvent généralement
contacter le serveur http Apache ou le
serveur svnserve en utilisant
localhost comme nom de serveur dans leurs URL
http:// ou svn://. Et
assurer la maintenance de plusieurs processus serveurs pour vos
dépôts Subversion vous créera plus de soucis qu'autre chose. Nous
vous recommandons de choisir un seul serveur (celui qui correspond
le mieux à vos besoins) et de vous y tenir !