2010-03-29 19 views
5

Il mio team utilizza SVN per il controllo del codice sorgente. Recentemente, ho lavorato su un ramo con fusioni occasionali dal trunk ed è stata un'esperienza abbastanza fastidiosa (vedi Joel Spolsky "Subversion Story #1"), quindi ho cercato modi alternativi per gestire i rami e la fusione. Dato che un repository SVN centralizzato non è negoziabile, quello che mi piacerebbe è un set di strumenti che soddisfano le seguenti condizioni.Strumenti per il mantenimento di rami in SVN

  1. storia Revisione totale deve essere conservato in SVN sia per tronco e rami.

  2. L'unione in entrambe le direzioni (e potenzialmente incrociate) dovrebbe essere relativamente indolore.

  3. La cronologia di unione deve essere memorizzata in SVN nella massima misura possibile.

Ho guardato sia git-svn e bzr-svn e nessuno dei due sembra essere all'altezza del compito — in fondo, data la storia di revisione possono esportare dal repository SVN, possono non sembrano fare di meglio di una la gestione del lavoro si fonde rispetto a SVN. Ad esempio, dopo la clonazione del repository con git, la cronologia delle revisioni per il mio ramo mostra il ramo originale fuori dal trunk, ma git non "vede" alcuno dello SVN temporaneo si fonde mentre "nativo" si unisce — la cronologia delle revisioni è una lunga linea. Di conseguenza, qualsiasi tentativo di unire da trunk in git produce altrettanti conflitti di un'unione SVN. (Inoltre, il git-svn documentation mette in guardia contro l'uso esplicitamente git di fondere tra i rami.)

Esiste un modo per regolare mio flusso di lavoro per rendere git soddisfare i requisiti di cui sopra? Forse ho solo bisogno di suggerimenti o trucchi (o di uno strumento di fusione separato?) Per aiutare SVN ad essere più bravo a fondersi con le filiali?

+0

Sembra proprio che tu debba solo convincere il tuo team a usare git. : P – Amber

+2

Penso, sfortunatamente, che stai affrontando il fatto che SVN è semplicemente limitato nella sua capacità di unire rami - e finché il repository centrale è un repo SVN, è difficile per qualsiasi quantità di magia git a salvarti. Sono certamente curioso di vedere se ci sono dei buoni kludges funzionanti! – Cascabel

risposta

2

Senza avere una risposta pura SVN, vorrei fare riferimento alla domanda SO "How to fool git-svn to recognize merges made with svn?"

ho consigliato di fare quelle git si fonde in un ramo speciale, ma una soluzione più semplice sarebbe quella di registrare (almeno il più recente) SVN si fonde nel git-svn repo clonato con git grafts file, al fine di trasformare:

o-...-A---o---D--- unstable 
/  
X-----B---M---o---o--- stable 

in:

o-...-A---o---D--- unstable 
/  \ 
X-----B---M---o---o--- stable 

, facilitando il processo di git merge, prima di dcommit e inviandolo a SVN.

+0

Il file di grafts sembra essere di grande aiuto, grazie! Sembra essere sufficiente aggiungere un innesto solo per l'ultima unione dal tronco. È giusto? Raccomanderesti 'git merge --quash' per nascondere il vero DAG da SVN? Inoltre, mi chiedo quanto bene soddisfi questo # 3 (anche se onestamente non sono sicuro di quanto sia importante avere un mergeinfo per SVN)? –

+0

@Chris: dopo aver letto http://stackoverflow.com/questions/2427238/in-git-what-is-the-difference-between-merge-squash-and-rebase, non credo che un 'merge squash' è necessario qui. SVN può usare il DAG per registrare alcuni metadati 'mergeinfo' durante' dcommit'. – VonC

Problemi correlati