Réparation de la sum de contrôle SVN

J’utilise subclipse dans Flex Builder 3 et j’ai récemment reçu cette erreur lors de la tentative de validation:

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

Je l’ai contourné par:

  1. Commettre tous les autres fichiers modifiés, en omettant le problème.
  2. Copier le contenu du fichier de panne dans une fenêtre TextMate
  3. Suppression de mon projet dans FlexBuilder / Eclipse
  4. Vérification de mon projet sur SVN
  5. Copier le texte du fichier de problème à partir de la fenêtre TextMate
  6. Commettre les modifications.

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

Peut-être plus important – est-ce un symptôme d’un problème plus important?

Le fichier dans le répertoire .svn qui garde la trace de ce que vous avez extrait, à quel moment, à quelle révision et d’où, de quelque manière que ce soit, pour ce fichier particulier.

Ce n’est pas plus dangereux ou critique que le problème normal des fichiers impairs, et peut être dû à divers problèmes, comme un programme de subversion mourant à mi-parcours, une interruption de l’alimentation, etc.

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

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

Notez que cela peut causer des problèmes si vous avez un projet occupé où vous devriez normalement fusionner des modifications.

Par exemple, vous et un collègue extrayez 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 la même chose, vous obtenez le problème de sum de contrôle que vous avez. 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 ne rencontrez pas le problème dans ce cas, vous devez mettre à jour votre copie de travail et gérer un conflit avec votre fichier.

Cependant, si vous effectuez une nouvelle vérification, complétez avec vos changements de collègues, il semble maintenant que vous avez supprimé ses modifications et remplacé par les vôtres. Aucun conflit, et aucune indication de subversion que quelque chose ne va pas.

Il y a aussi une cause plus simple que les bogues, ou la corruption de disque, etc. Je pense que la cause la plus probable est que quelqu’un écrit un remplacement de texte récursif sur la copie de travail, sans exclure les fichiers .svn.
Cela signifie que les copies originales des fichiers (essentiellement la version BASE des fichiers, stockée dans la zone administrative .svn) sont modifiées et que la sum MD5 est invalidée.

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

SVN conserve des copies parfaites de tous les fichiers que vous récupérez dans les répertoires .svn. Ceci s’appelle la base de texte. Cela permet des diffs et des retours rapides. Au cours de diverses opérations, SVN effectuera des sums de contrôle sur ces fichiers de base de texte pour détecter les problèmes de corruption de fichiers.

En général, une non-concordance de sum 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 ça veut dire?

  1. Corruption de disque (mauvais disque dur ou câble IDE)
  2. Bad RAM
  3. Mauvais lien réseau
  4. Une sorte de processus d’arrière-plan a modifié un fichier derrière vous (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 à la place récupéré “null”. S’il s’agissait d’un problème de corruption de fichier simple, je m’attendrais à ce que vous disposiez de deux hachages MD5 différents pour le résultat attendu / obtenu. Le fait que vous ayez un “null” implique que quelque chose d’autre est faux.

J’ai deux théories:

  1. Bug dans SVN.
  2. Quelque chose avait un verrou exclusif sur le fichier, et le MD5 ne pouvait pas arriver.

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

Dans le cas de # 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 fichier texte-base , pas le fichier que vous essayez de valider.

Je reçois de temps en temps des choses similaires, généralement avec des fichiers que personne n’a eu 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 avec le problème et exécuter

 svn update 

pour le recréer.

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

En règle générale, je dirais que c’est une bonne idée de ne pas laisser les fichiers édités non validés et de garder la copie de travail en ordre. 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 monte, 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 sauvegarder.

Juste aujourd’hui, j’ai réussi à récupérer 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 venaient d’être copiés. J’ai écrit la procédure en détail ici sur mon blog . Je serais intéressé d’entendre des utilisateurs plus expérimentés de SVN quels sont les avantages et les inconvénients de chaque approche.

essayez: svn up –force file.c

Cela a fonctionné pour moi sans avoir à faire autre chose

J’ai observé beaucoup de solutions allant de la correction des fichiers .svn / ensortinges au nouveau checkout.

Cela peut être une nouvelle façon (grâce à 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 

Matt, il existe un moyen plus facile que vous avez décrit – en modifiant la sum de contrôle dans le fichier .svn / ensortinges. Voici une description complète: http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnensortinges-file/

Une autre solution, peut-être même plus effrayante, pour les conflits de sum de contrôle que j’ai trouvé est la suivante:

MISE EN GARDE: assurez-vous que votre copie locale est la version la mieux connue ET que toute personne de votre projet sait ce que vous faites! (au cas où ce 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

Ayant ce problème, nos VM de développement sont tous * nix nos stations de travail win32. certains imbéciles ont créé des fichiers du même nom (cas différents) sur la case * nix, tous les extractions soudaines sur Win32 explose … parce que win ne sait pas lequel des 2 fichiers du même nom à MD5 contre , les check-out sur * nix se passaient bien… nous laissant un peu la tête

J’ai été capable de mettre à jour le repository sur la boîte de gains en copiant les dossiers “.svn” à partir d’une boîte * nix avec une bonne copie de travail. avoir encore à voir si le repo peut être nettoyé au point où nous pouvons faire une vérification complète à nouveau

Un autre moyen facile ….

  1. Mettez à jour votre projet pour obtenir la dernière version
  2. vérifier 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)

Au lieu de vérifier une nouvelle copie (que j’avais également à faire après avoir essayé toutes les autres options) et de fusionner toutes vos modifications précédemment sauvegardées, l’approche suivante a fonctionné de la même manière, mais elle m’a permis d’économiser de temps, et peut-être quelques erreurs:

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

Bien sûr, vous devez sauvegarder votre copie de travail originale corrompue au cas où. Dans mon cas, j’étais libre de l’enlever après que j’aie fini, car tout s’est bien passé.

Cela se produit lorsque le dossier .svn est corrompu. Solution: Supprimez tout le dossier du fichier et récupérez le dossier à nouveau.

  1. N’extrayez que le dossier contenant le fichier problématique du référentiel vers un autre emplacement.
  2. Assurez-vous que .svn\text-base\.svn-base est identique à celui extrait.
  3. Assurez-vous que la section de fichier problématique (toutes les lignes de la section) dans les .svn\ensortinges est identique à celle extraite.

Vous ne le croirez pas, mais j’ai corrigé mon erreur en supprimant la position ... du fichier pom.xml incriminé que j’espérais archiver. Il contenait l’URL du repository de subversion. il est archivé (c’est ce à quoi sert le paramètre Maven!), mais il génère en quelque sorte une sum de contrôle erronée pour le fichier lors de l’archivage.

J’ai littéralement essayé toutes les méthodes susmentionnées pour résoudre ce problème, mais en vain. Ai-je rencontré une situation très rare où le générateur de sum de contrôle n’est pas assez robuste?

Je suis également tombé sur ce problème et essayais de chercher des solutions rapides, essayé une partie de la solution donnée dans ce fil. Voici comment j’ai résolu ce problème dans mon environnement de développement (pour moi, c’était un changement minimal):

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 up, maintenant Eclipse / TortoiseSVN a commencé à montrer des conflits dans ce répertoire

4- Conflit marqué tel que résolu

Cela a fonctionné, j’ai pu mettre à jour, commettre plus tôt web.xml corrompu

Dans mon cas, la sum était différente. Tout ce que j’ai fait était:

1) Effectuez une vérification pour séparer le dossier

2) Remplacez par fichier à partir de ce dossier dans le répertoire .svn avec mon fichier de problème de projet qui a été dit dans le message d’erreur svn-client

3) ..Profit!

Bien que ce soit un vieux problème, je pensais que je donnerais aussi mes 2 cents, car je me suis juste débattu avec le problème pendant plus d’une heure.

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

Ma solution était simplement de supprimer tous les dossiers svn du projet.

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

Après cela, j’ai refait une simple vérification du projet. Ainsi, en laissant tous mes fichiers non validés intacts, tout en conservant une reconstruction de tous les fichiers svn.

J’ai eu ce problème sur Ubuntu 14.04 et le résoudre en suivant les étapes:

  1. $ cd / var / www / myProject
  2. $ svn upgrade
  3. $ svn update

Après ces étapes, je pourrais commettre un fichier sans erreur.

  1. Aller dans le dossier à l’origine du problème
  2. Exécuter la commande svn update --set-depth empty
  3. Ce dossier videra et annulera le dossier vide
  4. Synchroniser avec le svn et mettre à jour.

Cela fonctionne pour moi.

Voici comment j’ai résolu le problème – v simple, mais selon jsh ci-dessus, vous devez vous assurer que votre copie est la meilleure.

simplement

  1. faire 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 aux noms de fichiers originaux.
  5. commettre à nouveau.

suspecte que cela tue probablement toutes sortes d’historique de révision sur ce fichier, donc c’est une façon assez moche de s’y prendre …