Siamo geek Subversion e vogliamo conoscere i vantaggi di Mercurial [chiuso]

Avendo letto che sono un fanatico di Subversion, perché dovrei considerare o meno Mercurial o Git o qualsiasi altro DVCS .

Ho una domanda di follow-up correlata. Ho letto quella domanda e letto i link e i video consigliati e ne vedo i vantaggi, ma non vedo lo spostamento mentale generale di cui parlano le persone.

Il nostro team è composto da 8-10 sviluppatori che lavorano su un'unica grande base di codice composta da 60 progetti. Usiamo Subversion e abbiamo un trunk principale. Quando uno sviluppatore avvia un nuovo caso Fogbugz creano un ramo svn, fanno il lavoro sul ramo e quando hanno finito si fondono di nuovo con il tronco. Occasionalmente possono rimanere sul ramo per un tempo prolungato e unire il tronco al ramo per raccogliere le modifiche.

Quando ho visto Linus parlare delle persone che creano un ramo e non lo fanno mai più, non siamo affatto noi. Creiamo probabilmente 50-100 filiali alla settimana senza problemi. La più grande sfida è la fusione, ma siamo diventati abbastanza bravi anche in questo. Tendo a fondermi con il caso fogbugz e il check-in piuttosto che l'intera radice del ramo.

Non lavoriamo mai in remoto e non facciamo mai rami fuori dai rami. Se sei l'unico che lavora in quella sezione della base di codice, l'unione al trunk procede senza intoppi. Se qualcun altro ha modificato la stessa sezione di codice, l'unione può diventare disordinata e potrebbe essere necessario eseguire un intervento chirurgico. I conflitti sono conflitti, non vedo come qualsiasi sistema potrebbe farlo bene il più delle volte a meno che se non fosse abbastanza intelligente da capire il codice.

Dopo aver creato un ramo, il seguente checkout di 60k + file richiede del tempo, ma ciò costituirebbe un problema con qualsiasi sistema di controllo del codice sorgente che utilizzeremmo.

C'è qualche vantaggio di qualche DVCS che non stiamo vedendo che ci sarebbe di grande aiuto?

Per riformulare la tua domanda, "Se prevediamo di utilizzare il DVCS solo in modo centralizzato, quali vantaggi ha?" Quando lo chiedi in questo modo, non lo fa. Un ramo per attività è estremamente comune in VCS. Se ci pensate, avere una copia di lavoro locale del codice sorgente sul computer di uno sviluppatore che cambia in modo indipendente dal trunk per un giorno è un ramo, anche se nessuno lo chiama così. L'unica differenza tra questo e il tuo flusso di lavoro è che stai assegnando a quei rami un nome permanente anche sul server centrale. Non è il tipo di ramificazione di cui stanno parlando Linus e altri.

Comprendere il DVCS richiede un cambiamento fondamentale nel pensiero. Devi chiederti cosa faresti con tutti i rami che vuoi che siano condivisi con chi vuoi e solo con loro. Ciò include i rami che sono visti solo da te.

Le possibilità sono infinite. Per un solo esempio, che ne dici di due persone che lavorano su lati opposti di un'interfaccia? Devono condividere il codice tra loro regolarmente, ma non è ancora abbastanza stabile da condividere con tutti. Possono creare un ramo da condividere tra loro, quindi rimetterlo nel repository centrale quando è pronto.

La capacità di eseguire commit locali intermedi vale da sola. È qualcosa che devi solo provare da solo.

Anche la velocità guadagnata con il repository locale vale da sola. Sì, il clone iniziale sarà inevitabilmente lento in qualsiasi VCS per un repository di file da 60k, ma una volta ottenuto ciò, il check-out di un nuovo ramo è più rapido di ordini di grandezza con un DVCS.

Per il tuo caso particolare, non vi è alcun vantaggio nel passaggio a un DVCS. Sei soddisfatto del tuo sistema esistente, fa tutto il necessario, quindi perché cambiare? SVN è ancora un progetto Open Source attivo e ha integrazioni migliori e più mature con tutti i principali IDE e strumenti di sviluppo rispetto a hg o git. Date le dimensioni del tuo team e il numero di progetti, vuoi davvero prenderti il ​​tempo per convertirti in un nuovo strumento quando quello esistente funziona bene?

Se hai sviluppatori che non possono funzionare senza un DVCS, indirizzali verso i gateway svn per hg o git. Rendi molto chiaro a loro che i loro check-in nel repository svn devono conformarsi a qualsiasi procedura e processo vengano utilizzati dal resto del team. Un altro vantaggio di questo approccio è che i veri fanatici DVCS che stanno già utilizzando i gateway senza dirti che ora possono uscire dall'armadio :-).

Mi sembra che tu stia già utilizzando un flusso di lavoro che è molto simile al tipo di flusso di lavoro che molte persone adottano dopo aver iniziato a utilizzare un DVCS.

Dal tuo punto di vista, un DVCS avrà i seguenti vantaggi significativi rispetto a SVN:

• Dopo aver clonato i tuoi repository, molte operazioni possono essere eseguite localmente.
  • Guardando il registro del repository non è necessario toccare il server svn, quindi può essere incredibilmente veloce.
  • Allo stesso modo, il passaggio da una filiale all'altra non richiede l'accesso al server, né i cloni locali.
• Poiché i rami sono solo percorsi divergenti nella storia, il tuo repository non è ingombra di tutti i rami che qualcuno ha creato (in realtà abbiamo solo rami di rilascio in SVN, ma la branchesdirectory ha ancora molte sottodirectory che non sono più rilevanti).
  • In git, una volta che un ramo è stato unito nuovamente e il ref eliminato, potresti non sapere mai che era anche lì.
  • In Mercurial hai la possibilità di nominare un ramo (nel qual caso è codificato in ogni changeset in perpetuità) o semplicemente creare un ramo senza nome (topologico), che si fonderà silenziosamente nella storia quando mergetornerà in default( trunk)
• In SVN, i rami dei rami sono troppo oscuri per essere utili. In gite hgsono solo par per il corso.
• I DVCS comprendono che lo sviluppo del software è un DAG , ovvero quando si uniscono, si finisce con un changeset con più genitori. SVN (almeno la versione che ho usato) non lo capisce davvero.

Su quest'ultimo punto, dici

I conflitti sono conflitti, non vedo come qualsiasi sistema potrebbe farlo bene il più delle volte a meno che non sia abbastanza intelligente da capire il codice.

Nel passare dall'usare hgesclusivamente all'utilizzo svnda solo e poi gitsvnè stata la mia esperienza che le fusioni sono molto più semplici e senza problemi con hge gitsvnrispetto a come sono svn. Le fusioni con svn(almeno la versione che utilizziamo) producono molti più conflitti che devono essere risolti manualmente.

Uno dei motivi per cui le fusioni sono più difficili in SVN è che ti dà solo due opzioni per ogni linea che differisce,

• il testo del ramo in cui ti stai unendo
• il testo del ramo in cui ti stai unendo

mentre le fusioni da un DVCS offrono in genere una terza opzione, ovvero

• il testo dell'antenato comune di entrambi i rami che stai unendo

Non sottovalutare quanto sia benefico questo, ti fornisce un contesto molto migliore per i cambiamenti rispetto a un semplice diff bidirezionale.

Tutto sommato, suggerirei di provarlo. Con strumenti come gitsvne hgsubversion, puoi persino provarli con i tuoi attuali repository SVN .

^{Nota, in primo luogo la creazione del clone è un PItA reale, ma una volta che lo hai fatto, ottieni la maggior parte della potenza di un DVCS con il tuo CVCS esistente.}

C'è un cambiamento importante che ho notato dopo una tale transizione: cambio rami molto più spesso e mi impegno più spesso di quanto potrei mai permettermi con Subversion. Ad esempio, ci sono una serie di minuscoli rami di funzionalità, organizzati in una sequenza, e posso trascorrere mesi aggiungendo bit a ciascuno di essi, riordinandoli facilmente tutti in sequenza in un trunk in continua evoluzione. Riorganizzare l'ordine in cui i rami funzionalità vengono uniti è banale.

Ma, in realtà, in realtà non mi sono allontanato da Subversion. Sto solo usando git come il mio client svn locale.