la charge de subversion échoue avec «aucune révision de ce type»


18

J'essaie d'apprendre à migrer un dépôt Subversion et je rencontre un problème qui n'a pas de sens pour moi. J'ai l'habitude svndumpfilterde diviser un sous-projet et j'ai supprimé certains préfixes de chemin. Plusieurs centaines de validations importent désormais correctement, mais je reçois l'erreur suivante:

<<< Started new transaction, based on original revision 19190
     * editing path : branches/features/DynamicSource ... done.
     * editing path : branches/features/DynamicSource/src/build.properties ... done.
     * editing path : branches/features/DynamicSource/src/client/default.htm ...done.
     * editing path : branches/features/DynamicSource/src/client/js/AdHocController.js ... done.
     * editing path : branches/features/DynamicSource/src/client/js/Report.js ... done.
svnadmin: E160006: No such revision 19098
     * adding path : branches/features/DynamicSource/src/client/js/Enums.js ...

OK, alors je vais dans le fichier de vidage à regarder les révisions 19190 et 19098. Tout d' abord, la révision 19098 - t figurer dans le fichier de vidage et a été importé sans problème. La révision 19190 est une fusion. Dans 19190, voici les informations de ce dernier fichier, qui semblent être à l'origine du problème:

Node-copyfrom-rev: 19100
Node-copyfrom-path: trunk/src/client/js/Enums.js
Text-copy-source-md5: 2db7f8d9c0ba4750d88ce0722731aad6
Node-path: branches/features/DynamicSource/src/client/js/Enums.js
Node-action: add
Text-copy-source-sha1: 8f930509f8dbc17c5e82cd40aa5a76454d3d812c
Node-kind: file
Content-length: 0

Confusément, la révision 19100 n'existe PAS dans ce fichier filtré. Mais l'erreur ne fait pas référence à 19100, elle fait référence à 19098!

Que dois-je faire pour charger ce fichier?

Merci!


Si quelque chose de compliqué ("vidage et filtrage" suivi de "importation") échoue, essayez d'abord quelque chose de plus simple ("vidage", puis "importation"). Je n'ai jamais migré qu'un repo entier, et cela s'est facilement passé.
Dirk Eddelbuettel

Merci, Dirk. Nous devons vraiment diviser ce repo, cependant.
Harlan

Peut-être faire "Dump, Import. Réduire à la main, Dump encore. Importer 2nd Dump." ?
Dirk Eddelbuettel

À moins que je manque quelque chose, je ne pense pas que SVN fonctionne de cette façon. Vous devez réduire en utilisant le fichier de vidage et svndumpfilter. Et nous voulons garder l'histoire autant que possible.
Harlan

3
Pourquoi ne pas migrer vers git ou mercurial, et se débarrasser de l'héritage SVN en même temps?
vonbrand

Réponses:


1

J'ai fait ce genre de division plusieurs fois. Je pense que tout dépend de la façon dont vous utilisez le filtre et du traitement que vous effectuez ensuite sur le fichier de vidage. Personnellement, j'ai également dû changer l'utilisateur svn, à côté du chemin du projet, et renuméroter les révisions. Juste pour que vous puissiez voir ce qui peut être fait, voici une partie pertinente de mon script.

grp=$cust_group
usr=$cust_customer
svndumpfilter include $grp/$usr --drop-empty-revs --renumber-revs  <$repo_dump > $repo_dump.$usr
sed -e "s/Node-path: $grp\/$usr/Node-path: /" <$repo_dump.$usr >$repo_dump.$usr.fixed1
sed -e "s/Node-copyfrom-path: $grp\/$usr/Node-copyfrom-path: /" <$repo_dump.$usr.fixed1 >$repo_dump.$usr.fixed2
sed -e "/Node-path: /{ N; N; N; N; N; N; s/Node-path: \nNode-action: add\nNode-kind: dir\nProp-content-length: 10\nContent-length: 10\n\nPROPS-END//}" <$repo_dump.$usr.fixed2 >$repo_dump.$usr.fixed3
sed -e "/svn:author/{ N; N; s/svn:author\n.*\n$svn_usr_from/svn:author\nV $svn_usr_len\n$svn_usr_to/}" <$repo_dump.$usr.fixed3 >$repo_dump.$usr.fixed4
svnadmin load $repo_dir/$cust_group/$cust_customer --ignore-uuid < $repo_dump.$usr.fixed4

chown svn:svn -R $repo_dir/$cust_group/$cust_customer
#chown apache $repo_dir/$cust_group/$cust_customer/db/txn-current
#chown apache $repo_dir/$cust_group/$cust_customer/db/current
# apache is in svn group so the above 2 are not needed
chmod -R g+rw $repo_dir/$cust_group/$cust_customer

Ce qui se passe là-bas, c'est que d'abord, je filtre ce dont j'ai besoin, je supprime les révisions vides pour des raisons évidentes et je les renumérote. Cela donne de belles révisions ordonnées. Ensuite, je laisse tomber le chemin racine du projet qui, dans mon cas, était sous forme de groupe / client, car dans le nouveau référentiel qui n'a aucun sens (au lieu de cela, le référentiel lui-même est groupe / client sur le disque) - ce sont les 2 premiers sed

Ensuite, je supprime l'importation de répertoires non nommés, un résultant des 2 seds ci-dessus pour le répertoire de groupe et puis un pour l'ajout du répertoire de groupe / client.

enfin, j'ai séduit l'auteur pour le changer en un nouveau. Celui-ci était également un peu délicat car il nécessitait de mettre à jour la longueur de la définition de la propriété.

Ensuite, je le charge et corrige les autorisations du système de fichiers. Notez les 2 chowns commentés pour apache, dans certains cas, vous en aurez besoin. J'ai finalement fini par ajouter apache au groupe svn.

Maintenant, je n'ai jamais eu de fusion dans mes repo SVN donc je n'ai jamais eu à les traiter pour la scission. Dans votre cas, j'imagine que ce qui se passe est que le chemin de révision source n'est pas importé et c'est pourquoi il ne le trouve pas même si l'erreur se plaint de la révision elle-même). La règle générale dans le fichier d'importation svn est que tout ce qui est mentionné à un moment donné doit avoir déjà été importé avant d'être référencé. Donc, vous avez peut-être filtré quelque chose que vous ne devriez pas, même si vous le souhaitez, ou vous n'avez pas correctement mis à jour le fichier de vidage pour refléter les autres modifications que vous avez apportées.

Si vous fournissez la structure pertinente de votre dépôt d'origine, y compris le chemin source fusionné, ainsi que vos appels avec des paramètres, je pourrai peut- être vous dire ce que vous avez manqué. Mon argent est à la source de la fusion.


1

J'ai utilisé un excellent outil svndumpsanitizer . Le problème est que la structure du référentiel subversion est trop compliquée. Lorsque svndumpfilter est à la révision 10, il n'a aucun moyen de savoir si un nœud que l'utilisateur veut supprimer, sera déplacé vers une position qu'il souhaite conserver dans la révision 113. Il fait donc la seule chose qu'il peut faire - il supprime le nœud , et à la révision 113, le craps est sorti car il a déjà jeté les données dont il aurait eu besoin.

Svndumpsanitizer fonctionne d'une manière différente. Il scanne les nœuds plusieurs fois afin de découvrir quels nœuds doivent réellement être conservés. Après avoir déterminé les nœuds à conserver, il écrit uniquement ces nœuds dans le fichier de sortie. Enfin - si nécessaire - il ajoute un commit qui supprime tous les nœuds indésirables qui devaient être conservés afin de ne pas casser le référentiel.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.