All’inizio del 2003, Andreas Gruenbacher e Martin Quinson presero in prestito l’approccio degli script di Andrew e pubblicarono uno strumento chiamato «patchwork quilt» (letteralmente, coperta a scacchi) [Quilt], o semplicemente «quilt» (si veda [Gruenbacher2005] per un articolo che lo descrive). Dato che quilt sostanzialmente automatizzava la gestione delle patch, guadagnò rapidamente un grande seguito tra gli sviluppatori di software open source.

Quilt gestisce una pila di patch per un albero di directory. Per cominciare a usarlo, dite a quilt di gestire un albero di directory e quali file volete che gestisca, in modo che memorizzi i nomi e il contenuto di quei file. Per correggere un bug, create una nuova patch (usando un singolo comando), modificate i file che dovete correggere, poi «aggiornate» la patch.

L’operazione di aggiornamento induce quilt a esaminare l’albero di directory completando la patch con tutte le modifiche che avete fatto. Sulla base di questa prima patch, potete creare un’altra patch che terrà traccia dei cambiamenti richiesti per modificare l’albero da «albero con una patch applicata» ad «albero con due patch applicate».

Potete scegliere quali sono le patch da applicare all’albero. Se «estraete» una patch, i cambiamenti effettuati da quella patch spariranno dall’albero di directory. Quilt si ricorda quali patch avete estratto, comunque, così potete «inserire» nuovamente una patch estratta e l’albero di directory verrà ripristinato per contenere le modifiche di quella patch. La cosa più importante è che potete eseguire il comando di «aggiornamento» in ogni momento e la patch applicata più recentemente verrà aggiornata. Questo significa che, in ogni momento, potete modificare sia l’insieme delle patch da applicare sia l’insieme dei cambiamenti effettuati da quelle patch.

Quilt non ha nulla a che fare con gli strumenti di controllo di revisione, così funziona altrettanto bene con un gruppo di file estratti da un archivio compresso che con una copia di lavoro di Subversion.

A metà del 2005, Chris Mason prese le funzioni di quilt e implementò un’estensione chiamata Mercurial Queues, che aggiungeva a Mercurial un comportamento simile a quello di quilt.

La differenza chiave tra quilt e MQ è che quilt non è progettato per interagire con alcun sistema di controllo di revisione, mentre MQ è integrata in Mercurial. Ogni patch che inserite è rappresentata sotto forma di changeset Mercurial. Se estraete una patch, il changeset relativo sparisce.

Dato che quilt non si preoccupa degli strumenti di controllo di revisione, rimane un software tremendamente utile da conoscere per impiegarlo nelle situazioni in cui non potete usare Mercurial e MQ.

Per cominciare a lavorare su una nuova patch, usate il comando qnew. Questo comando prende come argomento il nome della patch da creare.

MQ userà questo nome per memorizzare un file nella directory .hg/patches, come potete vedere qui sotto.

$ hg tip
changeset:   0:c6618fa9eed7
etichetta:   tip
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:50:56 2009 +0000
sommario:    Prima modifica.

$ hg qnew prima.patch
$ hg tip
changeset:   1:f32697f1a94e
etichetta:   qtip
etichetta:   prima.patch
etichetta:   tip
etichetta:   qbase
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:50:57 2009 +0000
sommario:    [mq]: prima.patch

$ ls .hg/patches
prima.patch  series  status

La directory .hg/patches contiene anche altri due nuovi file, series e status. Il file series elenca tutte le patch per questo repository di cui MQ è a conoscenza, con una patch per ogni riga. Mercurial usa il file status per tenere traccia internamente di tutte le patch che MQ ha applicato a questo repository.

	Nota
	A volte potreste voler modificare il file series a mano, per esempio per cambiare la sequenza in cui sono applicate alcune patch. Tuttavia, modificare manualmente il file status è quasi sempre una cattiva idea, dato che così facendo si rischia facilmente di disorientare MQ.

Una volta che avete creato la vostra nuova patch, potete modificare i file nella directory di lavoro come fareste di solito. Tutti i normali comandi Mercurial, come hg diff e hg annotate, funzionano allo stesso modo in cui funzionavano prima.

Quando raggiungete un punto in cui volete salvare il vostro lavoro, usate il comando qrefresh per aggiornare la patch su cui state lavorando.

$ echo 'riga 2' >> file1
$ hg diff
diff -r f32697f1a94e file1
--- a/file1	Fri Jun 05 15:50:57 2009 +0000
+++ b/file1	Fri Jun 05 15:50:58 2009 +0000
@@ -1,1 +1,2 @@
 riga 1
+riga 2
$ hg qrefresh
$ hg diff
$ hg tip --style=compact --patch
1[qtip,prima.patch,tip,qbase]   18f39bf02ad5   2009-06-05 15:50 +0000   bos
  [mq]: prima.patch

diff -r c6618fa9eed7 -r 18f39bf02ad5 file1
--- a/file1	Fri Jun 05 15:50:56 2009 +0000
+++ b/file1	Fri Jun 05 15:50:59 2009 +0000
@@ -1,1 +1,2 @@
 riga 1
+riga 2

Questo comando include nella vostra patch i cambiamenti che avete fatto nella directory di lavoro e aggiorna il changeset corrispondente alla patch in modo che contenga quei cambiamenti.

Potete invocare qrefresh tutte le volte che volete, quindi questo comando rappresenta un buon modo per «controllare» il vostro lavoro. Aggiornate la vostra patch al momento opportuno, tentate un esperimento e se l’esperimento non funziona usate hg revert per ripristinare le vostre modifiche all’ultimo aggiornamento che avete compiuto.

$ echo 'riga 3' >> file1
$ hg status
M file1
$ hg qrefresh
$ hg tip --style=compact --patch
1[qtip,prima.patch,tip,qbase]   8593307a06ec   2009-06-05 15:51 +0000   bos
  [mq]: prima.patch

diff -r c6618fa9eed7 -r 8593307a06ec file1
--- a/file1	Fri Jun 05 15:50:56 2009 +0000
+++ b/file1	Fri Jun 05 15:51:00 2009 +0000
@@ -1,1 +1,3 @@
 riga 1
+riga 2
+riga 3

Una volta che avete finito di lavorare su una patch, o avete bisogno di lavorare su un’altra patch, potete usare di nuovo il comando qnew per creare una nuova patch. Mercurial applicherà questa patch a partire dalla vostra patch esistente.

$ hg qnew seconda.patch
$ hg log --style=compact --limit=2
2[qtip,seconda.patch,tip]   2d7ecb80769d   2009-06-05 15:51 +0000   bos
  [mq]: seconda.patch

1[prima.patch,qbase]   8593307a06ec   2009-06-05 15:51 +0000   bos
  [mq]: prima.patch

$ echo 'riga 4' >> file1
$ hg qrefresh
$ hg tip --style=compact --patch
2[qtip,seconda.patch,tip]   78d47e79ab59   2009-06-05 15:51 +0000   bos
  [mq]: seconda.patch

diff -r 8593307a06ec -r 78d47e79ab59 file1
--- a/file1	Fri Jun 05 15:51:00 2009 +0000
+++ b/file1	Fri Jun 05 15:51:02 2009 +0000
@@ -1,3 +1,4 @@
 riga 1
 riga 2
 riga 3
+riga 4

$ hg annotate file1
0: riga 1
1: riga 2
1: riga 3
2: riga 4

Notate che la patch contiene le modifiche della nostra patch precedente come parte del proprio contesto (potete vederlo più chiaramente nel risultato di hg annotate).

Finora, con l’eccezione di qnew e qrefresh, siamo stati attenti a usare solo gli ordinari comandi Mercurial. Tuttavia, MQ fornisce molti comandi che sono più facili da usare quando state pensando in termini di patch, come illustrato di seguito.

$ hg qseries
prima.patch
seconda.patch
$ hg qapplied
prima.patch
seconda.patch

La discussione precedente implica che ci deve essere una differenza tra patch «note» e patch «applicate», e in effetti c’è. MQ può gestire una patch senza che sia applicata al repository.

Una patch applicata ha un corrispondente changeset nel repository e gli effetti della patch e del changeset sono visibili nella directory di lavoro. Potete annullare l’applicazione di una patch usando il comando qpop. La patch estratta è ancora nota, cioè gestita da MQ, ma non ha più un corrispondente changeset nel repository, e la directory di lavoro non contiene più le modifiche apportate dalla patch. La Figura 12.1, «Patch applicate e non applicate nella pila delle patch di MQ» illustra la differenza tra patch applicate e registrate.

Figura 12.1. Patch applicate e non applicate nella pila delle patch di MQ

Potete riapplicare una patch non applicata o estratta usando il comando qpush. Questo comando crea un nuovo changeset da far corrispondere alla patch, e le modifiche della patch compaiono nuovamente nella directory di lavoro. Di seguito, vengono mostrati esempi di qpop e qpush in azione.

$ hg qapplied
prima.patch
seconda.patch
$ hg qpop
ora a: prima.patch
$ hg qseries
prima.patch
seconda.patch
$ hg qapplied
prima.patch
$ cat file1
riga 1
riga 2
riga 3

Notate che, dopo aver estratto una patch o due patch, il risultato di qseries è rimasto lo stesso, mentre quello di qapplied è cambiato.

Sebbene i comandi qpush e qpop operino in maniera predefinita su una singola patch alla volta, potete inserire ed estrarre molte patch in un unico passaggio. L’opzione -a di qpush lo induce a inserire tutte le patch non applicate, mentre l’opzione -a di qpop lo induce a estrarre tutte le patch applicate. (Per ulteriori modi di inserire ed estrarre molte patch, si veda la Sezione 12.8, «Ottenere le prestazioni migliori da MQ» più avanti.)

$ hg qpush -a
applico seconda.patch
ora a: seconda.patch
$ cat file1
riga 1
riga 2
riga 3
riga 4

Diversi comandi MQ esaminano la directory di lavoro prima di fare qualunque cosa e falliscono se trovano una qualsiasi modifica. Si comportano in questo modo per assicurarsi di non farvi perdere i cambiamenti che avete fatto ma che non avete ancora incorporato in una patch. L’esempio seguente illustra questo caso: il comando qnew eviterà di creare una nuova patch se ci sono cambiamenti in sospeso, causati in questo caso dall’invocazione di hg add su file3.

$ echo 'file 3, riga 1' >> file3
$ hg add file3
$ hg qnew aggiunto-file3.patch
fallimento: ci sono modifiche locali, aggiornate prima la patch corrente
$ hg qnew -f aggiunto-file3.patch

Tutti i comandi che esaminano la directory di lavoro accettano un’opzione «so cosa sto facendo» che si chiama sempre -f. L’esatto significato di -f dipende dal comando. Per esempio, hg qnew -f incorporerà i cambiamenti in sospeso nella nuova patch creata, ma hg qpop -f annullerà le modifiche a qualsiasi file coinvolto dalla patch che sta estraendo. Assicuratevi di leggere la documentazione per l’opzione -f di un comando prima di usarla!

Il comando qrefresh aggiorna sempre la patch applicata più recentemente. Questo significa che potete sospendere il lavoro su una patch (aggiornandola), operare estrazioni o inserimenti in modo che l’ultima patch applicata sia differente e lavorare su questa patch per un po’.

Ecco un esempio che illustra come potete sfruttare questa possibilità. Diciamo che state sviluppando una nuova funzione sotto forma di due patch. La prima è una modifica al nucleo del vostro software e la seconda—basata sulla prima—modifica l’interfaccia utente per usare il codice che avete appena aggiunto al nucleo. Se notate un bug nel nucleo mentre state lavorando sulla patch per l’interfaccia utente, per correggerlo vi basta usare qrefresh, in modo da salvare le modifiche in corso alla vostra patch di interfaccia, e poi usare qpop per poter operare sulla patch del nucleo. Correggete il bug nel nucleo, aggiornate la patch del nucleo con qrefresh e inserite la patch di interfaccia tramite qpush per continuare a lavorare dal punto dove avevate lasciato.

Se osservate le intestazioni di file in una patch, noterete che i percorsi dei nomi di solito hanno un componente aggiuntivo iniziale che non è presente nel percorso reale. Questo è uno strascico del modo in cui le persone erano abituate a generare le patch (questo modo viene ancora impiegato, ma piuttosto raramente ora che sono disponibili strumenti di controllo di revisione più moderni).

Alice avrebbe estratto un archivio, modificato i file e poi deciso di voler creare una patch. Quindi avrebbe rinominato la directory di lavoro, estratto nuovamente l’archivio (da qui nasce il bisogno di modificare il nome) e usato le opzioni -r e -N del comando diff per generare ricorsivamente una patch tra la directory non modificata e quella modificata. Come risultato, il nome della directory non modificata si sarebbe trovato all’inizio del percorso sulla parte sinistra di ogni intestazione di file e il nome della directory modificata si sarebbe trovato all’inizio del percorso sulla parte destra.

Dato che chi riceveva una patch dalle Alice della rete probabilmente non avrebbe avuto le due copie, modificata e non, della directory con esattamente gli stessi nomi, il comando patch è stato dotato di un’opzione -p che indica il numero di elementi iniziali da eliminare dal percorso al momento di applicare una patch. Questo numero viene chiamato il numero di cancellazioni.

Un’opzione «-p1» significa «usa un numero di cancellazioni pari a uno». Se patch vede un nome di file foo/bar/baz in un’intestazione di file, eliminerà foo e proverà ad applicare la patch al file bar/baz. Strettamente parlando, il numero di cancellazioni si riferisce al numero di separatori di percorso (e dei relativi elementi) da eliminare. Un numero di cancellazioni pari a uno trasformerà foo/bar in bar, ma /foo/bar (notate lo slash iniziale) in foo/bar.

Il numero di cancellazioni «standard» per le patch è pari a uno, in quanto quasi tutte le patch contengono un elemento iniziale da eliminare nel percorso. Il comando hg diff di Mercurial genera nomi di percorso in questa forma e sia il comando hg import che MQ si aspettano patch con un numero di cancellazioni pari a uno.

Se qualcuno vi invia una patch che volete aggiungere alla vostra coda delle patch e la patch necessita di un numero di cancellazioni diverso da uno, non potete usare semplicemente qimport con la patch, perché qimport non è ancora dotato di un’opzione -p (si veda il problema 311 per i dettagli). L’alternativa migliore che avete è quella di creare una vostra patch con qnew e poi usare il comando patch -pN per applicare la patch che avete ricevuto, seguito da hg addremove per registrare qualsiasi file aggiunto o rimosso dalla patch, seguito da hg qrefresh. Questa complessità potrebbe diventare inutile una volta che il problema 311 verrà risolto.

Quando patch applica un blocco, prova a impiegare una serie di strategie successive sempre meno accurate per portare a termine l’operazione. Questo impiego di tecniche alternative rende spesso possibile prendere una patch che è stata generata a partire da una vecchia versione di un file e applicarla alla nuova versione di quel file.

Come prima cosa, patch cerca una corrispondenza esatta, dove i numeri di riga, il contesto e il testo da modificare devono applicarsi perfettamente. Se non riesce a trovare una corrispondenza esatta, cerca una corrispondenza esatta per il contesto, senza onorare le informazioni sulla numerazione delle righe. Se questa strategia ha successo, il comando stampa una riga dicendo che il blocco è stato applicato, ma con un certo scostamento rispetto al numero di riga originale.

Se la corrispondenza con il solo contesto fallisce, patch rimuove la prima e l’ultima riga del contesto e tenta una corrispondenza con la sola versione ridotta del contesto. Se il blocco con il contesto ridotto ha successo, stampa un messaggio dicendo di aver applicato il blocco con un fattore di incertezza (il numero dopo il fattore di incertezza indica quante righe del contesto sono state escluse da patch prima che la patch si potesse applicare).

Quando nessuna di queste tecniche funziona, patch stampa un messaggio dicendo che il blocco in questione è stato rifiutato. Il comando salva i blocchi rifiutati (anche chiamati semplicemente «rifiuti») in un file con lo stesso nome e un’estensione .rej aggiuntiva. Le copie non modificate del file vengono salvate con un’estensione .orig, mentre la copia del file senza alcuna estensione conterrà le modifiche fatte dai blocchi che sono stati effettivamente applicati. Se avete una patch che modifica il file foo con sei blocchi, ma uno di essi non si riesce ad applicare, otterrete una copia foo.orig non modificata del file originale, un file foo.rej contenente un blocco e il file foo contenente le modifiche effettuate dai cinque blocchi applicati con successo.

Ci sono alcune cose utili da sapere sul modo in cui patch lavora con i file.

Anche se l’applicazione di un blocco con un certo scostamento o con un certo fattore di incertezza avrà spesso un successo completo, queste tecniche inesatte lasciano naturalmente aperta la possibilità di rovinare il file modificato. Il caso più comune è tipicamente quello in cui la patch viene applicata due volte o in una posizione sbagliata nel file. Se patch o qpush dovessero mai menzionare lo scostamento o il fattore di incertezza, dovreste assicurarvi che i file siano stati modificati in maniera corretta.

Spesso è una buona idea aggiornare una patch che è stata applicata con uno scostamento o un fattore di incertezza, perché l’aggiornamento della patch genera nuove informazioni di contesto che permetteranno di applicarla in maniera precisa. Dico «spesso», non «sempre», perché qualche volta l’aggiornamento di una patch ne renderà impossibile l’applicazione su una revisione differente dei file coinvolti. In alcuni casi, come quando state mantenendo una patch che deve essere applicabile a molteplici versioni di un albero di sorgenti, è considerato accettabile avere una patch che si applica con qualche incertezza, purché abbiate verificato i risultati del processo di applicazione in casi come questi.

Se qpush non riesce ad applicare una patch, stamperà un messaggio di errore e terminerà. Se ha lasciato alcuni file .rej, normalmente è meglio correggere i blocchi rifiutati prima di inserire altre patch o fare qualsiasi ulteriore modifica.

Se di solito la vostra patch si applicava in maniera pulita e ora non lo fa più perché avete modificato il codice sottostante su cui si basavano le vostre patch, Mercurial Queues può aiutarvi: leggete la Sezione 12.9, «Aggiornare le vostre patch quando il codice sottostante cambia» per i dettagli.

Sfortunatamente, non esiste alcuna tecnica particolare per gestire i blocchi rifiutati. Molto spesso, dovrete esaminare il file .rej e modificare il file di destinazione, applicando a mano i blocchi rifiutati.

Un programmatore del kernel di Linux, Chris Mason (l’autore di Mercurial Queues), ha realizzato uno strumento chiamato mpatch [Mason], che adotta un metodo semplice per automatizzare l’applicazione dei blocchi rifiutati da patch. Il comando mpatch può aiutarvi nel caso il blocco sia stato rifiutato per quattro tipiche ragioni:

Se usate il comando mpatch, dovreste stare doppiamente attenti quando controllate i risultati al termine dell’esecuzione. In effetti, mpatch impone questo metodo di doppio controllo sul risultato dello strumento, avviando automaticamente un programma di gestione delle unioni quando ha concluso il proprio lavoro, in modo che possiate verificare i risultati e risolvere qualsiasi conflitto rimanente.

Se volete sbarazzarvi di una patch, usate il comando hg qdelete per cancellare il file contenente la patch e rimuovere la sua voce dalla serie di patch. Se provate a cancellare una patch che è ancora applicata, hg qdelete si rifiuterà di operare.

$ hg init miorepo
$ cd miorepo
$ hg qinit
$ hg qnew cattiva.patch
$ echo a > a
$ hg add a
$ hg qrefresh
$ hg qdelete cattiva.patch
fallimento: non posso cancellare la patch applicata cattiva.patch
$ hg qpop
la coda delle patch è vuota
$ hg qdelete cattiva.patch

Una volta che avete finito di lavorare con una patch e volete trasformarla in un changeset permanente, usate il comando hg qfinish. Passate una revisione al comando per identificare la patch che volete trasformare in un normale changeset; questa patch deve essere già stata applicata.

$ hg qnew buona.patch
$ echo a > a
$ hg add a
$ hg qrefresh -m "Buona modifica."
$ hg qfinish tip
$ hg qapplied
$ hg tip --style=compact
0[tip]   8eae2605f537   2009-06-05 15:49 +0000   bos
  Buona modifica.

Il comando hg qfinish accetta un’opzione --all o -a per trasformare tutte le patch applicate in normali changeset.

È anche possibile trasformare un changeset esistente in una patch, passando l’opzione -r al comando hg qimport.

$ hg qimport -r tip
$ hg qapplied
0.diff

Notate che ha senso convertire un changeset in una patch solo se non avete propagato quel changeset in altri repository. L’identificatore del changeset importato cambierà ogni volta che aggiornate la patch, cosa che indurrà Mercurial a trattarlo come se non fosse correlato al changeset originale che avete trasmesso da qualche altra parte.

MQ vi aiuta a lavorare con la directory .hg/patches in qualità di repository. Quando preparate un repository per lavorare con le patch usando qinit, potete passare l’opzione -c per creare la directory .hg/patches sotto forma di repository Mercurial.

	Nota
	Se dimenticate di usare l’opzione -c, potete semplicemente posizionarvi nella directory .hg/patches in qualsiasi momento e invocare hg init. Non dimenticate, però, di aggiungere una voce per il file status al file .hgignore (hg qinit -c lo fa automaticamente per voi), perché il file status non andrebbe davvero amministrato.

Per convenienza, se MQ nota che la directory .hg/patches è un repository, userà automaticamente hg add per aggiungere ogni patch che create e importate.

MQ fornisce il comando abbreviato qcommit che esegue hg commit nella directory .hg/patches, per risparmiarvi noiose digitazioni.

Infine, sui sistemi Unix, potete definire l’alias mq come comando di convenienza per gestire la directory delle patch. Per esempio, sui sistemi Linux che usano la shell bash, potete aggiungere la riga seguente al vostro file ~/.bashrc.

alias mq=`hg -R $(hg root)/.hg/patches'

Potete poi invocare comandi della forma mq pull dal repository principale.

Il supporto di MQ per lavorare con un repository pieno di patch è limitato in alcuni aspetti di dettaglio.

MQ non può automaticamente scoprire quali modifiche avete fatto alla directory delle patch. Se usate hg pull, apportate cambiamenti a mano, o invocate hg update per aggiornare le modifiche alle patch o al file series, dovrete usare hg qpop -a e poi hg qpush -a nel repository sottostante per fare in modo che quelle modifiche compaiano anche là. Se dimenticate di fare questo, potreste confondere le idee a MQ in merito a quali patch sono state effettivamente applicate.

Dato che il costo di aggiungere file in un nuovo repository Mercurial è così basso, ha molto senso gestire le patch in questo modo anche se volete semplicemente fare alcune modifiche a un archivo di sorgenti che avete scaricato.

Cominciate con lo scaricare l’archivio dei sorgenti, estraendone i contenuti e trasformandoli in un repository Mercurial.

# Scarichiamo netplug-1.2.5.tar.bz2
$ tar jxf netplug-1.2.5.tar.bz2
$ cd netplug-1.2.5
$ hg init
$ hg commit -q --addremove --message netplug-1.2.5
$ cd ..
$ hg clone netplug-1.2.5 netplug
aggiorno la directory di lavoro
18 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti

Continuate creando una pila di patch e facendo le vostre modifiche.

$ cd netplug
$ hg qinit
$ hg qnew -m 'corregge un problema di assemblaggio con gcc 4' correzione-assemblaggio.patch
$ perl -pi -e 's/int addr_len/socklen_t addr_len/' netlink.c
$ hg qrefresh
$ hg tip -p
changeset:   1:5227ba4b6a8b
etichetta:   qtip
etichetta:   correzione-assemblaggio.patch
etichetta:   tip
etichetta:   qbase
utente:      Bryan O'Sullivan <bos@serpentine.com>
data:        Fri Jun 05 15:50:51 2009 +0000
sommario:    corregge un problema di assemblaggio con gcc 4

diff -r e709896f2959 -r 5227ba4b6a8b netlink.c
--- a/netlink.c	Fri Jun 05 15:50:49 2009 +0000
+++ b/netlink.c	Fri Jun 05 15:50:51 2009 +0000
@@ -275,7 +275,7 @@
         exit(1);
     }
 
-    int addr_len = sizeof(addr);
+    socklen_t addr_len = sizeof(addr);
 
     if (getsockname(fd, (struct sockaddr *) &addr, &addr_len) == -1) {
         do_log(LOG_ERR, "Could not get socket details: %m");

Diciamo che trascorrono alcune settimane o mesi e gli autori di quel pacchetto rilasciano una nuova versione. Prima di tutto, propagate i loro cambiamenti nel repository.

$ hg qpop -a
la coda delle patch è vuota
$ cd ..
# Scarichiamo netplug-1.2.8.tar.bz2
$ hg clone netplug-1.2.5 netplug-1.2.8
aggiorno la directory di lavoro
18 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ cd netplug-1.2.8
$ hg locate -0 | xargs -0 rm
$ cd ..
$ tar jxf netplug-1.2.8.tar.bz2
$ cd netplug-1.2.8
$ hg commit --addremove --message netplug-1.2.8

La coppia di comandi che comincia con hg locate appena invocata cancella tutti i file dalla directory di lavoro, in modo che l’opzione --addremove di hg commit possa effettivamente dirvi quali file sono stati davvero rimossi nella nuova versione dei sorgenti.

Infine, potete applicare le vostre patch al nuovo albero.

$ cd ../netplug
$ hg pull ../netplug-1.2.8
estraggo da ../netplug-1.2.8
cerco i cambiamenti
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 12 cambiamenti a 12 file
(eseguite 'hg update' per ottenere una copia di lavoro)
$ hg qpush -a
(la directory di lavoro non è alla punta)
applico correzione-assemblaggio.patch
ora a: correzione-assemblaggio.patch

MQ vi fornisce il comando qfold per consentirvi di combinare intere patch tra loro. Questo comando «include» le patch che nominate, nell’ordine in cui le nominate, nell’ultima patch applicata e concatena le loro descrizioni aggiungendole alla fine della descrizione di questa patch. Se le patch che includete sono applicate, devono essere estratte prima di poterle includere.

L’ordine in cui includete le patch è importante. Se la vostra ultima patch applicata è foo e voi utilizzate qfold per includervi bar e quux, otterrete una patch che opererà come se aveste applicato prima foo, poi bar, seguita da quux.

Unire parte di una patch a un’altra patch è più difficile che combinare intere patch tra loro.

Se volete spostare alcune modifiche su interi file, potete usare le opzioni -i e -x di filterdiff per scegliere le modifiche che desiderate ricavare da una patch, aggiungendo il risultato del comando in coda alla patch a cui unire i cambiamenti. Di solito non avrete bisogno di modificare la patch da cui prelevate le modifiche da unire. Piuttosto, MQ rifiuterà alcune parti della patch quando invocate qpush su di essa (a causa dei blocchi che avete spostato nell’altra patch) e voi potrete semplicemente aggiornare la patch tramite qrefresh per scartare i blocchi duplicati.

Se avete una patch con più blocchi che modificano un file e volete spostare solo alcuni di questi blocchi, il lavoro diventa più complicato, ma potete comunque automatizzarlo parzialmente. Usate lsdiff -nvv per stampare alcuni metadati sulla patch.

$ lsdiff -nvv rimuove-controlli-ridondati-su-null.patch
22	File #1  		a/drivers/char/agp/sgi-agp.c
	24	Blocco #1	static int __devinit agp_sgi_init(void)
37	File #2  		a/drivers/char/hvcs.c
	39	Blocco #1	static struct tty_operations hvcs_ops = 
	53	Blocco #2	static int hvcs_alloc_index_list(int n)
69	File #3  		a/drivers/message/fusion/mptfc.c
	71	Blocco #1	mptfc_GetFcDevPage0(MPT_ADAPTER *ioc, in
85	File #4  		a/drivers/message/fusion/mptsas.c
	87	Blocco #1	mptsas_probe_hba_phys(MPT_ADAPTER *ioc)
98	File #5  		a/drivers/net/fs_enet/fs_enet-mii.c
	100	Blocco #1	static struct fs_enet_mii_bus *create_bu
111	File #6  		a/drivers/net/wireless/ipw2200.c
	113	Blocco #1	static struct ipw_fw_error *ipw_alloc_er
	126	Blocco #2	static ssize_t clear_error(struct device
	140	Blocco #3	static void ipw_irq_tasklet(struct ipw_p
	150	Blocco #4	static void ipw_pci_remove(struct pci_de
164	File #7  		a/drivers/scsi/libata-scsi.c
	166	Blocco #1	int ata_cmd_ioctl(struct scsi_device *sc
178	File #8  		a/drivers/video/au1100fb.c
	180	Blocco #1	void __exit au1100fb_cleanup(void)

Questo comando stampa tre tipi diversi di numeri:

Dovrete leggere e ispezionare visivamente la patch per identificare i numeri di file e di blocco che volete, ma poi potrete passarli alle opzioni --files e --hunks di filterdiff per selezionare esattamente quel file e il blocco che volete estrarre.

Una volta che avete questo blocco, potete aggiungerlo in coda alla vostra patch di destinazione e continuare con il resto della Sezione 12.15.2, «Combinare intere patch».