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.
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 commentaire 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.