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.

Ceci n'est pas plus dangereux ou critique qu'un problème normal de fichiers impairs, et peut être dû à divers problèmes, comme un programme de subversion mourant en cours de modification, une coupure de courant, etc.

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

Cela 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 ajoutant les fichiers modifiés.

Notez que cela peut poser des problèmes si vous avez un projet chargé où vous devriez normalement fusionner les 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 somme de contrôle que vous avez. Si vous faites maintenant des copies de vos fichiers modifiés, effectuez une nouvelle extraction, puis subversion perdra la trace de la façon dont vos modifications doivent être fusionnées.

Si vous n'avez pas eu le problème dans ce cas, lorsque vous avez pris le temps d'enregistrer vos modifications, vous devez d'abord mettre à jour votre copie de travail et éventuellement gérer un conflit avec votre fichier.

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

Je reçois parfois des choses similaires, généralement avec des fichiers dont personne n'a été à proximité 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, comme lassevk et vous-même l'avez suggéré, une approche plus prudente est nécessaire.

D'une 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. Validez régulièrement, puis si la copie de travail explose, 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.< /p>

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

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

essayez : svn up --force fichier.c

Cela a fonctionné pour moi sans avoir à faire quoi que ce soit de plus

voici comment j'ai résolu le problème - c'est 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. s'engager.
4. renommez ensuite les copies avec les noms de fichiers d'origine.
5. s'engager à nouveau.

Je suppose que cela tue probablement toutes sortes d'historiques de révision sur ce fichier, donc c'est une façon assez laide de s'y prendre...