Nous venons 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 :

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/svn-real "$@"

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 !