La plus flexible de toutes les installations serveur possibles pour Subversion est basée sur Apache. Bien qu'un peu plus compliquée à mettre en place, elle offre des avantages que d'autres serveurs n'ont pas :

The first thing you need before installing Apache is a computer with Windows 2000, Windows XP+SP1, Windows 2003, Vista or Server 2008.

Vous avez maintenant mis en place Apache et Subversion, mais Apache ne sait pas encore comment gérer les clients Subversion comme TortoiseSVN. Pour qu'Apache sache quelle URL sera utilisée pour les référentiels Subversion vous devez éditer le fichier de configuration d'Apache (d'habitude placé dans c:\program files\apache group\apache2\conf\httpd.conf) avec votre éditeur de texte préféré (par exemple le Bloc-notes) :

Une courte explication sur ce que vous venez juste de saisir :

Mais ce n'est qu'un exemple. Il y a beaucoup, beaucoup plus de possibilités que vous pouvez faire avec le serveur web Apache.

Si vous avez utilisé la directive SVNParentPath alors vous n'avez pas à changer le fichier de configuration d'Apache chaque fois que vous ajoutez un nouveau référentiel Subversion. Créez simplement le nouveau référentiel au même emplacement que le premier référentiel et vous avez fini ! Dans ma société, j'ai un accès direct à ce dossier spécifique sur le serveur via SMB (accès Windows normal aux fichiers). Donc je crée juste un nouveau dossier là, j'exécute la commande de TortoiseSVN TortoiseSVN → Créer un référentiel ici... et un nouveau projet a un foyer...

Si vous utilisez Subversion 1.3 ou supérieur, vous pouvez utiliser la directive SVNListParentPath on pour permettre à Apache de produire une liste de tous les projets disponibles si vous allez avec votre navigateur sur le chemin parent plutôt qu'à un référentiel spécifique.

Le module mod_authz_svn permet un contrôle précis des autorisations d'accès basé sur les noms des utilisateurs et les chemins de référentiel. C'est possible avec le serveur Apache et, à partir de Subversion 1.3, c'est aussi disponible avec svnserve.

Un fichier d'exemple ressemblerait à ceci :

[groups]
admin = john, kate
devteam1 = john, rachel, sally
devteam2 = kate, peter, mark
docs = bob, jane, mike
training = zak
# Accès par défaut à TOUS les référentiels
# Tout le monde peut lire, les admins peuvent écrire, Dan German est exclus.
[/]
* = r
@admin = rw
dangerman =
# Permet aux développeurs un accès total aux référentiels de leurs projets
[proj1:/]
@devteam1 = rw
[proj2:/]
@devteam2 = rw
[bigproj:/]
@devteam1 = rw
@devteam2 = rw
trevor = rw
# Donne aux personnes en charge de la documentation un accès en écrite sur tous les répertoires de la documentation
[/trunk/doc]
@docs = rw
# Donne aux débutants un accès en écriture uniquement au référentiel d'entraînement
[TrainingRepos:/]
@training = rw

Notez que la vérification de chaque chemin peut être une opération couteuse, particulièrement dans le cas du journal de révision. Le serveur vérifie chaque chemin changé dans chaque révision et le vérifie pour la lisibilité, qui peut être consommatrice de temps sur les révisions qui affectent de grands nombres de fichiers.

L'authentification et l'autorisation sont des processus séparés. Si un utilisateur veut obtenir l'accès à un chemin de référentiel, il doit satisfaire tant les pré-requis habituels d'authentification que les pré-requis d'autorisation du fichier d'accès.

Comme vous l'avez peut-être remarqué vous devez faire une entrée nom d'utilisateur/mot de passe dans le fichier passwd pour chaque utilisateur séparément. Et si (pour des raisons de sécurité) vous voulez que vos utilisateurs changent périodiquement leurs mots de passe vous devez faire le changement manuellement.

Mais il y a une solution pour ce problème - du moins si vous avez accès au référentiel de l'intérieur d'un réseau local avec un contrôleur de domaine Windows : mod_auth_sspi !

Le module SSPI original a été offert par Syneapps en incluant le code source. Mais son développement a été arrêté. Mais ne désespérez pas, la communauté l'a récupéré et l'a amélioré. Il a un nouveau foyer sur SourceForge.

Notez que si vous vous authentifiez en utilisant SSPI, alors vous n'avez plus besoin de la ligne AuthUserFile pour définir un fichier de mot de passe. Apache authentifie votre nom d'utilisateur et votre mot de passe avec votre domaine Windows à la place. Vous devrez mettre à jour la liste d'utilisateurs dans votre svnaccessfile pour faire aussi référence au DOMAINE\nom d'utilisateur.

Il est aussi possible d'avoir plus d'une source d'authentification pour votre référentiel Subversion. Pour ce faire, vous devez rendre chaque type d'authentification non définitive, pour qu'Apache vérifie plusieurs sources pour la correspondance nom utilisateur/mot de passe.

Un scénario fréquent consiste à utiliser l'authentification par le domaine Windows et par fichier passwd, pour que vous puissiez fournir un accès SVN aux utilisateurs qui ne possèdent pas de login dans le domaine Windows.

Here is an example of the full Apache configuration for combined Windows domain and passwd file authentication:

<Location /svn>
  DAV svn
  SVNListParentPath on
  SVNParentPath D:\SVN

  AuthName "Subversion repositories"
  AuthzSVNAccessFile svnaccessfile.txt

# NT Domain Logins.
  AuthType SSPI
  SSPIAuth On
  SSPIAuthoritative Off
  SSPIDomain <domaincontroller>
  SSPIOfferBasic On

# Htpasswd Logins.
  AuthType Basic
  AuthBasicAuthoritative Off
  AuthUserFile passwd

  Require valid-user
</Location>

Even though Apache 2.2.x has OpenSSL support, it is not activated by default. You need to activate this manually.

<Location /svn>
  DAV svn
  SVNParentPath D:\SVN
  SSLRequireSSL
  AuthType Basic
  AuthName "Subversion repositories"
  AuthUserFile passwd
  #AuthzSVNAccessFile svnaccessfile
  Require valid-user
</Location>

Sent to the TortoiseSVN mailing list by Nigel Green. Thanks!

In some server configurations you may need to setup a single server containing 2 virtual SSL hosts: The first one for public web access, with no requirement for a client certificate. The second one to be secure with a required client certificate, running a Subversion server.

Adding an SSLVerifyClient Optional directive to the per-server section of the Apache configuration (i.e. outside of any VirtualHost and Directory blocks) forces Apache to request a client Certificate in the initial SSL handshake. Due to a bug in mod_ssl it is essential that the certificate is requested at this point as it does not work if the SSL connection is re-negotiated.

The solution is to add the following directive to the virtual host directory that you want to lock down for Subversion:

SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"

This directive grants access to the directory only if a client certificate was received and verified successfully.

To summarise, the relevant lines of the Apache configuration are:

SSLVerifyClient Optional

### Virtual host configuration for the PUBLIC host 
### (not requiring a certificate)

<VirtualHost 127.0.0.1:443>
  <Directory "pathtopublicfileroot">
  </Directory>
</VirtualHost>

### Virtual host configuration for SUBVERSION 
### (requiring a client certificate)
<VirtualHost 127.0.0.1:443>
  <Directory "subversion host root path">
    SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"
  </Directory>

  <Location /svn>
    DAV svn
    SVNParentPath /pathtorepository
  </Location>
</VirtualHost>