@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/ [ 588] 0 0 branches/ [ 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/ [ 588] 0 0 branches/ [ 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 DAV svn SVNPath /absolute/path/to/myrepos @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{} 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 Require valid-user @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 Require group svn_committers Require group svn_committers Require group svn_readers @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}.