SVN-Prüfsumme reparieren

  • Ich verwende Subclipse in Flex Builder 3 und habe kürzlich beim Versuch, einen Commit auszuführen, diesen Fehler erhalten:

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

    Ich habe das Problem behoben:

    1. Alle anderen geänderten Dateien werden übernommen, wobei die lästigen Dateien weggelassen werden.
    2. Kopieren des Inhalts der Trouble-Datei in ein TextMate-Fenster
    3. Löschen eines Projekts in FlexBuilder / Eclipse
    4. Überprüfung meines Projekts aus dem SVN
    5. Kopieren des Textes der Fehlerdatei aus dem TextMate-Fenster
    6. Übernehmen der Änderungen.

    Es hat funktioniert, aber ich kann mir nicht helfen, es gibt einen besseren Weg. Was passiert eigentlich, um den svn: checksum-Fehler zu verursachen, und was ist die beste Lösung?

    Vielleicht wichtiger - ist dies ein Symptom für ein größeres Problem?

    18 August 2008
    DevelopingChris
21 answer
  • Die Datei im .svn-Verzeichnis, in der nachverfolgt wird, was Sie überprüft haben, wann, welche Revision und von wo aus sie irgendwie beschädigt wurde.

    Dies ist nicht gefährlicher oder kritischer als das normale Problem mit ungeraden Dateien und kann auf verschiedene Probleme zurückzuführen sein, z |>

    Wenn nicht mehr passiert, würde ich nicht viel daraus machen.

    Es kann behoben werden, indem Sie das tun, was Sie getan haben, indem Sie eine Kopie Ihrer Arbeitsdateien erstellen , checken Sie eine neue Kopie aus und fügen Sie die geänderten Dateien wieder hinzu.

    Beachten Sie, dass dies Probleme verursachen kann, wenn Sie ein vielbeschäftigtes Projekt haben, bei dem Sie normalerweise Änderungen vornehmen müssen.

    Zum Beispiel checken Sie und ein Kollege eine neue Kopie aus und beginnen, an derselben Datei zu arbeiten. Irgendwann prüft Ihr Kollege seine Modifikationen. Wenn Sie versuchen, dasselbe zu tun, wird das Prüfsummenproblem angezeigt. Wenn Sie jetzt Kopien Ihrer geänderten Dateien anfertigen, überprüfen Sie erneut, ob die Änderungen rückgängig gemacht werden sollen.

    Wenn Sie das nicht gefunden haben Problem In diesem Fall müssen Sie, wenn Sie die Änderungen eingecheckt haben, zuerst Ihre Arbeitskopie aktualisieren und möglicherweise einen Konflikt mit Ihrer Datei lösen.

    Wenn jedoch Wenn Sie einen neuen Checkout mit den Änderungen Ihrer Kollegen durchführen, sieht es jetzt so aus, als hätten Sie seine Änderungen entfernt und durch Ihre eigenen ersetzt. Keine Konflikte und keine Hinweise von Subversion, dass etwas nicht stimmt.

    08 August 2008
    Lasse Vågsæther Karlsen
  • Es gibt auch eine einfachere Ursache als nur Fehler, Festplattenbeschädigung usw. Ich denke, der wahrscheinlichste Grund dafür ist, dass jemand eine rekursive Textersetzung in die Arbeitskopie schreibt, ohne .svn auszuschließen Dateien.
    Dies bedeutet, dass die ursprünglichen Kopien der Dateien (im Wesentlichen die BASE-Version der Dateien, die im Verwaltungsbereich von .svn gespeichert sind) geändert werden und die MD5-Summe ungültig wird.

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

    24 February 2009
    Sander RijkenThousand
  • SVN speichert makellose Kopien aller Dateien, die Sie ausgecheckt haben, in den .svn-Verzeichnissen. Dies wird als Textbasis bezeichnet. Dies ermöglicht schnelle Abweichungen und Wiederherstellungen. Während verschiedener Vorgänge führt SVN Prüfsummen für diese Textbasisdateien durch, um Probleme mit der Dateibeschädigung zu erkennen.

    Im Allgemeinen bedeutet ein Unterschied zwischen SVN-Prüfsummen, dass eine Datei nicht geändert wurde wurde irgendwie verändert. Was bedeutet das?

    1. Festplattenbeschädigung (defektes HDD- oder IDE-Kabel)
    2. Bad RAM
    3. Fehlerhafte Netzwerkverbindung
    4. Einige Hintergrundprozesse haben eine Datei hinter Ihrem Rücken verändert (Malware)

    All dies ist schlecht.

    JEDOCH , ich denke, Ihr Problem ist anders. Sehen Sie sich die Fehlermeldung an. Beachten Sie, dass einige MD5-Hashes erwartet wurden, stattdessen 'null' zurückgegeben wurde. Wenn dies ein Problem mit der einfachen Dateibeschädigung wäre, würde ich erwarten, dass Sie zwei unterschiedliche MD5-Hashwerte für das erwartete / erhalten hätten. Die Tatsache, dass Sie eine 'Null' haben, impliziert, dass etwas anderes falsch ist.

    Ich habe zwei Theorien:

    1. Fehler in SVN.
    2. Die Datei wurde exklusiv gesperrt, und der MD5 konnte nicht ausgeführt werden.

    Versuchen Sie im Falle von # 1, ein Upgrade auf die neueste SVN-Version durchzuführen. Vielleicht poste dies auch auf der svn-devel-Mailingliste ( http://svn.haxx.se ), so dass Entwickler können es sehen.

    Überprüfen Sie im Fall von # 2, ob die Datei gesperrt ist. Sie können eine Kopie von Process Explorer zur Überprüfung herunterladen. Beachten Sie, dass Sie wahrscheinlich sehen möchten, wer die Textbasis -Datei gesperrt hat, nicht die tatsächliche Datei, die Sie festgeschrieben haben.

    25 January 2009
    myron-semack
  • Ich bekomme gelegentlich ähnliche Dinge, normalerweise mit Dateien, die seit Wochen niemandem nahe ist. Wenn Sie wissen, dass Sie in dem betreffenden Verzeichnis nicht gearbeitet haben, können Sie im Allgemeinen das Verzeichnis mit dem Problem löschen und

     svn update
     
    <| ausführen >

    , um es neu zu erstellen.

    Wenn Sie Live-Änderungen im Verzeichnis haben und dann, wie von lassevk vorgeschlagen und Sie selbst vorgeschlagen haben, ist ein sorgfältigerer Ansatz erforderlich.

    Im Allgemeinen würde ich sagen, dass es eine gute Idee ist, bearbeitete Dateien nicht unverbindlich zu lassen und die Arbeitskopie aufgeräumt zu halten. Fügen Sie der Arbeitskopie, die Sie nicht verwenden, keine zusätzlichen Dateien hinzu nicht verwenden. Übernehmen Sie regelmäßig, und wenn die Arbeitskopie auf Hochtouren geht, können Sie einfach das Ganze löschen und neu beginnen, ohne sich Gedanken darüber zu machen, was Sie möglicherweise verlieren oder nicht, und ohne die Mühe zu bekommen, herauszufinden, welche Dateien gespeichert werden sollen.

    09 August 2008
    Polsonby
  • Erst heute konnte ich diesen Fehler beheben, indem ich eine Kopie des beschädigten Verzeichnisses nach / tmp auscheckte und die Dateien in .svn / text-base durch die gerade gemeinsam verwendeten ersetzt. Ich habe das Verfahren ausführlich aufgeschrieben. hier in meinem Blog . Ich würde gerne erfahrenere SVN-Benutzer erfahren, welche Vor- und Nachteile die einzelnen Ansätze haben.

    25 January 2009
    Andrew Hedges
  • Ich habe eine Reihe von Lösungen beobachtet, vom Patchen der .svn / entries-Datei bis zur neuen Kasse.

    :

     - 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
     
    06 May 2011
    Denis Barmenkov
  • try: svn up --force file.c

    Dies funktionierte für mich, ohne dass ich etwas extra tun musste

    06 March 2009
    aaron
  • Eine andere, möglicherweise noch erschreckendere Problemumgehung für Checksummenkonflikte, die ich gefunden habe, lautet wie folgt:

    CAVEAT: Stellen Sie sicher, dass Ihre lokale Kopie vorhanden ist die bekannteste Version UND dass jeder andere in Ihrem Projekt weiß, was Sie tun! (falls dies nicht bereits offensichtlich war).

    Wenn Sie wissen, dass Ihre lokale Kopie der Datei "die gute" ist, können Sie die Datei direkt vom SVN-Server löschen und erzwingen Sie anschließend die Übernahme Ihrer lokalen Kopie.

    Syntax zum direkten Löschen:

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

    viel Glück!

    J

    24 February 2018
    Eray BalkanliAnil
  • Es gibt einen einfacheren Weg als Sie beschrieben haben - das Ändern der Prüfsumme in der Datei .svn / entries. Hier ist vollständige Beschreibung: http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/

    30 June 2011
    Arturas Smorgun
  • Als Alternative zum Auschecken einer neuen Kopie (was ich auch tun musste, nachdem ich alle anderen Optionen ausprobiert hatte) und um alle Ihre Änderungen, die Sie zuvor gesichert hatten, zusammenzuführen, funktionierte der folgende Ansatz auf dieselbe Weise hat mir aber eine Menge Zeit und möglicherweise einige Fehler gespart:

    1. Schauen Sie sich eine neue Arbeitskopie an
    2. Kopie .svn-Ordner aus Ihrer neuen Kopie in Ihre beschädigte Kopie
    3. Voila

    Natürlich sollten Sie ein Backup Ihres Originals erstellen korrupte Arbeitskopie nur für den Fall. In meinem Fall konnte ich es nach Beendigung meiner Arbeit entfernen, da alles gut lief.

    08 July 2013
    Matija Han