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 chiamata «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.