@node Administration des Dépôts
@chapter Administration des Dépôts
Comment administrer un dépôt Subversion.
Dans cette section, nous nous concentrerons sur comment utiliser les
programmes @command{svnadmin} et @command{svnlook} pour travailler avec
des dépôts.
@menu
* Créer un dépôt::
* Examiner un dépôt::
* Accroches d un dépôt::
* Maintenance d un dépôt::
* Mettre un dépôt sur le réseau::
* Migrer un dépôt::
* WebDAV::
@end menu
@c ------------------------------------------------------------------
@node Créer un dépôt
@section Créer un dépôt
Créer un dépôt est incroyablement simple:
@example
$ svnadmin create path/to/myrepos
@end example
Ceci crée un nouveau dépôt dans le sous-répertoire @file{myrepos}.
(Notez que les programmes @command{svnadmin} et @command{svnlook} opère
@emph{directement} sur un dépôt car ils utilisent la librairie
@file{libsvn_fs.so}. Ainsi, ces outils attendent un chemin local ordinaire
vers le dépôt. Ceci est en opposition avec le programme client
@command{svn}, qui accède toujours à un dépôt via une URL de type
@url{http://} ou @url{file://}.)
Un nouveau depôt commence toujours sa ``vie'' à la révision 0, qui est
défini pour n'être rien saut le répertoire racine (@file{/}).
Comme mentionné précédament, les révisions de dépôt peuvent avoir des
propriétés non versionnées qui lui sont attachées. En particulier, chaque
révision est créée avec une propriété ``date de modification''
@samp{svn:date} (les autres propriétés communes incluent @samp{svn:author}
et @samp{svn:log}).
Pour un dépôt nouvellement créé, la révision 0 n'a rien sauf la propriété
@samp{svn:date} attachée.
Voici un arrêt rapide sur l'anatomie d'un dépôt:
@example
$ ls myrepos
conf/
dav/
db/
hooks/
locks/
@end example
@table @samp
@item conf
Actuellement inutilisé; les fichiers de configuration côté dépôt
arriveront un jour ici.
@item dav
Si le dépôt est accédé par Apache et mod_dav_svn, des bases de données
privées de gestion sont stockées ici.
@item db
L'environnement principal de ``Berkeley DB'', c'est plein de tables DB qui
comprennent les données stokées par libsvn_fs. C'est ici que toutes vos
données sont! En particulier, la plupart de vos contenus de fichiers
arrivent dans la table ``strings''. Les fichiers log s'accumulent aussi ici,
ainsi les transactions peuvent être récupérées.
@item hooks
C'est ici que ce trouve les fichiers d'accroche de pré-remontée et
post-remontée (et un jour, une accroche de lecture).
@item locks
Un simple fichier se trouve ici; les lectures et écriveurs prennent un
vérrou partagé sur ce fichier. Ne pas supprimer ce fichier.
@end table
Une fois que le dépôt a été créé, il est très probable que vous vouliez
utiliser le client svn pour importer une arborescence initiale. (essayez
@samp{svn help import}, ou @xref{Autres commandes}.)
@c ------------------------------------------------------------------
@node Examiner un dépôt
@section Examiner un dépôt
@subsection Transactions et Révisions
Un dépôt Subversion est essentiellement une séquence d'arborescence;
chaque arborescence est appelée une @dfn{révision}. Si ceci est nouveau
pour vous, il serait bon que vous lisiez
@ref{Transactions et numéro de révision}.
Chaque révision commence comme une @dfn{transaction} d'arborescence. Quand
vous faites une remontée, un client construit une transaction qui copie
ses modifications locales, et lorsque la remontée a réussie, la
transaction est effectivement promue en une nouvelle révision
d'arborescence et un nouveau numéro de révision lui est assigné.
Les mise à jour fonctionnent de façon similaire: le client contruit une
transaction d'arborescence qui est un ``mirroir'' de sa copie de travail.
Le dépôt alors compare la transaction d'arborescence avec une révision de
l'arborescence, et envoie en retour un delta des arborescences. Lorsque
la mise à jour est terminée, la transaction est terminée et supprimée du
dépôt.
L'utilisation de transaction d'arborescence est le seul moyen pour
'écrire' dans le système de fichier versionné du dépôt; tous les
utilisateurs de libsvn_fs font çà. Cependant, il est important de
comprendre que la durée de vie de la transaction est totalement flexible.
Dans le cas d'une mise à jour, la transaction d'arborescences est
temporaires et immédiatement détruites. Dans le cas d'une remontée,
les transactions sont transformées en une révision permanente (ou
abandonnées si la remontée échoue). Dans le cas d'une erreur ou d'un bug,
il est possible que la transaction soit accidentellement soit laissée tel
quel -- l'appelant de libsvn_fs peut mourrir avant de la supprimer. Et en
théorie, un jour une application de workflow entière pourra faire des
réparations lors de la creation des transaction; elles pourraient être
examinées alternativement par différents gestionnaires avant d'être
supprimées pour promues à une révision.
Le fait est que si vous êtes en train d'administrer un dépôt Subversion,
vous allez devoir examiner les révisions et les transactions. Celà fait
partie du travail de suveillance de la bonne santé de votre dépôt.
@subsection @command{svnlook}
@command{svnlook} est un outil qui travail en lecture-seule@footnote{
pourquoi en lecture-seule? parce que si un script d'accroche de
pré-remontée modifie la transaction avant que la remontée soit faite, la
copie de travail n'aura aucune moyen pour savoir ce qui c'est passé, et
serait donc désynchronisé sans le savoir. Subversion n'a actuellement
aucun moyen pour traiter cette situation, et peut-être ne l'aura jamais.}
et qui peut-être utilisé pour examiner les révisions et les transactions
d'arborescences d'un dépôt. Il est utile pour les administrateurs système,
et peut également être utilisé par les scripts d'accroche de pré-remontée,
(@file{pre-commit}), ou post-remontée, @file{post-commit}.
L'utilisation la plus simple est:
@example
$ svnlook repos
@end example
Celà imprime des informations sur la dernière révision dans le dépôt
``repos''. En particulier, elle montrera les descriptions de modification,
l'auteur, la date, et un diagramme de l'arborescence.
Pour regarder à une révision ou une transaction particulière:
@example
$ svnlook repos rev 522
$ svnlook repos txn 340
@end example
Ou, si vous voulez uniquement voir certains type d'information,
@command{svnlook} accèpte plusieurs sous-commandes. par exemple:
@example
$ svnlook repos rev 522 log
$ svnlook repos rev 559 diff
@end example
Les sous-commandes disponibles sont:
@table @samp
@item @samp{log}
Affiche la description des modifications de l'aborescence.
@item @samp{author}
Affiche l'auteur de l'arborescence.
@item @samp{date}
Affiche la date de l'arborescence.
@item @samp{dirs-changed}
Affiche la liste des répertoires qui ont changé dans l'arborescence.
@item @samp{changed}
Affiche la liste de tous les fichiers et répertoires qui ont changé dans
l'arborescence.
@item @samp{diff}
Affiche un ``unified diff'' des fichiers modifiés.
@end table
@subsection l'interpréteur de commande
L'outil @command{svnadmin} a un mode avec un interpréteur de commande
'jouet'. Il n'en fait pas beaucoup, mais il permet de ``fourrager'' dans
le le dépôt comme s'il y avait une mountage de système de fichier
imaginaire. Les commandes de base @samp{cd}, @samp{ls}, @samp{exit}, et
@samp{help} sont disponibles, aussi bien que la très spéciale commande
@samp{cr} -- ``changer de révision''. La dernière commande vous permet de
vous déplacer entre révisions d'arborescence.
@example
$ svnadmin shell repos
<609: />$
<609: />$ ls
< 1.0.2i7> [ 601] 1 0 trunk/
<nh.0.2i9> [ 588] 0 0 branches/
<jz.0.18c> [ 596] 0 0 tags/
<609: />$ cd trunk
<609: /trunk>$ cr 500
<500: /trunk>$ ls
< 2.0.1> [ 1] 0 3462 svn_config.dsp
< 4.0.dj> [ 487] 0 3856 PORTING
< 3.0.cr> [ 459] 0 7886 Makefile.in
< d.0.ds> [ 496] 0 9736 build.conf
< 5.0.d9> [ 477] 1 0 ac-helpers/
< y.0.1> [ 1] 0 1805 subversion.dsp
@dots{}
<500: />$ exit
@end example
L'affichage de @samp{ls} a seulement quelques colonnes:
@example
NODE-ID CREATED-REV HAS_PROPS? SIZE NAME
< 1.0.2i7> [ 601] 1 0 trunk/
<nh.0.2i9> [ 588] 0 0 branches/
<jz.0.18c> [ 596] 0 0 tags/
@end example
@c ------------------------------------------------------------------
@node Accroches d un dépôt
@section Accroches d un dépôt
Une @dfn{accroche} est un programme déclenché par un accès en lecture ou
écriture au dépôt. L'accoche reçoie suffisament d'information pour dire
quel est l'action, la/les cibles de l'opération, et qui le fait. En
fonction de la sortie ou du code de retour de l'accroche, le programme
d'accroche peut continuer l'action, la stopper, ou la suspendre
d'une certaine manière.
Les accroches de Subversion sont des programme qui résident dans le
répertoire @file{hooks} du dépôt:
@example
$ ls repos/hooks/
post-commit.tmpl* read-sentinels.tmpl write-sentinels.tmpl
pre-commit.tmpl* start-commit.tmpl*
@end example
C'est ainsi que le répertoire @file{hooks} apparait après la création d'un
dépôt. Il ne contient aucun programmes d'accroche -- ce ne sont que des
modèles.
Les accroches actuelles doivent être nommées @file{start-commit},
@file{pre-commit} ou @file{post-commit}. Les fichiers modèles (.tmpl) sont des exemples de
script shell pour vous aider à commencer; lisez les pour connaitre les
détails de fonctionnement de chaque accroche. Pour faire vos propre
accroche, copié @file{foo.tmpl} en @file{foo} et éditez le.
Les @file{read-sentinels} et @file{write-sentinels} ne sont pas encore
implémentés. Leurs intentions est d'offrir un fonctionnement plus proche
du démon que des accroches. Une sentinelle (Ndt: c'est la bonne traduction
?) est démarré au début d'une opération utilisateur. Le serveur Subversion
commnunique avec la sentinelle en utilisant un protocole encore a définir.
En fonction de la réponse de la sentinelle, Subversion va peut-être
stopper ou modifier l'opération.
Voici une description des programmes d'accroche:
@table @samp
@item @file{start-commit}
Le programme est exécuté avant que la transaction de remontée soit créée.
C'est typiquement utilisé pour décider si l'utilisateur à les privilèges
de remonter des modifications dans le dépôt. Le dépôt passe deux arguments
à ce programme: le chemin vers le dépôt, et le nom de l'utilisateur qui
tente la remontée. Si le programme retourne un code de sortie différent de
zéro, la remontée est stoppée avant que la transaction ne soit créée.
@item @file{pre-commit}
Ce programme est exécuter quand la transaction est complète, mais avant
quelle soit validée. Typiquement, cette accroche est utilisée pour
protéger contre des remontées qui ne sont pas authorisées à cause du
contenu ou du lieu (par exemple, votre site pourrait exiger que toutes
les remontées à une certaine branche inclues un numéros de ticket du
système de traçage de bug, ou que la description des modifications
arrivant soit non vide.)@footnote{Actuellement, c'est la seule méthode
part laquelle un utilisateur peut implémenter un contrôle d'accès avec une
granulosité fine; au-delà des facilités offertes pas Apache
(@file{httpd.conf}). Dans une future version de Subversion, Nous
planifions d'implémenter une système d'ACL (Liste de Control d'Accès)
directement dans le système de fichier.} Le dépôt passe deux paramètres à
ce programme: le chemin vers le dépôt et le nom de la transaction en
attende de validation. Si le programme retourne un code de sortie
différente de zéro, la remontée est annulée et la transaction supprimée.
Subversion inclut le script @file{tools/hook-scripts/commit-access-control.pl}
qui peut être appelé depuis @file{pre-commit} pour implémenter un contrôle
d'accès plus fin.
@item @file{post-commit}
Ce programme est exécuté après que la transation soit réalisée et que nous
avons une nouvelle révision. La plupart des gens utilise cette accroche
pour envoyer des emails decrivant la remontée ou pour réaliser une
sauvegarde à chaud du dépôt. Le dépôt passe deux arguments à ce programme:
le chemin vers le dépôt et le nouveau numéros de révision qui a été créé.
Le code de sortie du programme est ignoré.
Subversion inclut le script @file{tools/hook-scripts/commit-email.pl} qui
peut être utilisé pour envoyer les modifications appliquées par la
remontée à un nombre quelconque d'adresse de courrier électronique.
Le script @file{tools/backup/hot-backup.py}, également inclut, permet de
faire des sauvegardes à chaud de votre dépôt Subversion après chaque
remontée.
@end table
Notez que les accroches doient être exécutable part l'utilisateur qui
les lance (communément l'utilisateur qui exécute httpd) et que ce même
utilisateur doit être capable d'accèder au dépôt.
Les accroches de pre-remontée (@file{pre-commit}) et de post-remontée
(@file{post-commit}) ont besoin de connaitre des choses a propos des
modifications qui vont être remontées (ou qui viennent d'être remontée).
La solution est un programme indépendant, @command{svnlook}
(@xref{Examiner un dépôt}.) qui est installé au même endroit que le
binaire @command{svn}. Le script peut utiliser @command{svnlook} pour
examiner une transaction ou une révision d'arborescence. Il produit une
sortie qui est aussi visible par un humain que par un programme, ainsi les
scripts d'accroche peuvent facilement le parser. Notez que `svnlook'
travail en lecture-seule -- il ne peut que inspecter et ne peut pas
modifier le dépôt.
@c ------------------------------------------------------------------
@node Maintenance d un dépôt
@section Maintenance d un dépôt
@subsection Gestion de Berkeley DB
Actuellement, le dépôts de Subversion n'a qu'un moteur de base de données:
Berkeley DB. Toute votre structure de système de fichier et vos données
sont dans un ensemble de tables dans @file{repos/db/}.
Berkeley DB est livré avec des outils pour gérer ces fichiers, et ont
leure propre et excellente documenations. (voir
@url{http://www.sleepycat.com}, ou lisez juste les pages man.) Nous ne
couvrirons pas tous ces outils ici; nous mentionnerons quelqu'une des
procédures les plus communes dont un administrateur de dépôt pourrait
avoir besoin.
Premièrement, rappelez vous que Berkeley DB a de véritables transactions.
toutes tentatives de modifications de la DB (Data-Base, Base de Donnée)
est un premier loggué. Au moindre problème, la DB peut retourner
d'elle-même en arrière au précédent ``point de contrôle'' et recommencer
la transaction pour récupérer les données dans le même état.
Selon notre propre expérient, nous avons rencontré des situations ou un
bug dans Subversion (qui produit un plantage) peut parfois avoir l'effet
de bord de laisser d'environnement de DB dans un état ``vérouillé''. Les
tentatives suivantes de lecture ou écriture reste bloquées, en attente sur
le verrou.
Pour ``débloquer'' le dépôt, utilisez @command{db_recover}:
@example
$ db_recover -ve -h repos/db
db_recover: Finding last valid log LSN: file: 40 offset 4080873
db_recover: Checkpoint at: [40][4080333]
db_recover: Checkpoint LSN: [40][4080333]
db_recover: Previous checkpoint: [40][4079793]
db_recover: Checkpoint at: [40][4079793]
db_recover: Checkpoint LSN: [40][4079793]
db_recover: Previous checkpoint: [40][4078761]
db_recover: Recovery complete at Sun Jul 14 07:15:42 2002
db_recover: Maximum transaction id 80000000 Recovery checkpoint [40][4080333]
@end example
Premièrement, assurez vous que vous exécutez cette commande avec le compte
de la base de donnée et @emph{non} en tant que root. En exécutant
@command{db_recover} sous le compte root, celà laissera des fichiers avec
le propriétaire root dans le répertoire db qui ne pourront être ouvert par
le compte non root qui gère la base de donnée et qui est typiquement le
compte du processus Apache.
Deuxièmement, un administrateur de dépôt peut avoir besoin de gérer le
grossissement des fichiers log. A tout instant, l'environnement DB
utilise au moins un fichier log pour enregistrer la transactions; lorsque
le ficheir log actuel grossi jusqu'à 10 méga octet, un nouveau fichier log
est débuté, et l'ancien reste.
Ainsi, après une longue periode, vous constaterez un nombre important de
fichiers log. A ce moment là, vous avez deux choix : si vous laissez
tous les fichiers log, vous avez la garantie que @command{db_recorer}
pourra toujours ``rejouer'' chaques transactions de la base de donnée,
depuis la première remontée (ceci est la méthose sûre et un peu
paranoïaque). L'autre méthode, est de demander à Berkeley DB de vous dire
quels fichiers log ne sont plus activement utilisés :
@example
$ db_archive -a -h repos/db
log.0000000023
log.0000000024
log.0000000029
@end example
Notre dépôt de Subversion utilise une script d'accroche de post-remontée
(@file{post-commit}), qui après avoir réalisé une sauvegarde à chaud du
dépôt, supprime ces fichiers log excédentaire. Dans les sources de
Subversion, regardez @file{tools/backup/hot-backup.py}.
Ce script illustre également une méthode sûre de faire une sauvegarde du
dépôt alors qu'il reste en cours d'utilisation: copier tout le repertoire
du dépôt, puis recopier les fichiers log listé par la commande
@samp{db_recorer -l}.
Pour utiliser un dépôt de sauvegarde que vous venez de restaurer, assurez
vous d'exécuter la commande @samp{db_recover -ve} dans l'espace @file{db}
en premier. Ceci garanti que toutes transactions non-terminées soient
complètement ``jouées'' avant que le dépôt ne soit utilisé à nouveau.
Enfin, noté que Berkeley DB a un système de verrouillage complet; dans des
cas d'opérations extémement intense de svn, nous avons constaté des
situations où l'envirennement de DB n'a plus suffisament de verroux. Le
nombre maximum de verrou peut-être ajusté en changant les valeurs dans
le fichier @file{repos/db/DB_CONFIG}. Ne changez pas les valeurs par
défaut sans savoir exactement ce que vous faites; Voyez sûr d'avoir lu
@uref{http://www.sleepycat.com/docs/ref/lock/max.html} en premier.
@subsection Utilisation de svnadmin
L'outil @command{svnadmin} a des sous-commandes qui sont spécifiquement
utiles à un administrateur de dépôt. Faites attention lorsque vous
utilisez @command{svnadmin}! @command{svnadmin} contrairement à
@command{svnlook}, qui ne fonctionne qu'en lecture seule, peut modifier
le dépôt.
La fonctionnalité la plus utilisée est probablement @samp{svadmin
setlog}. Une description de modification est une propriété unversionnée
directement attaché à la révision; Il n'y a qu'une seule description de
modification par révision. Parfois l'utilisateur a remonté sa description
de modification et il a besoin de la remplacer.
@example
$ echo "Here is the new, correct log message" > newlog.txt
$ svnadmin setlog myrepos 388 newlog.txt
@end example
Il y a un sympathique script CGI dans @file{tools/cgi/} qui permet à
certain (avec un mot de passe d'accès) de modifier les descriptions de
message via un navigateur web.
Un autre usage courant de @command{svnadmin} est d'inspecter et de
nettoyer de vieilles transactions abandonnées. Les remontées et les mises
à jour créent toutes les deux des transactions d'arborescence, mais
occasionnellement un bug ou un plantage peut les laisser telles quelles.
En inspectant la date de la transaction, un administrateur peut decider la
supprimer.
@example
$ svnadmin lstxns myrepos
319
321
$ svnadmin lstxns --long myrepos
Transaction 319
Created: 2002-07-14T12:57:22.748388Z
@dots{}
$ svnadmin rmtxns myrepos 319 321
@end example
@c ### Hey guys, are going to continue to support @samp{svnadmin undeltify}??
Une autre sous-commande très utilisée est @samp{svnadmin undeltify}.
Rappelez vous que la dernière version de chaque fichier est stockée en
entier dans le dépôt, et les révisions précédentes des fichiers sont
stockés comme différences par rapport à la révision suivant la plus
proche. Lorsqu'un utilisateur tente un accès à une révision antérieur, le
dépôt doit appliquer à rebours les différences au plus récent des contenus
complet pour obtenir la version antérieur désirée.
Si une révision d'arborescence particulière est très populaire,
l'administrateur peut améliorer le temps d'accès à cette arborescence en
``undeltifying'' (supprimer les différences) tous les patches dans la
révision -- C'est-à-dire en convertissant chaque fichier en contenu
complet.
@example
$ svnadmin undeltify myrepos 230 /project/tags/release-1.3
Undeltifying `/project/tags/release-1.3' in revision 230...done.
@end example
@c ------------------------------------------------------------------
@node Mettre un dépôt sur le réseau
@section Mettre un dépôt sur le réseau
Vous avez donc un dépôt et vous voulez le rendre accessible pour tout le
réseau.
Le serveur réseau primaire de Subversion est httpd d'Apache parlant le
protocole WebDav/deltaV, qui est un ensemble d'extension à http. Pour plus
d'information sur DAV, voir @uref{http://www.webdav.org}.
Pour rendre votre dépôt accessible depuis le réseau, vous devez
@itemize @bullet
@item
avoir httpd 2.0 fonctionnant avec le module mod_dav
@item
installer le greffon mod_dav_svn pour mod_dav, qui utilise la librairie
d'accès au dépôt de Subversion
@item
configurer votre fichier @file{httpd.conf} pour exporter le dépôt
@end itemize
Vous pouvez accomplir les deux premiers en contruisant httpd et Subversion
depuis les sources ou en installant un paquetage binaire sur votre
système. Le second appendice de ce document contient plus d'instruction
détaillées pour le faire. (@xref{Compilation et installation}.) Des
instructions sont également disponibles dans le fichier @file{INSTALL}
dans les sources de Subversion.
Dans cette section, nous nous concentrerons sur la configuration de votre
fichier @file{httpd.conf}.
Quelque part au début de votre fichier de configuration, définissez un
nouveau bloque @samp{Location}:
@example
<Location /repos>
DAV svn
SVNPath /absolute/path/to/myrepos
</Location>
@end example
Ceci rend le dépôt @file{myrepos} disponible à l'URL
@url{http://hostname/repos}, sans aucune restriction d'accès :
@itemize @bullet
@item
Chaqu'un peut utiliser son client svn pour sortir une copie de travail, ou
de toute URL qui correspond à un sous-répertoire du dépôt.
@item
En pointant un navigateur web ordinaire à l'URL, toute personne peut
naviger intérectivement dans la dernière révision.
@item
Tout le monte peut remonter des modifications au dépôt.
@end itemize
Si vous voulez restreindre en lecture ou écriture l'accès à l'ensemble du
dépôt, vous pouvez utiliser les facilités de contrôle d'accès d'Apache.
Premièrement, créé un fichier vide qui contiendra les noms d'utilisateur
et leur mot de passe. Renseigné les noms et les mots de passe cryptés dans
le fichier comme ci-dessous:
@example
joe:Msr3lKOsYMkpc
frank:Ety6rZX6P.Cqo
mary:kV4/mQbu0iq82
@end example
Vous pouvez générer les mots de passe cryptés en utilisant une commande
@samp{crypt(3)} standard ou en utilisant l'outil @command{htpasswd}
présent dans le répertoire @file{bin} d'Apache.
@example
$ /usr/local/apache2/bin/htpasswd -n sussman
New password:
Re-type new password:
sussman:kUqncD/TBbdC6
@end example
Puis ajoutez ces quelques lignes dans votre block @samp{<Location>} qui
pointent sur le fichier des utilisateurs:
@example
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/users/file
@end example
Si vous voulez restreindre @emph{tout} accès au dépôt, ajouter une ligne
supplémentaire:
@example
Require valid-user
@end example
Cette ligne fait qu'Apache exigent un utilisateur authentifié pour toutes
les requêtes http à votre dépôt.
Pour restreindre les accès en écriture uniquement, vous devez exiger un
utilisateur authentifié pour toutes les méthodes de requête sauf celles
qui sont de type lecture seule:
@example
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
@end example
Ou, si vous voulez quelque chose de plus astucieux, vous pouvez créer deux
groupes d'utilisateurs séparés, un pour les utilisateurs en lecture, un
autre pour les utilisateurs en écriture:
@example
AuthGroupFile /my/svn/group/file
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require group svn_committers
</LimitExcept>
<Limit GET PROPFIND OPTIONS REPORT>
Require group svn_committers
Require group svn_readers
</Limit>
@end example
Ce ne sont que de simples exemples. Pour un tutorial complet sur les
contrôle d'accès d'Apache, regarder
@uref{http://httpd.apache.org/docs-2.0/misc/tutorials.html}.
Autre remarque: pour que @samp{svn cp} marche (ce qui est actuellement
implémenté comme une requête DAV COPY), mod_dav doit être capable de
déterminer le hostname du serveur. Un moyen standard est d'utiliser la
directive ServerName d'Apache pour fixer le hostname du serveur.
Ndt: si UseCanonicalName d'apache est sur off il n'est pas forcément
nécessaire de renseigner ServerName. Je vous conseile d'essayer en
premier ``UseCanonicalName Off'' qui pose moins de problème lors des
redirections par Apache.
Editez votre @file{httpd.conf} pour inclure:
@example
ServerName svn.myserver.org
@end example
Si vous utilisez le ``virtual hosting'' d'apache avec la directive
@samp{NameVirtualHost}, vous pourrez avoir besoin d'utiliser la directive
@samp{ServerAlias} pour spécifier des noms additionnels par lesquels votre
serveur est connu.
Si vous n'est pas familier avec une directive d'Apache, ou pas très sûr
de ce qu'elle fait, n'hésitez pas à consulter la documentation:
@uref{http://httpd.apache.org/docs-2.0/mod/directives.html}.
Vous pouvez tester votre dépôt exporté en lançant httpd:
@example
$ /usr/local/apache2/bin/apachectl stop
$ /usr/local/apache2/bin/apachectl start
@end example
Contrôler @file{/usr/local/apache2/logs/error_log} pour être sûre que sont
démarrage est OK. Essayez une sortie via le réseau de votre dépôt:
@example
$ svn co http://localhost/repos wc
@end example
La raison la plus commune pour que celà ne marche pas est un problème de
permission de lecture/écriture des fichiers db du dépôt. Assurez-vous que
l'utilisateur ``nobody'' (ou un autre UID utilisé par le processus httpd)
a les permissions de lecture et écriture aux fichiers Berkeley DB! C'est
le problème le plus courant.
Vous pouvez voire toute les ``plaintes'' de mod_dav_svn dans le fichier
d'erreur d'Apache, @file{/usr/local/apache2/logs/error_log} ou ailleur
en fonction de votre installation d'Apache. Pour plus d'information sur le
traçage des problèmes, regardez ``Debugging the server'' dans le fichier
@file{HACKING}.
@c ------------------------------------------------------------------
@node Migrer un dépôt
@section Migrer un dépôt
Parfois des situations spéciales arrivent où vous devez déplacer tout
votre donnée du système de fichier d'un dépôt vers un autre. Le schéma du
système de fichier de la base de données a changé dans une nouvelle
version de Subversion, ou peut-être vous voulez utiliser un moteur de base
de donnée différent.
Quoiqu'il en soit, vos données doivent être migrées vers un nouveau
dépôt. Pour le faire, vous avez les commandes @samp{svnadmin dump} et
@samp{svnadmin load}.
@samp{svnadmin dump} écrit un flux de vos données de votre dépôt vers
la sortie standard (stdout):
@example
$ svnadmin dump myrepos > dumpfile
* Dumped revision 0.
* Dumped revision 1.
* Dumped revision 2.
@dots{}
@end example
Ce flux décrit toutes les révisions dans votre dépôt comme un liste de de
modifications à des noeuds. C'est principalement du texte lisible par un
humain; mais lorsqu'un contenu de fichier change, le contenu entier est
envoyé dans le flux. Si vous avez des fichiers binaires ou des propriétés
binaires dans votre dépôt, ces parties du flux pourront être moins lisible
pour un humain. Plus loin, le flux complet sera appelé un dump.
Après avoir extrait vos données, vous pouvez déplacer le fichier vers un
système différent (ou quelque part ou l'environnement utilise une version
différente de @command{svnadmin} et/ou @file{libsvn_fs.so}), et créer un
``nouveau'' style de dépôt qui a un nouveau schéma ou moteur de base de
données.
@example
$ svnadmin create newrepos
@end example
La commande @samp{svnadmin load} est d'entreprendre de lire le dump
depuis l'entrée standard (stdin) et de rejouer chaques remontées:
@example
$ svnadmin load newrepos < dumpfile
<<< Started new txn, based on original revision 1
* adding path : A ... done.
* adding path : A/B ... done.
@dots{}
------- Committed new rev 1 (loaded from original rev 1) >>>
<<< Started new txn, based on original revision 2
* editing path : A/mu ... done.
* editing path : A/D/G/rho ... done.
------- Committed new rev 2 (loaded from original rev 2) >>>
@end example
Voilà, vos révisions ont été remontées dans le nouveau dépôt.
@subsection Stupide dump/load astuces
Les personne que aime ``copiner'' avec Unix peuvent essayer des choses comme
celles ci:
@example
$ svnadmin create newrepos
$ svnadmin dump myrepos | svnadmin load newrepos
@end example
Il est aussi possible de créer une série de petits fichiers dump et de les
charger en série (Dans le cas où un unique fichier dump est trop grop pour
rentrer sur le media de sauvegarde). Mais celà demande un peu de boulot.
@example
$ svnadmin dump myrepos 0 2000 > dumpfile1
$ svnadmin dump myrepos 2000 4000 > dumpfile2
@end example
Donc maintenant vous avez deux fichiers de dump. Le premier contient les
révision 0 à 2000, et le second contient les révisions 2000 à 4000.
Pourquoi le recouvrement ?
Voici le pourquoi. La première révision extraite par @samp{svnadmin
dump} est toujours comparée à la révision 0 qui est juste le répertoire
racine @file{/} vide. Ceci signifie que la première révision de tout dump
resemble toujours à une gigantesque liste de noeuds ``ajoutés''. Ce choix
a été fait pour que tout fichier comme @file{dumpfile2} puisse être
directement chargé dans un dépôt vide.
Mais il y a un inconvénient à cet avantage. Lorsque nous voulons charger
plusieurs fichiers de dump à la suite, Nous devons être sûr que chaques
fichiers se recouvrent par au moins une révision. Avant le chargement, la
première révision d'un fichier comme @file{dumpfile2} doit être
@emph{supprimé}, ainsi le fichier commence par une description de la
révision 2001 comme une différence d'arborescence par rapport à la
révision 2000:
@itemize @bullet
@item
Ouvrire le @file{dumpfile2} dans un éditeur
@item
ne @emph{pas} supprimer la ligne d'entête
@samp{SVN-fs-dump-format-version} au début du fichier.
@item
@emph{supprimer} la première révision, qui commence avec un enregistrement
@samp{Revision-number:}, et qui va jusqu'au prochain bloque
@samp{Revision-number:}.
@end itemize
Une fois que vos fichiers de dump ont été proprement ``ajustés'', vous
pouvez les charger avec la séquence:
@example
$ svnadmin load newrepos < dumpfile1
$ svnadmin load newrepos < dumpfile2
@end example
@c ------------------------------------------------------------------
@node WebDAV
@section WebDAV
WebDAV est le protocole réseau utilisé par Subversion. DAV (Distributed
Authoring and Versioning : publication et versionnement distribué). Nous
discuterons ici de ce que celà signifie pour vous, actuellement et dans le
futur.
WebDAV a été conçu pour faire du web un medium en lecture/écriture,
au-lieu d'un medium en lecture seule (comme c'est principalement le cas
actuellement). La principe de base est que les répertoires et les fichiers
peuvent être partagés à travers le web en utilisant une extension
standardisée d'HTTP. La RFC 2518 décrit l'extension WebDAV d'HTTP, et est
disponible (avec beaucoup d'autres informations utiles) à
@uref{http://www.webdav.org/}.
Actuellement, un grand nombre de gestionnaire de fichier de système
d'exploitation sont capable de ``monter'' un répertoire réseau utilisant
WebDAV. Sur Win32, l'Explorateur Windows peut naviguer dans ce qu'il
appèle un ``Dossier Web'', comme avec d'autres répertoires partagés. Mac
OS X a également cette capacité comme le navigateur Nautilus de GNOME.
Cependant, la RFC 2518 n'implémente pas complètement l'aspet versionnement
de WebDAV. Un commité séparé a créé la RFC 3253, connue comme l'extension
@dfn{DeltaV} de WebDAV, et disponible à @uref{http://www.webdav.org/deltav/}.
Ces extensions ajoutent le concept de contrôle de version à HTTP et c'est
ce qu'utilise Subversion.
Il est important de comprendre que bien que Subversion utilise DeltaV pour
communiquer, le client Subversion n'est @emph{pas} un client à usage
général de DeltaV. En fait, il attend des fonctionnalitées personnalisées
du serveur. De même, le serveur Subversion n'est pas un serveur à usage
général de DeltaV. Il implémente un strict sous-ensemble des
spécifications de DeltaV. Un client WebDAV ou DeltaV pourait très bien
communiquer avec, mais uniquement si ce client opère à l'intérieur de ce
faisceau étroit de fonctionnalité que le serveur implémente. Les futures
versions de Subversion apporteront une intéropérabilité plus complète de
WebDAV.
Au moment de l'écriture de ce guide, la plupart des navigateurs DAV et des
clients ne supporte pas encore DeltaV; ceci signifie qu'un dépôt
Subversion peut uniquement être consulté ou monté uniquement comme une
ressource en lecture-seule. (une requête ``PUT'' HTTP est valide
lorsqu'elle est envoyée à un serveur uniquement WebDAV, mais un serveur
DeltaV tel que mod_dav_svn ne le permet pas. Le client doit utiliser des
méthodes spéciales de contrôle de version pour écrire sur le serveur.)
Et, de l'autre côté, un client Subversion ne peut pas sortir une copie de
travail d'un serveur WebDAV générique; il attend un sous-ensemble
spécifique de fonctionnalités DeltaV.
Pour une description détaillée de l'implémentation WebDAV de Subversion, voir
@uref{http://svn.collab.net/repos/svn-repos/trunk/www/webdav-usage.html}.