Administration des Dépôts
*************************

Comment administrer un dépôt Subversion.

Dans cette section, nous nous concentrerons sur comment utiliser les programmes svnadmin et svnlook pour travailler avec des dépôts.

Créer un dépôt
==============

Créer un dépôt est incroyablement simple:

     $ svnadmin create path/to/myrepos

Ceci crée un nouveau dépôt dans le sous-répertoire myrepos.

(Notez que les programmes svnadmin et svnlook opère directement sur un dépôt car ils utilisent la librairie libsvn_fs.so. Ainsi, ces outils attendent un chemin local ordinaire vers le dépôt. Ceci est en opposition avec le programme client svn, qui accède toujours à un dépôt via une URL de type http:// ou 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 (/).

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'' svn:date (les autres propriétés communes incluent svn:author et svn:log).

Pour un dépôt nouvellement créé, la révision 0 n'a rien sauf la propriété svn:date attachée.

Voici un arrêt rapide sur l'anatomie d'un dépôt:

     $ ls myrepos
     conf/
     dav/
     db/
     hooks/
     locks/

conf
     Actuellement inutilisé; les fichiers de configuration côté dépôt arriveront un jour ici.

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.

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.

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

locks
     Un simple fichier se trouve ici; les lectures et écriveurs prennent un vérrou partagé sur ce fichier. Ne pas supprimer ce fichier.

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 svn help import, ou see Autres commandes.)

Examiner un dépôt
=================

Transactions et Révisions
-------------------------

Un dépôt Subversion est essentiellement une séquence d'arborescence; chaque arborescence est appelée une révision. Si ceci est nouveau pour vous, il serait bon que vous lisiez Transactions et numéro de révision.

Chaque révision commence comme une 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.

svnlook
-------

svnlook est un outil qui travail en lecture-seule (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, (pre-commit), ou post-remontée, post-commit.

L'utilisation la plus simple est:

     $ svnlook repos

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:

     $ svnlook repos rev 522
     $ svnlook repos txn 340

Ou, si vous voulez uniquement voir certains type d'information, svnlook accèpte plusieurs sous-commandes. par exemple:

     $ svnlook repos rev 522 log
     $ svnlook repos rev 559 diff

Les sous-commandes disponibles sont:

log
     Affiche la description des modifications de l'aborescence.

author
     Affiche l'auteur de l'arborescence.

date
     Affiche la date de l'arborescence.

dirs-changed
     Affiche la liste des répertoires qui ont changé dans l'arborescence.

changed
     Affiche la liste de tous les fichiers et répertoires qui ont changé dans l'arborescence.

diff
     Affiche un ``unified diff'' des fichiers modifiés.

l'interpréteur de commande
--------------------------

L'outil 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 cd, ls, exit, et help sont disponibles, aussi bien que la très spéciale commande cr -- ``changer de révision''. La dernière commande vous permet de vous déplacer entre révisions d'arborescence.

     $ 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
     ...
     <500: />$ exit

L'affichage de ls a seulement quelques colonnes:

       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/

Accroches d un dépôt
====================

Une 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 hooks du dépôt:

     $ ls repos/hooks/
     post-commit.tmpl*  read-sentinels.tmpl  write-sentinels.tmpl
     pre-commit.tmpl*   start-commit.tmpl*

C'est ainsi que le répertoire 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 start-commit, pre-commit ou 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é foo.tmpl en foo et éditez le.

Les read-sentinels et 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:

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.

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.) (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 (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 tools/hook-scripts/commit-access-control.pl qui peut être appelé depuis pre-commit pour implémenter un contrôle d'accès plus fin.

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 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 tools/backup/hot-backup.py, également inclut, permet de faire des sauvegardes à chaud de votre dépôt Subversion après chaque remontée.

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 (pre-commit) et de post-remontée (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, svnlook (see Examiner un dépôt.) qui est installé au même endroit que le binaire svn. Le script peut utiliser 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.

Maintenance d un dépôt
======================

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 repos/db/.

Berkeley DB est livré avec des outils pour gérer ces fichiers, et ont leure propre et excellente documenations.  (voir 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 db_recover:

     $ 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]

Premièrement, assurez vous que vous exécutez cette commande avec le compte de la base de donnée et non en tant que root. En exécutant 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 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 :

     $ db_archive -a -h repos/db
     log.0000000023
     log.0000000024
     log.0000000029

Notre dépôt de Subversion utilise une script d'accroche de post-remontée (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 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 db_recorer -l.

Pour utiliser un dépôt de sauvegarde que vous venez de restaurer, assurez vous d'exécuter la commande db_recover -ve dans l'espace 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 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 http://www.sleepycat.com/docs/ref/lock/max.html en premier.

Utilisation de svnadmin
-----------------------

L'outil svnadmin a des sous-commandes qui sont spécifiquement utiles à un administrateur de dépôt. Faites attention lorsque vous utilisez svnadmin! svnadmin contrairement à svnlook, qui ne fonctionne qu'en lecture seule, peut modifier le dépôt.

La fonctionnalité la plus utilisée est probablement 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.

     $ echo "Here is the new, correct log message" > newlog.txt
     $ svnadmin setlog myrepos 388 newlog.txt

Il y a un sympathique script CGI dans 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 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.

     $ svnadmin lstxns myrepos
     319
     321
     $ svnadmin lstxns --long myrepos
     Transaction 319
     Created: 2002-07-14T12:57:22.748388Z
     ...
     $ svnadmin rmtxns myrepos 319 321

Une autre sous-commande très utilisée est 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.

     $ svnadmin undeltify myrepos 230 /project/tags/release-1.3
     Undeltifying `/project/tags/release-1.3' in revision 230...done.

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 http://www.webdav.org.

Pour rendre votre dépôt accessible depuis le réseau, vous devez

  * avoir httpd 2.0 fonctionnant avec le module mod_dav

  * installer le greffon mod_dav_svn pour mod_dav, qui utilise la librairie d'accès au dépôt de Subversion

  * configurer votre fichier httpd.conf pour exporter le dépôt

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. (see Compilation et installation.) Des instructions sont également disponibles dans le fichier INSTALL dans les sources de Subversion.

Dans cette section, nous nous concentrerons sur la configuration de votre fichier httpd.conf.

Quelque part au début de votre fichier de configuration, définissez un nouveau bloque Location:

     <Location /repos>
        DAV svn
        SVNPath /absolute/path/to/myrepos
     </Location>

Ceci rend le dépôt myrepos disponible à l'URL http://hostname/repos, sans aucune restriction d'accès :

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

  * En pointant un navigateur web ordinaire à l'URL, toute personne peut naviger intérectivement dans la dernière révision.

  * Tout le monte peut remonter des modifications au dépôt.

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:

     joe:Msr3lKOsYMkpc
     frank:Ety6rZX6P.Cqo
     mary:kV4/mQbu0iq82

Vous pouvez générer les mots de passe cryptés en utilisant une commande crypt(3) standard ou en utilisant l'outil htpasswd présent dans le répertoire bin d'Apache.

     $ /usr/local/apache2/bin/htpasswd -n sussman
     New password:
     Re-type new password:
     sussman:kUqncD/TBbdC6

Puis ajoutez ces quelques lignes dans votre block <Location> qui pointent sur le fichier des utilisateurs:

     AuthType Basic
     AuthName "Subversion repository"
     AuthUserFile /path/to/users/file

Si vous voulez restreindre tout accès au dépôt, ajouter une ligne supplémentaire:

     Require valid-user

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:

     <LimitExcept GET PROPFIND OPTIONS REPORT>
        Require valid-user
     </LimitExcept>

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:

     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>

Ce ne sont que de simples exemples. Pour un tutorial complet sur les contrôle d'accès d'Apache, regarder http://httpd.apache.org/docs-2.0/misc/tutorials.html.

Autre remarque: pour que 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 httpd.conf pour inclure:

     ServerName svn.myserver.org

Si vous utilisez le ``virtual hosting'' d'apache avec la directive NameVirtualHost, vous pourrez avoir besoin d'utiliser la directive 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: http://httpd.apache.org/docs-2.0/mod/directives.html.

Vous pouvez tester votre dépôt exporté en lançant httpd:

     $ /usr/local/apache2/bin/apachectl stop
     $ /usr/local/apache2/bin/apachectl start

Contrôler /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:

     $ svn co http://localhost/repos wc

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, /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 HACKING.

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 svnadmin dump et svnadmin load.

svnadmin dump écrit un flux de vos données de votre dépôt vers la sortie standard (stdout):

     $ svnadmin dump myrepos > dumpfile
     * Dumped revision 0.
     * Dumped revision 1.
     * Dumped revision 2.
     ...

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 svnadmin et/ou 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.

     $ svnadmin create newrepos

La commande svnadmin load est d'entreprendre de lire le dump depuis l'entrée standard (stdin) et de rejouer chaques remontées:

     $ svnadmin load newrepos < dumpfile
     <<< Started new txn, based on original revision 1
          * adding path : A ... done.
          * adding path : A/B ... done.
     ...
     ------- 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) >>>

Voilà, vos révisions ont été remontées dans le nouveau dépôt.

Stupide dump/load astuces
-------------------------

Les personne que aime ``copiner'' avec Unix peuvent essayer des choses comme celles ci:

     $ svnadmin create newrepos
     $ svnadmin dump myrepos | svnadmin load newrepos

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.

     $ svnadmin dump myrepos 0 2000 > dumpfile1
     $ svnadmin dump myrepos 2000 4000 > dumpfile2

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 svnadmin dump est toujours comparée à la révision 0 qui est juste le répertoire racine / 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 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 dumpfile2 doit être 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:

  * Ouvrire le dumpfile2 dans un éditeur

  * ne pas supprimer la ligne d'entête SVN-fs-dump-format-version au début du fichier.

  * supprimer la première révision, qui commence avec un enregistrement Revision-number:, et qui va jusqu'au prochain bloque Revision-number:.

Une fois que vos fichiers de dump ont été proprement ``ajustés'', vous pouvez les charger avec la séquence:

     $ svnadmin load newrepos < dumpfile1
     $ svnadmin load newrepos < dumpfile2

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) à 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 DeltaV  de WebDAV, et disponible à 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 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 http://svn.collab.net/repos/svn-repos/trunk/www/webdav-usage.html.