1.1 --- a/it/ch04-concepts.xml	Wed Jul 01 17:25:39 2009 +0200
     1.2 +++ b/it/ch04-concepts.xml	Sun Jul 05 16:52:36 2009 +0200
     1.3 @@ -2,21 +2,21 @@
     1.4    <?dbhtml filename="dietro-le-quinte.html"?>
     1.5    <title>Dietro le quinte</title>
     1.6  
     1.7 -  <para id="x_2e8">Diversamente da molti sistemi di controllo di revisione, i concetti su cui Mercurial è costruito sono abbastanza semplici che è facile capire come il software funziona realmente. Conoscere questi dettagli non è certamente necessario, quindi è certamente sicuro saltare questo capitolo. Tuttavia, penso che otterrete di più dal software con un <quote>modello mentale</quote> di quello che sta succedendo.</para>
     1.8 -
     1.9 -  <para id="x_2e9">Essere in grado di capire quello che accade dietro le quinte mi dà la confidenza che Mercurial sia stato attentamente progettato per essere sia <emphasis>sicuro</emphasis> che <emphasis>efficiente</emphasis>. E allo stesso modo è importante, se è facile per me tenere a mente una buona idea di quello che il software sta facendo mentre effettuo un'attività di controllo di revisione, è meno probabile che venga sorpreso dal suo comportamento.</para>
    1.10 -
    1.11 -  <para id="x_2ea">In questo capitolo, tratteremo inizialmente i concetti chiave dietro alla progettazione di Mercurial, poi continueremo discutendo alcuni dei dettagli più interessanti della sua implementazione.</para>
    1.12 +  <para id="x_2e8">Diversamente da molti sistemi di controllo di revisione, Mercurial è costruito sulla base di concetti abbastanza semplici da facilitare la comprensione del modo in cui il software funziona realmente. Conoscere questi dettagli non è certamente necessario, per cui potete tranquillamente saltare questo capitolo. Tuttavia, penso che otterrete di più dal software conoscendo il <quote>modello concettuale</quote> del suo funzionamento.</para>
    1.13 +
    1.14 +  <para id="x_2e9">Essere in grado di capire quello che accade dietro le quinte mi dà una certa garanzia che Mercurial sia stato attentamente progettato per essere sia <emphasis>sicuro</emphasis> che <emphasis>efficiente</emphasis>. Analogamente, è importante che per me sia facile avere un'idea corretta di quello che il software sta facendo mentre svolgo un'attività di controllo di revisione, in modo da abbassare la probabilità di venire sorpreso dal suo comportamento.</para>
    1.15 +
    1.16 +  <para id="x_2ea">Inizieremo questo capitolo parlando dei concetti chiave alla base della progettazione di Mercurial, poi proseguiremo discutendo alcuni dei dettagli più interessanti della sua implementazione.</para>
    1.17  
    1.18    <sect1>
    1.19      <title>La registrazione della cronologia di Mercurial</title>
    1.20  
    1.21      <sect2>
    1.22 -      <title>Tenere traccia della cronologia di un singolo file</title>
    1.23 -
    1.24 -      <para id="x_2eb">Quando Mercurial tiene traccia delle modifiche a un file, memorizza la cronologia di quel file in un oggetto di metadati chiamato <emphasis>filelog</emphasis> (letteralmente, registro del file). Ogni voce in un filelog contiene informazioni sufficienti a ricostruire una revisione del file di cui viene tenuta traccia. I filelog sono memorizzati come file nella directory <filename role="special" class="directory">.hg/store/data</filename>. Un filelog contiene due tipi di informazione: dati di revisione e un indice per aiutare Mercurial a trovare una revisione in maniera efficiente.</para>
    1.25 -
    1.26 -      <para id="x_2ec">Il filelog di un file che sia di grandi dimensioni o abbia una lunga cronologia viene memorizzato in due file separati per i dati (con un suffisso <quote><literal>.d</literal></quote>) e l'indice (con un suffisso <quote><literal>.i</literal></quote>). Per file di piccole dimensioni senza molta cronologia, i dati di revisione e l'indice vengono combinati in un singolo file <quote><literal>.i</literal></quote>. La corrispondenza tra un file nella directory di lavoro e il filelog che tiene traccia della sua cronologia nel repository è illustrata nella <xref
    1.27 +      <title>Memorizzare la cronologia di un singolo file</title>
    1.28 +
    1.29 +      <para id="x_2eb">Quando Mercurial tiene traccia delle modifiche a un file, memorizza la cronologia di quel file in un oggetto di metadati chiamato <emphasis>filelog</emphasis> (letteralmente, registro del file). Ogni voce in un filelog contiene informazioni sufficienti a ricostruire una revisione del file di cui tiene traccia. I filelog sono memorizzati come file nella directory <filename role="special" class="directory">.hg/store/data</filename>. Un filelog contiene due tipi di informazione: dati di revisione, più un indice per aiutare Mercurial a trovare una revisione in maniera efficiente.</para>
    1.30 +
    1.31 +      <para id="x_2ec">Il filelog di un file di grandi dimensioni o che abbia una lunga cronologia viene memorizzato in due file separati per i dati (con un suffisso <quote><literal>.d</literal></quote>) e l'indice (con un suffisso <quote><literal>.i</literal></quote>). Per file di piccole dimensioni con una cronologia ridotta, i dati di revisione e l'indice vengono combinati in un singolo file <quote><literal>.i</literal></quote>. La corrispondenza tra un file nella directory di lavoro e il filelog che tiene traccia della sua cronologia nel repository è illustrata nella <xref
    1.32  	  linkend="fig:concepts:filelog"/>.</para>
    1.33  
    1.34        <figure id="fig:concepts:filelog">
    1.35 @@ -29,23 +29,23 @@
    1.36  
    1.37      </sect2>
    1.38      <sect2>
    1.39 -      <title>Gestire i file tracciati</title>
    1.40 -
    1.41 -      <para id="x_2ee">Mercurial usa una struttura chiamata <emphasis>manifest</emphasis> per collezionare informazioni sui file di cui tiene traccia. Ogni voce nel manifest contiene informaizoni sui file presenti in un singolo changeset. Una voce registra quali file sono presenti nel changeset, la revisione di ogni file e alcuni altri frammenti di metadati sui file.</para>
    1.42 +      <title>Gestire i file archiviati</title>
    1.43 +
    1.44 +      <para id="x_2ee">Mercurial usa una struttura chiamata <emphasis>manifest</emphasis> (in italiano, manifesto) per collezionare informazioni sui file di cui tiene traccia. Ogni voce nel manifest contiene informazioni sui file presenti in un singolo changeset e registra quali file sono contenuti nel changeset, la revisione di ogni file e alcuni altri metadati sui file.</para>
    1.45  
    1.46      </sect2>
    1.47      <sect2>
    1.48        <title>Registrare le informazioni di changeset</title>
    1.49  
    1.50 -      <para id="x_2ef">Il <emphasis>changelog</emphasis> (letteralmente, registro dei cambiamenti) contiene informazioni su tutti i changeset. Ogni revisione registra chi ha inserito un cambiamento, il commento del changeset, altri frammenti di informazione relativi al changeset e la revisione del manifest da usare.</para>
    1.51 +      <para id="x_2ef">Il <emphasis>changelog</emphasis> (letteralmente, registro dei cambiamenti) contiene informazioni su tutti i changeset. Ogni revisione memorizza chi ha inserito un cambiamento, il commento del changeset, altre informazioni relative al changeset e la revisione del manifest da usare.</para>
    1.52  
    1.53      </sect2>
    1.54      <sect2>
    1.55        <title>Relazioni tra le revisioni</title>
    1.56  
    1.57 -      <para id="x_2f0">Nell'ambito di un changelog, di un manifest, o di un filelog, ogni revisione memorizza un puntatore al suo genitore diretto (o ai suoi due genitori, se è una revisione di unione). Come ho già detto, esistono anche relazioni tra revisioni <emphasis>attraverso</emphasis> queste strutture, ed esse hanno natura gerarchica.</para>
    1.58 -
    1.59 -      <para id="x_2f1">Per ogni changeset nel repository, esiste esattamente una revisione memorizzata nel changelog. Ogni revisione del changelog contiene un puntatore a una singola revisione del manifest. Una revisione del manifest memorizza un puntatore a una singola revisione di ogni filelog tracciato quando il changeset è stato creato. Queste relazioni sono illustrate nella <xref linkend="fig:concepts:metadata"/>.</para>
    1.60 +      <para id="x_2f0">Nell'ambito di un changelog, di un manifest, o di un filelog, ogni revisione mantiene un puntatore al suo genitore diretto (o ai suoi due genitori, se è una revisione di unione). Come ho già detto, esistono anche relazioni tra revisioni <emphasis>attraverso</emphasis> queste strutture, e tali relazioni sono di natura gerarchica.</para>
    1.61 +
    1.62 +      <para id="x_2f1">Per ogni changeset nel repository, esiste esattamente una revisione memorizzata nel changelog. Ogni revisione del changelog contiene un puntatore a una singola revisione del manifest. Una revisione del manifest include un puntatore a una singola revisione di ogni filelog archiviato quando il changeset è stato creato. Queste relazioni sono illustrate nella <xref linkend="fig:concepts:metadata"/>.</para>
    1.63  
    1.64        <figure id="fig:concepts:metadata">
    1.65  	<title>Relazioni tra i metadati</title>
    1.66 @@ -55,8 +55,8 @@
    1.67  	</mediaobject>
    1.68        </figure>
    1.69  
    1.70 -      <para id="x_2f3">Come mostrato in figura, <emphasis>non</emphasis> c'è una relazione <quote>uno a uno</quote> tra le revisioni nel changelog, nel manifest, o nel filelog. Se un file tracciato da Mercurial non è cambiato tra due changeset, la voce per quel file nelle due revisioni del manifest punterà alla stessa revisione nel suo filelog<footnote>
    1.71 -	  <para id="x_725">&Egrave; possibile (sebbene inusuale) che il manifest rimanga lo stesso tra due changeset, nel qual caso le voci del changelog per quei changeset punteranno alla stessa revisione del manifest.</para>
    1.72 +      <para id="x_2f3">Come mostrato in figura, <emphasis>non</emphasis> c'è una relazione <quote>uno a uno</quote> tra le revisioni nel changelog, nel manifest, o nel filelog. Se un file registrato da Mercurial non è cambiato tra due changeset, la voce per quel file nelle due revisioni del manifest punterà alla stessa revisione nel suo filelog<footnote>
    1.73 +	  <para id="x_725">&Egrave; possibile (anche se inusuale) che il manifest rimanga lo stesso tra due changeset, nel qual caso le voci del changelog per quei changeset punteranno alla stessa revisione del manifest.</para>
    1.74  	</footnote>.</para>
    1.75  
    1.76      </sect2>
    1.77 @@ -64,30 +64,30 @@
    1.78    <sect1>
    1.79      <title>Memorizzazione sicura ed efficiente</title>
    1.80  
    1.81 -    <para id="x_2f4">I puntelli dei changelog, dei manifest e dei filelog sono forniti da una singola struttura chiamata <emphasis>revlog</emphasis> (letteralmente, registro di revisione).</para>
    1.82 +    <para id="x_2f4">Il supporto su cui si basano i changelog, i manifest e i filelog viene fornito da una singola struttura chiamata <emphasis>revlog</emphasis> (letteralmente, registro di revisione).</para>
    1.83  
    1.84      <sect2>
    1.85        <title>Memorizzazione efficiente</title>
    1.86  
    1.87 -      <para id="x_2f5">Il revlog fornisce una memorizzazione efficiente delle revisioni usando un meccanismo di <emphasis>delta</emphasis>. Invece di memorizzare una copia completa di un file per ogni revisione, memorizza i cambiamenti necessari a trasformare una revisione più vecchia nella nuova revisione. Per molti tipi di dati di file, queste delta sono tipicamente una frazione percentuale della dimensione di un'intera copia di un file.</para>
    1.88 -
    1.89 -      <para id="x_2f6">Alcuni sistemi di controllo di revisione obsoleti possono lavorare solo con le delta di file di testo. Essi devono memorizzare file binari come fotografie complete o codificarli in una rappresentazione testuale, entrambi approcci dispendiosi. Mercurial può maneggiare in maniera efficiente le delta di file con contenuti binari arbitrari; non ha bisogno di trattare il testo in maniera speciale.</para>
    1.90 +      <para id="x_2f5">Il revlog permette di memorizzare le revisioni in maniera efficiente usando un meccanismo basato su differenze chiamate <emphasis>delta</emphasis>. Invece di registrare una copia completa di un file per ogni revisione, il revlog memorizza i cambiamenti necessari a trasformare una revisione più vecchia nella nuova revisione. Per molti tipi di file, queste delta sono tipicamente una frazione percentuale della dimensione di un'intera copia di un file.</para>
    1.91 +
    1.92 +      <para id="x_2f6">Alcuni sistemi di controllo di revisione obsoleti possono lavorare solo con le delta di file di testo e sono costretti a memorizzare i file binari come copie complete o a codificarli in una rappresentazione testuale, entrambi approcci dispendiosi. Mercurial è in grado di gestire in maniera efficiente le delta di file con contenuti binari arbitrari, per cui non ha bisogno di trattare il testo in maniera speciale.</para>
    1.93  
    1.94      </sect2>
    1.95      <sect2 id="sec:concepts:txn">
    1.96        <title>Operazioni sicure</title>
    1.97  
    1.98 -      <para id="x_2f7">Mercurial si limita ad <emphasis>aggiungere</emphasis> dati alla fine di un file di revlog. Non modifica mai una sezione di un file dopo che lo ha scritto. Questo è sia più robusto che più efficiente rispetto a schemi che hanno bisogno di modificare o riscrivere i dati.</para>
    1.99 -
   1.100 -      <para id="x_2f8">In più, Mercurial tratta ogni scrittura come parte di una <emphasis>transazione</emphasis> che può coinvolgere un qualsiasi numero di file. Una transazione è <emphasis>atomica</emphasis>: o l'intera transazione ha successo e i suoi effetti sono visibili in lettura in un unico passo, oppure l'intera operazione viene annullata. Questa garanzia di atomicità significa che se state eseguendo due copie di Mercurial, dove una sta leggendo dati e l'altra sta scrivendo, il lettore non vedrà mai un risultato parzialmente scritto che potrebbe confonderlo.</para>
   1.101 -
   1.102 -      <para id="x_2f9">Il fatto che Mercurial aggiunga solo ai file rende più facile fornire questa garanzia transazionale. Più è facile fare cose come queste, più dovreste essere fiduciosi che vengano fatte correttamente.</para>
   1.103 +      <para id="x_2f7">Mercurial si limita ad <emphasis>aggiungere</emphasis> dati alla fine di un file di revlog invece di modificarne una sezione dopo averlo memorizzato. Questo approccio è più robusto ed efficiente rispetto a sistemi che hanno bisogno di modificare o riscrivere i dati.</para>
   1.104 +
   1.105 +      <para id="x_2f8">In più, Mercurial tratta ogni scrittura come parte di una <emphasis>transazione</emphasis> che può coinvolgere un qualsiasi numero di file. Una transazione è <emphasis>atomica</emphasis>: o l'intera transazione ha successo e i suoi effetti sono visibili in lettura in un unico passo, oppure l'operazione viene completamente annullata. Questa garanzia di atomicità significa che se state eseguendo due copie di Mercurial, una che sta leggendo dati e l'altra che sta scrivendo, la copia che agisce in lettura non vedrà mai un risultato parzialmente scritto che potrebbe confonderla.</para>
   1.106 +
   1.107 +      <para id="x_2f9">Il fatto che Mercurial operi solo aggiungendo dati alla fine dei file rende più facile fornire questa garanzia transazionale. Più è facile fare cose come queste, più dovreste avere fiducia che vengano fatte correttamente.</para>
   1.108  
   1.109      </sect2>
   1.110      <sect2>
   1.111        <title>Reperimento veloce</title>
   1.112  
   1.113 -      <para id="x_2fa">Mercurial evita astutamente un tranello comune a tutti i primi sistemi di controllo di revisione: il problema del <emphasis>reperimento inefficiente</emphasis>. La maggior parte dei sistemi di controllo di revisione memorizza i contenuti di una revisione come una serie incrementale di modifiche contro una <quote>fotografia</quote>. (Alcuni basano la fotografia sulla revisione più vecchia, altri su quella più nuova.) Per ricostruire una revisione specifica, dovete prima leggere la fotografia, e poi ognuna delle revisioni tra la fotografia e la vostra revisione obiettivo. Più un file accumula cronologia, più revisioni dovete leggere, quindi più tempo viene impiegato per ricostruire una particolare revisione.</para>
   1.114 +      <para id="x_2fa">Mercurial evita astutamente un'insidia comune a tutti i primi sistemi di controllo di revisione: il problema del <emphasis>reperimento inefficiente</emphasis>. La maggior parte dei sistemi di controllo di revisione memorizza i contenuti di una revisione come una serie incrementale di modifiche rispetto a una <quote>fotografia</quote>. (Alcuni basano la fotografia sulla revisione più vecchia, altri su quella più nuova.) Per ricostruire una revisione specifica, dovete leggere prima la fotografia e poi ognuna delle revisioni tra la fotografia e la revisione che volete. Più cronologia accumula un file, più revisioni dovete leggere, quindi più tempo viene impiegato per ricostruire una particolare revisione.</para>
   1.115  
   1.116        <figure id="fig:concepts:snapshot">
   1.117  	<title>Fotografia di un revlog, con delta incrementali</title>
   1.118 @@ -97,29 +97,29 @@
   1.119  	</mediaobject>
   1.120        </figure>
   1.121  
   1.122 -      <para id="x_2fc">L'innovazione che Mercurial applica a questo problema è semplice ma efficace. Una volta che la quantità totale di informazioni di delta memorizzata dall'ultima immagine supera una soglia fissata, Mercurial memorizza una nuova immagine (compressa, naturalmente) invece di un'altra delta. Questo rende possibile ricostruire velocemente <emphasis>qualsiasi</emphasis> revisione di un file. Questo approccio funziona così bene che in seguito è stato copiato da molti altri sistemi di controllo di revisione.</para>
   1.123 -
   1.124 -      <para id="x_2fd">La <xref linkend="fig:concepts:snapshot"/> illustra l'idea. In una voce di un file indice per un revlog, Mercurial memorizza l'intervallo di voci dal file di dati che deve leggere per ricostruire una particolare revisione.</para>
   1.125 +      <para id="x_2fc">L'innovazione che Mercurial applica alla soluzione di questo problema è semplice ma efficace. Una volta che la quantità totale di informazioni di delta memorizzate dall'ultima fotografia supera una soglia fissata, Mercurial memorizza una nuova fotografia (compressa, naturalmente) invece di un'altra delta. Questo approccio consente di ricostruire velocemente <emphasis>qualsiasi</emphasis> revisione di un file e funziona così bene che in seguito è stato copiato da molti altri sistemi di controllo di revisione.</para>
   1.126 +
   1.127 +      <para id="x_2fd">La <xref linkend="fig:concepts:snapshot"/> illustra l'idea. In una voce contenuta nel file indice di un revlog, Mercurial memorizza l'intervallo di voci che deve leggere dal file di dati per ricostruire una particolare revisione.</para>
   1.128  
   1.129        <sect3>
   1.130  	<title>Digressione: l'influenza della compressione video</title>
   1.131  
   1.132 -	<para id="x_2fe">Se avete familiarità con la compressione video o avete mai guardato un segnale televisivo attraverso un cavo digitale o un servizio satellitare, potreste sapere che la maggior parte degli schemi per la compressione video memorizzano ogni frame del video come una delta rispetto al frame precedente.</para>
   1.133 -
   1.134 -	<para id="x_2ff">Mercurial prende in prestito questa idea per fare in modo che sia possibile ricostruire una revisione da una fotografia e un piccolo numero di delta.</para>
   1.135 +	<para id="x_2fe">Se avete familiarità con la compressione video o avete mai osservato un segnale televisivo trasmesso attraverso un cavo digitale o un servizio satellitare, potreste sapere che la maggior parte degli schemi per la compressione video memorizzano ogni frame del video come una delta rispetto al frame precedente.</para>
   1.136 +
   1.137 +	<para id="x_2ff">Mercurial prende in prestito questa idea per fare in modo che sia possibile ricostruire una revisione da una fotografia e da un ridotto numero di delta.</para>
   1.138  
   1.139        </sect3>
   1.140      </sect2>
   1.141      <sect2>
   1.142        <title>Identificazione e integrità forte</title>
   1.143  
   1.144 -      <para id="x_300">Insieme alle informazioni di delta o di fotografia, una voce di revlog contiene un hash crittografico dei dati che rappresenta. Questo rende difficile contraffarre i contenuti di una revisione e facile scoprire una accidentale corruzione.</para>
   1.145 -
   1.146 -      <para id="x_301">Gli hash forniscono più di un semplice controllo contro la corruzione; essi sono usati come identificatori per le revisioni. Gli hash di identificazione dei changeset che avete visto come utenti finali provengono dalle revisioni del changelog. Sebbene anche i filelog e il manifest facciano uso di hash, in questo caso Mercurial li impiega solo dietro le quinte.</para>
   1.147 -
   1.148 -      <para id="x_302">Mercurial verifica che gli hash siano corretti quando reperisce le revisioni dei file e quando estrae i cambiamenti da un altro repository. Se incontra un problema di integrità, lo segnalerà e bloccherà l'operazione che stava eseguendo.</para>
   1.149 -
   1.150 -      <para id="x_303">In aggiunta all'effetto che ha sull'efficienza del reperimento, l'uso di fotografie periodiche da parte di Mercurial rende i repository più robusti nei confronti della corruzione parziale dei dati. Se un revlog diventa parzialmente corrotto a causa di un errore hardware o di un bug di sistema, spesso rimane possibile ricostruire alcune o la maggior parte delle revisioni a partire dalle sezioni non corrotte del revlog che si trovano prima e dopo la sezione rovinata. Questo non sarebbe possibile con un modello di memorizzazione basato unicamente sulle delta.</para>
   1.151 +      <para id="x_300">Insieme alle informazioni di delta e di fotografia, una voce di revlog contiene un hash crittografico dei dati che rappresenta. Questo rende difficile contraffarre i contenuti di una revisione e facilita la scoperta di corruzioni accidentali dei dati.</para>
   1.152 +
   1.153 +      <para id="x_301">Gli hash forniscono più di un semplice controllo contro la corruzione dei dati, infatti vengono usati come identificatori per le revisioni. Gli hash di identificazione dei changeset che avete visto come utenti finali provengono dalle revisioni del changelog. Sebbene anche i filelog e il manifest facciano uso di hash, in questo caso Mercurial li impiega solo dietro le quinte.</para>
   1.154 +
   1.155 +      <para id="x_302">Mercurial verifica che gli hash siano corretti nel momento in cui reperisce le revisioni dei file o estrae i cambiamenti da un altro repository. Se incontra un problema di integrità, lo segnalerà e bloccherà l'operazione che stava eseguendo.</para>
   1.156 +
   1.157 +      <para id="x_303">In aggiunta all'effetto che ha sull'efficienza del reperimento, l'uso di fotografie periodiche da parte di Mercurial rende i repository più robusti nei confronti della corruzione parziale dei dati. Se un revlog viene parzialmente rovinato da un errore hardware o da un bug di sistema, spesso rimane possibile ricostruire alcune o la maggior parte delle revisioni a partire dalle sezioni illese del revlog che si trovano prima e dopo la sezione rovinata. Questo non sarebbe possibile con un modello di memorizzazione basato unicamente sulle delta.</para>
   1.158      </sect2>
   1.159    </sect1>
   1.160  
   1.161 @@ -128,9 +128,9 @@
   1.162  
   1.163      <para id="x_304">Ogni voce in un revlog di Mercurial conosce l'identità della propria revisione progenitrice diretta, di solito chiamata <emphasis>genitore</emphasis>. In effetti, una revisione contiene spazio non solo per un genitore, ma per due. Mercurial usa un hash speciale, chiamato <quote>identificatore nullo</quote>, per rappresentare l'idea <quote>non c'è alcun genitore qui</quote>. Questo hash è semplicemente una stringa di zero.</para>
   1.164  
   1.165 -    <para id="x_305">Nella <xref linkend="fig:concepts:revlog"/>, potete vedere un esempio della struttura concettuale di un revlog. I filelog, i manifest e i changelog hanno tutti questa identica struttura; essi differiscono solo per il tipo di dati memorizzati in ogni delta e fotografia.</para>
   1.166 -
   1.167 -    <para id="x_306">La prima revisione in un revlog (nella parte inferiore dell'immagine) presenta un identificatore nullo in entrambi i posti genitoriali. Per una revisione <quote>normale</quote>, il primo posto genitoriale contiene l'identificatore della revisione genitore e il secondo contiene l'identificatore nullo, indicando che la revisione possiede un solo vero genitore. Due revisioni qualsiasi che possiedano lo stesso identificatore di genitore sono rami. Una revisione che rappresenta un'unione tra rami ha due identificatori di revisione normali nei propri posti genitoriali.</para>
   1.168 +    <para id="x_305">Nella <xref linkend="fig:concepts:revlog"/>, potete vedere un esempio della struttura concettuale di un revlog. I filelog, i manifest e i changelog hanno tutti questa identica struttura e differiscono solo per il tipo di dati memorizzati in ogni delta e fotografia.</para>
   1.169 +
   1.170 +    <para id="x_306">La prima revisione in un revlog (nella parte inferiore dell'immagine) presenta un identificatore nullo in entrambi gli spazi riservati ai genitori. Per una revisione <quote>normale</quote>, lo spazio del primo genitore contiene l'identificatore della revisione genitore e lo spazio del secondo contiene l'identificatore nullo, indicando che la revisione possiede un solo vero genitore. Due revisioni qualsiasi che possiedano lo stesso genitore si chiamano rami. Una revisione che rappresenta un'unione tra rami ha due identificatori di revisione normali negli spazi dedicati ai propri genitori.</para>
   1.171  
   1.172      <figure id="fig:concepts:revlog">
   1.173        <title>La struttura concettuale di un revlog</title>
   1.174 @@ -144,18 +144,18 @@
   1.175    <sect1>
   1.176      <title>La directory di lavoro</title>
   1.177  
   1.178 -    <para id="x_307">Nella directory di lavoro, Mercurial memorizza una fotografia dei file contenuti nel repository come un changeset particolare.</para>
   1.179 -
   1.180 -    <para id="x_308">La directory di lavoro <quote>sa</quote> quale changeset contiene. Quando aggiornate la directory di lavoro per contenere un particolare changeset, Mercurial cerca la revisione appropriata del manifest per trovare quali file stava tracciando nel momento in cui quel changeset è stato inserito, e quale revisione di ogni file era corrente in quel momento. Poi ricrea una copia di ognuno di quei file, con gli stessi contenuti che avevano quando il changeset è stato inserito.</para>
   1.181 -
   1.182 -    <para id="x_309">Il <emphasis>dirstate</emphasis> (letteralmente, stato della directory) è una struttura speciale che contiene le informazioni possedute da Mercurial sulla directory di lavoro. Viene mantenuto sotto forma di un file chiamato <filename>.hg/dirstate</filename> all'interno di un repository. Il dirstate contiene i dettagli dei changeset a cui la directory di lavoro è aggiornata, e di tutti i file che Mercurial sta tracciando nella directory di lavoro. Esso permette anche a Mercurial di notare velocemente i file modificati, registrando le loro date e dimensioni al momento del ~checkout~.</para>
   1.183 -
   1.184 -    <para id="x_30a">Esattamente come una revisione di un revlog ha spazio per due genitori, in modo da poter rappresentare sia una normale revisione (con un genitore) che un'unione di due revisioni precedenti, il dirstate ha spazio per due genitori. Quando usate il comando <command role="hg-cmd">hg update</command>, il changeset a cui aggiornate viene memorizzato nel posto del <quote>primo genitore</quote>, e l'identificatore nullo nel secondo. Quando incorporate un altro changeset tramite <command role="hg-cmd">hg merge</command>, il primo genitore rimane lo stesso, e il secondo genitore viene riempito con il changeset che state incorporando. Il comando <command role="hg-cmd">hg parents</command> vi dice quali sono i genitori del dirstate.</para>
   1.185 +    <para id="x_307">Nella directory di lavoro, Mercurial mantiene una fotografia dei file contenuti nel repository scattata su un changeset particolare.</para>
   1.186 +
   1.187 +    <para id="x_308">La directory di lavoro <quote>sa</quote> quale changeset contiene. Quando aggiornate la directory di lavoro per contenere un particolare changeset, Mercurial cerca la revisione appropriata del manifest per trovare quali file aveva registrato nel momento in cui quel changeset è stato inserito, e qual era la revisione corrente di ogni file in quel momento. Poi, ricrea una copia di tutti quei file, con gli stessi contenuti che avevano quando il changeset è stato inserito.</para>
   1.188 +
   1.189 +    <para id="x_309">Il <emphasis>dirstate</emphasis> (letteralmente, stato della directory) è una struttura speciale che contiene le informazioni possedute da Mercurial sulla directory di lavoro. Viene mantenuto sotto forma di un file chiamato <filename>.hg/dirstate</filename> all'interno di un repository. Il dirstate contiene i dettagli del changeset a cui la directory di lavoro è aggiornata e di tutti i file di cui Mercurial sta tenendo traccia nella directory di lavoro. Il dirstate permette a Mercurial anche di notare velocemente i file modificati, registrando le loro date e dimensioni al momento dell'aggiornamento.</para>
   1.190 +
   1.191 +    <para id="x_30a">Il dirstate riserva spazio per due genitori, esattamente come una revisione di un revlog, in modo da poter rappresentare sia una normale revisione (con un genitore) che un'unione di due revisioni precedenti. Quando usate il comando <command role="hg-cmd">hg update</command>, il changeset a cui aggiornate viene memorizzato nello spazio del <quote>primo genitore</quote> e l'identificatore nullo nello spazio del secondo. Quando incorporate un altro changeset tramite <command role="hg-cmd">hg merge</command>, il primo genitore rimane lo stesso e il secondo genitore diventa il changeset che state incorporando. Il comando <command role="hg-cmd">hg parents</command> vi dice quali sono i genitori del dirstate.</para>
   1.192  
   1.193      <sect2>
   1.194        <title>Cosa succede quando eseguite un commit</title>
   1.195  
   1.196 -      <para id="x_30b">Il dirstate memorizza le informazioni sui genitori per altri scopi oltre alla mera contabilità. Mercurial usa i genitori del dirstate come <emphasis>i genitori di un nuovo changeset</emphasis> quando effettuate un commit.</para>
   1.197 +      <para id="x_30b">Il dirstate mantiene le informazioni sui genitori per altri scopi oltre alla mera contabilità. Mercurial usa i genitori del dirstate come <emphasis>i genitori di un nuovo changeset</emphasis> quando effettuate un commit.</para>
   1.198  
   1.199        <figure id="fig:concepts:wdir">
   1.200  	<title>La directory di lavoro può avere due genitori</title>
   1.201 @@ -165,7 +165,7 @@
   1.202  	</mediaobject>
   1.203        </figure>
   1.204  
   1.205 -      <para id="x_30d">La <xref linkend="fig:concepts:wdir"/> mostra il normale stato della directory di lavoro, dove ha un singolo changeset come genitore. Quel changeset è la <emphasis>punta</emphasis>, il changeset più recente nel repository che non possiede figli.</para>
   1.206 +      <para id="x_30d">La <xref linkend="fig:concepts:wdir"/> mostra il normale stato della directory di lavoro, in cui la directory ha un singolo changeset come genitore. Quel changeset è la <emphasis>punta</emphasis>, il changeset più recente senza figli nel repository.</para>
   1.207  
   1.208        <figure id="fig:concepts:wdir-after-commit">
   1.209  	<title>La directory di lavoro acquisisce nuovi genitori dopo un commit</title>
   1.210 @@ -175,15 +175,15 @@
   1.211  	</mediaobject>
   1.212        </figure>
   1.213  
   1.214 -      <para id="x_30f">&Egrave; utile pensare alla directory di lavoro come al <quote>changeset che sto per inserire</quote>. Qualsiasi file che avete detto a Mercurial di avere aggiunto, rimosso, rinominato, o copiato verrà riflesso in quel changeset, così come le modifiche a qualsiasi file che Mercurial sta già tracciando; il nuovo changeset acquisirà i genitori della directory di lavoro come i propri.</para>
   1.215 -
   1.216 -      <para id="x_310">Dopo un commit, Mercurial aggiornerà i genitori della directory di lavoro, in modo che il primo genitore sia l'identificatore del nuovo changeset e il secondo sia l'identificatore nullo. Questo viene mostrato nella <xref linkend="fig:concepts:wdir-after-commit"/>. Mercurial non tocca alcun file nella directory di lavoro quando eseguite un commit, ma si limita a modificare il dirstate per annotare i suoi nuovi genitori.</para>
   1.217 +      <para id="x_30f">&Egrave; utile pensare alla directory di lavoro come al <quote>changeset che state per inserire</quote>. Le azioni compiute su qualsiasi file che abbiate detto a Mercurial di avere aggiunto, rimosso, rinominato, o copiato verranno riflesse in quel changeset, così come le modifiche a qualsiasi file che Mercurial aveva già registrato. Il nuovo changeset acquisirà come propri genitori quelli della directory di lavoro.</para>
   1.218 +
   1.219 +      <para id="x_310">Dopo un commit, Mercurial aggiornerà i genitori della directory di lavoro in modo che il primo genitore sia l'identificatore del nuovo changeset e il secondo sia l'identificatore nullo, come mostrato nella <xref linkend="fig:concepts:wdir-after-commit"/>. Mercurial non tocca alcun file nella directory di lavoro quando eseguite un commit, ma si limita a modificare il dirstate per annotare i nuovi genitori della directory.</para>
   1.220  
   1.221      </sect2>
   1.222      <sect2>
   1.223        <title>Creare una nuova testa</title>
   1.224  
   1.225 -      <para id="x_311">&Egrave; perfettamente normale aggiornare la directory di lavoro a un changeset diverso dalla punta corrente. Per esempio, potreste voler sapere come il vostro progetto appariva lo scorso martedì, oppure potreste stare guardando attraverso i changeset per vedere quale ha introdotto un bug. In casi come questo, la cosa naturale da fare è aggiornare la directory di lavoro al changeset che vi interessa e poi esaminare i file direttamente nella directory di lavoro per vedere com'erano i loro contenuti quando avevate inserito quel changeset. Gli effetti di questa azione si possono vedere nella <xref linkend="fig:concepts:wdir-pre-branch"/>.</para>
   1.226 +      <para id="x_311">&Egrave; perfettamente normale aggiornare la directory di lavoro a un changeset diverso dalla punta corrente. Per esempio, potreste voler sapere come il vostro progetto appariva lo scorso martedì, oppure potreste dover scorrere i changeset per trovare quello che ha introdotto un bug. In questi casi, la cosa naturale da fare è aggiornare la directory di lavoro al changeset che vi interessa e poi esaminare i file direttamente nella directory di lavoro per vedere quali erano i loro contenuti quando avete inserito quel changeset. Gli effetti di questa azione si possono vedere nella <xref linkend="fig:concepts:wdir-pre-branch"/>.</para>
   1.227  
   1.228        <figure id="fig:concepts:wdir-pre-branch">
   1.229  	<title>La directory di lavoro, aggiornata a un vecchio changeset</title>
   1.230 @@ -193,7 +193,7 @@
   1.231  	</mediaobject>
   1.232        </figure>
   1.233  
   1.234 -      <para id="x_313">Avendo aggiornato la directory di lavoro a un vecchio changeset, cosa succede se apportate alcuni cambiamenti e poi li inserite? Mercurial si comporta nello stesso modo delineato in precedenza. I genitori della directory di lavoro diventano i genitori del nuovo changeset. Questo nuovo changeset non ha figli, quindi diventa la nuova punta. E il repository ora contiene due changeset che non hanno figli, che vengono chiamati <emphasis>teste</emphasis>. Potete vedere la struttura creata da questa operazione nella <xref linkend="fig:concepts:wdir-branch"/>.</para>
   1.235 +      <para id="x_313">Avendo aggiornato la directory di lavoro a un vecchio changeset, cosa succede se apportate alcuni cambiamenti e poi li inserite? Mercurial si comporta nello stesso modo delineato in precedenza. I genitori della directory di lavoro diventano i genitori del nuovo changeset. Questo nuovo changeset non ha figli, quindi diventa la nuova punta. E il repository ora contiene due changeset senza figli che vengono chiamati <emphasis>teste</emphasis>. Potete vedere la struttura creata da questa operazione nella <xref linkend="fig:concepts:wdir-branch"/>.</para>
   1.236  
   1.237        <figure id="fig:concepts:wdir-branch">
   1.238  	<title>La situazione dopo un commit effettuato su un aggiornamento a un vecchio changeset</title>
   1.239 @@ -204,16 +204,16 @@
   1.240        </figure>
   1.241  
   1.242        <note>
   1.243 -	<para id="x_315">Se Mercurial vi è nuovo, dovreste tenere a mente un <quote>errore</quote> comune, che è quello di usare il comando <command role="hg-cmd">hg pull</command> senza alcuna opzione. Di default, il comando <command role="hg-cmd">hg pull</command> <emphasis>non</emphasis> aggiorna la directory di lavoro, così propagherete nuovi cambiamenti nel vostro repository, ma la directory di lavoro rimarrà sincronizzata allo stesso changeset in cui era prima della propagazione. Se ora effettuate alcuni cambiamenti e poi li inserite, creerete una nuova testa, perché la vostra directory di lavoro non è stata sincronizzata a qualunque revisione fosse la punta in quel momento. Per combinare le operazioni di estrazione e aggiornamento, eseguite <command>hg pull -u</command>.</para>
   1.244 -
   1.245 -	<para id="x_316">Ho messo la parola <quote>errore</quote> tra virgolette perché tutto quello che dovete fare per rettificare la situazione in cui avete creato una nuova testa per sbaglio è eseguire il comando <command role="hg-cmd">hg merge</command> seguito da <command role="hg-cmd">hg commit</command>. In altre parole, questo errore non ha quasi mai conseguenze negative; è solo qualcosa che può sorprendere gli utenti alle prime armi. Più tardi, discuterò altri modi per evitare questo comportamento, e le ragioni per cui Mercurial si comporta in questo modo inizialmente sorprendente.</para>
   1.246 +	<para id="x_315">Se avete appena cominciato a lavorare con Mercurial, dovreste tenere a mente un <quote>errore</quote> comune, che è quello di usare il comando <command role="hg-cmd">hg pull</command> senza alcuna opzione. Di default, il comando <command role="hg-cmd">hg pull</command> <emphasis>non</emphasis> aggiorna la directory di lavoro, ma propagherà i nuovi cambiamenti nel vostro repository lasciandola sincronizzata allo stesso changeset in cui si trovava prima della propagazione. Se ora effettuate alcuni cambiamenti e poi li inserite, creerete una nuova testa, perché la vostra directory di lavoro non è stata sincronizzata alla revisione di punta corrente. Per combinare le operazioni di estrazione e aggiornamento, eseguite <command>hg pull -u</command>.</para>
   1.247 +
   1.248 +	<para id="x_316">Ho messo la parola <quote>errore</quote> tra virgolette perché tutto quello che dovete fare per rettificare la situazione in cui avete creato una nuova testa per sbaglio è eseguire il comando <command role="hg-cmd">hg merge</command> seguito da <command role="hg-cmd">hg commit</command>. In altre parole, questo errore non ha quasi mai conseguenze negative, ma è solo qualcosa che può sorprendere i nuovi utenti. Più avanti, discuterò altri modi per evitare questo comportamento e le ragioni per cui Mercurial si comporta in questo modo inizialmente sorprendente.</para>
   1.249        </note>
   1.250  
   1.251      </sect2>
   1.252      <sect2>
   1.253        <title>Unire i cambiamenti</title>
   1.254  
   1.255 -      <para id="x_317">Quando eseguite il comando <command role="hg-cmd">hg merge</command>, Mercurial lascia intonso il primo genitore della directory di lavoro e imposta il secondo genitore al cambiamento che state incorporando, come mostrato nella <xref linkend="fig:concepts:wdir-merge"/>.</para>
   1.256 +      <para id="x_317">Quando eseguite il comando <command role="hg-cmd">hg merge</command>, Mercurial lascia invariato il primo genitore della directory di lavoro e imposta il secondo genitore al cambiamento che state incorporando, come mostrato nella <xref linkend="fig:concepts:wdir-merge"/>.</para>
   1.257  
   1.258        <figure id="fig:concepts:wdir-merge">
   1.259  	<title>Unire due teste</title>
   1.260 @@ -225,59 +225,59 @@
   1.261  	</mediaobject>
   1.262        </figure>
   1.263  
   1.264 -      <para id="x_319">Mercurial deve anche modificare la directory di lavoro, per unire i file gestiti dai due changeset. Semplificando un poco, il processo di unione funziona in questo modo, per ogni file contenuto nei manifest di entrambi i changeset.</para>
   1.265 +      <para id="x_319">Mercurial deve anche modificare la directory di lavoro, per unire i file gestiti dai due changeset. Semplificandolo un po', il processo di unione funziona in questo modo, per ogni file contenuto nei manifest di entrambi i changeset.</para>
   1.266        <itemizedlist>
   1.267  	<listitem><para id="x_31a">Se nessuno dei changeset ha modificato il file, non fare nulla con quel file.</para>
   1.268  	</listitem>
   1.269 -	<listitem><para id="x_31b">Se un changeset ha modificato il file, e l'altro non lo ha modificato, crea la copia modificata del file nella directory di lavoro.</para>
   1.270 -	</listitem>
   1.271 -	<listitem><para id="x_31c">Se un changeset ha rimosso un file, e l'altro no (o anche l'altro lo ha cancellato), cancella il file dalla directory di lavoro.</para>
   1.272 -	</listitem>
   1.273 -	<listitem><para id="x_31d">Se un changeset ha cancellato un file, ma l'altro lo ha modificato, chiedi all'utente cosa vuole fare: tenere il file modificato oppure rimuoverlo?</para>
   1.274 -	</listitem>
   1.275 -	<listitem><para id="x_31e">Se entrambi i changeset hanno modificato un file, richiama un programma di unione esterno per scegliere i contenuti del file da unire. Questo potrebbe richiedere informazioni da parte dell'utente.</para>
   1.276 -	</listitem>
   1.277 -	<listitem><para id="x_31f">Se un changeset ha modificato un file, e l'altro ha rinominato o copiato il file, assicurati che i cambiamenti seguano il nuovo nome del file.</para>
   1.278 +	<listitem><para id="x_31b">Se un changeset ha modificato il file e l'altro non lo ha modificato, crea la copia modificata del file nella directory di lavoro.</para>
   1.279 +	</listitem>
   1.280 +	<listitem><para id="x_31c">Se un changeset ha rimosso un file e l'altro no (o se anche l'altro lo ha cancellato), cancella il file dalla directory di lavoro.</para>
   1.281 +	</listitem>
   1.282 +	<listitem><para id="x_31d">Se un changeset ha cancellato un file ma l'altro lo ha modificato, chiedi all'utente cosa vuole fare: tenere il file modificato oppure rimuoverlo?</para>
   1.283 +	</listitem>
   1.284 +	<listitem><para id="x_31e">Se entrambi i changeset hanno modificato un file, richiama un programma di unione esterno per scegliere i contenuti del file da unire. Questa operazione potrebbe richiedere un'interazione con l'utente.</para>
   1.285 +	</listitem>
   1.286 +	<listitem><para id="x_31f">Se un changeset ha modificato un file e l'altro lo ha rinominato o copiato, assicurati che i cambiamenti seguano il nuovo nome del file.</para>
   1.287  	</listitem></itemizedlist>
   1.288 -      <para id="x_320">L'operazione ha molti altri dettagli&emdash;le unioni sono piene di casi particolari&emdash;ma queste sono le scelte più comuni coinvolte nel processo di unione. Come potete vedere, la maggior parte dei casi sono completamente automatizzati, e in effetti la maggior parte delle unioni termina automaticamente senza richiedere il vostro intervento per risolvere alcun conflitto.</para>
   1.289 -
   1.290 -      <para id="x_321">Se pensate a quello che succede quando effettuate un commit dopo un'unione, ancora una volta la directory di lavoro è <quote>il changeset che state per inserire</quote>. Dopo che il comando <command role="hg-cmd">hg merge</command> ha terminato, la directory di lavoro possiede due genitori; questi diventeranno i genitori del nuovo changeset.</para>
   1.291 -
   1.292 -      <para id="x_322">Mercurial vi lascia effettuare molteplici unioni, ma dovete inserire i risultati di ogni singola unione man mano che procedete. Questo è necessario perché Mercurial tiene traccia solamente di due genitori sia per le revisioni che per la directory di lavoro. Mentre sarebbe tecnicamente fattibile unire molteplici changeset alla volta, Mercurial evita di farlo per semplicità. Con unioni a più vie, il rischio di confondere l'utente, di incappare in conflitti sgradevoli da risolvere e di fare una terribile confusione in un'unione diventerebbe intollerabile.</para>
   1.293 +      <para id="x_320">Ci sono molti altri dettagli&emdash;le unioni sono piene di casi particolari&emdash;ma queste sono le scelte più comuni coinvolte nel processo di unione. Come potete vedere, la maggior parte dei casi è completamente automatizzata e in effetti la maggior parte delle unioni termina automaticamente senza richiedere il vostro intervento per risolvere alcun conflitto.</para>
   1.294 +
   1.295 +      <para id="x_321">Se considerate quello che succede quando effettuate un commit dopo un'unione, ancora una volta la directory di lavoro è <quote>il changeset che state per inserire</quote>. Dopo che il comando <command role="hg-cmd">hg merge</command> ha terminato, la directory di lavoro possiede due genitori, che poi diventeranno i genitori del nuovo changeset.</para>
   1.296 +
   1.297 +      <para id="x_322">Mercurial vi permette di effettuare molteplici unioni, ma dovete inserire i risultati di ogni singola unione man mano che procedete, perché Mercurial tiene traccia solamente di due genitori sia per le revisioni che per la directory di lavoro. Anche se unire molteplici changeset alla volta sarebbe tecnicamente possibile, Mercurial evita di farlo per semplicità. Con unioni a più vie, il rischio di confondere l'utente, di incappare in conflitti sgradevoli da risolvere e di fare una terribile confusione durante il processo di unione diventerebbe intollerabile.</para>
   1.298  
   1.299      </sect2>
   1.300  
   1.301      <sect2>
   1.302        <title>Le unioni e i cambiamenti di nome</title>
   1.303  
   1.304 -      <para id="x_69a">Un numero sorprendente di sistemi di controllo di revisione dedica poca o addirittura nessuna attenzione al <emphasis>nome</emphasis> di un file ~over time~. Per esempio, era pratica comune che se un file venisse rinominato in una delle due parti di un'unione, i cambiamenti dell'altra parte sarebbero stati silenziosamente scartati.</para>
   1.305 -
   1.306 -      <para id="x_69b">Mercurial registra metadati quando gli dite di effettuare una cambiamento di nome o una copia. Usa questi metadati durante le unioni per comportarsi in maniera appropriata. Per esempio, se modifico il nome di un file, e voi lo modificate senza rinominarlo, quando uniamo i nostri cambiamenti il file verrà rinominato e gli verranno applicate le vostre modifiche.</para>
   1.307 +      <para id="x_69a">Un numero sorprendente di sistemi di controllo di revisione dedica poca o addirittura nessuna attenzione ai cambiamenti del <emphasis>nome</emphasis> di un file nel tempo. Per esempio, era pratica comune scartare silenziosamente le modifiche a un file contenute in una delle due parti di un'unione se quel file fosse stato rinominato nell'altra parte.</para>
   1.308 +
   1.309 +      <para id="x_69b">Mercurial registra alcuni metadati quando gli dite di effettuare una cambiamento di nome o una copia e li usa durante le unioni per comportarsi in maniera appropriata. Per esempio, se io cambio il nome di un file che voi modificate senza rinominare, quando uniamo i nostri cambiamenti il file verrà rinominato e gli verranno applicate le vostre modifiche.</para>
   1.310      </sect2>
   1.311    </sect1>
   1.312  
   1.313    <sect1>
   1.314      <title>Altre caratteristiche di progettazione interessanti</title>
   1.315  
   1.316 -    <para id="x_323">Nelle sezioni precedenti, ho provato a evidenziare alcuni degli aspetti più importanti nella progettazione di Mercurial, per illustrare come dedichi la dovuta attenzione a prestazioni e affidabilità. Tuttavia, l'attenzione ai dettagli non finisce lì. Ci sono un certo numero di altri aspetti nella costruzione di Mercurial che trovo personalmente interessanti. Ne dettaglierò alcuni qui, separatamente dagli elementi ~<quote>big ticket</quote>~ analizzati finora, in modo che se siete interessati potete farvi un'idea più precisa della quantità di riflessioni che serve per realizzare un sistema ben progettato.</para>
   1.317 +    <para id="x_323">Nelle sezioni precedenti, ho provato a evidenziare alcuni degli aspetti più importanti nella progettazione di Mercurial, per illustrare come sia stata dedicata la dovuta attenzione a prestazioni e affidabilità. Tuttavia, l'attenzione ai dettagli non finisce lì. Ci sono un certo numero di altri aspetti nella costruzione di Mercurial che trovo personalmente interessanti. Ne descriverò alcuni qui, separatamente dagli elementi <quote>di primo piano</quote> analizzati finora, in modo che se siete interessati potete farvi un'idea più precisa di quanti ragionamenti ci sono dietro a un sistema ben progettato.</para>
   1.318  
   1.319      <sect2>
   1.320        <title>Compressione intelligente</title>
   1.321  
   1.322 -      <para id="x_324">Quando è appropriato, Mercurial memorizzera sia la fotografia che le delta in forma compressa. Fa questo <emphasis>cercando</emphasis> sempre di comprimere una fotografia o una delta, ma memorizzando la versione compressa solo se è più piccola della versione originale.</para>
   1.323 -
   1.324 -      <para id="x_325">Questo significa che Mercurial fa <quote>la cosa giusta</quote> quando memorizza un file il cui formato sia già compresso, come un archivio <literal>zip</literal> o un'immagine JPEG. Quando questi tipi di file sono compressi una seconda volta, il file risultante è tipicamente più grande del file originale, così Mercurial memorizzerà la prima versione semplice del file <literal>zip</literal> o <literal>JPEG</literal>.</para>
   1.325 -
   1.326 -      <para id="x_326">Le delta tra le revisioni di un file compresso sono di solito più grandi delle fotografie del file, e Mercurial ancora una volta fa <quote>la cosa giusta</quote> in questi casi. Scopre che tale delta oltrepassa la soglia alla quale dovrebbe memorizzare una fotografia completa del file, quindi memorizza la fotografia, risparmiando ancora spazio nei confronti di un approccio ingenuo basato solo sulle delta.</para>
   1.327 +      <para id="x_324">Quando è appropriato, Mercurial memorizzerà sia la fotografia che le delta in forma compressa, <emphasis>cercando</emphasis> sempre di comprimere una fotografia o una delta, ma memorizzando la versione compressa solo se è più piccola della versione originale.</para>
   1.328 +
   1.329 +      <para id="x_325">Questo significa che Mercurial fa <quote>la cosa giusta</quote> quando memorizza un file il cui formato sia già compresso, come un archivio <literal>zip</literal> o un'immagine JPEG. Quando questi tipi di file vengono compressi una seconda volta, il file risultante è tipicamente più grande di quello originale, così Mercurial memorizzerà la versione iniziale del file <literal>zip</literal> o JPEG.</para>
   1.330 +
   1.331 +      <para id="x_326">Di solito, le delta tra le revisioni di un file compresso sono più grandi delle fotografie del file, ma anche in questi casi Mercurial fa <quote>la cosa giusta</quote> ancora una volta. Scopre che tale delta supera la soglia oltre la quale dovrebbe registrare una fotografia completa del file e quindi memorizza la fotografia, risparmiando ancora spazio nei confronti di un approccio ingenuo basato solo sulle delta.</para>
   1.332  
   1.333        <sect3>
   1.334  	<title>Ricompressione di rete</title>
   1.335  
   1.336  	<para id="x_327">Nel memorizzare le revisioni su disco, Mercurial usa l'algoritmo di compressione <quote>deflate</quote> (lo stesso usato dal popolare formato <literal>zip</literal>), che bilancia una buona velocità con un rispettabile rapporto di compressione. Tuttavia, quando trasmette i dati di una revisione attraverso una connessione di rete, Mercurial decomprime i dati di revisione compressi.</para>
   1.337  
   1.338 -	<para id="x_328">Se la connessione usa il protocollo HTTP, Mercurial ricomprime l'intero flusso di dati usando un algoritmo di compressione che ha un rapporto di compressione migliore (l'algoritmo Burrows-Wheeler del pacchetto di compressione <literal>bzip2</literal> largamente utilizzato). Questa combinazinoe di algoritmo e compressione dell'intero flusso (invece di una revisione alla volta) riduce sostanzialmente il numero di byte da trasferire, producendo prestazioni di rete migliori sulla maggior parte delle reti.</para>
   1.339 -
   1.340 -	<para id="x_329">Se la connessione usa <command>ssh</command>, Mercurial <emphasis>non</emphasis> ricomprime il flusso, perché <command>ssh</command> è già in grado di farlo da solo. Potete dire a Mercurial di usare sempre le funzionalità di compressione di <command>ssh</command> modificando il file <filename>.hgrc</filename> che si trova nella vostra directory personale nel modo seguente.</para>
   1.341 +	<para id="x_328">Se la connessione avviene via HTTP, Mercurial ricomprime l'intero flusso di dati usando un algoritmo che ha un rapporto di compressione migliore (l'algoritmo Burrows-Wheeler del rinomato pacchetto di compressione <literal>bzip2</literal>). Questa combinazione di algoritmo e compressione dell'intero flusso (invece di una revisione alla volta) riduce sostanzialmente il numero di byte da trasferire, producendo prestazioni di rete migliori sulla maggior parte delle reti.</para>
   1.342 +
   1.343 +	<para id="x_329">Se la connessione avviene via <command>ssh</command>, Mercurial <emphasis>non</emphasis> ricomprime il flusso, perché <command>ssh</command> è già in grado di farlo da sé. Potete dire a Mercurial di usare sempre le funzionalità di compressione di <command>ssh</command> modificando il file <filename>.hgrc</filename> che si trova nella vostra directory personale nel modo seguente.</para>
   1.344  
   1.345  	<programlisting>[ui]
   1.346  ssh = ssh -C</programlisting>
   1.347 @@ -287,60 +287,60 @@
   1.348      <sect2>
   1.349        <title>Ordinamento e atomicità delle operazioni di lettura e scrittura</title>
   1.350  
   1.351 -      <para id="x_32a">Aggiungere in coda a un file non è tutta la storia quando si cerca di garantire che una lettura non veda scritture parziali. Se ricordate la <xref linkend="fig:concepts:metadata"/>, le revisioni in un changelog puntano alle revisioni nel manifest, e le revisioni nel manifest puntano alle revisioni nel filelog. Questa gerarchia è intenzionale.</para>
   1.352 -
   1.353 -      <para id="x_32b">Una operazione di scrittura avvia una transazione modificando i dati nel filelog e nel manifest, e non modifica alcun dato contenuto nel changelog fino a quando quelli hanno terminato. Una operazione di lettura comincia leggendo i dati nel changelog, poi i dati nel manifest, seguiti dai dati nel filelog.</para>
   1.354 -
   1.355 -      <para id="x_32c">Dato che la scrittura ha sempre terminato di modificare i dati nel filelog e nel manifest prima di modificare il changelog, una lettura non vedrà mai un puntatore dal changelog verso una revisione parzialmente modificata nel manifest, e non vedrà mai un puntatore dal manifest verso a una revisione parzialmente modificata nel filelog.</para>
   1.356 +      <para id="x_32a">Quando si cerca di garantire che una lettura non veda scritture parziali, non è sufficiente limitarsi ad aggiungere in coda ai file le nuove informazioni. Se ricordate la <xref linkend="fig:concepts:metadata"/>, le revisioni in un changelog puntano alle revisioni nel manifest e le revisioni nel manifest puntano alle revisioni nel filelog. Questa gerarchia è intenzionale.</para>
   1.357 +
   1.358 +      <para id="x_32b">Un'operazione di scrittura avvia una transazione modificando i dati nel filelog e nel manifest, senza modificare alcun dato contenuto nel changelog prima che quelli abbiano terminato. Un'operazione di lettura comincia leggendo i dati nel changelog, poi i dati nel manifest seguiti dai dati nel filelog.</para>
   1.359 +
   1.360 +      <para id="x_32c">Dato che la scrittura ha sempre terminato di modificare i dati nel filelog e nel manifest prima di modificare il changelog, una lettura non vedrà mai il changelog puntare verso una revisione parzialmente modificata del manifest e non vedrà mai il manifest puntare verso una revisione parzialmente modificata del filelog.</para>
   1.361  
   1.362      </sect2>
   1.363      <sect2>
   1.364        <title>Accesso concorrente</title>
   1.365  
   1.366 -      <para id="x_32d">Le garanzie sull'ordinamento e sull'atomicità delle operazioni di lettura significano che Mercurial non avrà mai bisogno di <emphasis>bloccare</emphasis> un repository di cui sta leggendo i dati, anche se il repository sta venendo modificato mentre la lettura sta accadendo. Questo ha un importante effetto sulla scalabilità; potete avere un numero arbitrario di processi Mercurial che in sicurezza leggono contemporaneamente i dati da un repository, senza preoccuparvi che stia venendo modificato oppure no.</para>
   1.367 -
   1.368 -      <para id="x_32e">La natura delle letture prive di blocchi significa che se state condividendo un repository su un sistema multi-utente, non avete bisogno di concedere ad altri utenti locali i permessi di <emphasis>scrittura</emphasis> al vostro repository per renderli in grado di clonarlo o estrarne i cambiamenti; essi hanno bisogno solo dei permessi di <emphasis>lettura</emphasis>. (Questa <emphasis>non</emphasis> è una caratteristica comune tra i sistemi di controllo di revisione, quindi non datela per scontata! La maggior parte dei sistemi richiede che i lettori siano in grado di bloccare un repository per accederlo in sicurezza, cosa che naturalmente provoca tutti i tipi di sgradevoli e fastidiosi problemi di sicurezza e amministrazione.)</para>
   1.369 -
   1.370 -      <para id="x_32f">Mercurial usa i blocchi per assicurarsi che un solo processo alla volta possa effettuare modifiche a un repository (il meccanismo di bloccaggio è sicuro persino su file system che sono notoriamente ostili ai blocchi, come NFS). Se un repository è blocato, una operazione di scrittura aspetterà per qualche tempo prima di riprovare se il repository si è sbloccato, ma se il repository rimane bloccato troppo a lungo, dopo un po' il processo che sta tentando di scrivere ~will time out~. Questo significa che il vostri script automatici non rimarranno bloccati per sempre accumulandosi se un sistema dovesse innavvertitamente cadere, per esempio. (Sì, il valore del timeout è configurabile, da zero a infinito.)</para>
   1.371 +      <para id="x_32d">Le garanzie sull'ordinamento e sull'atomicità delle operazioni di lettura significano che Mercurial non avrà mai bisogno di <emphasis>bloccare</emphasis> un repository da cui sta leggendo i dati, anche se il repository viene modificato mentre la lettura è in corso. Questo ha un importante effetto sulla scalabilità: potete avere un numero arbitrario di processi Mercurial che contemporaneamente leggono in sicurezza i dati da un repository, senza preoccuparvi che qualcun altro lo stia modificando oppure no.</para>
   1.372 +
   1.373 +      <para id="x_32e">La mancanza di un blocco durante la lettura significa che, se state condividendo un repository su un sistema multi-utente, non avete bisogno di concedere ad altri utenti locali i permessi di <emphasis>scrittura</emphasis> al vostro repository per consentire loro di clonarlo o estrarne i cambiamenti, ma saranno sufficienti i permessi di <emphasis>lettura</emphasis>. (Questa <emphasis>non</emphasis> è una caratteristica comune tra i sistemi di controllo di revisione, quindi non datela per scontata! La maggior parte dei sistemi richiede che i lettori siano in grado di bloccare un repository per accederlo in sicurezza, cosa che naturalmente provoca ogni tipo di sgradevoli e fastidiosi problemi di sicurezza e amministrazione.)</para>
   1.374 +
   1.375 +      <para id="x_32f">Mercurial usa i blocchi per assicurarsi che un solo processo alla volta possa effettuare modifiche a un repository (il meccanismo di bloccaggio è sicuro persino su file system che sono notoriamente avversi ai blocchi, come NFS). Se un repository è bloccato, un'operazione di scrittura aspetterà per qualche tempo prima di ricontrollare se il repository si è sbloccato, ma se il repository rimane bloccato troppo a lungo, dopo un po' il processo che sta tentando di scrivere andrà in timeout. Questo significa, per esempio, che il vostri script automatici non rimarranno bloccati per sempre accumulandosi l'uno sull'altro se un sistema dovesse innavvertitamente cadere. (Sì, il valore del timeout è configurabile, da zero a infinito.)</para>
   1.376  
   1.377        <sect3>
   1.378  	<title>Accesso sicuro al dirstate</title>
   1.379  
   1.380 -	<para id="x_330">Come con i dati di revisione, Mercurial non impiega un blocco per leggere il file di dirstate; acquisisce un blocco per modificarlo. Per evitare la possibilità di leggere una copia parzialmente modificata di un file di dirstate, Mercurial scrive su un file con un nome unico nella stessa directory del file di dirstate, poi cambia il nome del file temporaneo a <filename>dirstate</filename> in maniera atomica. Il file chiamato <filename>dirstate</filename> quindi è garantito di essere completo, non parzialmente modificato.</para>
   1.381 +	<para id="x_330">Come con i dati di revisione, Mercurial non blocca il file di dirstate per leggerlo, ma acquisisce un blocco solo per modificarlo. Per evitare la possibilità di leggere una copia parzialmente modificata di un file di dirstate, Mercurial scrive su un file con un nome unico nella stessa directory del file di dirstate, poi cambia il nome del file temporaneo a <filename>dirstate</filename> in maniera atomica. In questo modo si garantisce che il file chiamato <filename>dirstate</filename> sia sempre completo e mai parzialmente modificato.</para>
   1.382  
   1.383        </sect3>
   1.384      </sect2>
   1.385      <sect2>
   1.386        <title>Evitare le operazioni di seek</title>
   1.387  
   1.388 -      <para id="x_331">Un aspetto critico delle prestazioni di Mercurial è quello di evitare le operazioni di seek della testina del disco, dato che ognuna di queste operazioni è molto più dispendiosa persino di una operazione di lettura relativamente grande.</para>
   1.389 -
   1.390 -      <para id="x_332">Questa è la ragione per cui, per esempio, il dirstate è memorizzato in un singolo file. Se ci fosse un file di dirstate per ogni directory che Mercurial traccia, il disco effettuerebbe un'operazione di seek una volta per directory. Invece, Mercurial legge l'intero file di dirstate in un singolo passo.</para>
   1.391 -
   1.392 -      <para id="x_333">Mercurial adotta anche una strategia <quote>copy-on-write</quote> quando clona un repository su disco locale. Invece di copiare ogni file di revlog dal vecchio repository al nuovo, utilizza <quote>collegamenti fisici</quote> per indicare che <quote>due nomi puntano allo stesso file</quote>. Quando Mercurial sta per modificare uno dei file di revlog, controlla per vedere se il numero di nomi che puntano al file è più grande di uno. Se è così, questo significa che più di un repository sta usando il file, quindi Mercurial ne fa una nuova copia riservata a questo repository.</para>
   1.393 -
   1.394 -      <para id="x_334">Alcuni sviluppatori di sistemi per il controllo di revisione hanno fatto notare che questa idea di fare una copia privata completa di un file non è molto efficiente nel suo uso di spazio su disco. Sebbene sia vero, lo spazio su disco è economico, e questo metodo consente di avere le prestazioni migliori rinviando la maggior parte della contabilità al sistema operativo. Una strategia alternativa molto probabilmente ridurrebbe le prestazioni e aumenterebbe la complessità del software, ma velocità e semplicità sono aspetti chiave per la <quote>facilità</quote> nell'uso quotidiano.</para>
   1.395 +      <para id="x_331">Un aspetto critico delle prestazioni di Mercurial è quello di evitare le operazioni di seek della testina del disco, dato che ognuna di queste operazioni è molto più dispendiosa persino di un'operazione di lettura relativamente grande.</para>
   1.396 +
   1.397 +      <para id="x_332">Questa è la ragione per cui, per esempio, il dirstate è memorizzato in un singolo file. Se ci fosse un file di dirstate per ogni directory registrata da Mercurial, il disco effettuerebbe un'operazione di seek per ciascuna directory. Invece, Mercurial legge l'intero file di dirstate in un singolo passo.</para>
   1.398 +
   1.399 +      <para id="x_333">Mercurial adotta anche una strategia <quote>copy-on-write</quote> per clonare un repository su disco locale. Invece di copiare ogni file di revlog dal vecchio repository al nuovo, utilizza <quote>collegamenti fisici</quote> per indicare che <quote>due nomi puntano allo stesso file</quote>. Quando Mercurial sta per modificare uno dei file di revlog, controlla per vedere se il numero di nomi che puntano al file è più grande di uno. Se è così, questo significa che più di un repository sta usando il file, quindi Mercurial ne crea una nuova copia riservata a questo repository.</para>
   1.400 +
   1.401 +      <para id="x_334">Alcuni sviluppatori di sistemi per il controllo di revisione hanno fatto notare che la creazione di una copia privata completa di un file non usa lo spazio su disco in maniera molto efficiente. Sebbene questo sia vero, lo spazio su disco è piuttosto economico, e questo metodo consente di avere le prestazioni migliori rinviando la maggior parte della contabilità al sistema operativo. Molto probabilmente, una strategia alternativa ridurrebbe le prestazioni e aumenterebbe la complessità del software, ma velocità e semplicità sono aspetti chiave per la <quote>facilità</quote> nell'uso quotidiano.</para>
   1.402  
   1.403      </sect2>
   1.404      <sect2>
   1.405        <title>Altre informazioni contenute nel dirstate</title>
   1.406  
   1.407 -      <para id="x_335">Dato che Mercurial non vi obbliga a dirgli quando state modificando un file, usa il dirstate per memorizzare alcune informazioni aggiuntive in modo da poter determinare efficientemente se avete modificato un file. Per ogni file nella directory di lavoro, memorizza la data in cui lo ha modificato per l'ultima volta e la dimensione che il file aveva in quel momento.</para>
   1.408 -
   1.409 -      <para id="x_336">Quando utilizzate esplicitamente <command role="hg-cmd">hg add</command>, <command role="hg-cmd">hg remove</command>, <command role="hg-cmd">hg rename</command>, o <command role="hg-cmd">hg copy</command> su un file, Mercurial aggiorna il dirstate in modo che sappia cosa fare con quei file quando effettuate un commit.</para>
   1.410 +      <para id="x_335">Dato che Mercurial non vi obbliga a dirgli quando state modificando un file, usa il dirstate per memorizzare alcune informazioni aggiuntive in modo da poter determinare efficientemente se avete modificato un file. Per ogni file nella directory di lavoro, memorizza la data in cui lo ha registrato per l'ultima volta e la dimensione che il file aveva in quel momento.</para>
   1.411 +
   1.412 +      <para id="x_336">Quando utilizzate esplicitamente <command role="hg-cmd">hg add</command>, <command role="hg-cmd">hg remove</command>, <command role="hg-cmd">hg rename</command>, o <command role="hg-cmd">hg copy</command> su un file, Mercurial aggiorna il dirstate in modo che sappia cosa fare con quel file quando effettuate un commit.</para>
   1.413  
   1.414        <para id="x_337">Il dirstate aiuta Mercurial a controllare in maniera efficiente lo stato dei file in un repository.</para>
   1.415  
   1.416        <itemizedlist>
   1.417  	<listitem>
   1.418 -	  <para id="x_726">Quando Mercurial controlla lo stato di un file nella directory di lavoro, prima confronta la data dell'ultima modifica del file con la data registrata nel dirstate che indica quando Mercurial ha modificato quel file per l'ultima volta. Se le due date sono le stesse, il file non deve essere stato modificato, quindi Mercurial non ha bisogno di fare ulteriori controlli.</para>
   1.419 +	  <para id="x_726">Quando Mercurial controlla lo stato di un file nella directory di lavoro, per prima cosa confronta la data dell'ultima modifica del file con la data registrata nel dirstate che indica quando Mercurial ha registrato quel file per l'ultima volta. Se le due date sono le stesse, il file non deve essere stato modificato, quindi Mercurial non ha bisogno di fare ulteriori controlli.</para>
   1.420  	</listitem>
   1.421  	<listitem>
   1.422  	  <para id="x_727">Se la dimensione del file è cambiata, il file deve essere stato modificato. Solo nel caso in cui la data di modifica sia cambiata, ma non la dimensione, Mercurial ha effettivamente bisogno di leggere i contenuti del file per vedere se è stato modificato.</para>
   1.423  	</listitem>
   1.424        </itemizedlist>
   1.425  
   1.426 -      <para id="x_728">Memorizzare le dimensioni e la data di ultima modifica riduce drammaticamente il numero di operazioni di lettura che Mercurial deve effettuare quando eseguiamo comandi come <command>hg status</command>. Questo risulta in ampi miglioramenti delle prestazioni.</para>
   1.427 +      <para id="x_728">Memorizzare le dimensioni e la data di ultima modifica riduce drammaticamente il numero di operazioni di lettura che Mercurial deve effettuare quando eseguiamo comandi come <command>hg status</command>. Da questo stratagemma deriva un notevole miglioramento delle prestazioni.</para>
   1.428      </sect2>
   1.429    </sect1>
   1.430  </chapter>