This text is a work in progress—highly subject to change—and may not accurately describe any released version of the Apache™ Subversion® software. Bookmarking or otherwise referring others to this page is probably not such a smart idea. Please visit http://www.svnbook.com/ for stable versions of this book.

Gestion de versions automatique

Bien que le client Subversion ne soit pas un client DeltaV complet et que le serveur Subversion n'implémente pas toutes les fonctionnalités d'un serveur DeltaV, il faut se féliciter de l'existence d'une petite lueur d'intéropérabilité WebDAV : la gestion de versions automatique.

La gestion de versions automatique est une fonctionnalité optionnelle définie dans le standard DeltaV. Un serveur DeltaV classique n'autorise pas un client WebDAV non compatible à effectuer des opérations PUT sur un fichier suivi en versions. Pour modifier un tel fichier, le serveur exige un enchaînement précis de requêtes de gestion de versions : quelque chose comme MKACTIVITY, CHECKOUT, PUT, CHECKIN (c'est-à-dire : créer une activité, extraire le fichier suivi en versions, renvoyer le fichier modifié et assortir cette modification d'un commentaire). Mais si le serveur DeltaV supporte la fonctionnalité de gestion de versions automatique, les requêtes en écriture des clients WebDAV ordinaires sont acceptées. Le serveur agit comme si le client avait envoyé l'enchaînement de requêtes approprié, en faisant une propagation « sous le manteau ». En d'autres termes, la gestion de versions automatique permet à un serveur DeltaV de communiquer avec des clients WebDAV ordinaires qui ne disposent pas de fonctionnalités de gestion de versions.

Comme beaucoup de systèmes d'exploitation ont des clients WebDAV intégrés, cette fonctionnalité est particulièrement intéressante pour les administrateurs qui travaillent avec des utilisateurs non techniciens. Imaginez un bureau avec des utilisateurs « ordinaires » sous Microsoft Windows ou Mac OS. Chaque utilisateur « monte » le dépôt Subversion qui apparaît comme un lecteur réseau classique. Ils utilisent le partage réseau comme ils l'ont toujours fait : ils ouvrent les fichiers, les modifient et les sauvegardent. Pendant ce temps, le serveur assure automatiquement la gestion de versions. L'administrateur (ou tout autre utilisateur sachant le faire) peut toujours utiliser un client Subversion pour effectuer des requêtes sur l'historique des fichiers ou récupérer une vieille version.

Ce scénario n'est pas de la science-fiction : c'est du concret qui fonctionne. Pour activer la gestion de versions automatique dans mod_dav_svn, utilisez la directive SVNAutoversioning dans le bloc Location du fichier httpd.conf, comme dans l'exemple suivant :

<Location /depot>
  DAV svn
  SVNPath /var/svn/depot
  SVNAutoversioning on
</Location>

Quand la gestion de versions automatique de Subversion est active, les requêtes en écriture des clients WebDAV sont automatiquement transformées en propagations. Un message de propagation générique est créé et associé automatiquement à chaque révision.

Cependant, avant d'activer cette fonctionnalité, comprenez bien dans quoi vous vous engagez. Les clients WebDAV ont tendance à effectuer beaucoup de requêtes en écriture, ce qui engendre un nombre astronomique de propagations automatiques. Par exemple, lors d'une sauvegarde d'un fichier, beaucoup de clients effectuent un PUT pour un fichier de 0 octets (pour signifier qu'ils réservent le nom) suivi par un autre PUT avec les données effectives du fichier. La simple écriture d'un fichier entraîne ainsi deux propagations distinctes. Tenez également compte du fait que de nombreuses applications effectuent des sauvegardes automatiques régulièrement, toutes les cinq minutes par exemple, qui se traduisent par autant de propagations.

Si vous avez une procédure automatique qui envoie un e-mail après chaque propagation (post-commit), il est conseillé de désactiver cet envoi soit complètement soit au moins pour certaines parties du dépôt, selon que ces e-mails vous semblent apporter une plus-value ou pas. De plus, une procédure automatique post-commit bien pensée peut distinguer une propagation générée par la gestion de versions automatique d'une propagation classique. L'astuce consiste à examiner la propriété de révision dénommée svn:autoversioned. Si elle est présente, la propagation est issue d'un client WebDAV.

Une autre caractéristique utile et complémentaire de la gestion de versions automatique de Subversion est fournie par le module mod_mime d'Apache. Si un client WebDAV ajoute un nouveau fichier au dépôt, l'utilisateur n'a pas l'occasion de lui adjoindre la propriété svn:mime-type. Dans ce cas, il se peut que, lors de la navigation dans un répertoire partagé WebDAV, l'icône du fichier soit générique et qu'aucune application ne soit associée à ce fichier. Une solution peut être qu'un administrateur système (ou toute autre personne sachant utiliser Subversion) extraie une copie de travail et définisse manuellement la propriété svn:mime-type sur les fichiers concernés. Mais c'est un peu comme tenter de remplir le tonneau des Danaïdes, alors qu'il suffit de placer la directive ModMimeUsePathInfo dans le bloc <Location> de Subversion.

<Location /depot>
  DAV svn
  SVNPath /var/svn/depot
  SVNAutoversioning on

  ModMimeUsePathInfo on

</Location>

Cette directive autorise mod_mime à déduire automatiquement le type MIME des nouveaux fichiers qui entrent dans le dépôt de la gestion de versions automatique. Ce module examine l'extension du nom de fichier et éventuellement le contenu de celui-ci ; si certains motifs sont repérés, la propriété svn:mime-type est automatiquement renseignée.