1.1 --- a/it/ch01-intro.xml	Fri Jul 31 23:27:41 2009 +0200
     1.2 +++ b/it/ch01-intro.xml	Fri Jul 31 23:39:38 2009 +0200
     1.3 @@ -21,7 +21,7 @@
     1.4        <itemizedlist>
     1.5  	<listitem><para id="x_72">Terrà traccia della storia e dell'evoluzione del vostro progetto, così voi non dovete farlo. Per ogni modifica, registrerà informazioni riguardanti <emphasis>chi</emphasis> l'ha fatta, <emphasis>perché</emphasis> l'ha fatta, <emphasis>quando</emphasis> è stata fatta e <emphasis>cosa</emphasis> è stato modificato.</para></listitem>
     1.6  	<listitem><para id="x_73">Quando state lavorando con altre persone, il software per il controllo di revisione facilita la collaborazione. Per esempio, quando due persone effettuano cambiamenti incompatibili più o meno simultaneamente, il software vi aiuterà a identificare e risolvere questi conflitti.</para></listitem>
     1.7 -	<listitem><para id="x_74">Può aiutarvi a rettificare i vostri errori. Se fate una modifica che più tardi si rivela essere un errore, potete ritornare a una versione precedente di uno o più file. In effetti, uno strumento di controllo di revisione <emphasis>davvero</emphasis> buono vi aiuterà a calcolare efficientemente il momento esatto in cui un problema è stato introdotto (si veda FIXME <!--<xref linkend="sec:undo:bisect"/>--> per i dettagli).</para></listitem>
     1.8 +	<listitem><para id="x_74">Può aiutarvi a rettificare i vostri errori. Se fate una modifica che più tardi si rivela essere un errore, potete ritornare a una versione precedente di uno o più file. In effetti, uno strumento di controllo di revisione <emphasis>davvero</emphasis> buono vi aiuterà a calcolare efficientemente il momento esatto in cui un problema è stato introdotto (si veda la <xref linkend="sec:undo:bisect"/> per i dettagli).</para></listitem>
     1.9  	<listitem><para id="x_75">Vi aiuterà a lavorare simultaneamente su molteplici versioni del vostro progetto e a gestire gli spostamenti tra una versione e l'altra.</para></listitem>
    1.10        </itemizedlist>
    1.11  
    1.12 @@ -64,7 +64,7 @@
    1.13  
    1.14      <para id="x_86">C'è un piccolo svantaggio in questo approccio, cioè che le date e gli orari che vedete negli esempi tendono a venire <quote>compressi</quote> insieme in modo anomalo, diversamente da quanto accadrebbe se gli stessi comandi fossero digitati da un essere umano. Laddove un essere umano non può inviare più di un comando ogni pochi secondi, le cui marcature temporali sarebbero analogamente intervallate, i miei script d'esempio automatizzati sono in grado di eseguire molti comandi in un secondo.</para>
    1.15  
    1.16 -    <para id="x_87">Come conseguenza di questo fatto, potrebbe sembrare che molti inserimenti (commit) consecutivi vengano eseguiti durante lo stesso secondo. Potete osservare la presenza di questa anomalia nell'esempio di <literal role="hg-ext">bisezione</literal> in FIXME <!--<xref linkend="sec:undo:bisect"/>-->, tanto per farvi un'idea.</para>
    1.17 +    <para id="x_87">Come conseguenza di questo fatto, potrebbe sembrare che molti inserimenti (commit) consecutivi vengano eseguiti durante lo stesso secondo. Potete osservare la presenza di questa anomalia nell'esempio di <literal role="hg-ext">bisect</literal> nella <xref linkend="sec:undo:bisect"/>, tanto per farvi un'idea.</para>
    1.18  
    1.19      <para id="x_88">Quindi, mentre leggete gli esempi, non date troppo peso alle date e agli orari che vedete nell'uscita dei comandi, ma potete <emphasis>decisamente</emphasis> fare affidamento sulla consistenza e riproducibilità del comportamento illustrato.</para>
    1.20  

     2.1 --- a/it/ch02-tour-basic.xml	Fri Jul 31 23:27:41 2009 +0200
     2.2 +++ b/it/ch02-tour-basic.xml	Fri Jul 31 23:39:38 2009 +0200
     2.3 @@ -177,8 +177,7 @@
     2.4  
     2.5        &interaction.tour.log-v;
     2.6  
     2.7 -      <para id="x_2f">Se volete vedere sia la descrizione che il contenuto di un cambiamento, aggiungete l'opzione <option role="hg-opt-log">-p</option> (o <option role="hg-opt-log">--patch</option>). In questo modo il contenuto del cambiamento verrà stampato in formato <emphasis>unified diff</emphasis> (se non avete mai visto il formato unified diff prima d'ora, date un'occhiata a <!--<xref
     2.8 -	  linkend="sec:mq:patch"/>--> FIXME per un'introduzione).</para>
     2.9 +      <para id="x_2f">Se volete vedere sia la descrizione che il contenuto di un cambiamento, aggiungete l'opzione <option role="hg-opt-log">-p</option> (o <option role="hg-opt-log">--patch</option>). In questo modo il contenuto del cambiamento verrà stampato in formato <emphasis>unified diff</emphasis> (se non avete mai visto il formato unified diff prima d'ora, date un'occhiata alla <xref linkend="sec:mq:patch"/> per un'introduzione).</para>
    2.10  
    2.11        &interaction.tour.log-vp;
    2.12  
    2.13 @@ -259,8 +258,7 @@
    2.14      <tip>
    2.15        <title>Capire le patch</title>
    2.16  
    2.17 -      <para id="x_683">Ricordate di dare un'occhiata a <!--<xref
    2.18 -	  linkend="sec:mq:patch"/>--> FIXME se non sapete come interpretare il risultato del comando eseguito sopra.</para>
    2.19 +      <para id="x_683">Ricordate di dare un'occhiata alla <xref linkend="sec:mq:patch"/> se non sapete come interpretare il risultato del comando eseguito sopra.</para>
    2.20      </tip>
    2.21    </sect1>
    2.22    <sect1>

     3.1 --- a/it/ch03-tour-merge.xml	Fri Jul 31 23:27:41 2009 +0200
     3.2 +++ b/it/ch03-tour-merge.xml	Fri Jul 31 23:39:38 2009 +0200
     3.3 @@ -229,6 +229,6 @@
     3.4  	<para id="x_72b">Se siete utenti Unix, sarete contenti di sapere che il comando <command>hg rename</command> si può abbreviare in <command>hg mv</command>.</para>
     3.5      </footnote> per cambiarne il nome, in modo che Mercurial possa comportarsi in maniera appropriata nel caso più tardi effettuassimo un'unione.</para>
     3.6  
     3.7 -    <para id="x_72c">Tratteremo l'uso di questi comandi in maniera più estesa nel FIXME<!--<xref linkend="chap:daily.copy"/>-->.</para>
     3.8 +    <para id="x_72c">Tratteremo l'uso di questi comandi in maniera più estesa nel <xref linkend="chap:daily.copy"/>.</para>
     3.9    </sect1>
    3.10  </chapter>

     4.1 --- a/it/ch05-daily.xml	Fri Jul 31 23:27:41 2009 +0200
     4.2 +++ b/it/ch05-daily.xml	Fri Jul 31 23:39:38 2009 +0200
     4.3 @@ -272,8 +272,7 @@
     4.4  
     4.5      <para id="x_1e4">&Egrave; utile ricordare che il comando <command role="hg-cmd">hg revert</command> serve per i cambiamenti che non avete ancora inserito. Una volta che avete inserito un cambiamento, se decidete che è stato un errore potete ancora fare qualcosa, sebbene le vostre opzioni siano molto più limitate.</para>
     4.6  
     4.7 -    <para id="x_1e5">Per maggiori informazioni sul comando <command role="hg-cmd">hg revert</command> e dettagli su come trattare i cambiamenti che avete gia inserito, leggete la <!--<xref
     4.8 -	linkend="chap:undo"/>-->FIXME.</para>
     4.9 +    <para id="x_1e5">Per maggiori informazioni sul comando <command role="hg-cmd">hg revert</command> e dettagli su come trattare i cambiamenti che avete gia inserito, leggete il <xref linkend="chap:undo"/>.</para>
    4.10    </sect1>
    4.11  
    4.12    <sect1>

     5.1 --- a/it/ch06-collab.xml	Fri Jul 31 23:27:41 2009 +0200
     5.2 +++ b/it/ch06-collab.xml	Fri Jul 31 23:39:38 2009 +0200
     5.3 @@ -173,7 +173,7 @@
     5.4      <sect2>
     5.5        <title>Dove la collaborazione incontra la gestione dei rami</title>
     5.6  
     5.7 -      <para id="x_479">Una volta che voi e il vostro gruppo avete configurato qualche repository condiviso e cominciato a propagare cambiamenti avanti e indietro tra i repository locali e quelli condivisi, comincerete ad affrontare una sfida correlata ma leggermente differente: quella di gestire le diverse direzioni in cui il vostro gruppo potrebbe muoversi contemporaneamente. Anche se questa materia è intimamente legata al modo in cui il vostro gruppo collabora, è abbastanza densa da meritare una trattazione separata, nel <!--<xref linkend="chap:branch"/>-->FIXME.</para>
     5.8 +      <para id="x_479">Una volta che voi e il vostro gruppo avete configurato qualche repository condiviso e cominciato a propagare cambiamenti avanti e indietro tra i repository locali e quelli condivisi, comincerete ad affrontare una sfida correlata ma leggermente differente: quella di gestire le diverse direzioni in cui il vostro gruppo potrebbe muoversi contemporaneamente. Anche se questa materia è intimamente legata al modo in cui il vostro gruppo collabora, è abbastanza densa da meritare una trattazione separata, nel <xref linkend="chap:branch"/>.</para>
     5.9      </sect2>
    5.10    </sect1>
    5.11  
    5.12 @@ -563,7 +563,7 @@
    5.13  	      <para id="x_6ae"><literal>spartan</literal> è stato il template predefinito per lungo tempo.</para>
    5.14  	    </listitem>
    5.15  	  </itemizedlist>
    5.16 -	  <para id="x_6af">Potete anche specificare un vostro template personalizzato, come vedrete in dettaglio nel <!--<xref linkend="chap:template"/>-->FIXME per i dettagli. Qui potete vedere come abilitare lo stile <literal>gitweb</literal>.</para>
    5.17 +	  <para id="x_6af">Potete anche specificare un vostro template personalizzato, come vedrete in dettaglio nel <xref linkend="chap:template"/>. Qui potete vedere come abilitare lo stile <literal>gitweb</literal>.</para>
    5.18  	  <programlisting>[web]
    5.19  style = gitweb</programlisting>
    5.20  	</listitem>

     6.1 --- a/it/ch09-undo.xml	Fri Jul 31 23:27:41 2009 +0200
     6.2 +++ b/it/ch09-undo.xml	Fri Jul 31 23:39:38 2009 +0200
     6.3 @@ -278,7 +278,7 @@
     6.4  
     6.5        <para id="x_119">Il comando <command role="hg-cmd">hg backout</command> esegue un aggiornamento, un inserimento, un'unione e un altro inserimento per dare al meccanismo di unione la possibilità di fare il miglior lavoro possibile nel gestire tutte le modifiche avvenute <emphasis>tra</emphasis> il cambiamento che state ritirando e la revisione di punta corrente.</para>
     6.6  
     6.7 -      <para id="x_11a">Se state ritirando un cambiamento che si trova 100 revisioni indietro nella cronologia del vostro progetto, le probabilità che il comando <command>patch</command> sia in grado di applicare un diff invertito in maniera pulita non sono molto alte, perché i cambiamenti intercorsi avranno probabilmente <quote>rovinato il contesto</quote> utilizzato da <command>patch</command> per determinare se può applicare una patch (se questo vi sembra incomprensibile, leggete <!--<xref linkend="sec:mq:patch"/>-->FIXME per una discussione sul comando <command>patch</command>). In più, il meccanismo di unione di Mercurial riesce a gestire i cambiamenti di nome e di permessi per file e directory e le modifiche ai file binari, mentre <command>patch</command> non è in grado di farlo.</para>
     6.8 +      <para id="x_11a">Se state ritirando un cambiamento che si trova 100 revisioni indietro nella cronologia del vostro progetto, le probabilità che il comando <command>patch</command> sia in grado di applicare un diff invertito in maniera pulita non sono molto alte, perché i cambiamenti intercorsi avranno probabilmente <quote>rovinato il contesto</quote> utilizzato da <command>patch</command> per determinare se può applicare una patch (se questo vi sembra incomprensibile, leggete la <xref linkend="sec:mq:patch"/> per una discussione sul comando <command>patch</command>). In più, il meccanismo di unione di Mercurial riesce a gestire i cambiamenti di nome e di permessi per file e directory e le modifiche ai file binari, mentre <command>patch</command> non è in grado di farlo.</para>
     6.9  
    6.10      </sect2>
    6.11    </sect1>
    6.12 @@ -370,7 +370,7 @@
    6.13  
    6.14        <para id="x_123">Se avete inserito alcuni cambiamenti nel vostro repository locale e li avete propagati da qualche altra parte, questo non è necessariamente un disastro. Potete proteggervi prevenendo la comparsa di alcuni tipi di changeset sbagliati. Questo è particolarmente facile se di solito il vostro gruppo di lavoro estrae i cambiamenti da un repository centrale.</para>
    6.15  
    6.16 -      <para id="x_124">Configurando alcuni hook su quel repository per validare i changeset in entrata (si veda il <!--<xref linkend="chap:hook"/>-->FIXME), potete automaticamente evitare che alcuni tipi di changeset sbagliati compaiano nel repository centrale. Con una tale configurazione, alcuni tipi di changeset sbagliati tenderanno naturalmente a <quote>estinguersi</quote> perché non possono propagarsi verso il repository centrale. Ancora meglio, questo accade senza alcun bisogno di un intervento esplicito.</para>
    6.17 +      <para id="x_124">Configurando alcuni hook su quel repository per validare i changeset in entrata (si veda il <xref linkend="chap:hook"/>), potete automaticamente evitare che alcuni tipi di changeset sbagliati compaiano nel repository centrale. Con una tale configurazione, alcuni tipi di changeset sbagliati tenderanno naturalmente a <quote>estinguersi</quote> perché non possono propagarsi verso il repository centrale. Ancora meglio, questo accade senza alcun bisogno di un intervento esplicito.</para>
    6.18  
    6.19        <para id="x_125">Per esempio, un hook sui cambiamenti in entrata programmato per verificare che un changeset si possa effettivamente compilare è in grado di prevenire involontari <quote>guasti</quote> al processo di assemblaggio.</para>
    6.20      </sect2>

     7.1 --- a/it/ch12-mq.xml	Fri Jul 31 23:27:41 2009 +0200
     7.2 +++ b/it/ch12-mq.xml	Fri Jul 31 23:39:38 2009 +0200
     7.3 @@ -409,7 +409,7 @@
     7.4      <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>
     7.5  
     7.6      <itemizedlist>
     7.7 -      <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 <!--<xref linkend="sec:mqref:cmd:qpush"/>-->FIXME per sapere perché succede questo.</para>
     7.8 +      <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>
     7.9        </listitem>
    7.10        <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>
    7.11        </listitem>
    7.12 @@ -465,7 +465,7 @@
    7.13  
    7.14  &interaction.mq.tools.tools;
    7.15  
    7.16 -    <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"/>-->FIXME per un altro esempio.</para>
    7.17 +    <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>
    7.18  
    7.19    </sect1>
    7.20    <sect1>

     8.1 --- a/it/ch14-hgext.xml	Fri Jul 31 23:27:41 2009 +0200
     8.2 +++ b/it/ch14-hgext.xml	Fri Jul 31 23:39:38 2009 +0200
     8.3 @@ -10,7 +10,7 @@
     8.4      </listitem>
     8.5      <listitem><para id="x_501">Nel <xref linkend="chap:hook"/>, abbiamo parlato di diverse estensioni che sono utili per funzionalità relative agli hook: <literal role="hg-ext">acl</literal> aggiunge le liste di controllo d'accesso; <literal role="hg-ext">bugzilla</literal> aggiunge l'integrazione con il sistema Bugzilla per la gestione dei bug; e <literal role="hg-ext">notify</literal> invia email di notifica in reazione all'inserimento di nuovi cambiamenti.</para>
     8.6      </listitem>
     8.7 -    <listitem><para id="x_502">L'estensione Mercurial Queues per la gestione delle patch è talmente inestimabile che merita due capitoli e un'appendice a essa dedicati. Il <!--<xref linkend="chap:mq"/>-->FIXME copre le nozioni di base; il <!--<xref linkend="chap:mq-collab"/>-->FIXME ne discute gli argomenti avanzati; e il <!--<xref linkend="chap:mqref"/>-->FIXME entra nei dettagli di ogni comando.</para>
     8.8 +    <listitem><para id="x_502">L'estensione Mercurial Queues per la gestione delle patch è talmente inestimabile che merita due capitoli e un'appendice a essa dedicati: il <xref linkend="chap:mq"/> copre le nozioni di base, il <xref linkend="chap:mq-collab"/> ne discute gli argomenti avanzati e il <xref linkend="chap:mqref"/> entra nei dettagli di ogni comando.</para>
     8.9      </listitem>
    8.10    </itemizedlist>
    8.11  
    8.12 @@ -69,7 +69,7 @@
    8.13  hg clone crew inotify
    8.14  hg clone http://hg.kublai.com/mercurial/patches/inotify inotify/.hg/patches</programlisting>
    8.15        </listitem>
    8.16 -      <listitem><para id="x_517">Assicuratevi di avere abilitato l'estensione <literal role="hg-ext">mq</literal> per Mercurial Queues. Se non avete mai usato MQ, leggete la sezione <!--<xref linkend="sec:mq:start"/>-->FIXME per cominciare velocemente.</para>
    8.17 +      <listitem><para id="x_517">Assicuratevi di avere abilitato l'estensione <literal role="hg-ext">mq</literal> per Mercurial Queues. Se non avete mai usato MQ, leggete la <xref linkend="sec:mq:start"/> per cominciare velocemente.</para>
    8.18        </listitem>
    8.19        <listitem><para id="x_518">Posizionatevi nel repository <filename class="directory">inotify</filename> e applicate tutte le patch per l'estensione <literal role="hg-ext">inotify</literal> usando l'opzione <option role="hg-ext-mq-cmd-qpush-opt">hg -a</option> per il comando <command role="hg-ext-mq">qpush</command>.</para>
    8.20  	<programlisting>cd inotify
    8.21 @@ -127,7 +127,7 @@
    8.22      <para id="x_52a">Lanciare uno strumento di diff visuale è altrettanto facile. Ecco come lanciare il visualizzatore<command>kdiff3</command>.</para>
    8.23      <programlisting>hg extdiff -p kdiff3 -o</programlisting>
    8.24  
    8.25 -    <para id="x_52b">Se il comando che usate per visualizzare i diff non gestisce le directory, potete facilmente aggirare questo problema con un minimo di programmazione. Per un esempio di un programma simile in azione con l'estensione <literal role="hg-ext">mq</literal> e il comando <command>interdiff</command>, consultate la sezione <!--<xref linkend="mq-collab:tips:interdiff"/>-->FIXME.</para>
    8.26 +    <para id="x_52b">Se il comando che usate per visualizzare i diff non gestisce le directory, potete facilmente aggirare questo problema con un minimo di programmazione. Per un esempio di un programma simile in azione con l'estensione <literal role="hg-ext">mq</literal> e il comando <command>interdiff</command>, consultate la <xref linkend="mq-collab:tips:interdiff"/>.</para>
    8.27  
    8.28      <sect2>
    8.29        <title>Definire alias per i comandi</title>
    8.30 @@ -190,7 +190,7 @@
    8.31  	</listitem>
    8.32  	<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">hg -f</option>. Questa opzione prende un argomento, l'indirizzo email da usare.</para>
    8.33  	</listitem>
    8.34 -	<listitem><para id="x_53e">Il comportamento predefinito è quello di inviare diff in formato unified (leggete <!--<xref linkend="sec:mq:patch"/>-->FIXME per una descrizione del formato), uno per messaggio. Potete invece inviare un bundle eseguibile con l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">hg -b</option>.</para>
    8.35 +	<listitem><para id="x_53e">Il comportamento predefinito è quello di inviare diff in formato unified (leggete la <xref linkend="sec:mq:patch"/> per una descrizione del formato), uno per messaggio. Potete invece inviare un bundle eseguibile con l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">hg -b</option>.</para>
    8.36  	</listitem>
    8.37  	<listitem><para id="x_53f">I diff in formato unified sono normalmente preceduti da un'intestazione di metadati. Potete ometterla e inviare diff disadorni con l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">hg --plain</option>.</para>
    8.38  	</listitem>