1.1 --- a/it/ch09-undo.xml	Fri Jul 24 19:23:29 2009 +0200
     1.2 +++ b/it/ch09-undo.xml	Fri Jul 31 23:39:38 2009 +0200
     1.3 @@ -278,7 +278,7 @@
     1.4  
     1.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>
     1.6  
     1.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>
     1.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>
     1.9  
    1.10      </sect2>
    1.11    </sect1>
    1.12 @@ -370,7 +370,7 @@
    1.13  
    1.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>
    1.15  
    1.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>
    1.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>
    1.18  
    1.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>
    1.20      </sect2>