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

13

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.

svn

— Ioan
source

3

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.

— John
source

16

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.

— Yves Martin
source

+1 fonctionnait parfaitement avec une prise en pension délocalisée qui changeait également d'UUID

— Amro

8

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.

— Emil M
source

1

+ 1Merci pour la solution. Cela ne fonctionne pas pour les répertoires contenant des espaces. "find. -type f -name entrées -exec sed -i '/ old-uuid / new-uuid / g' {} \;" sans guillemets semble fonctionner.

— Tommy

sry pour necroing ce fil cette méthode m'a juste fait gagner beaucoup de temps .. pour les autres essayant ceci, je veux juste ajouter une note. Sed sur MACOX semble avoir besoin d'un usage légèrement différent, vous devez le dire sed -i "" 's/old-uuid/new-uuid/' et ça marche (juste les guillemets extra vides) ( ref )

— Karthik T

2

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'"

— Julien Barnoin
source

Merci pour les détails quand une copie de travail a été déplacée, je n’étais pas au courant de ce comportement

— Yves Martin

1

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

— Yasouser
source

Cette section parle des UUID du référentiel, pas des UUID de la copie de travail.

— Ioan

@ Ioan: Citation de cette section: Pour les personnes utilisant des versions de Subversion antérieures à 1.5, ces tâches sont un peu plus compliquées. Vous pouvez définir explicitement l'UUID d'un référentiel en redirigeant un fichier de vidage de référentiel portant la nouvelle spécification d'UUID via svnadmin load --force-uuid REPOS-PATH - N'est-ce pas ce dont vous aviez besoin?

— Yasouser

1

Encore une fois, non, je ne parle pas d’ UUID de référentiel , mais plutôt d’ UUID de copie de travail ; les copies de travail sont identiques à une commande.

— Ioan

Vous ne pouvez pas remplacer l’UUID de la copie de travail par celui du référentiel de serveur sans mettre à jour ou changer de copie de travail la copie de travail vers l’emplacement [nouveau / existant] du référentiel.

— Yasouser