1.1 --- a/it/ch04-concepts.xml	Sat Aug 15 22:40:31 2009 +0200
     1.2 +++ b/it/ch04-concepts.xml	Sun Aug 16 09:47:25 2009 +0200
     1.3 @@ -97,14 +97,14 @@
     1.4  	</mediaobject>
     1.5        </figure>
     1.6  
     1.7 -      <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.8 +      <para id="x_2fc">Il modo innovativo in cui Mercurial risolve 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.9  
    1.10        <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.11  
    1.12        <sect3>
    1.13  	<title>Digressione: l'influenza della compressione video</title>
    1.14  
    1.15 -	<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.16 +	<para id="x_2fe">Se avete familiarità con la compressione video o avete mai esaminato 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.17  
    1.18  	<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.19  
    1.20 @@ -113,7 +113,7 @@
    1.21      <sect2>
    1.22        <title>Identificazione e integrità forte</title>
    1.23  
    1.24 -      <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.25 +      <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 contraffare i contenuti di una revisione e facilita la scoperta di corruzioni accidentali dei dati.</para>
    1.26  
    1.27        <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.28  
    1.29 @@ -126,7 +126,7 @@
    1.30    <sect1>
    1.31      <title>Cronologia delle revisioni, ramificazioni e unioni</title>
    1.32  
    1.33 -    <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.34 +    <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 che <quote>non c'è alcun genitore qui</quote>. Questo hash è semplicemente una stringa di zeri.</para>
    1.35  
    1.36      <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.37  
    1.38 @@ -146,11 +146,11 @@
    1.39  
    1.40      <para id="x_307">Nella directory di lavoro, Mercurial mantiene una fotografia dei file contenuti nel repository scattata su un changeset particolare.</para>
    1.41  
    1.42 -    <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.43 +    <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.44  
    1.45      <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.46  
    1.47 -    <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.48 +    <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 la directory di lavoro 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.49  
    1.50      <sect2>
    1.51        <title>Cosa succede quando eseguite un commit</title>
    1.52 @@ -175,7 +175,7 @@
    1.53  	</mediaobject>
    1.54        </figure>
    1.55  
    1.56 -      <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.57 +      <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 aver 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.58  
    1.59        <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.60  
    1.61 @@ -225,7 +225,7 @@
    1.62  	</mediaobject>
    1.63        </figure>
    1.64  
    1.65 -      <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.66 +      <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 nel modo seguente, per ogni file contenuto nei manifest di entrambi i changeset.</para>
    1.67        <itemizedlist>
    1.68  	<listitem><para id="x_31a">Se nessuno dei changeset ha modificato il file, non fare nulla con quel file.</para>
    1.69  	</listitem>
    1.70 @@ -243,14 +243,14 @@
    1.71  
    1.72        <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.73  
    1.74 -      <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.75 +      <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 disorientare l'utente, di incappare in conflitti sgradevoli da risolvere e di fare una terribile confusione durante il processo di unione diventerebbe intollerabile.</para>
    1.76  
    1.77      </sect2>
    1.78  
    1.79      <sect2>
    1.80        <title>Le unioni e i cambiamenti di nome</title>
    1.81  
    1.82 -      <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.83 +      <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. 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.84  
    1.85        <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.86      </sect2>
    1.87 @@ -259,7 +259,7 @@
    1.88    <sect1>
    1.89      <title>Altre caratteristiche di progettazione interessanti</title>
    1.90  
    1.91 -    <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.92 +    <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 qui. Ci sono un certo numero di altri aspetti nella costruzione di Mercurial che trovo personalmente interessanti. Ne descriverò alcuni in questa sezione, 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.93  
    1.94      <sect2>
    1.95        <title>Compressione intelligente</title>
    1.96 @@ -268,16 +268,16 @@
    1.97  
    1.98        <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.99  
   1.100 -      <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.101 +      <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 quella delta supera la soglia oltre la quale Mercurial 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.102  
   1.103        <sect3>
   1.104  	<title>Ricompressione di rete</title>
   1.105  
   1.106  	<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.107  
   1.108 -	<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.109 -
   1.110 -	<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.111 +	<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 trasmissione migliori sulla maggior parte delle reti.</para>
   1.112 +
   1.113 +	<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 la funzione di compressione di <command>ssh</command> modificando il file <filename>.hgrc</filename> che si trova nella vostra directory personale nel modo seguente.</para>
   1.114  
   1.115  	<programlisting>[ui]
   1.116  ssh = ssh -C</programlisting>
   1.117 @@ -289,7 +289,7 @@
   1.118  
   1.119        <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.120  
   1.121 -      <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.122 +      <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 di aver terminato con quelli. Un'operazione di lettura comincia leggendo i dati nel changelog, poi i dati nel manifest seguiti dai dati nel filelog.</para>
   1.123  
   1.124        <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.125  
   1.126 @@ -297,11 +297,11 @@
   1.127      <sect2>
   1.128        <title>Accesso concorrente</title>
   1.129  
   1.130 -      <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.131 +      <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 leggono contemporaneamente in sicurezza i dati da un repository, senza preoccuparvi che qualcun altro lo stia modificando oppure no.</para>
   1.132  
   1.133        <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.134  
   1.135 -      <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.136 +      <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 al bloccaggio, 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 i vostri script automatici non rimarranno bloccati per sempre accumulandosi l'uno sull'altro se un sistema dovesse inavvertitamente cadere. (Sì, il valore del timeout è configurabile, da zero a infinito.)</para>
   1.137  
   1.138        <sect3>
   1.139  	<title>Accesso sicuro al dirstate</title>
   1.140 @@ -317,7 +317,7 @@
   1.141  
   1.142        <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.143  
   1.144 -      <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.145 +      <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 un 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.146  
   1.147        <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.148  
   1.149 @@ -325,7 +325,7 @@
   1.150      <sect2>
   1.151        <title>Altre informazioni contenute nel dirstate</title>
   1.152  
   1.153 -      <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.154 +      <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, Mercurial memorizza la data in cui ha registrato una modifica al file per l'ultima volta e la dimensione che il file aveva in quel momento.</para>
   1.155  
   1.156        <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.157  
   1.158 @@ -333,14 +333,14 @@
   1.159  
   1.160        <itemizedlist>
   1.161  	<listitem>
   1.162 -	  <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.163 +	  <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 l'ultima volta in cui Mercurial ha registrato una modifica per quel file. 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.164  	</listitem>
   1.165  	<listitem>
   1.166  	  <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.167  	</listitem>
   1.168        </itemizedlist>
   1.169  
   1.170 -      <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.171 +      <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 invochiamo comandi come <command>hg status</command>. Da questo stratagemma deriva un notevole miglioramento delle prestazioni.</para>
   1.172      </sect2>
   1.173    </sect1>
   1.174  </chapter>