2011-01-10 20 views
6

La nostra azienda utilizza (e supporta!) SVN, ma io tendo ad usare git. Quello che voglio provare è avere un repository git - uno per progetto, gli sviluppatori del progetto saranno in grado di estrarre da questo repository (e naturalmente tirare l'uno dall'altro, se lo vorranno). Ma voglio ancora spingere tutte le modifiche al SVN, perché SVN viene gestito dal nostro supporto tecnico.git svn dcommit senza rebasing

stavo testando lo scenario con i seguenti repository:

  1. SVN-repository - questa è mantenuta dalla nostra azienda e il nostro team dovrebbe spingere tutte le modifiche lì a un certo punto
  2. git-svn-clone - questo è git repository clonato da SVN sopra - tutti gli sviluppatori di progetto dovrebbero spingere i loro commit qui
  3. git-dev-clone - questo è il repository git dello sviluppatore.

L'unico problema con l'utilizzo diretto di 'git svn rebase' e 'git svn dcommit' che ho notato è che dopo ogni spinta dal repository git dello sviluppatore al repository-clone git-svn devo rebase repository dello sviluppatore non appena le modifiche saranno propagate a SVN e rebased. Quello che voglio ottenere è di evitare di ribasare dopo ogni spinta.

Si noti che presumo che ogni sviluppatore di progetto utilizzerà solo repository git e nessuno utilizzerà SVN direttamente.

Sono stato in grado di ottenere questo comportamento manualmente controllando ogni git commit uno alla volta nel repository 'git-svn-clone' dopo l'invio e l'invio di tali modifiche al SVN utilizzando il client SVN. Credo che 'git svn dcommit' faccia lo stesso, ma si sincronizza anche da SVN e cambia gli identificatori di SHA che mi obbligano a rebase.

P.S .: --no-rebase opzione per git svn dcommit non ha aiutato fin dopo il primo commit propagato a SVN git svn dcommit non mi ha permesso di commettere ulteriori modifiche al SVN fino a quando quella precedente del ribasamento. Ho provato questo comportamento una volta e probabilmente potrei trascurare qualcosa.

risposta

7

In realtà è anche peggio di così ... dcommit cambia i commit caricati in SVN (aggiungendo le linee git-svn-id, cambiando le informazioni di authorship, ecc.) Anche se hai hackerato dcommit per non provare a rebase.

Fondamentalmente, git-svn non è in grado di eseguire di nuovo la sincronizzazione da SVN senza eseguire rebases. È stato elaborato un nuovo git < -> interfaccia SVN che potrebbe rimuovere questa limitazione, ma non è ancora pronto.

Ho paura che se si desidera mantenere la sincronizzazione con il repository SVN, lo scenario non funzionerà senza rebasing in questo momento.

+0

Per quanto riguarda il fatto di non essere in grado di "sincronizzare di nuovo da SVN mai senza fare rebases". Sto bene senza sincronizzazione di ritorno da SVN, tutto ciò di cui ho bisogno è sincronizzare TO SVN. – Snowbear

+0

In questo caso dovrai ancora eseguire una serie di hackery su git-svn, perché usa le informazioni negli oggetti commit per un sacco di cose e quindi le riscrive durante il dcommitting. –

+0

Grazie, Jan. Ho anche capito che anche risolvere questo problema non mi permette di fare ciò che voglio in maniera accettabile a causa di altri problemi. Probabilmente inizierei a cercare di installare Git nella nostra azienda, quindi sarà disponibile senza SVN. Grazie comunque per la tua risposta. – Snowbear

Problemi correlati