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

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

Nel considerare ciascuno di essi tra loro e contro i sistemi di controllo della versione come SVN e Perforce, quali problemi dovrebbero essere considerati?

Nel pianificare una migrazione da SVN a uno di questi sistemi di controllo della versione distribuita, quali fattori considereresti?

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 proprio un cittadino di prima classe. Git espone gli hash come numeri di versione agli utenti; ciò fornisce garanzie (in quanto 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 li visualizza come oggetti di primo livello, ma non tiene traccia delle 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 tale hash potrebbero andare persi); ad alcuni puristi (me compreso) non piace molto.

Il bazar è ragionevolmente veloce (molto veloce per alberi con una storia superficiale, ma attualmente si ridimensiona male con la lunghezza della storia), ed è facile da imparare per coloro che hanno familiarità con le interfacce da riga di comando degli SCM tradizionali (CVS, SVN, ecc.). Win32 è considerato un obiettivo di prima classe 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 migliore supporto per l'integrazione con i sistemi di controllo di revisione basati su concetti diversi) e migliorare le prestazioni. Il team di Bazaar considera il tracciamento delle directory e rinomina il supporto di funzionalità di prima classe. Mentre gli identificatori di ID revisione univoci a livello globale sono disponibili per tutte le revisioni, revnos albero-locale (numeri di revisione standard, più simili a quelli usati da svn o altri SCM più convenzionali) sono usati al posto degli hash di contenuto per identificare le revisioni. Bazaar ha il supporto per "checkout leggeri", in cui la cronologia viene archiviata su un server remoto anziché copiata sul sistema locale e viene automaticamente indicata sulla rete quando necessario; al momento, questo è unico tra i DSCM.

Entrambi hanno una qualche forma di integrazione SVN disponibile; tuttavia, bzr-svn è considerevolmente più capace di git-svn, in gran parte a causa delle revisioni del formato back-end 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 considerevolmente più raffinata; Consiglio vivamente il suo utilizzo rispetto a quello di git-svn quando i limiti di budget e licenza lo consentono].

Non ho usato ampiamente Mercurial, e quindi non posso commentarlo in dettaglio - tranne per notare che, come Git, ha un indirizzamento dell'hash del contenuto per le revisioni; anche come Git, non tratta le directory come oggetti di prima classe (e non può memorizzare una directory vuota). È, tuttavia, più veloce di qualsiasi altro DSCM ad eccezione di Git e ha un'integrazione IDE molto migliore (specialmente per Eclipse) rispetto a tutti i suoi concorrenti. Date le sue caratteristiche prestazionali (che sono leggermente in ritardo rispetto a quelle di Git) e il suo eccellente supporto multipiattaforma e IDE, Mercurial potrebbe essere avvincente per i team con un numero significativo di membri win32-centric o IDE-bound.

Una preoccupazione nella migrazione da SVN è che i frontend GUI di SVN e l'integrazione IDE sono più maturi di quelli di uno degli SCM distribuiti. Inoltre, se attualmente si fa largo uso dell'automazione degli script di pre-esecuzione con SVN (cioè, per richiedere il superamento dei test unitari prima che possa procedere un commit), è consigliabile utilizzare uno strumento simile a PQM per automatizzare le richieste di unione nei rami condivisi.

SVK è un DSCM che utilizza Subversion come archivio di supporto e ha una buona integrazione con strumenti incentrati su SVN. Tuttavia, presenta caratteristiche di prestazioni e scalabilità drammaticamente peggiori rispetto a qualsiasi altro DSCM principale (anche Darcs) e dovrebbe essere evitato per i progetti che potrebbero aumentare in termini di lunghezza della cronologia o numero di file.

[Informazioni sull'autore: utilizzo Git e Perforce per 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 attorno a SVN; prima ho esperienza con GNU Arch, BitKeeper, CVS e altri. All'inizio Git era piuttosto scoraggiante - sembrava GNU Arch in quanto ambiente fortemente concettuale, al contrario dei toolkit costruiti per conformarsi 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 appena (28/09/2009) ha pubblicato un post di blog su questo argomento in cui fa un paragone eccezionale e persino consegnato di Git, Mercurial e Bazaar .

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

È una lettura breve e lo consiglio vivamente.

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

A mio avviso, la forza di Git è il suo design essenziale e ricco di funzionalità. Ha anche il miglior supporto per i repository multi-branch e la gestione di flussi di lavoro pesanti. È molto veloce e ha dimensioni ridotte del repository.

Ha alcune funzionalità che sono utili ma che richiedono un certo sforzo per essere utilizzate. Questi includono ara (indice) di stadiazione intermedia visibile tra l'area di lavoro e il database del repository, che consente una migliore risoluzione di fusione in casi più complicati, commit incrementale e commit con albero sporco; rilevare rinominazioni e copie usando l'euristica della somiglianza piuttosto che rintracciarle utilizzando un qualche tipo di ID file, che funziona bene e che consente la colpa (annotazione) che può seguire il movimento del codice attraverso i file e non solo rinominazioni all'ingrosso.

Uno degli svantaggi è che il supporto di MS Windows è in ritardo e non è completo. Un altro svantaggio percepito è che non è ben documentato come ad esempio Mercurial, ed è meno facile da usare rispetto alla concorrenza, ma cambia.

A mio avviso, la forza di Mercurial risiede nelle sue buone prestazioni e nelle dimensioni ridotte del repository, nel suo buon supporto per MS Windows.

Il principale svantaggio è a mio avviso il fatto che le filiali locali (più filiali in un unico repository) sono ancora cittadini di seconda classe e in modo strano e complicato implementano i tag. Anche il modo in cui gestisce le ridenominazioni dei file era subottimale (ma questa larghezza è cambiata). Mercurial non supporta le fusioni di polpo (con più di due genitori).

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

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

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

Nel considerare ciascuno di essi tra loro e contro i sistemi di controllo della versione come SVN e Perforce, quali problemi dovrebbero essere considerati?

I sistemi di controllo versione come Subversion (SVN), Perforce o ClearCase sono sistemi di controllo versione centralizzati . Git, Mercurial, Bazaar (e anche Darcs, Monotone e BitKeeper) sono sistemi di controllo della versione distribuiti . I sistemi di controllo della versione distribuita consentono una gamma molto più ampia di flussi di lavoro. Consentono di utilizzare "pubblica quando è pronto". Offrono un supporto migliore per la ramificazione e l'unione e per flussi di lavoro pesanti. Non è necessario fidarsi delle persone con accesso commit per poter ottenere contributi da loro in modo semplice.

Nel pianificare una migrazione da SVN a uno di questi sistemi di controllo della versione distribuita, quali fattori considereresti?

Uno dei fattori che potresti voler prendere in considerazione è il supporto per l'intrattazione con SVN; Git ha git-svn, Bazaar ha bzr-svn e Mercurial ha l'estensione hgsubversion.

Dichiarazione di non responsabilità: sono un utente Git e un collaboratore di piccole dimensioni e guardo (e partecipo alla) mailing list di git. Conosco Mercurial e Bazaar solo dalla loro documentazione, varie discussioni su IRC e mailing list, post sul blog e articoli che confrontano vari sistemi di controllo delle versioni (alcuni dei quali sono elencati nella pagina GitComparison su Git Wiki).

InfoQ ha un bel confronto .

Mercurial e Bazaar si assomigliano molto in superficie. Entrambi forniscono il controllo di base della versione distribuita, come nel commit offline e nell'unione di più rami, sono entrambi scritti in Python e sono entrambi più lenti di Git. Ci sono molte differenze una volta approfondito il codice, ma, per le attività quotidiane di routine, sono effettivamente le stesse, sebbene Mercurial sembri avere un po 'più di slancio.

Git, beh, non è per i non iniziati. È molto più veloce sia di Mercurial che di Bazaar ed è stato scritto per gestire il kernel Linux. È il più veloce dei tre ed è anche il più potente dei tre, con un certo margine. Gli strumenti di manipolazione del registro e del commit di Git non hanno eguali. Tuttavia, è anche il più complicato e il più pericoloso da usare. È molto facile perdere un commit o rovinare un repository, specialmente se non capisci 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 in base a tre importanti motivi:

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

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

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

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

Una cosa molto importante che manca nel bazar è il cp. Non puoi avere più file che condividono la stessa cronologia, come in SVN, vedi ad esempio qui e qui . Se non hai intenzione di usare cp, bzr è un ottimo sostituto (e molto facile da usare) di svn.

Stavo usando Bazaar da un po 'che mi piaceva molto ma erano solo progetti più piccoli e anche allora era piuttosto lento. Così facile da imparare, ma non super veloce. È molto x-platform però.

Attualmente uso Git che mi piace molto poiché la versione 1.6 lo ha reso molto più simile ad altri VCS in termini di comandi da usare.

Penso che le principali differenze per la mia esperienza nell'uso del DVCS sia questa:

1. Git ha la community più vivace ed è comune vedere articoli su Git
2. GitHub è davvero incredibile. Launchpad.net è ok, ma niente come il piacere di Github
3. Il numero di strumenti del flusso di lavoro per Git è stato eccezionale. È integrato ovunque. Ce ne sono alcuni per Bzr ma non così tanti o altrettanto ben mantenuti.

In sintesi, Bzr è stato fantastico quando mi sono tagliato i denti sul DVCS, ma ora sono molto contento di Git e Github.

Questa è una grande domanda che dipende molto dal contesto che ti richiederebbe molto tempo per scrivere in una di queste caselle di testo. Inoltre, tutti e tre questi sembrano sostanzialmente simili se usati per le solite cose che fanno la maggior parte dei programmatori, quindi anche comprendere le differenze richiede una conoscenza abbastanza esoterica.

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

Bazaar è IMHO più facile da imparare che git. Git ha un buon supporto su github.com.

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

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

Questa è una domanda molto aperta, al limite dell'esca di fiamma.

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 dell'utente. Mercurial è da qualche parte nel mezzo.

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

Nel considerare ciascuno di essi tra loro e contro i sistemi di controllo della versione 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 liberi come nel discorso .

La scelta centralizzata rispetto a quella decentralizzata è una scelta molto più importante di qualsiasi sistema menzionato nella sua categoria.

Nel pianificare una migrazione da SVN a uno di questi sistemi di controllo della versione distribuita, quali fattori considereresti?

Innanzitutto, la mancanza di un buon sostituto di TortoiseSVN. Anche se Bazaar sta lavorando alla propria variante di tartaruga , ma non è ancora lì, a settembre 2008.

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

Infine, l'integrazione con il resto del sistema, ad esempio tracker dei problemi, sistema notturno di build, sistema di test automatizzato, ecc.

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

ddaa.myopenid.com lo ha menzionato di sfuggita, ma penso che valga la pena menzionarlo di nuovo: Bazaar può leggere e scrivere su repository SVN remoti. Ciò significa che potresti usare Bazaar localmente come bozza di concetto mentre il resto della squadra sta ancora usando Subversion.

EDIT: Praticamente tutti gli strumenti ora hanno un modo di interagire con SVN, ma ora ho un'esperienza personale che git svnfunziona estremamente bene. Lo uso da 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 cosa sono gli SCM distribuiti e perché sono meglio di quelli centralizzati. Esistono molti confronti tra git (mercurial è considerato OK) e cvs / svn / perforce. Ci sono anche domande da parte del pubblico in merito alla migrazione verso 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) di Github.

Devo dire qui un avvertimento: Linus ha uno stile abbastanza aggressivo, penso che voglia essere divertente ma non ho riso. A parte questo, il video è fantastico se non hai familiarità con gli SCM distribuiti e pensi al passaggio da SVN.

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

I sistemi di controllo della versione distribuita (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 diventano allo stesso modo Benedette. L'unica vera differenza tra CVS, Subversion, ClearCase, Perforce, VisualSourceSafe e tutti gli altri CVCS è nel flusso di lavoro, nelle prestazioni e nell'integrazione che ciascun prodotto offre.

I sistemi VCS distribuiti sono progettati con l'intento che un repository è buono come un altro e che l'unione da un repository all'altro è solo un'altra forma di comunicazione. Qualsiasi valore semantico su quale archivio dovrebbe essere attendibile è imposto dall'esterno dal processo, non dal software stesso.

La vera scelta tra l'utilizzo di un tipo o dell'altro è organizzativa: se il tuo progetto o organizzazione desidera un controllo centralizzato, un DVCS è un dispositivo di avviamento. Se i tuoi sviluppatori dovrebbero lavorare in tutto il paese / mondo, senza connessioni sicure a banda larga a un repository centrale, allora DVCS è probabilmente la tua salvezza. Se hai bisogno di entrambi, sei fottuto.