SVN Workflow - Pollo Prima della Egg - Prima della fusione con V1 V2, ho bisogno di codice da V1 a lavorare su V2

Question

Il nostro team distribuito (3 sviluppatori interni ed esterni 3+ sviluppatori) Si usi SVN per gestire la nostra base di codice per un sito web. Abbiamo un ramo per ogni versione minore (4.1.0, 4.1.1, 4.1.2, ecc ...). Abbiamo un tronco, che si fondono in ogni versione quando facciamo un rilascio e pubblichiamo nel nostro sito.

Un esempio del problema che stiamo avendo è quindi: Una nuova caratteristica è aggiunto, consente di chiamare "capacità di creare un progetto" a 4.1.1. Un'altra caratteristica che dipende su quello 4.1.1 è in programma di andare a 4.1.2, detta "La capacità di aggiungere attività al Projects".

Quindi, il Lunedi, diciamo 4.1.1 è 'chiuso' e deve essere testato. I nostri sviluppatori a distanza di solito inizierà a lavorare su caratteristiche / biglietti per 4.1.2 a questo punto. Durante la settimana testeremo 4.1.1 e correggere eventuali bug e li impegnarsi di nuovo a 4.1.1. Poi, il Venerdì o giù di lì, ci sarà etichettare 4.1.1, si fondono con il tronco, e, infine, si fondono con 4.1.2. Ma, per i 4-5 giorni stiamo testando, 4.1.2 non si ha il codice 4.1.1 che alcune delle nuove funzionalità per 4.1.2 dipendono.

Quindi un dev che è l'aggiunta della "possibilità di aggiungere le attività a progetti" caratteristica, non ha la "capacità di creare un progetto" caratteristica su cui costruire, e ha a che fare alcuni imbrogli di copia dei file per essere in grado di mantenere lavorando su di esso.

Che cosa potrebbe / dovrebbe fare per appianare questo processo?

  

P.S. Mi scuso se questa domanda è stato chiesto prima -. I ha di ricerca, ma non riusciva a trovare quello che sto cercando

Answer 1

Il modo in cui lo facciamo è che tutti lo sviluppo avviene in tronco. Si, anche se solo di impegnarsi a tronco e poi tutte le correzioni necessarie per 4.1.1 get fusa da tronco a il ramo 4.1.1. Il ramo per 4.1.2 viene creato solo quando i test sulla 4.1.2 inizia - una volta che il ramo 4.1.2 è fatto, il lavoro continua in tronco e se sono necessarie eventuali correzioni per 4.1.2, sono fatti in tronco e poi fusa per incorporazione in 4.1.2.

E 'molto raro che mai dovessimo un cambiamento in un ramo che ha bisogno di essere fusi Indietro in tronco (o in qualsiasi altro luogo, in realtà).

Answer 2

Sembra che avete bisogno di un ramo X basato sul tronco, e un ramo Y sulla base di X.

E 'possibile sviluppare una funzione di X, ed iniziare ad avere testato. Nel frattempo, si copia X per un nuovo ramo Y, e sviluppare la seconda caratteristica lì.

Alla fine X viene fusa al tronco e rilasciato. Poi, quando si sta lavorando finito su Y, è possibile unire di nuovo in X per il test, e poi in tronco per il rilascio.

È possibile ripetere questo processo dopo che entrambe le funzioni vengono rilasciati. La prossima volta che finisce una caratteristica in X, e si vuole costruire su di esso, appena fondersi di nuovo in Y.

Se stai facendo questo, è importante ricordare:

• Tu fai unioni normali dal tronco in X, e da X in Y.
• Tu fai unioni reintegrare da X torna in tronco, e da Y di nuovo in X.
• Dopo una fusione reinserirsi nel bagagliaio, è necessario bloccare il commit da essere fusa di nuovo in X.
• Dopo una fusione reintegrarsi nella X, è necessario bloccare il commit da essere fusa di nuovo in Y.
• Tenere note dettagliate su quali funzionalità è in quale ramo; altrimenti questo può diventare confuso rapidamente.

Answer 3

avrei tutti i nuovi commit andare in tronco a meno che non ci sia un motivo per metterli da qualche altra parte. Con la creazione di diversi rami per 4.1.1 e 4.1.2, per esempio, il vostro esempio è meglio avvicinato da fare unioni tra rami, entrambi i quali possono poi essere di nuovo unito al tronco. Che schifo! Ecco mergeinfo inferno, a mio parere.

Ecco alcuni consigli di base dal libro di Subversion:

http://svnbook.red-bean.com /en/1.5/svn.branchmerge.commonpatterns.html

Answer 4

Credo che ci sono diversi modi per farlo.

pratica

Ma io che il tronco è sempre stabile. No non finito - codice instabile dovrebbe andare nel bagagliaio. Se c'è una nuova funzionalità da aggiungere e ci vogliono giorni, forse settimane, poi creo un ramo per esso. Quando si è fatto, e il ramo sembra stabile e testato, si ottiene fuse nel tronco di nuovo, e il ramo viene cancellato.

In questo modo il tronco rimarrà stabile. E il codice sperimentale è sempre ho il ramo.

Se per qualche ragione il cambiamento la mia mente e saltare un progetto fatto a metà, non devo pensare al tronco. Mi è sufficiente eliminare il ramo ....

Answer 5

Un approccio è quello ramo 4.1.2 da 4.1.1 invece che da tronco (e naturalmente 4.1.1 dal tronco).

Si può quindi facilmente unire 4.1.1 in 4.1.2 regolarmente ed essere ancora in grado di fare la parte posteriore fusione banale nel tronco per ogni ramo, quando è il momento di rilascio.