Quali sono i punti di forza e di debolezza relativi di Git, Mercurial e Bazaar?

Cosa vedono le persone qui come i relativi punti di forza e debolezze di Git, Mercurial e Bazaar?

Considerando ciascuno di essi l’uno con l’altro e contro i sistemi di controllo delle versioni come SVN e Perforce, quali problemi dovrebbero essere considerati?

Nel pianificare una migrazione da SVN a uno di questi sistemi di controllo delle versioni distribuite, quali fattori prenderesti in considerazione?

Git è molto veloce, si adatta molto bene ed è molto trasparente sui suoi concetti. Il lato negativo di questo è che ha una curva di apprendimento relativamente ripida. È disponibile una porta Win32, ma non del tutto un cittadino di prima class. Git espone gli hash come numeri di versione agli utenti; questo fornisce garanzie (nel senso che un singolo hash fa sempre riferimento allo stesso identico contenuto, un utente malintenzionato non può modificare la cronologia senza essere rilevato), ma può essere ingombrante per l’utente. Git ha un concetto unico di tracciamento dei contenuti dei file, anche se tali contenuti si spostano tra i file e visualizzano i file come oggetti di primo livello, ma non tracciano le directory. Un altro problema con git è che ha molte operazioni (come rebase ) che rendono facile modificare la cronologia (in un certo senso – il contenuto a cui fa riferimento un hash non cambierà mai, ma i riferimenti a quell’hash potrebbero andare persi); alcuni puristi (me compreso) non mi piacciono molto.

Il Bazaar è ragionevolmente veloce (molto veloce per gli alberi con una storia superficiale, ma attualmente presenta una scarsa scala con la lunghezza della cronologia) ed è facile da apprendere a coloro che hanno familiarità con le interfacce della riga di comando dei tradizionali SCM (CVS, SVN, ecc.). Win32 è considerato un objective di prima class dal suo team di sviluppo. Ha un’architettura collegabile per diversi componenti e sostituisce frequentemente il suo formato di archiviazione; ciò consente loro di introdurre nuove funzionalità (come un miglior supporto per l’integrazione con sistemi di controllo di revisione basati su concetti diversi) e migliorare le prestazioni. Il team di Bazaar ritiene che il rilevamento delle directory e la rinomina supportino funzionalità di prima class. Mentre gli identificatori di ID di revisione univoci a livello globale sono disponibili per tutte le revisioni, i revnos locali dell’albero (numeri di revisione standard, più simili a quelli utilizzati da svn o altri SCM più convenzionali) vengono utilizzati al posto degli hash del contenuto per identificare le revisioni. Bazaar ha il supporto per “checkouts leggeri”, in cui la cronologia è conservata su un server remoto invece di essere copiata nel sistema locale e viene automaticamente riferita alla rete quando necessario; allo stato attuale, questo è unico tra i DSCM.

Entrambi hanno una qualche forma di integrazione SVN disponibile; tuttavia, bzr-svn è notevolmente più capace di git-svn, in gran parte a causa delle revisioni del formato di backend introdotte a tale scopo. [Aggiornamento, a partire dal 2014: il prodotto commerciale di terze parti SubGit fornisce un’interfaccia bidirezionale tra SVN e Git che è paragonabile in fedeltà a bzr-svn e notevolmente più shiny; Raccomando caldamente il suo uso su quello di git-svn quando il budget e i vincoli di licenza lo consentono].

Non ho usato estesamente Mercurial e quindi non posso commentare in dettaglio – tranne notare che, come Git, ha un indirizzamento content-hash per le revisioni; anche come Git, non considera le directory come oggetti di prima class (e non può memorizzare una directory vuota). È, tuttavia, più veloce di qualsiasi altro DSCM ad eccezione di Git, e ha un’integrazione IDE di gran lunga migliore (specialmente per Eclipse) rispetto a qualsiasi altro suo concorrente. Date le sue caratteristiche prestazionali (che sono leggermente inferiori a quelle di Git) e il suo supporto multipiattaforma e IDE superiore, Mercurial potrebbe essere interessante per i team con un numero significativo di membri vincitori di win32-centric o IDE.

Una preoccupazione nella migrazione da SVN è che i frontend di interfaccia grafica e l’integrazione di IDE di SVN sono più maturi di quelli di qualsiasi SCM distribuito. Inoltre, se attualmente si fa un uso pesante dell’automazione degli script precommit con SVN (ovvero richiede che i test delle unità passino prima che un commit possa procedere), probabilmente si vorrà utilizzare uno strumento simile a PQM per automatizzare le richieste di unione ai rami condivisi.

SVK è un DSCM che usa Subversion come backing store e ha una discreta integrazione con gli strumenti SVN-centric. Tuttavia, ha prestazioni e caratteristiche di scalabilità decisamente peggiori di qualsiasi altro DSCM principale (persino Darcs) e dovrebbe essere evitato per progetti che potrebbero crescere in termini di lunghezza della cronologia o numero di file.

[Informazioni sull’autore: utilizzo Git e Perforce per il lavoro e Bazaar per i miei progetti personali e come libreria incorporata; altre parti dell’organizzazione del mio datore di lavoro usano pesantemente Mercurial. In una vita precedente ho costruito una grande quantità di automazione su SVN; prima ho esperienza con GNU Arch, BitKeeper, CVS e altri. All’inizio Git era piuttosto scoraggiante: sembrava GNU Arch come un ambiente pesante per i concetti, al contrario di toolkit costruiti per adattarsi alla scelta dei flussi di lavoro dell’utente, ma da allora sono diventato abbastanza a mio agio con it].

Steve Streeting del progetto Ogre 3D (28/09/2009) ha pubblicato un post su questo argomento in cui fa un ottimo paragone con Git, Mercurial e Bazaar .

Alla fine trova punti di forza e di debolezza con tutti e tre e nessun chiaro vincitore. Tra i lati positivi, dà un ottimo tavolo per aiutarti a decidere con chi andare.

alt text

È una lettura breve e lo consiglio vivamente.

InfoQ ha un bel confronto .


Cosa vedono le persone qui come i relativi punti di forza e debolezze di Git, Mercurial e Bazaar?

Secondo me, la forza di Git è il suo design pulito e sottostante e un insieme di funzionalità molto ricco. Inoltre, ritengo che il miglior supporto per i repository multi-ramo e la gestione dei flussi di lavoro pesanti per le filiali. È molto veloce e ha una piccola dimensione del repository.

Ha alcune caratteristiche che sono utili ma richiede un certo sforzo per essere usato per loro. Tra questi vi è l’intervallo di visualizzazione intermedio visibile (indice) tra l’area di lavoro e il database del repository, che consente una migliore risoluzione di fusione in casi più complicati, l’aumento di commit e l’utilizzo di un albero sporco; rintracciare i nomi e le copie usando l’euristica della similarità piuttosto che rintracciarli usando un qualche tipo di ID file, che funziona bene e che consente la colpa (annotate) che può seguire il movimento del codice tra file e non solo rinomina all’ingrosso.

Uno dei suoi svantaggi è che il supporto di MS Windows è in ritardo e non è pieno. Un altro svantaggio percepito è che non è ben documentato come ad esempio Mercurial, ed è meno user friendly della concorrenza, ma cambia.

Secondo me, la forza di Mercurial risiede nelle sue buone prestazioni e nella piccola dimensione del repository, nel suo buon supporto a MS Windows.

Il principale disadvanatge è, a mio parere, il fatto che le filiali locali (più filiali in un unico repository) siano ancora cittadini di seconda class, e in modo strano e complicato implementa i tag. Anche il modo in cui tratta i nomi dei file è subottimale (ma questo è cambiato). Mercurial non supporta l’unione di polpi (con più di due genitori).

Da quello che ho sentito e letto i principali vantaggi di Bazaar è il facile supporto per un stream di lavoro centralizzato (che è anche uno svantaggio, con concetti centralizzati visibili dove non dovrebbe), rintracciare i nomi di file e directory.

Il suo principale svantaggio sono le prestazioni e la dimensione del repository per grandi repository con una lunga storia non lineare (le prestazioni sono migliorate almeno per repository non troppo grandi), il fatto che il paradigma predefinito è un ranch per repository (è ansible configurarlo per condividere i dati, però) e concetti centralizzati (ma anche da quello che ho sentito cambiare).

Git è scritto in C, script di shell e Perl, ed è scriptable; Mercurial è scritto in C (core, per prestazioni) e Python e fornisce API per estensioni; Bazaar è scritto in Python e fornisce API per estensioni.


Considerando ciascuno di essi l’uno con l’altro e contro i sistemi di controllo delle versioni come SVN e Perforce, quali problemi dovrebbero essere considerati?

I sistemi di controllo versione come Subversion (SVN), Perforce o ClearCase sono sistemi di controllo della versione centralizzati . Git, Mercurial, Bazaar (e anche Darcs, Monotone e BitKeeper) sono sistemi di controllo della versione distribuiti . I sistemi di controllo delle versioni distribuiti consentono una gamma molto più ampia di flussi di lavoro. Consentono di utilizzare “pubblica quando è pronto”. Hanno un migliore supporto per ramificazioni e fusioni e per flussi di lavoro pesanti. Non è necessario fidarsi delle persone con accesso di commit per essere in grado di ottenere contributi da loro in modo semplice.


Nel pianificare una migrazione da SVN a uno di questi sistemi di controllo delle versioni distribuite, quali fattori prenderesti in considerazione?

Uno dei fattori che potresti voler considerare è il supporto per l’inattività con SVN; Git ha git-svn, Bazaar ha bzr-svn e Mercurial ha l’estensione hgsubversion.

Disclaimer: Sono un utente Git e un collaboratore di piccole dimensioni, e guardo (e partecipa) alla mailing list git. Conosco Mercurial e Bazaar solo dalla loro documentazione, varie discussioni su IRC e mailing list, e post di blog e articoli che mettono a confronto vari sistemi di controllo delle versioni (alcuni dei quali sono elencati sulla pagina GitComparison su Git Wiki).

Mercurial e Bazaar si somigliano molto in superficie. Entrambi forniscono il controllo di base della versione distribuita, come nel commit offline e la fusione di più rami, sono entrambi scritti in python e sono entrambi più lenti di git. Ci sono molte differenze dopo aver approfondito il codice, ma, per le attività quotidiane di routine, sono effettivamente le stesse, anche se Mercurial sembra avere un po ‘più di slancio.

Git, beh, non è per chi non lo sapesse. È molto più veloce di Mercurial e Bazaar, ed è stato scritto per gestire il kernel di Linux. È il più veloce dei tre ed è anche il più potente dei tre, con un margine piuttosto ampio. Gli strumenti di log e commit di Git sono ineguagliati. Tuttavia, è anche il più complicato e il più pericoloso da usare. È molto facile perdere un commit o rovinare un repository, specialmente se non si capisce il funzionamento interno di git.

Dai un’occhiata al confronto fatto di recente dagli sviluppatori Python: http://wiki.python.org/moin/DvcsComparison . Hanno scelto Mercurial sulla base di tre importanti motivi:

La scelta di andare con Mercurial è stata fatta per tre importanti motivi:

  • Secondo un piccolo sondaggio, gli sviluppatori Python sono più interessati all’utilizzo di Mercurial rispetto a Bazaar o Git.
  • Mercurial è scritto in Python, che è congruente con la tendenza python-dev a ‘mangiare il proprio cibo per cani’.
  • Mercurial è significativamente più veloce di bzr (è più lento di git, anche se con una differenza molto minore).
  • Mercurial è più facile da imparare per gli utenti SVN rispetto a Bazaar.

(da http://www.python.org/dev/peps/pep-0374/ )

Sun ha fatto una valutazione di git , Mercurial e Bazaar come candidati per sostituire il Sun Teamware VCS per la base di codici Solaris. L’ho trovato molto interessante.

Questa è una grande domanda che dipende molto dal contesto che ti richiederebbe molto tempo per digitare in una di queste piccole caselle di testo. Inoltre, tutte e tre queste appaiono sostanzialmente simili quando vengono usate per le solite cose che fanno la maggior parte dei programmatori, quindi anche la comprensione delle differenze richiede alcune conoscenze abbastanza esoteriche.

Probabilmente otterrai risposte molto migliori se riesci a interrompere l’analisi di questi strumenti fino al punto in cui hai domande più specifiche.

Il Bazar IMHO è più facile da imparare di git. Git ha un bel supporto in github.com.

Penso che dovresti provare ad usare entrambi e decidere quale ti piace di più.

Cosa vedono le persone qui come i relativi punti di forza e debolezze di Git, Mercurial e Bazaar?

Questa è una domanda molto aperta, al confine con flamebait.

Git è il più veloce, ma tutti e tre sono abbastanza veloci. Bazaar è il più flessibile (ha un supporto di lettura-scrittura trasparente per i repository SVN) e si preoccupa molto dell’esperienza utente. Mercurial è da qualche parte nel mezzo.

Tutti e tre i sistemi hanno molti fan. Sono personalmente un fanboy del Bazaar.

Considerando ciascuno di essi l’uno con l’altro e contro i sistemi di controllo delle versioni come SVN e Perforce, quali problemi dovrebbero essere considerati?

I primi sono sistemi distribuiti. Questi ultimi sono sistemi centralizzati. Inoltre, Perforce è proprietario mentre tutti gli altri sono gratuiti come nel linguaggio .

Centralizzato rispetto a decentralizzato è una scelta molto più importante di qualsiasi altro sistema menzionato nella sua categoria.

Nel pianificare una migrazione da SVN a uno di questi sistemi di controllo delle versioni distribuite, quali fattori prenderesti in considerazione?

Innanzitutto, la mancanza di un buon sostituto per TortoiseSVN. Sebbene Bazaar stia lavorando sulla propria variante di Tortoise , ma non c’è ancora, a partire da settembre 2008.

Quindi, istruisci le persone chiave su come l’utilizzo di un sistema decentralizzato influenzerà il loro lavoro.

Infine, l’integrazione con il resto del sistema, come ad esempio gli inseguitori di problemi, il sistema di generazione notturno, il sistema di test automatizzato, ecc.

Una cosa molto importante che manca nel bazar è cp. Non è ansible avere più file che condividono la stessa cronologia, come in SVN, si veda ad esempio qui e qui . Se non hai intenzione di usare cp, bzr è un’ottima alternativa (e molto facile da usare) per svn.

Per un po ‘stavo usando Bazaar che mi piaceva molto, ma erano solo progetti più piccoli e anche allora era piuttosto lento. Così facile da imparare, ma non super veloce. Comunque è molto x-platform.

Attualmente utilizzo Git che mi piace molto poiché la versione 1.6 lo rendeva molto più simile agli altri VCS in termini di comandi da usare.

Penso che le principali differenze per la mia esperienza nell’uso di DVCS sia questa:

  1. Git ha la comunità più vivace ed è comune vedere articoli su Git
  2. GitHub fa veramente un salto. Launchpad.net è ok, ma niente come il piacere di Github
  3. Il numero di strumenti per il stream di lavoro per Git è stato eccezionale. È integrato dappertutto. Ce ne sono alcuni per Bzr ma non così tanti o altrettanto ben mantenuti.

In sintesi, Bzr è stato fantastico quando stavo tagliando i denti su DVCS, ma ora sono molto felice con Git e Github.

I sistemi di controllo delle versioni distribuiti (DVCS) risolvono problemi diversi rispetto ai VCS centralizzati. Confrontarli è come confrontare martelli e cacciaviti.

I sistemi VCS centralizzati sono progettati con l’intento che esiste una vera fonte benedetta e quindi buona. Tutti gli sviluppatori lavorano (checkout) da quella fonte, quindi aggiungono (eseguono il commit) le loro modifiche, che poi diventano Blessed allo stesso modo. L’unica vera differenza tra CVS, Subversion, ClearCase, Perforce, VisualSourceSafe e tutti gli altri CVCS è nel stream di lavoro, nelle prestazioni e nell’integrazione che ogni prodotto offre.

I sistemi VCS distribuiti sono progettati con l’intento che un repository è buono come tutti gli altri e che si fondono da un repository all’altro sono solo un’altra forma di comunicazione. Qualsiasi valore semantico su quale repository debba essere considerato affidabile viene imposto dall’esterno dal processo, non dal software stesso.

La vera scelta tra l’utilizzo di un tipo o l’altro è organizzativa – se il tuo progetto o organizzazione desidera un controllo centralizzato, allora un DVCS è un non-starter. Se si prevede che i tuoi sviluppatori lavorino in tutto il paese / mondo, senza connessioni a banda larga sicure a un repository centrale, DVCS è probabilmente la tua salvezza. Se hai bisogno di entrambi, sei fsck’d.

Il tuo problema principale sarà che questi sono SCM distribuiti , e come tale richiedono un po ‘di cambiamento nella mentalità dell’utente. Una volta che le persone si abituano all’idea, i dettagli tecnici e i modelli di utilizzo andranno a posto, ma non sottovalutate quell’ostacolo iniziale, specialmente in un contesto aziendale. Ricorda, tutti i problemi sono i problemi delle persone.

ddaa.myopenid.com ne ha parlato di sfuggita, ma penso che valga la pena menzionarlo di nuovo: Bazaar può leggere e scrivere su repository SVN remoti. Ciò significa che puoi usare Bazaar localmente come proof-of-concept mentre il resto del team sta ancora utilizzando Subversion.

EDIT: Quasi tutti gli strumenti ora hanno un modo di interagire con SVN, ma ora ho esperienza personale che git svn funziona molto bene. L’ho usato per mesi, con il minimo singhiozzo.

C’è un buon video di Linus Torvalds su Git. È il creatore di Git quindi questo è ciò che promuove ma nel video spiega quali sono le SCM distribuite e perché sono migliori di quelle centralizzate. C’è parecchio da confrontare tra git (mercurial è considerato OK) e cvs / svn / perforce. Ci sono anche domande dal pubblico riguardanti la migrazione a SCM distribuito.

Ho trovato questo materiale illuminante e sono venduto a SCM distribuito. Ma nonostante gli sforzi di Linus, la mia scelta è mercuriale. Il motivo è bitbucket.org, l’ho trovato migliore (più generoso) e poi github.

Devo dire qui una parola di avvertimento: Linus ha uno stile abbastanza aggressivo, penso che voglia essere divertente ma non ho riso. A parte questo, il video è fantastico se sei nuovo su SCMs distribuiti e pensi di trasferirti da SVN.

http://www.youtube.com/watch?v=4XpnKHJAok8