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

Per riformulare la domanda, "Se pensiamo di utilizzare solo DVCS 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 sulla macchina di uno sviluppatore che cambia indipendentemente dal trunk per un giorno è un ramo, anche se nessuno lo chiama. L'unica differenza tra questo e il tuo flusso di lavoro è che stai dando a quei rami un nome permanente anche sul server centrale. Questo non è il tipo di ramificazione di cui parlano Linus e altri.

Per capire il DVCS è necessario un fondamentale cambiamento nel modo di pensare. Devi chiederti cosa faresti con tutte le filiali che vuoi condividere con chi vuoi e solo loro. Ciò include i rami che vengono visti solo da te.

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

La capacità di eseguire commit locali intermedi vale tutto da sola. È qualcosa che devi provare per te stesso.

La velocità ottenuta dall'avere il tuo repository locale vale anche la pena per conto proprio. Sì, il clone iniziale sarà inevitabilmente lento in qualsiasi VCS per un repository di file 60k, ma una volta verificato, il controllo di un nuovo ramo è più veloce di ordini con un DVCS.

Per il tuo caso particolare, non c'è 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 migliori e più mature integrazioni con tutti i principali IDE e strumenti di sviluppo rispetto a hg o git. Date le dimensioni della vostra squadra e il numero di progetti, volete davvero passare il tempo necessario per convertire in un nuovo strumento quando quello esistente funziona correttamente?

Se hai sviluppatori che semplicemente non possono funzionare senza DVCS, indirizzali ai gateway svn per hg o git. Rendere molto chiaro a loro che i loro check-in al repository svn devono conformarsi a qualsiasi procedura e processo utilizzato dal resto del team. Un altro vantaggio di questo approccio è che i veri fanatici DVCS che stanno già utilizzando i gateway senza dirlo 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:

• Una volta clonati i 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 cambio di filiali non richiede l'accesso al server, né i cloni locali.
• Poiché i rami sono solo percorsi divergenti attraverso la cronologia, il tuo repository non è ingombrato con ogni ramo che chiunque ha creato (abbiamo solo davvero rilascia rami in SVN, ma la directory branches ha ancora molte sottodirectory che non sono più rilevanti).
  • In git, una volta che un ramo è stato riunito e il ref eliminato, potresti non sapere mai che era presente anche lì.
  • In Mercurial puoi scegliere se nominare un ramo (nel qual caso è codificato in ogni changeset per sempre) o semplicemente creare un ramo (topologico) senza nome, che si unirà unire in modo silenzioso nella cronologia quando è merge d torna in default ( trunk )
• In SVN, i rami delle filiali sono troppo oscuri per essere utili. In git e hg sono solo par per il corso.
• DVCS 'capisce che lo sviluppo del software è un DAG , cioè quando ti unisci, finisci con un changeset con più i genitori. SVN (almeno la versione che ho usato) in realtà non lo capisce.

Sull'ultimo punto, dici

Conflicts are conflicts, I don't see how any system could get it right most of the time unless it was smart enough to understand the code.

Nel passaggio dall'utilizzo di hg esclusivamente all'utilizzo di svn e poi di gitsvn è stata la mia esperienza che le unioni sono molto più semplici e senza problemi con hg e gitsvn di quanto lo siano con svn . Unisce con svn (almeno la versione che usiamo) produce 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 dal ramo che stai unendo
• il testo dal ramo che stai unendo in

mentre si fonde da un DVCS di solito ti offre una terza opzione, che è

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

Non sottovalutare quanto sia vantaggioso, ti offre il molto contesto migliore per le modifiche rispetto a un semplice diff in due modi.

Tutto sommato, ti suggerisco di fare un tentativo. Con strumenti come gitsvn e hgsubversion , puoi persino provarli con i tuoi repository SVN correnti .

^{Nota, creare il clone in primo luogo è un PItA reale, ma una volta fatto ciò, ottieni la maggior parte della potenza di un DVCS con il tuo CVCS esistente.}

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

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