Qual è la procedura appropriata per l'unione di subversion? [duplicare]

Question

Qual è la procedura appropriata per l'unione di subversion? [duplicare]

#1 da (6 voti)

0

Abbiamo un progetto con alcuni rami di rilascio e un tronco. Ultimamente abbiamo aggiunto correzioni di bug e nuove funzionalità al ramo di rilascio, facendo contemporaneamente lo sviluppo di infrastrutture simultanee sul trunk. Questo ci ha causato alcuni problemi.

Oggi mi è stato detto di unire le modifiche da ramo a tronco, usando HEAD come revisione iniziale / finale. Ha generato una dozzina di conflitti, che ho risolto principalmente accettando la copia funzionante del bagagliaio. Dopo averlo fatto, ho trovato un codice criptato e alcune variabili che non appartenevano alle funzioni.

Oltre a darmi un mal di testa, questo mi fa ripensare al modo in cui mi sono avvicinato alla fusione. È una pratica migliore fondersi da una revisione iniziale RECENTE, a differenza dell'origine del ramo? In realtà l'ho fatto in questo modo per primo, e non ha provocato alcun codice criptato o variabili fuori posto.

branching svn merging

posta ktm5124 17.02.2014 - 23:57

fonte

1 risposta

Leggi altre domande sui tag branching svn merging

Mappatura di 40 numeri interi univoci su 41 e ritorno Consigli su quale tecnologia di archiviazione per un repository di immagini [duplicato]

score 6 · Answer 1

It generated a dozen conflicts, which I resolved mostly by accepting the working copy of the trunk.

Bene, questa sembrava essere una delle cause del problema. Controlla attentamente i conflitti di fusione e assicurati di risolverli mediante la modifica manuale, non da (forse ciecamente?) Accettandoli.

Specialmente con SVN (ma immagino anche con DVCS) quando si fanno cambiamenti strutturali su un ramo (con una natura trasversale, come le funzioni o le classi di rinomina, cambia il file o la struttura della libreria ecc.), è meglio non tenerli cambia da altri rami per un lungo periodo. Meglio unire queste modifiche agli altri rami il più presto possibile.

Quando ti ho capito bene, non potevi farlo qui così facilmente perché non volevi rischiare i cambiamenti strutturali nel tronco per destabilizzare il ramo relase. In questo caso, sarebbe stato probabilmente meglio unire ogni bug fix o nuova funzione dal ramo di release immediatamente al trunk una volta terminata la correzione del bug o la nuova funzionalità. Questo almeno ti permette di gestire i conflitti di fusione uno per uno, ed è più facile anticipare come una correzione di bug dal ramo di rilascio si associa al codice modificato strutturale del trunk quando questo viene fatto immediatamente.