Svnsync non può sincronizzare il repository

Question

Ho un accesso in lettura al repository Subversion remoto e desidero clonarlo tramite svnsync. La sincronizzazione inizia bene e procede bene, ma verso la fine ricevo un errore simile a:

Transmitting file data ...svnsync: File not found: transaction '12893-qyy', path
 '/project_name/trunk/path/to/file.cpp'

Posso controllare con successo la revisione in questione, la revisione precedente e la revisione successiva. Tutti i file sono a posto. Ho controllato il log per il file in questione: la sua cartella è stata spostata in questa posizione nella revisione precedente.

Posso forzare svnsync a ignorare questo errore e continuare la sincronizzazione? Non ho accesso come amministratore al repository, quindi non posso risolverlo.

AGGIORNATO: Risposta ai commenti: ho controllato lo stesso client subversion dell'uso del server (1.6.6), l'ultima versione stabile (1.6.17) e la versione beta (1.7). Tutti danno esattamente lo stesso errore. Inoltre, posso eseguire il checkout del repository "danneggiato": ultima revisione, revisione in questione (12893), revisione precedente (12892) e revisione successiva (12894) senza errori.

AGGIORNATO: risposta ad altri commenti: il registro svn mostra che nella revisione 12892 la cartella "a" è stata spostata da /repo/other_project/trunk/source_path a /repo/project_name/trunk/path

Answer 1

Dato che puoi effettuare il checkout delle revisioni prima e dopo, immagino che tu non abbia alcun danneggiamento del repository. svnsync funziona "riproducendo" le transazioni invece di rispecchiare i dati o qualcosa del genere. Di conseguenza, possono esserci bug che impediscono la riproduzione di una transazione. Immagino che qualcosa su quel commit abbia attivato un bug. È possibile eseguire svn log -c 12893 -v per esaminare la revisione in modo più dettagliato. Immagino che contenga qualcosa come una sostituzione "R" che sta causando il problema. Potresti raccogliere informazioni e inviarle a users@subversion.apache.org in modo che possa essere analizzato e, si spera, corretto.

Ecco alcune altre idee:

• Come si accede al repository dei sorgenti? file: // http:// ecc. Se è http:// potresti provare a cambiare dall'utilizzo della libreria HTTP predefinita di Neon a Serf e vedere se ha ancora il problema. Puoi farlo aggiungendo --config-option= servers: global: http-library= serf al comando svnsync quando lo esegui. Vale la pena provare.

• Vedi se riesci a scaricare la revisione. svnadmin dump -r12892: 12893 --incremental reposname> dumpfile

• Se puoi scaricare la revisione, caricarla puoi caricarla manualmente nel repository di destinazione utilizzando svnadmin load.

• Se puoi caricare la revisione, puoi correggere manualmente le proprietà di svnsync in modo che sappia di aver eseguito quella revisione. svn ps --revprop -r0 svn: sync-last-merged-rev 123893 url: // to / mirror

AGGIORNATO: il problema è stato risolto utilizzando la nuova utility svnrdump da subversion 1.7 RC2.

Answer 2

Per aggiungere alle risposte sopra, l'ultima risorsa che ha risolto il mio problema era usare il comando svndumpfilter per escludere i nodi che erano corrotti.

Ogni volta che ho provato a caricare la revisione specifica dopo aver utilizzato svnrdump, ricevevo il seguente errore;

... svnadmin: E160004: il file system è danneggiato svnadmin: E200014: mancata corrispondenza del checksum durante la lettura della rappresentazione: previsto: 77ec72e82afddd1cb8d2c63760cf4dbb effettivo: f34fb5883dffffec3cd59a69f8a2cb99

Se hai creato il dump della revisione come rev12892.dmp, puoi escludere un percorso, ad es. "/ nome_progetto / trunk / path" come segue;

svndumpfilter exclude / project_name / trunk / path pruned_dump_file

Vedi il redbook svn per dettagli sul comando svndumpfilter: http://svnbook.red-bean.com/en/1.7/svn.ref.svndumpfilter.commands.c.exclude.html