Un DVCS scritto in Python
Mercurial 1.0 è stato rilasciato il 19 marzo 2008 da Matt Mackall. Il progetto era partito nell’aprile 2005 — stessa settimana del primo commit di Git — come risposta della comunità all’abbandono di BitKeeper per lo sviluppo del kernel Linux. Mentre Linus Torvalds prendeva la strada di una riscrittura da zero in C, Matt Mackall sceglieva Python come linguaggio principale (con moduli critici in C per performance), privilegiando leggibilità ed estensibilità rispetto alla massima velocità.
La 1.0 formalizza tre anni di stabilizzazione: architettura dati, comandi utente, protocollo di rete. È distribuito con licenza GPLv2 (poi GPLv2+ con la 2.x).
L’architettura dati
Come Git, Mercurial è un DVCS — ogni clone contiene la storia completa del repository. A differenza di Git, il modello dati di Mercurial è più convenzionale:
- Storico come DAG di changeset, ciascuno identificato da un hash SHA-1
- Revlog come formato di storage — un append-only file per ogni tracked file + uno per il manifest, con delta incrementali
- Manifest per changeset — snapshot del filesystem a quel momento
- Branches nominati come attributo del changeset (non pointer mobili come in Git)
- Rename e copy tracking esplicito, non inferito da similarità
Il risultato è un sistema in cui le operazioni comuni sono prevedibili e documentabili. Un utente di CVS o Subversion trova in Mercurial un modello mentalmente più accessibile di quello di Git, con pari potenza sul piano distribuito.
Comandi e usabilità
I comandi principali — hg clone, hg pull, hg push, hg commit, hg update, hg log, hg diff, hg status, hg merge, hg branch, hg tag — hanno nomi e semantica ortogonali e coerenti. Ogni comando fa una sola cosa, senza modalità (contrariamente a Git, dove molti comandi hanno flag che ne cambiano radicalmente il comportamento).
Le extension (sottosistema ufficiale, ma anche terze parti) permettono di estendere Mercurial con funzionalità opzionali — mq (Mercurial Queues per patch management), rebase, churn, color, progress, transplant, hgk.
L’interfaccia web integrata hgweb fornisce un browser del repository senza dipendenze esterne.
Protocolli di rete
Mercurial supporta il trasporto via:
- HTTP(S) — attraverso
hg serveohgwebsu Apache/Nginx - SSH
- Filesystem locale (bundle files)
Il protocollo è efficiente sull’invio di changeset incrementali: cloni iniziali sono comparable a Git, pull successive sono ottimizzate.
Adozione istituzionale
Al 2008 Mercurial ha raccolto adozioni significative:
- Mozilla migra Firefox e Thunderbird da CVS a Mercurial nel 2007-2008
- OpenJDK (Sun Microsystems / poi Oracle) — migrazione dal 2007
- Python stesso — il linguaggio adotta Mercurial nel 2009 per il repository CPython, sostituendo Subversion
- Xen hypervisor
- Xen Project repository
- NetBeans (Sun)
- Numerosi progetti OCaml, Haskell, scientifici
La scelta è spesso motivata dalla curva di apprendimento più bassa rispetto a Git, dal fatto che tutti possono leggere il codice (Python) e contribuire al core, e dalla stabilità API delle extension.
Bitbucket
Nel 2008 viene lanciato Bitbucket come hosting dedicato a Mercurial — l’equivalente funzionale di GitHub per il mondo Hg. L’acquisizione da parte di Atlassian nel 2010 consolida il servizio, che aggiungerà support Git anni dopo.
La competizione GitHub/Bitbucket rispecchia in parte la competizione Git/Mercurial, con GitHub progressivamente prevalente.
Strumenti grafici
L’ecosistema Mercurial al 2008-2009 include:
- TortoiseHg — integrazione Windows Explorer (analogo a TortoiseSVN per SVN)
- hggit — extension per interoperabilità con repository Git
- Kiln (Fog Creek) — hosting enterprise Mercurial
- MacHg, SourceTree — client grafici
Il confronto con Git
A distanza di oltre dieci anni dalla release, il verdetto della comunità è che Git ha prevalso in adozione generale, ma Mercurial ha conservato una base di utilizzo consolidata in ambienti dove i suoi punti di forza sono apprezzati:
- Modello dati più semplice — curve di apprendimento inferiore
- Estendibilità in Python — plugin aziendali custom più semplici
- Performance comparabili su repository di medie dimensioni; Git vince su repository molto grandi grazie a ottimizzazioni C aggressive
- Storia immutabile di default — Mercurial rende più difficile riscrivere la storia dei changeset già pushati (eccetto tramite mq o hg strip), il che è apprezzato in ambienti dove l’audit trail è critico
Facebook/Meta è un caso particolare: ha investito massicciamente in Mercurial (sviluppando Sapling come evoluzione Mercurial-compatibile nei primi anni 2020) per gestire il proprio monorepo di scala eccezionale.
Nel contesto italiano
Al 2008 l’adozione italiana di Mercurial è modesta, con cluster di utilizzo:
- Gruppi di ricerca universitaria Python — il fatto che Mercurial sia Python e CPython lo usi come repo di riferimento porta naturalmente all’adozione
- Alcune software house specializzate in Java/Python che preferiscono l’usabilità Hg a Git
- Progetti internazionali (Mozilla, OpenJDK, Xen) con contribuzione italiana
Git si affermerà come scelta dominante in Italia negli anni 2010-2012 con l’effetto traino di GitHub; Mercurial manterrà utilizzo in progetti esistenti.
Il ruolo nella storia
Mercurial 1.0 dimostra che un DVCS di qualità può essere costruito con un linguaggio interpretato di alto livello senza compromessi sostanziali di performance per la stragrande maggioranza dei casi d’uso. Questa dimostrazione tecnica — che “Python è abbastanza veloce” per un’applicazione esigente come un sistema di controllo versione — ha influenza oltre lo specifico progetto: contribuisce a consolidare Python come linguaggio adatto a strumenti di sviluppo serio, non solo scripting o ricerca scientifica.
Riferimenti: Mercurial 1.0 (19 marzo 2008). Matt Mackall. Licenza GPLv2. Mozilla, OpenJDK, Python CPython, Xen come early adopters. Bitbucket (2008, poi Atlassian 2010). TortoiseHg.