Comment changer l'UUID de la copie de travail de subversion?

J'ai récemment mis à jour les référentiels Subversion d'une ancienne version 1.2.3 vers la version 1.6.0 via svnadmin dump / load . Les anciens référentiels utilisaient tous le même UUID (les référentiels ont été créés à l'aide de la copie d'un référentiel de modèles). J'ai modifié l'UUID de deux nouveaux référentiels via svnadmin setuuid pour qu'il soit unique. Je ne peux pas simplement déplacer mes copies de travail existantes de ces référentiels, car les UUID sont différents. Je sais comment exporter la copie de travail et extraire du nouveau référentiel, mais je me demandais s’il existait un moyen de changer l’UUID de la copie de travail sur place, comme ce que fait svnadmin setuuid pour les référentiels.

Vous devez éditer tous les fichiers 'entrées' dans votre référentiel tiré. Si le référentiel a beaucoup de répertoires, trouver + un script sed simplifiera la tâche.

Nouvelle réponse depuis le format de la copie de travail de Subversion 1.7 . Vous avez besoin d'un sqlite3utilitaire de ligne de commande.

Dans le répertoire racine de votre copie de travail, il y a maintenant un seul .svn/dossier avec une base de données SQLite. Vous pouvez interroger le référentiel actuel UUIDconnu pour votre copie de travail avec:

$ sqlite3 .svn/wc.db 'select uuid from REPOSITORY where id=1'
b6dc3e6c-5320-4549-b231-c153d86d7525

En conséquence, le changement UUIDpeut être effectué avec:

$ sqlite3 .svn/wc.db 'update REPOSITORY set uuid="1c0d1ec1-2326-0410-bef5-eb29cddfc032" where id=1'

Bien sûr, conservez une sauvegarde du .svn/wc.dbfichier avant d'appeler la requête de mise à jour. Il n'y a presque aucune chance que votre entité de référentiel ait un identifiant différent ou qu'il y ait plusieurs lignes dans cette table, mais vous pouvez vérifier si vous obtenez des résultats inattendus.

Voici une commande qui fait l'affaire pour SVN 1.6 et inférieur:

find . -type f -name entries -exec sed -i 's/old-uuid/new-uuid/g' {} \;

Remplacez old-uuidet new-uuidpar les identifiants actuels.

La réponse d'Yves Martin a très bien fonctionné pour plusieurs copies de travail avec SVN 1.8, mais nous avons fini par nous retrouver dans des cas où cela ne fonctionnait pas.

Exécuter la commande d'Yves sans "où id = 1" a fonctionné dans tous les cas pour nous:

$ sqlite3 .svn/wc.db 'update REPOSITORY set uuid="1c0d1ec1-2326-0410-bef5-eb29cddfc032"'

En recherchant pourquoi cela s'est produit, j'ai découvert que plusieurs UUID sont stockés lors du déplacement du référentiel, contrairement à l'intuition d'Yves selon laquelle cela ne devrait jamais se produire.

Une nouvelle entrée dans la table REPOSITORY est ajoutée après un transfert plutôt que de mettre à jour celui existant, en stockant un identifiant incrémenté avec la nouvelle racine du référentiel et son UUID. Ainsi, les cas qui ne fonctionnaient pas correctement étaient les copies de travail qui avaient déjà été déplacées dans le passé: la commande semblerait fonctionner, mais seul l'UUID initial a été modifié, pas celui actuellement utilisé.

On peut vérifier la liste des racines et des UUID stockés dans une copie de travail avec cette commande:

$ sqlite3 .svn/wc.db 'select id,uuid,root from REPOSITORY'

Pour finir, je noterai que je devais utiliser un ensemble de citations différent pour les fichiers de commandes / batch de Windows, comme suit:

> sqlite3.exe .svn\wc.db "update REPOSITORY set uuid='1c0d1ec1-2326-0410-bef5-eb29cddfc032'"

La section " Gestion des UUID du référentiel " dans svn red-bean book peut avoir la réponse que vous recherchez.