Confronto tra Git, Mercurial e Bazaar

PERCHE’ limitare il confronto tra questi tre e non includere, per esempio, subversion (di cui ho scritto nell’Introduzione al controllo di versione)? Oltre che essere rilasciati tutti e tre sotto licenza GNU sono accomunati dall’appartenenza ad una tipologia particolare di software di controllo di versione. Git, Bazaar (bzr) e Mercurial (hg) sono DVCS (distribuited version control system) ovvero sistemi di controllo di versione nei quali ogni working copy locale contiene l’intera storia di tutte le modifiche apportate in tutte le revisioni precedenti. Questo consente di “navigare” tra le varie modifiche e revisioni senza dover interrogare il repository centrale che risiede solitamente su server remoti aumentando notevolmente la flessibilità.

Con DVCS in realtà viene a mancare l’idea stretta di repository centrale, ogni working copy è un repository, ovvio che per collaborazione tra più sviluppatori e per motivi di backup è sempre necessario un server remoto. Per vedere tutti i vantaggi di questa classe di VCS vi consiglio di visitare la relativa pagina di Wikipedia versione inglese.

Ma tra questi tre DVCS quale scegliere? Google nell’estate del 2008 ha già fatto e pubblicato un attenta analisi di confronto tra Mercurial e Git, con annessa discussione, per decidere quale software utilizzare assieme a subversion nel servizio code.google.com. Per la cronaca hanno scelto Mercurial avanzando una maggiore efficienza nell’uso del protocollo HTTP e di una minore difficoltà di approccio. Bazaar nato nel dicembre dell’anno precedente forse era ancora troppo acerbo per essere preso in considerazione ma ora è il terzo più popolare e sicuramente all’altezza degli altri due.

Lo scopo di questo post non è dire, questo è migliore di quell’altro, cosa che ritengo impossibile visto che parliamo di software supportati da grandi progetti e sicuramente equiparabili ma cercare di evidenziarne le differenze per aiutare la scelta a seconda delle diverse necessità.

  • Git è sicuramente più ostico per chi si avvicina per la prima volta a questo tipo di programmi, Mercurial e Bazaar sono sicuramente più semplici ad un primo approccio. Sopratutto per chi già usa svn si troverà sicuramente bene con Mercurial.
  • I benchmarck dicono che Git è più performante rispetto agli altri due nelle operazioni di commit, diff, e iniziallizzazione, Mercurial in adding e status, invece Baazar segue senza medaglie. Questi dati vanno presi con le pinze perchè a forza di rilasci e aggiornamenti tutti e tre tendono sempre ad inseguirsi equipareggiandosi quasi come prestazioni.
  • Anche come dimesione del repository vince Git a parità di operazioni sugli stessi file il repository occupa 92 MB rispetto ai 112 MB di bzr e i 179 MB di hg. Questo è dovuto anche dal prossimo punto:
  • Senza entrare veramente nei dettagli e parlandone molto con superficialità si può dire che Git tra diverse versioni dello stesso file archivia le differenze e non gli interi due file come accade invece con bazaar e mercurial. Questa è dovuto ad un differente progetto del sistema.
  • Git sarà più difficile da usare ma sicuramente offre molto di più e in certe cose è decisamente uno strumento potente. Ma non sempre potenti funzioni di branching, merging e tagging sono indispensabili, la seplicità di bazaar a volte può essere un grosso vantaggio.
  • Forse per lo stesso motivo per cui Google ha scelto Mercurial, ovvero la maggior compatibilità con il protocollo HTTP, in rete sembra più facile trovare servizi che offrono hosting gratuito per progetti open source basandosi su hg.
  • Git da parte sua ha github l’hosting per progetti open source che personalmente preferisco in assoluto, diretto concorrente di Google code.

Infine vi lascio con qualche risorsa per i tre DVCS di cui ho parlato. Se vi interessa avere altre infomazioni su questo confronto vi consiglio di visitare Wikipedia inglese, in particolare: Comparison of revision control software e Comparison of open source software hosting facilities

Voi quale sistema di controllo di versione utilizzate? per quale motivo?

Git

Comando: git
Nota storica: Sviluppato da Linus Torvalds che dice di averlo chiamato così perchè “I’m an egotistical bastard, and I name all my projects after myself. First Linux, now git” in inglese git vuol dire qualcosa tipo stupido. E’ scritto in C e Perl
Progetti che lo utilizzano: Linux kernel, GNOME
Applicazione grafica: Tortoisegit (Windows) gitX (Mac OS X)
Sito ufficiale: git-scm.com
Guida: guida ufficiale , libro “Getting Good With Git” in inglese a 19$
Cheat sheet: GitCheatSheet, gitcheatsheet.pdf
Hosting gratutito per progetti open source: github.com, projectlocker.com, sourceforge.net, freepository.com

Mercurial

Comando: hg
Nota storica
: software creato da Matt Mackall e rilasciato con lincenza GNU nacque inzialmente per essere eseguito su Linux, successivamente furono fatte versioni anche per Windows, 2.0. É quasi completamente scritto in Python
Progetti che lo utilizzano: OpenOffice, Mozilla, Symbian
Applicazione grafica: TortoiseHg (Estensione per Windows Explorer e Nautilius), Murky (Mac OS X)
Sito ufficiale: mercurial.selenic.co
Guida: Bellissima guida a mercurial hginit.com (in inglese) Libro con anche ebook gratuito: hgbook.red-bean.com (in inglese)
Cheat sheet: Mercurial-Cheatsheet-Adrian-v1.0.pdf
Hosting gratutito per progetti open source: code.google.com/hosting, sourceforge.net, BerliOS

Bazaar

Comando: bzr
Nota storica: Sponsorizzato dalla canonical il rilascio della prima versione risale al dicembre del 2007 ma la sua storia è molto più lunga e trae origine dal progetto Baz abbandonato da tempo. Anche questo è scritto in Python e C.
Progetti che lo utilizzano: Ubuntu, MySql, Emacs
Applicazione grafica: Bazaar Explorer (multi piattaforma: GNOME, KDE, Windows, Mac OS X)
Sito ufficiale: bazaar.canonical.com
Guida: Guida ufficiale in inglese
Cheat sheet: quick-start-summary.svg
Hosting gratutito per progetti open source: sourceforge.net, launchpad.net

Introduzione al controllo di versione

QUANTE volte scrivendo il codice di un qualsiasi sorgente vi siete accorti che il lavoro delle ultime due ore era del tutto sbagliato e avreste voluto tornare indietro al codice di due ore prima, oppure non riuscite a capire per quale modifica il codice non funziona più. Bè se vi siete trovati in questa situazione allora avete bisogno del controllo di versione.

Il controllo di versione, o version control (VCS), è un software per la gestione di versioni differenti di un qualsiasi tipo di informazione (disegni, sorgenti, libri). In particolare nel campo della programmazione si occupa di tenere traccia di tutte le modifiche apportate ai file sorgente di un progetto software, questo può benissimo essere un sorgente scritto in C oppure un applicazione web o più semplicemente un plugin di WordPress, ma potrebbe benissimo essere un libro che stiamo scrivendo.

Il controllo di versione tenendo traccia di ogni modifica apportata consente di ritornare facilmente a vecchie versioni, di ricordarci ogni modifica che abbiamo apportato e di lavorare su versioni differenti dello stesso sorgente.

Solitamente il controllo di versione si utilizza su architetture di tipo client server. Ovvero c’è un server che contiene i repository (la raccolta di tutti i dati) e i client da remoto ci accedono per scaricare la copia locale su cui lavorare. Una volta finite le modifiche si “ricarica” la copia locale nel repository in modo da archiviare e volendo anche condividere le modifiche. Il modo più veloce per accedere ai repository è tramite linea di comando ma per chi non ci si trovasse bene esistono anche delle interfacce grafiche.

Un altra importantissima caratteristica è il supporto alla stesura collaborativa tra più persone dello stesso progetto, con il controllo di versione è possibile condividere gli stessi file sorgente sempre aggiornati e visualizzare chi ha modificato cosa. Alcuni software semplicemente impediscono a più persone contemporaneamente di modificare lo stesso file (lock) altri invece offrono strumenti (come il merge) per consentire l’unione di modfiche contemporanee dello stesso file e di risolvere eventuali conflitti che ne scaturiscono.

Dopo quest’introduzione vi presento un non esaustivo decisamente “alla mano” glossario e qualche risorsa per Subversione il software di controllo di versione più diffuso. In realtà questo post mi serviva per introdurre il prossimo che pubblicherò, nel quale confronterò tre VCS ovvero Git, Mercurial e Bazaar.

Glossario

Alcuni termini da conoscere che accomunano più o meno tutti i software di controllo di versione.
Commit: operazione con cui si carica la working copy nel repository
Repository: archivio dove risiede il progetto e tutte le revisioni, attraverso il quale è possibile risalire a revisioni precedenti, solitamente ci si accede da remoto.
Working Copy: è la copia locale del progetto a cui stiamo lavorando
Revision: è un numero che identifica ogni commit
Merge: è l’unione di modifiche concorrenti dello stesso file
Checkout: azione che si compie per scaricare in locale la working copy
Tagging: dare un preciso nome di versione ad una revisione
Branching: duplicare i dati sotto controllo di versione per portare avanti sviluppi paralleli dello stesso progetto
Log: registrazione cronologica di ogni operazione effettuata
Diff: comando per visualizzare le differenze tra due diverse revisioni

Subversion

Comando: svn
Nota storica: Naturale sucessore di CVS è nato nel 2000 ed è rilasciato sotto la stessa licenza di Apache. E’ forse il software per il controllo di versione più diffuso. Dal 2009 è stato incluso nei progetti dell’Apache software foundation.
Progetti che lo utilizzano: KDE, GCC, PHP
Applicazione grafica: TortoiseSVN (Windows) SvnX (MAC) kdesvn (KDE)
Sito ufficiale: subversion.apache.org
Guida: libro “Controllo di versione con Subversion” (quasi interamente tradotto in italiano)
Cheat sheet: Subversion-cheat-sheet.png
Hosting gratutito per progetti open source: code.google.com/hosting, projectlocker.com, freepository.com, sourceforge.net, BerliOS
Altro: molto comodo Subclipse il plugin per integrare SVN in Eclipse.