Suggerimenti per l'unione manuale del codice diviso

Question

Sono abbastanza abituato a usare svn per la ramificazione e la fusione, normalmente questo funziona correttamente. Tuttavia un componente è stato elaborato in due rami e fondamentalmente ha preso il componente in direzioni diverse, quindi l'unione automatica non funzionerà e l'utilizzo oltre il confronto mostra i file come per lo più diversi.

Ho cercato di unire insieme alcuni file, ma i risultati, anche se funzionano, sono abbastanza orribili.

Sono tentato di dire al business che questo non può essere fatto. Posso vedere questo frustrante come hanno modulo + funzione A funzionante e modulo + funzione B funzionante, ma modulo + funzione A + caratteristica B non ha senso come sta. Ad esempio, la caratteristica A può rimuovere qualcosa che era un componente chiave della funzione B.

C'è un modo per provare a unire tale codice? O il modulo + A + B è davvero modulo + C?

Abbiamo visto arrivare, ma la funzione A era necessaria su una scala temporale più breve rispetto alla funzione B che faceva parte di un progetto di lunga durata. Ci sono modi per lavorare per evitare che ciò accada? O sono i loro modi per strutturare il codice in modo che entrambe le caratteristiche si adattino bene insieme?

Answer 1

Quello di cui stai parlando è essenzialmente il tentativo di rebase di uno dei rami. C'è un supporto per questo in some DVCSs ma non sono a conoscenza di alcun supporto per questo genere di cose in SVN.

La soluzione migliore è scegliere uno dei rami (quello che è più importante avere ora) e unirlo alla linea principale che dovrebbe essere abbastanza semplice. Nell'altro ramo dovrai estrarre le modifiche dal trunk e riconciliare le differenze, data la situazione che hai descritto, questo non sarà quasi certamente automatico e potresti dover dedicare del tempo a riflettere su come implementare le funzionalità di questi rami in cima di quello unito alla linea principale, ma questo è il costo dello sviluppo parallelo: le cose cambiano.

Come si evita questo in futuro? Frequent integration.

Se si dispone di due team a cui è assegnata la base di codice A e si occupano di diverse funzionalità per 6 mesi, l'integrazione sarà molto dolorosa poiché ciascuna avrà fatto delle ipotesi su A che l'altra squadra ha cambiato. D'altro canto, con build di integrazione settimanali o mensili, ogni team dovrebbe essere sostanzialmente più consapevole di quali cambiamenti sta facendo l'altro e l'integrazione finale dovrebbe essere molto più semplice.

Questo è il motivo per cui i progetti open source spesso si oppongono a patch enormi, diventano obsoleti sorprendentemente veloci e nessuno ha davvero il tempo di esaminarli correttamente. D'altra parte, se prendi lo stesso contributo e lo suddivido in un numero di piccole parti digeribili che sono indipendenti, il tuo contributo è molto più probabile che sia A) accettato e B) riesaminato correttamente in modo che non risulti un flusso infinito di difetti.

Answer 2

Prendere un singolo file, ad esempio src1.c. È possibile costruire un diagramma diamante descrive l'unione in questo modo:

Original src1.c 
     /  \ 
    /  \ 
    /   \ 
    b1 src1.c  b2 src1.c 
     \   /
     \  /
     \  /
     \ /
     merged src1.c 

Dove b1 significa la prima versione ramo e b2 significa la seconda versione ramo. È possibile confrontare le differenze parallele (ad esempio quella tra la sorgente unita e la versione b2 e b1 e l'originale). Questo può aiutare.