Une fois encore, svn copy vient à la rescousse. Si vous voulez créer un instantané de /calc/trunk identique à ce qu'il est dans la révision HEAD, faites-en une copie :

$ svn copy http://svn.exemple.com/depot/calc/trunk \
           http://svn.exemple.com/depot/calc/tags/version-1.0 \
      -m "Étiquetage de la version 1.0 du projet 'calc'."

Révision 902 propagée.

Cet exemple présuppose qu'un répertoire /calc/tags existe déjà (s'il n'existe pas, vous pouvez le créer en utilisant svn mkdir). Une fois la copie terminée, le nouveau dossier version-1.0 sera pour toujours un instantané du dossier /trunk tel qu'il était en révision HEAD au moment où vous avez effectué la copie. Bien sûr, vous voudriez peut-être être plus précis quant à quelle révision vous copiez, au cas où quelqu'un d'autre aurait propagé des modifications au projet pendant que vous regardiez ailleurs. Donc si vous savez que la révision 901 de /calc/trunk est exactement l'instantané que vous voulez, vous pouvez le spécifier en passant -r 901 à la commande svn copy.

Mais attendez un moment : cette procédure de création d'étiquette, n'est-ce pas la même procédure que nous avons utilisé pour créer une branche ? En fait, oui. Dans Subversion, il n'y pas de différence entre une étiquette et une branche. Toutes deux ne sont que des répertoires ordinaires qui sont créés par copie. Comme pour les branches, la seule raison qui fasse qu'un répertoire copié soit une « étiquette » est que les humains ont décidé de le traiter de cette façon : aussi longtemps que personne ne propage de modification à ce répertoire, il reste un instantané. Si les gens commencent à y propager des choses, il devient une branche.

Si vous administrez un dépôt, il y a deux approches possibles pour gérer les étiquettes. La première approche est une politique de « non-intervention » : en tant que convention définie pour le projet, vous décidez où vos étiquettes sont placées et vous vous assurez que tous les utilisateurs savent comment traiter les répertoires qu'ils copient (c'est-à-dire que vous vous assurez qu'ils savent qu'ils ne doivent rien y propager). La seconde approche est plus paranoïaque : vous pouvez utiliser un des contrôles d'accès fournis avec Subversion pour empêcher que quiconque ne puisse faire autre chose dans la zone des étiquettes que d'y créer de nouvelles copies (voir le Chapitre 6, Configuration du serveur). L'approche paranoïaque n'est cependant pas nécessaire, en général. Si un utilisateur propage accidentellement une modification à un répertoire d'étiquettes, vous pouvez simplement revenir en arrière sur cette modification comme expliqué dans le paragraphe précédent. C'est ça la gestion de versions, après tout !

Il vous arrivera sûrement de vouloir que votre « instantané » soit plus compliqué qu'un simple répertoire à une unique révision donnée.

Par exemple, imaginons que votre projet est bien plus vaste que notre exemple calc : supposons qu'il contient un bon nombre de sous-dossiers et bien plus de fichiers encore. Au cours de votre travail, vous pouvez très bien décider que vous avez besoin de créer une copie de travail destinée à des fonctionnalités particulières et à des corrections de bogues. Pour cela vous pouvez antidater de manière sélective des fichiers ou dossiers à des révisions données (en utilisant généreusement svn update avec l'option -r), déporter des fichiers et des dossiers vers des branches particulières (au moyen de svn switch) ou même effectuer manuellement un tas de modifications locales. Quand vous en avez terminé, votre copie de travail est un vrai bazar, fait d'emplacements du dépôt à des révisions différentes. Mais après l'avoir testée, vous êtes alors certain que c'est l'exacte combinaison de données que vous vouliez étiqueter.

C'est alors le moment de prendre un cliché. Copier une URL vers une autre ne fonctionnera pas cette fois. Dans le cas présent, vous voulez prendre un cliché de l'arrangement exact de votre copie de travail et le placer dans le dépôt. Par chance, svn copy possède en fait quatre utilisations différentes (au sujet desquelles vous pouvez obtenir des informations au Partie II, « Guide de référence des commandes Subversion »), dont la possibilité de copier une arborescence de travail vers le dépôt :

$ ls
ma-copie-de-travail/

$ svn copy ma-copie-de-travail \
           http://svn.exemple.com/depot/calc/tags/mon-etiquette \
           -m "Étiquette l'état de ma copie de travail existante."

Révision 940 propagée.

Désormais il y a un nouveau répertoire dans le dépôt, /calc/tags/mon-etiquette, qui est un instantané exact de votre copie de travail : révisions mixtes, URL, modifications locales et tout et tout…

D'autres utilisateurs ont trouvé des usages intéressants pour cette fonctionnalité. Il y a parfois des situations où votre copie de travail contient un paquet de modifications locales que vous aimeriez montrer à un collaborateur. Au lieu de lancer svn diff et d'envoyer un fichier patch (qui ne listera pas les modifications de répertoires, de liens symboliques ou de propriétés), vous pouvez utiliser svn copy pour « envoyer » votre copie de travail vers une zone privée du dépôt. Votre collaborateur peut ensuite soit extraire une copie carbone de votre copie de travail, soit utiliser svn merge pour recevoir exactement vos modifications.

Bien que ce soit une méthode élégante pour mettre à disposition un instantané rapide de votre copie de travail, remarquez que ce n'est pas une bonne manière de créer une branche initialement. La création de branche devrait être un évènement en soi, tandis que cette méthode combine la création d'une branche avec des modifications supplémentaires apportées aux fichiers, le tout au sein d'une seule révision. Ceci rend très difficile (à terme) d'identifier un unique numéro de révision en tant que point de création de la branche.