1.1 --- a/it/ch12-mq.xml	Sat Aug 08 23:52:15 2009 +0200
     1.2 +++ b/it/ch12-mq.xml	Sun Aug 09 01:02:53 2009 +0200
     1.3 @@ -5,48 +5,48 @@
     1.4    <sect1 id="sec:mq:patch-mgmt">
     1.5      <title>Il problema della gestione delle patch</title>
     1.6  
     1.7 -    <para id="x_3ac">Ecco uno scenario comune: avete bisogno di installare un pacchetto software dai sorgenti, ma trovate un bug che dovete correggere nei sorgenti prima di poter cominciare a usare il pacchetto. Fate le vostre modifiche, vi dimenticate del pacchetto per un po' e alcuni mesi dopo avete bisogno di aggiornare il pacchetto a una nuova versione. Se la versione più nuova del pacchetto ha ancora il bug, dovete estrarre la vostra correzione dal vecchio albero dei sorgenti e applicarla alla nuova versione. Questa è un'attività seccante ed è facile commettere errori.</para>
     1.8 -
     1.9 -    <para id="x_3ad">Questo è un semplice caso del problema di <quote>gestione delle patch</quote>. Avete un albero di sorgenti <quote>a monte</quote> che non potete cambiare; avete bisogno di fare alcune modifiche locali all'albero a monte; e vi piacerebbe essere in grado di mantenere separate quelle modifiche, in modo da poterle applicare a nuove versioni della sorgente a monte.</para>
    1.10 -
    1.11 -    <para id="x_3ae">Il problema di gestione delle patch si presenta in molte situazioni. Probabilmente la più visibile è quella in cui un utente di un progetto software open source contribuisce la correzione di un bug o una nuova funzione ai manutentori del progetto sotto forma di patch.</para>
    1.12 -
    1.13 -    <para id="x_3af">I distributori di sistemi operativi che includono software open source hanno spesso bisogno di effettuare modifiche ai pacchetti che distribuiscono in modo da assemblarli correttamente nei propri ambienti.</para>
    1.14 -
    1.15 -    <para id="x_3b0">Quando avete alcune modifiche da mantenere, è facile gestire una singola patch usando i programmi standard <command>diff</command> e <command>patch</command> (si veda la <xref linkend="sec:mq:patch"/> per una discussione di questi strumenti). Una volta che il numero di modifiche cresce, comincia ad avere senso l'idea di mantenere le patch come <quote>frammenti di lavoro</quote> distinti, in modo che per esempio una singola patch conterrà solo una correzione di bug (la patch potrebbe modificare diversi file, ma sta facendo <quote>solo una cosa</quote>) e potreste avere un certo numero di queste patch per bug differenti che dovete correggere e modifiche locali di cui avete bisogno. In questa situazione, se sottoponete una patch per la correzione di un bug ai manutentori del pacchetto a monte e questi includono la vostra correzione in una release successiva, potete semplicemente scartare quella singola patch quando state aggiornando a una nuova release.</para>
    1.16 -
    1.17 -    <para id="x_3b1">Mantenere una singola patch per un albero a monte è un compito un po' fastidioso e soggetto a errori, ma non è difficile. Tuttavia, la complessità del problema cresce rapidamente man mano che il numero di patch che dovete mantenere aumenta. Con più di un piccolo numero di patch in mano, cpaire quali dovete applicare e mantenerle passa da confuso a opprimente.</para>
    1.18 -
    1.19 -    <para id="x_3b2">Fortunatamente, Mercurial include una potente estensione, chiamata Mercurial Queues (letteralmente, Code di Mercurial) o semplicemente <quote>MQ</quote>, che semplifica grandemente il problema di gestione delle patch.</para>
    1.20 +    <para id="x_3ac">Ecco uno scenario comune: avete bisogno di installare un pacchetto software dai sorgenti, ma trovate un bug che dovete correggere nei sorgenti prima di poter cominciare a usare il pacchetto. Fate le vostre modifiche, vi dimenticate del pacchetto per un po' e alcuni mesi dopo avete bisogno di aggiornare il pacchetto a una nuova versione. Se la versione più nuova del pacchetto contiene ancora il bug, dovete estrarre la vostra correzione dal vecchio albero dei sorgenti e applicarla alla nuova versione. Questa è un'attività seccante durante la quale è facile commettere errori.</para>
    1.21 +
    1.22 +    <para id="x_3ad">Questo è un semplice caso del problema di <quote>gestione delle patch</quote>. Avete un albero di sorgenti <quote>a monte</quote> che non potete cambiare, avete bisogno di fare alcune modifiche locali all'albero a monte e vi piacerebbe essere in grado di mantenere separate quelle modifiche, in modo da poterle applicare a nuove versioni dei sorgenti a monte.</para>
    1.23 +
    1.24 +    <para id="x_3ae">Il problema di gestione delle patch si presenta in molte situazioni. Probabilmente la più visibile è quella in cui un utente di un progetto software open source fornisce la correzione di un bug o una nuova funzione sotto forma di patch ai manutentori del progetto.</para>
    1.25 +
    1.26 +    <para id="x_3af">Chi distribuisce sistemi operativi che includono software open source ha spesso bisogno di effettuare modifiche ai pacchetti che distribuisce in modo da assemblarli correttamente nel proprio ambiente.</para>
    1.27 +
    1.28 +    <para id="x_3b0">Quando dovete mantenere solo alcune modifiche da mantenere, potete facilmente gestire una singola patch usando i programmi standard <command>diff</command> e <command>patch</command> (si veda la <xref linkend="sec:mq:patch"/> per una discussione di questi strumenti). Una volta che il numero di modifiche cresce, comincia ad avere senso l'idea di mantenere le patch come <quote>frammenti di lavoro</quote> distinti in modo che, per esempio, una singola patch contenga solo una correzione di bug (la patch potrebbe modificare diversi file, ma sta facendo <quote>solo una cosa</quote>) e un certo numero di queste patch sia destinato a bug differenti che dovete correggere e a modifiche locali di cui avete bisogno. In questa situazione, se sottoponete una patch per la correzione di un bug ai manutentori del pacchetto a monte e questi includono la vostra correzione in una release successiva, potete semplicemente scartare quella singola patch quando state aggiornando il pacchetto a una nuova release.</para>
    1.29 +
    1.30 +    <para id="x_3b1">Mantenere una singola patch per un albero a monte è un'attività un po' noiosa e soggetta a errori, ma non è difficile. Tuttavia, la complessità del problema cresce rapidamente man mano che il numero di patch che dovete mantenere aumenta. Con più di un piccolo numero di patch in mano, il compito di capire quali sono quelle che dovete applicare e di mantenerle passa da sgradevole a opprimente.</para>
    1.31 +
    1.32 +    <para id="x_3b2">Fortunatamente, Mercurial include una potente estensione, chiamata Mercurial Queues (letteralmente, Code di Mercurial) o semplicemente <quote>MQ</quote>, che semplifica notevolmente il problema di gestione delle patch.</para>
    1.33  
    1.34    </sect1>
    1.35    <sect1 id="sec:mq:history">
    1.36      <title>La preistoria di Mercurial Queues</title>
    1.37  
    1.38 -    <para id="x_3b3">Verso la fine degli anni '90, diversi sviluppatori del kernel di Linux cominciarono a mantenere alcune <quote>serie di patch</quote> che modificavano il comportamento del kernel di Linux. Alcune di queste serie si concentravano sulla stabilità, alcune sulla copertura di funzionalità e altre erano più sperimentali.</para>
    1.39 -
    1.40 -    <para id="x_3b4">La dimensinoe di queste serie di patch crebbe rapidamente. Nel 2002, Andrew Morton pubblicò alcuni script di shell che aveva usato per automatizzare la gestione delle proprie code di patch. Andrew era riuscito a usare questi script per gestire centinaia (talvolta migliaia) di patch per il kernel di Linux.</para>
    1.41 +    <para id="x_3b3">Verso la fine degli anni '90, diversi sviluppatori del kernel di Linux cominciarono a mantenere alcune <quote>serie di patch</quote> che modificavano il comportamento del kernel. Alcune di queste serie si concentravano sulla stabilità, alcune sull'inclusione di funzionalità e altre erano più sperimentali.</para>
    1.42 +
    1.43 +    <para id="x_3b4">La dimensione di queste serie di patch crebbe rapidamente. Nel 2002, Andrew Morton pubblicò alcuni script di shell che aveva usato per automatizzare la gestione delle proprie code di patch. Andrew era riuscito a usare questi script per gestire centinaia (talvolta migliaia) di patch per il kernel di Linux.</para>
    1.44  
    1.45      <sect2 id="sec:mq:quilt">
    1.46 -      <title>Una coperta a scacchi</title>
    1.47 -
    1.48 -      <para id="x_3b5">All'inizio del 2003, Andreas Gruenbacher and Martin Quinson presero in prestito l'approccio degli script di Andrew e pubblicarono uno strumento chiamato <quote>patchwork quilt</quote> (letteralmente, coperta a scacchi) <citation>web:quilt</citation>, o semplicemente <quote>quilt</quote> (si veda <citation>gruenbacher:2005</citation> 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.</para>
    1.49 -
    1.50 -      <para id="x_3b6">Quilt gestisce una <emphasis>pila di patch</emphasis> per un albero di directory. Per cominciare, dovete dire a quilt di gestire un albero di directory e quali file volete che gestisca; esso memorizza 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 <quote>aggiornate</quote> la patch.</para>
    1.51 -
    1.52 -      <para id="x_3b7">L'operazione di aggiornamento induce quilt a esaminare l'albero di directory; aggiorna la patch con tutte le modifiche che avete fatto. Potete creare un'altra patch in aggiunta alla prima, che terrà traccia dei cambiamenti richiesti per modificare l'albero da <quote>albero con una patch applicata</quote> ad <quote>albero con due patch applicate</quote>.</para>
    1.53 -
    1.54 -      <para id="x_3b8">Potete <emphasis>cambiare</emphasis> quali patch sono applicate all'albero. Se <quote>estraete</quote> una patch, i cambiamenti effettuati da quella patch spariranno dall'albero di directory. Quilt si ricorda quali patch avete estratto, comunque, così potete <quote>inserire</quote> nuovamente una patch estratta e l'albero di directory verrà ripristinato per contenere le modifiche in quella patch. La cosa più importante è che potete eseguire il comando di <quote>aggiornamento</quote> in ogni momento, e la patch applicata più recentemente verrà aggiornata. Questo significa che, in ogni momento, potete cambiare sia quali patch sono applicate sia quali modifiche vengono effettuate da quelle patch.</para>
    1.55 -
    1.56 -      <para id="x_3b9">Quilt non sa nulla di strumenti di controllo di revisione, così funziona altrettanto bene con un archivio estratto che con una copia di lavoro di Subversion.</para>
    1.57 +      <title>Una <quote>coperta a scacchi</quote></title>
    1.58 +
    1.59 +      <para id="x_3b5">All'inizio del 2003, Andreas Gruenbacher e Martin Quinson presero in prestito l'approccio degli script di Andrew e pubblicarono uno strumento chiamato <quote>patchwork quilt</quote> (letteralmente, coperta a scacchi) <citation>web:quilt</citation>, o semplicemente <quote>quilt</quote> (si veda <citation>gruenbacher:2005</citation> 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.</para>
    1.60 +
    1.61 +      <para id="x_3b6">Quilt gestisce una <emphasis>pila di patch</emphasis> 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 <quote>aggiornate</quote> la patch.</para>
    1.62 +
    1.63 +      <para id="x_3b7">L'operazione di aggiornamento induce quilt a esaminare l'albero di directory completando la patch con tutte le modifiche che avete fatto. Potete creare un'altra patch in aggiunta alla prima, che terrà traccia dei cambiamenti richiesti per modificare l'albero da <quote>albero con una patch applicata</quote> ad <quote>albero con due patch applicate</quote>.</para>
    1.64 +
    1.65 +      <para id="x_3b8">Potete <emphasis>scegliere</emphasis> quali sono le patch da applicare all'albero. Se <quote>estraete</quote> una patch, i cambiamenti effettuati da quella patch spariranno dall'albero di directory. Quilt si ricorda quali patch avete estratto, comunque, così potete <quote>inserire</quote> 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 <quote>aggiornamento</quote> 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.</para>
    1.66 +
    1.67 +      <para id="x_3b9">Quilt non ha nulla a che vedere 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.</para>
    1.68      </sect2>
    1.69  
    1.70      <sect2 id="sec:mq:quilt-mq">
    1.71        <title>Da patchwork quilt a Mercurial Queues</title>
    1.72  
    1.73 -      <para id="x_3ba">A metà del 2005, Chris Mason prese le funzionalità di quilt e implementò un'estensione che chiamò Mercurial Queues, che aggiungeva a Mercurial un comportamento simile a quello di quilt.</para>
    1.74 -
    1.75 -      <para id="x_3bb">La differenza chiave tra quilt e MQ è che quilt non sa nulla di sistemi di controllo di revisione, mentre MQ è <emphasis>integrata</emphasis> in Mercurial. Ogni patch che inserite è rappresentata sotto forma di changeset Mercurial. Estraete una patch, e il changeset sparisce.</para>
    1.76 +      <para id="x_3ba">A metà del 2005, Chris Mason prese le funzionalità di quilt e implementò un'estensione chiamata Mercurial Queues, che aggiungeva a Mercurial un comportamento simile a quello di quilt.</para>
    1.77 +
    1.78 +      <para id="x_3bb">La differenza chiave tra quilt e MQ è che quilt non è progettato per interagire con alcun sistema di controllo di revisione, mentre MQ è <emphasis>integrata</emphasis> in Mercurial. Ogni patch che inserite è rappresentata sotto forma di changeset Mercurial. Se estraete una patch, il changeset relativo sparisce.</para>
    1.79  
    1.80        <para id="x_3bc">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.</para>
    1.81  
    1.82 @@ -55,43 +55,43 @@
    1.83    <sect1>
    1.84      <title>L'enorme vantaggio di MQ</title>
    1.85  
    1.86 -    <para id="x_3bd">Non posso esagerare il valore che MQ offre attraverso l'unificazione di patch e controllo di revisione.</para>
    1.87 -
    1.88 -    <para id="x_3be">Una delle ragioni principali per cui le patch hanno continuato a venire usate nel mondo del software libero e open source&emdash;nonostante la disponibilità di strumenti di controllo di revisione sempre più capaci attraverso gli anni&emdash; è l'<emphasis>agilità</emphasis> che offrono.</para>
    1.89 -
    1.90 -    <para id="x_3bf">I tradizionali strumenti di controllo di revisione effettuano una registrazione permanente di ogni cosa che fate. Mentre questo ha un grande valore, è anche piuttosto soffocante. Se volete effettuare un esperimento allucinato, dovete stare molto attenti a come procedete, o rischiate di lasciare tracce inutili&emdash;o peggio, ingannevoli e destabilizzanti&emdash; dei vostri #missteps# e dei vostri errori nella registrazione permanente delle revisioni.</para>
    1.91 -
    1.92 -    <para id="x_3c0">Al contrario, il matrimonio tra controllo di revisione distribuito e patch realizzato da MQ rende molto più facile isolare il vostro lavoro. Le vostre patch si basano sulla normale cronologia delle revisioni e potete farle sparire e comparire a piacere. Se non vi piace una patch, potete scartarla. Se una patch non è esattamente come volete che sia, vi basta correggerla&emdash;tutte le volte che ne avete bisogno, fino a quando non l'avete affinata nella forma che desiderate.</para>
    1.93 -
    1.94 -    <para id="x_3c1">Per esempio, l'integrazione delle patch con il controllo di revisione rende la comprensione delle patch&emdash;e delle interazioni con il codice su cui si basano&emdash;e la correzione dei loro effetti <emphasis>enormemente</emphasis> più facile. Dato che ogni patch applicata ha un changeset associato, potete invocare <command role="hg-cmd">hg log</command> con un nome di file per vedere quali changeset e quali patch hanno avuto effetto sul file. Potete usare il comando <command role="hg-cmd">hg bisect</command> per condurre una ricerca binaria attraverso tutti i changeset e le patch applicate per vedere dove un bug è stato introdotto o corretto. Potete usare il comando <command role="hg-cmd">hg annotate</command> per vedere quali changeset o patch hanno modificato una particolare riga di un file sorgente. E così via.</para>
    1.95 +    <para id="x_3bd">Non posso esagerare il valore dell'unificazione tra patch e controllo di revisione offerta da MQ.</para>
    1.96 +
    1.97 +    <para id="x_3be">Una delle ragioni principali per cui le patch sono ancora continuamente usate nel mondo del software libero e open source&emdash;nonostante la disponibilità di strumenti di controllo di revisione sempre più sofisticati&emdash;è l'<emphasis>agilità</emphasis> che offrono.</para>
    1.98 +
    1.99 +    <para id="x_3bf">I tradizionali strumenti di controllo di revisione effettuano una registrazione permanente di ogni vostra azione. Da un lato questo ha un grande valore, ma dall'altro è anche piuttosto soffocante. Se volete effettuare un esperimento stravagante, dovete stare molto attenti a come procedete, o rischiate di lasciare tracce inutili&emdash;o peggio, ingannevoli e destabilizzanti&emdash;dei vostri passi falsi e dei vostri errori nella registrazione permanente delle revisioni.</para>
   1.100 +
   1.101 +    <para id="x_3c0">Al contrario, il matrimonio tra controllo di revisione distribuito e patch realizzato da MQ rende molto più facile isolare il vostro lavoro. Le vostre patch si basano sulla normale cronologia delle revisioni e potete farle sparire e comparire a piacere. Se non vi piace una patch, potete scartarla. Se una patch non è esattamente come volete che sia, vi basta correggerla&emdash;tutte le volte che ne avete bisogno, fino a quando non l'avete ritoccata facendole assumere la forma che desiderate.</para>
   1.102 +
   1.103 +    <para id="x_3c1">Per esempio, l'integrazione delle patch con il controllo di revisione facilita <emphasis>enormemente</emphasis> la comprensione delle patch e delle interazioni con il codice su cui si basano, nonché la correzione dei loro effetti. Dato che ogni patch applicata è associata a un changeset, potete invocare <command role="hg-cmd">hg log</command> con un nome di file per vedere quali changeset e quali patch hanno avuto effetto sul file. Potete usare il comando <command role="hg-cmd">hg bisect</command> per condurre una ricerca binaria attraverso tutti i changeset e le patch applicate in modo da scoprire dov'è è stato introdotto o corretto un bug. Potete usare il comando <command role="hg-cmd">hg annotate</command> per vedere quali changeset o patch hanno modificato una particolare riga di un file sorgente. E così via.</para>
   1.104    </sect1>
   1.105  
   1.106    <sect1 id="sec:mq:patch">
   1.107      <title>Capire le patch</title>
   1.108  
   1.109 -    <para id="x_3c2">Dato che MQ non nasconde la sua natura orientata alle patch, è utile capire cosa sono le patch e conoscere un po' gli strumenti che lavorano con esse.</para>
   1.110 +    <para id="x_3c2">Dato che MQ non nasconde la sua natura orientata alle patch, vi potrà essere d'aiuto capire cosa sono le patch e conoscere un po' gli strumenti che lavorano con esse.</para>
   1.111  
   1.112      <para id="x_3c3">Il tradizionale comando Unix <command>diff</command> confronta due file e stampa una lista di differenze tra loro. Il comando <command>patch</command> interpreta queste differenze come <emphasis>modifiche</emphasis> da effettuare a un file. Date un'occhiata qui di seguito per vedere un semplice esempio di questi comandi in azione.</para>
   1.113  
   1.114        &interaction.mq.dodiff.diff;
   1.115  
   1.116 -    <para id="x_3c4">Il tipo di file generato da <command>diff</command> (e che <command>patch</command> prende in ingresso) viene chiamato una <quote>patch</quote> o un <quote>diff</quote>; non c'è alcuna differenza tra una patch e un diff. (Noi useremo il termine <quote>patch</quote>, dato che è quello più comunemente usato.)</para>
   1.117 -
   1.118 -    <para id="x_3c5">Un file di patch può cominciare con testo arbitrario; il comando <command>patch</command> ignora questo testo, ma MQ lo usa come messaggio di commit quando crea i changeset. Per trovare l'inizio del contenuto della patch, <command>patch</command> cerca la prima riga che comincia con la stringa <quote><literal>diff -</literal></quote>.</para>
   1.119 +    <para id="x_3c4">Il tipo di file generato da <command>diff</command> (e che <command>patch</command> prende in ingresso) viene chiamato una <quote>patch</quote> (letteralmente, pezza) o un <quote>diff</quote>. Non c'è alcuna differenza tra una patch e un diff, ma noi useremo il termine <quote>patch</quote>, dato che è quello più comunemente usato.</para>
   1.120 +
   1.121 +    <para id="x_3c5">Un file di patch può cominciare con testo arbitrario che il comando <command>patch</command> ignora, ma che MQ usa come messaggio di commit quando crea i changeset. Per trovare l'inizio del contenuto della patch, il comando <command>patch</command> cerca la prima riga che comincia con la stringa <quote><literal>diff -</literal></quote>.</para>
   1.122  
   1.123      <para id="x_3c6">MQ lavora con i diff in formato <emphasis>unified</emphasis> (<command>patch</command> può accettare molti altri formati di diff, ma MQ no). Un diff in formato unified contiene due tipi di intestazione. L'<emphasis>intestazione di file</emphasis> descrive il file che viene modificato e contiene il nome del file da modificare. Quando <command>patch</command> vede una nuova intestazione di file, cerca il file con quel nome per cominciare a modificarlo.</para>
   1.124  
   1.125 -    <para id="x_3c7">L'intestazione di file è seguita da una serie di <emphasis>blocchi</emphasis>. Ogni blocco comincia con un'intestazione che identifica l'intervallo di numeri di riga nel file che il blocco dovrebbe modificare. Dopo l'intestazione, un blocco comincia e finisce con alcune (di solito tre) righe di testo dal file originale che vengono chiamate il <emphasis>contesto</emphasis> del blocco. Se c'è solo una quantità ridotta di contesto tra blocchi successivi, <command>diff</command> non stampa una nuova intestazione, ma si limita a unire i blocchi insieme, con alcune righe di contesto tra le modifiche.</para>
   1.126 -
   1.127 -    <para id="x_3c8">Ogni riga di contesto comincia con un carattere di spazio. Nell'ambito di un blocco, una riga che comincia con <quote><literal>-</literal></quote> significa <quote>rimuovi questa riga,</quote> mentre una riga che comincia con <quote><literal>+</literal></quote> significa <quote>inserisci questa riga.</quote> Per esempio, una riga modificata viene rappresentata da una cancellazione e un inserimento.</para>
   1.128 -
   1.129 -    <para id="x_3c9">Ritorneremo ad alcuni degli aspetti più sottili delle patch più tardi (nella <xref linkend="sec:mq:adv-patch"/>), ma ora dovreste avere abbastanza informazioni per usare MQ.</para>
   1.130 +    <para id="x_3c7">L'intestazione di file è seguita da una serie di <emphasis>blocchi</emphasis>. Ogni blocco comincia con un'intestazione che identifica l'intervallo di numeri di riga del file che il blocco dovrebbe modificare. Dopo l'intestazione, un blocco comincia e finisce con alcune (di solito tre) righe di testo proveniente dal file originale che vengono chiamate il <emphasis>contesto</emphasis> del blocco. Se c'è solo una quantità ridotta di contesto tra blocchi successivi, <command>diff</command> non stampa una nuova intestazione, ma si limita a unire insieme i blocchi inserendo alcune righe di contesto tra le modifiche.</para>
   1.131 +
   1.132 +    <para id="x_3c8">Ogni riga di contesto comincia con un carattere di spazio. Nell'ambito di un blocco, una riga che comincia con <quote><literal>-</literal></quote> significa <quote>rimuovi questa riga,</quote> mentre una riga che comincia con <quote><literal>+</literal></quote> significa <quote>inserisci questa riga.</quote> Per esempio, una riga modificata viene rappresentata da una cancellazione e da un inserimento.</para>
   1.133 +
   1.134 +    <para id="x_3c9">Ritorneremo su alcuni degli aspetti più sottili delle patch più avanti (nella <xref linkend="sec:mq:adv-patch"/>), ma ora dovreste avere abbastanza informazioni per usare MQ.</para>
   1.135    </sect1>
   1.136  
   1.137    <sect1 id="sec:mq:start">
   1.138      <title>Cominciare a usare Mercurial Queues</title>
   1.139  
   1.140 -    <para id="x_3ca">Dato che MQ è implementata come un'estensione, dovete esplicitamente abilitarla prima di poterla suare. (Non avete bisogno di scaricare nulla, perché MQ è inclusa con la distribuzione standard di Mercurial.) Per abilitare MQ, modificate il vostro file <filename role="home">~/.hgrc</filename> aggiungendo le seguenti righe.</para>
   1.141 +    <para id="x_3ca">Dato che MQ è implementata come un'estensione, dovete esplicitamente abilitarla prima di poterla usare. (Non avete bisogno di scaricare nulla, perché MQ è inclusa con la distribuzione standard di Mercurial.) Per abilitare MQ, modificate il vostro file <filename role="home">~/.hgrc</filename> aggiungendo le seguenti righe.</para>
   1.142  
   1.143      <programlisting>[extensions]
   1.144  hgext.mq =</programlisting>
   1.145 @@ -100,7 +100,7 @@
   1.146  
   1.147      &interaction.mq.qinit-help.help;
   1.148  
   1.149 -    <para id="x_3cc">Potete usare MQ con <emphasis>qualsiasi</emphasis> repository Mercurial, e i suoi comandi operano solo all'interno di quel repository. Per cominciare, preparate semplicemente il repository usando il comando <command role="hg-ext-mq">qinit</command> command.</para>
   1.150 +    <para id="x_3cc">MQ può essere usata con <emphasis>qualsiasi</emphasis> repository Mercurial e i suoi comandi operano solo all'interno di quel repository. Per cominciare, preparate semplicemente il repository usando il comando <command role="hg-ext-mq">qinit</command>.</para>
   1.151  
   1.152      &interaction.mq.tutorial.qinit;
   1.153  
   1.154 @@ -109,16 +109,16 @@
   1.155      <sect2>
   1.156        <title>Creare una nuova patch</title>
   1.157  
   1.158 -      <para id="x_3ce">Per cominciare a lavorare su una nuova patch, usate il comando <command role="hg-ext-mq">qnew</command>. Questo comando prende un argomento, il nome della patch da creare.</para>
   1.159 -
   1.160 -      <para id="x_3cf">MQ userà questo nome come il nome di un file che memorizzerà nella directory <filename role="special" class="directory">.hg/patches</filename>, come potete vedere qui sotto.</para>
   1.161 +      <para id="x_3ce">Per cominciare a lavorare su una nuova patch, usate il comando <command role="hg-ext-mq">qnew</command>. Questo comando prende come argomento il nome della patch da creare.</para>
   1.162 +
   1.163 +      <para id="x_3cf">MQ userà questo nome per memorizzare un file nella directory <filename role="special" class="directory">.hg/patches</filename>, come potete vedere qui sotto.</para>
   1.164  
   1.165        &interaction.mq.tutorial.qnew;
   1.166  
   1.167 -      <para id="x_3d0">La directory <filename role="special" class="directory">.hg/patches</filename> contiene anche altri due nuovi file, <filename role="special">series</filename> e <filename role="special">status</filename>.  Il file <filename role="special">series</filename> elenca tutte le patch che MQ conosce per questo repository, con una patch per riga. Mercurial usa il file <filename role="special">status</filename> per tenere traccia internamente di tutte le patch che MQ ha <emphasis>applicato</emphasis> a questo repository.</para>
   1.168 +      <para id="x_3d0">La directory <filename role="special" class="directory">.hg/patches</filename> contiene anche altri due nuovi file, <filename role="special">series</filename> e <filename role="special">status</filename>.  Il file <filename role="special">series</filename> elenca tutte le patch per questo repository di cui MQ è a conoscenza, con una patch per riga. Mercurial usa il file <filename role="special">status</filename> per tenere traccia internamente di tutte le patch che MQ ha <emphasis>applicato</emphasis> a questo repository.</para>
   1.169  
   1.170        <note>
   1.171 -	<para id="x_3d1">Talvolta, potreste voler modificare il file <filename role="special">series</filename> a mano, per esempio per cambiare la sequenza in cui sono applicate alcune patch. Tuttavia, modificare manualmente il file <filename role="special">status</filename> è quasi sempre una cattiva idea, dato che è facile rovinare l'idea di MQ di quello che sta succedendo.</para>
   1.172 +	<para id="x_3d1">A volte potreste voler modificare il file <filename role="special">series</filename> a mano, per esempio per cambiare la sequenza in cui sono applicate alcune patch. Tuttavia, modificare manualmente il file <filename role="special">status</filename> è quasi sempre una cattiva idea, dato che così facendo si rischia facilmente di disorientare MQ.</para>
   1.173        </note>
   1.174  
   1.175        <para id="x_3d2">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 <command role="hg-cmd">hg diff</command> e <command role="hg-cmd">hg annotate</command>, funzionano allo stesso modo in cui funzionavano prima.</para>
   1.176 @@ -133,7 +133,7 @@
   1.177  
   1.178        <para id="x_3d4">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.</para>
   1.179  
   1.180 -      <para id="x_3d5">Potete eseguire <command role="hg-ext-mq">qrefresh</command> tutte le volte che volete, quindi è un buon modo per <quote>controllare</quote> il vostro lavoro. Aggiornate la vostra patch al momento opportuno, tentate un esperimento e se l'esperimento non funziona usate <command role="hg-cmd">hg revert</command> per ripristinare le vostre modifiche all'ultimo aggiornamento che avete compiuto.</para>
   1.181 +      <para id="x_3d5">Potete invocare <command role="hg-ext-mq">qrefresh</command> tutte le volte che volete, quindi questo comando rappresenta un buon modo per <quote>controllare</quote> il vostro lavoro. Aggiornate la vostra patch al momento opportuno, tentate un esperimento e se l'esperimento non funziona usate <command role="hg-cmd">hg revert</command> per ripristinare le vostre modifiche all'ultimo aggiornamento che avete compiuto.</para>
   1.182  
   1.183        &interaction.mq.tutorial.qrefresh2;
   1.184      </sect2>
   1.185 @@ -145,16 +145,16 @@
   1.186  
   1.187        &interaction.mq.tutorial.qnew2;
   1.188  
   1.189 -      <para id="x_3d7">Notate che la patch contiene le modifiche nella nostra patch precedente come parte del proprio contesto (potete vederlo più chiaramente nell'output di <command role="hg-cmd">hg annotate</command>).</para>
   1.190 +      <para id="x_3d7">Notate che la patch contiene le modifiche nella nostra patch precedente come parte del proprio contesto (potete vederlo più chiaramente nel risultato di <command role="hg-cmd">hg annotate</command>).</para>
   1.191  
   1.192        <para id="x_3d8">Finora, con l'eccezione di <command role="hg-ext-mq">qnew</command> e <command role="hg-ext-mq">qrefresh</command>, 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.</para>
   1.193  
   1.194        &interaction.mq.tutorial.qseries;
   1.195  
   1.196        <itemizedlist>
   1.197 -	<listitem><para id="x_3d9">Il comando <command role="hg-ext-mq">qseries</command> elenca tutte le patch per questo repository note a MQ, dalla più vecchia alla più recente (più recentemente <emphasis>creata</emphasis>).</para>
   1.198 -	</listitem>
   1.199 -	<listitem><para id="x_3da">Il comando <command role="hg-ext-mq">qapplied</command> elenca tutte le patch che MQ ha <emphasis>applicato</emphasis> a questo repository, ancora dalla più vecchia alla più recente (più recentemente applicata).</para>
   1.200 +	<listitem><para id="x_3d9">Il comando <command role="hg-ext-mq">qseries</command> elenca tutte le patch per questo repository di cui MQ è a conoscenza, dalla più vecchia alla più recente (più recentemente <emphasis>creata</emphasis>).</para>
   1.201 +	</listitem>
   1.202 +	<listitem><para id="x_3da">Il comando <command role="hg-ext-mq">qapplied</command> elenca tutte le patch che MQ ha <emphasis>applicato</emphasis> a questo repository, sempre dalla più vecchia alla più recente (più recentemente applicata).</para>
   1.203  	</listitem></itemizedlist>
   1.204      </sect2>
   1.205  
   1.206 @@ -163,7 +163,7 @@
   1.207  
   1.208        <para id="x_3db">La discussione precedente implica che ci deve essere una differenza tra patch <quote>note</quote> e patch <quote>applicate</quote>, e in effetti c'è. MQ può gestire una patch senza che sia applicata al repository.</para>
   1.209  
   1.210 -      <para id="x_3dc">Una patch <emphasis>applicata</emphasis> 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 <command role="hg-ext-mq">qpop</command>. La patch estratta è ancora <emphasis>nota</emphasis>, o 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 <xref linkend="fig:mq:stack"/> illustra la differenza tra patch applicate e registrate.</para>
   1.211 +      <para id="x_3dc">Una patch <emphasis>applicata</emphasis> 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 <command role="hg-ext-mq">qpop</command>. La patch estratta è ancora <emphasis>nota</emphasis>, 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 <xref linkend="fig:mq:stack"/> illustra la differenza tra patch applicate e registrate.</para>
   1.212  
   1.213        <figure id="fig:mq:stack">
   1.214  	<title>Patch applicate e non applicate nella pila delle patch di MQ</title>
   1.215 @@ -173,74 +173,73 @@
   1.216  	</mediaobject>
   1.217        </figure>
   1.218  
   1.219 -      <para id="x_3de">Potete riapplicare una patch non applicata o estratta usando il comando <command role="hg-ext-mq">qpush</command>. Questo crea un nuovo changeset da far corrispondere alla patch, e le modifiche della patch diventano ancora una volta presenti nella directory di lavoro. Di seguito, vengono mostrati esempi di <command role="hg-ext-mq">qpop</command> e <command role="hg-ext-mq">qpush</command> in azione.</para>
   1.220 +      <para id="x_3de">Potete riapplicare una patch non applicata o estratta usando il comando <command role="hg-ext-mq">qpush</command>. Questo comando crea un nuovo changeset da far corrispondere alla patch, e le modifiche della patch diventano ancora una volta presenti nella directory di lavoro. Di seguito, vengono mostrati esempi di <command role="hg-ext-mq">qpop</command> e <command role="hg-ext-mq">qpush</command> in azione.</para>
   1.221  
   1.222        &interaction.mq.tutorial.qpop;
   1.223  
   1.224 -      <para id="x_3df">Notate che una volta che abbiamo estratto una patch o due patch, l'output di <command role="hg-ext-mq">qseries</command> rimane lo stesso, mentre quello di <command role="hg-ext-mq">qapplied</command> è cambiato.</para>
   1.225 +      <para id="x_3df">Notate che, dopo aver estratto una patch o due patch, il risultato di <command role="hg-ext-mq">qseries</command> rimane lo stesso, mentre quello di <command role="hg-ext-mq">qapplied</command> è cambiato.</para>
   1.226  
   1.227      </sect2>
   1.228  
   1.229      <sect2>
   1.230        <title>Inserire ed estrarre molte patch</title>
   1.231  
   1.232 -      <para id="x_3e0">Mentre ognuno dei comandi <command role="hg-ext-mq">qpush</command> e <command role="hg-ext-mq">qpop</command> opera in maniera predefinita su una singola patch alla volta, potete inserire ed estrarre molte patch in un unico passaggio. L'opzione <option role="hg-ext-mq-cmd-qpush-opt">hg -a</option> di <command role="hg-ext-mq">qpush</command> lo induce a inserire tutte le patch non applicate, mentre l'opzione <option role="hg-ext-mq-cmd-qpop-opt">-a</option> di <command role="hg-ext-mq">qpop</command> lo induce a estrarre tutte le patch applicate. (Per ulteriori modi di inserire ed estrarre molte patch, si veda la <xref linkend="sec:mq:perf"/> più avanti.)</para>
   1.233 +      <para id="x_3e0">Sebbene i comandi <command role="hg-ext-mq">qpush</command> e <command role="hg-ext-mq">qpop</command> operino in maniera predefinita su una singola patch alla volta, potete inserire ed estrarre molte patch in un unico passaggio. L'opzione <option role="hg-ext-mq-cmd-qpush-opt">-a</option> di <command role="hg-ext-mq">qpush</command> lo induce a inserire tutte le patch non applicate, mentre l'opzione <option role="hg-ext-mq-cmd-qpop-opt">-a</option> di <command role="hg-ext-mq">qpop</command> lo induce a estrarre tutte le patch applicate. (Per ulteriori modi di inserire ed estrarre molte patch, si veda la <xref linkend="sec:mq:perf"/> più avanti.)</para>
   1.234  
   1.235        &interaction.mq.tutorial.qpush-a;
   1.236      </sect2>
   1.237  
   1.238      <sect2>
   1.239 -      <title>I controlli di sicurezza, e come #overriding them#</title>
   1.240 -
   1.241 -      <para id="x_3e1">Diversi comandi MQ controllano la directory di lavoro prima di fare qualunque cosa e falliscono se trovano una qualsiasi modifica. Si comportano in questo modo per assicurarsi che non perdiate alcun cambiamento che avete fatto ma che non avete ancora incorporato in una patch. L'esempio seguente illustra questo caso: il comando <command role="hg-ext-mq">qnew</command> eviterà di creare una nuova patch se ci sono cambiamenti in sospeso, causati in questo caso dall'invocazione di <command role="hg-cmd">hg add</command> su <filename>file3</filename>.</para>
   1.242 +      <title>I controlli di sicurezza e come aggirarli</title>
   1.243 +
   1.244 +      <para id="x_3e1">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 <command role="hg-ext-mq">qnew</command> eviterà di creare una nuova patch se ci sono cambiamenti in sospeso, causati in questo caso dall'invocazione di <command role="hg-cmd">hg add</command> su <filename>file3</filename>.</para>
   1.245  
   1.246        &interaction.mq.tutorial.add;
   1.247  
   1.248 -      <para id="x_3e2">Tutti i comandi che controllano la directory di lavoro accettano un'opzione <quote>so cosa sto facendo</quote> che si chiama sempre <option>-f</option>. L'esatto significato di <option>-f</option> dipende dal comando. Per esempio, <command role="hg-cmd">hg qnew <option role="hg-ext-mq-cmd-qnew-opt">hg -f</option></command> incorporerà i cambiamenti in sospeso nella nuova patch creata, ma <command role="hg-cmd">hg qpop <option role="hg-ext-mq-cmd-qpop-opt">hg -f</option></command> annullerà le modifiche a qualsiasi file affetto dalla patch che sta estraendo. Assicuratevi di leggere la documentazione per l'opzione <option>-f</option> di un comando prima di usarla!</para>
   1.249 +      <para id="x_3e2">Tutti i comandi che esaminano la directory di lavoro accettano un'opzione <quote>so cosa sto facendo</quote> che si chiama sempre <option>-f</option>. L'esatto significato di <option>-f</option> dipende dal comando. Per esempio, <command role="hg-cmd">hg qnew <option role="hg-ext-mq-cmd-qnew-opt">-f</option></command> incorporerà i cambiamenti in sospeso nella nuova patch creata, ma <command role="hg-cmd">hg qpop <option role="hg-ext-mq-cmd-qpop-opt">-f</option></command> annullerà le modifiche a qualsiasi file affetto dalla patch che sta estraendo. Assicuratevi di leggere la documentazione per l'opzione <option>-f</option> di un comando prima di usarla!</para>
   1.250      </sect2>
   1.251  
   1.252      <sect2>
   1.253        <title>Lavorare su diverse patch alla volta</title>
   1.254  
   1.255 -      <para id="x_3e3">Il comando <command role="hg-ext-mq">qrefresh</command> aggiorna sempre la patch applicata <emphasis>in cima alla pila</emphasis>. Questo significa che potete sospendere il lavoro su una patch (aggiornandola), estrarre o inserire per posizionare una patch differente in cima alla pila e lavorare su <emphasis>quella</emphasis> patch per un po'.</para>
   1.256 -
   1.257 -      <para id="x_3e4">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&emdash;basata sulla prima&emdash;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, è facile correggere il nucleo. Vi basta usare <command role="hg-ext-mq">qrefresh</command> per salvare le modifiche in corso alla vostra patch di interfaccia ed estrarre tramite <command role="hg-ext-mq">qpop</command> la patch del nucleo. Correggete il bug nel nucleo, aggiornate la patch del nucleo con <command role="hg-ext-mq">qrefresh</command> e inserite la patch di interfaccia tramite <command role="hg-ext-mq">qpush</command> per continuare a lavorare dal punto dove avevate lasciato.</para>
   1.258 +      <para id="x_3e3">Il comando <command role="hg-ext-mq">qrefresh</command> aggiorna sempre la patch applicata <emphasis>più recentemente</emphasis>. 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 <emphasis>quella</emphasis> patch per un po'.</para>
   1.259 +
   1.260 +      <para id="x_3e4">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&emdash;basata sulla prima&emdash;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 <command role="hg-ext-mq">qrefresh</command>, in modo da salvare le modifiche in corso alla vostra patch di interfaccia, e poi usare <command role="hg-ext-mq">qpop</command> per estrarre la patch del nucleo. Correggete il bug nel nucleo, aggiornate la patch del nucleo con <command role="hg-ext-mq">qrefresh</command> e inserite la patch di interfaccia tramite <command role="hg-ext-mq">qpush</command> per continuare a lavorare dal punto dove avevate lasciato.</para>
   1.261      </sect2>
   1.262    </sect1>
   1.263  
   1.264    <sect1 id="sec:mq:adv-patch">
   1.265      <title>Ulteriori informazioni sulle patch</title>
   1.266  
   1.267 -    <para id="x_3e5">MQ usa il comando GNU <command>patch</command> per applicare le patch, quindi è utile conoscere qualche altro aspetto dettagliato sul funzionamento di <command>patch</command> e sulle patch stesse.</para>
   1.268 -
   1.269 -    <sect2>
   1.270 -      <title>#The strip count#</title>
   1.271 -
   1.272 -      <para id="x_3e6">Se guardate alle 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 è un rimasuglio del modo in cui le persone erano solite generare le patch (viene ancora fatto in questo modo, ma è piuttosto raro con i moderni strumenti di controllo di revisione).</para>
   1.273 -
   1.274 -      <para id="x_3e7">Alice estrarrebbe un archivio, modificherebbe i file e poi deciderebbe di voler creare una patch. Quindi rinominerebbe della directory di lavoro, estrarrebbe l'archivio nuovamente (da qui nasce il bisogno di modificare il nome) e userebbe le opzioni <option role="cmd-opt-diff">-r</option> e <option role="cmd-opt-diff">-N</option> del comando <command>diff</command> per generare ricorsivamente una patch tra la directory non modificata e quella modificata. Il risultato sarebbe che il nome della directory non modificata si troverebbe all'inizio del percorso sulla parte destra in ogni intestazione di file e il nome della directory modificata si troverebbe all'inizio del percorso sulla parte destra.</para>
   1.275 -
   1.276 -      <para id="x_3e8">Dato che chi riceve la patch dalle Alice della rete probabilmente non avrebbe le due copie, modificata e non, della directory, con esattamente gli stessi nomi, il comando <command>patch</command> ha un'opzione <option role="cmd-opt-patch">-p</option> che indica il numero di elementi iniziali da eliminare dal percorso al momento di applicare una patch. Questo numero viene chiamato <emphasis>#strip count#</emphasis>.</para>
   1.277 -
   1.278 -      <para id="x_3e9">Un'opzione <quote><literal>-p1</literal></quote> significa <quote>usa uno #strip count# di uno</quote>. Se <command>patch</command> vede un nome di file <filename>foo/bar/baz</filename> in un'intestazione di file, eliminerà <filename>foo</filename> e proverà ad applicare la patch al file <filename>bar/baz</filename>. (Strettamente parlando, lo #strip count# si riferisce al numero di <emphasis>separatori di percorso</emphasis> (e dei relativi elementi) da eliminare. Uno #strip count# pari a uno trasformerà <filename>foo/bar</filename> in <filename>bar</filename>, ma <filename>/foo/bar</filename> (notate lo slash iniziale) in <filename>foo/bar</filename>.)</para>
   1.279 -
   1.280 -      <para id="x_3ea">Lo #strip count# <quote>standard</quote> per le patch è pari a uno, in quanto quasi tutte le patch contengono un elemento iniziale da eliminare nel percorso. Il comando <command role="hg-cmd">hg diff</command> di Mercurial genera nomi di percorso in questa forma, e sia il comando <command role="hg-cmd">hg import</command> che MQ si aspettano patch con uno #strip count# pari a uno.</para>
   1.281 -
   1.282 -      <para id="x_3eb">Se qualcuno vi invia una patch che volete aggiungere alla vostra coda delle patch e la patch ha bisogno di uno #strip count# diverso da uno, non potete usare semplicemente <command
   1.283 -	  role="hg-ext-mq">qimport</command> con la patch, perché <command role="hg-ext-mq">qimport</command> non è ancora dotato di un'opzione <literal>-p</literal> (si veda il <ulink role="hg-bug" url="http://www.selenic.com/mercurial/bts/issue311">problema 311</ulink>). L'alternativa migliore che avete è quella di creare una vostra patch con <command role="hg-ext-mq">qnew</command> e poi usare <command>patch -pN</command> per applicare la patch che avete ricevuto, seguito da <command role="hg-cmd">hg addremove</command> per registrare qualsiasi file aggiunto o rimosso dalla patch, seguito da <command role="hg-ext-mq">hg qrefresh</command>. Questa complessità potrebbe diventare inutile; si veda il <ulink role="hg-bug" url="http://www.selenic.com/mercurial/bts/issue311">problema 311</ulink> per i dettagli.
   1.284 +    <para id="x_3e5">MQ usa il comando GNU <command>patch</command> per applicare le patch, quindi vi sarà d'aiuto conoscere qualche altro aspetto di dettaglio sul funzionamento di <command>patch</command> e sulle patch stesse.</para>
   1.285 +
   1.286 +    <sect2>
   1.287 +      <title>Il numero di cancellazioni</title>
   1.288 +
   1.289 +      <para id="x_3e6">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).</para>
   1.290 +
   1.291 +      <para id="x_3e7">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 <option role="cmd-opt-diff">-r</option> e <option role="cmd-opt-diff">-N</option> del comando <command>diff</command> per generare ricorsivamente una patch tra la directory non modificata e quella modificata. Come risultato, sarebbe che il nome della directory non modificata si sarebbe trovato all'inizio del percorso sulla parte sinistra in ogni intestazione di file e il nome della directory modificata si sarebbe trovato all'inizio del percorso sulla parte destra.</para>
   1.292 +
   1.293 +      <para id="x_3e8">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 <command>patch</command> è stato dotato di un'opzione <option role="cmd-opt-patch">-p</option> che indica il numero di elementi iniziali da eliminare dal percorso al momento di applicare una patch. Questo numero viene chiamato il <emphasis>numero di cancellazioni</emphasis>.</para>
   1.294 +
   1.295 +      <para id="x_3e9">Un'opzione <quote><literal>-p1</literal></quote> significa <quote>usa un numero di cancellazioni pari a uno</quote>. Se <command>patch</command> vede un nome di file <filename>foo/bar/baz</filename> in un'intestazione di file, eliminerà <filename>foo</filename> e proverà ad applicare la patch al file <filename>bar/baz</filename>. Strettamente parlando, il numero di cancellazioni si riferisce al numero di <emphasis>separatori di percorso</emphasis> (e dei relativi elementi) da eliminare. Un numero di cancellazioni pari a uno trasformerà <filename>foo/bar</filename> in <filename>bar</filename>, ma <filename>/foo/bar</filename> (notate lo slash iniziale) in <filename>foo/bar</filename>.</para>
   1.296 +
   1.297 +      <para id="x_3ea">Il numero di cancellazioni <quote>standard</quote> per le patch è pari a uno, in quanto quasi tutte le patch contengono un elemento iniziale da eliminare nel percorso. Il comando <command role="hg-cmd">hg diff</command> di Mercurial genera nomi di percorso in questa forma e sia il comando <command role="hg-cmd">hg import</command> che MQ si aspettano patch con un numero di cancellazioni pari a uno.</para>
   1.298 +
   1.299 +      <para id="x_3eb">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 <command role="hg-ext-mq">qimport</command> con la patch, perché <command role="hg-ext-mq">qimport</command> non è ancora dotato di un'opzione <literal>-p</literal> (si veda il <ulink role="hg-bug" url="http://www.selenic.com/mercurial/bts/issue311">problema 311</ulink> per i dettagli). L'alternativa migliore che avete è quella di creare una vostra patch con <command role="hg-ext-mq">qnew</command> e poi usare <command>patch -pN</command> per applicare la patch che avete ricevuto, seguito da <command role="hg-cmd">hg addremove</command> per registrare qualsiasi file aggiunto o rimosso dalla patch, seguito da <command role="hg-ext-mq">hg qrefresh</command>. Questa complessità potrebbe diventare inutile una volta che il <ulink role="hg-bug" url="http://www.selenic.com/mercurial/bts/issue311">problema 311</ulink> venga risolto.
   1.300        </para>
   1.301      </sect2>
   1.302  
   1.303      <sect2>
   1.304        <title>Strategie per applicare una patch</title>
   1.305  
   1.306 -      <para id="x_3ec">Quando <command>patch</command> applica un blocco, prova a impiegare una serie di strategie successive sempre meno accurate per fare in modo di applicare il blocco. Questa tecnica di #falling-back# spesso rende possibile prendere una patch che è stata generata da una vecchia versione di un file e applicarla alla nuova versione di quel file.</para>
   1.307 -
   1.308 -      <para id="x_3ed">Come prima cosa, <command>patch</command> cerca una corrispondenza esatta, dove i numeri di riga, il contesto e il testo da modificare devono applicarsi in maniera esatta. Se non può fare una corrispondenza esatta, cerca una corrispondenza esatta per il contesto, senza onorare le informazioni sulla numerazione delle righe. Se questa strategia ha successo, stampa una riga di output dicendo che il blocco è stato applicato, ma a una certa <emphasis>distanza</emphasis> dal numero di riga originale.</para>
   1.309 +      <para id="x_3ec">Quando <command>patch</command> 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 spesso rende possibile prendere una patch che è stata generata a partire da una vecchia versione di un file e applicarla alla nuova versione di quel file.</para>
   1.310 +
   1.311 +      <para id="x_3ed">Come prima cosa, <command>patch</command> 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 <emphasis>scostamento</emphasis> rispetto al numero di riga originale.</para>
   1.312  
   1.313        <para id="x_3ee">Se la corrispondenza con il solo contesto fallisce, <command>patch</command> rimuove la prima e l'ultima riga del contesto e tenta una corrispondenza con la sola versione <emphasis>ridotta</emphasis> del contesto. Se il blocco con il contesto ridotto ha successo, stampa un messaggio dicendo di aver applicato il blocco con un <emphasis>fattore di incertezza</emphasis> (il numero dopo il fattore di incertezza indica quante righe del contesto sono state escluse da <command>patch</command> prima che la patch si potesse applicare).</para>
   1.314  
   1.315 -      <para id="x_3ef">Quando nessuna di queste tecniche funziona, <command>patch</command> stampa un messaggio dicendo che il blocco in questione è stato rifiutato. Salva i blocchi rifiutati (anche chiamati semplicemente <quote>rifiuti</quote>) in un file con lo stesso nome e un'estensione <filename role="special">.rej</filename> aggiuntiva. Salva anche le copie non modificate del file con un'estensione <filename role="special">.orig</filename>; la copia del file senza alcuna estensione conterrà le modifiche fatte dal blocco che sono state <emphasis>effettivamente</emphasis> applicate. Se avete una patch che modifica il file <filename>foo</filename> con sei blocchi, e uno di essi non si riesce ad applicare, avrete: una copia <filename>foo.orig</filename> non modificata del file originale, un file <filename>foo.rej</filename> contenente un blocco e il file <filename>foo</filename> contenente le modifiche effettuate dai cinque blocchi applicati con successo.</para>
   1.316 +      <para id="x_3ef">Quando nessuna di queste tecniche funziona, <command>patch</command> stampa un messaggio dicendo che il blocco in questione è stato rifiutato. Il comando salva i blocchi rifiutati (anche chiamati semplicemente <quote>rifiuti</quote>) in un file con lo stesso nome e un'estensione <filename role="special">.rej</filename> aggiuntiva. Le copie non modificate del file vengono salvate con un'estensione <filename role="special">.orig</filename>, mentre la copia del file senza alcuna estensione conterrà le modifiche fatte dai blocchi che sono stati <emphasis>effettivamente</emphasis> applicati. Se avete una patch che modifica il file <filename>foo</filename> con sei blocchi, ma uno di essi non si riesce ad applicare, otterrete una copia <filename>foo.orig</filename> non modificata del file originale, un file <filename>foo.rej</filename> contenente un blocco e il file <filename>foo</filename> contenente le modifiche effettuate dai cinque blocchi applicati con successo.</para>
   1.317      </sect2>
   1.318  
   1.319      <sect2>
   1.320 @@ -250,15 +249,15 @@
   1.321        <itemizedlist>
   1.322  	<listitem><para id="x_3f1">Questo dovrebbe già essere ovvio, ma <command>patch</command> non è in grado di gestire i file binari.</para>
   1.323  	</listitem>
   1.324 -	<listitem><para id="x_3f2">Non si cura neanche del bit di esecuzione, bensì crea nuovi file come leggibili, ma non eseguibili.</para>
   1.325 +	<listitem><para id="x_3f2">Il comando non si cura neanche del bit di esecuzione, bensì crea i nuovi file come leggibili, ma non eseguibili.</para>
   1.326  	</listitem>
   1.327  	<listitem><para id="x_3f3"><command>patch</command> tratta la rimozione di un file come un diff tra il file da rimuovere e un file vuoto. Quindi la vostra idea di <quote>cancellare un file</quote> viene rappresentata in una patch come <quote>ogni riga di questo file è stata cancellata</quote>.</para>
   1.328  	</listitem>
   1.329  	<listitem><para id="x_3f4">Tratta l'aggiunta di un file come un diff tra un file vuoto e il file da aggiungere. Quindi la vostra idea di <quote>aggiungere un file</quote> viene rappresentata in una patch come <quote>ogni riga di questo file è stata aggiunta</quote>.</para>
   1.330  	</listitem>
   1.331 -	<listitem><para id="x_3f5">Tratta un file rinominato come la rimozione del file con il vecchio nome e l'aggiunta del file con il nuovo nome. Questo significa che i file rinominati hanno una grande impronta sulle patch. (Notate anche che Mercurial attualmente non cerca di inferire se i file in una patch sono stati rinominati o copiati.)</para>
   1.332 -	</listitem>
   1.333 -	<listitem><para id="x_3f6"><command>patch</command> non è in grado di rappresentare i file vuoti, quindi non potete usare una patch per rappresentare la nozione di <quote>aggiungere questo vile vuoto all'albero</quote>.</para>
   1.334 +	<listitem><para id="x_3f5">Tratta un file rinominato come la rimozione del file con il vecchio nome e l'aggiunta del file con il nuovo nome. Questo significa che i file rinominati occupano molto spazio in una patch. (Notate anche che Mercurial attualmente non cerca di inferire se i file in una patch sono stati rinominati o copiati.)</para>
   1.335 +	</listitem>
   1.336 +	<listitem><para id="x_3f6"><command>patch</command> non è in grado di rappresentare i file vuoti, quindi non potete usare una patch per rappresentare la nozione di <quote>aggiungere questo file vuoto all'albero</quote>.</para>
   1.337  	</listitem>
   1.338        </itemizedlist>
   1.339      </sect2>
   1.340 @@ -266,19 +265,19 @@
   1.341      <sect2>
   1.342        <title>Fate attenzione all'incertezza</title>
   1.343  
   1.344 -      <para id="x_3f7">Sebbene l'applicazione di un blocco a una certa distanza, 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 a una posizione sbagliata nel file. Se <command>patch</command> o <command role="hg-ext-mq">qpush</command> dovessero mai mezionare la distanza o il fattore di incertezza, dovreste assicurarvi che i file sono stati modificati in maniera corretta.</para>
   1.345 -
   1.346 -      <para id="x_3f8">Spesso è una buona idea aggiornare una patch che è stata applicata con una distanza o un fattore di incertezza; l'aggiornamento della patch genera nuove informazioni di contesto che permetteranno di applicarla in maniera pulita. Dico <quote>spesso,</quote> non <quote>sempre,</quote> 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 versioni multiple 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.</para>
   1.347 +      <para id="x_3f7">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 <command>patch</command> o <command role="hg-ext-mq">qpush</command> dovessero mai menzionare lo scostamento o il fattore di incertezza, dovreste assicurarvi che i file siano stati modificati in maniera corretta.</para>
   1.348 +
   1.349 +      <para id="x_3f8">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 pulita. Dico <quote>spesso</quote>, non <quote>sempre</quote>, 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.</para>
   1.350      </sect2>
   1.351  
   1.352      <sect2>
   1.353        <title>Gestire il rifiuto</title>
   1.354  
   1.355 -      <para id="x_3f9">Se <command role="hg-ext-mq">qpush</command> non riesce ad applicare una patch, stamperà un messaggio di errore e terminerà. Se ha lasciato alcuni file <filename role="special">.rej</filename>, normalmente è meglio correggere i blocchi rifiutati prima di inserire altre patch in cima alla pila o fare qualsiasi ulteriore modifica.</para>
   1.356 -
   1.357 -      <para id="x_3fa">Se la vostra patch <emphasis>era solita</emphasis> applicarsi in maniera pulita, e non lo fa più perché avete modificato il codice sottostante su cui le vostre patch si basavano, Mercurial Queues può aiutarvi; leggete la <xref linkend="sec:mq:merge"/> per i dettagli.</para>
   1.358 -
   1.359 -      <para id="x_3fb">Sfortunatamente, non c'è alcuna grande tecnica per gestire i blocchi rifiutati. Molto spesso, avrete bisogno di esaminare il file <filename role="special">.rej</filename> e di modificare il file di destinazione, applicando a mano i blocchi rifiutati.</para>
   1.360 +      <para id="x_3f9">Se <command role="hg-ext-mq">qpush</command> non riesce ad applicare una patch, stamperà un messaggio di errore e terminerà. Se ha lasciato alcuni file <filename role="special">.rej</filename>, normalmente è meglio correggere i blocchi rifiutati prima di inserire altre patch o fare qualsiasi ulteriore modifica.</para>
   1.361 +
   1.362 +      <para id="x_3fa">Se <emphasis>di solito</emphasis> 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 <xref linkend="sec:mq:merge"/> per i dettagli.</para>
   1.363 +
   1.364 +      <para id="x_3fb">Sfortunatamente, non esiste alcuna tecnica particolare per gestire i blocchi rifiutati. Molto spesso, avrete bisogno di esaminare il file <filename role="special">.rej</filename> e di modificare il file di destinazione, applicando a mano i blocchi rifiutati.</para>
   1.365  
   1.366        <para id="x_3fd">Un programmatore del kernel di Linux, Chris Mason (l'autore di Mercurial Queues), ha realizzato uno strumento chiamato <command>mpatch</command> (<ulink url="http://oss.oracle.com/~mason/mpatch/">http://oss.oracle.com/~mason/mpatch/</ulink>), che adotta un approccio semplice per automatizzare l'applicazione dei blocchi rifiutati da <command>patch</command>. Il comando <command>mpatch</command> può aiutarvi nel caso il blocco sia stato rifiutato per quattro tipiche ragioni:</para>
   1.367  
   1.368 @@ -293,7 +292,7 @@
   1.369  	</listitem>
   1.370        </itemizedlist>
   1.371  
   1.372 -      <para id="x_402">Se usate il comando <command>mpatch</command>, dovreste controllare doppiamente con attenzione i risultati quando avete finito. In effetti, <command>mpatch</command> impone questo metodo di doppio controllo sul risultato dello strumento, depositandovi automaticamente in un programma di gestione delle unioni quando ha concluso il proprio lavoro, in modo che possiate verificare i risultati e risolvere qualsiasi conflitto rimanente.</para>
   1.373 +      <para id="x_402">Se usate il comando <command>mpatch</command>, dovreste stare doppiamente attenti quando controllate i risultati al termine dell'esecuzione. In effetti, <command>mpatch</command> 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.</para>
   1.374      </sect2>
   1.375    </sect1>
   1.376  
   1.377 @@ -303,7 +302,7 @@
   1.378      <para id="x_6db">Man mano che acquisite familiarità con MQ, comincerete a voler eseguire altri tipi di operazioni di gestione delle patch.</para>
   1.379  
   1.380      <sect2>
   1.381 -      <title>Cancellare le patch non volute</title>
   1.382 +      <title>Cancellare le patch indesiderate</title>
   1.383  
   1.384        <para id="x_6dc">Se volete sbarazzarvi di una patch, usate il comando <command role="hg-ext-mq">hg qdelete</command> 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, <command role="hg-ext-mq">hg qdelete</command> si rifiuterà di operare.</para>
   1.385  
   1.386 @@ -313,11 +312,11 @@
   1.387      <sect2>
   1.388        <title>Convertire verso e da revisioni permanenti</title>
   1.389  
   1.390 -      <para id="x_6dd">Una volta che avete finito di lavorare con una patch e volete trasformarla in un changeset permanente, usate il comando <command role="hg-ext-mq">hg qfinish</command>. Passate una revisione al comando per identificare la patch che volete trasformare in un normale changeset, questa patch deve essere già stata applicate.</para>
   1.391 +      <para id="x_6dd">Una volta che avete finito di lavorare con una patch e volete trasformarla in un changeset permanente, usate il comando <command role="hg-ext-mq">hg qfinish</command>. Passate una revisione al comando per identificare la patch che volete trasformare in un normale changeset; questa patch deve essere già stata applicata.</para>
   1.392  
   1.393        &interaction.ch11-qdelete.convert;
   1.394  
   1.395 -      <para id="x_6e0">Il comando <command role="hg-ext-mq">hg qfinish</command> accetta una opzione <option>--all</option> o <option>-a</option> per trasformare tutte le patch applicate in normali changeset.</para>
   1.396 +      <para id="x_6e0">Il comando <command role="hg-ext-mq">hg qfinish</command> accetta un'opzione <option>--all</option> o <option>-a</option> per trasformare tutte le patch applicate in normali changeset.</para>
   1.397  
   1.398        <para id="x_6de">&Egrave; anche possibile trasformare un changeset esistente in una patch, passando l'opzione <option>-r</option> al comando <command role="hg-ext-mq">hg qimport</command>.</para>
   1.399  
   1.400 @@ -330,15 +329,15 @@
   1.401    <sect1 id="sec:mq:perf">
   1.402      <title>Ottenere le prestazioni migliori da MQ</title>
   1.403  
   1.404 -    <para id="x_403">MQ è molto efficiente nel gestire un grande numero di patch. Ho effettuato alcuni esperimenti sulle prestazioni a metà del 2006 per una presentazione che ho tenuto alla conferenza EuroPython 2006 (su macchine più moderne, dovreste aspettarvi risultati migliori di quelli che vedrete nel seguito). Come #data set# ho usato la serie di patch 2.6.17-mm1 per il kernel di Linux, contenente 1.738 patch. Ho applicato queste patch a un repository del kernel di Linux contenente tutte le 27.472 revisioni intercorse tra Linux 2.6.12-rc2 e Linux 2.6.17.</para>
   1.405 -
   1.406 -    <para id="x_404">Sul mio vecchio e lento portatile, sono riuscito a eseguire <command role="hg-cmd">hg qpush <option role="hg-ext-mq-cmd-qpush-opt">hg -a</option></command> per tutte le 1.738 patch in 3.5 minuti e a eseguire <command role="hg-cmd">hg qpop <option role="hg-ext-mq-cmd-qpop-opt">hg -a</option></command> per tutte le patch in 30 secondi. (Su portatili più recenti, il tempo per estrarre tutte le patch è sceso a due minuti.) Ho potuto aggiornare una delle patch più grandi (che ha effettuato 22.779 righe di cambiamenti a 287 file) eseguendo <command role="hg-ext-mq">qrefresh</command> in 6.6 secondi.</para>
   1.407 -
   1.408 -    <para id="x_405">Chiaramente, MQ è particolarmente adatto per lavorare su alberi di grandi dimensioni, ma ci sono alcuni trucchi che potete usare per ottenere pefrormance ancora migliori.</para>
   1.409 -
   1.410 -    <para id="x_406">Prima di tutto, provate a <quote>raggruppare</quote> insieme le operazioni. Ogni volta che eseguite <command role="hg-ext-mq">qpush</command> o <command role="hg-ext-mq">qpop</command>, questi comandi esaminano la directory di lavoro una volta per assicurarsi che non avete effettuato alcuna modifica dimenticandovi poi di invocare <command role="hg-ext-mq">qrefresh</command>. Su alberi di piccole dimensioni, il tempo impiegato da questa disamina è insignificante. Tuttavia, su un albero di medie dimensioni (contenente decine di migliaia di file), questa operazione può impiegare anche più di un secondo.</para>
   1.411 -
   1.412 -    <para id="x_407">I comandi <command role="hg-ext-mq">qpush</command> e <command role="hg-ext-mq">qpop</command> vi permettono di estrarre e inserire più patch alla volta. Potete identificare la <quote>patch di destinazione</quote> a cui volete giungere. Quando usate <command role="hg-ext-mq">qpush</command> specificando una destinazione, il comando inserirà patch fino a quando quella patch non si troverà in cima alla pila delle patch applicate. Quando usate <command role="hg-ext-mq">qpop</command> con una destinazione, MQ estrarrà patch fino a quando la patch di destinazione non si troverà in cima.</para>
   1.413 +    <para id="x_403">MQ è molto efficiente nel gestire un grande numero di patch. Ho effettuato alcuni esperimenti sulle prestazioni a metà del 2006 per una presentazione che ho tenuto alla conferenza EuroPython 2006 (su macchine più moderne, dovreste aspettarvi risultati migliori di quelli che vedrete nel seguito). Come dati campione ho usato la serie di patch 2.6.17-mm1 per il kernel di Linux, contenente 1.738 patch. Ho applicato queste patch a un repository del kernel di Linux contenente tutte le 27.472 revisioni intercorse tra Linux 2.6.12-rc2 e Linux 2.6.17.</para>
   1.414 +
   1.415 +    <para id="x_404">Sul mio vecchio e lento portatile, sono riuscito a eseguire <command role="hg-cmd">hg qpush <option role="hg-ext-mq-cmd-qpush-opt">-a</option></command> per tutte le 1.738 patch in 3.5 minuti e a eseguire <command role="hg-cmd">hg qpop <option role="hg-ext-mq-cmd-qpop-opt">-a</option></command> per tutte le patch in 30 secondi. (Su portatili più recenti, il tempo per estrarre tutte le patch è sceso a due minuti.) Ho potuto aggiornare una delle patch più grandi (che ha effettuato 22.779 righe di cambiamenti a 287 file) eseguendo <command role="hg-ext-mq">qrefresh</command> in 6.6 secondi.</para>
   1.416 +
   1.417 +    <para id="x_405">Chiaramente, MQ è particolarmente adatto per lavorare su alberi di grandi dimensioni, ma ci sono alcuni trucchi che potete usare per ottenere prestazioni ancora migliori.</para>
   1.418 +
   1.419 +    <para id="x_406">Prima di tutto, provate a <quote>raggruppare</quote> insieme le operazioni. Ogni volta che eseguite <command role="hg-ext-mq">qpush</command> o <command role="hg-ext-mq">qpop</command>, questi comandi esaminano la directory di lavoro una volta per assicurarsi che non abbiate effettuato alcuna modifica dimenticandovi poi di invocare <command role="hg-ext-mq">qrefresh</command>. Su alberi di piccole dimensioni, il tempo impiegato da questa disamina è insignificante. Tuttavia, su un albero di medie dimensioni (contenente decine di migliaia di file), questa operazione può impiegare anche più di un secondo.</para>
   1.420 +
   1.421 +    <para id="x_407">I comandi <command role="hg-ext-mq">qpush</command> e <command role="hg-ext-mq">qpop</command> vi permettono di estrarre e inserire più patch alla volta. Come prima cosa, identificate la <quote>patch di destinazione</quote> che volete raggiungere. Quando usate <command role="hg-ext-mq">qpush</command> specificando una destinazione, il comando inserirà patch finché quella patch non si troverà in cima alla pila delle patch applicate. Quando usate <command role="hg-ext-mq">qpop</command> con una destinazione, MQ estrarrà patch finché la patch di destinazione non si troverà in cima a quella pila.</para>
   1.422  
   1.423      <para id="x_408">Potete identificare una patch di destinazione usando il nome della patch oppure un numero. Se usate un identificatore numerico, il conteggio delle patch parte da zero; questo significa che la prima patch corrisponde a zero, la seconda a uno, e così via.</para>
   1.424    </sect1>
   1.425 @@ -346,32 +345,32 @@
   1.426    <sect1 id="sec:mq:merge">
   1.427      <title>Aggiornare le vostre patch quando il codice sottostante cambia</title>
   1.428  
   1.429 -    <para id="x_409">Capita spesso di avere una pila di patch su un repository sottostante che non modificate direttamente. Se state lavorando sui cambiamenti a codice di terze parti, o su una funzione che impiegate più tempo a sviluppare rispetto alla velocità di cambiamento del codice al di sotto, avrete spesso bisogno di sincronizzarvi con il codice sottostante e di correggere ogni blocco delle vostre patch che non è più applicabile. Questa operazione si chiama <emphasis>rifondare</emphasis> la vostra serie di patch.</para>
   1.430 -
   1.431 -    <para id="x_40a">Il modo più semplice per fare questo è di usare <command role="hg-cmd">hg qpop <option role="hg-ext-mq-cmd-qpop-opt">hg -a</option></command> per estrarre le vostre patch, poi invocare <command role="hg-cmd">hg pull</command> per propagare i cambiamenti nel repository sottostante e infine eseguire <command role="hg-cmd">hg qpush <option role="hg-ext-mq-cmd-qpop-opt">hg -a</option></command> per inserire nuovamente le vostre patch. MQ interromperà l'inserimento ogni volta che incontra una patch che non riesce ad applicare a causa di qualche conflitto, dandovi la possibilità di risolvere i conflitti, aggiornare la patch affetta tramite <command role="hg-ext-mq">qrefresh</command> e continuare a inserire fino a quando non avete corretto l'intera pila.</para>
   1.432 -
   1.433 -    <para id="x_40b">Questo approccio è semplice e funziona bene se non vi aspettate modifiche al codice sottostante che influenzino quanto bene si applicano le vostre patch. Se la vostra pila di patch tocca codice che viene modificato in maniera frequente o invasiva nel repository sottostante, tuttavia, corregere a mano i blocchi rifiutati diventa velocemente una seccatura.</para>
   1.434 -
   1.435 -    <para id="x_40c">&Egrave; possibile automatizzare parzialmente il processo di rifondazione. Se le vostre patch si applicano in maniera pulita su una qualche revisione del repository sottostante, MQ può usare questa informazione per aiutarvi a risolvere i conflitti tra le vostre patch e revisioni differenti.</para>
   1.436 +    <para id="x_409">Capita spesso di mantenere una pila di patch su un repository sottostante che non modificate direttamente. Se state lavorando sui cambiamenti a codice di terze parti, o su una funzione che impiegate più tempo a sviluppare rispetto alla velocità di cambiamento del codice su cui si basa, avrete spesso bisogno di sincronizzarvi con il codice sottostante e di correggere ogni blocco delle vostre patch che non è più applicabile. Questa operazione si chiama <emphasis>rifondare</emphasis> la vostra serie di patch.</para>
   1.437 +
   1.438 +    <para id="x_40a">Il modo più semplice per eseguire questa operazione è quello di usare <command role="hg-cmd">hg qpop <option role="hg-ext-mq-cmd-qpop-opt">-a</option></command> per estrarre le vostre patch, poi invocare <command role="hg-cmd">hg pull</command> per propagare i cambiamenti nel repository sottostante e infine eseguire <command role="hg-cmd">hg qpush <option role="hg-ext-mq-cmd-qpop-opt">-a</option></command> per inserire nuovamente le vostre patch. MQ interromperà l'inserimento ogni volta che incontra una patch che non riesce ad applicare a causa di qualche conflitto, dandovi la possibilità di risolvere i conflitti, aggiornare la patch interessata tramite <command role="hg-ext-mq">qrefresh</command> e continuare a inserire fino a quando non avrete corretto l'intera pila.</para>
   1.439 +
   1.440 +    <para id="x_40b">Questo approccio è semplice e funziona bene se non vi aspettate che le modifiche al codice sottostante influenzino l'applicabilità delle vostre patch. Tuttavia, se la vostra pila di patch coinvolge codice che viene modificato in maniera frequente o invasiva nel repository sottostante, correggere a mano i blocchi rifiutati diventa velocemente una seccatura.</para>
   1.441 +
   1.442 +    <para id="x_40c">&Egrave; possibile automatizzare parzialmente il processo di rifondazione. Se le vostre patch si applicano in maniera pulita su una qualche revisione del repository sottostante, MQ può usare questa informazione per aiutarvi a risolvere i conflitti tra le vostre patch e una revisione differente.</para>
   1.443  
   1.444      <para id="x_40d">Il processo è leggermente complicato.</para>
   1.445      <orderedlist>
   1.446 -      <listitem><para id="x_40e">Per cominciare, invocate <command role="hg-cmd">hg qpush -a</command> per inserire tutte le vostre patch sulla revisione su cui sapete che si applicano in maniera pulita.</para>
   1.447 -      </listitem>
   1.448 -      <listitem><para id="x_40f">Salvate una copia di backup della vostra directory delle patch usando <command role="hg-cmd">hg qsave <option role="hg-ext-mq-cmd-qsave-opt">hg -e</option> <option role="hg-ext-mq-cmd-qsave-opt">hg -c</option></command>. Questo stampa il nome della directory in cui sono state salvate le patch. Salverà le patch in una directory chiamata <filename role="special" class="directory">.hg/patches.N</filename>, dove <literal>N</literal> è un piccolo intero. Inserirà anche un <quote>changeset di salvataggio</quote> in cima alle vostre patch applicate, per registrare internamente gli stati dei file <filename role="special">series</filename> e <filename role="special">status</filename>.</para>
   1.449 -      </listitem>
   1.450 -      <listitem><para id="x_410">Usate <command role="hg-cmd">hg pull</command> per propagare i nuovi cambiamenti nel repository sottostante. (Non invocate <command role="hg-cmd">hg pull -u</command>; vedete più avanti perché.)</para>
   1.451 -      </listitem>
   1.452 -      <listitem><para id="x_411">Aggiornate la directory di lavoro alla nuova revisione di punta, usando <command role="hg-cmd">hg update <option role="hg-opt-update">-C</option></command> per #override# le patch che avete inserito.</para>
   1.453 -      </listitem>
   1.454 -      <listitem><para id="x_412">Unite tutte le patch usando <command>hg qpush -m -a</command>. L'opzione  <option role="hg-ext-mq-cmd-qpush-opt">-m</option> di <command role="hg-ext-mq">qpush</command> dice a MQ di effettuare un'unione a tre vie se la patch non si riesce ad applicare.</para>
   1.455 +      <listitem><para id="x_40e">Come prima cosa, invocate <command role="hg-cmd">hg qpush -a</command> per inserire tutte le vostre patch sulla revisione su cui sapete che si applicano in maniera pulita.</para>
   1.456 +      </listitem>
   1.457 +      <listitem><para id="x_40f">Salvate una copia di backup della vostra directory delle patch usando <command role="hg-cmd">hg qsave <option role="hg-ext-mq-cmd-qsave-opt">-e</option> <option role="hg-ext-mq-cmd-qsave-opt">-c</option></command>. Questo comando salva le patch in una directory chiamata <filename role="special" class="directory">.hg/patches.N</filename>, dove <literal>N</literal> è un piccolo intero, e stampa il nome della directory in cui sono state salvate le patch. Il comando inserisce anche un <quote>changeset di salvataggio</quote> dopo quelli corrispondenti alle vostre patch applicate, per registrare internamente gli stati dei file <filename role="special">series</filename> e <filename role="special">status</filename>.</para>
   1.458 +      </listitem>
   1.459 +      <listitem><para id="x_410">Invocate <command role="hg-cmd">hg pull</command> per propagare i nuovi cambiamenti nel repository sottostante. (Non usate <command role="hg-cmd">hg pull -u</command>, perché l'aggiornamento dovrà essere fatto in maniera particolare, come vedrete nel prossimo punto.)</para>
   1.460 +      </listitem>
   1.461 +      <listitem><para id="x_411">Aggiornate la directory di lavoro alla nuova revisione di punta, usando <command role="hg-cmd">hg update <option role="hg-opt-update">-C</option></command> per sovrascrivere le modifiche apportate dalle patch che avete inserito.</para>
   1.462 +      </listitem>
   1.463 +      <listitem><para id="x_412">Unite tutte le patch usando <command>hg qpush -m -a</command>. L'opzione <option role="hg-ext-mq-cmd-qpush-opt">-m</option> di <command role="hg-ext-mq">qpush</command> dice a MQ di effettuare un'unione a tre vie se l'applicazione di una patch fallisce.</para>
   1.464        </listitem></orderedlist>
   1.465  
   1.466 -    <para id="x_413">Durante l'esecuzione di <command role="hg-cmd">hg qpush <option role="hg-ext-mq-cmd-qpush-opt">hg -m</option></command>, ogni patch nel file <filename role="special">series</filename> viene applicata normalmente. Se una patch viene applicata con un fattore di incertezza o viene rifiutata, MQ guarda alla coda che avete salvato tramite <command role="hg-ext-mq">qsave</command> ed effettua un'unione a tre vie con il corrispondente changeset. Questa unione usa il normale meccanismo di unione di Mercurial, quindi potrebbe aprire uno strumento grafico per le unioni in modo da aiutarvi a risolvere i problemi.</para>
   1.467 +    <para id="x_413">Durante l'esecuzione di <command role="hg-cmd">hg qpush <option role="hg-ext-mq-cmd-qpush-opt">-m</option></command>, ogni patch nel file <filename role="special">series</filename> viene applicata normalmente. Se una patch viene applicata con un fattore di incertezza o viene rifiutata, MQ esamina la coda che avete salvato tramite <command role="hg-ext-mq">qsave</command> ed effettua un'unione a tre vie con il changeset che corrisponde alla patch. Questa unione sfrutta il normale meccanismo di unione di Mercurial, quindi potrebbe aprire uno strumento grafico per le unioni in modo da aiutarvi a risolvere i problemi.</para>
   1.468  
   1.469      <para id="x_414">Quando avete finito di risolvere gli effetti di una patch, MQ aggiornerà la vostra patch sulla base dei risultati dell'unione.</para>
   1.470  
   1.471 -    <para id="x_415">Alla fine di questo processo, il vostro repository avrà una testa aggiuntiva proveniente dalla vecchia coda delle patch, e una copia della vecchia coda delle patch si troverà in <filename role="special" class="directory">.hg/patches.N</filename>. Potete rimuovere la testa aggiuntiva usando <command role="hg-cmd">hg qpop -a -n patches.N</command> o <command role="hg-cmd">hg strip</command>. Potete cancellare <filename role="special" class="directory">.hg/patches.N</filename> una volta che siete sicuri che non ne avete più bisogno come backup.</para>
   1.472 +    <para id="x_415">Alla fine di questo processo, il vostro repository conterrà una testa aggiuntiva proveniente dalla vecchia coda delle patch e la directory <filename role="special" class="directory">.hg/patches.N</filename> conterrà una copia della vecchia coda delle patch. Potete rimuovere la testa aggiuntiva usando <command role="hg-cmd">hg qpop -a -n patches.N</command> o <command role="hg-cmd">hg strip</command>. Potete cancellare <filename role="special" class="directory">.hg/patches.N</filename> una volta che siete sicuri di non averne più bisogno come backup.</para>
   1.473    </sect1>
   1.474  
   1.475    <sect1>
   1.476 @@ -381,24 +380,24 @@
   1.477  
   1.478      <para id="x_417">Potete abbreviare il riferimento a una patch usando sia un nome che una differenza numerica: <literal>foo.patch-2</literal> significa <quote>due patch prima di <literal>foo.patch</literal></quote>, mentre <literal>bar.patch+4</literal> significa <quote>quattro patch dopo <literal>bar.patch</literal></quote>.</para>
   1.479  
   1.480 -    <para id="x_418">Il riferimento per indice non è molto differente. La prima patch visualizzata da <command role="hg-ext-mq">qseries</command> è la patch numero zero (sì, è uno di quei sistemi di conteggio che partono da zero), la seconda è la patch numero uno, e così via.</para>
   1.481 -
   1.482 -    <para id="x_419">MQ rende anche più facile lavorare con le patch quando state usando i normali comandi Mercurial. Tutti i comandi che accettano un identificatore di changeset accettano anche il nome di una patch applicata. MQ accresce le etichette normalmente presenti nel repository con un'etichetta eponima per ogni patch applicata. In più, le etichette speciali <literal role="tag">qbase</literal> e <literal role="tag">qtip</literal> identificano le patch applicate rispettivamente in fondo e in cima alla pila.</para>
   1.483 -
   1.484 -    <para id="x_41a">Queste aggiunte alla funzione di #tagging# di Mercurial rendono ancora più facile utilizzare le patch.</para>
   1.485 +    <para id="x_418">Il riferimento per indice non è molto diverso. La prima patch visualizzata da <command role="hg-ext-mq">qseries</command> è la patch numero zero (sì, è uno di quei sistemi di conteggio che partono da zero), la seconda è la patch numero uno, e così via.</para>
   1.486 +
   1.487 +    <para id="x_419">MQ rende anche più facile lavorare con le patch usando i normali comandi Mercurial. Tutti i comandi che accettano un identificatore di changeset accettano anche il nome di una patch applicata. MQ aggiunge un'etichetta eponima per ogni patch applicata alle etichette normalmente presenti nel repository. In più, le etichette speciali <literal role="tag">qbase</literal> e <literal role="tag">qtip</literal> identificano rispettivamente la prima e l'ultima patch applicata.</para>
   1.488 +
   1.489 +    <para id="x_41a">Queste aggiunte alla funzione di etichettatura di Mercurial facilitano ulteriormente l'uso delle patch.</para>
   1.490      <itemizedlist>
   1.491        <listitem><para id="x_41b">Volete bombardare di patch una mailing list con l'ultima serie dei vostri cambiamenti?</para>
   1.492  	<programlisting>hg email qbase:qtip</programlisting>
   1.493  	<para id="x_41c">(Non sapete cosa sia un <quote>bombardamento di patch</quote>? Leggete la <xref linkend="sec:hgext:patchbomb"/>.)</para>
   1.494        </listitem>
   1.495        <listitem><para id="x_41d">Avete bisogno di vedere tutte le patch che da <literal>foo.patch</literal> in poi hanno toccato i file contenuti in una sottodirectory del vostro albero?</para>
   1.496 -	<programlisting>hg log -r foo.patch:qtip subdir</programlisting>
   1.497 +	<programlisting>hg log -r foo.patch:qtip sottodirectory</programlisting>
   1.498        </listitem>
   1.499      </itemizedlist>
   1.500  
   1.501 -    <para id="x_41e">Dato che MQ rende disponibili i nomi delle patch al resto di Mercurial tramite il meccanismo interno delle etichette, non avete bisogno di digitare l'intero nome di una patch quando volete identificarla per nome.</para>
   1.502 -
   1.503 -    <para id="x_41f">Un'altra piacevole conseguenza del rappresentare i nomi di patch come etichette è che il comando <command role="hg-cmd">hg log</command> mostrerà il nome di una patch come un'etichetta, semplicemente come parte del proprio output normale. Questo rende facile distinguere visivamente le patch applicate dalle <quote>normali</quote> revisioni sottostanti. L'esempio seguente mostra alcuni comandi Mercurial in azione con le patch applicate.</para>
   1.504 +    <para id="x_41e">Dato che MQ rende disponibili i nomi delle patch alle altre parti di Mercurial tramite il meccanismo interno delle etichette, non avete bisogno di digitare l'intero nome di una patch quando volete identificarla per nome.</para>
   1.505 +
   1.506 +    <para id="x_41f">Un'altra piacevole conseguenza del rappresentare i nomi di patch come etichette è che il comando <command role="hg-cmd">hg log</command> mostrerà normalmente il nome di una patch come un'etichetta nel proprio elenco, rendendo facile distinguere visivamente le patch applicate dalle <quote>normali</quote> revisioni sottostanti. L'esempio seguente mostra alcuni comandi Mercurial in azione con le patch applicate.</para>
   1.507  
   1.508      &interaction.mq.id.output;
   1.509    </sect1>
   1.510 @@ -409,9 +408,9 @@
   1.511      <para id="x_420">Ci sono alcuni aspetti dell'uso di MQ che non trovano posto in sezioni dedicate, ma che è bene conoscere. Li presento qui, in un unico posto.</para>
   1.512  
   1.513      <itemizedlist>
   1.514 -      <listitem><para id="x_421">Normalmente, quando estraete una patch tramite <command role="hg-ext-mq">qpop</command> e poi la reinserite tramite <command role="hg-ext-mq">qpush</command>, il changeset che rappresenta la patch dopo l'estrazione/inserimento avrà una <emphasis>diversa identità</emphasis> rispetto al changeset che rappresentava l'hash in precedenza. Leggete la <xref linkend="sec:mqref:cmd:qpush"/> per sapere perché succede questo.</para>
   1.515 -      </listitem>
   1.516 -      <listitem><para id="x_422">Non è una buona idea usare <command role="hg-cmd">hg merge</command> per unire i cambiamenti da un altro ramo con un changeset di patch, almeno se volete mantenere la <quote>natura di patch</quote> di quel changeset e dei changeset che si trovano sotto a quello nella pila delle patch. Se provate a farlo, sembrerà avere successo, ma l'effetto sarà quello di confondere MQ.</para>
   1.517 +      <listitem><para id="x_421">Normalmente, quando estraete una patch tramite <command role="hg-ext-mq">qpop</command> e poi la reinserite tramite <command role="hg-ext-mq">qpush</command>, il changeset che rappresenta la patch dopo l'estrazione/inserimento avrà una <emphasis>diversa identità</emphasis> rispetto al changeset che rappresentava l'hash in precedenza. Leggete la <xref linkend="sec:mqref:cmd:qpush"/> per sapere perché.</para>
   1.518 +      </listitem>
   1.519 +      <listitem><para id="x_422">Non è una buona idea usare <command role="hg-cmd">hg merge</command> per unire i cambiamenti da un altro ramo con un changeset corrispondente a una patch, almeno se volete mantenere la <quote>natura di patch</quote> di quel changeset e dei changeset che si trovano sotto a quello nella pila delle patch. Se provate a farlo, sembrerà avere successo, ma l'effetto sarà quello di disorientare MQ.</para>
   1.520        </listitem>
   1.521      </itemizedlist>
   1.522    </sect1>
   1.523 @@ -421,26 +420,26 @@
   1.524  
   1.525      <para id="x_423">Dato che la directory <filename role="special" class="directory">.hg/patches</filename> di MQ risiede fuori dalla directory di lavoro di un repository Mercurial, il repository Mercurial <quote>sottostante</quote> non sa nulla della gestione o della presenza delle patch.</para>
   1.526  
   1.527 -    <para id="x_424">Questo presenta l'interessante possibilità di gestire i contenuti della directory delle patch come un repository Mercurial indipendente. Questo può essere un modo utile per lavorare. Per esempio, potete lavorare su una patch per un po', aggiornala tramite <command role="hg-ext-mq">qrefresh</command> it, poi usare <command role="hg-cmd">hg commit</command> per registrare lo stato corrente della patch. Questo vi permette di <quote>ritornare</quote> a quella versione della patch più tardi.</para>
   1.528 -
   1.529 -    <para id="x_425">Potete quindi condividere differenti versioni della stessa pila di patch tra molteplici repository sottostanti. Uso questo quando sto sviluppando una funzione del kernel di Linux. Ho una copia intatta dei miei sorgenti del kernel per ogni diversa architettura di CPU e un repository clonato sotto ognuno di questi che contiene le patch su cui sto lavorando. Quando voglio collaudare un cambiamento su un'architettura differente, trasmetto le mie patch correnti al repository associato con il kernel di quell'architettura, estraggo e inserisco tutte le mie patch, e assemblo e collaudo quel kernel.</para>
   1.530 -
   1.531 -    <para id="x_426">Gestire le patch in un repository rende possibile a più sviluppatori di lavorare sulla stessa serie di patch senza scontrarsi tra loro, il tutto basandosi su sorgenti sottostanti che potrebbero o non potrebbero controllare.</para>
   1.532 +    <para id="x_424">Questo presenta l'interessante possibilità di gestire i contenuti della directory delle patch come un repository Mercurial indipendente. Questo può essere un modo utile per lavorare. Per esempio, potete lavorare su una patch per un po', aggiornala tramite <command role="hg-ext-mq">qrefresh</command>, poi usare <command role="hg-cmd">hg commit</command> per registrare lo stato corrente della patch. Questo vi permette di <quote>ritornare</quote> a quella versione della patch più tardi.</para>
   1.533 +
   1.534 +    <para id="x_425">Potete quindi condividere differenti versioni della stessa pila di patch tra molteplici repository sottostanti. Uso questa tecnica quando sto sviluppando una funzione del kernel di Linux. Ho una copia intatta dei miei sorgenti del kernel per ogni diversa architettura di CPU e un repository clonato su ognuna di queste architetture che contiene le patch su cui sto lavorando. Quando voglio collaudare una modifica su un'architettura differente, trasmetto le mie patch correnti al repository associato con il kernel di quell'architettura, estraggo e inserisco tutte le mie patch, infine assemblo e collaudo quel kernel.</para>
   1.535 +
   1.536 +    <para id="x_426">Gestire le patch in un repository consente a più sviluppatori di lavorare sulla stessa serie di patch senza scontrarsi tra loro e basandosi su sorgenti sottostanti che potrebbero o non potrebbero essere sotto il loro controllo.</para>
   1.537  
   1.538      <sect2>
   1.539        <title>Il supporto di MQ per i repository di patch</title>
   1.540  
   1.541 -      <para id="x_427">MQ vi aiuta a lavorare con la directory <filename role="special" class="directory">.hg/patches</filename> come un repository; quando preparate un repository per lavorare con le patch usando <command role="hg-ext-mq">qinit</command>, potete passare l'opzione <option role="hg-ext-mq-cmd-qinit-opt">hg -c</option> per creare la directory <filename role="special" class="directory">.hg/patches</filename> sotto forma di un repository Mercurial.</para>
   1.542 +      <para id="x_427">MQ vi aiuta a lavorare con la directory <filename role="special" class="directory">.hg/patches</filename> in qualità di repository. Quando preparate un repository per lavorare con le patch usando <command role="hg-ext-mq">qinit</command>, potete passare l'opzione <option role="hg-ext-mq-cmd-qinit-opt">-c</option> per creare la directory <filename role="special" class="directory">.hg/patches</filename> sotto forma di un repository Mercurial.</para>
   1.543  
   1.544        <note>
   1.545 -	<para id="x_428">Se dimenticate di usare l'opzione <option role="hg-ext-mq-cmd-qinit-opt">hg -c</option>, potete semplicemente posizionarvi nella directory <filename role="special" class="directory">.hg/patches</filename> in qualsiasi momento e invocare <command role="hg-cmd">hg init</command>. Non dimenticate, però, di aggiungere una voce per il file <filename role="special">status</filename> al file <filename role="special">.hgignore</filename> (<command role="hg-cmd">hg qinit <option role="hg-ext-mq-cmd-qinit-opt">hg -c</option></command> fa questo automaticamente per voi); non volete <emphasis>davvero</emphasis> gestire il file <filename role="special">status</filename>.</para>
   1.546 +	<para id="x_428">Se dimenticate di usare l'opzione <option role="hg-ext-mq-cmd-qinit-opt">-c</option>, potete semplicemente posizionarvi nella directory <filename role="special" class="directory">.hg/patches</filename> in qualsiasi momento e invocare <command role="hg-cmd">hg init</command>. Non dimenticate, però, di aggiungere una voce per il file <filename role="special">status</filename> al file <filename role="special">.hgignore</filename> (<command role="hg-cmd">hg qinit <option role="hg-ext-mq-cmd-qinit-opt">-c</option></command> fa questo automaticamente per voi), perché il file <filename role="special">status</filename> non andrebbe <emphasis>davvero</emphasis> amministrato.</para>
   1.547        </note>
   1.548  
   1.549        <para id="x_42a">Per convenienza, se MQ nota che la directory <filename class="directory">.hg/patches</filename> è un repository, userà automaticamente <command role="hg-cmd">hg add</command> per aggiungere ogni patch che create e importate.</para>
   1.550  
   1.551 -      <para id="x_42b">MQ fornisce il comando abbreviato <command role="hg-ext-mq">qcommit</command> che esegue <command role="hg-cmd">hg commit</command> nella directory <filename role="special" class="directory">.hg/patches</filename>, per salvare noiose digitazioni.</para>
   1.552 -
   1.553 -      <para id="x_42c">Infine, come convenienza per gestire la directory delle patch, potete definire l'alias <command>mq</command> sui sistemi Unix. Per esempio, sui sistemi Linux che usano la shell <command>bash</command>, potete includere il seguente frammento nel vostro file <filename role="home">~/.bashrc</filename>.</para>
   1.554 +      <para id="x_42b">MQ fornisce il comando abbreviato <command role="hg-ext-mq">qcommit</command> che esegue <command role="hg-cmd">hg commit</command> nella directory <filename role="special" class="directory">.hg/patches</filename>, per risparmiarvi noiose digitazioni.</para>
   1.555 +
   1.556 +      <para id="x_42c">Infine, sui sistemi Unix, potete definire l'alias <command>mq</command> come comando di convenienza per gestire la directory delle patch. Per esempio, sui sistemi Linux che usano la shell <command>bash</command>, potete aggiungere la riga seguente al vostro file <filename role="home">~/.bashrc</filename>.</para>
   1.557  
   1.558        <programlisting>alias mq=`hg -R $(hg root)/.hg/patches'</programlisting>
   1.559  
   1.560 @@ -452,43 +451,43 @@
   1.561  
   1.562        <para id="x_42e">Il supporto di MQ per lavorare con un repository pieno di patch è limitato in alcuni aspetti di dettaglio.</para>
   1.563  
   1.564 -      <para id="x_42f">MQ non può automaticamente scoprire i cambiamenti che avete fatto alla directory delle patch. Se usate <command role="hg-cmd">hg pull</command>, fate delle modifiche a mano, o invocate <command role="hg-cmd">hg update</command> per aggiornare i cambiamenti alle patch o al file <filename role="special">series</filename>, dovrete usare <command role="hg-cmd">hg qpop <option role="hg-ext-mq-cmd-qpop-opt">hg -a</option></command> e poi <command role="hg-cmd">hg qpush <option role="hg-ext-mq-cmd-qpush-opt">hg -a</option></command> nel repository sottostante per fare in modo che quei cambiamenti si mostrino anche là. Se dimenticate di fare questo, potete confondere l'idea che MQ si è fatto su quali patch sono state applicate.</para>
   1.565 +      <para id="x_42f">MQ non può automaticamente scoprire quali modifiche avete fatto alla directory delle patch. Se usate <command role="hg-cmd">hg pull</command>, apportate cambiamenti a mano, o invocate <command role="hg-cmd">hg update</command> per aggiornare le modifiche alle patch o al file <filename role="special">series</filename>, dovrete usare <command role="hg-cmd">hg qpop <option role="hg-ext-mq-cmd-qpop-opt">-a</option></command> e poi <command role="hg-cmd">hg qpush <option role="hg-ext-mq-cmd-qpush-opt">-a</option></command> nel repository sottostante per fare in modo che quelle modifiche compaiano anche là. Se dimenticate di fare questo, potete confondere le idee a MQ in merito a quali patch sono state effettivamente applicate.</para>
   1.566  
   1.567      </sect2>
   1.568    </sect1>
   1.569    <sect1 id="sec:mq:tools">
   1.570      <title>Strumenti di terze parti che lavorano con le patch</title>
   1.571  
   1.572 -    <para id="x_430">Una volta che avete lavorato che le patch per un po', vi troverete affamati di strumenti che vi aiutino a capire e manipolare le patch che state maneggiando.</para>
   1.573 -
   1.574 -    <para id="x_431">Il comando <command>diffstat</command> <citation>web:diffstat</citation> genera un istogramma delle modifiche effettuate a ogni file in una patch. Fornisce un buon modo di <quote>#get a sense of#</quote> una patch&emdash;quali file coinvolge e quante modifiche introduce a ogni file e nell'insieme. (Trovo che è una buona idea usare l'opzione <option role="cmd-opt-diffstat">-p</option> di <command>diffstat</command> #as a matter of course#, in quanto altrimenti proverà a fare cose furbe con i prefissi dei nomi di file che almeno io trovo inevitabilmente confuse.)</para>
   1.575 -
   1.576 -&interaction.mq.tools.tools;
   1.577 -
   1.578 -    <para id="x_432">Il pacchetto <literal role="package">patchutils</literal> <citation>web:patchutils</citation> è inestimabile. Fornisce un insieme di piccole utilità che seguono la <quote>filosofia Unix:</quote> ognuna fa una singola cosa utile con una patch. Il comando di <literal role="package">patchutils</literal> che uso di più è <command>filterdiff</command>, che estrae sottinsiemi di un file di patch. Per esempio, data una patch che modifica centinaia di file attraverso dozzine di directory, una singola invocazione di <command>filterdiff</command> può generare una patch più piccola che tocca solo i file il cui nome corrisponde a un particolare pattern di tipo glob. Leggete la <xref linkend="mq-collab:tips:interdiff"/> per un altro esempio.</para>
   1.579 +    <para id="x_430">Una volta che avete lavorato con le patch per un po', vi troverete desiderosi di utilizzare strumenti che vi aiutino a capire e manipolare le patch di cui vi state occupando.</para>
   1.580 +
   1.581 +    <para id="x_431">Il comando <command>diffstat</command> <citation>web:diffstat</citation> genera un istogramma delle modifiche effettuate a ogni file in una patch. Fornisce un buon modo per <quote>farsi un'idea</quote> di una patch&emdash;quali file coinvolge e quante modifiche introduce a ogni file e nell'insieme. (Trovo che sia una buona idea usare regolarmente l'opzione <option role="cmd-opt-diffstat">-p</option> di <command>diffstat</command>, poiché altrimenti il comando proverà a manipolare i prefissi dei nomi di file in un modo che almeno io trovo inevitabilmente confuso.)</para>
   1.582 +
   1.583 +    &interaction.mq.tools.tools;
   1.584 +
   1.585 +    <para id="x_432">Il pacchetto <literal role="package">patchutils</literal> <citation>web:patchutils</citation> è inestimabile. Fornisce un insieme di piccole utilità che seguono la <quote>filosofia Unix:</quote> ognuna effettua una singola operazione utile su una patch. Il comando di <literal role="package">patchutils</literal> che uso di più è <command>filterdiff</command>, che estrae sottoinsiemi di un file di patch. Per esempio, data una patch che modifica centinaia di file attraverso dozzine di directory, una singola invocazione di <command>filterdiff</command> può generare una patch più piccola che coinvolge solo i file il cui nome corrisponde a un particolare pattern di tipo glob. Leggete la <xref linkend="mq-collab:tips:interdiff"/> per un altro esempio.</para>
   1.586  
   1.587    </sect1>
   1.588    <sect1>
   1.589      <title>Strategie valide per lavorare con le patch</title>
   1.590  
   1.591 -    <para id="x_433">Sia che voi stiate lavorando su una serie di patch da sottoporre a un progetto software libero o open source, o su una serie che intendete trattare come una sequenza di normali changeset una volta che avete finito, potete usare alcune semplici tecniche per mantenere bene organizzato il vostro lavoro.</para>
   1.592 -
   1.593 -    <para id="x_434">Date nomi descrittivi alle vostre patch. Un buon nome per una patch potrebbe essere <filename>rework-device-alloc.patch</filename>, perché vi suggerirà immediatamente qual è lo scopo della patch. I nomi lunghi non dovrebbero essere un problema; non digiterete i nomi spesso, ma <emphasis>invocherete</emphasis> comandi come <command role="hg-ext-mq">qapplied</command> e <command role="hg-ext-mq">qtop</command> più e più volte. Una buona denominazione diventa particolarmente importante quando avete un certo numero di patch con cui lavorare, o se vi state destreggiando tra un certo numero di attività differenti e le vostre patch ottengono solo una frazione della vostra attenzione.</para>
   1.594 -
   1.595 -    <para id="x_435">Fate attenzione alle patch su cui state lavorando. Usate frequentemente il comando <command role="hg-ext-mq">qtop</command> e date un'occhiata al testo delle vostre patch&emdash;per esempio, usando <command role="hg-cmd">hg tip <option role="hg-opt-tip">-p</option></command>)&emdash;per assicurarvi di sapere dove vi trovate. Mi è capitato spesso di modificare e aggiornare una patch diversa da quella che intendevo, ed è spesso complicato trasferire le modifiche nella patch giusta dopo averle effettuate in quella sbagliata.</para>
   1.596 -
   1.597 -    <para id="x_436">Per questo motivo, vale davvero la pena di investire un po' di tempo per imparare a usare alcuni degli strumenti di terze parti che ho descritto nella <xref linkend="sec:mq:tools"/>, in particolare <command>diffstat</command> e <command>filterdiff</command>. Il primo vi darà velocemente un'idea di quali modifiche effettuerà la vostra patch, mentre il secondo vi renderà più facile #splice out# blocchi particolari di una patch e inserirli in un'altra.</para>
   1.598 -
   1.599 -  </sect1>
   1.600 -  <sect1>
   1.601 -    <title>MQ #cookbook#</title>
   1.602 +    <para id="x_433">Sia che stiate lavorando su una serie di patch da sottoporre a un progetto software libero od open source, o su una serie che intendete trattare come una sequenza di normali changeset una volta che avete finito, potete usare alcune semplici tecniche per mantenere bene organizzato il vostro lavoro.</para>
   1.603 +
   1.604 +    <para id="x_434">Date nomi descrittivi alle vostre patch. Un buon nome per una patch potrebbe essere <filename>rework-device-alloc.patch</filename>, perché vi suggerirà immediatamente qual è lo scopo della patch. I nomi lunghi non dovrebbero essere un problema: non digiterete i nomi spesso, ma <emphasis>invocherete</emphasis> comandi come <command role="hg-ext-mq">qapplied</command> e <command role="hg-ext-mq">qtop</command> più e più volte. Una buona denominazione diventa particolarmente importante quando state lavorando con un certo numero di patch, o se vi state destreggiando tra un certo numero di attività differenti e le vostre patch ottengono solo una frazione della vostra attenzione.</para>
   1.605 +
   1.606 +    <para id="x_435">Siate consapevoli della patch su cui state lavorando. Usate frequentemente il comando <command role="hg-ext-mq">qtop</command> e date un'occhiata al testo delle vostre patch&emdash;per esempio, usando <command role="hg-cmd">hg tip <option role="hg-opt-tip">-p</option></command>&emdash;per assicurarvi di sapere dove vi trovate. Mi è capitato molte volte di modificare e aggiornare una patch diversa da quella che intendevo, ed è spesso complicato trasferire le modifiche nella patch giusta dopo averle inserite in quella sbagliata.</para>
   1.607 +
   1.608 +    <para id="x_436">Per questo motivo, vale davvero la pena di investire un po' di tempo per imparare a usare alcuni degli strumenti di terze parti che ho descritto nella <xref linkend="sec:mq:tools"/>, in particolare <command>diffstat</command> e <command>filterdiff</command>. Il primo vi darà velocemente un'idea di quali sono le modifiche effettuate dalla vostra patch, mentre il secondo vi renderà più facile selezionare blocchi particolari di una patch e inserirli in un'altra.</para>
   1.609 +
   1.610 +  </sect1>
   1.611 +  <sect1>
   1.612 +    <title>Il ricettario di MQ</title>
   1.613  
   1.614      <sect2>
   1.615        <title>Gestire patch <quote>elementari</quote></title>
   1.616  
   1.617        <para id="x_437">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.</para>
   1.618  
   1.619 -      <para id="x_438">Cominciate con lo scaricare ed estrarre l'archivio dei sorgenti, trasformandoli in un repository Mercurial.</para>
   1.620 +      <para id="x_438">Cominciate con lo scaricare l'archivio dei sorgenti, estraendone i contenuti e trasformandoli in un repository Mercurial.</para>
   1.621  
   1.622        &interaction.mq.tarball.download;
   1.623  
   1.624 @@ -510,19 +509,19 @@
   1.625      <sect2 id="sec:mq:combine">
   1.626        <title>Combinare intere patch</title>
   1.627  
   1.628 -      <para id="x_43d">MQ vi fornisce il comando <command role="hg-ext-mq">qfold</command> per consentirvi di combinare intere patch. Questo comando <quote>include</quote> le patch che nominate, nell'ordine in cui le nominate, nella patch applicata in cima alla pila, e concatena le loro descrizioni alla fine della descrizione di questa patch. Le patch che includete non devono essere applicate prima di includerle.</para>
   1.629 -
   1.630 -      <para id="x_43e">L'ordine in cui includete le patch è importante. Se la vostra patch applicata in cima alla pila è <literal>foo</literal> e voi utilizzate <command role="hg-ext-mq">qfold</command> per includere <literal>bar</literal> e <literal>quux</literal> in essa, otterrete una patch che opererà come se aveste applicato prima <literal>foo</literal>, poi <literal>bar</literal>, seguito da <literal>quux</literal>.</para>
   1.631 -    </sect2>
   1.632 -
   1.633 -    <sect2>
   1.634 -      <title>Unire parte di una patch con un'altra</title>
   1.635 -
   1.636 -      <para id="x_43f">Unire <emphasis>parte</emphasis> di una patch con un'altra patch è più difficile che combinare intere patch.</para>
   1.637 -
   1.638 -      <para id="x_440">Se volete spostare cambiamenti a interi file, potete usare le opzioni <option role="cmd-opt-filterdiff">-i</option> e <option role="cmd-opt-filterdiff">-x</option> di <command>filterdiff</command> per scegliere le modifiche da ritagliare da una patch, aggiungendo il risultato del comando in coda alla patch con cui volete effettuare l'unione. Di solito non avrete bisogno di modificare la patch da cui prelevate le modifiche da unire. Piuttosto, MQ riporterà alcune parti rifiutate quando eseguite <command role="hg-ext-mq">qpush</command> su di essa (a causa dei blocchi che avete spostato nell'altra patch) e voi potrete semplicemente aggiornare la patch tramite <command role="hg-ext-mq">qrefresh</command> per scartare i blocchi duplicati.</para>
   1.639 -
   1.640 -      <para id="x_441">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 <command>lsdiff -nvv</command> per stampare alcuni metadati sulla patch.</para>
   1.641 +      <para id="x_43d">MQ vi fornisce il comando <command role="hg-ext-mq">qfold</command> per consentirvi di combinare intere patch. Questo comando <quote>include</quote> 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.</para>
   1.642 +
   1.643 +      <para id="x_43e">L'ordine in cui includete le patch è importante. Se la vostra ultima patch applicata è <literal>foo</literal> e voi utilizzate <command role="hg-ext-mq">qfold</command> per includervi <literal>bar</literal> e <literal>quux</literal>, otterrete una patch che opererà come se aveste applicato prima <literal>foo</literal>, poi <literal>bar</literal>, seguita da <literal>quux</literal>.</para>
   1.644 +    </sect2>
   1.645 +
   1.646 +    <sect2>
   1.647 +      <title>Unire parte di una patch a un'altra</title>
   1.648 +
   1.649 +      <para id="x_43f">Unire <emphasis>parte</emphasis> di una patch a un'altra patch è più difficile che combinare intere patch.</para>
   1.650 +
   1.651 +      <para id="x_440">Se volete spostare alcune modifiche su interi file, potete usare le opzioni <option role="cmd-opt-filterdiff">-i</option> e <option role="cmd-opt-filterdiff">-x</option> di <command>filterdiff</command> 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 <command role="hg-ext-mq">qpush</command> su di essa (a causa dei blocchi che avete spostato nell'altra patch) e voi potrete semplicemente aggiornare la patch tramite <command role="hg-ext-mq">qrefresh</command> per scartare i blocchi duplicati.</para>
   1.652 +
   1.653 +      <para id="x_441">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 <command>lsdiff -nvv</command> per stampare alcuni metadati sulla patch.</para>
   1.654  
   1.655        &interaction.mq.tools.lsdiff;
   1.656  
   1.657 @@ -536,7 +535,7 @@
   1.658  	</listitem>
   1.659        </itemizedlist>
   1.660  
   1.661 -      <para id="x_446">Dovrete ispezionare visivamente e leggere la patch per identificare i numeri di file e di blocco che volete, ma poi potrete passarli alle opzioni <option role="cmd-opt-filterdiff">--files</option> e <option role="cmd-opt-filterdiff">--hunks</option> di <command>filterdiff</command> per selezionare esattamente quel file e quel blocco che volete estrarre.</para>
   1.662 +      <para id="x_446">Dovrete leggere e ispezionare visivamente la patch per identificare i numeri di file e di blocco che volete, ma poi potrete passarli alle opzioni <option role="cmd-opt-filterdiff">--files</option> e <option role="cmd-opt-filterdiff">--hunks</option> di <command>filterdiff</command> per selezionare esattamente quel file e il blocco che volete estrarre.</para>
   1.663  
   1.664        <para id="x_447">Una volta che avete questo blocco, potete aggiungerlo in coda alla vostra patch di destinazione e continuare con il resto della <xref linkend="sec:mq:combine"/>.</para>
   1.665