Réparer le code SVN <checksum>.

Question

Je suis en train d'utiliser subclipse dans Flex Builder 3, et j'ai récemment reçu cette erreur en essayant de commettre :

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

J'ai contourné le problème en :

1. Committant tous les autres fichiers modifiés, en omettant celui posant problème.
2. Copiant le contenu du fichier problématique dans une fenêtre TextMate
3. Supprimant mon projet dans FlexBuilder/Eclipse
4. Vérifiant mon projet frais depuis SVN
5. Collant le texte du fichier problématique depuis la fenêtre TextMate
6. Committant les modifications.

Cela a fonctionné, mais je ne peux m'empêcher de penser qu'il y a une meilleure solution. Que se passe-t-il réellement pour causer l'erreur de checksum svn et quelle est la meilleure solution.

Peut-être plus important - est-ce un 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 vérifié, quand, quelle révision, et d'où, a été corrompu d'une manière ou d'une autre, pour ce fichier en particulier.

Ce n'est pas plus dangereux ou critique que le problème habituel de fichier étrange, et cela peut être dû à divers problèmes, comme un programme de subversion qui plante en plein milieu d'un changement, une coupure de courant, etc.

Sauf s'il se produit à nouveau, je ne m'en ferais pas trop.

Cela peut être résolu en faisant ce que vous avez fait, c'est-à-dire faire une copie de vos fichiers de travail, vérifier une nouvelle copie, et ajouter à nouveau les fichiers modifiés.

Notez que cela peut causer des problèmes si vous avez un projet chargé où vous auriez normalement à fusionner des changements.

Par exemple, vous et un collègue vérifiez tous les deux une nouvelle copie, et commencez à travailler sur le même fichier. À un moment donné, votre collègue enregistre ses modifications. Lorsque vous essayez de faire la même chose, vous obtenez le problème de checksum que vous avez. Si vous faites maintenant des copies de vos fichiers modifiés, faites une nouvelle vérification, alors Subversion perdra la trace de la manière dont vos modifications doivent être fusionnées à nouveau.

Si vous n'avez pas eu le problème dans ce cas, lorsque vous avez finalement enregistré vos modifications, vous auriez besoin de mettre à jour votre copie de travail d'abord, et éventuellement traiter un conflit avec votre fichier.

Cependant, si vous faites une vérification complète, avec les modifications de votre collègue, il semble maintenant que vous avez supprimé ses changements et les avez remplacés par les vôtres. Pas de conflits, et pas d'indications de Subversion qu'il y a un problème.

Answer 2

Il y a aussi une cause plus simple à cela que simplement des bugs, une corruption de disque, etc. Je pense que la cause la plus probable de ce problème 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 non modifiées des fichiers (essentiellement la version DE BASE des fichiers, stockée à l'intérieur de 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 intactes de tous les fichiers que vous récupérez, enfouies dans les répertoires .svn. Cela s'appelle la base de texte. Cela permet des différences et des réversions rapides. Lors de diverses opérations, SVN fera des sommes de contrôle sur ces fichiers de base de texte pour attraper les problèmes de corruption de fichiers.

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

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

Tous ces cas sont mauvais.

CEPENDANT, je pense que votre problème est différent. Regardez le message d'erreur. Notez qu'il attendait certaines sommes de contrôle MD5, mais a obtenu 'null' à la place. S'il s'agissait d'un simple problème de corruption de fichier, je m'attendrais à ce que vous ayez deux sommes de contrôle MD5 différentes pour les attendues/obtenues. Le fait que vous ayez 'null' 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 #1, essayez de mettre à jour vers la dernière version de SVN. Essayez peut-être aussi de poster ceci sur la liste de diffusion svn-devel (http://svn.haxx.se), afin que les développeurs puissent le voir.

Dans le cas du #2, vérifiez si quelque chose a le fichier 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 de base de texte, pas le fichier réel que vous essayiez de commettre.

Answer 4

De temps en temps, j'obtiens des choses similaires, généralement avec des fichiers sur lesquels personne n'a touché depuis des semaines. En général, 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 modifications en direct dans le répertoire, alors comme l'a suggéré lassevk et vous-même, une approche plus prudente est nécessaire.

En règle générale, je dirais qu'il est bon de ne pas laisser des fichiers édités non validés, et de garder la copie de travail propre - ne pas ajouter une tonne de fichiers supplémentaires dans la copie de travail que vous n'allez pas utiliser. Validez régulièrement, et ensuite si la copie de travail a des problèmes, vous pouvez simplement la supprimer entièrement et recommencer sans vous soucier de ce que vous pourriez perdre, et sans la douleur d'essayer de savoir quels fichiers sauvegarder.

Answer 5

Juste aujourd'hui, j'ai réussi à récupérer cette erreur en vérifiant une copie du répertoire corrompu vers /tmp et en remplaçant les fichiers dans .svn/text-base par ceux qui viennent d'être copiés. J'ai rédigé la procédure en détail ici sur mon blog. Je serais intéressé d'entendre les avantages et les inconvénients de chaque approche de la part d'utilisateurs SVN plus expérimentés.