1.1 --- a/it/ch12-mq.xml	Fri Aug 21 22:29:44 2009 +0200
     1.2 +++ b/it/ch12-mq.xml	Fri Aug 21 23:01:58 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>

     2.1 --- a/it/ch13-mq-collab.xml	Fri Aug 21 22:29:44 2009 +0200
     2.2 +++ b/it/ch13-mq-collab.xml	Fri Aug 21 23:01:58 2009 +0200
     2.3 @@ -6,10 +6,10 @@
     2.4  
     2.5    <para id="x_15e">In questo capitolo, userò come esempio una tecnica che ho impiegato per gestire lo sviluppo di un driver del kernel di Linux per un dispositivo Infiniband. Il driver in questione è grande (almeno per le dimensioni dei driver), poiché contiene 25.000 righe di codice distribuite su 35 file sorgente, e viene mantenuto da un piccolo gruppo di sviluppatori.</para>
     2.6  
     2.7 -  <para id="x_15f">Sebbene la maggior parte del materiale in questo capitolo sia specifica per Linux, gli stessi principi si applicano per qualsiasi base di codice di cui non siate i proprietari principali e su cui dobbiate fare parecchio lavoro.</para>
     2.8 -
     2.9 -  <sect1>
    2.10 -    <title>Il problema dei molti obiettivi</title>
    2.11 +  <para id="x_15f">Sebbene la maggior parte del materiale in questo capitolo sia specifica per Linux, gli stessi principi si applicano nel caso in cui dobbiate fare parecchio lavoro su una qualsiasi base di codice di cui non siete i proprietari principali.</para>
    2.12 +
    2.13 +  <sect1>
    2.14 +    <title>Il problema di gestire molti obiettivi</title>
    2.15  
    2.16      <para id="x_160">Il kernel di Linux cambia rapidamente e non è mai stato stabile internamente, in quanto gli sviluppatori effettuano frequentemente modifiche drastiche tra una release e l'altra. Questo significa che, di solito, una versione del driver che funziona bene con una particolare versione rilasciata del kernel non potrà nemmeno essere <emphasis>compilata</emphasis> correttamente su qualsiasi altra versione del kernel.</para>
    2.17  
    2.18 @@ -17,9 +17,9 @@
    2.19      <itemizedlist>
    2.20        <listitem><para id="x_162">Un obiettivo è l'albero di sviluppo principale del kernel di Linux. In questo caso, le attività di manutenzione del codice sono parzialmente condivise con altri sviluppatori della comunità del kernel, che effettuano modifiche <quote>estemporanee</quote> al driver man mano che sviluppano e rifiniscono i sottosistemi del kernel.</para>
    2.21        </listitem>
    2.22 -      <listitem><para id="x_163">Manteniamo anche un certo numero di <quote>backport</quote> (letteralmente, conversioni all'indietro) verso vecchie versioni del kernel di Linux, per soddisfare le necessità di clienti che stanno utilizzando distribuzioni di Linux più vecchie che non incorporano i nostri driver. (Effetuare il <emphasis>backport</emphasis> del codice significa modificarlo per farlo funzionare in una versione del suo ambiente di destinazione più vecchia di quella per la quale era stato sviluppato.)</para>
    2.23 -      </listitem>
    2.24 -      <listitem><para id="x_164">Infine, rilasciamo il software seguendo una tabella di marcia che non è necessariamente allineata con quella usata da chi sviluppa il kernel e da chi distribuisce il sistema operativo, in modo da poter consegnare nuove funzionalità ai clienti senza obbligarli ad aggiornare il loro kernel o la loro intera distribuzione.</para>
    2.25 +      <listitem><para id="x_163">Manteniamo anche un certo numero di <quote>backport</quote> (letteralmente, conversioni all'indietro) verso vecchie versioni del kernel di Linux, per soddisfare le necessità di clienti che stanno utilizzando distribuzioni di Linux più vecchie che non incorporano i nostri driver. (Effettuare il <emphasis>backport</emphasis> del codice significa modificarlo per farlo funzionare in una versione del suo ambiente di destinazione più vecchia di quella per la quale era stato sviluppato.)</para>
    2.26 +      </listitem>
    2.27 +      <listitem><para id="x_164">Infine, rilasciamo il software seguendo una tabella di marcia che non è necessariamente allineata con quella usata da chi sviluppa il kernel e da chi distribuisce il sistema operativo, in modo da poter consegnare nuove funzioni ai clienti senza obbligarli ad aggiornare il loro kernel o la loro intera distribuzione.</para>
    2.28        </listitem>
    2.29      </itemizedlist>
    2.30  
    2.31 @@ -28,7 +28,7 @@
    2.32  
    2.33        <para id="x_165">Ci sono due modi <quote>standard</quote> per mantenere un software che deve funzionare in molti ambienti diversi.</para>
    2.34  
    2.35 -      <para id="x_166">Il primo è mantenere un certo numero di rami, ognuno dedicato a un singolo ambiente. Il problema di questo approccio è che dovete mantenere una ferrea disciplina nel flusso dei cambiamenti tra i repository. Una nuova funzione o correzione di bug deve prendere vita in un repository <quote>intatto</quote>, poi passare a tutti i repository di backport. Le modifiche di backport dovrebbero propagarsi verso un numero di rami più limitato, in quanto l'applicazione di una modifica di backport su un ramo a cui non appartiene probabilmente impedirà al driver di essere compilato.</para>
    2.36 +      <para id="x_166">Il primo è mantenere un certo numero di rami, ognuno dedicato a un singolo obiettivo. Il problema di questo approccio è che dovete mantenere una ferrea disciplina nel flusso dei cambiamenti tra i repository. Una nuova funzione o correzione di bug deve prendere vita in un repository <quote>intatto</quote>, poi passare a tutti i repository di backport. Le modifiche di backport dovrebbero propagarsi verso un numero di rami più limitato, in quanto l'applicazione di una modifica di backport su un ramo a cui non appartiene probabilmente impedirà al driver di essere compilato.</para>
    2.37  
    2.38        <para id="x_167">Il secondo è quello di mantenere un singolo albero di sorgenti pieno di istruzioni condizionali che attivano o disattivano parti di codice a seconda dell'ambiente designato. Dato che queste istruzioni <quote>ifdef</quote> non sono permesse nell'albero del kernel di Linux, è necessario seguire una procedura manuale o automatica per eliminarle e produrre un albero pulito. Una base di codice mantenuta in questo modo diventa rapidamente un caos di blocchi condizionali che sono difficili da capire e mantenere.</para>
    2.39  
    2.40 @@ -135,7 +135,7 @@
    2.41  
    2.42      <para id="x_181">Poi scelgo una versione <quote>di base</quote> sulla quale le patch vengono applicate. Questa è una fotografia dell'albero del kernel di Linux scattata su una revisione di mia scelta. Quando scatto la fotografia, registro l'identificatore di changeset proveniente dal repository del kernel nel messaggio di commit. Dato che la fotografia mantiene la <quote>forma</quote> e il contenuto delle parti rilevanti dell'albero del kernel, posso applicare le mie patch sul mio repository ridotto o su un normale albero del kernel.</para>
    2.43  
    2.44 -    <para id="x_182">Normalmente, l'albero di base a cui applicare le patch dovrebbe essere una fotografia di un albero a monte molto recente. Questa è la condizione migliore per facilitare lo sviluppo di patch che possono essere presentate a monte con poche o addirittura nessuna modifica.</para>
    2.45 +    <para id="x_182">Normalmente, l'albero di base su cui applicare le patch dovrebbe essere una fotografia di un albero a monte molto recente. Questa è la condizione migliore per facilitare lo sviluppo di patch che possono essere presentate a monte con poche o addirittura nessuna modifica.</para>
    2.46  
    2.47    </sect1>
    2.48    <sect1>
    2.49 @@ -172,7 +172,7 @@
    2.50      <para id="x_18e">Nel mio lavoro, uso un certo numero di guardie per controllare quali patch devono essere applicate.</para>
    2.51  
    2.52      <itemizedlist>
    2.53 -      <listitem><para id="x_18f">Le patch <quote>accettate</quote> sono sorvegliate da <literal>accettate</literal>. Questa guardia è abilitata per la maggior parte del tempo. Quando sto applicando le patch su un albero dove le patch sono già presenti, posso disabilitare questa guardia così le patch che la seguono verranno applicate in maniera pulita.</para>
    2.54 +      <listitem><para id="x_18f">Le patch <quote>accettate</quote> sono sorvegliate da <literal>accettate</literal>. Questa guardia è abilitata per la maggior parte del tempo. Quando sto applicando le patch su un albero dove sono già presenti, posso disabilitare questa guardia così le patch che la seguono verranno applicate in maniera pulita.</para>
    2.55        </listitem>
    2.56        <listitem><para id="x_190">Le patch che sono <quote>terminate</quote>, ma non sono ancora state proposte, non hanno guardie. Se sto applicando la pila delle patch a una copia dell'albero a monte, non ho bisogno di abilitare alcuna guardia per ottenere un albero di sorgenti ragionevolmente sicuro.</para>
    2.57        </listitem>
    2.58 @@ -202,7 +202,7 @@
    2.59      <sect2>
    2.60        <title>Organizzare le patch in directory</title>
    2.61  
    2.62 -      <para id="x_198">Se state lavorando su un progetto considerevole con MQ, non è difficile accumulare un grande numero di patch. Per esempio, mi è capitato di avere un repository di patch contenente più di 250 patch.</para>
    2.63 +      <para id="x_198">Se state lavorando su un progetto di dimensioni considerevoli con MQ, non è difficile accumulare un grande numero di patch. Per esempio, mi è capitato di avere un repository di patch contenente più di 250 patch.</para>
    2.64  
    2.65        <para id="x_199">Se riuscite a raggruppare queste patch in categorie logiche separate, potete memorizzarle in directory differenti, in quanto MQ non ha problemi a usare nomi di patch che contengono separatori di percorso.</para>
    2.66  
    2.67 @@ -210,14 +210,14 @@
    2.68      <sect2 id="mq-collab:tips:interdiff">
    2.69        <title>Visualizzare la cronologia di una patch</title>
    2.70  
    2.71 -      <para id="x_19a">Se sviluppate un insieme di patch per un lungo periodo, è una buona idea mantenerle in un repository, come discusso nella <xref linkend="sec:mq:repo"/>. Se fate in questo modo, scoprirete velocemente che è impraticabile usare il comando <command role="hg-cmd">hg diff</command> per esaminare la cronolgia dei cambiamenti di una patch. In parte, questo succede perché state osservando la derivata seconda del codice reale (un diff di un diff), ma anche perché MQ aggiunge rumore al processo modificando le marcature temporali e i nomi di directory quando aggiorna una patch.</para>
    2.72 -
    2.73 -      <para id="x_19b">Tuttavia, potete usare l'estensione <literal role="hg-ext">extdiff</literal> inclusa in Mercurial per rendere leggibile il diff di due versioni di una patch. Per fare questo, avrete bisogno di un pacchetto di terze parti chiamato <literal role="package">patchutils</literal> <citation><xref linkend="bib:patchutils"/></citation>. Il pacchetto fornisce un comando chiamato <command>interdiff</command> che mostra le differenze tra due diff di un diff. Usato su due versioni dello stesso diff, genera un diff che rappresenta le differenze tra la prima e la seconda versione.</para>
    2.74 +      <para id="x_19a">Se sviluppate un insieme di patch per un lungo periodo, è una buona idea mantenerle in un repository, come discusso nella <xref linkend="sec:mq:repo"/>. Se fate in questo modo, scoprirete velocemente che è impraticabile usare il comando <command role="hg-cmd">hg diff</command> per esaminare la cronologia dei cambiamenti di una patch. In parte, questo succede perché state osservando la derivata seconda del codice reale (un diff di un diff), ma anche perché MQ aggiunge rumore al processo modificando le marcature temporali e i nomi di directory quando aggiorna una patch.</para>
    2.75 +
    2.76 +      <para id="x_19b">Tuttavia, potete usare l'estensione <literal role="hg-ext">extdiff</literal> inclusa in Mercurial per rendere leggibile il diff di due versioni di una patch. Per fare questo, avrete bisogno di un pacchetto di terze parti chiamato <literal role="package">patchutils</literal> <citation><xref linkend="bib:patchutils"/></citation>. Il pacchetto fornisce un comando chiamato <command>interdiff</command> che mostra le differenze tra due diff come un diff. Usato su due versioni dello stesso diff, genera un diff che rappresenta le differenze tra la prima e la seconda versione.</para>
    2.77  
    2.78        <para id="x_19c">Potete abilitare l'estensione <literal role="hg-ext">extdiff</literal> nel solito modo, aggiungendo una riga alla sezione <literal role="rc-extensions">extensions</literal> del vostro file <filename role="special">~/.hgrc</filename>.</para>
    2.79        <programlisting>[extensions]
    2.80  extdiff =</programlisting>
    2.81 -      <para id="x_19d">Il comando <command>interdiff</command> si aspetta che gli vengano passati i nomi di due file, ma l'estensione <literal role="hg-ext">extdiff</literal> passa una coppia di directory al programma che invoca, ognuna delle quali può contenere un numero arbitrario di file. Quindi abbiamo bisogno di un piccolo programma che invochi <command>interdiff</command> su ogni coppia di file in quelle due directory. Questo programma è disponibile sotto il nome di <filename role="special">hg-interdiff</filename> nella directory <filename class="directory">examples</filename> del repository di codice sorgente che accompagna questo libro.<footnote><para id="x_ffa">FIXME Where in the world is the file in that repository?</para></footnote></para>
    2.82 +      <para id="x_19d">Il comando <command>interdiff</command> si aspetta che gli vengano passati i nomi di due file, ma l'estensione <literal role="hg-ext">extdiff</literal> passa una coppia di directory al programma che invoca, ognuna delle quali può contenere un numero arbitrario di file. Quindi abbiamo bisogno di un piccolo programma che invochi <command>interdiff</command> su ogni coppia di file in quelle due directory. Questo programma è disponibile sotto il nome di <filename role="special">hg-interdiff</filename> nella directory <filename class="directory">contrib</filename> del repository di codice sorgente che accompagna questo libro.<footnote><para id="x_ffa">[NdT] Potete scaricare il programma <filename role="special">hg-interdiff</filename> dal <ulink role="hg-script" url="http://bitbucket.org/bos/hgbook/raw/tip/contrib/hg-interdiff">repository Mercurial del libro</ulink> ospitato su Bitbucket.</para></footnote></para>
    2.83  
    2.84        <para id="x_19e">Dopo aver incluso il programma <filename role="special">hg-interdiff</filename> nel percorso di ricerca della vostra shell, potete eseguirlo come segue, dall'interno di una directory di patch gestita da MQ:</para>
    2.85        <programlisting>hg extdiff -p hg-interdiff -r A:B mio-cambiamento.patch</programlisting>

     3.1 --- a/it/ch14-hgext.xml	Fri Aug 21 22:29:44 2009 +0200
     3.2 +++ b/it/ch14-hgext.xml	Fri Aug 21 23:01:58 2009 +0200
     3.3 @@ -15,10 +15,12 @@
     3.4    </itemizedlist>
     3.5  
     3.6    <para id="x_503">In questo capitolo, parleremo di alcune delle altre estensioni disponibili per Mercurial e tratteremo brevemente alcuni dei meccanismi che avrete bisogno di conoscere se volete scrivere le vostre estensioni.</para>
     3.7 +  <!--
     3.8    <itemizedlist>
     3.9      <listitem><para id="x_504">Nella <xref linkend="sec:hgext:inotify"/>, discuteremo la possibilità di <emphasis>enormi</emphasis> miglioramenti delle prestazioni tramite l'uso dell'estensione <literal role="hg-ext">inotify</literal>.</para>
    3.10      </listitem>
    3.11    </itemizedlist>
    3.12 +  -->
    3.13  
    3.14    <sect1 id="sec:hgext:inotify">
    3.15      <title>Migliorare le prestazioni con l'estensione <literal role="hg-ext">inotify</literal></title>
    3.16 @@ -33,7 +35,7 @@
    3.17  
    3.18      <para id="x_509">Molti sistemi operativi moderni contengono utilità di notifica per i file. Se un programma si registra al servizio appropriato, il sistema operativo lo avvertirà ogni volta che un file di interesse viene creato, modificato, o cancellato. Sui sistemi Linux, il componente del kernel che si occupa di questa funzione si chiama <literal>inotify</literal>.</para>
    3.19  
    3.20 -    <para id="x_50a">L'estensione <literal role="hg-ext">inotify</literal> di Mercurial interagisce con il componente <literal>inotify</literal> per ottimizzare l'esecuzione di <command role="hg-cmd">hg status</command>. Questa estensione ha due componenti. Un demone viene eseguito in background e riceve le notifiche dal sottosistema <literal>inotify</literal>, accettando connessioni anche dai normali comandi Mercurial. L'estensione modifica il comportamento di Mercurial in modo che, invece di esaminare il file system, interroghi il demone. Dato che il demone possiede informazioni esatte sullo stato del repository, può rispondere istantaneamente con un risultato, evitando il bisogno di esaminare tutti i file e le directory nel repository.</para>
    3.21 +    <para id="x_50a">L'estensione <literal role="hg-ext">inotify</literal> di Mercurial interagisce con il componente <literal>inotify</literal> per ottimizzare l'esecuzione di <command role="hg-cmd">hg status</command>. Questa estensione ha due componenti. Un demone viene eseguito in background e riceve le notifiche dal sottosistema <literal>inotify</literal>, accettando connessioni anche dai normali comandi Mercurial. L'estensione modifica il comportamento di Mercurial in modo che, invece di esaminare il file system, interroghi il demone. Dato che il demone possiede informazioni esatte sullo stato del repository, può rispondere istantaneamente con un risultato, senza dover esaminare tutti i file e le directory nel repository.</para>
    3.22  
    3.23      <para id="x_50b">Ricordate i dieci secondi che ho misurato come il tempo impiegato dal solo Mercurial per eseguire <command role="hg-cmd">hg status</command> su un repository di 150.000 file? Con l'estensione <literal role="hg-ext">inotify</literal> abilitata, il tempo è sceso a 0.1 secondi, più veloce di un fattore <emphasis>cento</emphasis>.</para>
    3.24  
    3.25 @@ -46,7 +48,7 @@
    3.26        <listitem><para id="x_50f">Non tutti i file system sono adatti per essere usati con l'estensione <literal role="hg-ext">inotify</literal>. I file system di rete come NFS sono fuori gioco, per esempio, in particolare se state eseguendo Mercurial su diversi sistemi che montano lo stesso file system di rete. Il sistema <literal>inotify</literal> del kernel non ha alcun modo di sapere quali cambiamenti sono avvenuti su un altro sistema. La maggior parte dei file system locali (e.g. ext3, XFS, ReiserFS) dovrebbe andare bene.</para>
    3.27        </listitem></itemizedlist>
    3.28  
    3.29 -    <para id="x_510">A maggio 2007,<!--<footnote><para id="x_ffd">FIXME The <literal role="hg-ext">inotify</literal> extension is bundled with Mercurial since Mercurial 1.0!</para></footnote>--> l'estensione <literal role="hg-ext">inotify</literal> non viene ancora distribuita con Mercurial, quindi è un po' più complicata da installare rispetto ad altre estensioni. Ma il miglioramento delle prestazioni ne vale la pena!</para>
    3.30 +    <para id="x_510">A maggio 2007,<footnote><para id="x_ffd">FIXME The <literal role="hg-ext">inotify</literal> extension is bundled with Mercurial since Mercurial 1.0!</para></footnote> l'estensione <literal role="hg-ext">inotify</literal> non viene ancora distribuita con Mercurial, quindi è un po' più complicata da installare rispetto ad altre estensioni. Ma il miglioramento delle prestazioni ne vale la pena!</para>
    3.31  
    3.32      <para id="x_511">Attualmente, l'estensione è divisa in due parti: un insieme di patch al codice sorgente di Mercurial e una libreria di interfaccia Python al sottosistema <literal>inotify</literal>.</para>
    3.33      <note>
    3.34 @@ -164,7 +166,7 @@
    3.35  
    3.36      <para id="x_532">Grazie alla sua estensione <literal role="hg-ext">patchbomb</literal>, Mercurial facilita l'invio di email contenenti modifiche da rivedere o applicare. L'estensione è chiamata così perché le modifiche vengono inviate in forma di patch e solitamente viene inviato un singolo changeset per ogni messaggio email. Quindi, inviare una lunga serie di cambiamenti via email è molto simile a <quote>bombardare</quote> la casella del ricevente, da cui il nome <quote>patchbomb</quote>.</para>
    3.37  
    3.38 -    <para id="x_533">Come al solito, la configurazione di base dell'estensione <literal role="hg-ext">patchbomb</literal> occupa solo una o due righe del vostro file <filename role="special">/.hgrc</filename>.</para>
    3.39 +    <para id="x_533">Come al solito, la configurazione di base dell'estensione <literal role="hg-ext">patchbomb</literal> occupa solo una o due righe del vostro file <filename role="special">~/.hgrc</filename>.</para>
    3.40      <programlisting>[extensions]
    3.41  patchbomb =</programlisting>
    3.42      <para id="x_534">Una volta che avete abilitato l'estensione, avrete a disposizione un nuovo comando chiamato <command role="hg-ext-patchbomb">email</command>.</para>
    3.43 @@ -186,9 +188,9 @@
    3.44  
    3.45        <para id="x_53b">Non tutti i progetti hanno esattamente le stesse convenzioni per spedire cambiamenti via email, così l'estensione <literal role="hg-ext">patchbomb</literal> prova a fornire un certo numero di variazioni attraverso le opzioni a riga di comando.</para>
    3.46        <itemizedlist>
    3.47 -	<listitem><para id="x_53c">Potete scrivere un oggetto per il messaggio introduttivo sulla riga di comando usando l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-s</option>. Questa opzione accetta un argomento, il testo da usare per l'oggetto.</para>
    3.48 -	</listitem>
    3.49 -	<listitem><para id="x_53d">Per cambiare l'indirizzo email da cui vengono spediti i messaggi usate l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-f</option>. Questa opzione accetta un argomento, l'indirizzo email da usare.</para>
    3.50 +	<listitem><para id="x_53c">Potete scrivere un oggetto per il messaggio introduttivo sulla riga di comando usando l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-s</option>. Questa opzione accetta come argomento il testo da usare per l'oggetto.</para>
    3.51 +	</listitem>
    3.52 +	<listitem><para id="x_53d">Per cambiare l'indirizzo email da cui vengono spediti i messaggi usate l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-f</option>. Questa opzione accetta come argomento l'indirizzo email da usare.</para>
    3.53  	</listitem>
    3.54  	<listitem><para id="x_53e">Il comportamento predefinito è quello di inviare diff unificati (leggete la <xref linkend="sec:mq:patch"/> per una descrizione del formato), uno per ogni messaggio. Potete invece usare l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-b</option> per inviare un bundle eseguibile.</para>
    3.55  	</listitem>
    3.56 @@ -196,7 +198,7 @@
    3.57  	</listitem>
    3.58  	<listitem><para id="x_540">I diff vengono normalmente spediti <quote>in linea</quote>, nella stessa parte del corpo che contiene la descrizione della patch. Questo è il modo più facile per consentire al più ampio numero di lettori di rispondere citando parti di un diff, dato che alcuni client email citeranno soltanto la prima parte MIME del corpo di un messaggio. Se preferite inviare la descrizione e il diff in parti separate del corpo, usate l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-a</option>.</para>
    3.59  	</listitem>
    3.60 -	<listitem><para id="x_541">Invece di spedire messaggi email, potete salvarli in una cartella email in formato <literal>mbox</literal> usando l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-m</option>. Questa opzione accetta un argomento, il nome del file su cui scrivere.</para>
    3.61 +	<listitem><para id="x_541">Invece di spedire messaggi email, potete salvarli in una cartella email in formato <literal>mbox</literal> usando l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-m</option>. Questa opzione accetta come argomento il nome del file su cui scrivere.</para>
    3.62  	</listitem>
    3.63  	<listitem><para id="x_542">Se preferite aggiungere un riepilogo nel formato del comando <command>diffstat</command> a ogni patch e uno al messaggio introduttivo, usate l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-d</option>. Il comando <command>diffstat</command> mostra una tabella contenente il nome di ogni file coinvolto nella patch, il numero di righe modificate e un istogramma che illustra quante modifiche sono state apportate a ogni file. Questo riepilogo offre a chi legge una visione qualitativa della complessità di una patch.</para>
    3.64  	</listitem>

     4.1 --- a/it/examples/mq.id.output.it	Fri Aug 21 22:29:44 2009 +0200
     4.2 +++ b/it/examples/mq.id.output.it	Fri Aug 21 23:01:58 2009 +0200
     4.3 @@ -4,19 +4,19 @@
     4.4  seconda.patch
     4.5  <prompt>$</prompt> <userinput>hg log -r qbase:qtip</userinput>
     4.6  changeset:   1:32b3cae9e753
     4.7 -tag:         prima.patch
     4.8 -tag:         qbase
     4.9 -user:        Bryan O'Sullivan &lt;bos@serpentine.com&gt;
    4.10 -date:        Fri Jun 05 15:50:45 2009 +0000
    4.11 -summary:     [mq]: prima.patch
    4.12 +etichetta:   prima.patch
    4.13 +etichetta:   qbase
    4.14 +utente:      Bryan O'Sullivan &lt;bos@serpentine.com&gt;
    4.15 +data:        Fri Jun 05 15:50:45 2009 +0000
    4.16 +sommario:    [mq]: prima.patch
    4.17  
    4.18  changeset:   2:dee839d89dc6
    4.19 -tag:         qtip
    4.20 -tag:         seconda.patch
    4.21 -tag:         tip
    4.22 -user:        Bryan O'Sullivan &lt;bos@serpentine.com&gt;
    4.23 -date:        Fri Jun 05 15:50:46 2009 +0000
    4.24 -summary:     [mq]: seconda.patch
    4.25 +etichetta:   qtip
    4.26 +etichetta:   seconda.patch
    4.27 +etichetta:   tip
    4.28 +utente:      Bryan O'Sullivan &lt;bos@serpentine.com&gt;
    4.29 +data:        Fri Jun 05 15:50:46 2009 +0000
    4.30 +sommario:    [mq]: seconda.patch
    4.31  
    4.32  <prompt>$</prompt> <userinput>hg export seconda.patch</userinput>
    4.33  # HG changeset di patch

     5.1 --- a/it/examples/mq.qinit-help.help.it	Fri Aug 21 22:29:44 2009 +0200
     5.2 +++ b/it/examples/mq.qinit-help.help.it	Fri Aug 21 23:01:58 2009 +0200
     5.3 @@ -4,12 +4,12 @@
     5.4  
     5.5  inizializza un nuovo repository di coda
     5.6  
     5.7 -    Per default, il repository di coda non è sotto controllo di
     5.8 -    versione. Se viene specificato -c, qinit creerà un repository
     5.9 -    annidato separato per le patch (qinit -c può anche essere
    5.10 -    invocato più tardi per convertire un repository di patch non
    5.11 -    gestito in uno gestito). Potete usare qcommit per inserire
    5.12 -    modifiche in questo repository di coda.
    5.13 +    Per default, il repository di coda non è sotto controllo
    5.14 +    di revisione. Se viene specificato -c, qinit creerà un
    5.15 +    repository annidato separato per le patch (qinit -c può
    5.16 +    anche essere invocato più tardi per convertire un repository
    5.17 +    di patch non gestito in uno gestito). Potete usare qcommit
    5.18 +    per inserire modifiche in questo repository di coda.
    5.19  
    5.20  opzioni:
    5.21  

     6.1 --- a/it/examples/mq.tarball.download.it	Fri Aug 21 22:29:44 2009 +0200
     6.2 +++ b/it/examples/mq.tarball.download.it	Fri Aug 21 23:01:58 2009 +0200
     6.3 @@ -1,5 +1,5 @@
     6.4  <!-- BEGIN mq.tarball.download -->
     6.5 -<screen><prompt>$</prompt> <userinput>download netplug-1.2.5.tar.bz2</userinput>
     6.6 +<screen># Scarichiamo netplug-1.2.5.tar.bz2
     6.7  <prompt>$</prompt> <userinput>tar jxf netplug-1.2.5.tar.bz2</userinput>
     6.8  <prompt>$</prompt> <userinput>cd netplug-1.2.5</userinput>
     6.9  <prompt>$</prompt> <userinput>hg init</userinput>

     7.1 --- a/it/examples/mq.tarball.newsource.it	Fri Aug 21 22:29:44 2009 +0200
     7.2 +++ b/it/examples/mq.tarball.newsource.it	Fri Aug 21 23:01:58 2009 +0200
     7.3 @@ -2,7 +2,7 @@
     7.4  <screen><prompt>$</prompt> <userinput>hg qpop -a</userinput>
     7.5  la coda delle patch è vuota
     7.6  <prompt>$</prompt> <userinput>cd ..</userinput>
     7.7 -<prompt>$</prompt> <userinput>download netplug-1.2.8.tar.bz2</userinput>
     7.8 +# Scarichiamo netplug-1.2.8.tar.bz2
     7.9  <prompt>$</prompt> <userinput>hg clone netplug-1.2.5 netplug-1.2.8</userinput>
    7.10  aggiorno la directory di lavoro
    7.11  18 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti

     8.1 --- a/it/examples/mq.tarball.qinit.it	Fri Aug 21 22:29:44 2009 +0200
     8.2 +++ b/it/examples/mq.tarball.qinit.it	Fri Aug 21 23:01:58 2009 +0200
     8.3 @@ -6,13 +6,13 @@
     8.4  <prompt>$</prompt> <userinput>hg qrefresh</userinput>
     8.5  <prompt>$</prompt> <userinput>hg tip -p</userinput>
     8.6  changeset:   1:5227ba4b6a8b
     8.7 -tag:         qtip
     8.8 -tag:         correzione-assemblaggio.patch
     8.9 -tag:         tip
    8.10 -tag:         qbase
    8.11 -user:        Bryan O'Sullivan &lt;bos@serpentine.com&gt;
    8.12 -date:        Fri Jun 05 15:50:51 2009 +0000
    8.13 -summary:     corregge un problema di assemblaggio con gcc 4
    8.14 +etichetta:   qtip
    8.15 +etichetta:   correzione-assemblaggio.patch
    8.16 +etichetta:   tip
    8.17 +etichetta:   qbase
    8.18 +utente:      Bryan O'Sullivan &lt;bos@serpentine.com&gt;
    8.19 +data:        Fri Jun 05 15:50:51 2009 +0000
    8.20 +sommario:    corregge un problema di assemblaggio con gcc 4
    8.21  
    8.22  diff -r e709896f2959 -r 5227ba4b6a8b netlink.c
    8.23  --- a/netlink.c	Fri Jun 05 15:50:49 2009 +0000

     9.1 --- a/it/examples/mq.tutorial.qnew.it	Fri Aug 21 22:29:44 2009 +0200
     9.2 +++ b/it/examples/mq.tutorial.qnew.it	Fri Aug 21 23:01:58 2009 +0200
     9.3 @@ -1,21 +1,21 @@
     9.4  <!-- BEGIN mq.tutorial.qnew -->
     9.5  <screen><prompt>$</prompt> <userinput>hg tip</userinput>
     9.6  changeset:   0:c6618fa9eed7
     9.7 -tag:         tip
     9.8 -user:        Bryan O'Sullivan &lt;bos@serpentine.com&gt;
     9.9 -date:        Fri Jun 05 15:50:56 2009 +0000
    9.10 -summary:     Prima modifica.
    9.11 +etichetta:   tip
    9.12 +utente:      Bryan O'Sullivan &lt;bos@serpentine.com&gt;
    9.13 +data:        Fri Jun 05 15:50:56 2009 +0000
    9.14 +sommario:    Prima modifica.
    9.15  
    9.16  <prompt>$</prompt> <userinput>hg qnew prima.patch</userinput>
    9.17  <prompt>$</prompt> <userinput>hg tip</userinput>
    9.18  changeset:   1:f32697f1a94e
    9.19 -tag:         qtip
    9.20 -tag:         prima.patch
    9.21 -tag:         tip
    9.22 -tag:         qbase
    9.23 -user:        Bryan O'Sullivan &lt;bos@serpentine.com&gt;
    9.24 -date:        Fri Jun 05 15:50:57 2009 +0000
    9.25 -summary:     [mq]: prima.patch
    9.26 +etichetta:   qtip
    9.27 +etichetta:   prima.patch
    9.28 +etichetta:   tip
    9.29 +etichetta:   qbase
    9.30 +utente:      Bryan O'Sullivan &lt;bos@serpentine.com&gt;
    9.31 +data:        Fri Jun 05 15:50:57 2009 +0000
    9.32 +sommario:    [mq]: prima.patch
    9.33  
    9.34  <prompt>$</prompt> <userinput>ls .hg/patches</userinput>
    9.35  prima.patch  series  status

    10.1 --- a/it/examples/mq.tutorial.qrefresh2.it	Fri Aug 21 22:29:44 2009 +0200
    10.2 +++ b/it/examples/mq.tutorial.qrefresh2.it	Fri Aug 21 23:01:58 2009 +0200
    10.3 @@ -11,7 +11,7 @@
    10.4  --- a/file1	Fri Jun 05 15:50:56 2009 +0000
    10.5  +++ b/file1	Fri Jun 05 15:51:00 2009 +0000
    10.6  @@ -1,1 +1,3 @@
    10.7 - line 1
    10.8 + riga 1
    10.9  +riga 2
   10.10  +riga 3
   10.11