Description

Il arrive qu'un administrateur doive changer l'emplacement (tout du moins du point de vue de l'utilisateur) d'un dépôt. Le contenu du dépôt ne change pas mais l'URL racine du dépôt si. Le nom d'hôte peut aussi varier parce que le dépôt est accessible via une autre machine. Ou encore, le type d'URL change parce que le dépôt est maintenant accessible en SSL (en utilisant https://) au lieu du simple HTTP). Ainsi, les raisons pour changer l'emplacement d'un dépôt ne manquent pas. Mais, idéalement, un « changement d'adresse » d'un dépôt ne devrait pas rendre inutilisable du jour au lendemain toutes les copies de travail qui pointent vers ce dépôt. Et heureusement, ce n'est pas le cas. Plutôt que de forcer les utilisateurs à extraire une nouvelle copie de travail quand un dépôt est déplacé, Subversion fournit la commande svn relocate qui modifie les métadonnées de la zone administrative de la copie de travail pour pointer vers la nouvelle adresse du dépôt.

La première forme de svn relocate permet de mettre à jour une ou plusieurs copies en effectuant essentiellement un rechercher-remplacer dans les URL racines des dépôts des copies de travail. Subversion remplace la sous-chaîne initiale PREFIX-SRC par la chaîne PREFIX-DST dans ces URL. Le préfixe d'URL de la source peut être aussi grand que nécessaire pour le différencier. Manifestement, pour utiliser cette forme, vous devez connaître à la fois l'URL racine actuelle du dépôt vers lequel pointe la copie de travail et la nouvelle URL de ce dépôt. Vous pouvez utiliser svn info pour déterminer la première.

La deuxième forme ne requiert pas de connaître l'URL racine du dépôt actuel vers lequel pointe la copie de travail mais seulement la nouvelle URL (URL-DST) vers laquelle pointer. Avec cette forme, une seule copie de travail peut être déplacée à la fois.

	Avertissement
	Les utilisateurs ont souvent du mal à faire la différence entre svn switch et svn relocate. Voici une règle générale : si la copie de travail doit refléter un nouveau répertoire à l'intérieur du dépôt, utilisez svn switch ; si la copie de travail pointe toujours vers le même répertoire, mais que l'emplacement du dépôt lui-même a changé, utilisez svn relocate.

Options

--ignore-externals

Exemples

Commençons par une copie de travail qui pointe vers l'URL d'un dépôt local :

$ svn info | grep URL:
URL: file:///var/svn/depot/trunk
$

L'administrateur décide de renommer le répertoire qui héberge le dépôt. Nous avons manqué l'annonce et nous nous retrouvons avec une erreur la fois suivante où nous essayons de mettre à jour notre copie de travail.

$ svn up
Mise à jour de '.' :
svn: E180001: Unable to connect to a repository at URL 'file:///var/svn/depot/trunk'
svn: E180001: Impossible d'ouvrir une session ra_local pour l'URL
svn: E180001: Le dépôt 'file:///var/svn/depot/trunk' n'a pu être ouvert

Après avoir alpagué l'administrateur à la machine à café, nous prenons connaissance du déplacement du dépôt et de sa nouvelle URL. Plutôt que d'extraire une nouvelle copie de travail, nous demandons simplement à Subversion de modifier les métadonnées de la copie de travail pour pointer vers le nouvel emplacement du dépôt.

$ svn relocate file:///var/svn/nouveau-depot/trunk
$

Subversion ne nous dit pas grand chose sur ce qu'il vient de faire mais il n'a pas signalé d'erreur non plus, c'est le principal. Voyons si la copie de travail est de nouveau fonctionnelle :.

$ svn up
Updating '.':
A    lib/nouveau.c
M    src/code.h
M    src/headers.h
…

	Note
	Là encore, cette commande n'affecte que les seules métadonnées de la copie de travail. Elle ne touchera pas au contenu de vos fichiers suivis ou non en versions, ne fera pas d'opérations sur le dépôt (telles que des propagations ou mises à jour), etc.

Quelques mois plus tard, nous apprenons que la société déplace les machines de développement sur des serveurs dédiés et que nous devons dorénavant utiliser HTTP pour accéder au dépôt. Nous faisons encore pointer notre copie de travail vers un nouvel emplacement :

$ svn relocate http://svn.ma-societe.com/depot/trunk
$

Maintenant, chaque fois que nous effectuons un tel déplacement, Subversion contacte le dépôt (à sa nouvelle URL, bien sûr) pour vérifier quelques éléments.

D'abord, il compare l'uuID du dépôt avec la valeur qu'il a stockée dans la copie de travail. Si les UUID ne correspondent pas, le déplacement de la copie de travail n'est pas autorisé. Peut-être ne s'agit-il pas du même dépôt après tout ?

Ensuite, Subversion s'assure que les métadonnées de la copie de travail mise à jour sont conformes à l'emplacement du répertoire à l'intérieur du dépôt. Subversion ne vous laisse pas accidentellement faire pointer une copie de travail d'une branche de votre dépôt vers l'URL d'une autre branche à l'intérieur du même dépôt (c'est le rôle de la commande svn switch décrite dans svn switch (sw).)

Enfin, Subversion n'autorise pas de déplacer une sous-arborescence de la copie de travail. Si vous devez faire pointer la copie de travail vers un nouvel emplacement, vous devez prendre tout le paquet. Cela évite des problèmes d'intégrité pour les métadonnées et protège le comportement de la copie de travail en général (et, soit dit en passant, vous auriez certainement du mal à trouver une bonne raison de déplacer uniquement une partie de votre copie de travail).

Examinons un dernier déplacement possible. Après avoir utilisé HTTP pendant un certain temps, la société migre vers un accès en SSL uniquement. Maintenant, le seul changement à l'URL du dépôt concerne le type d'accès qui passe de http:// à https://. Il existe deux façons pour faire pointer notre copie de travail vers le nouvel emplacement. La première est de faire exactement comme nous l'avons fait jusqu'ici :

$ svn relocate https://svn.ma-societe.com/depot/trunk
$

La deuxième consiste à demander à Subversion de permuter les préfixes qui ont changé dans l'URL :

$ svn relocate http https
$

Les deux méthodes produisent une copie de travail avec des métadonnées qui pointent vers le bon emplacement de dépôt.

Par défaut, svn relocate parcourt toutes les copies de travail externes incluses dans votre copie de travail et essaie de déplacer aussi ces copies de travail. Utilisez l'option --ignore-externals, pour désactiver ce comportement.