2012-11-02 25 views
5

ProblemaUtilizzo di Git come bridge tra Git e SVN Repos?

mio team utilizza git per il controllo del codice sorgente sul bitbucket, il nostro cliente utilizza Subversion in casa. In che modo il nostro team può continuare a utilizzare git pur avendo il codice controllato in Subversion? E, no, non credo che git-svn funzionerà.

Requisiti

La mia squadra vuole utilizzare una soluzione git pura, non git-svn. La ragione di ciò è che il nostro client ci ha concesso l'accesso al loro ambiente svn solo all'interno della nostra LAN ufficio; non possiamo impegnarci a svn quando lavoriamo fuori dall'ufficio.

mio approccio

ho pensato che avrei potuto checkout il repository subversion con git-svn, quindi aggiungere il nostro esempio bitbucket git come un telecomando per lo stesso repository svn git-avvolto. Un lavoro cron potrebbe quindi fare il git pull dalla nostra repo bitbucket, poi fare un git svn dcommit per spingere i cambiamenti nella bitbucket fino al repository subversion del nostro cliente.

Questo era problematico per il motivo che git avrebbe sempre mostrato che era "x" numero di revisioni prima del repository git bitbucket dopo il processo pull, svn dcommit terminato.

Mentre nulla di strano all'esterno si sta verificando, a un certo punto sono fiducioso che il nostro cliente inizierà a fare check-in nel proprio repository di subversion che dovrò eventualmente spingere alla nostra istanza di bitbucket.

Dettagli tecnici

Ecco una serie di massima di passi che ho usato per cercare di ottenere questo lavoro:

git svn clone -s http://svn.my-client.us/my-proj/ 
cd my-proj 
git remote add origin path-to-bitbucket-repo 
git fetch origin 
git checkout -b develop remotes/develop 
git branch --set-upstream develop origin/develop 
git pull 
#add merge comment here 
git svn rebase 
git svn dcommit #takes a while to transfer all the individual commits 

Dopo tutto quanto sopra, l'esecuzione git status:

[[email protected] myDir]$ git st 
# On branch develop 
# Your branch is ahead of 'origin/develop' by 59 commits. 
# 
nothing to commit (working directory clean) 

Dato che ho bisogno di essere in grado di fare il check-in da qualsiasi luogo, non solo mentre sono in ufficio, c'è qualche s trategy per usarlo come il ponte per fare questo?

Grazie!

risposta

4

L'approccio è corretto, ma è necessario essere consapevoli del fatto che lo dcommit riscrive la cronologia in modo ancora più disastroso di una normale rebase. Ad esempio, aggiunge una riga git-svn-id a ciascun commit che viene inviato a svn. Questo è il motivo per cui la vostra filiale develop appare davanti origin/develop - perché ha 59 impegna tutte contenenti git-svn-id nel messaggio, e nessuno di questi sono presenti in origin/develop. Di conseguenza, dovrai rebase i tuoi rami di git dopo ogni dcommit, o almeno prima del prossimo dcommit. Ciò significa forza che spinge a riscrivere la storia del monte:

git push -f origin develop 

Se tutti gli altri rami sono stati basati su questo monte, avrebbero ora devono essere rapportati su di esso. sezione

i caveat del git-svn man page va più nel dettaglio, così si dovrebbe assolutamente leggerlo.

Le modifiche apportate dal client sul lato svn verranno automaticamente incorporate nel ramo di sviluppo tramite lo git svn rebase e infine raggiungeranno bitbucket tramite lo git push -f precedente.

Se questo tipo di flusso di lavoro non ti soddisfa, potrebbe valere la pena di guardare SubGit. Non l'ho mai provato, ma pretendono di offrire un'integrazione molto meno limitata tra i due SCM.