Come gestire due versioni principali usando SVN?

Naviga le tue risposte
6

Nella società in cui lavoro, supportiamo due versioni del software che sviluppiamo. Una versione è disponibile per i clienti e una versione in cui gli sviluppatori stanno sviluppando nuove funzionalità. La versione disponibile per i clienti è anche cambiata dagli sviluppatori, per correggere i bug che i nostri clienti hanno trovato.

Quindi, ad esempio, abbiamo una versione 4.1 disponibile per i clienti e stiamo sviluppando 4.2. Non appena rilasciamo 4.2, 4.1 viene chiuso e iniziamo a sviluppare su 4.3.

Attualmente abbiamo due tronchi, uno per ogni versione che è aperta per lo sviluppo. Ogni volta che viene risolto un bug nella versione rilasciata, dobbiamo unirlo alla nuova versione. Questo è un lavoro extra. Accanto a questo, vorremmo lavorare in anticipo, e avere una versione già finita 'sullo scaffale', e già iniziare su una nuova versione. Il che significherebbe se risolviamo un bug nella versione rilasciata, dovremmo unirlo in tre tronchi!

C'è un modo migliore di strutturare questo ed eventualmente eliminare le unioni duplicate? Stiamo facendo qualcosa di completamente sbagliato?

Grazie in anticipo.

    
posta Geerten 26.10.2011 - 12:13
fonte

2 risposte

4

La solita terminologia qui è che si ha un trunk (il codice che porta a 4.3) e due rami (4.1 e 4.2), anche se il ramo per 4.1 verrà chiuso in base alla descrizione quando viene rilasciato 4.2 (al stesso tempo in cui viene creato il nuovo ramo 4.2).

È possibile evitare la situazione a tre estremità quando si esegue il "lavoro preliminare" in un ramo di funzionalità che non è destinato a essere privo di bug. Cioè, avresti tre estremità aperte: 

trunk (will be 4.2 some day)
branches/4.1
branches/conquer-the-world (a feature planned for 4.3)

e unisci solo correzioni di bug da 4.1 a 4.2. Quando il mondo conquistato è finito (alcuni punti dopo il rilascio di 4.2, presumo), uniscilo nel bagagliaio.

    
risposta data 26.10.2011 - 12:26
fonte
0

Non capisco perché unire le modifiche da un ramo a un altro sia un lavoro extra.

Allo stesso modo di pensare, potresti dire che correggere bug è un lavoro extra e sviluppare codice senza bug in primo luogo.

In altre parole, una unione di correzioni di errori è un lavoro normale ed è inclusa nell'attività di correzione dei bug.

A proposito, non modificare la struttura di controllo della versione: è perfettamente OK.

    
risposta data 26.10.2011 - 12:24
fonte

Leggi altre domande sui tag

GPL "Integrabile" ma non "integrato" È possibile applicare prontamente le metriche di contenimento dei contatori a livello organizzativo quando esiste una struttura coerente del processo organizzativo?