SVN - Non-concordance de la somme de contrôle lors de la mise à jour


122

Lorsque j'essaye de mettre à jour certains fichiers depuis Subversion, j'obtiens l'erreur:

org.tigris.subversion.javahl.ClientException: 
Checksum mismatch while updating 'D:\WWW\Project\\.svn\text-base\import.php.svn-base'; expected: '3f9fd4dd7d1a0304d8020f73300a3e07', actual: 'cd669dce5300d7035eccb543461a961e'

Pourquoi ai-je ça? Comment puis-je y remédier?

Réponses:


70

Le moyen le plus simple de résoudre ce problème (si vous n'avez pas beaucoup de modifications) consiste à copier vos modifications dans un autre répertoire, à supprimer le répertoire dans lequel votre projet est extrait et à extraire à nouveau le projet.

Copiez ensuite vos modifications dans (ne copiez aucun dossier .svn), validez et continuez.


9
Je viens de supprimer le dossier où se trouvait un fichier problématique et j'ai mis à jour l'ensemble du projet. Maintenant, ça semble aller.
Koralek M.

+1 L'autre alternative que j'ai trouvée m'a laissé pirater la base de données svn, beaucoup plus facile
SeanDowney

@SeanDowney comment faire ça?
arvindwill

@arvindwill Désolé, je n'ai pas été très clair dans mon commentaire, cette méthode est beaucoup plus simple. Voici l'alternative effrayante: maymay.net/blog/2008/06/17/…
SeanDowney

2
Ce n'est pas du tout une solution spécifique. Vous pouvez toujours supprimer toutes vos données locales et commencer avec une nouvelle copie du dépôt.
tim

197

Si vous utilisez SVN 1.7+, une solution de contournement est décrite ici .

Juste pour récapituler:

  1. Accédez au dossier contenant le fichier posant problème
  2. Exécuter la commande svn update --set-depth empty(note: cela supprimera vos fichiers, alors faites d'abord une copie!)
  3. Exécuter la commande svn update --set-depth infinity

17
Bien que cela ait fonctionné pour moi, notez que "svn update --set-depth empty" supprimera tout de ce chemin, alors faites d'abord une copie
tristanbailey

3
Cela a très bien fonctionné pour réparer un référentiel géant à un emplacement distant. Tout en faisant une nouvelle caisse aurait fonctionné, cela aurait pris plus d'une heure; cela a pris quelques minutes.
Brian Gillespie

salut j'ai en utilisant window et tortoisesvn comme client svn .. J'étais en train d'essayer votre solution. mais il montre toujours l'isse
Amit Bera

Je viens de remplacer le répertoire .svn du nouveau référentiel par l'ancien, cela a fonctionné :)
harishkumar329

Cela a très bien fonctionné pour moi, merci! Il convient de noter que le point n ° 1 consiste à explorer le dossier (ou fichier) réel à l'origine du problème. Ensuite, vous n'avez pas besoin de beaucoup mettre à jour. J'avais un dossier avec quelques dizaines de fichiers dans lequel j'ai utilisé Tortoise "Update To-> only this item" sur le dossier, puis "Update To-> entièrement récursif" pour tout récupérer. Cependant, tout le monde prend garde que cela supprime les fichiers de ce dossier! Sur une liaison VPN lente avec un dépôt de plusieurs gigaoctets et des profondeurs réglées finement, la solution «standard» était tout simplement inutile.
dash-tom-bang

6

J'ai eu un problème similaire. Le fournisseur principal était l'antivirus "FortiClient" (antivirus + VPN CLient). Lorsque je l'ai désactivé - toutes les mises à jour / vérifications ont été effectuées correctement


1
C'est la seule réponse qui a résolu mon problème. Je ne pourrais jamais penser à ça. Merci!
heure du

5

J'ai trouvé un moyen plus simple de résoudre ce problème. Vous ne pouvez pas faire cela directement depuis Eclipse. Pas:

  1. Accédez à la structure des dossiers de l'espace de travail dans Windows
  2. renommer le dossier
  3. rafraîchir dans l'éclipse
  4. Maintenant, le dossier et les fichiers seront supprimés du projet dans eclipse et apparaîtront sous un nouveau dossier renommé
  5. Maintenant, essayez l'option "Synchroniser avec le référentiel".

Cela restaurera le dossier de base du texte dans .svnfolder. L'erreur de correspondance de la somme de contrôle lors de la mise à jour n'apparaîtra plus.


1

Cela m'est arrivé en utilisant le plug-in Eclipse et en synchronisant. Le fichier à l'origine du problème n'avait pas de modifications locales (et en fait aucune modification à distance depuis ma dernière mise à jour). J'ai choisi «revenir» pour le fichier, sans aucune autre modification des fichiers, et les choses sont revenues à la normale.


1

J'ai eu la même erreur mais pour un fichier. Dans IntelliJ IDEA, j'ai pu faire une copie du fichier, puis aller dans le projet et supprimer le fichier en question, puis valider avec succès. Ensuite, j'ai créé un nouveau fichier avec le même nom et j'y ai recopié le contenu. Je suppose que vous perdriez l'historique des révisions, mais cela fonctionne.


1

Si vous avez un collègue qui travaille avec vous:

1) lui demander de renommer le fichier causant des problèmes et commit

2) vous update(maintenant vous voyez le fichier avec une somme de contrôle invalide avec un nom différent)

3) Renommez-le à son nom d'origine

4) commit(et demandez à votre collègue de updaterécupérer le nom du fichier dans son état initial)

Cela a résolu le problème pour moi.



1

J'utilise Tortoise SVN, après avoir essayé toutes les solutions de cette page et ne fonctionne pas,

Je sauvegarde enfin le fichier problématique. et utilisez Repo Browsersupprimer le fichier problématique, puis mettez à jour le dossier local afin que le fichier du dossier local soit supprimé. Ensuite, recopiez le fichier de sauvegarde et Add > Commitpuis je peux mettre à jour avec succès.

Le seul inconvénient de cette méthode est que l'historique de ce fichier sera supprimé.


0

Pour résoudre ce problème, procédez comme suit:

  1. Ouvrez le fichier d'entrées situé dans le répertoire .svn où vous obtenez l'erreur.
  2. Recherchez l'entrée du fichier donnant une erreur et remplacez la valeur attendue par la valeur réelle en erreur.
  3. Maintenant, synchronisez et essayez de mettre à jour.

Si cela ne fonctionne toujours pas. Essayez-les. C'est juste une solution de contournement:

  1. Supprimez le fichier de votre système.
  2. Supprimez l'entrée du fichier du fichier d'entrées. (À partir du nom du fichier jusqu'aux caractères spéciaux).
  3. Maintenant, synchronisez et mettez à jour le fichier.

Cela obtiendra la dernière version du fichier du référentiel et tous les conflits seront résolus.


0

avait un problème similaire sur un serveur mais le répertoire SVN était très volumineux, je ne voulais pas supprimer et resynchroniser donc j'ai juste fait une copie des fichiers localement, puis je les ai supprimés. Lorsque la mise à jour a réussi et que les fichiers sont à nouveau ajoutés.


0

essayez de supprimer le fichier et supprimez la référence de fichier des entrées de fichier sous le répertoire .svn


0

J'ai eu une erreur similaire et j'ai corrigé comme suit:

(Ma `` solution '' est basée sur une hypothèse qui peut être correcte ou non car je ne sais pas grand-chose sur le fonctionnement de la subversion en interne, mais cela a définitivement fonctionné pour moi)

Je suppose que .svn \ text-base \ import.php.svn-base devrait correspondre au dernier commit.

Lorsque j'ai vérifié le fichier sur lequel j'avais l'erreur, le fichier de base ne correspondait PAS à la dernière validation dans le référentiel.

J'ai copié le texte du dernier commit et l'ai enregistré dans le dossier .svn, en remplaçant le fichier incorrect (j'ai fait une copie de sauvegarde au cas où mes hypothèses seraient fausses). (le fichier a été marqué en lecture seule, j'ai effacé cet indicateur, écrasé et remis en lecture seule)

J'ai alors pu m'engager avec succès.


0

Ma solution était:

  1. Exécuter le nettoyage svn à partir du système de fichiers
  2. Passer à une autre branche
  3. Résoudre les conflits
  4. Passer à la branche "problématique"
  5. Exécuter le nettoyage à partir de Spring Tool Suite
  6. Exécuter la mise à jour du projet

0

1.'update to reversion 'check' seulement cet élément 'sous le répertoire 2.update again check' Fully recursive '

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.