it-swarm.it

Sono un fanatico di Subversion, perché dovrei considerare o meno Mercurial o Git o qualsiasi altro DVCS?

Cerco di comprendere i vantaggi del sistema di controllo della versione distribuita (DVCS).

Ho trovato Subversion Re-education e questo articolo di Martin Fowler molto utile.

Mercurial e altri DVCS promuovono un nuovo modo di lavorare sul codice con changeset e commit locali. Impedisce di fondere l'inferno e altri problemi di collaborazione

Non siamo interessati da questo mentre pratico integrazione continua e lavorare da soli in una filiale privata non è un'opzione, a meno che non stiamo sperimentando. Usiamo un ramo per ogni versione principale, in cui correggiamo i bug uniti dal trunk.

Mercurial ti consente di avere tenenti

Capisco che questo possa essere utile per progetti molto grandi come Linux, ma non vedo il valore in team piccoli e altamente collaborativi (da 5 a 7 persone).

Mercurial è più veloce, occupa meno spazio su disco e la copia locale completa consente operazioni più veloci di registro e diff.

Nemmeno questo mi preoccupa, dato che non ho notato problemi di velocità o spazio con SVN anche con progetti molto grandi su cui sto lavorando.

Sto cercando le tue esperienze personali e/o opinioni da ex geek SVN. Soprattutto per quanto riguarda il concetto changeset e il miglioramento generale delle prestazioni misurati.

AGGIORNAMENTO (12 gennaio) : ora sono convinto che valga la pena provare.

AGGIORNAMENTO (12 giugno) : Ho baciato Mercurial e mi è piaciuto. Il gusto del suo locale ciliegio si impegna. Ho baciato Mercurial solo per provarlo. Spero che al mio server SVN non dispiaccia. Sembrava così sbagliato. Sembrava così giusto. Non voglio dire che sono innamorato stasera .

AGGIORNAMENTO FINALE (29 luglio) : ho avuto il privilegio di rivedere Eric Sink Il prossimo libro chiamato Versione Controllo per esempio . Ha finito per convincermi. Vado per Mercurial.

304
user2567

Nota: vedi "EDIT" per la risposta alla domanda corrente


Prima di tutto, leggi Subversion Re-education di Joel Spolsky. Penso che la maggior parte delle tue domande avranno una risposta lì.

Un'altra raccomandazione, il discorso di Linus Torvalds su Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Quest'altro potrebbe anche rispondere alla maggior parte delle tue domande ed è piuttosto divertente.

A proposito, qualcosa che trovo abbastanza divertente: persino Brian Fitzpatrick e Ben Collins-Sussman, due dei creatori originali di Subversion hanno detto in un discorso su Google "scusatemi" riferendosi a Subversion che è inferiore a Mercurial (e DVCS in generale).

Ora, IMO e in generale, le dinamiche di gruppo si sviluppano in modo più naturale con qualsiasi DVCS e un vantaggio eccezionale è che puoi impegnarti offline perché implica le seguenti cose:

  • Non dipendi da un server e una connessione, il che significa tempi più rapidi.
  • Non essere schiavo di luoghi in cui è possibile ottenere l'accesso a Internet (o una VPN) solo per essere in grado di impegnarsi.
  • Ognuno ha un backup di tutto (file, cronologia), non solo del server. Significa che chiunque può diventare il server .
  • Puoi impegnarti compulsivamente se è necessario senza incasinare il codice degli altri . Gli commit sono locali. Non ti calpesti le dita dei piedi mentre commetti. Non rompere le build o gli ambienti degli altri semplicemente impegnandosi.
  • Le persone senza "commit access" possono eseguire il commit (poiché il commit in un DVCS non implica il caricamento di codice), abbassando la barriera per i contributi, puoi decidere di apportare le loro modifiche o meno come integratore.
  • Può rafforzare la comunicazione naturale poiché un DVCS lo rende essenziale ... In Subversion ciò che hai invece sono razze commesse, che forzano la comunicazione, ma ostacolando il tuo lavoro.
  • I collaboratori possono unirsi e gestire la propria fusione, il che significa alla fine meno lavoro per gli integratori.
  • I collaboratori possono avere le proprie filiali senza influire su quelle degli altri (ma essere in grado di condividerle se necessario).

Sui tuoi punti:

  • La fusione dell'inferno non esiste in DVCSland; non ha bisogno di essere gestito. Vedi il prossimo punto .
  • Nei DVCS, ognuno rappresenta un "ramo", il che significa che ci sono fusioni ogni volta che vengono apportate modifiche. I rami nominati sono un'altra cosa.
  • Se lo desideri, puoi continuare a utilizzare l'integrazione continua. Non è necessario l'IMHO, perché aggiungere complessità? Basta continuare i test come parte della propria cultura/politica.
  • Mercurial è più veloce in alcune cose, git è più veloce in altre cose. Non proprio ai DVCS in generale, ma alle loro particolari implementazioni AFAIK.
  • Tutti avranno sempre il progetto completo, non solo tu. La cosa distribuita ha a che fare con il fatto che puoi impegnarti/aggiornare localmente, la condivisione/presa dall'esterno del tuo computer si chiama push/pull.
  • Ancora una volta, leggi la rieducazione di Subversion. I DVCS sono più facili e più naturali, ma sono diversi, non provare a pensare che cvs/svn === sia la base di tutto il controllo delle versioni.

Stavo contribuendo con alcuni documenti al progetto Joomla per aiutare a predicare una migrazione ai DVCS e qui Ho realizzato alcuni diagrammi per illustrare centralizzato vs distribuito.

centralizzata

alt text

Distribuito nella pratica generale

alt text

Distribuito al massimo

alt text

Vedi nel diagramma c'è ancora un "repository centralizzato", e questo è uno degli argomenti preferiti dai fan della versione centralizzata: "sei ancora centralizzato", e no, non lo sei, dal momento che il repository "centralizzato" è solo un repository tutti concordano (ad es. un repository github ufficiale), ma questo può cambiare in qualsiasi momento.

Ora, questo è il tipico flusso di lavoro per progetti open source (ad esempio un progetto con una collaborazione massiccia) che utilizzano DVCS:

alt text

Bitbucket.org è in qualche modo un equivalente github per Mercurial, sappi che hanno repository privati ​​illimitati con spazio illimitato, se la tua squadra è più piccola di cinque puoi usarlo gratuitamente.

Il modo migliore per convincerti di usare un DVCS è provare un DVCS, ogni sviluppatore DVCS esperto che ha usato svn/cvs ti dirà che ne vale la pena e che non sanno come sono sopravvissuti per tutto il loro tempo senza di esso.


[~ # ~] edit [~ # ~] : per rispondere alla tua seconda modifica posso solo ribadire che con un DVCS hai un flusso di lavoro diverso, I ti consiglio di non cercare motivi per non provarlo a causa di best practice, sembra che quando le persone sostengono che OOP non è necessario perché possono aggirare schemi di progettazione complessi con ciò che fanno sempre con il paradigma XYZ; puoi comunque trarne vantaggio.

Provalo, vedrai come lavorare in "una filiale privata" è in realtà un'opzione migliore. Uno dei motivi per cui posso dire perché l'ultimo è vero è perché perdi la paura di impegnarti , permettendoti di impegnarti in qualsiasi momento ritieni opportuno e funzionante un modo più naturale.

Per quanto riguarda "fusione dell'inferno", dici "a meno che non stiamo sperimentando", dico "anche se stai sperimentando + mantenendo + + lavorando contemporaneamente su v2.0 rinnovato ". Come dicevo prima, la fusione dell'inferno non esiste, perché:

  • Ogni volta che ti impegni generi una filiale senza nome e ogni volta che i tuoi cambiamenti incontrano quelli di altre persone, si verifica una fusione naturale.
  • Poiché i DVCS raccolgono più metadati per ogni commit, si verificano meno conflitti durante l'unione ... quindi potresti persino chiamarlo "unione intelligente".
  • Quando ti imbatti in conflitti di unione, questo è ciò che puoi usare:

alt text

Inoltre, le dimensioni del progetto non contano, quando sono passato da Subversion in realtà stavo già vedendo i benefici mentre lavoravo da solo, tutto sembrava giusto. I changeset (non esattamente una revisione, ma un set specifico di modifiche per file specifici che includi un commit, isolato dallo stato della base di codice) ti consentono visualizza esattamente cosa intendevi facendo quello che stavi facendo a un gruppo specifico di file, non all'intera base di codice.

Per quanto riguarda il funzionamento dei changeset e l'aumento delle prestazioni. Proverò ad illustrarlo con un esempio che mi piace dare: il passaggio del progetto mootools da svn illustrato nel loro grafico della rete github .

Prima

alt text

Dopo

alt text

Quello che vedi è che gli sviluppatori sono in grado di concentrarsi sul proprio lavoro mentre commettono, senza il timore di violare il codice degli altri, si preoccupano di rompere il codice degli altri dopo aver premuto/tirato (DVCS: prima commetti, poi Push/pull, quindi aggiorna ) ma poiché la fusione qui è più intelligente, spesso non lo fanno mai ... anche quando c'è un conflitto di unione (che è raro), passi solo 5 minuti o meno a risolverlo.

La mia raccomandazione è di cercare qualcuno che sappia usare Mercurial/git e di dirgli di spiegarglielo direttamente. Trascorrendo circa mezz'ora con alcuni amici nella riga di comando mentre usavo Mercurial con i nostri desktop e account bitbucket che mostravano loro come unirsi, persino fabbricando conflitti per loro per vedere come risolvere in un ridicolo ammontare di tempo, sono stato in grado di mostrare loro il vero potere di un DVCS.

Infine, ti consiglio di usare Mercurial + bitbucket invece di git + github se lavori con Windows. Mercurial è anche un po 'più semplice, ma git è più potente per una gestione dei repository più complessa (ad es. git rebase ).

Alcune letture consigliate aggiuntive:

333
dukeofgaming

Quello che stai dicendo è tra l'altro che se rimani essenzialmente su un singolo ramo, non hai bisogno del controllo della versione distribuita.

Questo è vero, ma non è una limitazione inutilmente forte al tuo modo di lavorare e uno che non si adatta bene a più posizioni in più fusi orari? Dove dovrebbe trovarsi il server centrale Subversion e tutti dovrebbero andare a casa se quel server per qualche motivo non funziona?

I DVCS sono Subversion, ciò che Bittorrent è ftp

(tecnicamente, non legalmente). Forse se ci pensi sopra, potresti capire perché è un grande balzo in avanti?

Per me, il nostro passaggio a git, è risultato immediatamente

  • I nostri backup sono più facili da eseguire (basta "git remote update" e il gioco è fatto)
  • È più facile eseguire piccoli passaggi quando si lavora senza accesso al repository centrale. Devi solo lavorare e sincronizzarti quando torni alla rete che ospita il repository centrale.
  • Build Hudson più veloci. Molto, molto più veloce da usare git pull rispetto all'aggiornamento.

Quindi, considera perché bittorrent è meglio di ftp e riconsidera la tua posizione :)


Nota: è stato menzionato che ci sono casi d'uso in cui ftp è più veloce e bittorrent. Questo è vero allo stesso modo in cui il file di backup gestito dall'editor preferito è più rapido da utilizzare rispetto a un sistema di controllo della versione.

59
user1249

La caratteristica killer dei sistemi di controllo della versione distribuita è la parte distribuita. Non si esegue il checkout di una "copia di lavoro" dal repository, si clona un'intera copia del repository. Questo è enorme, in quanto offre potenti vantaggi:

  • Puoi usufruire dei vantaggi del controllo versione, anche quando non hai accesso a Internet come ... Questo è sfortunatamente abusato e sovrascritto come una ragione per cui DVCS è fantastico --- non è solo un punto di forza in quanto molti di noi si trovano a programmare senza accesso a Internet tutte le volte che iniziano a piovere rane.

  • La vera ragione per cui un repository locale è killer è che hai il controllo totale sulla cronologia del commit prima che venga trasferita al repository principale.

Mai corretto un bug e ho finito con qualcosa del tipo:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

E così via. La storia del genere è disordinata --- c'era davvero solo una correzione, ma ora l'implementazione è diffusa tra molti commit che contengono artefatti indesiderati come l'aggiunta e la rimozione di istruzioni di debug. Con un sistema come SVN, l'alternativa è non eseguire il commit (!!!) fino a quando tutto funziona per mantenere pulita la cronologia. Anche allora, gli errori scivolano via e la Legge di Murphy è in attesa di brutalizzarti quando quantità significative di lavoro non sono protette dal controllo della versione.

Avere un clone locale del repository, di tua proprietà , risolve questo problema in quanto puoi riscrivere la cronologia eseguendo continuamente il "fix it" e "oops "si impegna nel commit" bug fix ". Alla fine della giornata, un commit pulito viene inviato al repository principale che assomiglia a:

r321 Fixed annoying bug.

Qual è il modo in cui dovrebbe essere.

La capacità di riscrivere la storia è ancora più potente se combinata con il modello di ramificazione. Uno sviluppatore può fare un lavoro completamente isolato all'interno di un ramo e quindi quando è il momento di portare quel ramo nel trunk hai tutte le opzioni interessanti:

  • Effettua una semplice fusione Vanilla . Porta tutto in verruche e tutto.

  • Esegui un rebase . Ti consente di ordinare la cronologia delle filiali, riorganizzare l'ordine dei commit, eliminare i commit, unire i commit insieme, riscrivere i messaggi di commit --- persino modificare i commit o aggiungerne di nuovi! n sistema di controllo di versione distribuito ha un profondo supporto per la revisione del codice.

Una volta appreso come i repository locali mi permettessero di modificare la mia storia per motivi di sanità mentale dei miei colleghi programmatori e del mio sé futuro, ho appeso per sempre SVN. Il mio client Subversion ora è git svn.

Consentire a sviluppatori e manager di esercitare il controllo editoriale sui risultati della cronologia del commit in una migliore cronologia del progetto e avere una cronologia pulita con cui lavorare aiuta davvero la mia produttività come programmatore. Se tutto questo parlare di "riscrittura della storia" ti spaventa, non preoccuparti perché questo è ciò che serve per i repository centrali, pubblici o principali. La storia può (e dovrebbe!) Essere riscritta fino al punto in cui qualcuno la porta in un ramo in un deposito da cui altre persone stanno attingendo. A quel punto la storia dovrebbe essere trattata come se fosse scolpita su una tavoletta di pietra.

46
Sharpie

la risposta di dukofgamings è probabilmente la migliore possibile, ma voglio affrontarla da un'altra direzione.

Supponiamo che ciò che dici sia assolutamente vero e che applicando le buone pratiche puoi evitare i problemi che DVCS è stato progettato per risolvere. Questo significa che un DVCS non ti offrirebbe alcun vantaggio? Persone puzza alle seguenti migliori pratiche. Le persone sono andando a sbagliare. Quindi perché dovresti evitare il software progettato per risolvere una serie di problemi, scegliendo invece di affidarti alle persone per fare qualcosa che puoi prevedere in anticipo che non faranno?

18
philosodad

Sì, fa male quando devi unire grandi commit in Subversion. Ma questa è anche un'ottima esperienza di apprendimento, che ti fa fare tutto il possibile per evitare la fusione di conflitti. In altre parole, impari a fai il check-in spesso . L'integrazione precoce è un'ottima cosa per qualsiasi progetto condiviso. Finché lo fanno tutti, l'utilizzo di Subversion non dovrebbe essere un grosso problema.

Git, ad esempio, era progettato per il lavoro distribuito e incoraggia le persone a lavorare sui propri progetti e creare le proprie forcelle per una (eventuale) fusione in un secondo momento. Non era non specificamente progettato per l'integrazione continua in un "team piccolo e altamente collaborativo" che è ciò che l'OP chiede. È piuttosto il contrario, vieni a pensarci. Non avrai alcuna utilità per le sue fantasiose funzioni distribuite se tutto ciò che stai facendo è seduto nella stessa stanza, lavorando insieme sullo stesso codice.

Quindi, per un team co-localizzato che utilizza CI, non penso davvero che importi molto se usi un sistema distribuito o meno. Si riduce a una questione di gusto ed esperienza.

9
Martin Wickman

Perché dovresti sfidare continuamente le tue conoscenze. Sei appassionato di Subversion, e posso capire perché l'ho usato per molti anni, e ne sono stato molto contento, ma ciò non significa che sia ancora lo strumento più adatto a te.

Credo che quando ho iniziato a usarlo, era la scelta migliore al momento. Ma altri strumenti emergono nel tempo e ora preferisco git, anche per i miei progetti di tempo libero.

E Subversion ha alcune carenze. Per esempio. se si rinomina una directory su disco, non viene rinominata nel repository. Lo spostamento di file non è supportato, facendo spostare un file in un'operazione di copia/eliminazione, apportando modifiche quando i file sono stati spostati/rinominati difficili. E il monitoraggio delle fusioni non è realmente integrato nel sistema, ma implementato sotto forma di soluzione alternativa.

Git risolve questi problemi (incluso il rilevamento automatico se un file è stato spostato, non è nemmeno necessario dirlo che è un dato di fatto).

D'altra parte git non ti permette di diramare su singoli livelli di directory come fa Subversion.

Quindi la mia risposta è che dovresti studiare alternative, vedere se si adatta meglio alle tue esigenze rispetto a ciò che conosci, e quindi decidere.

8
Pete

Per quanto riguarda le prestazioni, Git o qualsiasi altro DVCS ha un grande vantaggio rispetto a SVN quando si deve passare da un ramo all'altro o passare da una revisione all'altra. Poiché tutto è archiviato localmente, le cose sono molto più veloci rispetto a SVN.

Questo da solo potrebbe farmi cambiare!

7
Xavier Nodet

Invece, basandosi sull'idea che "applicando le migliori pratiche non è necessario un DVCS", perché non considerare che il flusso di lavoro SVN è un flusso di lavoro, con un insieme di migliori pratiche e il flusso di lavoro GIT/Hg è un flusso di lavoro diverso, con un insieme diverso di migliori pratiche.

git bisect (e tutte le sue implicazioni sul tuo repository principale)

In Git, un principio molto importante è che puoi trovare bug usando git bisect. Per fare questo, prendi l'ultima versione che hai eseguito che era noto funzionare, e la prima versione che hai eseguito che era noto per fallire, ed esegui (con l'aiuto di Git) una ricerca binaria per capire quale commit ha causato il bug. Per fare ciò, l'intera cronologia delle revisioni deve essere relativamente libera da altri bug che possono interferire con la ricerca dei bug (che ci crediate o no, in realtà funziona abbastanza bene nella pratica, e gli sviluppatori del kernel Linux lo fanno sempre).

Realizzare git bisect capacità, sviluppi una nuova funzionalità da sola ramo di funzionalità , la riformuli e ripulisci la cronologia (quindi non hai alcun non noto revisioni di lavoro nella tua cronologia - solo un mucchio di modifiche che ti portano a risolvere parzialmente il problema), e poi quando la funzione è terminata, la fondi nel ramo principale con la cronologia di lavoro.

Inoltre, per far funzionare tutto questo, devi avere una disciplina su quale versione del ramo principale inizi la tua funzione. Non puoi semplicemente iniziare dallo stato corrente del ramo master perché potrebbe avere bug non correlati - quindi il consiglio nella comunità del kernel è di iniziare a lavorare dall'ultima versione stabile del kernel (per grandi funzionalità ) o per iniziare a lavorare dall'ultimo candidato alla versione con tag.

Puoi anche eseguire il backup dei tuoi progressi intermedi spingendo nel frattempo il ramo della funzione su un server e puoi spingere il ramo della funzione su un server per condividerlo con qualcun altro ed ottenere un feedback, prima che la funzione sia completa, prima che tu debba trasforma il codice in una caratteristica permanente del codebase che tutti * nel tuo progetto devono affrontare.

La pagina man gitworkflows è una buona introduzione ai flussi di lavoro per cui Git è progettato. Inoltre Perché Git è migliore di X discute i flussi di lavoro di git.

Grandi progetti distribuiti

Perché abbiamo bisogno di luogotenenti in un team altamente collaborativo con buone pratiche e buone abitudini di progettazione?

Perché in progetti come Linux, ci sono così tante persone coinvolte che sono così geograficamente distribuite che è difficile collaborare come un piccolo team che condivide una sala conferenze. (Sospetto che per lo sviluppo di un prodotto di grandi dimensioni come Microsoft Windows che anche se le persone si trovano tutte nello stesso edificio, il team è troppo grande per mantenere il livello di collaborazione che fa funzionare un VCS centralizzato senza sostituti.)

3
Ken Bloom

Perché non usarli in tandem? Nel mio attuale progetto siamo costretti a usare CVS. Tuttavia, manteniamo anche repository git locali per lo sviluppo delle funzionalità. Questo è il migliore di entrambi i mondi perché puoi provare varie soluzioni e mantenere le versioni di ciò su cui stai lavorando, sulla tua macchina. Ciò ti consente di ripristinare le versioni precedenti della tua funzionalità o provare diversi approcci senza incorrere in problemi quando confondi il tuo codice. Avere un repository centrale ti offre quindi i vantaggi di avere un repository centralizzato.

2
Vadim

Non ho esperienza personale con DVCS, ma da ciò che raccolgo dalle risposte qui e da alcuni documenti collegati, la differenza fondamentale tra DVCS e CVCS è il modello di lavoro utilizzato

DVCS

Il modello di funzionamento di DVCS è che stai facendo sviluppo isolato. Stai sviluppando la tua nuova funzionalità/correzione di bug in modo isolato da tutte le altre modifiche fino al momento in cui decidi di rilasciarla al resto del team. Fino a quel momento, puoi fare qualsiasi check-in che ti piace, perché nessun altro ne sarà disturbato.

CVCS

Il modello di lavoro di CVCS (in particolare Subversion) è che stai facendo sviluppo collaborativo. Stai sviluppando la tua nuova funzionalità/correzione di bug in collaborazione diretta con tutti gli altri membri del team e tutte le modifiche sono immediatamente disponibili per tutti.

Altre differenze

Altre differenze tra svn e git/hg, come le revisioni contro i changeset sono casuali. È molto ben possibile creare un DVCS basato su revisioni (come hanno Subversion) o un CVCS basato su changeset (come hanno Git/Mercurial).

Non consiglierò alcun particolare strumento, perché dipende principalmente dal modello di lavoro con cui tu (e il tuo team) siete più a vostro agio.
Personalmente, non ho problemi a lavorare con un CVCS.

  • Non ho paura di fare il check-in, poiché non ho problemi a portarlo in uno stato incompleto, ma compilabile.
  • Quando ho sperimentato merge-hell, si è verificato in situazioni in cui si sarebbe verificato sia in svn che git/hg. Ad esempio, V2 di alcuni software veniva gestito da un team diverso, utilizzando un VCS diverso, mentre sviluppavamo V3. Occasionalmente, le correzioni di bug dovrebbero essere importate dal VCS V2 al VCS V3, il che in pratica significava fare un check-in molto ampio sul VCS V3 (con tutti i bugfix in un singolo changeset). So che non era l'ideale, ma è stata una decisione di gestione utilizzare diversi sistemi VCS.