•  08-06-2019
  •  | 
  •  

Domanda

Sto utilizzando subclipse in Flex Builder 3 e recentemente ho ricevuto questo errore durante il tentativo di eseguire il commit:

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

Ho risolto il problema:

  1. Salvando tutti gli altri file modificati, omettendo quello problematico.
  2. Copia del contenuto del file dei problemi in una finestra di TextMate
  3. Eliminazione del mio progetto in FlexBuilder/Eclipse
  4. Controllo il mio progetto fresco da SVN
  5. Copia del testo del file dei problemi dalla finestra TextMate
  6. Effettuare le modifiche.

Ha funzionato, ma non posso fare a meno di pensare che ci sia un modo migliore.Cosa sta realmente accadendo per causare l'errore svn:checksum e qual è la soluzione migliore.

Forse ancora più importante: è questo il sintomo di un problema più grande?

È stato utile?

Soluzione

Il file nella directory .svn che tiene traccia di ciò che hai estratto, quando, quale revisione e da dove è stato danneggiato in qualche modo, per quel particolare file.

Questo non è più pericoloso o critico del normale problema di file strani e può essere dovuto a vari problemi, come un programma di sovversione che muore durante la modifica, un'interruzione dell'alimentazione, ecc.

A meno che non accada di più, non ne ricaverei molto.

Il problema può essere risolto facendo quello che hai fatto, creando una copia dei tuoi file di lavoro, estraendo una nuova copia e aggiungendo nuovamente i file modificati.

Tieni presente che ciò potrebbe causare problemi se hai un progetto impegnativo in cui normalmente dovresti unire le modifiche.

Ad esempio, tu e un collega prelevate una nuova copia e iniziate a lavorare sullo stesso file.Ad un certo punto, il tuo collega controlla le sue modifiche.Quando provi a fare lo stesso, ottieni il problema del checksum che hai.Se ora esegui copie dei file modificati, esegui un nuovo checkout, quindi subversion perderà traccia di come le modifiche dovrebbero essere reintegrate.

Se non hai riscontrato il problema in questo caso, quando sei riuscito a depositare le modifiche, dovresti prima aggiornare la tua copia di lavoro ed eventualmente gestire un conflitto con il tuo file.

Tuttavia, se esegui un nuovo checkout, completo delle modifiche dei tuoi colleghi, ora sembra che tu abbia rimosso le sue modifiche e le abbia sostituite con le tue.Nessun conflitto e nessuna indicazione da parte della sovversione che qualcosa non va.

Altri suggerimenti

C'è anche una causa più semplice per questo oltre ai semplici bug, alla corruzione del disco, ecc.Penso che la causa più probabile che ciò accada sia quando qualcuno scrive una sostituzione ricorsiva del testo sulla copia di lavoro, senza escludere i file .svn.
Ciò significa che le copie originali dei file (sostanzialmente la versione BASE dei file, archiviata nell'area amministrativa .svn) vengono modificate e ciò invalida la somma MD5.

@Andrew Hedges:questo spiega anche perché la tua soluzione risolve questo problema.

SVN conserva copie intatte di tutti i file che estrai sepolti nelle directory .svn.Questa è chiamata base testuale.Ciò consente differenze e ripristini rapidi.Durante le varie operazioni, SVN eseguirà dei checksum su questi file di testo per individuare eventuali problemi di danneggiamento dei file.

In generale, una mancata corrispondenza del checksum SVN significa che un file che non avrebbe dovuto essere modificato è stato modificato in qualche modo.Che cosa significa?

  1. Danneggiamento del disco (HDD difettoso o cavo IDE)
  2. RAM difettosa
  3. Collegamento di rete errato
  4. Una sorta di processo in background ha alterato un file alle tue spalle (malware)

Tutto questo è negativo.

TUTTAVIA, penso che il tuo problema sia diverso.Guarda il messaggio di errore.Tieni presente che si aspettava alcuni hash MD5, ma invece ha ottenuto "null".Se si trattasse di un semplice problema di corruzione dei file, mi aspetterei che avresti due hash MD5 diversi per quello previsto/ottenuto.Il fatto che tu abbia un "null" implica che qualcos'altro è sbagliato.

Ho due teorie:

  1. Bug nell'SVN.
  2. Qualcosa aveva un blocco esclusivo sul file e l'MD5 non poteva verificarsi.

Nel caso n. 1, prova ad aggiornare all'ultima versione SVN.Forse pubblicalo anche sulla mailing list svn-devel (http://svn.haxx.se), in modo che gli sviluppatori possano vederlo.

Nel caso n. 2, controlla se qualcosa ha bloccato il file.È possibile scaricare una copia di Process Explorer per verificare.Tieni presente che probabilmente vorrai vedere chi ha il lucchetto sul file base testuale file, non il file effettivo che stavi tentando di eseguire il commit.

Di tanto in tanto ricevo cose simili, di solito con file a cui nessuno si è avvicinato da settimane.Generalmente, se sai di non aver lavorato nella directory in questione, puoi semplicemente eliminare la directory con il problema ed eseguire 

svn update

per ricrearlo.

Se sono presenti modifiche in tempo reale nella directory, come suggerito da te e da Lassevk, è necessario un approccio più attento.

In generale, direi che è una buona idea non lasciare i file modificati non impegnati e mantenere la copia di lavoro in ordine: non aggiungere un sacco di file extra nella copia di lavoro che non utilizzerai.Impegnati regolarmente, e poi se la copia di lavoro si inceppa, puoi semplicemente eliminare tutto e ricominciare da capo senza preoccuparti di cosa potresti o non potresti perdere, e senza il dolore di cercare di capire quali file salvare.

Proprio oggi sono riuscito a recuperare questo errore estraendo una copia della directory danneggiata in /tmp e sostituendo i file in .svn/text-base con quelli appena inseriti.Ho scritto la procedura in dettaglio qui sul mio blog. Sarei interessato a sentire dagli utenti SVN più esperti quali sono i vantaggi e gli svantaggi di ciascun approccio.

Tentativo:svn up --force file.c

Questo ha funzionato per me senza dover fare nulla in più

Ho osservato molte soluzioni, dall'applicazione di patch al file .svn/entries al nuovo checkout.

Può essere un modo nuovo (grazie al mio collega):

- 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

Matt, esiste un modo più semplice di quello che hai descritto: modificare il checksum nel file .svn/entries.Ecco la descrizione completa:http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/

Un'altra soluzione alternativa, forse ancora più spaventosa, per i conflitti di checksum che ho trovato è la seguente:

AVVERTIMENTO: Assicurati che la tua copia locale sia la versione più conosciuta E che chiunque altro nel tuo progetto sappia cosa stai facendo!(nel caso in cui questo non fosse già ovvio).

se sai che la tua copia locale del file è "quella buona" puoi eliminare direttamente il file dal server SVN e quindi forzare il commit della tua copia locale.

sintassi per la cancellazione diretta:

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

buona fortuna!

J

In alternativa al controllo di una nuova copia (cosa che dovevo fare anche dopo aver provato tutte le altre opzioni) e all'unione di tutte le modifiche salvate in precedenza, il seguente approccio ha funzionato allo stesso modo, ma mi ha fatto risparmiare una quantità considerevole di tempo e possibilmente alcuni errori:

  1. Dai un'occhiata a una nuova copia funzionante
  2. Copia la cartella .svn dalla tua nuova copia nella copia corrotta
  3. Ecco

Naturalmente, dovresti eseguire il backup della tua copia funzionante originale corrotta per ogni evenienza.Nel mio caso, ero libero di rimuoverlo dopo aver finito, poiché tutto è andato bene.

Ciò accadrà quando la cartella .svn è danneggiata.Soluzione:Rimuovere l'intera cartella contenente il file ed estrarre nuovamente la cartella.

Se si è verificato questo problema, le nostre VM di sviluppo sono tutte *nix sulle nostre workstation win32.Alcuni folli hanno creato file con lo stesso nome (caso diverso) nella casella *Nix all'improvviso controlla su Win32 fa esplodere ...Poiché la vittoria non sa quale dei 2 file con lo stesso nome su MD5 contro, le cassa su *Nix andavano bene ...lasciandoci a grattarci la testa per un po'

Sono riuscito ad aggiornare il repository sulla win box copiando le cartelle ".svn" da una box *nix con una buona copia funzionante.dobbiamo ancora vedere se il repository può essere ripulito al punto da poter eseguire nuovamente un checkout completo

Un altro modo semplice....

  1. Aggiorna il tuo progetto per ottenere la versione più recente
  2. controlla la stessa versione in un'altra cartella
  3. sostituisci la cartella .svn dal nuovo checkout alla copia di lavoro (ho sostituito i file .svn-base)
  1. Controlla solo la cartella con il file problematico dal repository in un'altra posizione.
  2. Assicurarsi .svn\text-base\<problematic file>.svn-base è identico a quello verificato.
  3. Assicurati che la sezione del file problematica (tutte le righe della sezione) In .svn\entries è identico a quello verificato.

Non ci crederai, ma in realtà ho corretto il mio errore rimuovendo il file <scm>...</scm> posizione dal file pom.xml incriminato che speravo di verificare.Conteneva l'URL del repository subversion in cui è stato archiviato (questo è lo scopo dell'impostazione Maven!), Ma in qualche modo ha generato un checksum errato per il file durante l'archiviazione.

Ho letteralmente provato tutti i metodi sopra menzionati per risolvere questo problema, ma senza alcun risultato.Ho riscontrato una situazione molto rara in cui il generatore di checksum non è abbastanza robusto?

Anch'io mi sono imbattuto in questo problema e stavo cercando soluzioni rapide, ho provato alcune delle soluzioni fornite in questo thread.Ecco come ho risolto questo problema nel mio ambiente di sviluppo (per me si è trattato di un cambiamento minimo):

1- Directory eliminata localmente in cui il file è stato danneggiato (WEB-INF):

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

2- Directory copiata e incollata (WEB-INF) da un nuovo checkout

3- Svn up, ora Eclipse/TortoiseSVN ha iniziato a mostrare conflitti in questa directory

4- Conflitto contrassegnato come risolto

Ha funzionato, sono stato in grado di aggiornare, eseguire il commit di web.xml precedentemente danneggiato

Nel mio caso la somma era diversa.Tutto quello che ho fatto è stato:

1) Effettua il Check Out in una cartella separata

2) Sostituisci con un file da questa cartella nella directory .svn con il file dei problemi del mio progetto indicato nel messaggio di errore svn-client

3) ..profitto!

Anche se questo è un vecchio problema, ho pensato di dare anche i miei 2 centesimi, dato che ho lottato con il problema per più di un'ora.

Le soluzioni di cui sopra non hanno funzionato per me o sembravano troppo complicate.

La mia soluzione era semplicemente rimuovere tutte le cartelle svn dal progetto.

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

Successivamente, ho eseguito nuovamente il semplice checkout del progetto.Lasciando così intatti tutti i miei file non salvati, ma ho comunque ottenuto una ricostruzione di tutti i file svn.

Ho avuto questo problema su Ubuntu 14.04 e l'ho risolto seguendo i passaggi:

  1. $ cd /var/www/mioprogetto
  2. Aggiornamento $ svn
  3. Aggiornamento $ svn

dopo questi passaggi ho potuto eseguire il commit del file senza errori.

  1. Vai alla cartella che causa il problema
  2. Esegui il comando svn update --set-depth empty
  3. Questa cartella si svuoterà e ripristinerà la cartella vuota
  4. Sincronizza con svn e aggiorna.

Questo funziona per me.

ecco come ho risolto il problema: è semplice, ma come da jsh sopra, devi assicurarti che la tua copia sia la migliore.

semplicemente

  1. fare una copia di tutti i file problematici, nella stessa cartella.
  2. cancella quelli vecchi con svn rm
  3. commettere.
  4. quindi rinominare le copie con i nomi dei file originali.
  5. impegnarsi di nuovo.

sospetto che questo probabilmente uccida ogni sorta di cronologia delle revisioni su quel file, quindi è un modo piuttosto brutto per farlo...

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top