2011-08-25 8 views
16

Quando eseguo ungit-svn recupero non sta tirando nelle ultime versioni

git svn fetch

dal mio repository, restituisce nulla e non aggiorna, anche se ci sono nuovi commit sotto svn.

[root]# svn log -l 1 http://example.com/trunk/client-resources/resource-pa 
    r12958 | ing | 2011-08-22 18:29:57 -0500 (Mon, 22 Aug 2011) | 1 line 
    SRGENERAL-1468 adding more arrays for pa 
[root]# git-svn fetch 
[root]# git log -1 
    commit be19ae4c7d1a3c3da6dd90389aebd6d76792cc71 
    Author: sltin <[email protected]> 
    Date: Wed Jun 22 14:30:53 2011 +0000 

    Fixing the classpath. 

    git-svn-id: http://example.com/trunk/client-resources/[email protected] 44b83e5a-25ef-0310-8dbe-ee0aa4f92a64 

Nota le differenze di versione. Il registro svn elenca 12958 e il registro git elenca l'ultima versione svn come 12406.

posso fare un reset a 12406 e poi un nuovo recupero:

[root]# git svn reset 12406 
    r12406 = be19ae4c7d1a3c3da6dd90389aebd6d76792cc71 (refs/remotes/git-svn) 
[root]# git svn fetch 
     M  src/test/java/csl/resource/ioc/AbstractResourceIocTest.java 
    r12977 = 1b21f560b0354b28fe1a272d7723b1e6fa90a99c (refs/remotes/git-svn) 
     M  src/test/java/csl/resource/ioc/AbstractResourceIocTest.java 
    r12978 = bf22ea0151a364eb1ca1af37a7a907d5b5cc7420 (refs/remotes/git-svn) 
     M  src/test/java/csl/resource/ioc/AbstractResourceIocTest.java 
    r12987 = ce922c2eae07f6c12dbbd4175a9c61055b563ee3 (refs/remotes/git-svn) 

E quando controllo le versioni di registro, sono invariati.

Come faccio a ottenere git-svn per inserire le ultime versioni da svn?

Edit:

ho trovato la risposta, i dati svn viene caricato in una filettatura inattiva che normalmente verrebbe fusa per il ramo attivo, che non esiste in un repository nudo. Ho provato a fare un reset, ma anche quello ha bisogno di un ramo attivo. La risposta finale è stata:

git reset --soft refs/remotes/git-svn 
+1

Il repository git sto tirando i dati a un nudo repository che sempre e solo ottenere leggere da (nessun dcommits) in modo da non permettere nemmeno un rebase. – Starkii

+0

Inoltre, "git svn log -1" restituisce la versione corretta, ma "git log -1" non lo fa e la versione aggiornata non è nel repository. – Starkii

+0

Starkii: devi distinguere tra 'git-svn' e' git'. 'git log' visualizza il file dal git commit corrente (' HEAD'), 'git svn log' utilizza le informazioni ottenute tramite i metadati svn e visualizza il log per - non necessariamente raggiungibile da HEAD - svn commit. – knittl

risposta

6

Ho trovato la risposta, i dati svn sono caricati in un thread inattivo che verrebbe normalmente unito nel ramo attivo, che non esiste in un repository nudo. Ho provato a fare un reset, ma anche quello ha bisogno di un ramo attivo. La risposta finale è stata:

git reset --soft refs/remotes/git-svn 
+0

domanda stupida, ma lo fai dopo il git svn fetch, o prima? –

4

credo che si desidera git svn rebase. Questo è diverso da git pull, ma simili in quanto comportano entrambi due passaggi (recupero da remoto e quindi rebase o unione).

È inoltre possibile rebase solo già commit recuperati:

git svn rebase --local 

Se si dispone di commit locali che non sono ancora in SVN, git-svn ripete (rebase) li in cima alla più recente SVN commit.

23

git svn fetch copia solo le nuove revisioni nel database degli oggetti locale, molto simile a git fetch - entrambi sincronizzano solo i database degli oggetti. Non aggiornerà la tua filiale e la copia di lavoro. Per ottenere le modifiche appena recuperate nel ramo, utilizzare git svn rebase; riapplicherà tutte le modifiche locali in cima all'ultima revisione di svn.

git svn rebase eseguirà un avanzamento rapido quando non ci sono commit locali, quindi non dovrebbe rovinare la cronologia. In alternativa è possibile utilizzare git merge --ff-only git-svn per avanzare rapidamente alla revisione più recente svn (e interrompe quando non è veloce-forwardable, cioè non un diretto discendente)

Si dovrebbe utilizzare solo git svn reset quando svn monte ha cambiato la storia (svndump/svnadmin) ed è necessario recuperare nuovamente i nuovi commit, ma questo non dovrebbe quasi mai accadere (altrimenti incolpare l'amministratore!)

Problemi correlati