Controllo versione TFS 2012 vs Mercurial

Question

Sto valutando un sistema di controllo versione per il nostro team (da 1 a 2 sviluppatori) e mi chiedo come il controllo della versione TFS 2012 sia paragonabile a Mercurial in termini di fusione e ramificazione. Non abbiamo una grande squadra e potrebbe essere solo io e forse un altro sviluppatore, quindi potremmo non aver bisogno di solide funzionalità di ramificazione/fusione offerte da un DVCS. Non sono stato in grado di trovare molte informazioni sul controllo della versione di TFS 2012 in termini di capacità. Qualcuno può indicarmi una guida o evidenziare alcune funzionalità? Si prega di notare che abbiamo accesso solo alla versione standalone di TFS 2012 su VS versione professionale.

Grazie

Answer 1

Prefazione:

Non sto correlati in alcun modo con TFS e mai usata

Viso:

nuovi 'tfs2012' domanda, a almeno alcuni (How to set up TFS to cater multiple projects to multiple clients, TFS 2012: Correllating binaries to builds and source code, TFS 2012 Disable Multiple Check-out not working), dimostraci problemi, che non considero mai come domanda in Mercurial (con alcuni strumenti esterni aggiunti a volte). Ma puoi capire anche che TFS è posizionato come strumento ALM completo, non come puro SCM, che è Mercurial.

"Team Foundation Server is the Lotus Notes of version control tools" da James McKay non è l'articolo più recente (febbraio 2011), ma almeno alcune affermazioni sono ancora valide, penso.

quantità di ramificazione-fusione sarà correlata al team-size solo in parte, dipende principalmente dalla stile di sviluppo, le abitudini di sviluppatori

Answer 2

Se ci si trova in una piccola squadra, andare con Mercurial senza dubbio.

Mercurial è leggero e flessibile per quanto riguarda il flusso di lavoro di sviluppo specifico che verrà utilizzato. Si adatta meglio ai team più piccoli, infatti, si adatta anche a un solo dev perché non impone alcun sovraccarico amministrativo.

Sulla necessità di unire, non è proprio una funzionalità avanzata come si sottintende: è una caratteristica molto fondamentale che la maggior parte (tutti?) VCS non distribuiti non riescono a ottenere correttamente. Potresti non averne bisogno ora, ma se mai lo farai, ce l'avrai proprio in Mercurial e funzionerà.

Answer 3

Le precedenti "risposte" sono un po 'strane. La ramificazione e l'unione in TFS 2012 funziona esattamente come ci si aspetterebbe, con una GUI e un'implementazione della riga di comando. Ecco un buon documento che copre l'argomento abbastanza completamente:

ALM Ranger Guideaggiornato

Answer 4

ramificazione Mercurial differisce da TFS in un modo critico. Mentre TFS memorizza le tue filiali in una parte diversa dello spazio file, Mercurial le memorizza nella cronologia stessa. Questo riduce enormemente l'attrito coinvolto nella ramificazione e fusione. Significa, ad esempio:

• I rami vengono creati implicitamente, semplicemente aggiornando a una revisione diversa dall'ultima, quindi impegnandosi in precedenza.
• Anche i rami vengono chiusi implicitamente, ancora una volta, semplicemente mediante l'unione.
• I rami possono essere riaperti in modo implicito, allo stesso modo in cui li si crea in primo luogo.
• Mercurial consente di passare da un ramo all'altro facilmente. Non è necessario impostare mapping di aree di lavoro separati e non è necessario passare da una directory a un'altra.
• I rami possono essere anonimi.
• Considerando che TFS ha "fusioni senza fondamento" (che in pratica significa che ha enormi problemi con rami che non sono in una relazione diretta genitore/figlio), non c'è nulla di simile in Mercurial. È sempre possibile trovare un'origine comune tra due revisioni, indipendentemente dalla distanza tra i rispettivi rami divergenti.
• La vista grafica delle filiali in TortoiseHg è integrata con la cronologia del progetto, rendendo molto più semplice la comprensione di come funzionano effettivamente le diramazioni e le fusioni.

Esistono numerosi vantaggi di ramificazione e unione che si applicano anche a team di piccole dimensioni oa sviluppatori singoli. Un esempio è la possibilità di correggere i bug sul sistema di produzione anche quando si hanno altre funzionalità in fase di sviluppo. Un altro esempio è lo sviluppo esplorativo o sperimentale: se un approccio non funziona, è possibile tornare indietro facilmente e provare un secondo approccio diverso, mantenendo comunque l'approccio originale nel caso in cui sia necessario fare riferimento ad esso.