2015-09-08 21 views
34

Quando eseguo git svn clone ottengo il seguente errore:git info error svn clone indice malformati

0 [main] perl 24432 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump 
    fatal: malformed index info 100644 362f1c18ceed5d593eb021432545685283a93 

Quando apro il file vedo il seguente:

Exception: STATUS_ACCESS_VIOLATION at rip=0048360C537 rax=00000006039F81E0 rbx=000000005219E248 rcx=000000060003A3C0 rdx=0000000000000000 rsi=000000000000FDB4 rdi=0000000000000004 r8 =0000000000000000 r9 =0000000000000000 r10=0000000000230000 r11=000000048D785FBA r12=0000000000000003 r13=000006FFFF7FEDB8 r14=00000006014D4030 r15=000006FFFF7FEDD0 rbp=000000000007EDA8 rsp=000000000022BE80 program=C:\Program Files\Git\usr\bin\perl.exe, pid 24432, thread main cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

ho controllato il seguente link:

Error with Git SVN clone

Problem cloning a single SVN Branch via git svn

Python SVN bindings for Windows

subversion python bindings documentation?

Purtroppo, io non sono a conoscenza sufficiente per le tecnologie di base per capire esattamente che cosa dovrei fare. Potrebbe causare questo e come potrei essere in grado di risolvere?

+1

Si può eludere l'elettore per favore spiegare perché questo è stato rifiutato? – Aelphaeis

+2

Sto votando per chiudere questa domanda come off-topic perché SO non è un posto dove discutere specifici bug noti di un software. Dovrebbero segnalarlo a bugzilla o mailing dove dovrebbe essere –

risposta

5

ho avuto eccezioni simili e messaggi di errore, per me un

git gc 

e/o un

git svn gc 

portato il repository di nuovo in uno stato utilizzabile. Vedi anche https://stackoverflow.com/a/1436386/411846

+0

dato che 'git svn clone' è * creando * un repository, dove hai eseguito questi comandi? – simpleuser

+0

Ho appena visto lo stesso messaggio di errore, potrebbe essere stato dopo aver fatto "git svn clone" prima, onestamente, non mi ricordo più nei dettagli più ora. – centic

0

Nel mio caso questo errore si è verificato con un grande repository. Quindi prova a clonare la sottocartella, se possibile.

2

aggiornato - Il problema si verifica ancora dopo git gc per me. Ho provato ogni versione di git windows (sia a 32 che a 64 bit), ma ho ancora ricevuto questo errore. Poi sono passato a usare git su linux e funziona bene per me, anche per commit estremamente grandi. Vi consiglio di passare a Linux altrimenti non siete fortunati perché il problema è stato sollevato qui - https://github.com/git-for-windows/git/issues/274 ha quasi 6 mesi.

aggiornato - Per aggiungere alla risposta di centic, il git gc funziona correttamente per git 32 bit per Windows, per questo particolare problema.

Penso che il problema esista per git 64 bit per Windows. Stavo avendo lo stesso problema con git 64 bit, ma dopo il passaggio a git 2.7.2 windows 32-bit, i problemi sembrano essere risolti per me.

+0

Sono passato a 32 bit da 64 bit. E l'ho risolto! Grazie. – Devgrapher

1

Sono stato in grado di controllare correttamente il repository SVN utilizzando Cygwin.

17

Ho ricevuto questo errore durante la migrazione di repository svn enorme per git utilizzando lo strumento svn2git. Ho aggiunto qui di seguito le linee nel mio .git file/config e iniziato a lavorare:

[core] 
    repositoryformatversion = 0 
    filemode = false 
    bare = false 
    logallrefupdates = true 
    symlinks = false 
    ignorecase = true 
    hideDotFiles = dotGitOnly 
    packedGitLimit = 256m 
    packedGitWindowSize = 256m 
    longpaths = true 
[http] 
    postBuffer = 524288000 
[pack] 
    deltaCacheSize = 256m 
    packSizeLimit = 256m 
    windowMemory = 1024m 

Queste impostazioni sono spiegate al git-config man page.

+0

Inoltre ha risolto il problema per me. Le uniche due impostazioni che ho dovuto modificare erano 'core.packedGitLimit' e' core.packedGitWindowSize' – wimh

+1

'longpaths = true' mi stava aiutando! Grazie! – derFunk

+0

Per me è stato 'postBuffer = 134217728' che ha aiutato (aumentare a questo valore già aiutato, renderlo ancora più grande, come nell'esempio sopra, sarebbe d'aiuto). – JonnyJD

4

Verificare quale svn commit ha causato il problema.

I commit vengono emessi dal comando git svn clone, preceduto da un r. L'ultimo commit che viene emesso è quello problematico.

L'esempio seguente mostra cosa uscite di comando git svn clone quando iniziano procesing revisione Subversion15 come Git impegnano373fb1...:

r15 = 373fb1de430a6b1e89585425f276aae0058c3deb (refs/remotes/svn/trunk) 

contempla il comando git svn clone utilizzando l'opzione -r (revisione)

Utilizzare questo metodo:

git svn clone -r 0:<problematic_revision - 1> <repo URL> 
git svn clone -r <problematic_revision - 1>:problematic_revision <repo URL> 
git svn clone -r <problematic_revision>:HEAD <repo URL> 

Supponendo revisione 15 come problematica, e il repository in /tmp/svn/repo/, la soluzione sarebbe:

git svn clone -r 0:14 file:///tmp/svn/repo/ 
git svn clone -r 14:15 file:///tmp/svn/repo/ 
git svn clone -r 15:HEAD file:///tmp/svn/repo/ 
+0

Nel mio caso, la revisione problematica era il numero 1. Ma l'uso della formula non ha funzionato direttamente. Ciò che ha funzionato per me è stato splitint 0: 2 e poi 2: HEAD. La soluzione utilizzava comunque il tuo metodo. – jgomo3

11

Aggiornamento: Dopo l'aggiornamento a Ubuntu 17.04 con 2.11.0 e git-svn 1 : 2.11.0-2ubuntu0.2 il clone funzionava perfettamente.

ho trovato una soluzione divertente per questo problema durante il debug attraverso gli script Perl:

  • Rallentare o in qualche modo manipolare l'esecuzione eseguendo git svn nel debugger perl.

Avviare git svn fetch con il seguente comando (potrebbe essere necessario modificare i percorsi. Ciò dovrebbe funzionare anche con clone). Assicurarsi di eseguire il comando all'interno del repository git/directory:

perl -d /usr/lib/git-core/git-svn fetch 

Immettere il seguente nel debugger e premere INVIO:

b /usr/share/perl5/Git/SVN/Fetcher.pm:368 $base==undef or $dup==undef 

Questo aggiunge fondamentalmente un punto di interruzione condizionale nella posizione in cui mi ottenere il segnale 11. Questa è la riga di codice:

[ SVN::TxDelta::apply($base, $dup, undef, $fb->{path}, $fb->{pool}) ]; 

questo punto inserite c per continuare l'esecuzione de n e premere ENTRA.

Qualcuno può spiegare perché questo aiuta?

Modifica: Ha funzionato: 213000 revisioni e 1780 rami clonati in git!

+0

Grazie! Questa soluzione ha funzionato per me! Altre soluzioni alternative come l'aggiornamento di git/svn, la modifica di .git/config, l'uso di 64-bit (OS o/e git), o linux, non hanno aiutato. Comunque ho avuto un altro problema (max file aperti), ma questo ha aiutato http://stackoverflow.com/a/24796466/199225 – kibab

+0

Questo ha aiutato molto come soluzione, ma ho ancora bisogno di trovare la soluzione. – lcltj

+0

OMG, sì, questo ha funzionato anche per me. Che strano. Grazie! –

0

Nel mio caso, non ero connesso alla nostra VPN, necessaria per la nostra connessione svn.Questo è il mio errore:

Exception: STATUS_ACCESS_VIOLATION at rip=00000000000 
rax=0000000000000000 rbx=00000006010BBDA8 rcx=00000006010BBDA8 
rdx=00000006010C40E8 rsi=0000000000000011 rdi=0000000000000000 
r8 =0000000000000000 r9 =00000006010EBCA8 r10=0000000100000000 
r11=000000049F2423C9 r12=00000000FFFFC190 r13=00000000FFFFC198 
r14=00000006010B2DF8 r15=00000006010B2D68 
rbp=00000000FFFFC1A8 rsp=00000000FFFFC138 
program=C:\Program Files\Git\usr\bin\perl.exe, pid 7884, thread main 
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B 
Stack trace: 
Frame  Function Args 
End of stack trace 
1

mi è stato sempre tutti i tipi di errori con git-svn in cui lo script perl sarebbe morto in vari luoghi, il recupero avrebbe rotto, o il server avrebbe tagliato la connessione. Questo è stato un enorme repo che ha richiesto dozzine di GB al check-out via svn.

Ciò che mi ha risolto era semplicemente utilizzare SmartGit anziché git-svn. Richiede Java 8, ha funzionato molto velocemente e non ha segnalato errori di sorta, completando in poche ore l'attività che ha richiesto svn diversi giorni.

+1

Sembra una buona idea ... ma schifo, è gratuito solo per uso non commerciale ;-( – GhostCat

0

Ecco il problema che ho:

  • OS: Xubuntu 16.04
  • git-svn versione 2.7.4 (svn 1.9.3)

informazioni Trace da perl -d /usr/lib/git-core/git-svn fetch:

Signal SEGV at /usr/local/share/perl/5.22.1/Git/SVN/Fetcher.pm line 368 
    Git::SVN::Fetcher::apply_textdelta(Git::SVN::Fetcher=HASH(0x20ee160), HASH(0x2488a40), undef, _p_apr_pool_t=SCALAR(0x2488bf0)) called at /usr/lib/x86_64-linux-gnu/perl5/5.22/SVN/Ra.pm line 623 
    SVN::Ra::Reporter::AUTOLOAD(SVN::Ra::Reporter=ARRAY(0x8d0fa0), SVN::Pool=REF(0x20ee910)) called at /usr/local/share/perl/5.22.1/Git/SVN/Ra.pm line 308 
    Git::SVN::Ra::gs_do_update(Git::SVN::Ra=HASH(0x20df170), 42560, 42560, Git::SVN=HASH(0x20dea08), Git::SVN::Fetcher=HASH(0x20ee160)) called at /usr/local/share/perl/5.22.1/Git/SVN.pm line 1205 
    Git::SVN::do_fetch(Git::SVN=HASH(0x20dea08), HASH(0x20ee1d8), 42560) called at /usr/local/share/perl/5.22.1/Git/SVN/Ra.pm line 471 
    Git::SVN::Ra::gs_fetch_loop_common(Git::SVN::Ra=HASH(0x20df170), 42500, 95400, ARRAY(0x1637c08), ARRAY(0x1637c20)) called at /usr/local/share/perl/5.22.1/Git/SVN.pm line 179 
    Git::SVN::fetch_all("svn", HASH(0x20dee28)) called at /usr/lib/git-core/git-svn line 570 
    main::cmd_fetch() called at /usr/lib/git-core/git-svn line 386 
    eval {...} called at /usr/lib/git-core/git-svn line 384 
Aborted (core dumped) 

Alla fine ho risolto questo problema le seguenti operazioni (questo è per Ubuntu Linux 16.04 utenti):

sudo apt build-dep subversion 
sudo apt install libneon27-dev 
sudo cpan SVN::Core 

allora posso usare git svn fetch/clone senza alcun incidente.

La causa principale di questo problema è che lo script della libreria Perl SVN :: Core non corrisponde ai file binari installati in Perl (ci sono binari di sovversione separati installati in Perl accanto a quelli installati di sistema).

Attenzione, questo farà passare la versione svn della tua git-svn alla versione 1.8.11 (prima che sia 1.9.3), e potrebbe causare altri problemi.

0

posso riprodurre questo problema ogni volta, e git svn funziona perfettamente in

version 1.9.5

È possibile installarlo dal Git-1.9.5-preview20141217.exe da

https://github.com/msysgit/msysgit/releases/tag/Git-1.9.5-preview20141217

mi chiedo se qualcuno può controllare la differenza tra la vecchia versione 1.9.5 e la versione attuale (dopo aver spostato da msysgit a qui)

È doloroso usare la vecchia versione per git, solo perché git svn non può ork correttamente nella nuova versione.