Mercurial: la guida definitiva

Esiste un certo numero di ragioni per le quali voi o il vostro gruppo potreste voler usare uno strumento automatico per il controllo di revisione su un progetto.

La maggior parte di queste ragioni sono altrettanto valide—almeno in teoria—sia che lavoriate su un progetto da soli sia che collaboriate insieme a un centianio di altre persone.

Un aspetto chiave della praticità del controllo di revisione a queste due dimensioni di sviluppo differenti («programmatore solitario» e «gruppo gigantesco») è il confronto tra i suoi benefici e i suoi costi. Uno strumento di controllo di revisione che sia difficile da capire e usare finirà per imporre un costo piuttosto alto.

È probabile che un progetto di cinquecento persone collassi quasi immediatamente sotto il proprio peso senza un processo e uno strumento di controllo di revisione. In questo caso, il costo di usare il controllo di revisione potrebbe sembrare difficilmente meritevole di considerazione, dato che senza di esso il fallimento del progetto è quasi garantito.

D’altra parte, il «lavoretto veloce» di una singola persona potrebbe sembrare il contesto meno adatto per impiegare uno strumento di controllo di revisione, perché sicuramente il costo di usarne uno deve essere vicino al costo complessivo del progetto. Giusto?

Mercurial supporta in maniera unica entrambe queste dimensioni di sviluppo. Potete impararne le basi in pochi minuti appena, e grazie al suo basso costo di gestione potete applicare il controllo di revisione al più piccolo dei progetti con facilità. La sua semplicità vi permetterà di concentrarvi su qualunque cosa stiate davvero cercando di fare senza distrarvi con schiere di concetti astrusi o lunghe sequenze di comandi. Allo stesso tempo, le elevate prestazioni e la natura peer-to-peer di Mercurial vi permetteranno di scalare in maniera indolore per gestire grandi progetti.

Nessuno strumento di controllo di revisione può salvare un progetto gestito male, ma la scelta degli strumenti adeguati può fare una notevole differenza nella facilità con cui potete lavorare su un progetto.

Il controllo di revisione è un campo talmente vario che vi si fa spesso riferimento attraverso diversi nomi e acronimi. Ecco alcune delle variazioni più comuni che incontrerete:

Alcune persone affermano che questi termini in realtà abbiano significati differenti, ma in pratica essi si sovrappongono così tanto che non c’è alcun modo concordato o persino utile di distinguerli.

Se siete affascinati da un progetto open source e decidete che vi piacerebbe cominciare a lavorarci sopra, e quel progetto usa uno strumento distribuito di controllo di revisione, potete immediatamente operare su un piano di parità con il gruppo di persone che si considerano il «cuore» di quel progetto. Se il gruppo pubblica il proprio repository, potete immediatamente copiare la cronologia del progetto, cominciare a effettuare modifiche e registrare il vostro lavoro utilizzando gli stessi strumenti allo stesso modo dei membri del gruppo. Al contrario, con uno strumento centralizzato, siete costretti a usare il software in modalità di «sola lettura» a meno che qualcuno non vi conceda il permesso di inserire i vostri cambiamenti sul server centrale. Fino a quel momento non sarete in grado di registrare i cambiamenti, e le vostre modifiche rischieranno di venire rovinate ogni volta che provate ad aggiornare la vista del repository dal vostro client.

Molti progetti commerciali vengono intrapresi da gruppi i cui membri sono sparpagliati attraverso il globo. I collaboratori lontani da un server centrale soffriranno un maggiore lentezza nell’esecuzione dei comandi e forse una minore affidabilità. I sistemi commerciali di controllo di revisione tentano di mitigare questi problemi tramite componenti aggiuntivi per la replicazione di siti remoti che sono tipicamente costosi da acquistare e complicati da amministrare. Un sistema distribuito non soffre di questi problemi in prima istanza. Ancora meglio, potete facilmente configurare molteplici server autoritativi, diciamo uno per ogni sito, in modo che non ci siano comunicazioni ridondanti tra i repository durante i costosi collegamenti di rete a grande distanza.

I sistemi centralizzati di controllo di revisione tendono ad avere una scalabilità relativamente bassa. Non è inusuale che un costoso sistema centralizzato cada sotto il carico combinato di una sola dozzina di utenti concorrenti. Ancora una volta, la tipica contromisura tende a essere un dispositivo di replicazione costoso e macchinoso. Dato che con uno strumento distribuito il carico su un server centrale—sempre che ne abbiate uno—è molto più basso (perché tutti i dati sono replicati ovunque), un singolo server economico può gestire i bisogni di un gruppo di lavoro molto più grande, e la replicazione per il bilancio del carico diventa una semplice questione di programmazione.

I vostri impiegati potranno beneficiare del controllo di versione distribuito anche quando si trovano nella sede di un cliente per risolvere un problema in loco. Gli strumenti permetteranno loro di generare versioni personalizzate del software nel repository, provare soluzioni differenti isolandole l’una dall’altra e cercare in maniera efficiente attraverso la cronologia delle revisioni le sorgenti di bug e regressioni nell’ambiente del cliente, il tutto senza aver bisogno di collegarsi alla rete della vostra azienda.

Subversion è un sistema di controllo di revisione piuttosto popolare, sviluppato per sostituire CVS. Ha un’architettura client/server centralizzata.

Subversion e Mercurial hanno comandi con nomi simili per effettuare le stesse operazioni, così se avete familiarità con uno dei due è facile imparare a usare l’altro. Entrambi gli strumenti sono portabili su tutti i sistemi operativi più popolari.

Prima della versione 1.5, Subversion non aveva alcun supporto efficace per le unioni. Al momento della scrittura, la sua funzione per la gestione delle unioni è nuova e nota per essere complicata e difettosa.

Mercurial ha un sostanzioso vantaggio in termini di prestazioni rispetto a Subversion per tutte le operazioni di controllo di revisione di cui ho effettuato il benchmark. Il suo vantaggio si misura in un intervallo che va da un fattore due a un fattore sei quando lo si confronta con il modulo ra_local di Subversion 1.4.3, che lavora con repository locali ed è quindi il metodo di accesso più veloce disponibile. In situazioni più realistiche che coinvolgono un accesso al repository attraverso la rete, Subversion sconterà uno svantaggio sostanzialmente più consistente. Dato che molti comandi di Subversion devono comunicare con il server e Subversion non è dotato di meccanismi di replicazione efficaci, la capacità del server e la banda di rete diventano colli di bottiglia già per progetti di dimensioni moderate.

In più, Subversion si espone a un sostanziale utilizzo aggiuntivo di spazio su disco per evitare transazioni di rete durante l’esecuzione di alcune operazioni comuni, come trovare i file modificati (status) e visualizzare le modifiche rispetto alla revisione corrente (diff). Come risultato, la copia di lavoro di un repository Subversion è spesso delle stesse dimensioni, se non più grande, di un intero repository Mercurial più la sua directory di lavoro, anche nel caso in cui il repository Mercurial contenga la cronologia completa del progetto.

Subversion è ampiamente supportato da strumenti di terze parti. Mercurial è considerevolmente indietro in quest’area. Il divario si sta assottigliando, tuttavia, e in effetti alcuni degli strumenti di interfaccia grafica di Mercurial attualmente offuscano i loro equivalenti per Subversion. Come Mercurial, Subversion è dotato di un eccellente manuale d’uso.

Dato che Subversion non memorizza la cronologia di revisione sul client, è molto adatto a gestire progetti che hanno a che fare con numerosi file binari di grandi dimensioni. Se aggiungete cinquanta revisioni di un file incomprimibile di 10MB a un repository, l’utilizzo di spazio sul lato client da parte di Subversion rimarrà costante. Lo spazio usato da qualunque SCM distribuito crescerà rapidamente in proporzione al numero delle revisioni, perché le differenze tra una revisione e l’altra sono grandi.

In più, è spesso difficile, o più tipicamente impossibile, unire differenti versioni di un file binario. L’abilità di Subversion di permettere a un utente di bloccare un file, in modo da ottenere temporaneamente i diritti esclusivi per modificarlo, può essere un vantaggio significativo in progetti dove i file binari vengono largamente utilizzati.

Mercurial può importare la cronologia delle revisioni da un repository Subversion. Può anche esportare la propria cronologia delle revisioni verso un repository Subversion. Questa caratteristica vi permette di «sentire l’acqua» utilizzando Mercurial e Subverison in parallelo prima di decidere di cambiare. La conversione della cronologia è incrementale, così potete effettuare una conversione iniziale, poi piccole conversioni aggiuntive per introdurre successivamente nuovi cambiamenti.

Git è uno strumento per il controllo di revisione distribuito che è stato sviluppato per gestire l’albero dei sorgenti del kernel di Linux. Come Mercurial, il suo design iniziale è stato in qualche modo influenzato da Monotone.

Git possiede un insieme di comandi piuttosto ampio, con la versione 1.5.0 che fornisce 139 singoli comandi. Si è fatto una certa reputazione di essere difficile da imparare. Rispetto a Git, Mercurial pone una maggiore attenzione alla semplicità.

In termini di prestazioni, Git è estremamente veloce. In molti casi, è più veloce di Mercurial, almeno sotto Linux, mentre Mercurial è più prestante per altre operazioni. Tuttavia, sotto Windows, le prestazioni e il livello generale di supporto offerto da Git sono, al momento della scrittura, molto più indietro rispetto a Mercurial.

Mentre un repository Mercurial non ha bisogno di alcuna manutenzione, un repository Git richiede frequenti «reimpacchettamenti» manuali dei propri metadati. Senza questi, le prestazioni degradano e l’utilizzo di spazio cresce rapidamente. Le prestazioni di un server che contiene molti repository Git che non vengono rigorosamente e frequentemente reimpacchettati diventeranno pesantemente legate all’utilizzo del disco durante i backup, risultando in istanze di backup giornalieri che impiegano molto più di 24 ore per terminare. Un repository Git appena impacchettato è leggermente più piccolo di un repository Mercurial, ma un repository non impacchettato ha dimensioni maggiori di diversi ordini di grandezza.

Il cuore di Git è scritto in C. Molti comandi di Git sono implementati come script di shell o in linguaggio Perl la cui qualità è notevolmente variabile. Ho incontrato diversi casi in cui gli script proseguivano ciecamente la propria esecuzione in presenza di errori che avrebbero dovuto essere fatali.

Mercurial può importare la cronologia di revisione da un repository Git.

CVS è probabilmente lo strumento di controllo di revisione più usato nel mondo. A causa della sua età e della sporcizia interna, è stato mantenuto solo superficialmente per diversi anni.

Ha un’architettura client/server centralizzata. Non raggruppa cambiamenti di file correlati in inserimenti atomici, esponendo gli utenti al rischio di «guastare il software»: una persona può inserire con successo parte di un cambiamento e poi essere bloccata dalla necessità di un’unione, vincolando altre persone a vedere solo una porzione del lavoro che intendeva fare. Questo influisce anche sul modo di lavorare con la cronologia del progetto. Se volete vedere tutte le modifiche che qualcuno ha effettuato come parte di un’attività, dovrete ispezionare manualmente le descrizioni e le marcature temporali dei cambiamenti fatti a ogni file coinvolto (sempre che sappiate quali fossero quei file).

CVS ha una nozione confusa di etichette e rami di lavoro che non cercherò nemmeno di descrivere. Non gestisce per bene il cambiamento dei nomi di file o directory, esponendo il repository al rischio di danneggiamenti. Non ha quasi alcuna funzionalità per il controllo della consistenza interna, quindi tipicamente non è nemmeno possibile dire se un repository è danneggiato. Non raccomanderei CVS per nessun progetto, nuovo o esistente.

Mercurial può importare la cronologia di revisione da un repository CVS. Tuttavia, ci sono alcune avvertenze da considerare, valide anche per qualsiasi altro strumento di controllo di revisione che importi dati da CVS. A causa della mancanza di inserimenti atomici in CVS e della mancanza di versioni per la gerarchia dei file, non è possibile ricostruire la cronologia di CVS in maniera completa e accurata, bensì devono essere fatte alcune supposizioni, e le modifiche ai nomi dei file di solito non verranno mostrate. Dato che buona parte dell’amministrazione avanzata di CVS deve essere fatta a mano e quindi è soggetta a errori, i programmi che importano dati da CVS incorrono comunemente in molteplici problemi dovuti a repository danneggiati (marcature temporali completamente fasulle per le revisioni e file che sono rimasti bloccati per più di un decennio sono solo due dei problemi meno interessanti che posso ricordare dalla mia esperienza personale).

Perforce ha un’architettura client/server centralizzata in cui nessun dato viene memorizzato sul lato client. A differenza degli strumenti di controllo di revisione moderni, Perforce richiede che l’utente esegua un comando per comunicare al server di voler modificare un qualsiasi file.

Le prestazioni di Perforce sono piuttosto buone per piccoli gruppi di lavoro, ma decadono rapidamente man mano che il numero di utenti cresce oltre le poche dozzine. Installazioni di Perforce di modeste dimensioni richiedono l’utilizzo di proxy per fronteggiare il carico generato dai propri utenti.

Con l’eccezione di CVS, tutti gli strumenti appena elencati hanno qualità uniche che li rendono adatti a particolari stili di lavoro. Non esiste un singolo strumento di controllo di revisione che sia il migliore in tutte le situazioni.

Per fare un esempio, Subversion è una buona scelta per chi lavora con file binari frequentemente modificati, a causa della sua natura centralizzata e del supporto per il bloccaggio dei file.

Personalmente trovo che le caratteristiche di Mercurial, come la semplicità, le prestazioni e un buon supporto per le unioni, siano una combinazione irresistibile che mi ha servito bene per diversi anni.

La miglior versione di Mercurial per Windows è TortoiseHg, che può essere trovata all’indirizzo http://bitbucket.org/tortoisehg/stable/wiki/Home. Questo pacchetto non ha dipendenze esterne ed è pronto a funzionare non appena viene installato. Fornisce sia un’interfaccia a linea di comando sia un’interfaccia grafica.

Lee Cantey fornisce un pacchetto di installazione di Mercurial per Mac OS X all’indirizzo http://mercurial.berkwood.com.

Dato che ogni distribuzione Linux ha i propri stumenti di impacchettamento, le proprie politiche e il proprio ritmo di sviluppo, è difficile dare un insieme completo di istruzioni su come installare i pacchetti eseguibili di Mercurial. La versione di Mercurial che finirete per ottenere può variare a seconda di quanto sia attiva la persona che mantiene il pacchetto di installazione per la vostra distribuzione.

Per semplificare le cose, mi concentrerò sull’installazione di Mercurial dalla linea di comando sulle distribuzioni Linux più popolari. La maggior parte di queste distribuzioni fornisce un gestore grafico per i pacchetti di installazione che vi permetterà di installare Mercurial con un singolo click sulla voce relativa al pacchetto chiamato mercurial.

SunFreeWare, all’indirizzo http://www.sunfreeware.com, allestisce pacchetti precompilati di Mercurial.

Mercurial include un sistema di aiuto predefinito che si rivela inestimabile quando vi trovate bloccati cercando di ricordare come si esegue un comando. Se siete completamente bloccati, provate a invocare hg help per visualizzare una breve lista di comandi insieme a una descrizione delle funzionalità di ognuno. Se chiedete aiuto per un comando specifico (come nell’esempio seguente), verranno stampate informazioni più dettagliate.

$ hg help init
hg init [-e CMD] [--remotecmd CMD] [DEST]

crea un nuovo repository nella directory data

    Inizializza un nuovo repository nella directory data. Se questa
    directory non esiste, viene creata.

    Se non viene data alcuna directory, il comando usa la directory
    corrente.

    È possibile specificare un URL ssh:// come destinazione.
    Si veda 'hg help urls' per maggiori informazioni.

opzioni:

 -e --ssh        specifica il comando ssh da usare
    --remotecmd  specifica il comando hg da eseguire in remoto

usate "hg -v help init" per vedere le opzioni globali

Per ottenere un livello di dettaglio ancora maggiore (che di solito non vi servirà) eseguite hg help -v. L’opzione -v è l’abbreviazione di --verbose e dice a Mercurial di stampare più informazioni di quanto farebbe di solito.

Copiare un repository è in realtà un’operazione un po’ speciale. Pur potendo usare un normale comando di copia dei file per copiare un repository, il modo migliore per farlo è quello di usare un comando predefinito fornito da Mercurial. Questo comando si chiama hg clone, perché crea una copia identica di un repository esistente.

$ hg clone http://hg.serpentine.com/tutorial/hello
directory di destinazione: hello
richiedo tutte le modifiche
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 5 changeset con 5 cambiamenti a 2 file
aggiorno la directory di lavoro
2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti

Come possiamo vedere qui sopra, il comando hg clone ha il vantaggio di poter clonare un repository attraverso la rete. Un altro vantaggio di questo comando è quello di ricordare da dove abbiamo effettuato la copia, cosa che ci tornerà utile molto presto quando vorremo prelevare nuovi cambiamenti da un altro repository.

Se la nostra clonazione ha avuto successo, ora dovremmo avere una directory locale chiamata hello. Questa directory contiene alcuni file.

$ ls -l
total 4
drwxrwxr-x 3 bos bos 4096 May  5 06:55 hello
$ ls hello
Makefile  hello.c

Il contenuto e la cronologia di questi file nel nostro repository sono gli stessi di quelli presenti nel repository che abbiamo clonato.

Ogni repository Mercurial contiene la propria copia privata dei file e della cronologia di un progetto ed è sempre completo, auto-contenuto e indipendente. Come abbiamo appena detto, il clone di un repository ricorda l’ubicazione del repository da cui è stato clonato, ma Mercurial non comunicherà con quel repository, o con qualsiasi altro repository, a meno che non siamo noi a chiederlo.

Per ora, questo significa che siamo liberi di effettuare esperimenti con il nostro repository, sapendo con sicurezza che è un «ambiente di prova» privato le cui variazioni non avranno effetto su nessun altro.

Se diamo un’occhiata più dettagliata all’interno di un repository, possiamo vedere che contiene una directory chiamata .hg. Questo è il luogo dove Mercurial tiene tutti i propri metadati sul repository.

$ cd hello
$ ls -a
.  ..  .hg  Makefile  hello.c

Il contenuto della directory .hg e delle sue sottodirectory è riservato a Mercurial. Tutti gli altri file e directory nel repository sono vostri e potete farne ciò che volete.

Per introdurre un po’ di terminologia, diciamo che la directory .hg è il repository «reale» e che tutti gli altri file e directory che coesistono con esso si trovano nella directory di lavoro. Potete ricordare facilmente questa distinzione se considerate che il repository contiene la cronologia del progetto, mentre la directory di lavoro contiene una fotografia del vostro progetto in un punto particolare della cronologia.

Dato che l’inglese è una lingua notoriamente trasandata e che l’informatica ha una storia consacrata alla confusione terminologica (perché usare un solo termine quando se ne possono usare quattro?), il controllo di revisione impiega una varietà di termini ed espressioni per indicare la stessa cosa. Se parlate della cronologia di Mercurial con altre persone, scoprirete che il termine «changeset» è spesso abbreviato in «change» (in italiano, cambiamento) o in «cset» (nella sua forma scritta) e che talvolta ci si riferisce a un changeset chiamandolo «revisione» oppure «rev».

Mentre non ha importanza quale parola voi usiate per riferirvi al concetto di «un changeset», l’identificatore che usate per riferirvi a «uno specifico changeset» è di grande importanza. Ricordatevi che il campo changeset nel riepilogo mostrato da hg log identifica un changeset utilizzando sia un numero che una stringa esadecimale.

Questa distinzione è importante. Se spedite un’email a qualcuno parlando della «revisione 33», c’è un’alta probabilità che la sua revisione 33 non sia la stessa della vostra, perché un numero di revisione dipende dall’ordine in cui i cambiamenti sono stati introdotti in un repository e non c’è alcuna garanzia che gli stessi cambiamenti siano avvenuti nello stesso ordine in repository differenti. Tre cambiamenti a,b,c possono facilmente comparire in un repository come 0,1,2 e in un altro repository come 0,2,1.

Mercurial usa i numeri di revisione soltanto come un’abbreviazione di convenienza. Se avete bisogno di discutere un changeset con qualcuno o di indicare un changeset per qualche altra ragione (per esempio, nella segnalazione di un bug), usate l’identificatore esadecimale.

Per ridurre l’elenco stampato dal comando hg log a una singola revisione, usate l’opzione -r (o --rev). Potete usare sia un numero di revisione che un identificatore esadecimale e potete fornire al comando tutte le revisioni che volete.

$ hg log -r 3
changeset:   3:0272e0d5a517
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Sat Aug 16 22:08:02 2008 +0200
sommario:    Induce make a generare l'eseguibile finale dal file .o.

$ hg log -r 0272e0d5a517
changeset:   3:0272e0d5a517
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Sat Aug 16 22:08:02 2008 +0200
sommario:    Induce make a generare l'eseguibile finale dal file .o.

$ hg log -r 1 -r 4
changeset:   1:82e55d328c8c
utente:      mpm@selenic.com
data:        Fri Aug 26 01:21:28 2005 -0700
sommario:    Crea un makefile.

changeset:   4:2278160e78d4
etichetta:   tip
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Sat Aug 16 22:16:53 2008 +0200
sommario:    Aggiusta i commenti.

Se volete vedere la cronologia di diverse revisioni senza doverle elencare tutte potete usare la notazione di intervallo, che vi permette di esprimere l’idea di operare su «tutte le revisioni tra abc e def comprese».

$ hg log -r 2:4
changeset:   2:fef857204a0c
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Sat Aug 16 22:05:04 2008 +0200
sommario:    Introduce un errore in hello.c.

changeset:   3:0272e0d5a517
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Sat Aug 16 22:08:02 2008 +0200
sommario:    Induce make a generare l'eseguibile finale dal file .o.

changeset:   4:2278160e78d4
etichetta:   tip
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Sat Aug 16 22:16:53 2008 +0200
sommario:    Aggiusta i commenti.

Mercurial rispetta anche l’ordine in cui specificate le revisioni, quindi il comando hg log -r 2:4 stamperà le revisioni 2, 3 e 4, mentre il comando hg log -r 4:2 stamperà le revisioni 4, 3 e 2.

Mentre le informazioni di riepilogo stampate da hg log sono utili se sapete già cosa state cercando, potreste aver bisogno di vedere una descrizione completa del cambiamento, o una lista dei file modificati, nel caso stiate tentando di capire se il changeset è quello che volevate. L’opzione -v (o --verbose) del comando hg log vi fornisce questi dettagli aggiuntivi.

$ hg log -v -r 3
changeset:   3:0272e0d5a517
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Sat Aug 16 22:08:02 2008 +0200
file:        Makefile
descrizione:
Induce make a generare l'eseguibile finale dal file .o.

Se volete vedere sia la descrizione che il contenuto di un cambiamento, aggiungete l’opzione -p (o --patch). In questo modo il contenuto del cambiamento verrà stampato come un diff unificato (se non avete mai visto un diff unificato prima d’ora, date un’occhiata alla Sezione 12.4, «Capire le patch» per un’introduzione).

$ hg log -v -p -r 2
changeset:   2:fef857204a0c
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Sat Aug 16 22:05:04 2008 +0200
file:        hello.c
descrizione:
Introduce un errore in hello.c.


diff -r 82e55d328c8c -r fef857204a0c hello.c
--- a/hello.c	Fri Aug 26 01:21:28 2005 -0700
+++ b/hello.c	Sat Aug 16 22:05:04 2008 +0200
@@ -11,6 +11,6 @@
 
 int main(int argc, char **argv)
 {
-	printf("ciao, mondo!\n");
+	printf("ciao, mondo!\");
 	return 0;
 }

L’opzione -p è tremendamente utile, quindi merita di essere ricordata.

Quando provate a eseguire hg commit per la prima volta, non c’è alcuna garanzia che il comando abbia successo. Mercurial registra il vostro nome e indirizzo con ogni cambiamento che inserite, in modo che più tardi voi e gli altri siate in grado di dire chi lo ha effettuato. Mercurial prova a costruire automaticamente un nome utente ragionevole da usare per l’inserimento. Proverà ognuno dei seguenti metodi, in questo ordine.

Se tutti questi meccanismi falliscono, Mercurial si fermerà stampando un messaggio di errore. In questo caso, non vi permetterà di eseguire il commit fino a quando non avrete impostato il vostro nome utente.

Dovreste considerare la variabile d’ambiente HGUSER e l’opzione -u del comando hg commit come modi per rimpiazzare la selezione predefinita del nome utente da parte di Mercurial. Normalmente, il modo più semplice e robusto per impostare il vostro nome utente è quello di creare un file .hgrc.

2.7.1.1. Creare un file di configurazione per Mercurial

Per impostare un nome utente, usate il vostro editor preferito e create un file chiamato .hgrc nella vostra directory personale. Mercurial userà questo file per cercare le vostre impostazioni di configurazione personalizzate. Il contenuto iniziale del vostro file .hgrc dovrebbe somigliare al seguente.

	La «directory personale» sotto Windows
	In una installazione italiana di Windows, la vostra directory personale di solito corrisponde a una cartella chiamata con il vostro nome utente che si trova in C:\Documents and Settings. Potete scoprire l’esatto nome della vostra directory personale aprendo una finestra del prompt dei comandi e invocando il comando seguente. C:\> echo %UserProfile%

# Questo è un file di configurazione per Mercurial.
[ui]
username = Nome Cognome <indirizzo.email@example.org>

La riga «[ui]» comincia una sezione del file di configurazione, così potete leggere la riga «username = ...» con il significato di «imposta il valore dell’elemento username nella sezione ui». Una sezione continua fino a quando ne comincia una nuova o fino alla fine del file. Mercurial ignora le righe vuote e tratta il testo di ogni riga che comincia con il carattere «#» come un commento.

2.7.1.2. Scegliere un nome utente

Potete usare il testo che preferite come valore dell’elemento di configurazione username, dato che questa informazione serve per essere letta da altre persone e non verrà interpretata da Mercurial. La convenzione seguita dalla maggior parte delle persone è quella di usare il proprio nome e indirizzo email, come nell’esempio precedente.

	Nota
	Il server web predefinito di Mercurial offusca gli indirizzi email, per rendere la vita difficile agli strumenti che gli spammer usano per raccogliere nuovi indirizzi. Questo riduce la possibilità che cominciate a ricevere una maggior quantità di spazzatura nella vostra casella email se pubblicate un repository Mercurial sul web.

Quando inseriamo un cambiamento, Mercurial apre un editor di testo per farci scrivere un messaggio di commit allo scopo di descrivere le modifiche che abbiamo effettuato in questo changeset. Il messaggio verrà registrato per i lettori interessati a sapere quello che abbiamo fatto e perché, e verrà stampato dalle invocazioni di hg log successive alla terminazione dell’inserimento.

$ hg commit

L’editor aperto dal comando hg commit conterrà una o due righe vuote, seguite da un certo numero di righe che cominciano con «HG:».

Potete digitare qui il vostro messaggio di commit.

HG: Inserite un messaggio di commit. Le righe che cominciano con 'HG:' verranno rimosse.
HG: --
HG: utente: Bryan O'Sullivan <bos@serpentine.com>
HG: ramo 'default'
HG: modificato hello.c

Mercurial ignora le righe che cominciano con «HG:» e le usa solamente per dirci a quali file appartengono i cambiamenti che sta per registrare. Modificare o cancellare quelle righe non ha alcun effetto.

Dato che hg log stampa per default solo la prima riga del messaggio di commit, è meglio scrivere un messaggio di commit in cui la prima riga stia in piedi da sola. Ecco un esempio reale di un messaggio di commit che non segue questa linea guida e che quindi presenta un riepilogo incomprensibile.

changeset:   73:584af0e231be
utente:      Persona Censurata <persona.censurata@example.org>
data:        Tue Sep 26 21:37:07 2006 -0700
sommario:    incluso buildmeister/commondef. Aggiunti gli export.

Non ci sono regole ferree da seguire per quanto riguarda il resto del contenuto del messaggio di commit. Lo stesso Mercurial non interpreta né si occupa del contenuto del messaggio, sebbene il vostro progetto possa adottare politiche che vi obbligano a un certo tipo di formattazione.

Personalmente, prediligo messaggi di commit brevi ma informativi che mi dicano qualcosa che non sono in grado di capire attraverso una veloce occhiata al risultato del comando hg log --patch.

Se eseguiamo hg commit senza argomenti, il comando registra tutti i cambiamenti che abbiamo effettuato, come segnalati dai comandi hg status e hg diff.

	Una sorpresa per gli utenti Subversion
	Come altri comandi Mercurial, hg commit opererà su tutta la directory di lavoro del repository se non forniamo esplicitamente al comando i nomi dei file da inserire. Dovete fare attenzione a questa particolarità se venite dal mondo Subversion o CVS, perché potreste aspettarvi di operare solo nella directory corrente in cui vi trovate e nelle sue sottodirectory.

Se decidete di non voler eseguire l’inserimento mentre state scrivendo il messaggio di commit, vi basta uscire dal vostro editor senza salvare il file che contiene il messaggio. Questo eviterà che il repository e la directory di lavoro vengano alterati in alcun modo.

Una volta che abbiamo terminato l’inserimento, possiamo usare il comando hg tip per visualizzare il changeset che abbiamo appena creato. Questo comando produce una stampa identica a quella del comando hg log, ma mostra solamente la revisione più recente nel repository.

$ hg tip -vp
changeset:   5:764347e47e75
etichetta:   tip
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:51:52 2009 +0000
file:        hello.c
descrizione:
Inserisce una riga con un messaggio aggiuntivo.


diff -r 2278160e78d4 -r 764347e47e75 hello.c
--- a/hello.c	Sat Aug 16 22:16:53 2008 +0200
+++ b/hello.c	Fri Jun 05 15:51:52 2009 +0000
@@ -8,5 +8,6 @@
 int main(int argc, char **argv)
 {
 	printf("ciao, mondo!\");
+	printf("ancora ciao!\n");
 	return 0;
 }

Ci riferiremo alla revisione più recente nel repository come alla revisione di punta, o semplicemente la punta.

Notate che il comando hg tip accetta molte delle stesse opzioni viste per hg log, quindi l’opzione -v nell’esempio precedente chiede al comando di «essere verboso» e l’opzione -p specifica di «stampare una patch». L’uso di -p per stampare le patch è un altro esempio della denominazione consistente che avevamo menzionato in precedenza.

Per cominciare, cloniamo il nostro repository hello originale, che non contiene la modifica che abbiamo appena introdotto. Chiameremo hello-estrazione il nostro repository temporaneo.

$ cd ..
$ hg clone hello hello-estrazione
aggiorno la directory di lavoro
2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti

Useremo il comando hg pull per propagare i cambiamenti dal repository mio-hello al repository hello-estrazione. Tuttavia, estrarre alla cieca cambiamenti sconosciuti da un repository è una prospettiva che può incutere qualche timore. Mercurial fornisce il comando hg incoming proprio allo scopo di elencare quali cambiamenti verrebbero estratti dal repository senza effettivamente procedere con l’operazione.

$ cd hello-estrazione
$ hg incoming ../mio-hello
confronto con ../mio-hello
cerco i cambiamenti
changeset:   5:764347e47e75
etichetta:   tip
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:51:52 2009 +0000
sommario:    Inserisce una riga con un messaggio aggiuntivo.

Propagare i cambiamenti in un repository è semplicemente questione di eseguire il comando hg pull, dicendogli opzionalmente da quale repository compiere l’estrazione.

$ hg tip
changeset:   4:2278160e78d4
etichetta:   tip
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Sat Aug 16 22:16:53 2008 +0200
sommario:    Aggiusta i commenti.

$ hg pull ../mio-hello
estraggo da ../mio-hello
cerco i cambiamenti
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 1 cambiamenti a 2 file
(eseguite 'hg update' per ottenere una copia di lavoro)
$ hg tip
changeset:   5:764347e47e75
etichetta:   tip
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:51:52 2009 +0000
sommario:    Inserisce una riga con un messaggio aggiuntivo.

Come potete vedere se confrontate il risultato di hg tip prima e dopo, abbiamo propagato con successo i cambiamenti nel nostro repository. Tuttavia, Mercurial separa l’operazione di estrazione dei cambiamenti da quella di aggiornamento della directory di lavoro. Rimane ancora un passo da fare prima di poter vedere i cambiamenti appena estratti comparire nella directory di lavoro.

Estrarre cambiamenti specifici

È possibile che, a causa del ritardo tra l’esecuzione di hg incoming e hg pull, non riusciate vedere tutti i changeset che verranno prelevati dall’altro repository. Supponete di voler estrarre cambiamenti da un repository che si trovi in rete da qualche parte. Mentre state osservando il risultato di hg incoming, ma prima che riusciate a estrarre quei cambiamenti, qualcuno potrebbe aver inserito qualcosa nel repository remoto. Questo significa che è possibile estrarre più cambiamenti di quelil esaminati tramite hg incoming. Se volete estrarre solamente quei particolari cambiamenti che sono stati elencati da hg incoming, o avete qualche altra ragione per estrarre un sottoinsieme dei cambiamenti, è sufficiente utilizzare l’identificatore di changeset del cambiamento che volete estrarre, e.g. hg pull -r7e95bb.

Finora abbiamo glissato sulla relazione tra il repository e la sua directory di lavoro. Il comando hg pull che abbiamo eseguito nella Sezione 2.8.1, «Estrarre i cambiamenti da altri repository» ha propagato i cambiamenti nel repository ma, se controlliamo, non c’è alcuna traccia di quei cambiamenti nella directory di lavoro. Questo accade perché il comportamento predefinito di hg pull prevede di non modificare la directory di lavoro. Per fare questo, dobbiamo invece usare il comando hg update.

$ grep printf hello.c
	printf("ciao, mondo!\");
$ hg update tip
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ grep printf hello.c
	printf("ciao, mondo!\");
	printf("ancora ciao!\n");

Potrebbe sembrare un po’ strano che hg pull non aggiorni automaticamente la directory di lavoro, ma c’è una buona ragione per questo: hg update è in grado di aggiornare la directory di lavoro allo stato in cui era in qualsiasi revisione contenuta nella cronologia del repository. Se la vostra directory di lavoro fosse stata aggiornata a una vecchia revisione—per cercare l’origine di un bug, diciamo—potreste non essere terribilmente contenti di vedere il comando hg pull da voi eseguito aggiornare automaticamente la directory di lavoro a una nuova revisione.

Dato che la sequenza di estrazione e aggiornamento è così comune, Mercurial vi permette di combinare le due operazioni passando l’opzione -u al comando hg pull.

Se tornate indietro alla Sezione 2.8.1, «Estrarre i cambiamenti da altri repository» e osservate il testo visualizzato dal comando hg pull eseguito senza l’opzione -u, potete vedere che contiene un promemoria utile a ricordarci che dobbiamo effettuare un passo esplicito per aggiornare la directory di lavoro.

Per scoprire a quale revisione è aggiornata la directory di lavoro, usate il comando hg parents.

$ hg parents
changeset:   5:764347e47e75
etichetta:   tip
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:51:52 2009 +0000
sommario:    Inserisce una riga con un messaggio aggiuntivo.

Se tornate indietro a guardare la Figura 2.1, «Rappresentazione grafica della cronologia per il repository hello», vedrete che ogni changeset è collegato da frecce. Ogni nodo da cui parte una freccia è un genitore e il nodo corrispondente a cui la freccia arriva è suo figlio. Analogamente, anche la directory di lavoro possiede un genitore, che è il changeset contenuto nella directory in quel momento.

Per aggiornare la directory di lavoro a una particolare revisione, fornite un numero di revisione o un identificatore di changeset al comando hg update.

$ hg update 2
2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ hg parents
changeset:   2:fef857204a0c
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Sat Aug 16 22:05:04 2008 +0200
sommario:    Introduce un errore in hello.c.

$ hg update
2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ hg parents
changeset:   5:764347e47e75
etichetta:   tip
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:51:52 2009 +0000
sommario:    Inserisce una riga con un messaggio aggiuntivo.

Se omettete una revisione esplicita, hg update effettuerà l’aggiornamento alla revisione più recente (la revisione di punta), come mostrato nella seconda invocazione di hg update nell’esempio precedente.

Mercurial ci permette di trasmettere i nostri cambiamenti dal repository in cui ci troviamo verso un altro repository. Come per l’esempio del comando hg pull appena illustrato, creeremo un repository temporaneo a cui trasmettere i nostri cambiamenti.

$ cd ..
$ hg clone hello hello-trasmissione
aggiorno la directory di lavoro
2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti

Il comando hg outgoing ci dice quali cambiamenti verrebbero trasmessi verso un altro repository.

$ cd mio-hello
$ hg outgoing ../hello-trasmissione
confronto con ../hello-trasmissione
cerco i cambiamenti
changeset:   5:764347e47e75
etichetta:   tip
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:51:52 2009 +0000
sommario:    Inserisce una riga con un messaggio aggiuntivo.

E il comando hg push esegue l’effettiva trasmissione.

$ hg push ../hello-trasmissione
trasmetto a ../hello-trasmissione
cerco i cambiamenti
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 1 cambiamenti a 2 file

Allo stesso modo di hg pull, il comando hg push non aggiorna la directory di lavoro nel repository verso il quale sta trasmettendo i cambiamenti. Diversamente da hg pull, hg push non fornisce un’opzione -u che aggiorni la directory di lavoro dell’altro repository. Questa asimmetria è voluta: il repository verso il quale stiamo trasmettendo potrebbe essere su un server remoto e condiviso da molte persone. Se dovessimo aggiornare la sua directory di lavoro mentre altre persone ci stanno lavorando, il loro lavoro sarebbe rovinato.

Cosa succede se proviamo a estrarre o trasmettere cambiamenti che il repository contiene già? Nulla di particolarmente eccitante.

$ hg push ../hello-trasmissione
trasmetto a ../hello-trasmissione
cerco i cambiamenti
nessun cambiamento trovato

Quando cloniamo un repository, Mercurial registra l’ubicazione del repository che abbiamo clonato nel file .hg/hgrc del nuovo repository. I comandi hg pull e hg push useranno quella ubicazione come impostazione predefinita quando vengono invocati senza fornire esplicitamente un percorso. Anche i comandi hg incoming e hg outgoing si comporteranno allo stesso modo.

Se aprite il file .hg/hgrc di un repository con un editor di testo, vedrete contenuti simili ai seguenti.

[paths]
default = http://www.selenic.com/repo/hg

È possibile—e spesso utile—impostare le ubicazioni per hg push e hg outgoing con valori differenti rispetto a quelle per hg pull e hg incoming, aggiungendo un elemento default-push alla sezione [paths] del file .hg/hgrc nel modo seguente.

[paths]
default = http://www.selenic.com/repo/hg
default-push = http://hg.example.com/hg

I comandi che abbiamo trattato nelle precedenti sezioni non si limitano a lavorare con repository locali. Ogni comando funziona esattamente allo stesso modo attraverso una connessione di rete quando gli viene passato un URL invece di un percorso locale.

$ hg outgoing http://hg.serpentine.com/tutorial/hello
confronto con http://hg.serpentine.com/tutorial/hello
cerco i cambiamenti
changeset:   5:764347e47e75
etichetta:   tip
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:51:52 2009 +0000
sommario:    Inserisce una riga con un messaggio aggiuntivo.

In questo esempio, possiamo vedere quali cambiamenti potremmo trasmettere al repository remoto, ma il repository è comprensibilmente impostato per evitare che gli utenti anonimi vi pubblichino le proprie modifiche.

$ hg push http://hg.serpentine.com/tutorial/hello
trasmetto a http://hg.serpentine.com/tutorial/hello
cerco i cambiamenti
connessione ssl richiesta

Come ricorderete, Mercurial memorizza l’identità del genitore di ogni changeset. Se un cambiamento possiede un genitore, lo chiamiamo figlio o discendente del genitore. Una testa è un changeset che non ha figli. Quindi, la revisione di punta è una testa, perché la revisione più recente in un repository non possiede alcun figlio. Ci sono occasioni in cui un repository può contenere più di una testa.

Figura 3.2. I contenuti del repository dopo aver propagato i cambiamenti da mio-hello a mio-nuovo-hello

Dalla Figura 3.2, «I contenuti del repository dopo aver propagato i cambiamenti da mio-hello a mio-nuovo-hello», potete vedere l’effetto della propagazione dei cambiamenti dal repository mio-hello al repository mio-nuovo-hello. La cronologia già presente in mio-nuovo-hello non viene toccata, ma al repository è stata aggiunta una nuova revisione. Riferendoci alla Figura 3.1, «Le cronologie divergenti dei repository mio-hello e mio-nuovo-hello», possiamo vedere che nel nuovo repository l’identificatore di changeset rimane lo stesso, ma il numero di revisione è cambiato. (Questo, incidentalmente, è un buon esempio del perché sia inopportuno usare i numeri di revisione per discutere i changeset.) Possiamo vedere le teste di un repository utilizzando il comando hg heads.

$ hg heads
changeset:   6:764347e47e75
etichetta:   tip
genitore:    4:2278160e78d4
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:51:52 2009 +0000
sommario:    Inserisce una riga con un messaggio aggiuntivo.

changeset:   5:1c343117a2e3
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:52:03 2009 +0000
sommario:    Un nuovo saluto per un nuovo giorno.

Cosa succede se proviamo a usare normalmente il comando hg update per aggiornare la directory di lavoro alla nuova punta?

$ hg update
fallimento: attraversa i rami (usate 'hg merge' o 'hg update -C')

Mercurial ci sta dicendo che hg update non è in grado di effettuare un’unione. Il comando non aggiornerà la directory di lavoro se pensa che potremmo voler eseguire un’unione, a meno che non gli chiediamo esplicitamente di farlo. (Incidentalmente, forzare l’aggiornamento tramite hg update -C provocherebbe la perdita di tutte le modifiche contenute nella directory di lavoro e non ancora inserite nel repository.)

Per avviare un’unione tra le due teste, usiamo il comando hg merge.

$ hg merge
unisco hello.c
0 file aggiornati, 1 file uniti, 0 file rimossi, 0 file irrisolti
(unione tra rami, ricordatevi di eseguire il commit)

Il contenuto del file hello.c viene sistemato. L’operazione aggiorna la directory di lavoro in modo che contenga le modifiche provenienti da entrambe le teste, cosa che si riflette sia nell’elenco visualizzato dal comando hg parents sia nei contenuti del file hello.c.

$ hg parents
changeset:   5:1c343117a2e3
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:52:03 2009 +0000
sommario:    Un nuovo saluto per un nuovo giorno.

changeset:   6:764347e47e75
etichetta:   tip
genitore:    4:2278160e78d4
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:51:52 2009 +0000
sommario:    Inserisce una riga con un messaggio aggiuntivo.

$ cat hello.c
/*
 * Rilasciato al pubblico dominio da Bryan O'Sullivan. Questo
 * programma non è protetto da brevetti negli Stati Uniti o in
 * altri paesi.
 */

#include <stdio.h>

int main(int argc, char **argv)
{
	printf("ancora una volta, ciao.\n");
	printf("ciao, mondo!\");
	printf("ancora ciao!\n");
	return 0;
}

Ogni volta che eseguiamo un’unione, il comando hg parents mostrerà due genitori fino a quando non invocheremo hg commit per inserire i risultati dell’unione nel repository.

$ hg commit -m "Unisce i cambiamenti."

Ora abbiamo una nuova revisione di punta che, come potete notare, possiede entrambe le nostre vecchie teste come genitori. Queste sono le stesse revisioni che erano state precedentemente mostrate da hg parents.

$ hg tip
changeset:   7:e300c3dcceca
etichetta:   tip
genitore:    5:1c343117a2e3
genitore:    6:764347e47e75
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:52:07 2009 +0000
sommario:    Unisce i cambiamenti.

Nella Figura 3.3, «Lo stato della directory di lavoro e del repository durante l’unione e dopo l’inserimento», potete vedere una rappresentazione di quanto accade alla directory di lavoro durante l’unione e di come questo abbia effetto sul repository quando avviene l’inserimento. Durante l’unione, la directory di lavoro possiede due changeset genitori che poi diventano i genitori del nuovo changeset.

Figura 3.3. Lo stato della directory di lavoro e del repository durante l’unione e dopo l’inserimento

Talvolta si dice che un’unione è composta da due parti: la parte sinistra è costituita dal primo genitore elencato da hg parents e la parte destra dal secondo. Se per esempio la directory di lavoro si fosse trovata alla revisione 5 prima che cominciassimo l’unione, quella revisione sarebbe diventata la parte sinistra dell’unione.

Il mio strumento grafico preferito per gestire le unioni è kdiff3, che userò per descrivere le caratteristiche comuni a queste applicazioni. Potete vedere kdiff3 in azione nella Figura 3.5, «Usare kdiff3 per unire diverse versioni di un file». Il tipo di unione che sta eseguendo si chiama unione a tre vie, perché ci sono tre differenti versioni di un file che ci interessano. La porzione superiore della finestra è divisa in tre pannelli:

Il pannello sottostante contiene il risultato corrente dell’unione. Il nostro compito è quello di sostituire tutto il testo in rosso, che indica conflitti irrisolti, con una qualche combinazione ragionevole della «nostra» e della «loro» versione del file.

Tutti e quattro questi pannelli sono collegati tra loro: se ci spostiamo in verticale o in orizzontale in un pannello qualsiasi, gli altri vengono aggiornati per mostrare le sezioni corrispondenti dei rispettivi file.

Figura 3.5. Usare kdiff3 per unire diverse versioni di un file

Per ogni porzione conflittuale del file, possiamo scegliere di risolvere il conflitto usando una qualche combinazione di testo dalla versione base, dalla nostra, o dalla loro. Possiamo anche modificare manualmente il file risultante in ogni momento, nel caso avessimo bisogno di effettuare ulteriori cambiamenti.

Esistono molti strumenti per gestire l’unione di file, davvero troppi per elencarli qui. Si differenziano a seconda della piattaforma per cui sono disponibili e delle loro particolari forze e debolezze. La maggior parte è calibrata per unire file contenenti testo semplice, mentre alcuni sono orientati a particolari formati di file (generalmente XML).

In questo esempio, riprodurremo la cronologia delle modifiche ai file della Figura 3.4, «Modifiche in conflitto a un documento» vista in precedenza. Per cominciare, creiamo un repository con una versione base del nostro documento.

$ cat > lettera.txt <<EOF
> Salve!
> Sono Mariam Abacha, moglie dell'ex
> dittatore nigeriano Sani Abacha.
> EOF
$ hg add lettera.txt
$ hg commit -m 'truffa 419, prima bozza'

Cloniamo il repository e apportiamo un cambiamento al file.

$ cd ..
$ hg clone truffa truffa-cugino
aggiorno la directory di lavoro
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ cd truffa-cugino
$ cat > lettera.txt <<EOF
> Salve!
> Sono Shehu Musa Abacha, cugino dell'ex
> dittatore nigeriano Sani Abacha.
> EOF
$ hg commit -m 'truffa 419, con cugino'

E ora aggiungiamo un altro clone, per simulare qualcun altro che effettui un cambiamento al file. (Questo suggerisce l’idea che non è affatto inusuale ritrovarsi a unire tra loro i propri repository contenenti attività isolate, risolvendo i conflitti incontrati nel corso di questo processo.)

$ cd ..
$ hg clone truffa truffa-figlio
aggiorno la directory di lavoro
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ cd truffa-figlio
$ cat > lettera.txt <<EOF
> Salve!
> Sono Alhaji Abba Abacha, figlio dell'ex
> dittatore nigeriano Sani Abacha.
> EOF
$ hg commit -m 'truffa 419, con figlio'

Avendo creato due versioni differenti del file, predisponiamo un ambiente adeguato a eseguire la nostra unione.

$ cd ..
$ hg clone truffa-cugino truffa-unione
aggiorno la directory di lavoro
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ cd truffa-unione
$ hg pull -u ../truffa-figlio
estraggo da ../truffa-figlio
cerco i cambiamenti
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 1 cambiamenti a 1 file (+1 teste)
non aggiorno, sono state aggiunte nuove teste
(eseguite 'hg heads' per vedere le teste, 'hg merge' per unire)

In questo esempio, imposterò la variabile d’ambiente HGMERGE per dire a Mercurial di usare il comando non interattivo merge. Questo comando è incluso in molti sistemi di tipo Unix. (Se state seguendo questo esempio sul vostro computer, non preoccupatevi di impostare HGMERGE. Vi verrà presentata un’applicazione grafica da utilizzare per unire i file, che è un’alternativa di gran lunga preferibile.)

$ export HGMERGE=merge
$ hg merge
unisco lettera.txt
merge: attenzione: conflitti durante l'unione
unione di lettera.txt fallita!
0 file aggiornati, 0 file uniti, 0 file rimossi, 1 file irrisolti
usate 'hg resolve' per riprovare a unire i file irrisolti o 'hg up --clean' per abbandonare
$ cat lettera.txt
Salve!
<<<<<<< /tmp/panoramica-unioni-conflitto/truffa-unione/lettera.txt
Sono Shehu Musa Abacha, cugino dell'ex
=======
Sono Alhaji Abba Abacha, figlio dell'ex
>>>>>>> /tmp/lettera.txt~other.01poS4
dittatore nigeriano Sani Abacha.

Dato che merge non riesce a risolvere il conflitto tra i cambiamenti, inserisce alcuni marcatori di unione all’interno del file che esibisce i conflitti, per indicare quali righe sono in conflitto e se quelle righe provengono dalla nostra versione del file o dalla loro.

Dal modo in cui merge termina, Mercurial riconosce che non è stato in grado di operare con successo, quindi ci dice quali comandi abbiamo bisogno di eseguire se vogliamo rifare l’operazione di unione. Questo potrebbe essere utile se, per esempio, stessimo lavorando con un’applicazione grafica per la gestione delle unioni e la chiudessimo perché siamo confusi o realizziamo di aver commesso un errore.

Nel caso in cui l’unione automatica o manuale fallisca, nulla ci impedisce di «correggere» i file interessati per conto nostro, per poi inserire i risultati della nostra unione nel repository:

$ cat > lettera.txt <<EOF
> Salve!
> Sono Bryan O'Sullivan, nessuna parentela con l'ex
> dittatore nigeriano Sani Abacha.
> EOF
$ hg resolve -m lettera.txt
$ hg commit -m 'Mandatemi i vostri soldi'
$ hg tip
changeset:   3:df19ae0ef4d4
etichetta:   tip
genitore:    1:ae14113af250
genitore:    2:11ab3b2b6d1b
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:52:13 2009 +0000
sommario:    Mandatemi i vostri soldi

	Dov’è il comando hg resolve?
	Il comando hg resolve è stato introdotto nella verisone 1.1 di Mercurial rilasciata nel dicembre 2008. Se state usando una versione più vecchia (eseguite hg version per controllare) questo comando non sarà presente. Nel caso la vostra versione di Mercurial sia precedente alla 1.1, vi consiglio vivamente di installare una versione più recente prima di affrontare unioni complicate.

Quando Mercurial tiene traccia delle modifiche a un file, memorizza la cronologia di quel file in un oggetto di metadati chiamato filelog (letteralmente, registro del file). Ogni voce in un filelog contiene informazioni sufficienti a ricostruire una revisione del file di cui tiene traccia. I filelog sono memorizzati come file nella directory .hg/store/data. Un filelog contiene due tipi di informazione: dati di revisione, più un indice per aiutare Mercurial a trovare una revisione in maniera efficiente.

Il filelog di un file di grandi dimensioni o che abbia una lunga cronologia viene memorizzato in due file separati per i dati (con un suffisso «.d») e l’indice (con un suffisso «.i»). Per file di piccole dimensioni con una cronologia ridotta, i dati di revisione e l’indice vengono combinati in un singolo file «.i». La corrispondenza tra un file nella directory di lavoro e il filelog che tiene traccia della sua cronologia nel repository è illustrata nella Figura 4.1, «Relazioni tra i file nella directory di lavoro e i filelog nel repository».

Figura 4.1. Relazioni tra i file nella directory di lavoro e i filelog nel repository

Mercurial usa una struttura chiamata manifest (in italiano, manifesto) per collezionare informazioni sui file di cui tiene traccia. Ogni voce nel manifest contiene informazioni sui file presenti in un singolo changeset e registra quali file sono contenuti nel changeset, la revisione di ogni file e alcuni altri metadati sui file.

Il changelog (letteralmente, registro dei cambiamenti) contiene informazioni su tutti i changeset. Ogni revisione memorizza chi ha inserito un cambiamento, il commento del changeset, altre informazioni relative al changeset e la revisione del manifest da usare.

Nell’ambito di un changelog, di un manifest, o di un filelog, ogni revisione mantiene un puntatore al suo genitore diretto (o ai suoi due genitori, se è una revisione di unione). Come ho già detto, esistono anche relazioni tra revisioni attraverso queste strutture, e tali relazioni sono di natura gerarchica.

Per ogni changeset nel repository, esiste esattamente una revisione memorizzata nel changelog. Ogni revisione del changelog contiene un puntatore a una singola revisione del manifest. Una revisione del manifest include un puntatore a una singola revisione di ogni filelog registrato quando il changeset è stato creato. Queste relazioni sono illustrate nella Figura 4.2, «Relazioni tra i metadati».

Figura 4.2. Relazioni tra i metadati

Come mostrato in figura, non c’è una relazione «uno a uno» tra le revisioni nel changelog, nel manifest, o nel filelog. Se un file registrato da Mercurial non è cambiato tra due changeset, la voce per quel file nelle due revisioni del manifest punterà alla stessa revisione nel suo filelog^[3].

Il revlog permette di memorizzare le revisioni in maniera efficiente usando un meccanismo basato su differenze chiamate delta. Invece di registrare una copia completa di un file per ogni revisione, il revlog memorizza i cambiamenti necessari a trasformare una revisione più vecchia nella nuova revisione. Per molti tipi di file, queste delta sono tipicamente una frazione percentuale della dimensione di un’intera copia di un file.

Alcuni sistemi di controllo di revisione obsoleti possono lavorare solo con le delta di file di testo e sono costretti a memorizzare i file binari come copie complete o a codificarli in una rappresentazione testuale, entrambi approcci dispendiosi. Mercurial è in grado di gestire in maniera efficiente le delta di file con contenuti binari arbitrari, per cui non ha bisogno di trattare il testo in maniera speciale.

Mercurial si limita ad aggiungere dati alla fine di un file di revlog invece di modificarne una sezione dopo averlo memorizzato. Questo approccio è più robusto ed efficiente rispetto a sistemi che hanno bisogno di modificare o riscrivere i dati.

In più, Mercurial tratta ogni scrittura come parte di una transazione che può coinvolgere un qualsiasi numero di file. Una transazione è atomica: o l’intera transazione ha successo e i suoi effetti sono visibili in lettura in un unico passo, oppure l’operazione viene completamente annullata. Questa garanzia di atomicità significa che se state eseguendo due copie di Mercurial, una che sta leggendo dati e l’altra che sta scrivendo, la copia che agisce in lettura non vedrà mai un risultato parzialmente scritto che potrebbe confonderla.

Il fatto che Mercurial operi solo aggiungendo dati alla fine dei file rende più facile fornire questa garanzia transazionale. Più è facile fare cose come queste, più dovreste avere fiducia nel fatto che vengano eseguite correttamente.

Mercurial evita astutamente un’insidia comune a tutti i primi sistemi di controllo di revisione: il problema del reperimento inefficiente. La maggior parte dei sistemi di controllo di revisione memorizza i contenuti di una revisione come una serie incrementale di modifiche rispetto a una «fotografia». (Alcuni basano la fotografia sulla revisione più vecchia, altri su quella più recente.) Per ricostruire una revisione specifica, dovete leggere prima la fotografia e poi ognuna delle revisioni tra la fotografia e la revisione che volete. Più cronologia accumula un file, più revisioni dovete leggere, quindi più tempo viene impiegato per ricostruire una particolare revisione.

Figura 4.3. Fotografia di un revlog, con delta incrementali

Il modo innovativo in cui Mercurial risolve questo problema è semplice ma efficace. Una volta che la quantità totale di informazioni di delta memorizzate dall’ultima fotografia supera una soglia fissata, Mercurial memorizza una nuova fotografia (compressa, naturalmente) invece di un’altra delta. Questo approccio consente di ricostruire velocemente qualsiasi revisione di un file e funziona così bene che in seguito è stato copiato da molti altri sistemi di controllo di revisione.

La Figura 4.3, «Fotografia di un revlog, con delta incrementali» illustra l’idea. In una voce contenuta nel file indice di un revlog, Mercurial memorizza l’intervallo di voci che deve leggere dal file di dati per ricostruire una particolare revisione.

Insieme alle informazioni di delta e di fotografia, una voce di revlog contiene un hash crittografico dei dati che rappresenta. Questo rende difficile contraffare i contenuti di una revisione e facilita la scoperta di corruzioni accidentali dei dati.

Gli hash forniscono più di un semplice controllo contro la corruzione dei dati, infatti vengono usati come identificatori per le revisioni. Gli hash di identificazione dei changeset che avete visto come utenti finali provengono dalle revisioni del changelog. Sebbene anche i filelog e il manifest facciano uso di hash, in questo caso Mercurial li impiega solo dietro le quinte.

Mercurial verifica che gli hash siano corretti nel momento in cui reperisce le revisioni dei file o estrae i cambiamenti da un altro repository. Se incontra un problema di integrità, lo segnalerà e bloccherà l’operazione che stava eseguendo.

In aggiunta all’effetto che ha sull’efficienza del reperimento, l’uso di fotografie periodiche da parte di Mercurial rende i repository più robusti nei confronti della corruzione parziale dei dati. Se un revlog viene parzialmente rovinato da un errore hardware o da un bug di sistema, spesso rimane possibile ricostruire alcune o la maggior parte delle revisioni a partire dalle sezioni illese del revlog che si trovano prima e dopo la sezione rovinata. Questo non sarebbe possibile con un modello di memorizzazione basato unicamente sulle delta.

Il dirstate mantiene le informazioni sui genitori per altri scopi in aggiunta alla mera contabilità. Mercurial usa i genitori del dirstate come i genitori di un nuovo changeset quando effettuate un commit.

Figura 4.5. La directory di lavoro può avere due genitori

La Figura 4.5, «La directory di lavoro può avere due genitori» mostra il normale stato della directory di lavoro, in cui la directory ha un singolo changeset come genitore. Quel changeset è la punta, il changeset più recente senza figli nel repository.

Figura 4.6. La directory di lavoro acquisisce nuovi genitori dopo un commit

È utile pensare alla directory di lavoro come al «changeset che state per inserire». Le azioni compiute su qualsiasi file che abbiate detto a Mercurial di aver aggiunto, rimosso, rinominato, o copiato verranno riflesse in quel changeset, così come le modifiche a qualsiasi file che Mercurial aveva già registrato. Il nuovo changeset acquisirà come propri genitori quelli della directory di lavoro.

Dopo un commit, Mercurial aggiornerà i genitori della directory di lavoro in modo che il primo genitore sia l’identificatore del nuovo changeset e il secondo sia l’identificatore nullo, come mostrato nella Figura 4.6, «La directory di lavoro acquisisce nuovi genitori dopo un commit». Mercurial non tocca alcun file nella directory di lavoro quando eseguite un commit, ma si limita a modificare il dirstate per annotare i nuovi genitori della directory.

È perfettamente normale aggiornare la directory di lavoro a un changeset diverso dalla punta corrente. Per esempio, potreste voler sapere come il vostro progetto appariva lo scorso martedì, oppure potreste dover scorrere i changeset per trovare quello che ha introdotto un bug. In questi casi, la cosa naturale da fare è aggiornare la directory di lavoro al changeset che vi interessa e poi esaminare i file direttamente nella directory di lavoro per vedere quali erano i loro contenuti quando avete inserito quel changeset. Gli effetti di questa azione si possono vedere nella Figura 4.7, «La directory di lavoro, aggiornata a un vecchio changeset».

Figura 4.7. La directory di lavoro, aggiornata a un vecchio changeset

Avendo aggiornato la directory di lavoro a un vecchio changeset, cosa succede se apportate alcuni cambiamenti e poi li inserite? Mercurial si comporta nello stesso modo delineato in precedenza. I genitori della directory di lavoro diventano i genitori del nuovo changeset. Questo nuovo changeset non ha figli, quindi diventa la nuova punta. E il repository ora contiene due changeset senza figli che vengono chiamati teste. Potete vedere la struttura creata da questa operazione nella Figura 4.8, «La situazione dopo un commit effettuato su un aggiornamento a un vecchio changeset».

Figura 4.8. La situazione dopo un commit effettuato su un aggiornamento a un vecchio changeset

Nota

Se avete appena cominciato a lavorare con Mercurial, dovreste tenere a mente un «errore» comune, che è quello di usare il comando hg pull senza alcuna opzione. Per default, il comando hg pull non aggiorna la directory di lavoro, ma propagherà i nuovi cambiamenti nel vostro repository lasciandola sincronizzata allo stesso changeset in cui si trovava prima della propagazione. Se ora effettuate alcuni cambiamenti e poi li inserite, creerete una nuova testa, perché la vostra directory di lavoro non è stata sincronizzata alla revisione di punta corrente. Per combinare le operazioni di estrazione e aggiornamento, eseguite hg pull -u. Ho messo la parola «errore» tra virgolette perché tutto quello che dovete fare per rettificare la situazione in cui avete creato una nuova testa per sbaglio è eseguire il comando hg merge seguito da hg commit. In altre parole, questo errore non ha quasi mai conseguenze negative, ma è solo qualcosa che può sorprendere i nuovi utenti. Più avanti, discuterò altri modi per evitare questo comportamento e le ragioni per cui Mercurial si comporta in questo modo inizialmente sorprendente.

Quando eseguite il comando hg merge, Mercurial lascia invariato il primo genitore della directory di lavoro e imposta il secondo genitore al cambiamento che state incorporando, come mostrato nella Figura 4.9, «Unire due teste».

Figura 4.9. Unire due teste

Mercurial deve anche modificare la directory di lavoro per unire i file gestiti dai due changeset. Semplificandolo un po’, il processo di unione funziona nel modo seguente, per ogni file contenuto nei manifest di entrambi i changeset.

Ci sono molti altri dettagli—le unioni sono piene di casi particolari—ma queste sono le scelte più comuni coinvolte nel processo di unione. Come potete vedere, la maggior parte dei casi è completamente automatizzata e in effetti la maggior parte delle unioni termina automaticamente senza richiedere il vostro intervento per risolvere alcun conflitto.

Se considerate quello che succede quando effettuate un commit dopo un’unione, ancora una volta la directory di lavoro è «il changeset che state per inserire». Dopo che il comando hg merge ha terminato, la directory di lavoro possiede due genitori, che poi diventeranno i genitori del nuovo changeset.

Mercurial vi permette di effettuare molteplici unioni, ma dovete inserire i risultati di ogni singola unione man mano che procedete, perché Mercurial tiene traccia solamente di due genitori sia per le revisioni che per la directory di lavoro. Anche se unire molteplici changeset alla volta sarebbe tecnicamente possibile, Mercurial evita di farlo per semplicità. Con unioni a più vie, il rischio di disorientare l’utente, di incappare in conflitti sgradevoli da risolvere e di fare una terribile confusione durante il processo di unione diventerebbe intollerabile.

Un numero sorprendente di sistemi di controllo di revisione dedica poca o addirittura nessuna attenzione ai cambiamenti del nome di un file. Per esempio, era pratica comune scartare silenziosamente le modifiche a un file contenute in una delle due parti di un’unione se quel file fosse stato rinominato nell’altra parte.

Mercurial registra alcuni metadati quando gli dite di effettuare una cambiamento di nome o una copia e li usa durante le unioni per comportarsi in maniera appropriata. Per esempio, se io cambio il nome di un file che voi modificate senza rinominare, quando uniamo i nostri cambiamenti il file verrà rinominato e gli verranno applicate le vostre modifiche.

Quando è appropriato, Mercurial memorizzerà sia la fotografia che le delta in forma compressa, cercando sempre di comprimere una fotografia o una delta, ma memorizzando la versione compressa solo se è più piccola della versione originale.

Questo significa che Mercurial fa «la cosa giusta» quando memorizza un file il cui formato sia già compresso, come un archivio zip o un’immagine JPEG. Quando questi tipi di file vengono compressi una seconda volta, il file risultante è tipicamente più grande di quello originale, così Mercurial memorizzerà la versione iniziale del file zip o JPEG.

Di solito, le delta tra le revisioni di un file compresso sono più grandi delle fotografie del file, ma anche in questi casi Mercurial fa «la cosa giusta» ancora una volta. Scopre che quella delta supera la soglia oltre la quale Mercurial dovrebbe registrare una fotografia completa del file e quindi memorizza la fotografia, risparmiando ancora spazio nei confronti di un approccio ingenuo basato solo sulle delta.

[ui]
ssh = ssh -C

Quando si cerca di garantire che una lettura non veda scritture parziali, non è sufficiente limitarsi ad aggiungere in coda ai file le nuove informazioni. Se ricordate la Figura 4.2, «Relazioni tra i metadati», le revisioni in un changelog puntano alle revisioni nel manifest e le revisioni nel manifest puntano alle revisioni nei filelog. Questa gerarchia è intenzionale.

Un’operazione di scrittura avvia una transazione modificando i dati nei filelog e nel manifest, senza modificare alcun dato contenuto nel changelog prima che di aver terminato con quelli. Un’operazione di lettura comincia leggendo i dati nel changelog, poi i dati nel manifest seguiti dai dati nei filelog.

Dato che la scrittura ha sempre terminato di modificare i dati nei filelog e nel manifest prima di modificare il changelog, una lettura non vedrà mai il changelog puntare verso una revisione parzialmente modificata del manifest e non vedrà mai il manifest puntare verso una revisione parzialmente modificata di un filelog.

Le garanzie sull’ordinamento e sull’atomicità delle operazioni di lettura significano che Mercurial non avrà mai bisogno di bloccare un repository da cui sta leggendo i dati, anche se il repository viene modificato mentre la lettura è in corso. Questo ha un importante effetto sulla scalabilità: potete avere un numero arbitrario di processi Mercurial che leggono contemporaneamente in sicurezza i dati da un repository, senza preoccuparvi che qualcun altro lo stia modificando oppure no.

La mancanza di un blocco durante la lettura significa che, se state condividendo un repository su un sistema multi-utente, non avete bisogno di concedere ad altri utenti locali i permessi di scrittura al vostro repository per consentire loro di clonarlo o estrarne i cambiamenti, ma saranno sufficienti i permessi di lettura. (Questa non è una caratteristica comune tra i sistemi di controllo di revisione, quindi non datela per scontata! La maggior parte dei sistemi richiede che i lettori siano in grado di bloccare un repository per accederlo in sicurezza, cosa che naturalmente provoca ogni tipo di sgradevoli e fastidiosi problemi di sicurezza e amministrazione.)

Mercurial usa i blocchi per assicurarsi che un solo processo alla volta possa effettuare modifiche a un repository (il meccanismo di bloccaggio è sicuro persino su file system che sono notoriamente avversi al bloccaggio, come NFS). Se un repository è bloccato, un’operazione di scrittura aspetterà per qualche tempo prima di ricontrollare se il repository si è sbloccato, ma se il repository rimane bloccato troppo a lungo, dopo un po’ il processo che sta tentando di scrivere andrà in timeout. Questo significa, per esempio, che i vostri script automatici non rimarranno bloccati per sempre accumulandosi l’uno sull’altro se un sistema dovesse inavvertitamente cadere. (Sì, il valore del timeout è configurabile, da zero a infinito.)

Un aspetto critico delle prestazioni di Mercurial è quello di evitare le operazioni di seek della testina del disco, dato che ognuna di queste operazioni è molto più dispendiosa persino di un’operazione di lettura relativamente grande.

Questa è la ragione per cui, per esempio, il dirstate è memorizzato in un singolo file. Se ci fosse un file di dirstate per ogni directory registrata da Mercurial, il disco effettuerebbe un’operazione di seek per ciascuna directory. Invece, Mercurial legge l’intero file di dirstate in un singolo passo.

Mercurial adotta anche una strategia «copy-on-write» per clonare un repository su disco locale. Invece di copiare ogni file di revlog dal vecchio repository al nuovo, utilizza «collegamenti fisici» per indicare che «due nomi puntano allo stesso file». Quando Mercurial sta per modificare uno dei file di un revlog, controlla per vedere se il numero di nomi che puntano al file è più grande di uno. Se è così, questo significa che più di un repository sta usando il file, quindi Mercurial ne crea una nuova copia riservata a questo repository.

Alcuni sviluppatori di sistemi per il controllo di revisione hanno fatto notare che la creazione di una copia privata completa di un file non sfrutta lo spazio su disco in maniera molto efficiente. Sebbene questo sia vero, lo spazio su disco è piuttosto economico, e questo metodo consente di avere le prestazioni migliori rinviando la maggior parte della contabilità al sistema operativo. Molto probabilmente, una strategia alternativa ridurrebbe le prestazioni e aumenterebbe la complessità del software, ma velocità e semplicità sono aspetti chiave per la «facilità» nell’uso quotidiano.

Dato che Mercurial non vi obbliga a dirgli quando state modificando un file, usa il dirstate per memorizzare alcune informazioni aggiuntive in modo da poter determinare in maniera efficiente se avete modificato un file. Per ogni file nella directory di lavoro, Mercurial memorizza la data in cui ha registrato una modifica al file per l’ultima volta e la dimensione che il file aveva in quel momento.

Quando utilizzate esplicitamente hg add, hg remove, hg rename, o hg copy su un file, Mercurial aggiorna il dirstate in modo che sappia cosa fare con quel file quando effettuate un commit.

Il dirstate aiuta Mercurial a controllare in maniera efficiente lo stato dei file in un repository.

Memorizzare le dimensioni e la data di ultima modifica riduce drammaticamente il numero di operazioni di lettura che Mercurial deve effettuare quando invochiamo comandi come hg status. Da questo stratagemma deriva un notevole miglioramento delle prestazioni.

Se passate un nome di una directory a un comando, ogni comando Mercurial interpreterà opportunamente questa azione come la richiesta di «operare su ogni file in questa directory e nelle sue sottodirectory».

$ mkdir b
$ echo b > b/qualchefile.txt
$ echo c > b/sorgente.cpp
$ mkdir b/d
$ echo d > b/d/test.h
$ hg add b
aggiungo b/d/test.h
aggiungo b/qualchefile.txt
agginugo b/sorgente.cpp
$ hg commit -m "Aggiunti tutti i file nella sottodirectory."

Notate che, in questo esempio, Mercurial ha stampato i nomi dei file che ha aggiunto, mentre non lo ha fatto quando abbiamo aggiunto il file miofile.txt nell’esempio precedente.

Questo accade perché, nel primo esempio, abbiamo esplicitamente nominato il file da aggiungere sulla riga di comando. In questi casi, Mercurial assume che sappiamo ciò che stiamo facendo, per cui non stampa alcuna informazione.

Tuttavia, quando implichiamo i nomi dei file dando il nome di una directory, Mercurial compie il passo aggiuntivo di stampare il nome di ogni file su cui agisce. Questo rende più chiaro ciò che sta succedendo e riduce la probabilità di una sorpresa sgradita e silenziosa. La maggior parte dei comandi Mercurial si comporta in questo modo.

Mercurial non tiene traccia delle informazioni sulle directory, ma tiene traccia del percorso di un file. Prima di creare un file, crea tutte le directory mancanti che ne compongono il percorso. Dopo che ha cancellato un file, cancella ogni directory vuota che faceva parte del percorso del file cancellato. Questa sembra una distinzione irrilevante, ma ha una conseguenza pratica di secondaria importanza: Mercurial non vi permette di rappresentare una directory completamente vuota.

Le directory vuote sono raramente utili e ci sono soluzioni non invadenti che potete usare per ottenere un effetto appropriato. Quindi, gli sviluppatori di Mercurial hanno deciso che la complessità che sarebbe stata richiesta per gestire le directory vuote non valesse il limitato beneficio che questa caratteristica avrebbe portato.

Se avete bisogno di una directory vuota nel vostro repository, ci sono alcuni modi per ottenerla. Uno dei modi possibili è quello di creare una directory e usare hg add per aggiungere un file «nascosto» a quella directory. Sui sistemi di tipo Unix, ogni file il cui nome comincia con un punto («.») viene considerato nascosto dalla maggior parte dei comandi e delle applicazioni con interfaccia grafica. Questo approccio è illustrato qui di seguito.

$ hg init esempio-nascosto
$ cd esempio-nascosto
$ mkdir vuota
$ touch vuota/.nascosto
$ hg add vuota/.nascosto
$ hg commit -m "Gestisce una directory che sembra vuota."
$ ls vuota
$ cd ..
$ hg clone esempio-nascosto temp
aggiorno la directory di lavoro
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ ls temp
vuota
$ ls temp/vuota

Un altro modo per soddisfare il bisogno di una directory vuota è semplicemente quello di farla creare al vostro programma automatico di assemblaggio del progetto nel momento in cui ne avete bisogno.

È importante capire che la rimozione di un file ha solo due effetti.

La rimozione di un file non altera la cronologia del file in alcun modo.

Se aggiornate la directory di lavoro a un changeset che era stato inserito quando Mercurial stava ancora tenendo traccia del file che più tardi avete rimosso, il file riapparirà nella directory di lavoro con i contenuti che aveva quando avete inserito quel changeset. Se poi aggiornate la directory di lavoro a un changeset successivo in cui il file è stato rimosso, Mercurial cancellerà ancora una volta il file dalla directory di lavoro.

Mercurial considera mancante un file che avete cancellato senza usare hg remove. Un file mancante viene rappresentato con «!» nell’elenco mostrato da hg status. Di solito, i comandi Mercurial non agiscono mai sui file mancanti.

$ hg init esempio-mancante
$ cd esempio-mancante
$ echo a > a
$ hg add a
$ hg commit -m "Il file sta per diventare mancante."
$ rm a
$ hg status
! a

Se il vostro repository contiene un file che hg status segnala come mancante e volete che il file rimanga assente, potete eseguire hg remove --after in qualsiasi momento per dire a Mercurial che volevate effettivamente rimuovere il file.

$ hg remove --after a
$ hg status
R a

D’altra parte, se avete cancellato il file mancante per errore, passate al comando hg revert il nome del file da recuperare e il file riapparirà senza alcun cambiamento.

$ hg revert a
$ cat a
a
$ hg status

Potreste chiedervi perché Mercurial vi costringe a dirgli esplicitamente che state cancellando un file. Nelle prime fasi di sviluppo, Mercurial vi permetteva di cancellare un file nel modo che preferivate: avrebbe notato automaticamente l’assenza del file durante la successiva esecuzione di hg commit e avrebbe smesso di monitorarlo. In pratica, questo modo di operare rendeva troppo facile rimuovere accidentalmente un file senza accorgersene.

Mercurial fornisce il comando combinato hg addremove per aggiungere i file non ancora registrati e segnare i file mancanti come rimossi.

$ hg init esempio-addremove
$ cd esempio-addremove
$ echo a > a
$ echo b > b
$ hg addremove
aggiungo a
aggiungo b

Il comando hg commit offre anche un’opzione -A che effettua la stessa operazione di aggiunta-e-rimozione, immediatamente seguita da un commit.

$ echo c > c
$ hg commit -A -m "Commit con addremove."
aggiungo c

Quello che succede durante un’unione è che i cambiamenti «seguono» la copia. Per illustrare al meglio cosa questo significa, creiamo un esempio. Cominceremo con il solito piccolo repository che contiene un singolo file.

$ hg init mia-copia
$ cd mia-copia
$ echo riga > file
$ hg add file
$ hg commit -m "Aggiunto un file."

Abbiamo bisogno di fare alcune modifiche in parallelo, in modo da avere due cambiamenti da unire tra loro. Quindi cloniamo il nostro repository.

$ cd ..
$ hg clone mia-copia vostra-copia
aggiorno la directory di lavoro
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti

Tornando al nostro repository iniziale, usiamo il comando hg copy per fare una copia del primo file che abbiamo creato.

$ cd mia-copia
$ hg copy file nuovo-file

Se successivamente osserviamo il risultato del comando hg status, il file copiato appare come un normale file aggiunto.

$ hg status
A nuovo-file

Ma se passiamo l’opzione -C al comando hg status, otterremo un’altra riga nell’elenco stampato: questo è il file da cui il nostro file appena aggiunto è stato copiato.

$ hg status -C
A nuovo-file
  file
$ hg commit -m "File copiato."

Ora, tornando al repository che abbiamo clonato, apportiamo un cambiamento in parallelo. Aggiungeremo una riga al contenuto del file originale che abbiamo creato.

$ cd ../vostra-copia
$ echo 'nuovi contenuti' >> file
$ hg commit -m "File modificato."

Ora abbiamo un file modificato in questo repository. Quando estraiamo i cambiamenti dal primo repository e uniamo le due teste, Mercurial propagherà i cambiamenti che abbiamo apportato localmente a file nella sua copia nuovo-file.

$ hg pull ../mia-copia
estraggo da ../mia-copia
cerco i cambiamenti
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 1 cambiamenti a 1 file (+1 teste)
(eseguite 'hg heads' per vedere le teste, 'hg merge' per unire)
$ hg merge
unisco file e nuovo-file in nuovo-file
0 file aggiornati, 1 file uniti, 0 file rimossi, 0 file irrisolti
(unione tra rami, ricordatevi di eseguire il commit)
$ cat nuovo-file
riga
nuovi contenuti

Questo comportamento—dei cambiamenti a un file che si propagano alle copie del file—potrebbe sembrare esoterico, ma nella maggior parte dei casi è altamente desiderabile.

Prima di tutto, ricordatevi che questa propagazione avviene solamente durante un’unione. Quindi se usate hg copy su un file e in seguito modificate il file originale nel normale corso del vostro lavoro, non accadrà nulla.

La seconda cosa da sapere è che le modifiche si propagheranno alla copia solo se il changeset da cui state incorporando le modifiche non ha ancora visto la copia.

Il motivo per cui Mercurial si comporta in questo modo è il seguente. Diciamo che io correggo un bug importante in un file sorgente e inserisco i miei cambiamenti nel repository. Nel frattempo, voi avete deciso di eseguire hg copy per fare una copia del file nel vostro repository, senza sapere del bug o aver visto la correzione, e avete cominciato a lavorare sulla vostra copia del file.

Se dopo aver estratto e incorporato le mie modifiche Mercurial non avesse propagato i cambiamenti attraverso le copie, il vostro nuovo file sorgente ora conterrebbe il bug e, a meno che voi non sapeste come propagare la correzione a mano, il bug rimarrebbe nella vostra copia del file.

Propagando automaticamente le modifiche che hanno corretto il bug dal file originale alla copia, Mercurial previene questo tipo di problemi. A quanto ne so, Mercurial è l’unico sistema di controllo di revisione che propaga i cambiamenti verso le copie in questo modo.

Una volta che la vostra cronologia dei cambiamenti contiene la registrazione che la copia e la successiva unione sono avvenute, di solito non c’è più bisogno di propagare cambiamenti dal file originale al file copiato. Questo è il motivo per cui Mercurial propaga i cambiamenti verso le copie solo durante la prima unione ma non successivamente.

Se per qualche ragione decidete che questa faccenda di propagare automaticamente i cambiamenti verso le copie non fa per voi, utilizzate il normale comando per la copia di file fornito dal vostro sistema (cp per i sistemi di tipo Unix) per effettuare la copia di un file, poi aggiungete a mano la nuova copia invocando hg add. Prima di farlo, però, rileggete la Sezione 5.3.2, «Perché i cambiamenti dovrebbero seguire le copie?» e prendete una decisione informata sulla validità di questo comportamento nel vostro caso specifico.

Quando usate il comando hg copy, Mercurial esegue la copia dei file originali contenuti nella directory di lavoro nello stato in cui si trovano in quel momento. Questo significa che, se fate alcune modifiche a un file e poi lo copiate tramite hg copy senza prima aver inserito quelle modifiche nel repository, anche la nuova copia conterrà le modifiche che avete apportato fino a quel momento. (Trovo che questo comportamento sia leggermente controintuitivo ed è per questo che lo menziono qui.)

Il comando hg copy agisce in maniera simile al comando Unix cp (potete usare l’alias hg cp se preferite). Dobbiamo fornirgli due o più argomenti, di cui l’ultimo viene trattato come destinazione e tutti gli altri vengono trattati come sorgenti.

Se invocate hg copy con un singolo file come sorgente e la destinazione non esiste, il comando crea un nuovo file con quel nome.

$ mkdir k
$ hg copy a k
$ ls k
a

Se la destinazione è una directory, Mercurial copia le sorgenti in quella directory.

$ mkdir d
$ hg copy a b d
$ ls d
a  b

Copiare una directory è un’operazione ricorsiva e preserva la struttura delle directory della sorgente.

$ hg copy z e
copio z/a/c in e/a/c

Se la sorgente e la destinazione sono entrambe directory, l’albero della sorgente viene ricreato nella directory di destinazione.

$ hg copy z d
copio z/a/c in d/z/a/c

Come con il comando hg remove, se copiate un file manualmente e poi volete informare Mercurial di aver copiato il file, usate semplicemente l’opzione --after di hg copy.

$ cp a n
$ hg copy --after a n

Dato che Mercurial rinomina i file tramite un’operazione di copia-e-rimozione, i cambiamenti vengono propagati nello stesso modo quando effettuate un’unione sia dopo aver copiato un file che dopo averlo rinominato.

Se io modifico un file e voi lo rinominate e poi uniamo i nostri rispettivi cambiamenti, le mie modifiche al file con il suo nome originale verranno propagate al file con il suo nuovo nome. (Vi potreste aspettare che questo «funzioni e basta» ma in realtà non tutti i sistemi di controllo di revisione lo fanno.)

Sebbene la propagazione dei cambiamenti alle copie sia una funzione che potreste approvare dicendo «sì, questo potrebbe essere utile», deve essere chiaro che propagare i cambiamenti ai file rinominati è assolutamente importante. Senza questo meccanismo, i cambiamenti a un file si potrebbero perdere con troppa facilità quando il file viene rinominato.

Il caso dei nomi divergenti si verifica quando due sviluppatori cominciano con un file—chiamiamolo foo—nei loro rispettivi repository.

$ hg clone orig anna
aggiorno la directory di lavoro
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ hg clone orig bruno
aggiorno la directory di lavoro
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti

Anna cambia il nome del file a bar.

$ cd anna
$ hg rename foo bar
$ hg ci -m "Rinominato foo a bar."

Nel frattempo, Bruno lo rinomina quux. (Ricordatevi che hg mv è un alias di hg rename.)

$ cd ../bruno
$ hg mv foo quux
$ hg ci -m "Rinominato foo a quux."

Mi piace pensare a questo come a un conflitto perché entrambi gli sviluppatori hanno espresso intenzioni differenti a proposito di come il file dovrebbe essere chiamato.

Cosa pensate che dovrebbe accadere quando Anna e Bruno uniscono il loro lavoro? L’effettivo comportamento di Mercurial è quello di preservare sempre entrambi i nomi quando unisce changeset che contengono cambiamenti di nome divergenti.

# Si veda http://www.selenic.com/mercurial/bts/issue455
$ cd ../orig
$ hg pull -u ../anna
estraggo da ../anna
cerco i cambiamenti
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 1 cambiamenti a 1 file
1 file aggiornati, 0 file uniti, 1 file rimossi, 0 file irrisolti
$ hg pull ../bruno
estraggo da ../bruno
cerco i cambiamenti
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 1 cambiamenti a 1 file (+1 teste)
(eseguite 'hg heads' per vedere le teste, 'hg merge' per unire)
$ hg merge
attenzione: cambiamenti di nome divergenti di foo a:
 bar
 quux
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
(unione tra rami, ricordatevi di eseguire il commit)
$ ls
bar  quux

Notate che, sebbene Mercurial vi avverta del cambiamento di nome divergente, lascia che siate voi a riconciliare la divergenza dopo l’unione.

Un altro tipo di conflitto tra i cambiamenti di nome avviene quando due persone rinominano differenti file sorgente alla stessa destinazione. In questo caso, Mercurial esegue l’unione normalmente e lascia che siate voi a guidarlo verso una risoluzione ragionevole.

Mercurial soffre di un bug noto da tempo che gli impedisce di portare a termine un’unione in cui una parte contiene un file con un certo nome mentre l’altra contiene una directory con lo stesso nome. Questo è documentato come problema 29.

$ hg init problema29
$ cd problema29
$ echo a > a
$ hg ci -Ama
aggiungo a
$ echo b > b
$ hg ci -Amb
aggiungo b
$ hg up 0
0 file aggiornati, 0 file uniti, 1 file rimossi, 0 file irrisolti
$ mkdir b
$ echo b > b/b
$ hg ci -Amc
aggiungo b/b
creata una nuova testa
$ hg merge
fallimento: è una directory: /tmp/problema29/b

Quando avviene un’unione, di solito la maggior parte dei file rimarrà tale e quale. Mercurial terrà traccia dello stato di ogni file su cui deve operare.

Se Mercurial vede un qualsiasi file nello stato irrisolto dopo un’unione, considera fallita l’unione. Fortunatamente, non abbiamo bisogno di ricominciare l’intera unione da zero.

L’opzione --list o -l del comando hg resolve mostra lo stato di ogni file coinvolto in un’unione.

$ hg resolve -l
U miofile.txt

Nell’elenco stampato da hg resolve, un file risolto è contrassegnato con una R mentre un file irrisolto è contrassegnato con una U. Se un file qualsiasi viene elencato con una U, sappiamo che un tentativo di inserire i risultati dell’unione nel repository andrà incontro al fallimento.

Abbiamo diverse opzioni per far passare un file dallo stato irrisolto a quello risolto. Quella di gran lunga più comune consiste nell’eseguire nuovamente hg resolve. Se passiamo i nomi di singoli file o directory, il comando riproverà a unire i file irrisolti presenti in quelle ubicazioni. Possiamo anche passare l’opzione --all o -a per riprovare a unire tutti i file irrisolti.

Mercurial ci permette anche di modificare direttamente lo stato di risoluzione di un file. Possiamo contrassegnare manualmente un file come risolto usando l’opzione --mark o come irrisolto usando l’opzione --unmark. Questo ci consente di ripulire a mano un’unione particolarmente disordinata e di tenere traccia dei nostri progressi con ogni file man mano che procediamo.

L’aspetto più importante che dovete tenere presente per qualsiasi modello è il grado di conformità ai bisogni e alle capacità delle persone che lo useranno. Questo potrebbe sembrare ovvio, ma in ogni caso non potete comunque permettervi di dimenticarvelo nemmeno per un momento.

Una volta mi capitò di comporre un modello di workflow che a me sembrava perfettamente sensato, ma che provocò una notevole quantità di litigi e parecchia costernazione tra i membri del mio gruppo di sviluppo. Nonostante i miei tentativi di spiegare perché avessimo bisogno di un insieme complesso di ramificazioni e come i cambiamenti dovessero circolare tra i rami, alcuni membri del gruppo si ribellarono. Sebbene fossero persone intelligenti, non volevano fare attenzione ai vincoli sotto i quali stavamo operando, né affrontare le conseguenze di quei vincoli sui dettagli del modello che stavo difendendo.

Evitate di nascondere sotto il tappeto i prevedibili problemi di tipo tecnico o sociale. Qualunque schema adottiate, dovreste avere un piano per affrontare errori e scenari problematici. Prendete in considerazione l’idea di aggiungere meccanismi automatici per prevenire o risolvere velocemente i problemi che siete in grado di anticipare. Per esempio, se intendete avere un ramo con cambiamenti che non desiderate rilasciare al pubblico, fareste meglio a pensare fin dall’inizio alla possibilità che qualcuno possa accidentalmente incorporare quei cambiamenti in un ramo di release. Potete evitare questo particolare problema implementando un hook che prevenga l’unione di cambiamenti da rami non appropriati.

Non vorrei suggerire che un approccio in cui «tutto è permesso» sia qualcosa di sostenibile, ma è un modello che è facile da capire e funziona perfettamente in alcune situazioni inusuali.

Per esempio, molti progetti hanno un gruppo sparpagliato di collaboratori che si incontrano fisicamente solo di rado. Alcuni gruppi preferiscono superare l’isolamento del lavoro a distanza organizzando «maratone» occasionali in cui un certo numero di persone si ritrova insieme in un’unico luogo (la stanza delle riunioni di un’azienda, la sala delle conferenze in un hotel, posti di questo tipo) e passa diversi giorni più o meno chiuso lì, a lavorare intensamente su una manciata di progetti.

Una maratona o una sessione di programmazione in un locale sono le occasioni perfette per usare il comando hg serve, dato che hg serve non richiede alcuna infrastruttura server elaborata. Potete cominciare a usare hg serve in pochi minuti, leggendo la Sezione 6.4, «Condivisione informale con hg serve» più avanti. Poi vi basta comunicare ai vostri vicini l’esistenza di un server in esecuzione, fargli sapere l’URL a cui devono collegarsi, e avrete un modo rapido da predisporre per lavorare insieme. Gli altri potranno digitare il vostro URL nel proprio browser e revisionare velocemente i vostri cambiamenti, o estrarre la correzione di un bug dal vostro repository e verificarla, o clonare un ramo contenente una nuova funzione e provarla.

Il fascino, e allo stesso tempo il problema, di fare le cose ad hoc in questo modo è che solo le persone che sanno dell’esistenza dei vostri cambiamenti e sanno dove trovarli possono vederli. Un approccio informale di questo tipo non riesce proprio a scalare oltre una manciata di persone, perché ogni individuo ha bisogno di conoscere n diversi repository da cui estrarre modifiche.

Per progetti di dimensioni ridotte che stanno migrando da uno strumento centralizzato di controllo di revisione, forse il modo più facile per cominciare è far passare i cambiamenti attraverso un singolo repository centrale condiviso. Questo è anche il più comune «mattone da costruzione» per schemi di workflow più ambiziosi.

I collaboratori cominciano clonando una copia di questo repository, potendo estrarne i cambiamenti ogni volta che ne hanno bisogno. Alcuni sviluppatori (forse tutti) hanno il permesso di trasmettere le modifiche al repository quando sono pronte per essere viste da altre persone.

In questo modello, può ancora avere senso che alcune persone propaghino i cambiamenti direttamente tra loro, senza passare dal repository centrale. Considerate il caso in cui io ho creato una correzione sperimentale di un bug, ma sono preoccupato che, se la pubblicassi sul repository centrale, tutti gli altri possano successivamente danneggiare i propri alberi nel momento in cui la estraggono. Per ridurre il danno potenziale, posso chiedervi di clonare temporaneamente il mio repository in un vostro repository privato e di collaudare la correzione. Questo ci permette di rimandare la pubblicazione di cambiamenti potenzialmente pericolosi fino a quando non hanno subìto una ragionevole verifica.

Se un gruppo sta mantenendo il repository sui propri server in questo tipo di scenario, di solito i membri useranno il protocollo ssh per trasmettere in sicurezza i cambiamenti al repository centrale, come documentato nella Sezione 6.5, «Usare il protocollo di Shell Sicura (ssh)». Di solito, viene anche pubblicata una copia del repository in sola lettura via HTTP, come nella Sezione 6.6, «Condividere i dati attraverso HTTP usando CGI». Pubblicare via HTTP soddisfa le necessità di chi non ha accesso in scrittura e di chi preferisce usare un browser per navigare la cronologia del repository.

Una caratteristica meravigliosa dei servizi di hosting come Bitbucket è che non solo si occupano di gestire i dettagli della configurazione del server, come gli account utente, l’autenticazione e i protocolli sicuri di rete, ma offrono anche un’infrastruttura aggiuntiva per far funzionare al meglio questo modello.

Per esempio, un servizio di hosting ben ingegnerizzato consentirà agli sviluppatori di clonare le proprie copie di un repository con un singolo clic, in modo da farli lavorare in spazi separati e lasciarli condividere i propri cambiamenti quando sono pronti.

In più, un buon servizio di hosting permetterà ai propri utentei di comunicare tra loro, per esempio per segnalare che «questo albero contiene modifiche pronte per la tua revisione».

Qualsiasi progetto di dimensioni significative tende a fare progressi su più fronti contemporaneamente. Nel caso del software, un progetto passa comunemente attraverso una serie di release ufficiali periodiche. Una release potrebbe andare in fase di «manutenzione» per un po’ dopo la sua prima pubblicazione, finendo per contenere solo correzioni di bug, senza che vengano aggiunte nuove funzioni. Una o più release future potrebbero trovarsi in lavorazione in parallelo a queste revisioni di manutenzione. Normalmente le persone usano il termine «ramo» (in inglese, branch) per indicare una di queste direzioni leggermente differenti in cui lo sviluppo sta procedendo.

Mercurial è particolarmente adatto a gestire un certo numero di rami paralleli ma non identici. Ogni «direzione di sviluppo» può vivere nel proprio repository centrale e voi potete unire cambiamenti dall’uno all’altro repository quando ne avete bisogno. Dato che i repository sono tra loro indipendenti, i cambiamenti instabili in un ramo di sviluppo non avranno mai effetto su un ramo stabile a meno che qualcuno incorpori esplicitamente quei cambiamenti nel ramo stabile.

Ecco un esempio di come questo processo può funzionare in pratica. Diciamo che avete un «ramo principale» su un server centrale.

$ hg init principale
$ cd principale
$ echo 'Questa è una funzione noiosa.' > miofile
$ hg commit -A -m "Abbiamo raggiunto una pietra miliare importante!"
aggiungo miofile

Altre persone lo clonano, effettuano modifiche locali, le collaudano e le trasmettono indietro.

Una volta che il ramo principale raggiunge la milestone (letteralmente, pietra miliare) di una release, potete usare il comando hg tag per dare un nome permanente alla revisione di milestone.

$ hg tag v1.0
$ hg tip
changeset:   1:be452d95a1d0
etichetta:   tip
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:49:15 2009 +0000
sommario:    Aggiunta l'etichetta v1.0 per il changeset c93791f54ca9

$ hg tags
tip                                1:be452d95a1d0
v1.0                               0:c93791f54ca9

Diciamo che alcune modifiche esterne vengono effettuate sul ramo principale.

$ cd ../principale
$ echo 'Questa è nuova ed eccitante!' >> miofile
$ hg commit -m "Aggiunge una nuova funzione."
$ cat miofile
Questa è una funzione noiosa.
Questa è nuova ed eccitante!

Grazie all’etichetta registrata sulla milestone, chi clonerà quel repository in futuro potrà usare hg update per ottenere una copia della directory di lavoro nello stato esatto in cui si trovava quando quella revisione etichettata è stata inserita.

$ cd ..
$ hg clone -U principale principale-vecchio
$ cd principale-vecchio
$ hg update v1.0
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ cat miofile
Questa è una funzione noiosa.

In più, immediatamente dopo che il ramo principale è stato etichettato, possiamo clonare il ramo principale sul server creando un nuovo ramo «stabile», anche quello sul server.

$ cd ..
$ hg clone -rv1.0 principale stabile
richiedo tutte le modifiche
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 1 cambiamenti a 1 file
aggiorno la directory di lavoro
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti

Se abbiamo bisogno di fare una modifica al ramo stabile, possiamo clonare quel repository, fare i nostri cambiamenti, effettuarne il commit e trasmetterli indietro a quello stesso repository.

$ hg clone stabile stabile-con-correzione
aggiorno la directory di lavoro
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ cd stabile-con-correzione
$ echo 'Questa è una correzione a una funzione noiosa.' > miofile
$ hg commit -m "Corretto un bug."
$ hg push
trasmetto a /tmp/stabile
cerco i cambiamenti
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 1 cambiamenti a 1 file

Dato che i repository Mercurial sono indipendenti e che Mercurial non sposta automaticamente i cambiamenti da un repository a un altro, il ramo principale e quello stabile sono isolati tra loro. I cambiamenti che abbiamo fatto al ramo principale non «filtreranno» verso il ramo stabile e viceversa.

Vorremo spesso che tutte le nostre correzioni di bug nel ramo stabile compaiano anche nel ramo principale. Piuttosto che riscrivere una correzione sul ramo principale, possiamo semplicemente estrarre i cambiamenti dal ramo stabile e unirli a quello principale, così sarà Mercurial a introdurre per noi quelle correzioni di bug.

$ cd ../principale
$ hg pull ../stabile
estraggo da ../stabile
cerco i cambiamenti
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 1 cambiamenti a 1 file (+1 teste)
(eseguite 'hg heads' per vedere le teste, 'hg merge' per unire)
$ hg merge
unisco miofile
0 file aggiornati, 1 file uniti, 0 file rimossi, 0 file irrisolti
(unione tra rami, ricordatevi di eseguire il commit)
$ hg commit -m "Incorpora la correzione del bug dal ramo stabile."
$ cat miofile
Questa è una correzione a una funzione noiosa.
Questa è nuova ed eccitante!

Il ramo principale conterrà ancora cambiamenti che non sono presenti nel ramo stabile, ma conterrà anche tutte le correzioni di bug provenienti dal ramo stabile. Il ramo stabile non viene toccato da quei cambiamenti, dato che le modifiche stanno passando solo dal ramo stabile a quello principale e non nell’altra direzione.

Per progetti di dimensioni più grandi, un modo efficace per gestire i cambiamenti è quello di dividere un gruppo in piccoli sottogruppi. Ogni sottogruppo gestisce un proprio ramo condiviso, clonato da un singolo ramo «principale» usato dall’intero progetto. Le persone che lavorano su un singolo ramo sono tipicamente piuttosto isolate dagli sviluppi che avvengono negli altri rami.

Figura 6.1. Rami di funzione

Quando si ritiene che una funzione particolare sia in una forma appropriata, qualche membro del sottogruppo di quella funzione estrae i cambiamenti dal ramo principale e li unisce al ramo della funzione, poi trasmette le modifiche indietro al ramo principale.

L’organizzazione di alcuni progetti può ricordare quella di un «treno»: le release sono fissate a intervalli di alcuni mesi e includono tutte le funzioni che sono pronte quando il «treno» è pronto a partire.

Questo modello assomiglia all’impiego dei rami di funzione, tranne per il fatto che quando un ramo di funzione perde un treno, qualche membro del gruppo di quella funzione estrae i cambiamenti che sono partiti con il treno della release e li unisce al ramo della funzione. Così, il gruppo continua a lavorare partendo da quella release, in modo che la funzione di cui è responsabile possa essere inclusa nella release successiva.

Il modello di sviluppo del kernel di Linux è caratterizzato da una struttura gerarchica poco profonda circondata da una nuvola di caos apparente. Dato che la maggior parte degli sviluppatori Linux usa git, uno strumento distribuito di controllo di revisione con caratteristiche simili a Mercurial, è utile descrivere come si lavora in quell’ambiente in modo che, se le idee vi piacciono, possiate tradurre il metodo da uno strumento all’altro.

Al centro della comunità siede Linus Torvalds, il creatore di Linux. Linus pubblica un singolo repository di sorgenti che è considerato il ramo «autoritativo» corrente dall’intera comunità di sviluppo. Chiunque può clonare l’albero di Linus, ma Linus è piuttosto selettivo per quanto riguarda gli alberi da cui estrae le modifiche.

Linus ha un certo numero di «luogotenenti di fiducia». Come regola generale, estrae qualunque cambiamento gli trasmettano, nella maggior parte dei casi senza nemmeno revisionare quelle modifiche. Alcuni di quei luogotenenti hanno accettato il ruolo di «manutentori» responsabili di specifici sottosistemi del kernel. Se un programmatore qualsiasi vuole che la propria modifica a un sottosistema del kernel finisca nell’albero di Linus, deve trovare il manutentore di quel sottosistema e chiedergli di accettarla. Se il manutentore revisiona le modifiche e accetta di prenderle, le passerà a Linus al momento giusto.

Ogni singolo luogotenente segue il proprio metodo per revisionare, accettare e pubblicare le modifiche, e per decidere quando passarle a Linus. In più, esistono diversi rami ben noti che vengono usati per scopi differenti. Per esempio, alcune persone mantengono repository «stabili» di vecchie versioni del kernel alle quali applicano correzioni critiche quando è necessario. Alcuni manutentori pubblicano molteplici alberi: uno per modifiche sperimentali, uno per cambiamenti che stanno per passare in alto, e così via. Altri pubblicano semplicemente un singolo albero.

Questo modello ha due caratteristiche importanti. La prima è quella di essere «a sola estrazione». Dovete chiedere, convincere, o implorare un altro sviluppatore di prendere una modifica da voi, perché non c’è quasi nessun albero a cui più di una persona possa trasmettere e non c’è modo di trasmettere cambiamenti a un albero controllato da qualcun altro.

La seconda è quella di essere basato su reputazione e approvazione. Se siete sconosciuti, Linus probabilmente ignorerà le vostre modifiche senza nemmeno rispondervi. Ma il manutentore di un sottosistema probabilmente le revisionerà e sarà disposto ad accettarle se rispettano i suoi criteri di conformità. Più modifiche «buone» presentate a un manutentore, più è probabile che si fidi del vostro giudizio e accetti i vostri cambiamenti. Se siete ben conosciuti e mantenete un ramo di lunga data per qualcosa che Linus non ha ancora accettato, le persone con interessi simili potranno incorporare regolarmente i vostri cambiamenti per rimanere aggiornati sul vostro lavoro.

Reputazione e approvazione non oltrepassano necessariamente i confini tecnici e sociali di un sottosistema. Se siete un programmatore rispettato ma specializzato nell’ambito della memorizzazione dei dati e provate a correggere un bug relativo all’infrastruttura di rete, un manutentore del sottosistema esaminerà minuziosamente quel cambiamento come se fosse stato realizzato da un completo sconosciuto.

Alle persone che provengono da esperienze con progetti più ordinari, il processo di sviluppo relativamente caotico del kernel di Linux sembra spesso completamente folle: subisce i capricci dei singoli, le persone apportano radicali cambiamenti ogni volta che lo ritengono opportuno e la velocità di sviluppo è sorprendente. Nonostante questo, Linux è un software molto apprezzato e di grande successo.

Nella comunità open source si tenta continuamente di stabilire, attraverso accese discussioni, se un modello di sviluppo in cui le persone non fanno altro che estrarre cambiamenti le une dalle altre sia «meglio» di un modello in cui più persone possono trasmettere modifiche a un repository condiviso.

Tipicamente, i sostenitori del modello a scrittura condivisa usano strumenti che impongono attivamente questo approccio. Se state usando uno strumento centralizzato di controllo di revisione come Subversion, non c’è alcun modo di scegliere il modello che userete: lo strumento vi fornisce un modello a scrittura condivisa e se volete fare qualcos’altro dovete strutturare il vostro metodo al di sopra di quel modello (per esempio, applicando una patch a mano).

Un buon sistema distribuito di controllo di revisione supporterà entrambi i modelli. Voi e i vostri collaboratori potrete quindi organizzare il modo di lavorare insieme sulla base dei vostri bisogni e delle vostre preferenze, non delle acrobazie a cui vi costringono gli strumenti.

Una volta che voi e il vostro gruppo avete configurato qualche repository condiviso e cominciato a propagare cambiamenti avanti e indietro tra i repository locali e quelli condivisi, comincerete ad affrontare una sfida correlata ma leggermente differente: quella di gestire le diverse direzioni in cui il vostro gruppo potrebbe muoversi contemporaneamente. Anche se questa materia è intimamente legata al modo in cui il vostro gruppo collabora, è abbastanza densa da meritare una trattazione separata, nel Capitolo 8, Gestire le release e lo sviluppo con i rami.

Dato che hg serve fornisce un accesso non autenticato in lettura a tutti i client, dovreste usarlo solo in un ambiente in cui non vi interessa, o potete interamente controllare, chi può accedere alla vostra rete ed estrarre dati dal vostro repository.

Il comando hg serve non sa nulla del firewall che potreste avere installato a protezione del vostro sistema o della vostra rete: non è in grado di scoprire se avete un firewall né di controllarlo. Se altre persone non riescono ad accedere a un’istanza di hg serve in esecuzione, la seconda cosa che dovreste fare (dopo aver verificato che stiano usando l’URL corretto) è controllare la configurazione del vostro firewall.

Per default, hg serve accetta connessioni in entrata sulla porta 8000. Se un altro processo sta già occupando la porta che volete usare, potete specificare una porta differente tramite l’opzione -p.

Normalmente, quando hg serve parte, non stampa alcuna informazione, cosa che potrebbe intimidirvi. Se volete avere una conferma che il comando stia eseguendo correttamente, e volete scoprire l’esatto URL che dovreste inviare ai vostri collaboratori, lanciate hg serve con l’opzione -v.

Un URL ssh tende ad avere la forma seguente:

ssh://bos@hg.serpentine.com:22/hg/libro

Si rischia facilmente di fare confusione con il percorso locale contenuto negli URL ssh, dato che gli strumenti non hanno un modo standard per interpretarlo. Alcuni programmi si comportano in modo diverso rispetto ad altri quando operano su questi percorsi. Questa non è una situazione ideale, ma è difficile che possa cambiare, quindi leggete il paragrafo seguente con la dovuta attenzione.

Mercurial tratta il percorso di un repository sul server come se fosse relativo alla directory personale dell’utente remoto. Per esempio, se l’utente foo possiede una directory personale /home/foo sul server, allora un URL ssh che contiene un percorso bar si riferisce in realtà alla directory /home/foo/bar.

Se volete specificare un percorso relativo alla directory personale di un altro utente, potete usare un percorso che comincia con un carattere di tilde seguito dal nome utente (chiamiamolo altroutente) in questo modo.

ssh://server/~altroutente/hg/repo

E se proprio volete specificare un percorso assoluto sul server, iniziate il percorso con due caratteri di slash, come in questo esempio.

ssh://server//percorso/assoluto

Quasi tutti i sistemi di tipo Unix includono un’installazione di OpenSSH. Se state usando uno di questi sistemi, eseguite which ssh per scoprire se il comando ssh è installato (di solito si trova nella directory /usr/bin). Nell’improbabile eventualità in cui non sia presente, date un’occhiata alla documentazione del vostro sistema per capire come installarlo.

Su Windows, il pacchetto TortoiseHg comprende una versione dell’eccellente comando plink, realizzato da Simon Tatham, che non dovrebbe avere bisogno di ulteriori configurazioni.

Per evitare di dover ripetutamente digitare una password ogni volta che avete bisogno di usare il vostro client ssh, vi suggerisco di generare una coppia di chiavi.

	Le coppie di chiavi non sono obbligatorie
	Mercurial non sa nulla di autenticazione ssh o coppie di chiavi. Se volete, potete tranquillamente ignorare questa sezione e quella che segue fino a quando non vi stancherete di digitare ripetutamente le password ssh.

Quando generate una coppia di chiavi, di solito è altamente raccomandabile proteggerla con una frase di accesso chiamata passphrase. (L’unico caso in cui potreste non volerlo fare è quando state usando il protocollo ssh per attività automatiche su una rete sicura.)

In ogni caso, generare semplicemente la coppia di chiavi non basta, ma dovrete aggiungere la chiave pubblica all’insieme di chiavi autorizzate che appartiene a qualsiasi utente vogliate utilizzare per accedere al server remoto. Per i server che usano OpenSSH (la grande maggioranza), questo significa aggiungere la chiave pubblica a una lista contenuta in un file chiamato authorized_keys nella directory .ssh dell’utente.

Su un sistema di tipo Unix, la vostra chiave pubblica avrà una estensione .pub. Se state usando puttygen su Windows, potete salvare la chiave pubblica in un file di vostra scelta, o copiarla dalla finestra in cui è visualizzata e incollarla direttamente nel file authorized_keys.

Un agente di autenticazione è un demone che tiene le passphrase in memoria (quindi le dimenticherà se uscite dal sistema e poi rientrate). Un client ssh noterà se un agente è in esecuzione e gli richiederà una passphrase. Se non c’è alcun agente di autenticazione attivo, o se l’agente non ha memorizzato la passphrase necessaria, dovrete digitare la vostra passphrase ogni volta che Mercurial prova a comunicare con il server per vostro conto (per esempio, ogni volta che estraete o trasmettete cambiamenti).

Lo svantaggio di memorizzare le passphrase in un agente è che un aggressore ben preparato sarebbe in grado di recuperare il testo in chiaro delle vostre passphrase, a volte anche se il vostro sistema è stato riavviato. Dovreste giudicare da voi se questo è un rischio che potete correre. Di certo, un agente vi permette di risparmiare tempo evitandovi di digitare ripetutamente sempre lo stesso testo.

Dato che ssh può essere complicato da configurare se non siete esperti, un certo numero di cose potrebbero andare storte. Aggiungete Mercurial a tutto questo, e le possibilità di fare confusione aumenteranno ulteriormente. La maggior parte di questi potenziali problemi si presenta sul lato server, non sul lato client. La buona notizia è che, una volta che avete una configurazione funzionante, di solito continuerà a funzionare indefinitamente.

Prima di provare a usare Mercurial per comunicare con un server ssh, è preferibile che vi assicuriate di poter usare i normali comandi ssh o putty per contattare il server. Se incontrate problemi usando direttamente questi comandi, Mercurial sicuramente non funzionerà e in più nasconderà il problema sottostante. Ogni volta che avete un problema relativo a ssh con Mercurial, per cominciare dovreste accertarvi nuovamente che i semplici comandi ssh lato client funzionino prima di preoccuparvi di eventuali problemi con Mercurial.

La prima cosa di cui accertarsi sul lato server è che siate in grado di entrare nel sistema da un’altra macchina. Se non potete usare ssh o putty per entrare, il messaggio di errore che vi viene mostrato potrebbe darvi alcuni suggerimenti per capire che cosa non va. I problemi più comuni sono i seguenti.

Riepilogando, se avete problemi di comunicazione con il demone ssh del server, per prima cosa assicuratevi che ne esista uno in esecuzione. Su molti sistemi sarà installato ma disabilitato per default. Una volta che avete compiuto questo passo, dovreste controllare che il firewall del server sia configurato per consentire connessioni in entrata verso la porta su cui il demone ssh si trova in ascolto (di solito, la 22). Non preoccupatevi di altri errori di configurazione più esotici fino a quando non avete controllato questi due.

Se state usando un agente di autenticazione sul lato client per memorizzare le passphrase per le vostre chiavi, dovreste essere in grado di accedere al server senza che vi vengano chieste una passphrase o una password. Se vi viene comunque richiesta una passphrase, ecco alcune possibili cause.

Se vi viene richiesta la password per l’utente remoto, ecco altri possibili cause.

In un mondo ideale, dovreste essere in grado di eseguire il comando seguente con successo e ottenere come risultato la stampa di una riga contenente la data e l’ora correnti.

ssh mioserver date

Se gli script di accesso sul vostro server stampano messaggi informativi o altri tipi di testo anche quando eseguite comandi non interattivi come questo, dovreste correggerli prima di continuare, in modo che stampino solo se vengono eseguiti interattivamente. Altrimenti, questi messaggi come minimo confonderanno le stampe di Mercurial e nel caso peggiore potrebbero causare problemi durante l’esecuzione remota dei comandi Mercurial. Mercurial prova a individuare e ignorare questi messaggi durante le sessioni ssh non interattive, ma non è infallibile. (Se state modificando i vostri script di accesso sul vostro server, potete vedere se uno script di accesso viene eseguito in una shell interattiva controllando il codice restituito dal comando tty -s.)

Dopo aver verificato che il buon vecchio ssh stia funzionando con il vostro server, il passo successivo è quello di assicurarsi che Mercurial sia in esecuzione sul server. Il comando seguente dovrebbe terminare con successo:

ssh mioserver hg version

Se vedete un messaggio di errore invece del normale risultato di hg version, di solito questo accade perché non avete installato Mercurial in /usr/bin. Se questo è il caso, non preoccupatevi: non avete bisogno di farlo. Ma dovreste controllare alcuni possibili problemi.

Se riuscite a eseguire hg version attraverso una connessione ssh, ben fatto! Siete riusciti a configurare il client e il server. Ora dovreste essere in grado di usare Mercurial per accedere ai repository ospitati da quel nome utente su quel server. Se a questo punto incontrate qualche problema con Mercurial e ssh, provate a usare l’opzione --debug per avere un’immagine più chiara di quello che sta succedendo.

Mercurial non comprime i dati quando usa il protocollo ssh, perché il protocollo ssh può comprimere i dati in maniera trasparente. Tuttavia, il comportamento predefinito dei client ssh è quello di non richiedere la compressione.

Su qualsiasi rete diversa da una LAN veloce (persino una rete wireless), è probabile che l’uso della compressione velocizzi significativamente le operazioni di rete di Mercurial. Per esempio, qualcuno ha misurato che la compressione riduce il tempo necessario per creare un repository particolarmente grande attraverso una WAN da 51 minuti a 17 minuti.

Sia ssh che plink richiedono l’opzione -C per attivare la compressione. Potete facilmente modificare il vostro file ~/.hgrc in modo da abilitare la compressione per tutti gli utilizzi del protocollo ssh da parte di Mercurial. Per esempio, ecco come fare per l’ordinario comando ssh sui sistemi di tipo Unix.

[ui]
ssh = ssh -C

Se usate ssh su un sistema di tipo Unix, potete configurarlo per usare sempre la compressione quando comunicate con il vostro server. Per fare questo, modificate il vostro file .ssh/config (che potrebbe anche non esistere) come segue.

Host hg
  Compression yes
  HostName hg.example.com

Questo definisce l’alias hg per il nome della macchina. Quando usate l’alias sulla riga di comando ssh o in un URL ssh di Mercurial, ssh si connetterà a hg.example.com e userà la compressione. In questo modo, potete ottenere sia un nome più corto da digitare sia la compressione, che dal canto loro sono entrambe buone cose.

Prima di proseguire, prendetevi qualche momento per controllare alcuni aspetti delle impostazioni del vostro sistema.

Se non avete un server web installato e non avete una considerevole esperienza nel configurare Apache, dovreste considerare l’uso del server web lighttpd invece di Apache. Le configurazioni di Apache hanno la reputazione ben meritata di essere complicate e di confondere gli utenti. Sebbene Apache sia dotato di un numero maggiore di funzioni rispetto a lighttpd, buona parte di queste funzioni non è rilevante per servire repository Mercurial. E lighttpd è innegabilmente molto più facile da affrontare di Apache.

Su sistemi di tipo Unix, di solito gli utenti hanno una sottodirectory con un nome simile a public_html nella propria directory personale da cui possono servire pagine web. Un file chiamato foo in questa directory sarà accessibile tramite un URL della forma http://www.example.com/~nomeutente/foo.

Per cominciare, prendete lo script hgweb.cgi che dovrebbe essere presente nella vostra installazione di Mercurial. Se non riuscite a trovarne velocemente una copia sul vostro sistema, scaricatela da uno dei principali repository di Mercurial all’indirizzo http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi.

Dovrete copiare questo script nella vostra directory public_html e assicurarvi che sia eseguibile.

cp .../hgweb.cgi ~/public_html
chmod 755 ~/public_html/hgweb.cgi

L’argomento 755 passato a chmod ha un effetto un po’ più generale rispetto a quello di rendere lo script eseguibile: garantisce che lo script sia eseguibile da chiunque e che i permessi di scrittura per il «gruppo» e gli «altri» non siano concessi. Se lasciaste abilitati quei permessi, probabilmente il sottosistema suexec di Apache si rifiuterebbe di eseguire lo script. In effetti, suexec insiste sul fatto che anche la directory in cui risiede lo script non sia modificabile da altri.

chmod 755 ~/public_html

chmod 755 ~
find ~/public_html -type d -print0 | xargs -0r chmod 755
find ~/public_html -type f -print0 | xargs -0r chmod 644

<Directory /home/*/public_html>
  AllowOverride FileInfo AuthConfig Limit
  Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
  <Limit GET POST OPTIONS>
    Order allow,deny
    Allow from all
  </Limit>
  <LimitExcept GET POST OPTIONS>
    Order deny,allow Deny from all
  </LimitExcept>
</Directory>

AddHandler cgi-script .cgi

userdir.path = "public_html"
cgi.assign = (".cgi" => "" )

Lo script hgweb.cgi ha una fastidiosa restrizione che vi permette solo di pubblicare un singolo repository. Se volete pubblicarne più di uno senza complicarvi la vita con molteplici copie dello stesso script, ognuna con un nome diverso, la scelta migliore è quella di usare lo script hgwebdir.cgi.

La procedura per configurare hgwebdir.cgi è solo leggermente più complicata di quella per hgweb.cgi. Per prima cosa, dovete ottenere una copia dello script. Se non ne avete una sottomano, potete scaricala dal repository principale di Mercurial all’indirizzo http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi.

Dovrete copiare questo script nella vostra directory public_html e assicurarvi che sia eseguibile.

cp .../hgwebdir.cgi ~/public_html
chmod 755 ~/public_html ~/public_html/hgwebdir.cgi

Una volta effettuata questa configurazione di base, provando a visitare http://nomemacchina/~nomeutente/hgwebdir.cgi con il vostro browser, dovreste vedere una lista di repository vuota. Se ottenete una finestra bianca o un messaggio di errore, provate a ripercorrere la lista di possibili problemi già vista nella Sezione 6.6.2.1, «Che cosa potrebbe andare storto?».

Lo script hgwebdir.cgi si basa su un file di configurazione esterno. Per default, cerca un file chiamato hgweb.config nella stessa directory in cui si trova. Dovrete creare questo file e renderlo leggibile agli altri. Il formato di questo file è simile a quello di un file «ini» di Windows, riconoscibile dal modulo ConfigParser [ConfigParser] di Python.

Il modo più facile di configurare hgwebdir.cgi è tramite una sezione chiamata collections che vi consentirà di pubblicare automaticamente tutti i repository contenuti nelle directory che nominate. La sezione dovrebbe somigliare a questa:

[collections]
/mia/radice = /mia/radice

Mercurial la interpreta guardando al nome della directory sul lato destro del segno «=», individuando i repository nella gerarchia contenuta in quella directory e usando il testo sul lato sinistro per eliminare il testo corrispondente dai nomi che elencherà effettivamente nell’interfaccia web. I componenti del percorso che rimangono dopo questa eliminazione formano un «percorso virtuale».

Dato l’esempio precedente, se abbiamo un repository il cui percorso locale è /mia/radice/questo/repository, lo script CGI eliminerà la parte /mia/radice iniziale dal nome e pubblicherà il repository con il percorso virtuale questo/repository. Se l’URL per il nostro script CGI è http://nomemacchina/~nomeutente/hgwebdir.cgi, l’URL completo per quel repository sarà http://nomemacchina/~nomeutente/hgwebdir.cgi/questo/repository.

Se sostituiamo /mia/radice sul lato sinstro di questo esempio con /mia, allora hgwebdir.cgi eliminerà solo /mia dal nome del repository e ci darà il percorso virtuale radice/questo/repository invece di questo/repository.

Lo script hgwebdir.cgi cercherà i repository ricorsivamente in ogni directory elencata nella sezione collections del suo file di configurazione, ma non navigherà ricorsivamente nei repository che trova.^[4]

Il meccanismo delle collezioni nella sezione collections facilita la pubblicazione di molti repository in modalità «spara e dimentica». Dovete impostare lo script CGI e il file di configurazione una volta sola, dopodiché potete pubblicare o ritirare un repository in ogni momento semplicemente spostandolo dentro o fuori dalla gerarchia di directory in cui hgwebdir.cgi è configurato per guardare.

6.6.3.1. Specificare esplicitamente quali repository pubblicare

In aggiunta al meccanismo basato su collections, lo script hgwebdir.cgi vi consente di pubblicare una lista specifica di repository. Per fare questo, create una sezione paths con un contenuto simile al seguente.

[paths]
repo1 = /mio/percorso/vero/qualche/repository
repo2 = /qualche/percorso/verso/un/altro

In questo caso, il percorso virtuale (il componente che apparirà in un URL) è sul lato sinistro di ogni definizione, mentre il percorso del repository è sulla destra. Notate che non c’è bisogno che esista alcuna relazione tra il percorso virtuale che scegliete e l’ubicazione di un repository sul vostro file system.

Se lo desiderate, potete usare entrambe le sezioni collections e paths contemporaneamente in un unico file di configurazione.

	Fate attenzione ai percorsi virtuali duplicati
	Se diversi repository hanno lo stesso percorso virtuale, hgwebdir.cgi non segnalerà un errore, ma si comporterà in maniera imprevedibile.

L’interfaccia web di Mercurial permette agli utenti di scaricare un archivio di qualsiasi revisione. Questo archivio conterrà la fotografia della directory di lavoro scattata su quella revisione, ma non conterrà una copia dei dati del repository.

Per default, questa funzione è disabilitata. Per abilitarla, dovrete aggiungere un elemento allow_archive alla sezione web del vostro file ~/.hgrc come spiegato in dettaglio nella prossima sezione.

Le interfacce web di Mercurial (il comando hg serve e gli script hgweb.cgi e hgwebdir.cgi) hanno un certo numero di opzioni di configurazione che potete impostare. Queste opzioni appartengono a una sezione chiamata web.

Se state usando hgwebdir.cgi, potete inserire gli elementi di configurazione motd e style nella sezione web del file hgweb.config invece che nel file ~/.hgrc, nel caso lo troviate più conveniente.

Un file hgrc globale può essere utile nella situazione in cui gli utenti stanno estraendo cambiamenti posseduti da altri utenti. Per default, Mercurial non si fida della maggior parte degli elementi di configurazione contenuti nel file .hg/hgrc all’interno di un repository che è posseduto da un utente differente. Se cloniamo o estraiamo i cambiamenti da un repository di questo tipo, Mercurial stamperà un avvertimento dicendo che non si fida dei dati nel file .hg/hgrc di quel repository.

Se tutti i membri di uno specifico gruppo Unix fanno parte dello stesso gruppo di sviluppo e dovrebbero fidarsi l’uno delle impostazioni di configurazione dell’altro, o se vogliamo fidarci di alcuni utenti particolari, possiamo rimpiazzare il comportamento guardingo predefinito di Mercurial creando un file hgrc di sistema come il seguente:

# Salva questo file con un nome tipo /etc/mercurial/hgrc.d/trust.rc
[trusted]
# Fidati di tutte le voci in qualsiasi file hgrc posseduto
# dai gruppi "editors" o "www-data"
groups = editors, www-data

# Fidati delle voci nei file hgrc posseduti dai seguenti utenti.
users = apache, bobo

Questa è un’introduzione ai tipi di pattern che potete usare quando state cercando una corrispondenza con un pattern di tipo glob.

Il carattere «*» corrisponde a qualsiasi stringa all’interno di una singola directory.

$ hg add 'glob:*.py'
aggiungo principale.py

Il pattern «**» corrisponde a qualsiasi stringa e attraversa i confini delle directory. Non è un simbolo di tipo glob standard su Unix, ma viene accettato da diverse shell Unix popolari ed è molto utile.

$ cd ..
$ hg status 'glob:**.py'
A esempi/semplice.py
A sorgenti/principale.py
? esempi/efficiente.py
? setup.py
? sorgenti/controllore/controllore.py

Il pattern «?» corrisponde a qualsiasi carattere singolo.

$ hg status 'glob:**.?'
? sorgenti/controllore/_controllore.c

Il carattere «[» comincia una classe di caratteri. Questo pattern corrisponde a qualsiasi carattere compreso nella classe. La classe viene terminata da un carattere «]». Una classe può contenere molteplici intervalli della forma «a-f», che è una abbreviazione per «abcdef».

$ hg status 'glob:**[nr-t]'
? MANIFEST.in
? sorgenti/xyzzy.txt

Se il primo carattere dopo «[» in una classe di caratteri è «!», si ottiene l’effetto di negare la classe, facendola corrispondere a qualsiasi carattere non compreso nella classe.

Un carattere «{» comincia un gruppo di sottopattern, che trova una corrispondenza se un qualsiasi sottopattern nel gruppo trova una corrispondenza. Il carattere «,» separa i sottopattern e il carattere «}» termina il gruppo.

$ hg status 'glob:*.{in,py}'
? MANIFEST.in
? setup.py

$ hg status 'glob:*.py'
? setup.py
$ hg status 'glob:**.py'
A esempi/semplice.py
A sorgenti/principale.py
? esempi/efficiente.py
? setup.py
? sorgenti/controllore/controllore.py

Mercurial accetta la stessa sintassi per le espressioni regolari che viene usata dal linugaggio di programmazione Python (usa internamente il motore di regexp di Python). Questa sintassi è basata su quella del linguaggio Perl, che è il dialetto più popolare attualmente in uso (è anche utilizzato in Java, per esempio).

Non discuterò alcun dettaglio del dialetto di regexp di Mercurial in questo libro, dato che le espressioni regolari non vengono usate molto spesso. Le regexp in stile Perl sono comunque già documentate in maniera esauriente su una moltitudine di siti web e in numerosi libri. Invece, qui mi concentrerò su alcune cose che dovreste sapere se vi trovate ad aver bisogno di usare le espressioni regolari con Mercurial.

Un’espressione regolare cerca una corrispondenza con un intero nome di file, relativo alla radice del repository. In altre parole, anche se siete già nella sottodirectory foo, se volete una corrispondenza con i file in questa directory il vostro pattern dovrà cominciare con «foo/».

Una cosa da notare, se avete familiarità con le regexp in stile Perl, è che le espressioni regolari di Mercurial sono vincolate, nel senso che un’espressione regolare cerca una corrispondenza partendo sempre dall’inizio di una stringa e non da altre posizioni all’interno della stringa. Per cercare una corrispondenza in qualsiasi punto della stringa, il vostro pattern deve cominciare con «.*».

Il meccanismo di memorizzazione dei repository Mercurial è sicuro per le maiuscole. Traduce i nomi dei file in modo che possano essere memorizzati senza problemi sia su file system sensibili alle maiuscole sia su quelli insensibili alle maiuscole. Questo significa che, per esempio, potete usare i normali strumenti per la copia di file per trasferire un repository Mercurial su una chiave USB, e spostare la chiave e il repository avanti e indietro tra un Mac, un PC con Windows e una macchina Linux senza problemi.

Quando opera sulla directory di lavoro, Mercurial segue la politica di denominazione del file system su cui la directory di lavoro si trova. Se il file system conserva le maiuscole ma è insensibile a esse, Mercurial tratterà i nomi che differiscono solo per le maiuscole come se fossero uguali.

È importante ricordare che questo approccio permette di eseguire su un file system sensibile alle maiuscole (tipicamente Linux o Unix) il commit di un changeset che creerà problemi per gli utenti di file system insensibili alle maiuscole (di solito Windows e MacOS). Se un utente Linux inserisce nel repository le modifiche a due file, uno chiamato miofile.c e l’altro chiamato MioFile.c, questi file verranno memorizzati correttamente. E gli stessi file verranno correttamente rappresentati come due file separati nella directory di lavoro di altri utenti Linux.

Se un utente Windows o Mac estrae questo changeset, inizialmente non avrà alcun problema, perché il meccanismo di memorizzazione di un repository Mercurial è sicuro per le maiuscole. Tuttavia, appena tenta di aggiornare la directory di lavoro a quel changeset tramite hg update, o di unire il proprio lavoro con quel changeset tramite hg merge, Mercurial individuerà il conflitto tra i due nomi di file che il file system tratterebbe come lo stesso nome e impedirà all’aggiornamento o all’unione di avvenire.

Se state usando Windows o Mac in un ambiente misto dove alcuni dei vostri collaboratori usano Linux o Unix, e Mercurial riporta un conflitto di ripiegamento delle maiuscole quando provate a eseguire hg update o hg merge, la procedura per correggere il problema è semplice.

Trovate la macchina Linux o Unix più vicina, clonatevi il repository problematico e usate il comando hg rename di Mercurial per cambiare i nomi di qualsiasi file o directory che crea complicazioni, in modo da non causare più alcun conflitto di ripiegamento delle maiuscole. Inserite queste modifiche nel repository, eseguite hg pull o hg push attraverso i vostri sistemi Windows o MacOS e usate hg update per aggiornare la directory di lavoro alla revisione che contiene i nomi senza conflitti.

Il changeset con i nomi in conflitto rimarrà nella cronologia del vostro progetto e non sarete comunque in grado di usare hg update per aggiornare la directory di lavoro a quel changeset su un sistema Windows o MacOS, ma potrete continuare a sviluppare senza impedimenti.

Avrete raramente bisogno di preoccuparvi del file .hgtags, ma talvolta la sua presenza si farà sentire durante un’unione. Il formato del file è semplice: consiste di una serie di righe, ognuna delle quali comincia con un hash di changeset, seguito da uno spazio, seguito dal nome di un’etichetta.

Se state risolvendo un conflitto nel file .hgtags durante un’unione, c’è una particolarità da ricordare quando modificate il file .hgtags: quando Mercurial sta analizzando le etichette in un repository, non legge mai la copia di lavoro del file .hgtags, ma legge la revisione del file registrata più recentemente.

Una sfortunata conseguenza di questo comportamento è che non potete verificare la correttezza del file .hgtags risultato dall’unione se non dopo aver effettuato il commit di un cambiamento. Quindi, se vi trovate a risolvere un conflitto su .hgtags durante un’unione, assicuratevi di eseguire hg tags dopo aver effettuato il commit. Se il comando trova un errore nel file .hgtags, vi indicherà la posizione dell’errore, che potrete dunque correggere registrando la correzione nel repository. Dovreste poi eseguire ancora hg tags, giusto per essere sicuri che la vostra correzione sia valida.

Potreste aver notato che il comando hg clone offre un’opzione -r per lasciarvi clonare la copia esatta di una particolare revisione di un repository. Il nuovo clone non conterrà alcuna cronologia del progetto registrata dopo la revisione che avete specificato. Questa operazione interagisce con le etichette in un modo che potrebbe sorprendere i più distratti.

Se ricordate, un’etichetta viene memorizzata come una revisione del file .hgtags. Quando create un’etichetta, il changeset in cui viene registrata si riferisce a un changeset precedente. Quando eseguite hg clone -r foo per clonare un repository all’etichetta foo, il nuovo clone non conterrà alcuna revisione più recente di quella a cui si riferisce l’etichetta, compresa la revisione in cui l’etichetta è stata creata. Come risultato, otterrete esattamente il sottoinsieme corretto della cronologia del progetto nel nuovo repository, ma non l’etichetta che vi sareste potuti aspettare.

Dato che le etichette di Mercurial sono soggette a controllo di revisione e fanno parte della cronologia del progetto, chiunque lavori con voi vedrà le etichette che avete creato. Ma i nomi delle revisioni possono essere usati in modi che vanno oltre la semplice annotazione che la revisione 4237e45506ee è in realtà la v2.0.2. Se state provando a rintracciare un bug intricato, poteste volere un’etichetta per ricordarvi di qualcosa come «Anna ha visto gli effetti del bug in questa revisione».

In casi come questo, quello che potreste voler usare sono le etichette locali. Un’etichetta locale viene creata tramite l’opzione -l del comando hg tag e viene memorizzata in un file chiamato .hg/localtags. Diversamente da .hgtags, .hg/localtags non è soggetto a controllo di revisione, quindi qualsiasi etichetta creiate usando l’opzione -l rimarrà strettamente locale al repository in cui state attualmente lavorando.