Qual è il modo migliore per gestire più "stream" simultanei di sviluppo nel controllo della versione?

Come sospetti, questo è un chiaro caso d'uso per un VCS. Ma ... non tutti i VCS gestiscono la fusione molto bene. Non riesco a parlare con TFS, ma il tracciamento della fusione di Subversion lascia molto a desiderare. I DVCS come Hg e Git gestiscono la fusione molto meglio. Le fusioni non sono sempre semplici, e ho scoperto che molti sviluppatori hanno problemi con fusioni anche relativamente semplici. Se hai una o due persone che sono disposte a fare del bene con le fusioni, questo ti aiuterà.

Ti consiglio di testare la fusione di TFS con qualche piccola applicazione di esempio, in cui rinomini i file e modifichi lo stesso file in un ramo diverso, unisci più volte da un ramo all'altro, ecc.

L'approccio a più versioni in un albero che descrivi sembra un vero incubo quando ti avvicini alla tua prima versione e ti rendi conto che dovrai eseguire qualche modifica o un cambiamento significativo dell'interfaccia per la tua seconda versione. Non vorrai apportare modifiche drastiche alla base di codice vicino a una versione, ma non vorrai ritardare la modifica per il lavoro necessario per la seconda versione. Se non stai ramificando, sarà difficile renderlo disponibile nello stesso albero dei file.

Sono d'accordo con il retracle e per aggiungere alcune esperienze TFS. L'unione può essere dolorosa, quindi è necessario farlo il più spesso possibile per ridurre il numero di conflitti simultanei. Non salvarlo finché uno dei tuoi stream è quasi completo o avrai un incubo a portata di mano.

Leggi le istruzioni per i rangers ALM e dovresti essere impostato. Si spera che tu stia usando TFS 2010 poiché la fusione è significativamente migliore rispetto alle versioni precedenti.

Potresti anche trovare questo blog interessante. Brian Harry mette a confronto l'esperienza di fusione tra git, TFS 2010 e TFS 11

Come indicato nelle altre risposte, questo è il caso d'uso classico per la ramificazione e l'amp; fusione, quindi consiglio di provare anche questo.

Tuttavia, questa non è l'unica soluzione. Un'alternativa potrebbe essere l'uso di "flag di funzionalità":

In sostanza, tutte le modifiche che non dovrebbero essere attive (ancora) sono racchiuse in un blocco if , quindi possono essere attivate / disattivate dalla configurazione. Qualcosa come: se

($cfg.enable_unicorn_polo) {
    // do something new and amazing here.
}
else {
    // do the current boring stuff.
}

Questo ha vantaggi e svantaggi rispetto alla branching & mergin solution, ma è bene saperlo.

Questo è apparentemente come Flickr fa il loro sviluppo. Fonte:

link

Se Branching non funziona, considera l'integrazione continua su build-server come Cruise Control. Ogni build sul server di build dovrebbe eseguire tutti i test di unità e di integrazione (e possibilmente altri controlli come consistenza del database, copertura del codice ecc.). Se una build non ha successo, la persona / le persone che hanno effettuato il check-in dovrebbe immediatamente risolvere il problema - nessun altro compito dovrebbe superare il build build fixing oltre alla morte o al parto (considerare di ritardare entrambi, se una build è rotta). I check-in effettuati da terzi non dovrebbero essere consentiti prima che la correzione venga verificata e verificata.

Nota: l'integrazione continua e continua potrebbe funzionare fianco a fianco.