Confronto tra sistemi di controllo versione centralizzata e distribuita [chiuso]

Question

Quali sono i vantaggi e svantaggi dell'uso dei sistemi di controllo versione (DVCS) centralizzati rispetto a quelli distribuiti ? Hai riscontrato problemi in DVCS e come ti sei protetto da questi problemi? Mantieni lo strumento di discussione agnostico e fiammeggiante al minimo.

Per coloro che si chiedono quali strumenti DVCS sono disponibili, ecco un elenco dei DVCS gratuiti / open source più noti:

• Git , (scritto in C) utilizzato da Linux Kernel e Ruby on Rails .
• Mercurial , (scritto in Python) utilizzato da Mozilla e OpenJDK .
• Bazaar , (scritto in Python) utilizzato da Sviluppatori Ubuntu .
• Darcs , (scritto in Haskell).

Answer 1

Da la mia risposta a un'altra domanda :

  

Sistemi di controllo della versione distribuita   (DVCS) risolvono problemi diversi rispetto a   VCS centralizzati. Confrontandoli è   come confrontare martelli e   cacciaviti.

     I

VCS centralizzati sono   progettato con l'intento che c'è   Una vera fonte benedetta e   quindi buono. Tutti gli sviluppatori lavorano   (checkout) da quella fonte e quindi   aggiungere (commit) le loro modifiche, che poi   diventa altrettanto benedetto. Il solo   vera differenza tra CVS,   Subversion, ClearCase, Perforce,   VisualSourceSafe e tutti gli altri   CVCSes è nel flusso di lavoro,   prestazioni e integrazione che ciascuno   offerte di prodotti.

     I sistemi

?? VCS distribuiti sono   progettato con l'intento che uno   il repository è buono come qualsiasi altro,   e che si fonde da un repository a   un'altra è solo un'altra forma di   comunicazione. Qualsiasi valore semantico come   a quale repository dovrebbe essere attendibile   è imposto dall'esterno da   processo, non dal software stesso.

     

La vera scelta tra l'utilizzo di un tipo   o l'altro è organizzativo - se   il tuo progetto o organizzazione vuole   controllo centralizzato, quindi un DVCS è un   non-starter. Se i tuoi sviluppatori lo sono   dovrebbe funzionare in tutto il   paese / mondo, senza sicuro   connessioni a banda larga a una centrale   repository, quindi DVCS è probabilmente il tuo   salvezza. Se hai bisogno di entrambi, lo sei   fsck'd.

Answer 2

  

A coloro che pensano che i sistemi distribuiti non consentano l'autorità   copie si prega di notare che ci sono molti posti dove distribuiti   i sistemi hanno copie autorevoli, l'esempio perfetto è probabilmente   Albero del kernel di Linus. Certo molte persone hanno i loro alberi ma   quasi tutti scorrono verso l'albero di Linus.

     

Detto questo, penso che gli SCM distribuiti fossero utili solo per   molti sviluppatori fanno cose diverse ma recentemente hanno deciso   che qualsiasi cosa un repository centralizzato può fare, uno distribuito può fare   meglio.

     

Ad esempio, supponiamo che tu sia uno sviluppatore solista che lavora da solo   progetto. Un repository centralizzato potrebbe essere una scelta ovvia ma   considera questo scenario. Sei lontano dall'accesso alla rete (su un aereo,   in un parco, ecc.) e vuoi lavorare al tuo progetto. Hai il tuo locale   copia in modo da poter lavorare bene ma vuoi davvero impegnarti perché tu   hai finito una funzione e vuoi passare a un'altra, o l'hai trovata   un bug da correggere o altro. Il punto è che con un repository centralizzato   finisci per mettere insieme tutti i cambiamenti e commetterli   in un changeset non logico o li dividi manualmente in seguito.

     

Con un repository distribuito si va in affari come al solito, si impegna, si passa,   quando hai di nuovo accesso alla rete, spingi al tuo "vero repository" e   non è cambiato nulla.

     

Per non parlare dell'altra cosa bella dei repository distribuiti: completa   storia disponibile sempre. È necessario esaminare i registri di revisione quando   lontano dalla rete? È necessario annotare la fonte per vedere come un bug   è stato presentato? Tutto possibile con repository distribuiti.

     

Per favore, non credete che sia distribuito o centralizzato   proprietà o copie autorevoli o simili. La realtà   è distribuito è il prossimo passo nell'evoluzione di SCM.

Answer 3

Non proprio un confronto, ma ecco cosa stanno usando i grandi progetti:

VCS centralizzati

• Subversion

  Apache, GCC, Ruby, MPlayer, Zope, Plone, Xiph, FreeBSD, WebKit, ...

• CVS

  CVS

VCS distribuiti

• git

  Kernel Linux, KDE, Perl, Ruby on Rails, Android, Wine, Fedora, X.org, Mediawiki, Django, VLC, Mono, Gnome, Samba, CUPS, GnuPG, Emacs ELPA ...

• mercurial (hg)

  Mozilla e Mozdev, OpenJDK (Java), OpenSolaris, ALSA, NTFS-3G, Dovecot, MoinMoin, mutt, PETSc, Octave, FEniCS, Aptitude, Python, XEmacs, Xen, Vim, Xine ...

• bzr

  Emacs, Apt, Mailman, MySQL, Squid, ... promossi anche all'interno di Ubuntu.

• darcs

  ghc, ion, xmonad, ... popolare nella comunità di Haskell.

• fossil

  SQLite

Answer 4

W. Craig Trader ha detto questo su DVCS e CVCS:

  

Se hai bisogno di entrambi, sei fsck'd.

Non direi che sei fsck'd quando usi entrambi. Praticamente gli sviluppatori che usano gli strumenti DVCS di solito cercano di unire le loro modifiche (o inviare richieste pull) in una posizione centrale (di solito a un ramo di rilascio in un repository di rilascio). C'è un po 'di ironia con gli sviluppatori che usano DVCS ma, alla fine, con un flusso di lavoro centralizzato, puoi iniziare a chiederti se l'approccio Distributed è davvero migliore di Centralized.

Ci sono alcuni vantaggi con DVCS rispetto a un CVCS:

• La nozione di commit riconoscibili in modo univoco rende l'invio di patch tra peer indolore. Cioè fai la patch come commit e la condividi con altri sviluppatori che ne hanno bisogno. Successivamente, quando tutti vogliono unirsi, quel particolare impegno viene riconosciuto e può essere confrontato tra i rami, avendo meno possibilità di unire il conflitto. Gli sviluppatori tendono a scambiarsi patch tramite chiavetta USB o e-mail, indipendentemente dallo strumento di controllo delle versioni utilizzato. Sfortunatamente nel caso CVCS, il controllo della versione registrerà i commit come separati, non riconoscendo che i cambiamenti sono gli stessi, portando a maggiori possibilità di unire conflitti.

• Puoi avere rami sperimentali locali (i repository clonati possono anche essere considerati un ramo) che non devi mostrare agli altri. Ciò significa che interrompere le modifiche non deve influire sugli sviluppatori se non hai spinto nulla a monte. In un CVCS, quando hai ancora una modifica, potresti dover lavorare offline fino a quando non lo hai risolto e confermare le modifiche entro quel momento. Questo approccio sconfigge efficacemente lo scopo di utilizzare il versioning come rete di sicurezza, ma è un male necessario in CVCS.

• Nel mondo di oggi, le aziende di solito lavorano con sviluppatori off-shore (o se ancora meglio vogliono lavorare da casa). Avere un DVCS aiuta questo tipo di progetti perché elimina la necessità di una connessione di rete affidabile poiché ognuno ha il proprio repository.

& # 8230; e alcuni svantaggi che di solito hanno soluzioni alternative:

• Chi ha l'ultima revisione? In un CVCS, il trunk di solito ha l'ultima revisione, ma in un DVCS potrebbe non essere chiaramente ovvio. La soluzione alternativa sta usando le regole di comportamento, che gli sviluppatori in un progetto devono raggiungere un accordo in cui repo per unire il loro lavoro.

• I blocchi pessimistici, ovvero un file è bloccato quando si effettua un check-out, di solito non sono possibili a causa della concorrenza che può verificarsi tra i repository in DVCS. Il motivo per cui esiste il blocco dei file nel controllo versione è perché gli sviluppatori vogliono evitare conflitti di unione. Tuttavia, il blocco ha lo svantaggio di rallentare lo sviluppo poiché due sviluppatori non possono lavorare sullo stesso codice contemporaneamente come con un modello di transazione lungo e non è una garanzia completa contro i conflitti di unione. L'unico modo sensato, indipendentemente dal controllo della versione, è quello di combattere i grandi conflitti di unione è avere una buona architettura del codice (come un basso accoppiamento ad alta coesione) e dividere le attività di lavoro in modo che abbiano un basso impatto sul codice (che è più facile a dirsi che a farsi) .

• Nei progetti proprietari sarebbe disastroso se l'intero repository diventasse pubblicamente disponibile. Ancora di più se un programmatore scontento o malizioso si impadronisce di un repository clonato. La perdita del codice sorgente è una grave sofferenza per le aziende proprietarie. I DVCS rendono tutto ciò semplice poiché è sufficiente clonare il repository, mentre alcuni sistemi CM (come ClearCase) tentano di limitare tale accesso. Tuttavia, a mio avviso, se hai una quantità sufficiente di disfunzionalità nella cultura della tua azienda, nessun controllo di versione al mondo ti aiuterà a evitare la perdita del codice sorgente.

Answer 5

Durante la mia ricerca dell'SCM giusto, ho trovato di grande aiuto i seguenti link:

  
1. Migliore iniziativa SCM: confronto . Confronto di circa 26 sistemi di controllo della versione.
  
2. Confronto tra software di controllo delle revisioni . Articolo di Wikipedia che confronta circa 38 sistemi di controllo della versione che trattano argomenti come differenze tecniche, funzionalità, interfacce utente e altro.
  
3. Sistemi di controllo della versione distribuita . Un altro confronto, ma focalizzato principalmente sui sistemi distribuiti.

Answer 6

In una certa misura, i due schemi sono equivalenti:

• Un VCS distribuito può emulare banalmente uno centralizzato se si spingono sempre le modifiche in un repository upstream designato dopo ogni commit locale.
• Un VCS centralizzato di solito non è in grado di emularne uno distribuito in modo altrettanto naturale, ma puoi ottenere qualcosa di molto simile se usi qualcosa come quilt sopra di esso. La trapunta, se non si ha familiarità con essa, è uno strumento per la gestione di grandi serie di patch su alcuni progetti a monte. L'idea qui è che il comando di commit DVCS sia implementato creando una nuova patch e il comando push sia implementato eseguendo il commit di ogni patch in sospeso sul VCS centralizzato e quindi scartando i file di patch. Sembra un po 'imbarazzante, ma in pratica funziona piuttosto bene.

Detto questo, ci sono un paio di cose che tradizionalmente i DVCS fanno molto bene e di cui la maggior parte dei VCS centralizzati fa un po 'di hashish. Il più importante di questi è probabilmente la ramificazione: un DVCS renderà molto semplice ramificare il repository o unire i rami che non sono più necessari e manterrà traccia della cronologia mentre lo fai. Non vi è alcun motivo particolare per cui uno schema centralizzato avrebbe problemi con questo, ma storicamente nessuno sembra aver capito bene. Se questo sia effettivamente un problema per te dipende da come organizzerai lo sviluppo, ma per molte persone è una considerazione significativa.

L'altro vantaggio ipotizzato dei DVCS è che funzionano offline. Non ne ho mai avuto molto uso; Mi occupo principalmente di sviluppo in ufficio (quindi il repository è sulla rete locale) o a casa (quindi c'è l'ADSL). Se fai molto sviluppo su laptop mentre viaggi, questa potrebbe essere una considerazione per te.

In realtà non ci sono molti gotcha specifici per i DVCS. C'è una tendenza leggermente maggiore per le persone a tacere, perché puoi impegnarti senza spingere ed è facile finire per lucidare le cose in privato, ma a parte questo non abbiamo avuto molti problemi. Ciò può essere dovuto al fatto che abbiamo un numero significativo di sviluppatori open source, che di solito hanno familiarità con il modello di sviluppo di patch trading, ma anche gli sviluppatori in arrivo di fonti chiuse sembrano raccogliere le cose abbastanza rapidamente.

Answer 7

I VCS distribuiti sono interessanti in molti modi, ma uno svantaggio che sarà importante per la mia azienda è il problema della gestione di file non unibili (in genere binari, ad esempio documenti Excel). Subversion si occupa di questo supportando " svn: needs-lock " proprietà, il che significa che è necessario ottenere un blocco per il file non unificabile prima di modificarlo. Funziona bene. Ma quel flusso di lavoro richiede un modello di repository centralizzato, che è in contrasto con il concetto DVCS.

Quindi, se si desidera utilizzare un DVCS, non è davvero appropriato per la gestione di file non unibili.

Answer 8

Uso sovversione ormai da molti anni e ne sono rimasto davvero soddisfatto.

Quindi è iniziato il ronzio GIT e ho dovuto testarlo. E per me, il principale punto di forza era la ramificazione. Oh ragazzo. Ora non ho più bisogno di ripulire il mio repository, tornare indietro di alcune versioni o delle cose stupide che ho fatto usando sovversione. Tutto è economico in DVC. Ho provato solo fossili e git però, ma ho usato perforce, cvs e sovversione e sembra che tutti i dvc abbiano ramificazioni e tag molto economici. Non è più necessario copiare tutto il codice da un lato e quindi l'unione è solo un gioco da ragazzi.

Qualsiasi dvcs può essere configurato con un server centrale, ma quello che ottieni è tra l'altro

Puoi controllare qualsiasi piccola modifica che ti piace, come dice Linus se devi usare più di una frase per descrivere ciò che hai appena fatto, stai facendo troppo. Puoi fare a modo tuo con il codice, il ramo, unire, clonare e testare tutti a livello locale senza far scaricare nessuno di enormi quantità di dati. E devi solo inserire le modifiche finali nel server centrale.

E puoi lavorare senza rete.

Quindi in breve, usare un controllo di versione è sempre una buona cosa. L'uso di dvcs è più economico (in KB e larghezza di banda) e penso che sia più divertente da usare.

Per il checkout di Git: http://git-scm.com/
Per fare il checkout Fossil: http://www.fossil-scm.org
Per controllare Mercurial: https://www.mercurial-scm.org

Ora posso solo consigliare sistemi dvcs e puoi facilmente usare un server centrale

Answer 9

Il problema principale (a parte l'ovvio problema della larghezza di banda) è proprietà .

Questo è certo che siti diversi (geografici) non funzionano sullo stesso elemento rispetto all'altro.

Idealmente, lo strumento è in grado di assegnare la proprietà a un file, un ramo o persino un repository.

Per rispondere ai commenti di questa risposta, vuoi davvero che lo strumento ti dica chi possiede cosa, e quindi comunica (tramite telefono, messaggistica istantanea o posta) con il sito remoto.
Se non disponi di un meccanismo di proprietà ... comunicherai " ma spesso troppo tardi;) (ovvero: dopo aver eseguito lo sviluppo simultaneo su un insieme identico di file nello stesso ramo. Il commit può diventare disordinato)

Answer 10

Per me questa è un'altra discussione su un gusto personale ed è piuttosto difficile essere veramente obiettivi. Personalmente preferisco Mercurial rispetto agli altri DVCS. Mi piace scrivere hook nella stessa lingua in cui Mercurial è scritto e l'overhead di rete più piccolo - solo per dico alcune delle mie ragioni.

Answer 11

Al giorno d'oggi, tutti sono sul carro di come i DVCS sono superiori, ma il commento di Craig è importante. In un DVCS, ogni persona ha l'intera storia del ramo. Se stai lavorando con molti file binari, (ad esempio file di immagine o FLA), questo richiede una grande quantità di spazio e non puoi fare differenze.

Answer 12

Ho la sensazione che Mercurial (e altri DVCS) siano più sofisticati di quelli centralizzati. Ad esempio, l'unione di un ramo in Mercurial mantiene la cronologia completa del ramo mentre in SVN devi andare nella directory del ramo per vedere la cronologia.

Answer 13

Un altro vantaggio per SCM distribuito anche nello scenario di sviluppatore solista è se tu, come molti di noi là fuori, hai più di una macchina su cui lavori.

Supponiamo che tu abbia una serie di script comuni. Se ogni macchina su cui lavori ha un clone, puoi su richiesta aggiornare e modificare i tuoi script. Ti dà:

1. un risparmio di tempo, specialmente con i tasti ssh
2. un modo per ramificare le differenze tra sistemi diversi (ad esempio Red Hat vs Debian, BSD vs Linux, ecc.)

Answer 14

W. La risposta di Craig Trader ne riassume la maggior parte, tuttavia, trovo che anche lo stile di lavoro personale faccia una grande differenza. Laddove attualmente lavoro, utilizziamo la sovversione come One True Source, tuttavia molti sviluppatori usano git-svn sui loro computer personali per compensare il problema del flusso di lavoro (fallimento della gestione, ma questa è un'altra storia). In ogni caso. si tratta davvero di bilanciare quali set di funzionalità ti rendono più produttivo con ciò di cui l'organizzazione ha bisogno (ad esempio l'autenticazione centralizzata).

Answer 15

Un sistema centralizzato non ti impedisce necessariamente di usare rami separati per lo sviluppo. Non è necessario disporre di un'unica copia vera della base di codice, piuttosto sviluppatori o team diversi possono avere rami diversi, rami legacy potrebbero esistere ecc.

Ciò che generalmente significa è che il repository è gestito centralmente, ma questo è generalmente un vantaggio in un'azienda con un dipartimento IT competente perché significa che c'è solo un posto in cui eseguire il backup e un solo posto in cui gestire l'archiviazione.