Come posso risolvere l'errore di fine riga dell'importazione SVN?

Question

Devo importare un enorme repository SVN che devo trasferire da un server a un altro. Così ho esportato dal vecchio server:

svnadmin dump . > archive.svn 

e importati sul nuovo:

svnadmin load . < archive.svn 

Nel bel mezzo del processo di importazione ho ottenuto questo errore:

Cannot accept non-LF line endings in 'svn:ignore' property 

Come posso risolvere questo? Ho il pieno controllo di entrambi i server.

Answer 1

Hai cambiato la versione del server? Questo è un problema noto in 1.6 e causa problemi quando si passa da 1.4 o 1.5.

Subversion 1.6 non accetta più i ritorni a capo (^ M) nei file di proprietà. Dovrai correggere le interruzioni di riga nella tua svn: ignora i file o ricreare se è più facile.

In alternativa, è possibile utilizzare Subversion 1.7 oppure utilizzare uberSVN.

Answer 2

Hai 2 opzioni, ripara l'origine o disattiva la validazione del puntello.

Riparazione sorgente (svn: log e svn: ignore):

sed -e '/^svn:log$/,/^K/s/^M/ /' -e '/^svn:ignore$/,/^PROPS-END$/ s/^M/\n/' archive.svn > repaired-archive.svn 

svnadmin load . < repaired-archive.svn 

Dove ^M è un carattere di controllo, che significa 0D in esadecimale. Per farlo utilizzare^V^M (controllo controllo V M) invece^M (circonflesso M o di controllo M)

Disattivazione convalida prop:

svnadmin load --bypass-prop-validation . < archive.svn 

Answer 3

mi sono imbattuto in questo errore durante l'aggiornamento un 1,6 pronti contro termine a 1,8. Ho trovato un numero di "correzioni" sulla rete.

Il --bypass-prop-validation non mi ha attirato perché rimanda il problema, la prossima volta che è necessario ripristinare il repository si colpirà lo stesso promblem.

Ho trovato uno script di bash per scorrere le revisioni ottenendo i commenti e impostandoli di nuovo, ma questo non ha funzionato.

Un miglioramento sulla soluzione di ventura10 ha funzionato. A causa delle dimensioni della discarica ho finito per usare il singolo comando per rimuovere i caratteri indesiderati durante il ripristino della discarica

sed -e '/^svn:log$/,/^K/s/^M/ /' -e '/^svn:ignore$/,/^PROPS-END$/ s/^M/\n/' /path/to/svn.dump | svnadmin load /path/to/repo 

NOTA:

Where ^M is a control character, that means 0D in hex. To get it use ^V^M (control V control M) instead ^M (circumflex M or control M)

Answer 4

La prima opzione della risposta di @ ventura10 suonava bene ma non ha funzionato per me. Il comando sed ha modificato alcuni contenuti con versione esterna alla sezione delle proprietà, causando incoerenze md5 durante il caricamento del dump.

Poiché il mio repository non ha proprietà con contenuto binario, ho modificato il comando sed per correggere tutte le proprietà e non solo svn:log e svn:ignore. Ero anche sicuro che nessun file con versione contenesse una riga che inizia con Prop-content-length:. Altrimenti avrei ricevuto un errore durante il caricamento del dump.

sed -e '/^Prop-content-length: /,/^PROPS-END$/ s/^M/ /' svn.dump > svn.dump.repaired 

E 'importante sostituire ^M con [blank], perché la dimensione del valore della proprietà non deve cambiare.

La nota di @ ventura10 è ancora valido:

^M is a control character, that means 0D in hex. To get it use ^V^M (control V control M) instead ^M (circumflex M or control M)

E 'difficile credere che l'aggiornamento di un archivio esistente da svn 1.4 a SVN 1.7 rende questo passo nessecary, ma ho trovato nessun altro modo per sbarazzarsi dei ritorni a capo che non sono più accettati da quando svn 1.6.

Answer 5

Uso svndumptool:

svndumptool.py eolfix-prop svn:ignore svn.dump svn.dump.repaired 

soluzione @tangens lavora troppo per me, ma non è perfetto come sto ricevendo un carattere di spazio extra come la sostituzione dei caratteri di ritorno a capo. Ho comunque provato che lo svn: ignore funziona ancora con quello spazio extra, ma non ho provato le altre proprietà SVN.

Lo svantaggio dell'uso di svndumptool è che può funzionare solo su una proprietà svn alla volta, il che richiede molto tempo se i file di dump sono grandi.

---

Alcuni risultati

si potrebbe essere curioso sul perché @tangens non sostituire il^M con carattere vuoto. Se si tenta di sostituirlo con carattere vuoto, si sarà in questo errore:

file memorizza

svnadmin: E140001: Dumpstream data appears to be malformed 

la discarica Prop-content-length proprietà che verrà confrontato con il contenuto del contenuto effettivo della proprietà. Sostituendo^M con un carattere vuoto si riduce la lunghezza del contenuto della proprietà, quindi l'errore.

svndumptool cambierà rispettivamente lo Prop-content-length e Content-length.

Answer 6

Con un po 'di ginnastica è possibile aggirare il problema utilizzando svnsync, che ha la capacità di correggere gli EOL. Supponiamo che il tuo repository venga scaricato in archive.svn.

Innanzitutto creare il repository per caricare il repo indietro, ignorando i problemi EOL:

svnadmin create repo 
svnadmin load repo < archive.svn --bypass-prop-validation 

Ora create un nuovo repository per la copia in:

svnadmin create repo-fixed 

svnsync richiede un po 'di pre-commit hook, anche se non lo usi, quindi usa semplicemente il tuo editor per crearne uno vuoto in repo-fixed/hooks/pre-revprop-change:

#!/bin/sh 
exit 0 

Inizializzare il repository di destinazione per svnsync:

svnsync init file:///path/to/repo-fixed file:///path/to/repo 

Ora copiare l'intero repository su:

svnsync sync file:///path/to/repo-fixed 

Accidenti! svnsync sarà anche darvi una buona notizia: (. Perché la squadra di Subversion non si aggiornava svnadmin a fare lo stesso normalizzazione è un mistero per me) NOTE: Normalized svn:* properties to LF line endings

Una volta fatto, il dump del nuovo repository:

svnadmin dump repo-fixed > archive-fixed.svn 

Ora hai archive-fixed.svn, che dovrebbe essere identico a archive.svn tranne che gli EOL sono stati risolti secondo necessità.

(opzionale) È ora possibile rimuovere il repository temporanea utilizzato per svnsync:

rm -rf repo-fixed 

Aggiornamento Si scopre se si carica questa nuova discarica, il client di Subversion ottiene un errore: Repository UUID does not match expected UUID . Dovrai utilizzare svnadmin setuuid ... a change the UUID ID to what it used to be.

(Questo post è il culmine di una moltitudine di frammenti e soluzioni parziali che ho trovato in giro per il web, grazie a tutte le persone che sapevano più di me;. Ho appena messo tutto insieme.)

Vedi anche :

• Copying subversion repositories with history using svnsync
• https://stackoverflow.com/a/28472420/421049
• https://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt

Answer 7

Ho appena riparato un file svn dump con successo. Aveva anche un CRLF nelle proprietà, che ha causato un'eccezione nell'importazione di dump di SVN Edge (hanno una routine di importazione veramente brutta). Poi ho "installato" svnserve per i test, che era molto più facile del previsto (istruzioni per il sistema operativo Windows):

1. scaricare e installare TortoiseSVN o un altro software che include strumenti da riga di comando svn. L'ho già installato
2. start cmd.exe, eseguire svnserve -d.Questa finestra di cmd è occupata ora.
3. avviare un altro cmd.exe creare un repo: svnadmin create d:\svn_repos\test12
4. carico la discarica nella repo: svnadmin load d:\svn_repos\test12 < d:\temp\svn\backup_test.dump

svnserve vi darà informazioni dettagliate che cosa non è riuscita.

Ed ecco cosa si deve riparare (originale a sinistra, riparato sul lato destro):