Réparer la somme de contrôle SVN

Question

J'utilise subclipse dans Flex Builder 3 et j'ai récemment reçu cette erreur en essayant de valider :

svn: Checksum mismatch for '/Users/redacted/Documents/Flex Builder 3/path/to/my/file.mxml'; expected: 'f8cb275de72776657406154dd3c10348', actual: 'null'

J'ai contourné ce problème en :

1. Valider tous les autres fichiers modifiés, en omettant celui qui pose problème.
2. Copie du contenu du fichier de problèmes dans une fenêtre TextMate
3. Supprimer mon projet dans FlexBuilder/Eclipse
4. Vérifier mon projet fraîchement depuis SVN
5. Copie du texte du fichier de problème à partir de la fenêtre TextMate
6. Valider les modifications.

Cela a fonctionné, mais je ne peux m'empêcher de penser qu'il existe une meilleure solution.Qu'est-ce qui se passe réellement pour provoquer l'erreur svn:checksum et quelle est la meilleure solution.

Peut-être plus important encore : est-ce le symptôme d’un problème plus grave ?

Answer 1

Le fichier dans le répertoire .svn qui garde une trace de ce que vous avez extrait, quand, quelle révision et d'où, a été corrompu d'une manière ou d'une autre, pour ce fichier particulier.

Ce n'est pas plus dangereux ou critique que le problème normal d'un fichier impair, et peut être dû à divers problèmes, comme la mort d'un programme Subversion en cours de modification, une coupure de courant, etc.

À moins que cela n’arrive davantage, je n’en tirerais pas grand-chose.

Il peut être corrigé en faisant ce que vous avez fait, en faisant une copie de vos fichiers de travail, en extrayant une nouvelle copie et en rajoutant les fichiers modifiés.

Notez que cela peut poser des problèmes si vous avez un projet chargé dans lequel vous devrez normalement fusionner les modifications.

Par exemple, vous et un collègue extrayez tous les deux une nouvelle copie et commencez à travailler sur le même fichier.À un moment donné, votre collègue vérifie ses modifications.Lorsque vous essayez de faire de même, vous rencontrez le problème de somme de contrôle que vous rencontrez.Si vous faites maintenant des copies de vos fichiers modifiés, effectuez une nouvelle extraction, alors Subversion perdra la trace de la manière dont vos modifications doivent être fusionnées.

Si vous n'avez pas rencontré le problème dans ce cas, lorsque vous aurez réussi à archiver vos modifications, vous devrez d'abord mettre à jour votre copie de travail et éventuellement gérer un conflit avec votre fichier.

Cependant, si vous effectuez une nouvelle commande, complétée par les modifications de vos collègues, il semble maintenant que vous ayez supprimé ses modifications et les avez remplacées par les vôtres.Pas de conflits, et aucune indication de subversion indiquant que quelque chose ne va pas.

Answer 2

Il existe également une cause plus simple à cela que de simples bugs ou une corruption de disque, etc.Je pense que la cause la plus probable pour laquelle cela se produit est lorsque quelqu'un écrit un remplacement de texte récursif sur la copie de travail, sans exclure les fichiers .svn.
Cela signifie que les copies vierges des fichiers (essentiellement la version BASE des fichiers, stockée dans la zone administrative .svn) sont modifiées, ce qui invalide la somme MD5.

@Andrew Hedges :cela explique également pourquoi votre solution résout ce problème.

Answer 3

SVN conserve des copies vierges de tous les fichiers que vous extrayez enfouis dans les répertoires .svn.C'est ce qu'on appelle la base de texte.Cela permet des différences et des retours rapides.Au cours de diverses opérations, SVN effectuera des sommes de contrôle sur ces fichiers à base de texte pour détecter les problèmes de corruption de fichiers.

En général, une incompatibilité de somme de contrôle SVN signifie qu'un fichier qui n'aurait pas dû être modifié a été modifié d'une manière ou d'une autre.Qu'est-ce que cela signifie?

1. Corruption du disque (mauvais disque dur ou câble IDE)
2. Mauvaise RAM
3. Mauvaise liaison réseau
4. Une sorte de processus en arrière-plan a modifié un fichier dans votre dos (malware)

Tout cela est mauvais.

CEPENDANT, je pense que votre problème est différent.Regardez le message d'erreur.Notez qu'il s'attendait à des hachages MD5, mais qu'il est revenu « nul ».S'il s'agissait d'un simple problème de corruption de fichier, je m'attendrais à ce que vous ayez deux hachages MD5 différents pour l'attendu/obtenu.Le fait que vous ayez un « nul » implique que quelque chose d’autre ne va pas.

J'ai deux théories :

1. Bug dans SVN.
2. Quelque chose avait un verrou exclusif sur le fichier et le MD5 n'a pas pu se produire.

Dans le cas du n°1, essayez de mettre à niveau vers la dernière version de SVN.Peut-être aussi publier ceci sur la liste de diffusion svn-devel (http://svn.haxx.se), afin que les développeurs puissent le voir.

Dans le cas du numéro 2, vérifiez si le fichier est verrouillé.Vous pouvez télécharger une copie de Process Explorer pour vérifier.Notez que vous voulez probablement voir qui a un verrou sur le base de texte fichier, pas le fichier réel que vous essayiez de valider.

Answer 4

Je reçois parfois des choses similaires, généralement avec des fichiers dont personne n'a eu accès depuis des semaines.Généralement, si vous savez que vous n'avez pas travaillé dans le répertoire en question, vous pouvez simplement supprimer le répertoire présentant le problème et exécuter

svn update

pour le recréer.

Si vous avez des modifications en direct dans le répertoire, comme lassevk et vous-même l'avez suggéré, une approche plus prudente est nécessaire.

De manière générale, je dirais que c'est une bonne idée de ne pas laisser les fichiers modifiés non validés et de garder la copie de travail bien rangée - n'ajoutez pas tout un tas de fichiers supplémentaires dans la copie de travail que vous n'allez pas utiliser.Engagez-vous régulièrement, puis si la copie de travail s'effondre, vous pouvez simplement supprimer le tout et recommencer sans vous soucier de ce que vous pourriez ou non perdre, et sans avoir à essayer de déterminer quels fichiers enregistrer.

Answer 5

Aujourd'hui encore, j'ai réussi à me remettre de cette erreur en extrayant une copie du répertoire corrompu dans /tmp et en remplaçant les fichiers dans .svn/text-base par ceux qui viennent d'être créés.J'ai écrit la procédure en détail ici sur mon blog. Je serais intéressé d'entendre des utilisateurs SVN plus expérimentés quels sont les avantages et les inconvénients de chaque approche.

Answer 6

essayer:svn up --force fichier.c

Cela a fonctionné pour moi sans rien faire de plus

Answer 7

J'ai observé de nombreuses solutions, depuis la correction du fichier .svn/entries jusqu'à une nouvelle extraction.

Cela peut être une nouvelle façon (merci à mon collègue) :

- go to work directory where recorder/expected checksum issue occured
- call "svn diff" and make sure that there isnt any local modifications
- cd ..
- remove trouble file's directory with "rm -rf"
- issue "svn up" command, svn client will restore new fresh files copies

Answer 8

Matt, il existe un moyen plus simple que celui que vous avez décrit : modifier la somme de contrôle dans le fichier .svn/entries.Voici la description complète :http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/

Answer 9

Une autre solution de contournement, peut-être encore plus effrayante, pour les conflits de somme de contrôle que j'ai trouvée est la suivante :

MISE EN GARDE: Assurez-vous que votre copie locale est la version la plus connue ET que toute autre personne participant à votre projet sait ce que vous faites !(au cas où cela ne serait pas déjà évident).

si vous savez que votre copie locale du fichier est "la bonne", vous pouvez directement supprimer le fichier du serveur SVN, puis forcer la validation de votre copie locale.

syntaxe pour la suppression directe :

svn delete -m "deleting corrupted file XXXX" 
svn+ssh://username@svnserver/path/to/XXXX

bonne chance!

J.

Answer 10

Au lieu d'extraire une nouvelle copie (ce que j'ai également dû faire après avoir essayé toutes les autres options) et de fusionner toutes vos modifications que vous aviez précédemment enregistrées, l'approche suivante a fonctionné de la même manière, mais m'a permis d'économiser une somme considérable. du temps, et éventuellement quelques erreurs :

1. Découvrez une nouvelle copie de travail
2. Copiez le dossier .svn de votre nouvelle copie dans votre copie corrompue
3. Voilà

Bien sûr, vous devez sauvegarder votre copie de travail originale corrompue au cas où.Dans mon cas, j'étais libre de le supprimer une fois que j'avais terminé, car tout s'était bien passé.

Answer 11

Cela se produira lorsque le dossier .svn sera corrompu.Solution:Supprimez tout le dossier du fichier et extrayez à nouveau le dossier.

Answer 12

Ayant ce problème, nos machines virtuelles de développement sont toutes *nix nos postes de travail win32.Certains imbéciles ont créé des fichiers du même nom (cas différent) sur la case * Nix Soudain vérification sur Win32 exploser ...Parce que Win ne sait pas lequel des 2 fichiers du même nom contre MD5, les caisses sur * Nix étaient bien ...nous laissant nous gratter un peu la tête

J'ai pu mettre à jour le dépôt sur la boîte Win en copiant les dossiers ".svn" à partir d'une boîte * nix avec une bonne copie de travail.je n'ai pas encore vu si le dépôt peut être nettoyé au point où nous pouvons à nouveau effectuer un paiement complet

Answer 13

Un autre moyen simple....

1. Mettez à jour votre projet pour obtenir la dernière version
2. extraire la même version dans un autre dossier
3. remplacez le dossier .svn de la nouvelle extraction par la copie de travail (j'ai remplacé les fichiers .svn-base)

Answer 14

1. Extrayez uniquement le dossier contenant le fichier problématique du référentiel vers un autre emplacement.
2. S'assurer .svn\text-base\<problematic file>.svn-base est identique à celui extrait.
3. Assurez-vous que la section du fichier problématique (toutes les lignes de la section) dans .svn\entries est identique à celui extrait.

Answer 15

Vous ne le croirez pas, mais j'ai corrigé mon erreur en supprimant le <scm>...</scm> position du fichier pom.xml incriminé que j'espérais enregistrer.Il contenait l'URL du référentiel Subversion dans lequel il est archivé (c'est à cela que sert le paramètre Maven !), mais d'une manière ou d'une autre, il a généré une somme de contrôle erronée pour le fichier lors de l'archivage.

J'ai littéralement essayé toutes les méthodes mentionnées ci-dessus pour résoudre ce problème, mais en vain.Ai-je rencontré une situation très rare dans laquelle le générateur de somme de contrôle n'est pas assez robuste ?

Answer 16

Je suis également tombé sur ce problème et j'essayais de chercher des solutions rapides, j'ai essayé certaines des solutions données dans ce fil.Voici comment j'ai résolu ce problème dans mon environnement de développement (pour moi, c'était un changement minime) :

1- Répertoire supprimé localement dans lequel le fichier a été corrompu (WEB-INF) :

 svn: Checksum mismatch for 'path-to-folder\WEB-INF\web.xml':
   expected:  d60cb051162e4a6790a3ea0c9ddfb434
     actual:  16885ded2cbc1adc250e4cbbc1427546

2- Répertoire copié et collé (WEB-INF) à partir d'une nouvelle caisse

3- Est-ce que svn a été activé, maintenant Eclipse/TortoiseSVN a commencé à afficher des conflits dans ce répertoire

4- Conflit marqué comme résolu

Cela a fonctionné, j'ai pu mettre à jour, valider un fichier web.xml corrompu plus tôt

Answer 17

Dans mon cas, la somme était différente.Tout ce que j'ai fait c'est :

1) Effectuez l'extraction dans un dossier séparé

2) Remplacer par le fichier de ce dossier dans le répertoire .svn par le fichier problème de mon projet qui a été indiqué dans le message d'erreur svn-client

3) ..Bénéfice !

Answer 18

Bien qu'il s'agisse d'un vieux problème, j'ai pensé que je donnerais également mes 2 centimes, car je viens de lutter contre le problème depuis plus d'une heure.

Les solutions ci-dessus n'ont pas fonctionné pour moi ou semblaient trop compliquées.

Ma solution consistait simplement à supprimer tous les dossiers svn du projet.

find . -name .svn -exec rm -rf {} \;

Après cela, j’ai à nouveau effectué une simple vérification du projet.Laissant ainsi tous mes fichiers non validés intacts, tout en obtenant une reconstruction de tous les fichiers svn.

Answer 19

J'ai eu ce problème sur Ubuntu 14.04 et je l'ai résolu en suivant les étapes suivantes :

1. $ cd /var/www/monProjet
2. $ mise à niveau svn
3. $ mise à jour svn

après ces étapes, j'ai pu valider le fichier sans erreur.

Answer 20

1. Allez dans le dossier à l'origine du problème
2. Exécuter la commande svn update --set-depth empty
3. Ce dossier se videra et rétablira le dossier vide
4. Synchronisez avec le svn et mettez à jour.

Cela fonctionne pour moi.

Answer 21

voici comment j'ai résolu le problème - c'est simple, mais comme indiqué dans jsh ci-dessus, vous devez vous assurer que votre copie est la meilleure.

simplement

1. faites une copie de tous les fichiers problématiques, dans le même dossier.
2. supprimer les anciens avec svn rm
3. commettre.
4. puis renommez les copies avec les noms de fichiers d'origine.
5. s'engager à nouveau.

je suppose que cela tue probablement toutes sortes d'historique de révision sur ce fichier, c'est donc une façon assez moche de procéder...