Le programme svnadmin est le meilleur ami de l'administrateur de dépôts. En plus de fournir la possibilité de créer des dépôts Subversion, ce programme vous permet d'effectuer de nombreuses opérations de maintenance sur ces dépôts. La syntaxe de svnadmin est similaire à celle des autres programmes en ligne de commande de Subversion :

$ svnadmin help
usage général : svnadmin SOUS_COMMANDE DÉPÔT [ARGS & OPTIONS ...]
Entrer 'svnadmin help <sous-commande>' pour une aide spécifique.
Entrer 'svnadmin --version' pour avoir la version et les modules de stockages.

Sous-commandes disponibles :
   crashtest
   create
   deltify
…

Au début de ce chapitre (dans la section intitulée « Création d'un dépôt »), nous vous avons présenté la sous-commande svnadmin create. Beaucoup d'autres sous-commandes svnadmin sont couvertes plus loin dans ce chapitre. Vous pouvez également consulter Guide de référence de svnadmin : administration des dépôts Subversion pour une liste complète des sous-commandes et des fonctionnalités qu'elles apportent.

svnlook est un outil de Subversion pour examiner les différentes révisions et transactions (qui sont des révisions en cours de création) dans un dépôt. Aucune modification n'est faite au dépôt par cet outil. svnlook est généralement utilisé par les procédures automatiques du dépôt pour signaler les changements qui vont être propagés (dans le cas de la procédure automatique pre-commit) ou qui viennent d'être propagés (dans le cas de la procédure automatique post-commit). Un administrateur peut être amené à utiliser cet outil à des fins de diagnostic.

La syntaxe de svnlook est particulièrement simple :

$ svnlook help
usage général : svnlook SOUS_COMMANDE CHEMIN_DÉPÔT [ARGS & OPTIONS...]
Note : Quand --revision ou --transaction ne sont pas précisées, les sous-
       commandes qui en ont besoin utilisent la révision la plus récente.
Entrer 'svnlook help <sous-commande>' pour une aide spécifique.
Entrer 'svnlook --version' pour avoir la version et les modules de stockage.
…

Beaucoup de sous-commandes svnlook peuvent être appliquées soit à une révision soit à une arborescence de transaction, affichant les informations à propos de l'arborescence elle-même ou les différences par rapport à la révision précédente du dépôt. Pour spécifier quelle révision ou quelle transaction examiner, utilisez respectivement les options --revision (-r) et --transaction (-t). En l'absence des options --revision (-r) ou --transaction (-t), svnlook examine la révision la plus récente (la révision HEAD) du dépôt. Ainsi, les deux commandes suivantes font exactement la même chose si la révision la plus récente du dépôt situé à l'emplacement /var/svn/depot porte le numéro 19 :

$ svnlook info /var/svn/depot
$ svnlook info /var/svn/depot -r 19

Signalons une exception à ces règles concernant les sous-commandes : la sous-commande svnlook youngest ne prend aucune option et affiche simplement le numéro de la révision la plus récente du dépôt :

$ svnlook youngest /var/svn/depot
19
$

	Note
	Gardez à l'esprit que les seules transactions que vous pouvez examiner sont celles qui n'ont pas été propagées. La plupart des dépôts ne comportent pas de transactions de ce type parce que les transactions sont habituellement soit propagées (auquel cas vous devriez y avoir accès sous la forme de révisions via l'option --revision (-r)), soit annulées et supprimées.

La sortie de svnlook est conçue pour être à la fois lisible par un humain et analysable par une machine. Prenons, par exemple, la sortie de la sous-commande svnlook info :

$ svnlook info /var/svn/depot
sally
2002-11-04 09:29:13 -0600 (lun. 04 nov. 2002)
27
J'ai ajouté le traditionnel
Arbre grec.
$

La sortie de svnlook info est constituée des éléments suivants, par ordre d'apparition :

Cette sortie est lisible par un humain, ce qui veut dire que les éléments tels que la date sont représentés par du texte simple au lieu d'un obscur code (comme le nombre de nanosecondes depuis le passage aux nouveaux francs). Mais cette sortie est aussi analysable par une machine — parce que le commentaire de propagation peut comporter plusieurs lignes et n'est pas limité en taille, svnlook affiche la longueur du commentaire avant le commentaire lui-même. Cela permet aux scripts et autres utilitaires faisant appel à cette commande de prendre des décisions opportunes à propos du commentaire de propagation, comme savoir combien de mémoire allouer pour le commentaire ou au moins savoir combien d'octets sauter dans le cas où les données affichées par svnlook ne sont pas les dernières données du flux.

svnlook peut répondre à un tas d'autres requêtes : afficher des sous-ensembles des informations précédemment citées, lister récursivement les arborescences suivies en versions des répertoires, lister les chemins modifiés lors de telle révision ou transaction, afficher les différences de contenu et de propriétés pour les fichiers et répertoires,  etc. Reportez-vous à Guide de référence de svnlook : outil d'exploration du contenu d'un dépôt Subversion pour la liste complète des fonctionnalités offertes par svnlook.

Bien que ce ne soit pas l'outil qu'un administrateur utilise le plus, svndumpfilter fournit une fonctionnalité d'un genre très particulier qui est d'une grande utilité : la possibilité de modifier rapidement et facilement des flux de l'historique du dépôt Subversion en agissant en tant que filtre sur les chemins.

La syntaxe de svndumpfilter est la suivante :

$ svndumpfilter help
usage général : svndumpfilter SOUS_COMMANDE [ARGS & OPTIONS ...]
Entrer 'svndumpfilter help <sous-commande>' pour l'aide spécifique.
Entrer 'svndumpfilter --version' pour avoir le numéro de version du programme.

Sous-commandes disponibles :
   exclude
   include
   help (?, h)

Il n'y a que deux sous-commandes intéressantes : svndumpfilter exclude et svndumpfilter include. Elles vous permettent de choisir entre l'inclusion implicite et l'inclusion explicite des chemins dans le flux. Vous en saurez plus sur ces sous-commandes et sur l'utilité si particulière de svndumpfilter plus loin dans ce chapitre, dans la section intitulée « Filtrage de l'historique d'un dépôt ».

Le programme svnrdump est, pour faire simple, essentiellement une variante qui fonctionne avec un réseau des sous-commandes svnadmin dump et svnadmin load.

$ svnrdump help
usage général : svnrdump SOUS_COMMANDE DÉPÔT [-r BAS[:HAUT]]
Entrer 'svnrdump help <sous-commande>' pour une aide spécifique.
Entrer 'svnrdump --version' pour la version et les modules d'accès (RA).

Sous-commandes disponibles :
   dump
   load
   help (?, h)

$

Nous entrerons dans le détail de l'utilisation des commandes svnrdump et svnadmin plus loin dans ce chapitre (voir la section intitulée « Migration des données d'un dépôt »).

Le programme svnsync fournit toutes les fonctionnalités requises pour faire fonctionner un miroir en lecture seule d'un dépôt Subversion. Ce programme a une et une seule fonction : transférer l'historique d'un dépôt vers un autre dépôt. Et, bien qu'il y ait différentes manières de faire, sa force réside dans sa capacité de travailler à distance : les dépôts « source » et « destination » peuvent être sur deux ordinateurs différents et svnsync sur un troisième.

Comme vous vous en doutez, svnsync possède une syntaxe très proche des autres programmes déjà mentionnés dans ce chapitre :

$ svnsync help
usage général : svnsync SOUS_COMMANDE DÉPÔT [ARGS & OPTIONS ...]
Entrer 'svnsync help <sous-commande>' pour une aide spécifique.
Entrer 'svnsync --version' pour la version et les modules d'accès (RA).

Sous-commandes disponibles :
   initialize (init)
   synchronize (sync)
   copy-revprops
   info
   help (?, h)
$

Nous revenons en détail sur la réplication de dépôts avec svnsync plus loin dans ce chapitre (voir la section intitulée « Réplication d'un dépôt »).

Bien qu'il ne fasse pas officiellement partie des outils Subversion, le script fsfs-reshard.py (situé dans le répertoire tools/server-side du code source de Subversion) est un outil particulièrement utile à l'administrateur pour optimiser les performances de dépôts Subversion utilisant un magasin de données FSFS. Les dépôts FSFS contiennent des fichiers qui décrivent les changements apportés dans chaque révision. Parfois ces fichiers sont conservés dans un même répertoire, parfois ils sont répartis (sharded en anglais, d'où le nom du script) dans plusieurs répertoires.

Les versions anciennes de FSFS contenaient tous les fichiers de révision dans un répertoire unique qui grandissait (un fichier par nouvelle révision) au fur et à mesure. Cela entrainait des problèmes sur les systèmes qui ont des limites fixées sur le nombre maximum de fichiers dans un répertoire et cela pouvait engendrer des chutes de performances sur certains systèmes.

>À partir de la version 1.5, Subversion crée des dépôts FSFS en utilisant une disposition légèrement modifiée dans laquelle le contenu du répertoire des fichiers de révisions est éparpillé (c'est-à-dire réparti dans plusieurs sous-répertoires). Cela peut réduire de manière considérable le temps nécessaire au système pour trouver n'importe quel fichier et ainsi améliore la performance globale de Subversion lors des lectures dans le dépôt.

Le nombre de fichiers autorisés dans un sous-répertoire donné est configurable (les valeurs par défaut sont toutefois raisonnables pour la plupart des plateformes connues), mais modifier cette configuration après que le dépôt a été utilisé depuis quelque temps peut empêcher Subversion de retrouver les fichiers qu'il cherche. C'est l'objet de la commande fsfs-reshard.py.

fsfs-reshard.py remanie la structure du dépôt pour se conformer au nombre de sous-répertoires demandés et met à jour la configuration du dépôt pour conserver cette modification. Utilisé en combinaison avec svnadmin upgrade , c'est particulièrement utile pour convertir un dépôt Subversion pre-1.5 vers le dernier schéma réparti de Subversion (ce que Subversion ne fait pas automatiquement pour vous). Vous pouvez aussi ajuster finement cette valeur dans un dépôt déjà réparti.

Pour garder un dépôt petit, Subversion utilise la différenciation (ou « stockage différentiel ») à l'intérieur du dépôt lui-même. La différenciation implique l'encodage de la représentation d'un groupe de données sous la forme d'un ensemble de différences par rapport à un autre groupe de données. Si les deux groupes de données sont très similaires, la différenciation économise de l'espace pour le groupe différencié — au lieu de prendre le même espace que les données originales, le groupe occupe juste l'espace nécessaire pour dire : « je ressemble à l'autre groupe de données là-bas, sauf pour les deux ou trois changements qui suivent ». Au final, l'espace occupé par l'ensemble des données du dépôt (c'est-à-dire le contenu des fichiers suivis en versions) est beaucoup plus petit que la représentation textuelle originale de ces données.

Le stockage sous forme différenciée a fait partie de l'architecture conceptuelle de Subverson dès le début de sa conception ; et il a subi des améliorations au cours des ans. Les dépôts créés avec la version 1.4 ou ultérieure de Subversion bénéficient de la compression du contenu des fichiers « pleins-textes ». Les dépôts créés avec la version 1.6 ou ultérieure de Subversion économisent davantage d'espace disque grace au partage de représentation, une fonctionnalité qui permet à plusieurs fichiers ou révisions de fichiers dont le contenu est identique de faire référence à une seule instance partagée de ce contenu plutôt que chacun n'en conserve sa propre copie.

Bien que rares, il y a des circonstances dans lesquelles le déroulement d'une propagation Subversion peut mal se terminer, laissant derrière elle dans le dépôt des restes de cette tentative de propagation : une transaction inachevée et toutes les modifications de fichiers et de répertoires associées. Il peut y avoir plusieurs raisons à cet échec : l'utilisateur a peut-être brutalement interrompu l'opération côté client ou bien une coupure réseau s'est peut-être produite au milieu de l'opération. Quoi qu'il en soit, des transactions mortes peuvent apparaître. Elles ne sont pas dangereuses mais elles consomment inutilement de l'espace disque. Un administrateur consciencieux se doit néanmoins de les supprimer.

Vous pouvez utiliser la commande svnadmin lstxns pour obtenir la liste des noms des transactions non encore réglées :

$ svnadmin lstxns mon-depot
19
3a1
a45
$

Chaque élément de la sortie de cette commande peut être passé en argument de svnlook (avec l'option --transaction (-t)) pour déterminer qui est à l'origine de la transaction, quand elle a eu lieu et quels types de changements ont été effectués — ces informations sont très utiles pour savoir si on peut supprimer la transaction sans arrière pensée ! Si vous décidez effectivement de supprimer la transaction, son nom peut être passé à svnadmin rmtxns qui fera le nettoyage adéquat. En fait, svnadmin rmtxns peut directement prendre en entrée la sortie de svnadmin lstxns !

 
$ svnadmin rmtxns mon-depot `svnadmin lstxns mon-depot`
$

Si vous utilisez ces deux sous-commandes ainsi, vous devriez envisager de rendre votre dépôt temporairement indisponible pour les clients. De cette manière, personne ne peut initier une transaction légitime avant que le nettoyage n'ait commencé. L'exemple Exemple 5.3, « txn-info.sh (lister les transactions inachevées) » contient quelques lignes de script shell qui peuvent produire les informations relatives à chaque transaction inachevée de votre dépôt.

#!/bin/sh

### Produit les informations relatives à toutes les transactions
### inachevées d'un dépôt Subversion

DEPOT="${1}"
if [ "x$DEPOT" = x ] ; then
  echo "utilisation: $0 CHEMIN_VERS_LE_DEPOT"
  exit
fi

for TXN in `svnadmin lstxns ${DEPOT}`; do
  echo "---[ Transaction ${TXN} ]-------------------------------------------"
  svnlook info "${DEPOT}" -t "${TXN}"
done

La sortie produite par ce script est, en bref, la concaténation des différents groupes d'informations fournis par svnlook info (voir la section intitulée « svnlook ») et ressemble à ceci :

$ txn-info.sh mon-depot
---[ Transaction 19 ]-------------------------------------------
sally
2001-09-04 11:57:19 -0500 (mar. 04 sep. 2001)
0
---[ Transaction 3a1 ]-------------------------------------------
harry
2001-09-10 16:50:30 -0500 (lun. 10 sep. 2001)
39
Tentative de propagation dans un réseau capricieux
---[ Transaction a45 ]-------------------------------------------
sally
2001-09-12 11:09:28 -0500 (mer. 12 sep. 2001)
0
$

Une transaction initiée depuis longtemps correspond en général à une propagation qui a été interrompue ou qui a échoué. L'horodatage de la transaction peut fournir des informations intéressantes — par exemple, quelle est la probabilité qu'une transaction commencée il y a neuf mois soit toujours active ?

En résumé, la décision de supprimer une transaction ne doit pas être prise à la légère. D'autres sources d'informations (comme les journaux d'Apache sur les erreurs et les accès, les journaux opérationnels de Subversion, l'historique des révisions Subversion, etc.) peuvent aider à la prise de décision. Et bien sûr, l'administrateur peut toujours entrer en contact (par email, par exemple) avec l'auteur d'une transaction qui semble abandonnée pour vérifier que c'est bien le cas.

Les dépôts FSFS contiennent des fichiers de révision qui décrivent, pour chaque révision, les modifications apportées et les propriétés de la révision concernée. Les dépôts créés avec des versions de Subversion antérieures à 1.5 gardent ces fichiers dans deux dossiers (un dossier pour chaque type de fichier). Au fur et à mesure que les révisions sont propagées dans le dépôt, Subversion dépose autant de fichiers dans ces dossiers. Avec le temps, le nombre de fichiers dans chaque dossier peut se révéler relativement important. Cela peut être la cause de chutes de performances sur certains systèmes de fichiers réseaux.

Le premier problème est que le système d'exploitation doit référencer ces fichiers sur une courte période de temps. Cela conduit à une mauvaise utilisation du cache disque et, en conséquence, à plus de temps pour les recherches sur les gros disques. C'est pour cette raison que Subversion est pénalisé lorsqu'il accède à vos données suivies en versions.

Le deuxième problème est un peu plus subtil. En raison de la manière dont la plupart des systèmes de fichiers allouent l'espace disque, chaque fichier utilise sur le disque plus de place qu'il n'en prend réellement. Cette quantité d'espace disque nécessaire pour stocker un seul fichier peut atteindre de 2 à 16 kilooctets par fichier, en fonction du type de système de fichiers. Cela se traduit directement par un gachis d'espace disque à chaque révision pour les dépôts FSFS. L'effet est d'autant plus sensible pour les dépôts qui ont de petites révisions, puisque le surplus d'espace nécessaire pour stocker le fichier de révision dépasse rapidement la taille des données effectivement stockées.

Afin de résoudre ce problème, Subversion 1.6 introduit la commande svnadmin pack. En « tassant » (pack en anglais) tous les fichiers d'un dépôt fragmenté dans un seul fichier et en supprimant les fichiers correspondants à chaque révision, svnadmin pack remplace la fragmentation par un seul fichier. Ainsi,le cache du système de fichiers est plus performant et le temps d'accès aux fichiers est réduit.

Subversion peut tasser des dépôts fragmentés qui ont été mis à niveau vers le système de fichiers 1.6 ou ultérieur (voir svnadmin upgrade dans Guide de référence de svnadmin : administration des dépôts Subversion). Pour le faire, lancez simplement svnadmin pack sur le dépôt:

 
$ svnadmin pack /var/svn/depot
Packing shard 0...done.
Packing shard 1...done.
Packing shard 2...done.
…
Packing shard 34...done.
Packing shard 35...done.
Packing shard 36...done.
$

Comme le processus de tassage obtient les verrous nécessaires avant de faire son travail, vous pouvez lancer la commande sur un dépôt en service, ou même comme action dans la procédure automatique post-commit. Tasser un dépôt déjà tassé est autorisé, mais n'aura aucun effet sur l'utilisation de l'espace disque par le dépôt.

La commande svnadmin pack n'a aucun effet sur un dépôt BDB.

Quelle que soit la raison pour laquelle vous voulez migrer votre historique de dépôt, l'utilisation des sous-commandes svnadmin dump et svnadmin load est simplissime. svnadmin dump affiche un intervalle de révisions du dépôt, chacune utilisant le format des fichiers dump Subversion. Le fichier dump est envoyé sur la sortie standard tandis que les messages d'information sont envoyés sur la sortie d'erreur. Ceci vous permet de rediriger le flux standard vers un fichier tout en visualisant ce qui se passe dans votre terminal. Par exemple :

$ svnlook youngest mon-depot
26
$ svnadmin dump mon-depot > fichier-dump
* Révision 0 déchargée.
* Révision 1 déchargée.
* Révision 2 déchargée.
…
* Révision 25 déchargée.
* Révision 26 déchargée.

À la fin de la procédure, vous obtiendrez un fichier unique (fichier-dump dans l'exemple précédent) qui contient toutes les données stockées dans votre dépôt pour l'intervalle de révisions demandé. Notez que svnadmin dump lit les arborescences des révisions du dépôt de la même manière que tout autre processus « lecteur » (par exemple svn checkout), vous pouvez donc sans risque lancer cette commande à n'importe quel moment.

La commande jumelle, svnadmin load, recherche dans l'entrée standard la structure d'un fichier dump Subversion puis insère les révisions déchargées dans le dépôt de destination spécifié. Elle fournit elle aussi des informations sur le déroulement de l'opération, cette fois en utilisant la sortie standard :

$ svnadmin load nouveau-depot < fichier-dump
<<< Début d'une nouvelle transaction basée sur la révision 1
       * édition du chemin : A ... fait.
       * édition du chemin : A/B ... fait.
       …
  ------- Révision 1 propagée (commit) >>>

  <<< Début d'une nouvelle transaction basée sur la révision 2
       * édition du chemin : A/mu ... fait.
       * édition du chemin : A/D/G/rho ... fait.

  ------- Révision 2 propagée (commit) >>>

  …

  <<< Début d'une nouvelle transaction basée sur la révision 25
       * édition du chemin : A/D/gamma ... fait.

  ------- Révision 25 propagée (commit) >>>

  <<< Début d'une nouvelle transaction basée sur la révision 26
       * édition du chemin : A/Z/zeta ... fait.
       * édition du chemin : A/mu ... fait.

  ------- Révision 26 propagée (commit) >>>

Le résultat d'un chargement est l'ajout de nouvelle révisions à un dépôt — comme si vous faisiez des propagations vers ce dépôt avec un client Subversion classique. De la même manière que pour une propagation, vous pouvez utiliser les procédures automatiques pour effectuer des actions particulières avant et après chaque propagation faite par la procédure de chargement. En passant les options --use-pre-commit-hook et --use-post-commit-hook (respectivement) à svnadmin load, vous demandez à Subversion d'exécuter les procédures automatiques pre-commit et post-commit (respectivement) pour chaque révision chargée. Un exemple d'utilisation de ces options est de s'assurer que les révisions chargées passent par les mêmes étapes de validation qu'une propagation normale. Bien sûr, utilisez ces options avec prudence — si votre procédure automatique post-commit envoie des emails à une liste de diffusion pour chaque nouvelle propagation, vous ne voulez peut-être pas envoyer des centaines voire des milliers d'emails de notification à la suite vers cette liste ! Vous pouvez en apprendre davantage sur l'utilisation des procédures automatiques dans la section intitulée « Mise en place des procédures automatiques ».

Notez que puisque svnadmin utilise l'entrée et la sortie standards pour le déchargement et le rechargement, les administrateurs les plus intrépides peuvent tenter des choses du genre (peut-être même en utilisant différentes versions de svnadmin de chaque côté de la barre verticale |) :

$ svnadmin create nouveau-depot
$ svnadmin dump vieux-depot | svnadmin load nouveau-depot

Par défaut, un fichier dump prend beaucoup de place (beaucoup plus que le dépôt lui-même). C'est parce que, par défaut, chaque version de chaque fichier est écrite en entier dans le fichier dump. C'est le comportement le plus simple et le plus rapide et cela convient bien si vous redirigez le flux de données directement vers un autre processus (comme un programme de compression, de filtrage ou de chargement). Mais si vous créez un fichier dump dans une optique de stockage à long terme, vous voudrez sans doute économiser de l'espace disque en utilisant l'option --deltas. Avec cette option, les révisions successives des fichiers sont écrites en tant que différences binaires et compressées (de la même manière que pour le stockage des fichiers dans le dépôt). Cette option ralentit le processus mais le fichier résultant a une taille beaucoup plus proche de celle du dépôt original.

Nous avons mentionné auparavant que svnadmin dump affiche un intervalle de révisions. Pour spécifier une révision unique ou un intervalle à décharger, utilisez l'option --revision (-r). Si vous omettez cette option, toutes les révisions existantes sont affichées :

$ svnadmin dump mon-depot -r 23 > rev-23.fichier-dump
$ svnadmin dump mon-depot -r 100:200 > revs-100-200.fichier-dump

Au fur et à mesure que Subversion décharge chaque nouvelle révision, il n'affiche que le minimum d'informations nécessaire à un futur chargement pour re-générer la révision à partir de la précédente. En d'autres termes, pour n'importe quelle révision du fichier dump, seuls les éléments ayant subi une modification dans cette révision apparaissent dans le fichier dump. La seule exception à cette règle concerne la première révision qui est déchargée par la commande svnadmin dump courante.

Par défaut, Subversion n'exprime pas la première révision déchargée sous forme de différences à appliquer à la révision précédente. En effet, il n'y a pas de révision précédente dans le fichier dump ! Et puis Subversion ne peut pas connaître l'état du dépôt dans lequel les données vont être chargées (si jamais elles le sont). Pour s'assurer que la sortie de chaque exécution de svnadmin dump est auto-suffisante, la première révision déchargée est, par défaut, une représentation complète de chaque répertoire, de chaque fichier et de chaque propriété de cette révision du dépôt.

Vous pouvez toujours modifier ce comportement par défaut. Si vous ajoutez l'option --incremental quand vous déchargez le dépôt, svnadmin compare la première révision déchargée à la révision précédente du dépôt (de la même manière qu'il traite toutes les autres révisions qui sont déchargées). Il affiche alors la première révision de la même manière que le reste des révisions dans l'intervalle demandé (en ne mentionnant que les changements contenus dans cette révision). L'avantage est que vous pouvez créer plusieurs petits fichiers dump qui peuvent être chargés les uns à la suite des autres au lieu d'un unique gros fichier. Par exemple :

 
$ svnadmin dump mon-depot -r 0:1000 > fichier-dump1
$ svnadmin dump mon-depot -r 1001:2000 --incremental > fichier-dump2
$ svnadmin dump mon-depot -r 2001:3000 --incremental > fichier-dump3

Ces fichiers dump peuvent maintenant être chargés dans un nouveau dépôt avec la séquence de commandes suivante :

 
$ svnadmin load nouveau-depot < fichier-dump1
$ svnadmin load nouveau-depot < fichier-dump2
$ svnadmin load nouveau-depot < fichier-dump3

Une autre astuce consiste à utiliser l'option --incremental pour ajouter un nouvel intervalle de révisions à un fichier dump existant. Par exemple, vous pouvez avoir une procédure automatique post-commit qui ajoute simplement à un fichier dump le contenu de la révision qui a déclenché la procédure. Ou alors vous pouvez avoir un script qui tourne la nuit pour ajouter à un fichier dump les données de toutes les révisions qui ont eu lieu depuis le dernier lancement du script. Ainsi, svnadmin dump est une manière de réaliser des sauvegardes des changements de votre dépôt au fil du temps, dans l'éventualité d'un plantage système ou de toute autre événement catastrophique.

Les fichiers dump peuvent aussi être utilisés pour fusionner le contenu de différents dépôts en un seul dépôt. En utilisant l'option --parent-dir de svnadmin load, vous pouvez spécifier un nouveau répertoire racine virtuel pour la procédure de chargement. Ainsi, si vous avez des fichiers dump pour trois dépôts (disons fichier-dump-calc, fichier-dump-cal et fichier-dump-tab) vous pouvez commencer par créer un nouveau dépôt pour les héberger tous :

$ svnadmin create /var/svn/projets
$

Ensuite, créez dans le dépôt les nouveaux répertoires qui vont encapsuler le contenu de chacun des trois dépôts précédents :

$ svn mkdir -m "Racines initiales des projets" \
      file:///var/svn/projets/calc \
      file:///var/svn/projets/calendrier \
      file:///var/svn/projets/tableur
Révision 1 propagée.
$

Enfin, chargez chaque fichier dump dans le répertoire correspondant du nouveau dépôt :

$ svnadmin load /var/svn/projets --parent-dir calc < fichier-dump-calc
…
$ svnadmin load /var/svn/projets --parent-dir calendrier < fichier-dump-cal
…
$ svnadmin load /var/svn/projets --parent-dir spreadsheet < fichier-dump-tab
…
$

Dans Subversion 1.7, la commande svnrdump a rejoint la trousse à outils Subversion. Elle est plutôt spécialisée en tant que version réseau de svnadmin dump et svnadmin load, que nous avons vu en détail dans la section intitulée « Migration des données d'un dépôt à l'aide de svnadmin ». svnrdump dump génère un flux dump à partir d'un dépôt distant, en l'affichant sur la sortie standard ; svnrdump load lit un flux depuis l'entrée standard et le charge dans un dépôt distant. En utilisant svnrdump, vous pouvez générer des dumps incrémentaux tout comme vous le feriez avec svnadmin dump. Vous pouvez même décharger une sous-arborescence d'un dépôt (ce que ne peut pas faire svnadmin dump).

La principale différence est que vous n'avez pas besoin d'avoir un accès direct au dépôt avec svnrdump car elle utilise les mêmes protocoles définis par Repository Access (RA) que le client texte interactif Subversion. Ainsi, vous serez peut-être amené à fournir des éléments d'authentification. Aussi, vous actions à distance sont soumises aux droits qui vous sont octroyés par la configuration du serveur Subversion.

	Note
	svnrdump dump requiert que le serveur soit en version 1.4 au moins. Elle génère des flux dump du type de ceux générés lorsque vous spécifiez l'option --deltas à svnadmin dump. Ce n'est pas significatif pour l'utilisation courante de cette commande mais peut vous impacter si vous avez en tête de transformer le flux dump de sortie.

	Note
	Comme elle modifie les propriétés de révisions après avoir propagé les nouvelles révisions, svnrdump load requiert que le dépôt cible soit configuré afin d'autoriser les modifications de propriétés via la procédure automatique pre-revprop-change. Reportez-vous à pre-revprop-change dans Guide de référence des procédures automatiques de Subversion pour plus de détails.

Comme vous pouvez vous y attendre, vous pouvez utiliser svnadmin et svnrdump de concert. Vous pouvez, par exemple, utililser svnrdump dump pour générer un flux dump depuis un dépôt distant et rediriger ce flux vers svnadmin load pour copier tout l'historique de ce dépôt vers un dépôt local. Vous pouvez tout aussi bien effectuer l'inverse, copier l'historique d'un dépôt local vers un distant.

	Astuce
	Si vous utiliser des URL de type file://, svnrdump peut alors accéder à des dépôts locaux, mais il le fera en utilisant la couche d'abstraction Repository Access (RA) de Subversion ; vous obtiendrez de bien meilleures performances en utilisant svnadmin dans de tels cas de figure.

Supposons que vous avez un dépôt source que vous voulez répliquer ; il vous faut alors disposer d'un dépôt destination qui servira de miroir. Ce dépôt cible peut utiliser n'importe quel magasin de données disponible (voir À propos des magasins de données), les couches d'abstraction de Subversion s'assurent que ces détails ne vous impactent pas. Par défaut, ce dépôt ne doit comporter aucun historique (nous aborderons une exception à cette règle plus loin dans cette section).

Le protocole utilisé par svnsync pour transmettre les informations de révision est particulièrement sensible aux divergences entre les historiques suivies en versions de la source et de la destination. Pour cette raison, bien que svnsync ne puisse pas exiger que le dépôt destination soit en lecture seule^[57], autoriser des modifications d'historique sur le dépôt destination par un mécanisme externe autre que le processus de réplication mène droit au désastre.

	Avertissement
	Ne modifiez pas le dépôt miroir de sorte que son historique de version diffère de celui du dépôt source. Les seules propagations et modifications de propriétés de révisions qui doivent avoir lieu sur ce dépôt miroir sont celles effectuées par l'outil svnsync.

Une autre exigence concernant le dépôt destination est que le processus svnsync doit être autorisé à modifier les propriétés de révision. Comme svnsync fonctionne dans le cadre du système des procédures automatiques du dépôt, l'état par défaut du dépôt (qui consiste à interdire les modifications des propriétés de révision, voir pre-revprop-change dans Guide de référence des procédures automatiques de Subversion) n'est pas suffisant. Vous devez activer explicitement la procédure automatique pre-revprop-change et votre script doit autoriser svnsync à définir et à modifier les propriétés de révision. Une fois ces dispositions prises, vous êtes parés pour commencer la réplication des révisions du dépôt.

	Astuce
	Il est de bon ton de mettre un place un contrôle d'accès pour autoriser le processus de réplication de votre dépôt à faire ce qu'il a à faire tout en interdisant aux autres utilisateurs de modifier le contenu de votre dépôt miroir.

Examinons maintenant l'utilisation de svnsync dans un scénario classique de réplication. Nous saupoudrons le discours de quelques recommandations pratiques que vous êtes libre d'ignorer si elles ne sont pas nécessaires ou pas applicables à votre environnement.

nous allons répliquer le dépôt public qui contient le code source de ce livre et mettre ce miroir à disposition sur Internet, sur une machine différente de celle qui héberge le dépôt original. Cet hôte distant possède une configuration globale qui autorise les accès anonymes en lecture mais requiert une authentification pour modifier les dépôts (pardonnez-nous de passer rapidement sur les détails de la configuration du serveur Subversion pour le moment, mais ces aspects sont traités en profondeur dans le Chapitre 6, Configuration du serveur.). Et pour rendre l'exemple plus intéressant, et uniquement pour cela, nous piloterons la réplication depuis une troisième machine — en l'occurrence, celle que nous sommes en train d'utiliser.

Dans un premier temps, nous allons créer le dépôt qui servira de miroir. Cette étape et les deux suivantes requièrent l'accès à la ligne de commande de la machine sur laquelle le miroir sera hébergé. Toutefois, une fois que ce dépôt sera complètement configuré, nous n'aurons plus besoin d'y avoir accès directement.

 
$ ssh admin@svn.exemple.com \
      "svnadmin create /var/svn/miroir-svn"
admin@svn.exemple.com's password: ********
$

À ce stade, nous disposons d'un dépôt et, en raison de la configuration de notre serveur, ce dépôt est accessible directement depuis Internet. Maintenant, puisque nous ne voulons pas que quoi que ce soit modifie notre dépôt en dehors du processus de réplication, nous devons trouver un moyen de distinguer ce processus des autres prétendants aux propagations. Pour ce faire, nous utilisons un identifiant d'utilisateur dédié à notre processus. Seules les propagations et les modifications de propriétés de révisions effectuées par l'identifiant spécial id-sync sont autorisées.

Nous allons utiliser le système de procédures automatiques du dépôt à la fois pour autoriser le processus de réplication à faire ce qu'il doit faire et pour garantir qu'il soit le seul à le faire. Nous implémentons donc deux des procédures automatiques du dépôt : pre-revprop-change et start-commit. Le script pre-revprop-change est présenté dans l'Exemple 5.4, « Procédure automatique pre-revprop-change du dépôt miroir » et, pour résumer, vérifie que l'utilisateur qui essaie de modifier les propriétés est bien notre utilisateur id-sync. Si c'est bien le cas, la modification est autorisée ; sinon, elle est refusée.

#!/bin/sh

USER="$3"

if [ "$USER" = "id-sync" ]; then exit 0; fi

echo "Seul l'utilisateur id-sync est autorisé à modifier les propriétés de révision." >&2
exit 1

Voilà pour les modifications des propriétés de révision. Maintenant nous devons nous assurer que seul l'utilisateur id-sync est autorisé à propager de nouvelles révisions dans le dépôt. Ce que nous allons faire en utilisant une procédure automatique start-commit telle que celle présentée dans l'Exemple 5.5, « Procédure automatique start-commit du dépôt miroir ».

#!/bin/sh

USER="$2"

if [ "$USER" = "id-sync" ]; then exit 0; fi

echo "Seul l'utilisateur id-sync est autorisé à effectuer des propagations." >&2
exit 1

Après avoir installé nos procédures automatiques et s'être assuré qu'elles sont exécutables par le serveur Subversion, nous en avons terminé avec l'installation de notre dépôt miroir. Maintenant, nous allons effectivement lancer la réplication.

La première chose à faire avec svnsync est d'enregistrer dans notre dépôt destination le fait qu'il sera un miroir du dépôt source. Nous utilisons donc la sous-commande svnsync initialize. Nous fournissons des URL qui pointent vers les répertoires racines des dépôts destination et source, respectivement. Dans Subversion 1.4, c'est obligatoire — seule la réplication de dépôts complets est permise. Depuis Subversion 1.5, cependant, vous pouvez aussi utiliser svnsync pour répliquer uniquement des sous-arborescences du dépôt.

$ svnsync help init
initialize (init): usage : svnsync initialize DEST_URL SOURCE_URL

Initialise un dépôt destination pour être synchronisé à partir
d'un autre dépôt.
…
$ svnsync initialize http://svn.exemple.com/miroir-svn \
                     http://svn.code.sf.net/p/svnbook/source \
                     --sync-username id-sync --sync-password mdp-sync
Propriétés copiées pour la révision 0.
$

Notre dépôt destination se souviendra maintenant qu'il est un miroir du dépôt public du code source de ce livre. Notez que nous avons fourni un identifiant et un mot de passe en arguments à svnsync — c'était exigé par la procédure automatique pre-revprop-change de notre dépôt miroir.

Note

Dans Subversion 1.4, les valeurs assignées aux options --username et --password de svnsync étaient utilisées pour l'authentification à la fois par le dépôt source et par le dépôt destination. Cela posait des problèmes quand ces l'utilisateur n'avait pas exactement les mêmes éléments pour les deux dépôts, particulièrement quand le mode non-interactif était utilisé (avec l'option --non-interactive).Ce problème a été résolu dans la version 1.5 de Subversion avec l'introduction de deux nouvelles paires d'options. Utilisez --source-username et --source-password pour vous authentifier auprès du dépôt source ; utilisez --sync-username et --sync-password pour vous authentifier auprès du dépôt destination (les vieilles options --username et --password existent encore pour assurer la compatibilité mais nous en déconseillons l'usage).

Abordons maintenant la partie amusante. En une seule sous-commande, nous pouvons demander à svnsync de copier toutes les révisions qui n'ont pas encore été répliquées du dépôt source vers le dépôt destination^[58]. La sous-commande svnsync synchronize fouille dans les propriétés de révision spéciales du dépôt destination pour déterminer la dernière révision qui a été répliquée, en l'occurrence la révision 0. Ensuite, elle interroge le dépôt source pour savoir quelle est la dernière révision propagée dans ce dépôt. Enfin, elle demande au dépôt source de commencer à envoyer toutes les révisions entre la révision 0 et la dernière révision. Au moment où svnsync reçoit la réponse du dépôt source, elle commence la retransmission des révisions vers le dépôt destination en tant que nouvelles propagations.

$ svnsync help synchronize
synchronize (sync): Usage : svnsync synchronize URL_DEST [URL_SOURCE]

Tranfère toutes les révisions en attente vers la destination à partir
de la source avec laquelle elles ont été initialisées.
…
$ svnsync synchronize http://svn.exemple.com/miroir-svn \
                      http://svn.code.sf.net/p/svnbook/source
Transmission des données ........................................
Révision 1 propagée.
Propriétés copiées pour la révision 1.
Transmission des données ..
Révision 2 propagée.
Propriétés copiées pour la révision 2.
Transmission des données .....
Révision 3 propagée.
Propriétés copiées pour la révision 3.
…
Transmission des données ..
Révision 4063 propagée.
Propriétés copiées pour la révision 4063.
Transmission des données .
Révision 4064 propagée.
Propriétés copiées pour la révision 4064.
Transmission des données ....
Révision 4065 propagée.
Propriétés copiées pour la révision 4065.
$

Il est intéressant de noter ici que, pour chaque révision répliquée, il y a d'abord propagation de la révision dans le dépôt destination, puis des changements de propriétés ont lieu. C'est parce que la propagation initiale est effectuée par (et donc attribuée à) l'utilisateur id-sync et qu'elle est horodatée lors de la création de la nouvelle révision. Et aussi parce que les interfaces d'accès au dépôt Subversion n'autorisent pas la définition de propriétés de révision au sein d'une propagation. C'est pourquoi svnsync fait suivre la réplication par une série de modifications de propriétés qui copient dans le dépôt destination toutes les propriétés de révision trouvées dans le dépôt source pour cette révision. Cela a également pour effet de corriger l'auteur et l'horodatage de la révision pour être cohérent avec le dépôt source.

Notez également que svnsync documente tout ce qu'il fait en détail, afin de pouvoir être interrompu ou redémarré sans remettre en cause l'intégrité des données répliquées. Si une panne réseau survient pendant la réplication d'un dépôt, relancez simplement la commande svnsync synchronize et elle reprendra tranquillement là où elle s'était arrêtée. En fait, au fur et à mesure que de nouvelles révisions apparaissent dans le dépôt source, c'est précisément ce qu'il faut faire pour conserver votre miroir à jour.

Avertissement

Parmi les informations stockées par le mirroir, svnsync enregistre l'URL source avec laquelle il a été initialisé. Ainsi, les appels suivants à svnsync ne requièrent pas de fournir l'URL source dans la ligne de commande. Cependant, pour plus de sécurité, nous recommandons que vous continuyez à le faire. En fonction de la manière dont il a été déployé, il peut s'avérer risqué pour svnsync de faire confiance à l'URL source qu'il récupère dépôt mirroir et depuis laquelle il récupère les données suivies en versions.

$ svn propdel --revprop -r0 svn:sync-lock http://svn.exemple.com/miroir-svn
Propriété 'svn:sync-lock' supprimée de la révision 0 du dépôt
$

$ svn initialize --allow-non-empty http://svn.exemple.com/miroir-svn \
                                   NOUVELLE-URL-SOURCE
Propriétés copiées pour la révision 4065.
$

$ svn propset --revprop -r0 svn:sync-from-url NOUVELLE-URL-SOURCE \
      http://svn.exemple.com/miroir-svn
Propriété 'svn:sync-from-url' définie à la révision 0 du dépôt
$

$ svnsync help info
info: usage : svnsync info URL_DEST

Affiche les informations du dépôt destination d'une synchronisation
à URL_DEST.
…
$ svnsync info http://svn.exemple.com/mirroir-svn
URL source : https://svn.code.sf.net/p/svnbook/source
UUID du dépôt source : 931749d0-5854-0410-9456-f14be4d6b398
Dernière révision fusionnée : 4065
$

Le procédé est cependant peu élégant. Comme les propriétés des révisions Subversion peuvent être modifiées n'importe quand dans la vie du dépôt et comme elles ne conservent pas de trace des modifications effectuées, les processus de réplication doivent faire particulièrement attention à ces propriétés. Si vous avez déjà répliqué les quinze premières révisions d'un dépôt et que quelqu'un modifie une propriété de révision concernant la révision 12, svnsync ne sait pas qu'il faut revenir en arrière et modifier la copie de la révision 12. Vous devez le lui indiquer manuellement en utilisant la sous-commande svnsync copy-revprops (ou à l'aide d'autres outils), ce qui re-réplique toutes les propriétés de révision pour une révision particulière ou un ensemble de révisions.

copy-revprops: usage :

    1. svnsync copy-revprops URL_DEST [URL_SOURCE]
    2. svnsync copy-revprops URL_DEST REV[:REV2]

…
$ svnsync copy-revprops http://svn.exemple.com/mirroir-svn 12
Propriétés copiées pour la révision 12.
$

C'en est fini pour la présentation rapide de la réplication de dépôt. Vous voudrez sûrement automatiser un certain nombre de choses autour de ce processus. Par exemple, alors que notre exemple présentait une mise en place « tirer-et-pousser », vous êtes susceptible de vouloir que ce soit le dépôt source qui pousse les modifications vers un ou plusieurs miroirs prédéfinis lors de l'exécution des procédures automatiques post-commit et post-revprop-change. Ceci permettrait au miroir d'être à jour presque en temps réel.

svnsync n'est pas limitée à la copie intégrale de tout ce qui se trouve dans le dépôt. Elle peut aussi prendre en compte toute une variation de réplications partielles. Par exemple, bien que ce ne soit pas une situation très courante, svnsync sait répliquer des dépôts pour lesquels l'identifiant qu'elle utilise pour s'authentifier n'a que des droits partiels en lecture. Elle copie simplement les parties du dépôt qu'elle est autorisée à voir. Un tel miroir n'est clairement pas une bonne solution de sauvegarde..

Avec Subversion 1.5, svnsync a acquis la capacité de répliquer uniquement un sous-ensemble d'un dépôt plutôt que le dépôt entier. La procédure pour configurer et assurer la maintenance d'un tel miroir est exactement la même que pour répliquer un dépôt entier, excepté lors du passage de l'URL du dépôt source à svnsync init : vous spécifiez l'URL d'un sous-dossier à l'intérieur du dépôt. La synchronisation du miroir ne copie que les modifications relatives à l'arborescence sous le répertoire indiqué. Notez quand même quelques restrictions sur cette fonction : premièrement, vous ne pouvez pas répliquer plusieurs sous-dossiers disjoints du dépôt source vers un unique dépôt miroir — vous devez dans ce cas répliquer un répertoire parent qui est commun à tous les répertoires que vous voulez répliquer ; deuxièmement, la logique de filtrage est entièrement basée sur le chemin d'accès donc, si le sous-dossier que vous répliquez a été renommé par le passé, votre miroir ne contiendra que les révisions depuis lesquelles il a le nom indiqué dans l'URL que vous avez spécifiée. Et, de la même manière, si le sous-dossier source est renommé dans le futur, le processus de synchronisation ne répliquera plus les données à partir du moment où l'URL que vous avez spécifiée ne sera plus valide.

Nous avons mentionné le coût de mise en place d'un mirroir pour un dépôt existant. Pour beaucoup, le coût apparent de transmettre des milliers (voire des millions) de révisions de l'historique vers un nouveau dépôt mirroir avec svnsync est le point d'arrêt final. Heureusement, Subversion 1.7 offre une porte de sortie avec la nouvelle option --allow-non-empty de svnsync initialize. Cette option vous permet d'initialiser un dépôt comme mirroir d'un autre en courtcircuitant la vérification que le dépôt à initialiser possède bien un historique vide. À la lecture de nos précédents avertissements sur la sensibilité du processus de réplication, vous devriez pressentir que cette option à n'utiliser qu'avec la plus grande prudence. Mais elle est terriblement efficace si vous avez les droits d'accès au dépôt source et que vous pouvez faire une copie physique du dépôt, puis initialiser cette copie en tant que nouveau mirroir :

$ svnadmin hotcopy /chemin/vers/depot /chemin/vers/depot-mirroir
$ ### créer le fichier /chemin/vers/depot-mirroir/hooks/pre-revprop-change
$ svnsync initialize file:///chemin/vers/depot-mirroir \
                     file:///chemin/vers/depot
svnsync: E000022: Le dépôt destination contient déjà des révisions ; utilisez
éventuellement l'option --allow-non-empty si ces révisions correspondent à
leurs contreparties dans le dépôt source
$ svnsync initialize --allow-non-empty file:///chemin/vers/depot-mirroir \
                                       file:///chemin/vers/depot
Propriétés copiées pour la révision 32042.
$

Les administrateurs qui utilisent une version antérieure à Subversion 1.7 (et qui n'ont donc pas accès à l'option --allow-non-emptyde svnsync initialize) peuvent atteindre le même résultat en manipulant précautionneusement la propriété de la révision r0 sur la copie du dépôt qui a vocation à devenir un mirroir. Utilisez svnadmin setrevprop pour créer les mêmes propriétés de journalisation que svnsync aurait créées.

Nous avons vu deux façons de répliquer l'historique des révisions d'un dépôt vers un autre. Regardons maintenant les choses du point de vue de l'utilisateur. Comment les réplications et les diverses situations qui y font appel affectent-elles les clients Subversion ?

Tant que l'on considère les interactions relatives aux dépôts et mirroirs, une copie de travail unique peut interagir avec les deux, mais vous devrez jongler un peu pour y arriver. D'abord, vous devez vous assurer que le dépôt primaire et le mirroir possèdent bien le même UUID (ce qui n'est pas le cas par défaut). Reportez-vous à la section intitulée « Gestion des identifiants uniques (UUID) des dépôts » plus loin dans ce chapitre pour en savoir davantage.

Une fois que les dépôts possèdent le même UUID, vous pouvez utiliser svn relocate pour faire pointer votre copie de travail vers le dépôt avec lequel vous souhaitez travailler ; cette procédure est décrite dans svn relocate dans Partie II, « Guide de référence des commandes Subversion ». Un danger vous guette ici cependant, car si les dépôts ne sont pas parfaitement synchrones, une copie de travail à jour et pointant vers le dépôt principal sera, si vous la faites pointer vers un mirroir obsolète, déboussolée par la perte apparente et soudaine des révisions qu'elle s'attend à trouver dans le dépôt. Elle renverra des erreurs pour vous le signaler. Si jamais cela survient, vous pouvez refaire pointer votre copie de travail vers le dépôt primaire et, soit attendre que le dépôt mirroir se mette à jour, soit remonter dans le temps votre copie de travail vers une révision dont vous savez qu'elle figure dans le dépôt mirroir, puis tenter à nouveau de faire pointer votre copie de travail vers ce mirroir.

Enfin, soyez conscient que la réplication des révisions fournie par svnsync n'est que cela  : une réplication de révisions. Seules les informations pouvant être contenues dans le format de fichier dump des dépôts Subversion peuvent être répliquées. Ainsi, les outils tels que svnsync (et svnrdump que nous avons vu dans la section intitulée « Migration des données d'un dépôt en utilisant svnrdump ») possèdent les mêmes limites intrinsèques aux fichiers dump. Ils ne répliquent pas les procédures automatiques, les transactions non propagées ou les verrous posés par les utilisateurs sur les chemins du dépôt.