git svn fetch recupera la stessa revisione Subversion più volte per le diramazioni

Question

Sto vedendo git svn fetch recuperare ripetutamente le stesse revisioni di Subversion quando trova i rami nel mio repository Subversion. Siamo usando il layout standard del repository Subversion, con le directory /trunk,/tags e/branches di livello superiore (e il repository git era creato con 'git svn init -s'). Tuttavia, i rami problematici sono spesso copie effettuate da una sottodirectory all'interno del trunk, invece del trunk .

Lo svn git fetch output è di solito qualcosa di simile:

 
r2537 = d5b22e956157af036d4112e42e8fb927e45758c8 (trunk) 
     M  Enterprise/VC/libgc/SymbolVenue.cpp 
r2538 = cfed4ca0491da0b732f32bfff72ba678450a0915 (trunk) 
Found possible branch point: http://repo/prod_repos/trunk/Enterprise/VC => http://repo/prod_repos/branches/file_conversion, 2523 
W: Refspec glob conflict (ref: refs/remotes/scripter@832): 
expected path: branches/scripter@832 
    real path: trunk/Enterprise/Python 
Continuing ahead with trunk/Enterprise/Python 
W: Refspec glob conflict (ref: refs/remotes/trunk): 
expected path: branches/trunk 
    real path: trunk 
Continuing ahead with trunk 
Initializing parent: file_conversion@2523 
     A  gc/QuoteService.cpp 
     A  gc/TestSuite.h 
     A  gc/quote_svc.pro 
     A  gc/QuoteService.h 
..... 

r1 = d349ed8cb2d76596fe2b83224986275be4600fad (QuoteSvcFix442@2698) 
     D  gc/FixMessageLogger.h 
..... 
r5 = 
r19 = 
r20 = 
..... 

E siamo tornati a revisione 1. git svn fetch poi continua a prendere le revisioni fino a raggiungere la revisione che creato il ramo.

Cosa sto sbagliando? Devo comunque comunicare a git svn fetch a di non recuperare le revisioni che ha già tirato?

Answer 1

ho notato questa domanda perché ho ottenuto lo stesso messaggio di errore:

W: Refspec glob conflict (ref: refs/remotes/trunk): 
expected path: branches/trunk 
    real path: trunk 

Si è scoperto che .git/config aveva righe duplicate che sembrano confondere git-svn, come questo:

[svn-remote "svn"] 
... 
    branches = project/branches/*:refs/remotes/* 
    tags = project/tags/*:refs/remotes/tags/* 
    branches = project/branches/*:refs/remotes/* 
    tags = project/tags/*:refs/remotes/tags/* 

Rimuovere quei duplicati ha risolto il comportamento strano di git-svn per me, e potrebbe valere anche per te. Non sono sicuro di cosa abbia causato a git-svn la duplicazione di queste informazioni in primo luogo. Ho ucciso e continuato il clone iniziale, questo potrebbe essere correlato?

Answer 2

git-svn sembra stia ripetendo ripetutamente le stesse revisioni perché ci sono tag nel tuo repository SVN. Il concetto di tag di SVN è leggermente diverso da git's: SVN tags are actually branches (quindi SVN tags are copies).

Date un'occhiata più da vicino l'output:

r1 = d349ed8cb2d76596fe2b83224986275be4600fad (QuoteSvcFix442@2698)

Anche se la revisione r1 = sembra troppo familiare, il resto del testo probabilmente è diversa. Come minimo, il nome del tag (in questo caso QuoteSvcFix442@2698) non sarà lo stesso.

Penso che l'unico modo per evitare questo è avere git-svn saltare i tag SVN. Se non è possibile vivere senza i tag, è possibile anche convert the SVN 'tag' branches to real git tags (ma bisogna prendere tutti i rami di tag, in primo luogo!)

---

Un correlato domanda SO con possibili work-around: Can Git-svn be used on large, branched repositories?

Alcune discussioni su questo problema: git-svn --tags should at least /try/ to handle tags as tags.

Answer 3

Rimuovere i duplicati ha ancora creato un problema per me. Ogni volta che riesegui il comando clone, ad es. git svn clone svn: //.../svnroot --no-metadata -A authors-transform.txt --stdlayout. Aggiunge altre due righe a.git/config. ho dovuto togliere tutte le linee che contengono rami = rami/: refs/telecomandi/ e tags = Tag/: refs/telecomandi/tags/

Lasciando config cercando come di seguito:

[core] 
     repositoryformatversion = 0 
     filemode = true 
     bare = false 
     logallrefupdates = true 
[svn-remote "svn"] 
     noMetadata = 1 
     url = svn://.../svnroot 
     fetch = trunk:refs/remotes/trunk 
[svn] 
     authorsfile = /home/users/denn/authors-transform.txt 
~ 

Answer 4

Se, in qualsiasi punto, il trunk del repository era presente in una posizione diversa in SVN, provare a specificare questa posizione per recuperare ulteriormente il file di configurazione del repository. Per esempio:

[svn-remote "svn"] 
... 
    fetch = project/trunk:refs/remotes/origin/trunk 
    fetch = previous/location/of/trunk:refs/remotes/origin/trunk-old1 
    fetch = another/location/of/trunk:refs/remotes/origin/trunk-old2 
    ... 

Per il progetto mi importava, ci sono stati molti rami e tag che erano stati creati da queste posizioni precedenti. Dato che questi erano rami/tag creati da un luogo "sconosciuto", git svn stava alzando le mani e stava recuperando tutta la storia per scoprirlo. (Questo approccio richiedeva comunque un recupero completo per ogni posizione, ma era MOLTO più veloce di un recupero cronologico completo per ogni tag)