1.1 --- a/it/ch12-mq.xml	Mon Aug 17 01:53:50 2009 +0200
     1.2 +++ b/it/ch12-mq.xml	Sat Aug 22 17:00:08 2009 +0200
     1.3 @@ -11,7 +11,7 @@
     1.4  
     1.5      <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.6  
     1.7 -    <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.8 +    <para id="x_3af">Chi distribuisce sistemi operativi che includono software open source ha spesso bisogno di effettuare modifiche ai pacchetti distribuiti in modo da assemblarli correttamente nel proprio ambiente.</para>
     1.9  
    1.10      <para id="x_3b0">Quando dovete mantenere solo alcune modifiche, 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 proponete 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.11  
    1.12 @@ -177,7 +177,7 @@
    1.13  
    1.14        &interaction.mq.tutorial.qpop;
    1.15  
    1.16 -      <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.17 +      <para id="x_3df">Notate che, dopo aver estratto una patch o due patch, il risultato di <command role="hg-ext-mq">qseries</command> è rimasto lo stesso, mentre quello di <command role="hg-ext-mq">qapplied</command> è cambiato.</para>
    1.18  
    1.19      </sect2>
    1.20  
    1.21 @@ -196,7 +196,7 @@
    1.22  
    1.23        &interaction.mq.tutorial.add;
    1.24  
    1.25 -      <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 coinvolto dalla patch che sta estraendo. Assicuratevi di leggere la documentazione per l'opzione <option>-f</option> di un comando prima di usarla!</para>
    1.26 +      <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 -f</command> incorporerà i cambiamenti in sospeso nella nuova patch creata, ma <command role="hg-cmd">hg qpop -f</command> annullerà le modifiche a qualsiasi file coinvolto dalla patch che sta estraendo. Assicuratevi di leggere la documentazione per l'opzione <option>-f</option> di un comando prima di usarla!</para>
    1.27      </sect2>
    1.28  
    1.29      <sect2>
    1.30 @@ -204,7 +204,7 @@
    1.31  
    1.32        <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>questa</emphasis> patch per un po'.</para>
    1.33  
    1.34 -      <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.35 +      <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 poter operare sulla 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.36      </sect2>
    1.37    </sect1>
    1.38  
    1.39 @@ -267,7 +267,7 @@
    1.40  
    1.41        <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.42  
    1.43 -      <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.44 +      <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 precisa. 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.45      </sect2>
    1.46  
    1.47      <sect2>
    1.48 @@ -331,11 +331,11 @@
    1.49  
    1.50      <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.51  
    1.52 -    <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.53 +    <para id="x_404">Sul mio vecchio e lento portatile, sono riuscito a eseguire <command role="hg-cmd">hg qpush -a</command> per tutte le 1.738 patch in 3.5 minuti e a eseguire <command role="hg-cmd">hg qpop -a</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.54  
    1.55      <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.56  
    1.57 -    <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.58 +    <para id="x_406">Prima di tutto, provate a <quote>raggruppare</quote> insieme le operazioni. Quando 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.59  
    1.60      <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.61  
    1.62 @@ -347,7 +347,7 @@
    1.63  
    1.64      <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.65  
    1.66 -    <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.67 +    <para id="x_40a">Il modo più semplice per eseguire questa operazione è quello di usare <command role="hg-cmd">hg qpop -a</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 -a</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.68  
    1.69      <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.70  
    1.71 @@ -357,16 +357,16 @@
    1.72      <orderedlist>
    1.73        <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.74        </listitem>
    1.75 -      <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.76 +      <listitem><para id="x_40f">Salvate una copia di backup della vostra directory delle patch usando <command role="hg-cmd">hg qsave -e -c</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.77        </listitem>
    1.78        <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.79        </listitem>
    1.80 -      <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.81 +      <listitem><para id="x_411">Aggiornate la directory di lavoro alla nuova revisione di punta, usando <command role="hg-cmd">hg update -C</command> per sovrascrivere le modifiche apportate dalle patch che avete inserito.</para>
    1.82        </listitem>
    1.83        <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.84        </listitem></orderedlist>
    1.85  
    1.86 -    <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 operazione sfrutta il normale meccanismo di unione di Mercurial, quindi potrebbe aprire uno strumento grafico di unione in modo da aiutarvi a risolvere i problemi.</para>
    1.87 +    <para id="x_413">Durante l'esecuzione di <command role="hg-cmd">hg qpush -m</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 operazione sfrutta il normale meccanismo di unione di Mercurial, quindi potrebbe aprire uno strumento grafico di unione in modo da aiutarvi a risolvere i problemi.</para>
    1.88  
    1.89      <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.90  
    1.91 @@ -420,7 +420,7 @@
    1.92  
    1.93      <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.94  
    1.95 -    <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.96 +    <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', aggiornarla 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.97  
    1.98      <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.99  
   1.100 @@ -432,7 +432,7 @@
   1.101        <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 repository Mercurial.</para>
   1.102  
   1.103        <note>
   1.104 -	<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> lo fa automaticamente per voi), perché il file <filename role="special">status</filename> non andrebbe <emphasis>davvero</emphasis> amministrato.</para>
   1.105 +	<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 -c</command> lo fa automaticamente per voi), perché il file <filename role="special">status</filename> non andrebbe <emphasis>davvero</emphasis> amministrato.</para>
   1.106        </note>
   1.107  
   1.108        <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.109 @@ -451,7 +451,7 @@
   1.110  
   1.111        <para id="x_42e">Il supporto di MQ per lavorare con un repository pieno di patch è limitato in alcuni aspetti di dettaglio.</para>
   1.112  
   1.113 -      <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, potreste confondere le idee a MQ in merito a quali patch sono state effettivamente applicate.</para>
   1.114 +      <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 -a</command> e poi <command role="hg-cmd">hg qpush -a</command> nel repository sottostante per fare in modo che quelle modifiche compaiano anche là. Se dimenticate di fare questo, potreste confondere le idee a MQ in merito a quali patch sono state effettivamente applicate.</para>
   1.115  
   1.116      </sect2>
   1.117    </sect1>
   1.118 @@ -470,11 +470,11 @@
   1.119    <sect1>
   1.120      <title>Strategie valide per lavorare con le patch</title>
   1.121  
   1.122 -    <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.123 +    <para id="x_433">Sia che stiate lavorando su una serie di patch da sottoporre a un progetto software libero od open source, oppure 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.124  
   1.125      <para id="x_434">Date nomi descrittivi alle vostre patch. Un buon nome per una patch potrebbe essere <filename>riorganizza-allocazione-dispositivi.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.126  
   1.127 -    <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.128 +    <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 -p</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.129  
   1.130      <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.131  
   1.132 @@ -529,7 +529,7 @@
   1.133        <itemizedlist>
   1.134  	<listitem><para id="x_443">(nella prima colonna) un <emphasis>numero di file</emphasis> per identificare ogni file modificato dalla patch;</para>
   1.135  	</listitem>
   1.136 -	<listitem><para id="x_444">(sulla riga seguente, indentato) il numero di riga del file modificato dove comincia il blocco; e</para>
   1.137 +	<listitem><para id="x_444">(sulla riga seguente, indentato) il numero di riga del file modificato dove comincia il blocco;</para>
   1.138  	</listitem>
   1.139  	<listitem><para id="x_445">(sulla stessa riga) un <emphasis>numero di blocco</emphasis> per identificare quel blocco.</para>
   1.140  	</listitem>