Le client texte interactif Subversion sait faire plusieurs opérations en utilisant des URL du dépôt et sans copie de travail afin d'effectuer des modifications simples. Certaines sont décrites ailleurs dans ce livre, mais nous vous en donnons la liste exhaustive ici.

Certainement la plus évidente des opérations à distance de type propagation est la comande svn import. Nous décrivons cette commande dans la section intitulée « Importation de fichiers et de dossiers » lorsque nous expliquons comment insérer facilement une arborescence complète de données non suivies en versions dans un dépôt Subversion afin de démarrer le processus de suivi de versions sur ces données.

Les commandes svn mkdir et svn delete, lorsqu'elle ciblent des URL, sont aussi des opérations de type propagation. Elles permettent respectivement à l'utilisateur de créer un ou plusieurs nouveaux dossiers suivis en versions ou supprimer (récursivement) un ou plusieurs fichiers ou dossiers suivis en versions, sans l'utilisation d'une copie de travail. Chaque fois que vous entrez une de ces commandes, le client communique avec le serveur de la même manière que s'il décrivait la propagation de l'ajout d'un dossier ou de la suppression d'un élément de la copie de travail. S'il n'y a pas de problème ou de conflit détecté par cette opération, le serveur propage les ajouts ou les suppressions dans une nouvelle révision unique.

Vous pouvez utiliser svn copy ou svn move avec deux URL (une URL source de la copie/déplacement et une URL destination) pour propager des copies ou des déplacements de fichiers ou dossiers directement dans le dépôt. Ces opérations s'avèrent être les plus coûteuses quand elles sont effectuées à l'intérieur d'une copie de travail alors qu'elles s'exécutent en temps constant lorsqu'elles sont effectuées à distance en utilisant des URL du dépôt. En fait, l'opération distante svn copy est communément utilisée pour créer des branches dans Subversion, comme nous le montrons dans la section intitulée « Création d'une branche ».

Comme pour la commande svn commit habituelle, vous pouvez spécifier un commentaire de propagation avec toutes ces commandes pour décrire les modifications que vous effectuez. Utilisez l'option --file (-F) ou --message (-m), sinon autorisez le client à vous inviter à lui fournir un commentaire de propagation.

Enfin, il y a plusieurs opérations relatives aux propriétés non suivies en versions que vous pouvez effectuer directement sur le dépôt. En fait, les propriétés de révisions sont quelques peu uniques dans ce contexte, puisqu'elles ne sont pas stockées dans les copies de travail et, par conséquent. doivent être modifiées sans toucher à la copie de travail. Reportez-vous à la section intitulée « Propriétés » pour une description détaillée de la façon de gérer les propriétés dans Subversion.

Un inconvénient de la propagation à distance par le client texte interactif est que vous êtes limité à une seule opération (réellement un type d'opération) par propagation. Par exemple, il est parfaitement naturel et possible de, disons, utiliser svn delete suivi de svn mkdir dans une copie de travail pour remplacer un répertoire suivi en versions existant avec un tout neuf. Lorsque vous propagez ces opérations, une seule nouvelle révision est créée dans le dépôt et cette révision comporte le remplacement complet de votre répertoire. Vous ne pouvez pas faire la même chose en opération à distance en utilisant le client texte interactif, tout en préservant l'unité de la transaction (svn delete URL créera une nouvelle révision qui supprime le répertoire et svn mkdir URL créera une deuxième révision qui recrée le répertoire).

Heureusement, Subversion fournit un utilitaire séparé qui a pour vocation de permettre aux utilisateurs d'enchaîner un ensemble d'opérations à distance et de les propager comme une modification atomique. Cet outil est svnmucc, pour Subversion Multiple URL Command Client (que l'on pourrait traduire par client Subversion pour les commandes avec de multiples URL) :

$ svnmucc --help
…Subversion multiple URL command client
usage: svnmucc ACTION...

  Perform one or more Subversion repository URL-based ACTIONs, committing
  the result as a (single) new revision.

Actions:
  cp REV SRC-URL DST-URL : copy SRC-URL@REV to DST-URL
  mkdir URL              : create new directory URL
  mv SRC-URL DST-URL     : move SRC-URL to DST-URL
  rm URL                 : delete URL
  put SRC-FILE URL       : add or modify file URL with contents copied from
                           SRC-FILE (use "-" to read from standard input)
  propset NAME VALUE URL : set property NAME on URL to VALUE
  propsetf NAME FILE URL : set property NAME on URL to value read from FILE
  propdel NAME URL       : delete property NAME from URL
…

svnmucc est inlus dans le code source du projet Subversion depuis de nombreuses années (en tant que commande mucc historiquement), mais c'est seulement à partir de Subversion 1.8 qu'il est devenu un membre à part entière de la panoplie des utilitaires en ligne de commande de Subversion.

L'utilitaire svnmucc peut effectuer toutes les manipulations que svn fait. Mais, au contraire de svn, svnmucc ne comporte pas de sous-commande. La syntaxe adoptée consiste à lui fournir une liste d'actions et d'opérandes dans une seule ligne de commande (ou depuis un fichier, via l'option --extra-args (-X)). Certaines actions autorisées par svnmucc singent le fonctionnement du client texte interactif. Vous aurez noté dans la sortie de la commande précédente que les cp, mkdir, mv et rm ressemblent bigrement aux commandes que nous avons citées dans la section intitulée « Opérations du client texte interactif à distance ». Mais souvenez-vous que la différence fondamentale réside dans le fait que vous pouvez enchaîner plusieurs actions dans une seule ligne de commande et que cela ne générera qu'une seule révision dans le dépôt.

Prenons l'exemple précédent qui consiste à simplement remplacer un répertoire à distance. En utilisant svnmucc, vous le feriez ainsi :

$ svnmucc rm http://svn.exemple.fr/projets/pour-jouer \
          mkdir http://svn.exemple.fr/projets/pour-jouer \
          -m "Remplace mon vieux projet pour-jouer par un tout neuf."
r22 propagée par harry le 2013-01-15T21:45:26.442865Z
$

Comme vous pouvez le constater, svnmucc a réalisé en une seule révision ce qui aurait nécessité deux révision pour svn (sans copie de travail à disposition).

	Avertissement
	Une autre différence entre svnmucc et svn réside dans le fait que le premier ne vous demandera pas d'entrer un commentaire de propagation si vous ne le fournissez pas via la ligne de commande. En lieu et place, il utilisera un message par défaut (ce qui est relativement inutile).

L'utilitaire svnmucc n'est pas simplement limité aux actions que svn ferait tout aussi bien. Il introduit des fonctionnalités supplémentaires que l'on ne trouve pas dans le client texte interactif. Par exemple, vous pouvez utiliser l'action put pour ajouter ou modifier un fichier dans le dépôt, en copiant le contenu d'un fichier présent sur votre machine locale ou depuis le flux de l'entrée standard. Cet outil permet aussi de manipuler les propriétés des fichiers et dossiers suivis en versions avec les actions propset, propsetf et propdel, explicitement ou en copiant les valeurs des propriétés à partir d'un fichier local. Ces actions ne sont pas possible depuis le client texte interactif à l'heure actuelle.

Il est temps de préciser la différence entre ce que peut faire svnmucc et ce qu'il est souhaitable qu'il fasse. Deux exemples viennent à l'esprit :

Comme vous travaillez sans copie de travail, il est impossible pour Subversion de détecter des conflits avant la propagation. Lors d'une utilisation classique de svn, les changements qui sont propagés vers le serveur sont comparés à une version de base déterminée du fichier ou du répertoire, afin de ne pas écraser par inadvertance des modifications concurrentes apportées par un autre membre de l'équipe. Le serveur connait la version du fichier que vous aviez avant vos modifications et il sait si d'autres gens ont changé ce fichier depuis la révision que vous détenez. Ce sont ces informations dont le serveur a besoin pour refuser votre propagation et qu'elle n'écrase pas les changements faits par quelqu'un d'autre ; il vous force alors à intégrer ces changements dans votre copie de travail et à reconsidérer vos propres modifications. Avec svnmucc, il n'y a pas de copie de travail, ce qui vous donne la possibilité de contourner ces sécurités et d'agir comme si l'état courant du dépot était celui qui vous sert de base de travail. Heureusement, il est évident pour vous qu'un tel pouvoir ne s'utilise pas à la légère.

Heureusement, svnmucc vous permet de poser un garde-fou lors de son utilisation. Afin d'offrir un mécanisme de sécurité comparable à l'utilisation d'une copie de travail, svnmucc propose l'option --revision (-r). Avec cette option, vous pouvez spécifier manuellement une révision de base pour les modifications que vous essayez de propager. Cette révision de base est idéalement la plus récente du dépôt dont vous ayez connaissance.

	Avertissement
	Nous encourageons fermement les utilisateurs à utiliser, et de manière appropriée, l'option --revision (-r) de svnmucc.

L'utilisation appropriée de svnmucc put démontre sans équivoque comment l'option --revision (-r) doit être invoquée. Considérons que Harry veuille modifier le fichier suivi en versions LISEZMOI sans s'embêter à rappatrier une copie de travail complète (nous supposons qu'il n'y a pas d'autre raison de disposer d'une copie de travail pour cette action, telles que le lancement de scripts avant de propager une révision pour vérifier qu'elle satisfait certains critères). Il doit en premier lieu décider avec quelle révision du fichier il va travailler. Typiquement, les utilisateurs souhaitent travailler avec la version la plus à jour d'un fichier. Ainsi, Harry effectue la requête relative à la révision de la dernière modification du fichier et modifie le contenu du fichier dans un fichier temporaire local :

$ svn info http://svn.exemple.com/projets/bac-à-sable/LISEZMOI
Chemin : LISEZMOI
URL : http://svn.exemple.com/projets/bac-à-sable/LISEZMOI
Relative URL : ^/bac-à-sable/LISEZMOI
Racine du dépôt : http://svn.example.com/projects
UUID du dépôt : 13f79535-47bb-0310-9956-ffa450edef68
Révision : 22
Type de nœud : fichier
Auteur de la dernière modification : sally
Révision de la dernière modification : 14
Date de la dernière modification : 2012-09-02 10:34:09 -0400 (dim. 02 sep. 2012)

$ svn cat -r 14 http://svn.exemple.com/projets/bac-à-sable/LISEZMOI \
      > LISEZMOI.tempo
$

Harry possède maintenant une copie du fichier LISEZMOI tel qu'il était lors de sa dernière modification. Il fait ses modifications dans cette copie du fichier. Naturellement, lorsqu'il a terminé, il veut propager ces modifications vers le dépôt.

Maintenant, si Harry utilise naïvement svnmucc put …, pour remplacer le contenu de LISEZMOI dans le dépôt par le contenu de son fichier local, il fait un abus de pouvoir avec svnmucc. Que se passe-t-il si, quelques microsecondes avant sa propagation, Sally a aussi modifié le fichier LISEZMOI ? Tout comme svn, svnmucc n'essaiera pas de fusionner sur le serveur les modifications de chacun pour les préserver. Non, svnmucc remplacera simplement la dernière version du fichier par la nouvelle qu'on lui donne. Harry n'en aura pas conscience, Sally sera furieuse.

$ svnmucc put LISEZMOI.tempo \
          http://svn.exemple.com/projets/bac-à-sable/LISEZMOI \
          -m "Modifié le fichier LISEZMOI."
r24 propagée par harry le 2013-01-21T16:21:23.100133Z
$
Message from sally@shell.example.com on pts/2 at 16:26 ...
Il faut qu'on se parle. Maintenant.
EOF

À la place, Harry doit rappeler la révision qu'il a utilisée comme base de travail à la commande svnmucc via l'option --revision (-r). Ainsi, le serveur pourra rejeter la propagation si, par malheur, Harry essaie de modifier un élément obsolète :

$ svnmucc -r 14 put LISEZMOI.tempo \
          http://svn.exemple.com/projets/bac-à-sable/LISEZMOI \
          -m "Modifié le fichier LISEZMOI."
svnmucc: E170004: Item '/bac-à-sable/LISEZMOI' est obsolète.
$

Comme toutes les autres options de svnmucc, l'option --revision (-r) est globale pour la commande, c'est-à-dire qu'elle s'applique à toutes les actions spécifiées dans la commande. Cela vous permet d'avoir les mêmes sortes de garde-fous que si vous aviez extrait une copie de travail du dépôt tout entier (et donc comme si vous travailliez sur une copie de travail uniformisée à la même révision), vous aviez effectué vos modifications sur cette copie de travail, puis vous aviez propagé toutes les modifications en même temps.

Comme vous pouvez le constater, svnmucc trouve bien sa place dans la boite à outils Subversion. Pour une référence complète des possibilités de cet outil, reportez-vous à Guide de référence de svnmucc : client texte Subversion pour URL multiples.