Reparatur-SVN Prüfsumme

Question

Ich bin mit subclipse in Flex Builder 3, und vor kurzem erhielt diese Fehler, wenn Sie versuchen zu Begehen:

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

Ich arbeitete um es durch:

1. Begehen alle anderen geänderten Dateien, dem auslassen der mühsam ein.
2. Das kopieren von Inhalten des trouble-Datei auf eine TextMate-Fenster
3. Löschen mein Projekt in FlexBuilder/Eclipse
4. Überprüfen mein Projekt aus frischen aus dem SVN
5. Kopieren Sie den text von the trouble Datei wieder aus dem Fenster TextMate
6. Begehen Sie die änderungen.

Es hat funktioniert, aber ich kann nicht helfen, aber denke es gibt einen besseren Weg.Was actaully geschieht, um die Ursache zu svn:Prüfsumme Fehler, und was ist der beste beheben.

Vielleicht noch wichtiger-ist dies ein symptom für ein größeres problem?

Answer 1

Die Datei, in der .svn-Verzeichnis, die Spur hält, was Sie haben ausgecheckt, wenn das, was der revision, und von wo, bekommen hat irgendwie beschädigt, für diese bestimmte Datei.

Dies ist nicht mehr gefährlich oder kritisch als das normale odd-Datei problem und können aufgrund verschiedener Probleme, wie ein subversion-Programm sterben Mitte ändern, power-Störungen, etc.

Es sei denn, es passiert noch mehr, ich würde nicht viel aus ihm heraus.

Es kann behoben werden, indem Sie tun, was Sie getan haben, erstellen Sie eine Kopie Ihrer Arbeit-Dateien, schauen Sie sich eine neue Kopie, und fügen Sie die geänderten Dateien wieder in.

Beachten Sie, dass dies Probleme verursachen könnte, wenn Sie einen anstrengenden Projekt, wo man normalerweise zum Zusammenführen von änderungen.

Für Beispiel, Sie und ein Kollege, beide schauen Sie sich eine neue Kopie, und anfangen zu arbeiten auf der gleichen Datei.Irgendwann, Ihr Kollege prüft in seinen Modifikationen.Wenn Sie versuchen, das gleiche zu tun, erhalten Sie die Prüfsumme problem, das Sie haben.Wenn Sie jetzt Kopien von Ihren Dateien geändert, eine neue Kasse, dann wird subversion den überblick verlieren, wie sich die änderungen zusammengeführt werden sollen zurück in.

Wenn Sie nicht bekommen, das problem ist in diesem Fall, wenn Sie rund um Check-in Ihren Modifikationen, würden Sie brauchen, um Ihre Arbeitskopie aktualisieren, erste, und möglicherweise auch mit dem Konflikt mit Ihrer Datei.

Allerdings, wenn Sie eine neue Kasse, komplett mit Ihren Kollegen wechselt, es sieht jetzt aus wie entfernt man seine änderungen und ersetzt mit Ihren eigenen.Keine Konflikte, keine Anzeichen von subversion, dass etwas nicht in Ordnung ist.

Answer 2

Es gibt auch eine einfachere Ursache für diese als nur bugs oder Beschädigung der Festplatte, etc.Ich denke, es ist die wahrscheinlichste Ursache für dieses geschehen ist, wenn jemand schreibt eine rekursive ersetzen von text auf der Arbeitskopie, ohne Ausnahme .svn-Dateien.
Dies bedeutet, dass die unberührte Kopien der Dateien, die im Grunde die BASIS-version der Dateien, die gespeichert ist im inneren des .svn-Verwaltungsbereich) modifiziert werden, und das wird, erlischt die MD5-Summe.

@Andrew Hedges:das erklärt auch, warum Ihre Lösung behebt das.

Answer 3

SVN hält unberührten Kopien aller Dateien, die Sie Kasse begraben .svn-Verzeichnisse.Dies nennt man die text-base.Dies ermöglicht eine schnelle diffs und konvertiert.Während der verschiedenen Operationen, SVN tun Prüfsummen auf diesen text-base Dateien zu fangen-Datei Korruption Fragen.

Im Allgemeinen, ein SVN-Prüfsumme überein, dass eine Datei, die sollte nicht verändert worden war irgendwie verändert.Was bedeutet das?

1. Eine Beschädigung der Festplatte (bad-Festplatte oder IDE-Kabel)
2. RAM
3. Schlechte Netzwerk-link
4. Irgendeine Art von hintergrund-Prozess verändert eine Datei hinter Ihrem Rücken (malware)

Alle diese schlecht sind.

JEDOCH, Ich denke, Ihr problem ist anders.Blick auf die Fehlermeldung.Beachten Sie, dass es erwartet, dass einige MD5-hashes, aber stattdessen bekam zurück 'null'.Wenn dies eine einfache Datei Korruption Problem, ich würde erwarten, dass Sie zwei verschiedene MD5-hashes für das rechnen/habe.Die Tatsache, dass Sie eine "null" bedeutet, dass etwas anderes falsch ist.

Ich habe zwei Theorien:

1. Fehler in SVN.
2. Etwas hatte einen exklusiven lock auf die Datei, und der MD5 nicht geschehen konnte.

Bei #1, die versuchen, ein Upgrade auf die neueste SVN-version.Vielleicht auch, diesem post svn-devel mailing list (http://svn.haxx.se), so können die Entwickler sehen es.

Im Fall von #2, überprüfen zu sehen wenn alles, was die Datei ist gesperrt.Sie können eine Kopie der Process Explorer, um zu überprüfen.Beachten Sie, dass Sie wahrscheinlich wollen, um zu sehen, wer hat eine Sperre auf der text-base Datei, nicht die eigentliche Datei, die Sie versucht haben zu verpflichten.

Answer 4

Ich bekomme gelegentlich ähnliche Dinge, die in der Regel mit Dateien, niemand war in der Nähe in Wochen.In der Regel, wenn Sie wissen, Sie haben nicht gearbeitet, in das Verzeichnis, in Frage, können Sie löschen Sie einfach das Verzeichnis mit dem problem, und führen Sie

svn update

neu zu erstellen.

Wenn Sie live-Veränderungen in dem Verzeichnis dann als lassevk und Sie selbst vorgeschlagen, ein vorsichtiger Ansatz erforderlich.

Generell würde ich sagen, es ist eine gute Idee, nicht zu verlassen bearbeitet Dateien, die kein commit ausgeführt wurde, und halten Sie die Arbeitskopie ordentlich - nicht noch eine ganze Reihe von zusätzlichen Dateien in der Arbeitskopie, die Sie nicht verwenden.Begehen regelmäßig, und dann, wenn die Arbeitskopie goes tits up, können Sie entfernen Sie einfach die ganze Sache und beginnen, ohne sich Gedanken über das, was Sie möglicherweise oder möglicherweise nicht werden, zu verlieren, und ohne Schmerzen, zu versuchen, um herauszufinden, welche Dateien zu speichern.

Answer 5

Gerade heute habe ich es geschafft, sich zu erholen von diesen Fehler, indem Sie eine Kopie der beschädigten Verzeichnis /tmp und ersetzen Sie die Dateien in .svn/text-base mit nur co-ed ones.Ich schrieb die Verfahren im detail hier auf meinem blog. Ich wäre daran interessiert zu hören, mehr erfahren SVN-Nutzer was sind die vor-und Nachteile jedes Ansatzes.

Answer 6

versuchen:svn up --Datei erzwingen.c

Dies funktionierte für mich, ohne nichts zu tun extra

Answer 7

Ich habe beobachtet, eine Menge von Lösungen, die von patchen .svn/entries-Datei an die frische checkout.

Es kann eine neue Möglichkeit (vielen Dank an meine Kollegin):

- 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, es ist einfacher, Weg, als Sie beschrieben - ändern der Prüfsumme in .svn/entries-Datei.Hier ist die vollständige Beschreibung:http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/

Answer 9

Ein weiterer, möglicherweise noch erschreckender, Abhilfe für die Prüfsumme Konflikte fand ich wie folgt:

VORBEHALT: Stellen Sie sicher, dass Ihre lokale Kopie ist die bekannteste version ist, UND dass jemand anderes auf Ihr Projekt weiß, was du tust!(falls dies nicht offensichtlich schon).

wenn Sie wissen, dass Ihre lokale Kopie der Datei ist "die guten" können Sie direkt löschen der Datei aus dem SVN-server, und erzwingen Sie dann Begehen, Ihre lokale Kopie.

syntax für die direkte Löschung:

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

viel Glück!

J

Answer 10

Als alternative zum Auschecken einer neuen Kopie (was ich auch tun musste, um nach dem Versuch, alle anderen Optionen) und als Zusammenführung aller änderungen, die Sie zuvor gespeichert haben, gesichert in den folgenden Ansatz gearbeitet, der gleichen Weise, aber mich gerettet, eine beträchtliche Menge an Zeit und eventuell einige Fehler:

1. Schauen Sie sich eine frische Arbeitskopie
2. Kopieren .svn-Ordner aus, die Sie frisches Exemplar in Ihre korrupten kopieren
3. Voila

Natürlich sollten Sie ein backup Ihrer original beschädigt Arbeitskopie nur für den Fall.In meinem Fall, ich war frei, um es zu entfernen, nachdem ich fertig war, da ging alles gut.

Answer 11

Dies passiert, wenn der .svn-Ordner beschädigt.Lösung:Entfernen Sie den gesamten Ordner, der die Datei enthält, und bezahlen Sie den Ordner wieder ein.

Answer 12

Hatte dieses Problem, unsere dev-VM ' s sind alle *nix-unsere workstations win32.einige Narren(s) erstellt Dateien mit dem gleichen Namen (anderer Fall) auf die *nix-box plötzlich Kassen auf Win32 weht...da gewinnen Sie nicht wissen, welche der 2 Dateien mit dem gleichen Namen auf MD5 vor, Check-out auf *nix waren in Ordnung...verlassen uns zu kratzen unsere Köpfe für ein bisschen

Ich war in der Lage zu aktualisieren die repo-auf der win-box-durch kopieren der ".svn" - Ordner von einer *nix-box mit einer guten Arbeitskopie.haben noch zu sehen, wenn die repo-können gereinigt werden, zu dem Punkt, wo wir können, führen Sie eine vollständige Kaufabwicklung erneut

Answer 13

Eine andere einfache Weise....

1. Aktualisieren Sie Ihr Projekt, um neueste version
2. Kasse die gleiche version in einem anderen Ordner
3. ersetzen .svn-Ordner aus der neuen Kasse, um die Arbeit zu kopieren ( habe ich ersetzt .svn-base-Dateien )

Answer 14

1. Check-out nur Ordner mit problematischen Datei aus dem repository zu einem anderen Speicherort.
2. Stellen Sie sicher, .svn\text-base\<problematic file>.svn-base ist identisch zu einem der ausgecheckt.
3. Stellen Sie sicher, dass problematische Datei Abschnitt (alle Zeilen des Abschnitts) in .svn\entries ist identisch zu einem der ausgecheckt.

Answer 15

Du wirst es nicht glauben, aber ich habe tatsächlich meinen Fehler behoben, durch entfernen der <scm>...</scm> Haltung von beleidigen pom.xml Datei hoffte ich, check-in.Es enthielt die URL des subversion-Projektarchivs, die es aktiviert ist (dies ist, was die Maven-Einstellung!), aber irgendwie ist es erzeugt eine fehlerhafte Prüfsumme für die Datei beim Check in.

Ich habe buchstäblich versucht, alle oben genannten Methoden dies zu beheben, aber ohne Erfolg.Habe ich auch eine sehr seltene situation, in der die Prüfsummen-generator ist nicht robust genug?

Answer 16

Auch ich stolperte über dieses Problem und war auf der Suche nach schnellen Lösungen, versuchte, etwas von der Lösung in diesem thread.Dies ist, wie ich dieses Problem behoben in meiner Entwicklungsumgebung (mir wurde es nur minimal geändert):

1 - Lokal gelöschte Verzeichnis, in dem die Datei wurde beschädigt (WEB-INF):

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

2 - Kopiert und eingefügt (Verzeichnis WEB-INF) aus einem frischen checkout

3 - Hast svn up, jetzt Eclipse/TortoiseSVN gestartet mit Konflikten in diesem Verzeichnis

4 - Markiert den Konflikt als Gelöst

Dies funktionierte, war ich in der Lage, update, commit früheren beschädigt web.xml

Answer 17

In meinem Fall die Summe war anders.Alles was ich gemacht habe war:

1) Make Check Out to separate Ordner

2) Ersetzen durch-Datei aus diesem Ordner in .svn-Verzeichnis mit meinem Projekt problem-Datei, die gesagt wurde in der svn-client-Fehlermeldung

3) ..Gewinn!

Answer 18

Dies ist zwar ein altes Thema, ich dachte, ich würde meine 2 Cent, da Ich nur haderte mit dem problem, für mehr als eine Stunde.

Die oben genannten Lösungen entweder gar keine Arbeit für mich, oder schien kompliziert.

Meine Lösung war, einfach zu entfernen Sie alle svn-Ordner aus dem Projekt.

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

Danach habe ich einfach das Auschecken des Projekts wieder.So verlassen alle meine un-committed-Dateien intakt, aber immer noch eine Neuerstellung alle svn-Dateien.

Answer 19

Ich hatte dieses problem auf ubuntu 14.04 und es lösen, indem Sie die Schritte befolgen:

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

nach diesen Schritten, die ich Begehen konnte die Datei ohne Fehler.

Answer 20

1. Gehen Sie zu dem Ordner verursacht problem
2. Befehl ausführen svn update --set-depth empty
3. Dieser Ordner leer ist und wieder die leeren Ordner
4. Die Synchronisierung mit dem svn und zu aktualisieren.

Diese Arbeit für mich.

Answer 21

hier ist, wie ich das Problem beseitigt - v einfache, aber pro jsh oben, müssen sicher sein, Ihre Kopie ist die beste.

einfach

1. machen Sie eine Kopie aller problematischen Dateien im selben Ordner.
2. löschen Sie den alten mit svn rm
3. Begehen.
4. dann benennen Sie die Kopien wieder dem ursprünglichen Dateinamen.
5. commit wieder.

vermute, dass dies wahrscheinlich tötet alle Arten von revisionsverlauf für die Datei, es ist also eine ziemlich hässliche Art und Weise, darüber zu gehen...