2009-08-19 6 views
4

Peu importe comment je suis arrivé ici, je suis en mesure de restaurer un dépôt SVN à partir de la sauvegarde. Malheureusement, la sauvegarde a été légèrement corrompue et sur plus de 19000 révisions, environ 80 sont perdues. La sauvegarde était un fichier bzip2 et j'ai pu utiliser bzip2recover pour récupérer environ 99% des blocs. Ce sont des «biens connus» puisqu'ils se sont décompressés avec succès. Par conséquent, j'ai été en mesure de créer une liste des validations connues et des validations perdues.svn récupération - restauration des révisions individuelles

Le référentiel d'origine était également endommagé, mais de nombreux fichiers ont survécu. Malheureusement, le référentiel dans son ensemble est cassé. J'ai donc la chance d'avoir les fichiers des répertoires db/revs et db/revprops d'origine pour ces révisions manquantes. Les chances sont que la corruption du fichier de sauvegarde bz2 ne s'aligne pas avec la corruption des fichiers db/revs.

J'ai reconstruit tout jusqu'à r13892, mais je sais que r13893 est corrompu, donc je n'ai pas de sauvegarde pour r13893. J'ai les fichiers db/revs/13893 et ​​db/revprops/13893 du dépôt d'origine.

J'ai créé et reconstruit le référentiel avec svn-1.4, mais j'ai migré vers svn-1.6 pour pouvoir utiliser la commande svnadmin verify sélective (sur une seule ou plusieurs plages de validation).

Je pensais peut-être que je pourrais déposer ces deux fichiers dans le nouveau référentiel, mettre à jour db/current [1], puis continuer. Cependant quand j'essaye de vérifier que j'obtiens cette erreur:

$ svnadmin verify new-svn 
* Verified revision 1. 
... 
* Verified revision 13889. 
* Verified revision 13890. 
* Verified revision 13891. 
* Verified revision 13892. 
svnadmin: Can't read file 'svn/db/revs/13214': End of file found 

Ainsi ceci évidemment n'a pas fonctionné. Je ne sais pas ce que 13214 a à voir avec quoi que ce soit ici.

Je suis revenu à svn-1.4.6 juste au cas où quelque chose d'étrange se produirait avec 1.6. Malheureusement, je reçois le même résultat - révision 13893 ne vérifie pas:

... 
* Verified revision 13891. 
* Verified revision 13892. svnadmin: Can't read file 'svn/db/revs/13214': 
End of file found 

Alors, voici ce que je sais:

  • Je sais que les révisions 1-13892 sont 100% correct (à moins que, par hasard, extrêmement improbable un bloc bz2 a été décomprimé incorrectement mais a passé la somme de contrôle).
  • Je ne sais pas si les fichiers r13893 du dépôt SVN original sont corrects - ils peuvent être corrompus, mais la quantité de corruption est si petite qu'elle est peu probable (mais possible).

Est-ce que quelqu'un a des idées sur la façon dont je pourrais combler ce trou? Notez que j'ai un r13894 100% confiant en ma possession, donc si je peux obtenir r13893 branché je peux continuer avec le reste de la restauration.

[1] Je mis à jour db/courant avec ce script: http://svn.haxx.se/users/archive-2005-12/att-0630/make-current-fix.py

Je l'ai testé cela sur d'autres dépôts SVN (! Après la désactivation de l'écriture à db/courant) pour vérifier qu'il produisait la même valeur comme cela déjà là. Cela fait.

Répondre

2

En ce qui concerne ceci:

svnadmin: Can't read file 'svn/db/revs/13214': End of file found 

Je soupçonne que quelque chose référencé rev 13893 de rev 13214 (par exemple une copie de fichiers, ou des trucs sauter-tours, ou quelque chose).

Lors du chargement svn, les nouvelles révisions correspondaient-elles aux révisions d'origine? Je me souviens d'avoir rencontré un cas où mon vidage faisait référence à un rev 0, et il a été chargé en tant que rev 1. Si quelque chose comme ça se produit ici, la référence arrière de rev 13214 sera désactivée par un.

Vous pourriez essayer d'utiliser les fichiers du repo db pour créer le rev manquant au format dump. Malheureusement, je ne connais pas d'outil qui puisse le faire. Mais je recommanderais de regarder SvnDumpTool; il est capable de manipuler svn dumps de beaucoup de manières utiles.

Divulgation: J'ai contribué à svndumptool dans le passé

+0

Oui, en haut de r13893 il est dit: DELTA 13214 0 12567271 Il est donc un delta au-dessus de 13214, ce qui explique d'où ça vient de. Une chose que je remarque est que mon binaire reconstruit engage (en db/régime moteur) commencer par ceci: SVN^A^@^@<86>^@ Et mon r13893 d'origine commettras ressemble à ceci: SVN^@^@<86>^@ Notez que le premier octet après "SVN" est^@ (00) dans l'ancienne validation, mais^A (01) dans les nouveaux validations. Est-ce un numéro de version xdelta? Peut-être que j'ai besoin de reconstruire 1 à 13892 avec une version de subversion qui utilise le même format xdelta? – meowsqueak

+0

Je ne connais pas le^@ vs^A. Mais lors du chargement de la sauvegarde, il devrait vous dire quel était le numéro de rev original et quel était le numéro de rev nouvellement créé. Est-ce que ces deux chiffres correspondent? – retracile

+1

Oui, ces chiffres correspondent. J'ai résolu ce problème en fait - c'était parce que j'avais créé le nouveau repo avec 1.4, mais les anciens fichiers ont été créés avec 1.3, donc le format xdelta était différent. J'ai recommencé avec svn-1.3 et ce problème est maintenant résolu. Malheureusement svnadmin segfaults plus tard, donc tout n'est pas très bien ... – meowsqueak

Questions connexes