Commits

Anonymous committed 0a49072

Final editing for chapters 4-7.

Comments (0)

Files changed (10)

it/ch04-concepts.xml

 
     </sect2>
     <sect2>
-      <title>Gestire i file archiviati</title>
+      <title>Gestire i file monitorati</title>
 
       <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>
 
 
       <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>
 
-      <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>
+      <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 registrato quando il changeset è stato creato. Queste relazioni sono illustrate nella <xref linkend="fig:concepts:metadata"/>.</para>
 
       <figure id="fig:concepts:metadata">
 	<title>Relazioni tra i metadati</title>
 
       <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>
 
-      <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>
+      <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 nel fatto che vengano eseguite correttamente.</para>
 
     </sect2>
     <sect2>
       <title>Reperimento veloce</title>
 
-      <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>
+      <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ù recente.) 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>
 
       <figure id="fig:concepts:snapshot">
 	<title>Fotografia di un revlog, con delta incrementali</title>
 
     <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>
 
-    <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>
+    <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 <emphasis>rami</emphasis>. Una revisione che rappresenta un'unione tra rami ha due identificatori di revisione normali negli spazi dedicati ai propri genitori.</para>
 
     <figure id="fig:concepts:revlog">
       <title>La struttura concettuale di un revlog</title>
 
     <para id="x_307">Nella directory di lavoro, Mercurial mantiene una fotografia dei file contenuti nel repository scattata su un changeset particolare.</para>
 
-    <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>
+    <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>
 
-    <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>
+    <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 che Mercurial sta monitorando 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>
 
     <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>
 
     <sect2>
       <title>Cosa succede quando eseguite un commit</title>
 
-      <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>
+      <para id="x_30b">Il dirstate mantiene le informazioni sui genitori per altri scopi in aggiunta alla mera contabilità. Mercurial usa i genitori del dirstate come <emphasis>i genitori di un nuovo changeset</emphasis> quando effettuate un commit.</para>
 
       <figure id="fig:concepts:wdir">
 	<title>La directory di lavoro può avere due genitori</title>
     <sect2>
       <title>Ordinamento e atomicità delle operazioni di lettura e scrittura</title>
 
-      <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>
+      <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 nei filelog. Questa gerarchia è intenzionale.</para>
 
-      <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>
+      <para id="x_32b">Un'operazione di scrittura avvia una transazione modificando i dati nei 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 nei filelog.</para>
 
-      <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>
+      <para id="x_32c">Dato che la scrittura ha sempre terminato di modificare i dati nei 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 di un filelog.</para>
 
     </sect2>
     <sect2>
 
       <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>
 
-      <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>
+      <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 sfrutta 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>
 
     </sect2>
     <sect2>
       <title>Altre informazioni contenute nel dirstate</title>
 
-      <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>
+      <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 in maniera efficiente 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>
 
       <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>
 
 
       <itemizedlist>
 	<listitem>
-	  <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>
+	  <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 memorizzata 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>
 	</listitem>
 	<listitem>
 	  <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>

it/ch05-daily.xml

   <sect1>
     <title>Aggiungere file a un repository Mercurial</title>
 
-    <para id="x_1a3">Mercurial lavora solo con i file che gli dite di gestire nel vostro repository. Il comando <command role="hg-cmd">hg status</command> vi dirà quali sono i file che Mercurial non conosce, usando un <quote><literal>?</literal></quote> per mostrare questi file.</para>
+    <para id="x_1a3">Mercurial lavora solo con i file che gli dite di amministrare nel vostro repository. Il comando <command role="hg-cmd">hg status</command> vi dirà quali sono i file che Mercurial non conosce, usando un <quote><literal>?</literal></quote> per mostrare questi file.</para>
 
     <para id="x_1a4">Per dire a Mercurial di tenere traccia di un file, usate il comando <command role="hg-cmd">hg add</command>. Una volta che avete aggiunto un file, la voce per quel file nell'elenco visualizzato da <command role="hg-cmd">hg status</command> cambia da <quote><literal>?</literal></quote> ad <quote><literal>A</literal></quote>.</para>
 
-      &interaction.daily.files.add;
+    &interaction.daily.files.add;
 
     <para id="x_1a5">Dopo aver eseguito <command role="hg-cmd">hg commit</command>, i file che avete aggiunto prima dell'inserimento non verranno più elencati dal comando <command role="hg-cmd">hg status</command>, perché il comportamento predefinito di <command role="hg-cmd">hg status</command> è quello di segnalarvi solo i file <quote>interessanti</quote> come (per esempio) quelli che avete modificato, rimosso, o rinominato. Se avete un repository che contiene migliaia di file, vorrete raramente sapere qualcosa dei file che Mercurial ha già registrato ma che non sono cambiati. (Potete comunque ottenere questa informazione, come vedremo più avanti.)</para>
 
 
     &interaction.daily.files.remove;
 
-    <para id="x_1b0">Dopo che avete rimosso un file tramite <command role="hg-cmd">hg remove</command>, Mercurial non terrà più traccia di quel file anche se ricreate un file con lo stesso nome nella vostra directory di lavoro. Se ricreate davvero un file con lo stesso nome e volete che Mercurial registri il nuovo file, usate semplicemente <command role="hg-cmd">hg add</command>. Mercurial saprà che il nuovo file non è in alcun modo legato al vecchio file con lo stesso nome.</para>
+    <para id="x_1b0">Dopo che avete rimosso un file tramite <command role="hg-cmd">hg remove</command>, Mercurial non terrà più traccia di quel file anche se ricreate un file con lo stesso nome nella vostra directory di lavoro. Se ricreate davvero un file con lo stesso nome e volete che Mercurial amministri il nuovo file, usate semplicemente <command role="hg-cmd">hg add</command>. Mercurial saprà che il nuovo file non è in alcun modo legato al vecchio file con lo stesso nome.</para>
 
     <sect2>
       <title>La rimozione di un file non ha effetti sulla sua cronologia.</title>
 
       &interaction.daily.files.missing;
 
-      <para id="x_1b7">Se il vostro repository contiene un file che <command role="hg-cmd">hg status</command> riporta come mancante, e volete che il file rimanga assente, potete eseguire <command role="hg-cmd">hg remove <option role="hg-opt-remove">--after</option></command> in qualsiasi momento, per dire a Mercurial che volevate effettivamente rimuovere il file.</para>
+      <para id="x_1b7">Se il vostro repository contiene un file che <command role="hg-cmd">hg status</command> segnala come mancante e volete che il file rimanga assente, potete eseguire <command role="hg-cmd">hg remove <option role="hg-opt-remove">--after</option></command> in qualsiasi momento per dire a Mercurial che volevate effettivamente rimuovere il file.</para>
 
       &interaction.daily.files.remove-after;
 
 
     <para id="x_6d0">Per esempio, un sistema distribuito di controllo di revisione non può, per sua natura, offrire un meccanismo di bloccaggio dei file. Quindi non esiste alcun meccanismo predefinito per evitare che due persone apportino cambiamenti in conflitto a un file binario. Se fate parte di un gruppo in cui diverse persone potrebbero modificare frequentemente i file binari, potrebbe non essere una buona idea impiegare Mercurial&emdash;o un qualsiasi altro sistema distribuito di controllo di revisione&emdash;per gestire quei file.</para>
 
-    <para id="x_6d1">Quando memorizza le modifiche a un file, di solito Mercurial salva solo le differenze tra la versione corrente del file e quella precedente. Per la maggior parte dei file di testo questo approccio si rivela estremamente efficiente. Tuttavia, alcuni file (in particolare i file binari) sono fatti in modo tale che persino una piccola modifica al contenuto logico del file risulta nel cambiamento di molti o della maggior parte dei byte contenuti nel file. Per esempio, i file compressi sono particolarmente sensibili a questo effetto. Se le differenze tra ogni versione di un file e la successiva sono sempre grandi, Mercurial non riuscirà a memorizzare la cronologia del file in maniera molto efficiente. Questo potrebbe avere effetti sia sul bisogno di spazio di memorizzazione locale sia sulla quantità di tempo che viene impiegata per clonare un repository.</para>
+    <para id="x_6d1">Quando Mercurial memorizza le modifiche a un file, di solito salva solo le differenze tra la versione corrente del file e quella precedente. Per la maggior parte dei file di testo questo approccio si rivela estremamente efficiente. Tuttavia, alcuni file (in particolare i file binari) sono fatti in modo tale che persino una piccola modifica al contenuto logico del file risulta nel cambiamento di molti o della maggior parte dei byte contenuti nel file. Per esempio, i file compressi sono particolarmente sensibili a questo effetto. Se le differenze tra ogni versione di un file e la successiva sono sempre grandi, Mercurial non riuscirà a memorizzare la cronologia del file in maniera molto efficiente. Questo potrebbe avere effetti sia sul bisogno di spazio di memorizzazione locale sia sulla quantità di tempo che viene impiegata per clonare un repository.</para>
 
-    <para id="x_6d2">Per avere un'idea di come questo problema potrebbe riguardarvi nella pratica, supponete di voler usare Mercurial per gestire un documento OpenOffice. OpenOffice memorizza i documenti su disco sotto forma di file zip compressi. Modificate anche solo una lettera nel vostro documento in OpenOffice e quasi ogni byte nell'intero file cambierà quando lo salverete. Ora supponete che le dimensioni di quel file siano di 2MB. Dato che la maggior parte del file cambia ogni volta che lo salvate, Mercurial dovrà memorizzare tutti i 2MB del file ogni volta che eseguite un commit, anche se dal vostro punto di vista forse solo poche parole vengono cambiate ogni volta. Un singolo file modificato frequentemente che non rispetti le assunzioni dei meccanismi di memorizzazione di Mercurial può facilmente avere un effetto fuori misura sulle dimensioni del repository.</para>
+    <para id="x_6d2">Per avere un'idea di come questo problema potrebbe riguardarvi nella pratica, supponete di voler usare Mercurial per gestire un documento OpenOffice. OpenOffice memorizza i documenti su disco sotto forma di file ZIP compressi. Modificate anche solo una lettera nel vostro documento in OpenOffice e quasi ogni byte nell'intero file cambierà quando lo salverete. Ora supponete che le dimensioni di quel file siano pari a 2MB. Dato che la maggior parte del file cambia ogni volta che lo salvate, Mercurial dovrà memorizzare tutti i 2MB del file ogni volta che eseguite un commit, anche se dal vostro punto di vista forse solo poche parole vengono cambiate ogni volta. Un singolo file modificato frequentemente che non rispetti le assunzioni dei meccanismi di memorizzazione di Mercurial può facilmente avere un effetto fuori misura sulle dimensioni del repository.</para>
 
     <para id="x_6d3">Anche peggio, se due di voi modificano il documento OpenOffice su cui state lavorando, non c'è alcun modo utile di effettuare un'unione tra le diverse versioni. In effetti, non c'è nemmeno un buon modo di capire quali sono le differenze tra i vostri rispettivi cambiamenti.</para>
 

it/ch06-collab.xml

   <?dbhtml filename="collaborare-con-altre-persone.html"?>
   <title>Collaborare con altre persone</title>
 
-  <para id="x_44a">Essendo uno strumento completamente decentralizzato, Mercurial non impone alcuna politica su come le persone dovrebbero lavorare insieme. Tuttavia, se per voi il controllo di revisione distribuito è una novità, conoscere alcuni strumenti ed esempi può aiutarvi a ragionare sui possibili modelli di workflow da adottare.</para>
+  <para id="x_44a">Essendo uno strumento completamente decentralizzato, Mercurial non impone alcuna politica su come le persone dovrebbero lavorare insieme. Tuttavia, se per voi il controllo di revisione distribuito è una novità, conoscere alcuni strumenti ed esempi può aiutarvi a ragionare sui possibili modelli di workflow (letteralmente, flusso di lavoro) da adottare.</para>
 
   <sect1>
     <title>L'interfaccia web di Mercurial</title>
 
     <para id="x_44c">L'interfaccia web vi permette di navigare interattivamente un singolo repository o una collezione di repository. Potete vedere la cronologia di un repository, esaminare qualsiasi cambiamento (con i commenti e le differenze) e vedere il contenuto di qualsiasi file o directory. Potete persino ottenere una vista della cronologia che vi fornisce una rappresentazione grafica delle relazioni tra le unioni e i singoli cambiamenti.</para>
 
-    <para id="x_44d">L'interfaccia web offre ai visitatori anche i feed RSS e Atom dei cambiamenti in un repository. Questo vi permette di <quote>abbonarvi</quote> a un repository usando il vostro lettore di feed preferito e di venire automaticamente informati sulle attività in quel repository non appena cominciano. Trovo questa possibilità molto più conveniente rispetto al modello di iscrizione a una mailing list a cui sono spedite le notifiche, in quanto non richiede alcuna configurazione aggiuntiva da parte di chiunque stia servendo il repository.</para>
+    <para id="x_44d">L'interfaccia web offre ai visitatori anche i feed RSS e Atom dei cambiamenti in un repository. Questo vi permette di <quote>abbonarvi</quote> a un repository usando il vostro lettore di feed preferito e di venire automaticamente informati sulle attività in quel repository non appena vengono compiute. Trovo questa possibilità molto più conveniente rispetto al modello di iscrizione a una mailing list a cui sono spedite le notifiche, in quanto non richiede alcuna configurazione aggiuntiva da parte di chiunque stia condividendo il repository.</para>
 
     <para id="x_44e">L'interfaccia web consente agli utenti remoti anche di clonare un repository, estrarne i cambiamenti e (quando il server è configurato per permetterlo) trasmettervi le proprie modifiche. Mercurial comprime aggressivamente i dati incapsulando il protocollo HTTP in modo da lavorare con grande efficienza persino attraverso connessioni di rete a banda ridotta.</para>
 
 
     <para id="x_69e">Per repository destinati a progetti di lunga durata che vorreste mantenere disponibili permanentemente, potete rivolgervi ai diversi servizi di hosting pubblici esistenti. Alcuni ospitano gratuitamente i progetti open source, mentre altri offrono un hosting commerciale a pagamento. Una lista aggiornata di questi servizi è disponibile all'indirizzo <ulink url="http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting">http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting</ulink>.</para>
 
-    <para id="x_6a0">Se invece preferite tenere i repository sui vostri server, Mercurial è dotato di un supporto predefinito per diverse tecnologie di hosting popolari, in particolar modo CGI (acronimo di Common Gateway Interface) e WSGI (acronimo di Web Services Gateway Interface). Leggete la <xref linkend="sec:collab:cgi"/> per i dettagli sulle configurazioni di CGI e WSGI.</para>
+    <para id="x_6a0">Se invece preferite tenere i repository sui vostri server, Mercurial è dotato di un supporto predefinito per diverse tecnologie di hosting popolari, in particolar modo CGI (acronimo di Common Gateway Interface, interfaccia di gateway comune) e WSGI (acronimo di Web Server Gateway Interface, interfaccia di gateway per server web). Leggete la <xref linkend="sec:collab:cgi"/> per i dettagli sulle configurazioni di CGI e WSGI.</para>
   </sect1>
 
   <sect1>
 
       <para id="x_455">Non vorrei suggerire che un approccio in cui <quote>tutto è permesso</quote> sia qualcosa di sostenibile, ma è un modello che è facile da capire e funziona perfettamente in alcune situazioni inusuali.</para>
 
-      <para id="x_456">Per esempio, molti progetti hanno un gruppo sparso di collaboratori che si incontrano fisicamente solo di rado. Alcuni gruppi preferiscono superare l'isolamento del lavoro a distanza organizzando <quote>maratone</quote> occasionali in cui un certo numero di persone si ritrova insieme in un'unico luogo (la stanza delle riunioni di un'azienda, la sala delle conferenze in un hotel, posti di questo tipo) e passa diversi giorni più o meno chiuso lì, a lavorare intensamente su una manciata di progetti.</para>
+      <para id="x_456">Per esempio, molti progetti hanno un gruppo sparpagliato di collaboratori che si incontrano fisicamente solo di rado. Alcuni gruppi preferiscono superare l'isolamento del lavoro a distanza organizzando <quote>maratone</quote> occasionali in cui un certo numero di persone si ritrova insieme in un'unico luogo (la stanza delle riunioni di un'azienda, la sala delle conferenze in un hotel, posti di questo tipo) e passa diversi giorni più o meno chiuso lì, a lavorare intensamente su una manciata di progetti.</para>
 
       <para id="x_457">Una maratona o una sessione di programmazione in un locale sono le occasioni perfette per usare il comando <command role="hg-cmd">hg serve</command>, dato che	<command role="hg-cmd">hg serve</command> non richiede alcuna infrastruttura server elaborata. Potete cominciare a usare <command role="hg-cmd">hg serve</command> in pochi minuti, leggendo la <xref linkend="sec:collab:serve"/> più avanti. Poi vi basta comunicare ai vostri vicini l'esistenza di un server in esecuzione, fargli sapere l'URL a cui devono collegarsi, e avrete un modo rapido da predisporre per lavorare insieme. Gli altri potranno digitare il vostro URL nel proprio browser e revisionare velocemente i vostri cambiamenti, o estrarre la correzione di un bug dal vostro repository e verificarla, o clonare un ramo contenente una nuova funzione e provarla.</para>
 
 
       <para id="x_45a">I collaboratori cominciano clonando una copia di questo repository, potendo estrarne i cambiamenti ogni volta che ne hanno bisogno. Alcuni sviluppatori (forse tutti) hanno il permesso di trasmettere le modifiche al repository quando sono pronte per essere viste da altre persone.</para>
 
-      <para id="x_45b">In questo modello, può ancora aver senso che alcune persone propaghino i cambiamenti direttamente tra loro, senza passare dal repository centrale. Considerate il caso in cui io ho creato una possibile correzione di un bug, ma sono preoccupato che, se la pubblicassi sul repository centrale, tutti gli altri possano successivamente danneggiare i propri alberi nel momento in cui la estraggono. Per ridurre il danno potenziale, posso chiedervi di clonare temporaneamente il mio repository in un vostro repository privato e di collaudare la correzione. Questo ci permette di rimandare la pubblicazione di cambiamenti potenzialmente pericolosi fino a quando non hanno subìto una ragionevole verifica.</para>
+      <para id="x_45b">In questo modello, può ancora avere senso che alcune persone propaghino i cambiamenti direttamente tra loro, senza passare dal repository centrale. Considerate il caso in cui io ho creato una correzione sperimentale di un bug, ma sono preoccupato che, se la pubblicassi sul repository centrale, tutti gli altri possano successivamente danneggiare i propri alberi nel momento in cui la estraggono. Per ridurre il danno potenziale, posso chiedervi di clonare temporaneamente il mio repository in un vostro repository privato e di collaudare la correzione. Questo ci permette di rimandare la pubblicazione di cambiamenti potenzialmente pericolosi fino a quando non hanno subìto una ragionevole verifica.</para>
 
       <para id="x_45c">Se un gruppo sta mantenendo il repository sui propri server in questo tipo di scenario, di solito i membri useranno il protocollo <command>ssh</command> per trasmettere in sicurezza i cambiamenti al repository centrale, come documentato nella <xref linkend="sec:collab:ssh"/>. Di solito, viene anche pubblicata una copia del repository in sola lettura via HTTP, come nella <xref linkend="sec:collab:cgi"/>. Pubblicare via HTTP soddisfa le necessità di chi non ha accesso in scrittura e di chi preferisce usare un browser per navigare la cronologia del repository.</para>
     </sect2>
 
       <para id="x_6a2">Per esempio, un servizio di hosting ben ingegnerizzato consentirà agli sviluppatori di clonare le proprie copie di un repository con un singolo clic, in modo da farli lavorare in spazi separati e lasciarli condividere i propri cambiamenti quando sono pronti.</para>
 
-      <para id="x_6a3">In più, un buon servizio di hosting permetterà alle persone di comunicare tra loro, per esempio per segnalare che <quote>questo albero contiene modifiche pronte per la tua revisione</quote>.</para>
+      <para id="x_6a3">In più, un buon servizio di hosting permetterà ai propri utentei di comunicare tra loro, per esempio per segnalare che <quote>questo albero contiene modifiche pronte per la tua revisione</quote>.</para>
     </sect2>
 
     <sect2>
 
       &interaction.branching.clone;
 
-      <para id="x_465">Se abbiamo bisogno di fare una modifica al ramo stabile, possiamo clonare <emphasis>quel</emphasis> repository, fare i nostri cambiamenti, effettuarne il commit, e trasmetterli indietro a quello stesso repository.</para>
+      <para id="x_465">Se abbiamo bisogno di fare una modifica al ramo stabile, possiamo clonare <emphasis>quel</emphasis> repository, fare i nostri cambiamenti, effettuarne il commit e trasmetterli indietro a quello stesso repository.</para>
 
       &interaction.branching.stable;
 
     <sect2>
       <title>Rami di funzione</title>
 
-      <para id="x_469">Per progetti di dimensioni più grandi, un modo efficace di gestire i cambiamenti è quello di dividere un gruppo in piccoli sottogruppi. Ogni sottogruppo gestisce un proprio ramo condiviso, clonato da un singolo ramo <quote>principale</quote> usato dall'intero progetto. Le persone che lavorano su un singolo ramo sono tipicamente piuttosto isolate dagli sviluppi che accadono negli altri rami.</para>
+      <para id="x_469">Per progetti di dimensioni più grandi, un modo efficace per gestire i cambiamenti è quello di dividere un gruppo in piccoli sottogruppi. Ogni sottogruppo gestisce un proprio ramo condiviso, clonato da un singolo ramo <quote>principale</quote> usato dall'intero progetto. Le persone che lavorano su un singolo ramo sono tipicamente piuttosto isolate dagli sviluppi che avvengono negli altri rami.</para>
 
       <figure id="fig:collab:feature-branches">
 	<title>Rami di funzione</title>
 
       <para id="x_476">Nella comunità open source si tenta continuamente di stabilire, attraverso accese discussioni, se un modello di sviluppo in cui le persone non fanno altro che estrarre cambiamenti le une dalle altre sia <quote>meglio</quote> di un modello in cui più persone possono trasmettere modifiche a un repository condiviso.</para>
 
-      <para id="x_477">Tipicamente, i sostenitori del modello a scrittura condivisa usano strumenti che impongono attivamente questo approccio. Se state usando uno strumento centralizzato di controllo di revisione come Subversion, non c'è alcun modo di scegliere il modello che userete: lo strumento vi fornisce un modello a scrittura condivisa e se volete fare qualcos'altro dovete costruire il vostro approccio al di sopra di quel modello (per esempio, applicando una patch a mano).</para>
+      <para id="x_477">Tipicamente, i sostenitori del modello a scrittura condivisa usano strumenti che impongono attivamente questo approccio. Se state usando uno strumento centralizzato di controllo di revisione come Subversion, non c'è alcun modo di scegliere il modello che userete: lo strumento vi fornisce un modello a scrittura condivisa e se volete fare qualcos'altro dovete strutturare il vostro metodo al di sopra di quel modello (per esempio, applicando una patch a mano).</para>
 
-      <para id="x_478">Un buon sistema distribuito di controllo di revisione supporterà entrambi i modelli. Voi e i vostri collaboratori poterete quindi strutturare il modo di lavorare insieme sulla base dei vostri bisogni e delle vostre preferenze, non delle acrobazie a cui vi costringono gli strumenti.</para>
+      <para id="x_478">Un buon sistema distribuito di controllo di revisione supporterà entrambi i modelli. Voi e i vostri collaboratori potrete quindi organizzare il modo di lavorare insieme sulla base dei vostri bisogni e delle vostre preferenze, non delle acrobazie a cui vi costringono gli strumenti.</para>
     </sect2>
     <sect2>
       <title>Dove la collaborazione incontra la gestione dei rami</title>
 
       <para id="x_4a0">Dato che ssh può essere complicato da configurare se non siete esperti, un certo numero di cose potrebbero andare storte. Aggiungete Mercurial a tutto questo, e le possibilità di fare confusione aumenteranno ulteriormente. La maggior parte di questi potenziali problemi si presenta sul lato server, non sul lato client. La buona notizia è che, una volta che avete una configurazione funzionante, di solito continuerà a funzionare indefinitamente.</para>
 
-      <para id="x_4a1">Prima di provare a usare Mercurial per comunicare con un server ssh, è preferibile che vi assicuriate di poter usare i normali comandi <command>ssh</command> o <command>putty</command> per contattare il server. Se incontrate problemi usando direttamente questi comandi, Mercurial sicuramente non funzionerà e quel che è peggio è che nasconderà il problema sottostante. Ogni volta che avete un problema relativo a ssh con Mercurial, per cominciare dovreste accertarvi nuovamente che i semplici comandi ssh lato client funzionino <emphasis>prima</emphasis> di preoccuparvi di eventuali problemi con Mercurial.</para>
+      <para id="x_4a1">Prima di provare a usare Mercurial per comunicare con un server ssh, è preferibile che vi assicuriate di poter usare i normali comandi <command>ssh</command> o <command>putty</command> per contattare il server. Se incontrate problemi usando direttamente questi comandi, Mercurial sicuramente non funzionerà e in più nasconderà il problema sottostante. Ogni volta che avete un problema relativo a ssh con Mercurial, per cominciare dovreste accertarvi nuovamente che i semplici comandi ssh lato client funzionino <emphasis>prima</emphasis> di preoccuparvi di eventuali problemi con Mercurial.</para>
 
       <para id="x_4a2">La prima cosa di cui accertarsi sul lato server è che siate in grado di entrare nel sistema da un'altra macchina. Se non potete usare <command>ssh</command> o <command>putty</command> per entrare, il messaggio di errore che vi viene mostrato potrebbe darvi alcuni suggerimenti per capire che cosa non va. I problemi più comuni sono i seguenti.</para>
       <itemizedlist>
       <para id="x_4ad">In un mondo ideale, dovreste essere in grado di eseguire il comando seguente con successo e ottenere come risultato la stampa di una riga contenente la data e l'ora correnti.</para>
       <programlisting>ssh mioserver date</programlisting>
 
-      <para id="x_4ae">Se gli script di accesso sul vostro server stampano messaggi informativi o altri tipi di testo anche quando eseguite comandi non interattivi come questo, dovreste correggerli prima di continuare, in modo che stampino solo se vengono eseguiti interattivamente. Altrimenti, questi messaggi come minimo confonderanno le stampe di Mercurial, o peggio, potrebbero potenzialmente causare problemi durante l'esecuzione remota dei comandi Mercurial. Mercurial prova a scoprire e ignorare questi messaggi durante le sessioni <command>ssh</command> non interattive, ma non è infallibile. (Se state modificando i vostri script di accesso sul vostro server, potete vedere se uno script di accesso viene eseguito in una shell interattiva controllando il codice restituito dal comando <literal>tty -s</literal>.)</para>
+      <para id="x_4ae">Se gli script di accesso sul vostro server stampano messaggi informativi o altri tipi di testo anche quando eseguite comandi non interattivi come questo, dovreste correggerli prima di continuare, in modo che stampino solo se vengono eseguiti interattivamente. Altrimenti, questi messaggi come minimo confonderanno le stampe di Mercurial e nel caso peggiore potrebbero causare problemi durante l'esecuzione remota dei comandi Mercurial. Mercurial prova a individuare e ignorare questi messaggi durante le sessioni <command>ssh</command> non interattive, ma non è infallibile. (Se state modificando i vostri script di accesso sul vostro server, potete vedere se uno script di accesso viene eseguito in una shell interattiva controllando il codice restituito dal comando <literal>tty -s</literal>.)</para>
 
       <para id="x_4af">Dopo aver verificato che il buon vecchio ssh stia funzionando con il vostro server, il passo successivo è quello di assicurarsi che Mercurial sia in esecuzione sul server. Il comando seguente dovrebbe terminare con successo:</para>
 
 	<listitem><para id="x_4b4">La variabile d'ambiente <envar>PYTHONPATH</envar> potrebbe aver bisogno di contenere il percorso ai moduli Python di Mercurial. Potrebbe non essere per niente impostata, potrebbe essere sbagliata, o potrebbe venire impostata solo se l'accesso è interattivo.</para>
 	</listitem></itemizedlist>
 
-      <para id="x_4b5">Se riuscite a eseguire <command role="hg-cmd">hg version</command> attraverso una connessione ssh, ben fatto! Siete riusciti a configurare il client e il server. Ora dovreste essere in grado di usare Mercurial per accedere ai repository ospitato da quel nome utente su quel server. Se a questo punto incontrate qualche problema con Mercurial e ssh, provate a usare l'opzione <option role="hg-opt-global">--debug</option> per avere un'immagine più chiara di quello che sta succedendo.</para>
+      <para id="x_4b5">Se riuscite a eseguire <command role="hg-cmd">hg version</command> attraverso una connessione ssh, ben fatto! Siete riusciti a configurare il client e il server. Ora dovreste essere in grado di usare Mercurial per accedere ai repository ospitati da quel nome utente su quel server. Se a questo punto incontrate qualche problema con Mercurial e ssh, provate a usare l'opzione <option role="hg-opt-global">--debug</option> per avere un'immagine più chiara di quello che sta succedendo.</para>
     </sect2>
     <sect2>
       <title>Usare la compressione con ssh</title>
   Compression yes
   HostName hg.example.com</programlisting>
 
-      <para id="x_4ba">Questo definisce l'alias <literal>hg</literal> per il nome della macchina. Quando usate l'alias sulla riga di comando <command>ssh</command> o in un URL ssh di Mercurial, <command>ssh</command> si connetterà a <literal>hg.example.com</literal> e userà la compressione. In questo modo, potete ottenere sia un nome più corto da digitare sia la compressione, che dal canto loro sono entrambe buone cose..</para>
+      <para id="x_4ba">Questo definisce l'alias <literal>hg</literal> per il nome della macchina. Quando usate l'alias sulla riga di comando <command>ssh</command> o in un URL ssh di Mercurial, <command>ssh</command> si connetterà a <literal>hg.example.com</literal> e userà la compressione. In questo modo, potete ottenere sia un nome più corto da digitare sia la compressione, che dal canto loro sono entrambe buone cose.</para>
     </sect2>
   </sect1>
 
   <sect1 id="sec:collab:cgi">
-    <title>Servire i dati attraverso HTTP usando CGI</title>
+    <title>Condividere i dati attraverso HTTP usando CGI</title>
 
     <para id="x_6a8">Il modo più semplice per condividere uno o più repository in modo permanente è quello di usare un server web e il supporto CGI di Mercurial.</para>
 
 	<listitem><para id="x_4c1">Il vostro server è configurato per consentirvi di eseguire programmi CGI nella directory dove pianificate di farlo? La maggior parte delle impostazioni di partenza dei server disabilitano esplicitamente la possibilità di eseguire programmi CGI.</para>
 	</listitem></orderedlist>
 
-      <para id="x_4c2">Se non avete un server web installato e non avete una considerevole esperienza nel configurare Apache, dovreste considerare l'uso del server web <literal>lighttpd</literal> invece di Apache. Le configurazioni di Apache hanno la reputazione ben meritata di essere complicate e di confondere gli utenti. Mentre Apache è dotato di un numero maggiore di funzioni rispetto a <literal>lighttpd</literal>, buona parte di queste funzioni non è rilevante per servire repository Mercurial. E <literal>lighttpd</literal> è innegabilmente <emphasis>molto</emphasis> più facile da affrontare di Apache.</para>
+      <para id="x_4c2">Se non avete un server web installato e non avete una considerevole esperienza nel configurare Apache, dovreste considerare l'uso del server web <literal>lighttpd</literal> invece di Apache. Le configurazioni di Apache hanno la reputazione ben meritata di essere complicate e di confondere gli utenti. Sebbene Apache sia dotato di un numero maggiore di funzioni rispetto a <literal>lighttpd</literal>, buona parte di queste funzioni non è rilevante per servire repository Mercurial. E <literal>lighttpd</literal> è innegabilmente <emphasis>molto</emphasis> più facile da affrontare di Apache.</para>
     </sect2>
 
     <sect2>
       <sect3 id="sec:collab:wtf">
 	<title>Che cosa <emphasis>potrebbe</emphasis> andare storto?</title>
 
-	<para id="x_4c7">Una volta che avete copiato lo script CGI al suo posto, aprite un browser web e provate a visitare l'URL <literal>http://nomemacchina/~nomeutente/hgweb.cgi</literal>, <emphasis>ma</emphasis> raccogliete le forze per affrontare un fallimento immediato. C'è un'alta probabilità che la visita a questo URL fallisca e ci sono molte possibili ragioni per questo. In effetti, probabilmente vi imbatterete in quasi tutti i possibili errori descritti più avanti, quindi leggete attentamente. Quelli che seguono sono tutti i problemi che ho incontrato sul sistema operativo Fedora 7, con un'installazione vergine di Apache e un account utente che ho creato espressamente per effettuare questo esercizio.</para>
+	<para id="x_4c7">Una volta che avete copiato lo script CGI al suo posto, aprite un browser web e provate a visitare l'URL <literal>http://nomemacchina/~nomeutente/hgweb.cgi</literal>, <emphasis>ma</emphasis> raccogliete le forze per affrontare un fallimento immediato. C'è un'alta probabilità che la visita a questo URL fallisca e ci sono molte possibili ragioni per questo. In effetti, probabilmente vi imbatterete in quasi tutti i possibili errori descritti più avanti, quindi leggete attentamente. Quelli che seguono sono tutti i problemi che ho incontrato sul sistema operativo Fedora 7, con un'installazione vergine di Apache e un account utente creato espressamente per effettuare questo esercizio.</para>
 
 	<para id="x_4c8">Il vostro server web potrebbe aver disabilitato le directory di pubblicazione per utente. Se state usando Apache, cercate la direttiva <literal>UserDir</literal> nel vostro file di configurazione. Se non è presente, o se è presente ma il suo valore è <literal>disabled</literal>, allora le directory per utente sono disabilitate. Altrimenti, la stringa che segue <literal>UserDir</literal> è il nome della sottodirectory della vostra directory personale che verrà letta da Apache, per esempio <filename class="directory">public_html</filename>.</para>
 
 
       <para id="x_4d8">Lo script <filename role="special">hgwebdir.cgi</filename> si basa su un file di configurazione esterno. Per default, cerca un file chiamato <filename role="special">hgweb.config</filename> nella stessa directory in cui si trova. Dovrete creare questo file e renderlo leggibile agli altri. Il formato di questo file è simile a quello di un file <quote>ini</quote> di Windows, riconoscibile dal modulo <literal>ConfigParser</literal> <citation><xref linkend="bib:cp"/></citation> di Python.</para>
 
-      <para id="x_4d9">Il modo più facile di configurare <filename role="special">hgwebdir.cgi</filename> è tramite una sezione chiamata <literal>collections</literal>. Questo pubblicherà automaticamente <emphasis>tutti</emphasis> i repository contenuti nelle directory che nominate. La sezione dovrebbe somigliare a questa:</para>
+      <para id="x_4d9">Il modo più facile di configurare <filename role="special">hgwebdir.cgi</filename> è tramite una sezione chiamata <literal>collections</literal> che vi consentirà di pubblicare automaticamente <emphasis>tutti</emphasis> i repository contenuti nelle directory che nominate. La sezione dovrebbe somigliare a questa:</para>
       <programlisting>[collections]
 /mia/radice = /mia/radice</programlisting>
-      <para id="x_4da">Mercurial la interpreta guardando al nome della directory sul lato <emphasis>destro</emphasis> del segno <quote><literal>=</literal></quote>, trovando i repository nella gerarchia contenuta in quella directory e usando il testo sul lato <emphasis>sinistro</emphasis> per eliminare il testo corrispondente dai nomi che elencherà effettivamente nell'interfaccia web. I componenti del percorso che rimangono dopo questa eliminazione formano un <quote>percorso virtuale</quote>.</para>
+      <para id="x_4da">Mercurial la interpreta guardando al nome della directory sul lato <emphasis>destro</emphasis> del segno <quote><literal>=</literal></quote>, individuando i repository nella gerarchia contenuta in quella directory e usando il testo sul lato <emphasis>sinistro</emphasis> per eliminare il testo corrispondente dai nomi che elencherà effettivamente nell'interfaccia web. I componenti del percorso che rimangono dopo questa eliminazione formano un <quote>percorso virtuale</quote>.</para>
 
       <para id="x_4db">Dato l'esempio precedente, se abbiamo un repository il cui percorso locale è <filename class="directory">/mia/radice/questo/repository</filename>, lo script CGI eliminerà la parte <filename class="directory">/mia/radice</filename> iniziale dal nome e pubblicherà il repository con il percorso virtuale <filename class="directory">questo/repository</filename>. Se l'URL per il nostro script CGI è <literal>http://nomemacchina/~nomeutente/hgwebdir.cgi</literal>, l'URL completo per quel repository sarà <literal>http://nomemacchina/~nomeutente/hgwebdir.cgi/questo/repository</literal>.</para>
 
       <para id="x_4dc">Se sostituiamo <filename class="directory">/mia/radice</filename> sul lato sinstro di questo esempio con <filename class="directory">/mia</filename>, allora <filename role="special">hgwebdir.cgi</filename> eliminerà solo <filename class="directory">/mia</filename> dal nome del repository e ci darà il percorso virtuale <filename class="directory">radice/questo/repository</filename> invece di	<filename class="directory">questo/repository</filename>.</para>
 
-      <para id="x_4dd">Lo script <filename role="special">hgwebdir.cgi</filename> cercherà i repository ricorsivamente in ogni directory elencata nella sezione <literal>collections</literal> del suo file di configurazione, ma <emphasis>non</emphasis> navigherà ricorsivamente nei repository che trova.</para>
+      <para id="x_4dd">Lo script <filename role="special">hgwebdir.cgi</filename> cercherà i repository ricorsivamente in ogni directory elencata nella sezione <literal>collections</literal> del suo file di configurazione, ma <emphasis>non</emphasis> navigherà ricorsivamente nei repository che trova.<footnote><para id="x_ff3">[NdT] A partire dalla versione 1.3, Mercurial supporta i repository innestati.</para></footnote></para>
 
       <para id="x_4de">Il meccanismo delle collezioni nella sezione <literal>collections</literal> facilita la pubblicazione di molti repository in modalità <quote>spara e dimentica</quote>. Dovete impostare lo script CGI e il file di configurazione una volta sola, dopodiché potete pubblicare o ritirare un repository in ogni momento semplicemente spostandolo dentro o fuori dalla gerarchia di directory in cui <filename role="special">hgwebdir.cgi</filename> è configurato per guardare.</para>
 
 
 	<para id="x_4df">In aggiunta al meccanismo basato su <literal>collections</literal>, lo script <filename role="special">hgwebdir.cgi</filename> vi consente di pubblicare una lista specifica di repository. Per fare questo, create una sezione <literal>paths</literal> con un contenuto simile al seguente.</para>
 	<programlisting>[paths]
-repo1 = /mio/percorso/a/qualche/repository
-repo2 = /qualche/percorso/a/un/altro</programlisting>
+repo1 = /mio/percorso/vero/qualche/repository
+repo2 = /qualche/percorso/verso/un/altro</programlisting>
 	<para id="x_4e0">In questo caso, il percorso virtuale (il componente che apparirà in un URL) è sul lato sinistro di ogni definizione, mentre il percorso del repository è sulla destra. Notate che non c'è bisogno che esista  alcuna relazione tra il percorso virtuale che scegliete e l'ubicazione di un repository sul vostro file system.</para>
 
 	<para id="x_4e1">Se lo desiderate, potete usare entrambe le sezioni	  <literal>collections</literal> e <literal>paths</literal> contemporaneamente in un unico file di configurazione.</para>

it/ch07-filenames.xml

     <para id="x_544">A livello di implementazione, Mercurial usa un unico meccanismo per gestire i nomi dei file. Tutti i comandi si comportano in maniera uniforme rispetto ai nomi dei file e lavorano nel modo seguente.</para>
 
     <para id="x_545">Se indicate esplicitamente nomi di file esistenti sulla riga di comando, Mercurial lavora esattamente con quei file, come vi aspettereste.</para>
-    
-      &interaction.filenames.files;
+
+    &interaction.filenames.files;
 
     <para id="x_546">Quando fornite un nome di directory, Mercurial interpreterà questa azione come la volontà di <quote>operare su tutti i file in questa directory e nelle sue sottodirectory</quote>. Mercurial considera i file e le sottodirectory in una directory secondo l'ordine alfabetico. Quando incontra una sottodirectory, attraverserà quella sottodirectory prima di continuare con la directory corrente.</para>
 
-      &interaction.filenames.dirs;
+    &interaction.filenames.dirs;
   </sect1>
 
   <sect1>
 
     <para id="x_54c">L'esempio di <command role="hg-cmd">hg add</command> nella sezione precedente illustra qualcos'altro che è utile sapere sui comandi Mercurial. Se un comando opera su un file che non avete nominato esplicitamente sulla riga di comando, di solito stamperà il nome del file in modo che non veniate sorpresi da quello che sta succedendo.</para>
 
-    <para id="x_54d">In questo caso, Mercurial segue il principio della <emphasis>minima sorpresa</emphasis>. Se avete fornito il nome esatto di un file sulla riga di comando, non ha senso ripetervelo. Se Mercurial sta agendo <emphasis>implicitamente</emphasis> su un file, e.g. perché non avete fornito alcun nome, o su una directory, o su un pattern (si veda più avanti), ritiene sia più sicuro farvi sapere su quali file sta lavorando.</para>
+    <para id="x_54d">In questo caso, Mercurial segue il principio della <emphasis>minima sorpresa</emphasis>. Se avete fornito il nome esatto di un file sulla riga di comando, non ha senso ripetervelo. Se Mercurial sta agendo <emphasis>implicitamente</emphasis> su un file, per esempio perché non avete fornito alcun nome, o su una directory, o su un pattern (si veda più avanti), ritiene sia più sicuro farvi sapere su quali file sta lavorando.</para>
 
     <para id="x_54e">Potete ridurre al silenzio i comandi che si comportano in questo modo usando l'opzione <option role="hg-opt-global">-q</option>. Potete anche dire loro di stampare il nome di tutti i file, anche quelli che avete nominato esplicitamente, usando l'opzione <option role="hg-opt-global">-v</option>.</para>
   </sect1>
 
     <para id="x_54f">Oltre a lavorare con i nomi di file e directory, Mercurial vi consente di usare i <emphasis>pattern</emphasis> per identificare i file. La gestione dei pattern da parte di Mercurial è espressiva.</para>
 
-    <para id="x_550">Su sistemi di tipo Unix (Linux, Mac OS X, etc.), di solito è la shell ad occuparsi di trovare le corrispondenze tra i pattern e i nomi dei file. Su questi sistemi, dovete esplicitamente dire a Mercurial che un nome è un pattern. Su Windows, la shell non si occupa di espandere i pattern, quindi Mercurial identificherà automaticamente i nomi che sono pattern e li espanderà per voi.</para>
+    <para id="x_550">Su sistemi di tipo Unix (Linux, Mac OS X, etc.), di solito è la shell che si occupa di trovare le corrispondenze tra i pattern e i nomi dei file. Su questi sistemi, dovete esplicitamente dire a Mercurial che un nome è un pattern. Su Windows, la shell non si occupa di espandere i pattern, quindi Mercurial identificherà automaticamente i nomi che sono pattern e li espanderà per voi.</para>
 
     <para id="x_551">Per fornire un pattern al posto di un nome ordinario sulla riga di comando, il meccanismo è semplice:</para>
     <programlisting>sintassi:corpodelpattern</programlisting>
-    <para id="x_552">Cioè, un pattern viene identificato da una breve stringa di testo che indica il tipo del pattern, seguita dai due punti, seguiti dall'effettivo pattern.</para>
+    <para id="x_552">Quindi, un pattern viene identificato da una breve stringa di testo che indica il tipo del pattern, seguita dai due punti, seguiti dall'effettivo pattern.</para>
 
     <para id="x_553">Mercurial supporta due tipi di sintassi per i pattern. Quello usato più spesso è chiamato <literal>glob</literal>: è lo stesso tipo di pattern usato dalla shell Unix e dovrebbe essere familiare anche agli utenti del prompt dei comandi di Windows.</para>
 
 
     <para id="x_6b4">Per fare in modo che Mercurial ignori permanentemente quei file, create un file chiamato <filename>.hgignore</filename> alla radice del vostro repository. <emphasis>Dovreste</emphasis> registrare questo file tramite <command>hg add</command> in modo che Mercurial ne tenga traccia insieme al resto dei contenuti del vostro repository, dato che anche i vostri collaboratori potrebbero trovarlo utile.</para>
 
-    <para id="x_6b5">Mercurial si aspetta che il file <filename>.hgignore</filename> contenga una lista di espressioni regolari, una per riga. Le linee vuote vengono saltate. La maggior parte delle persone preferisce descrivere i file che vuole ignorare utilizzando la sintassi <quote>glob</quote> che abbiamo descritto in precedenza, quindi un tipico file <filename>.hgignore</filename> comincerà con questa direttiva:</para>
+    <para id="x_6b5">Mercurial si aspetta che il file <filename>.hgignore</filename> contenga una lista di espressioni regolari, una per riga. Le righe vuote vengono saltate. La maggior parte delle persone preferisce descrivere i file che vuole ignorare utilizzando la sintassi <quote>glob</quote> che abbiamo descritto in precedenza, quindi un tipico file <filename>.hgignore</filename> comincerà con questa direttiva:</para>
 
     <programlisting>syntax: glob</programlisting>
 
     <itemizedlist>
       <listitem><para id="x_56c">Completa insensibilità alle maiuscole. Le versioni maiuscole e minuscole di una lettera sono trattate come se fossero identiche, sia quando un file viene creato sia durante i successivi accessi. Questo è il funzionamento comune dei vecchi sistemi basati su DOS.</para>
       </listitem>
-      <listitem><para id="x_56d">Conservazione delle maiuscole, ma insensibilità ad esse. Quando un file o una directory vengono creati, le maiuscole nel loro nome vengono memorizzate e possono essere recuperate e visualizzate dal sistema operativo. Quando un file esistente viene cercato, le maiuscole nel suo nome vengono ignorate. Questa è la situazione standard su Windows e MacOS. I nomi <filename>foo</filename> e <filename>FoO</filename> identificano lo stesso file. Questo trattamento intercambiabile delle lettere maiuscole e minuscole è anche chiamato <emphasis>ripiegamento delle maiuscole</emphasis>.</para>
+      <listitem><para id="x_56d">Conservazione delle maiuscole, ma insensibilità a esse. Quando un file o una directory vengono creati, le maiuscole nel loro nome vengono memorizzate e possono essere recuperate e visualizzate dal sistema operativo. Quando un file esistente viene cercato, le maiuscole nel suo nome vengono ignorate. Questa è la situazione standard su Windows e MacOS. I nomi <filename>foo</filename> e <filename>FoO</filename> identificano lo stesso file. Questo trattamento intercambiabile delle lettere maiuscole e minuscole è anche chiamato <emphasis>ripiegamento delle maiuscole</emphasis> (in inglese, case folding).</para>
       </listitem>
       <listitem><para id="x_56e">Sensibilità alle maiuscole. Le lettere maiuscole di un nome sono significative in ogni momento. I nomi <filename>foo</filename> e <filename>FoO</filename> identificano due file differenti. Questo è il modo in cui i sistemi Linux e Unix lavorano normalmente.</para>
       </listitem></itemizedlist>
 
-    <para id="x_56f">Su sistemi di tipo Unix è possibile avere uno qualsiasi o tutti e tre i modi di gestire le maiuscole in azione allo stesso tempo. Per esempio, se usate Linux per operare su una chiave USB formattata con un file system FAT32, il sistema operativo gestirà i nomi su quel file system in modo da conservare le maiuscole senza essere sensibile ad esse.</para>
+    <para id="x_56f">Su sistemi di tipo Unix è possibile avere uno qualsiasi o tutti e tre i modi di gestire le maiuscole in azione allo stesso tempo. Per esempio, se usate Linux per operare su una chiave USB formattata con un file system FAT32, il sistema operativo gestirà i nomi su quel file system in modo da conservare le maiuscole senza essere sensibile a esse.</para>
 
     <sect2>
       <title>Memorizzazione del repository sicura e portabile</title>
 
-      <para id="x_570">Il meccanismo di memorizzazione dei repository Mercurial è <emphasis>sicuro per le maiuscole</emphasis>. Traduce i nomi dei file in modo che possano essere memorizzati senza problemi sia su file system sensibili alle maiuscole sia su quelli insensibili alle maiuscole. Questo significa che, per esempio, potete usare i normali strumenti per la copia di file per trasferire un repository Mercurial su una chiave USB, e spostare la chiavetta e il repository avanti e indietro tra un Mac, un PC con Windows e una macchina Linux senza problemi.</para>
+      <para id="x_570">Il meccanismo di memorizzazione dei repository Mercurial è <emphasis>sicuro per le maiuscole</emphasis>. Traduce i nomi dei file in modo che possano essere memorizzati senza problemi sia su file system sensibili alle maiuscole sia su quelli insensibili alle maiuscole. Questo significa che, per esempio, potete usare i normali strumenti per la copia di file per trasferire un repository Mercurial su una chiave USB, e spostare la chiave e il repository avanti e indietro tra un Mac, un PC con Windows e una macchina Linux senza problemi.</para>
 
     </sect2>
     <sect2>
       <title>Riconoscere i conflitti tra maiuscole e minuscole</title>
 
-      <para id="x_571">Quando opera sulla directory di lavoro, Mercurial segue la politica di denominazione del file system su cui la directory di lavoro si trova. Se il file system conserva le maiuscole ma è insensibile ad esse, Mercurial tratterà i nomi che differiscono solo per le maiuscole come se fossero uguali.</para>
+      <para id="x_571">Quando opera sulla directory di lavoro, Mercurial segue la politica di denominazione del file system su cui la directory di lavoro si trova. Se il file system conserva le maiuscole ma è insensibile a esse, Mercurial tratterà i nomi che differiscono solo per le maiuscole come se fossero uguali.</para>
 
       <para id="x_572">&Egrave; importante ricordare che questo approccio permette di eseguire su un file system sensibile alle maiuscole (tipicamente Linux o Unix) il commit di un changeset che creerà problemi per gli utenti di file system insensibili alle maiuscole (di solito Windows e MacOS). Se un utente Linux inserisce nel repository le modifiche a due file, uno chiamato <filename>miofile.c</filename> e l'altro chiamato <filename>MioFile.c</filename>, questi file verranno memorizzati correttamente. E gli stessi file verranno correttamente rappresentati come due file separati nella directory di lavoro di altri utenti Linux.</para>
 
-      <para id="x_573">Se un utente Windows o Mac estrae questo changeset, inizialmente non avrà alcun problema, perché il meccanismo di memorizzazione di un repository Mercurial è sicuro per le maiuscole. Tuttavia, appena tenta di aggiornare la directory di lavoro a quel changeset tramite <command role="hg-cmd">hg update</command>, o a unire il proprio lavoro con quel changeset tramite <command role="hg-cmd">hg merge</command>, Mercurial individuerà il conflitto tra i due nomi di file che il file system tratterebbe come lo stesso nome e impedirà all'aggiornamento o all'unione di avvenire.</para>
+      <para id="x_573">Se un utente Windows o Mac estrae questo changeset, inizialmente non avrà alcun problema, perché il meccanismo di memorizzazione di un repository Mercurial è sicuro per le maiuscole. Tuttavia, appena tenta di aggiornare la directory di lavoro a quel changeset tramite <command role="hg-cmd">hg update</command>, o di unire il proprio lavoro con quel changeset tramite <command role="hg-cmd">hg merge</command>, Mercurial individuerà il conflitto tra i due nomi di file che il file system tratterebbe come lo stesso nome e impedirà all'aggiornamento o all'unione di avvenire.</para>
     </sect2>
 
     <sect2>
       <title>Correggere un conflitto tra maiuscole e minuscole</title>
 
-      <para id="x_574">Se state usando Windows o Mac in un ambiente misto dove alcuni dei vostri collaboratori usano Linux o Unix, e Mercurial riporta un conflitto di ripiegamento delle maiuscole (indicandolo con il termine inglese <emphasis>case folding</emphasis> nel messaggio di errore) quando provate a eseguire <command role="hg-cmd">hg update</command> o <command role="hg-cmd">hg merge</command>, la procedura per correggere il problema è semplice.</para>
+      <para id="x_574">Se state usando Windows o Mac in un ambiente misto dove alcuni dei vostri collaboratori usano Linux o Unix, e Mercurial riporta un conflitto di ripiegamento delle maiuscole quando provate a eseguire <command role="hg-cmd">hg update</command> o <command role="hg-cmd">hg merge</command>, la procedura per correggere il problema è semplice.</para>
 
       <para id="x_575">Trovate la macchina Linux o Unix più vicina, clonatevi il repository problematico e usate il comando <command role="hg-cmd">hg rename</command> di Mercurial per cambiare i nomi di qualsiasi file o directory che crea complicazioni, in modo da non causare più alcun conflitto di ripiegamento delle maiuscole. Inserite queste modifiche nel repository, eseguite <command role="hg-cmd">hg pull</command> o <command role="hg-cmd">hg push</command> attraverso i vostri sistemi Windows o MacOS e usate <command role="hg-cmd">hg update</command> per aggiornare la directory di lavoro alla revisione che contiene i nomi senza conflitti.</para>
 

it/examples/branching.tag.it

 <screen><prompt>$</prompt> <userinput>hg tag v1.0</userinput>
 <prompt>$</prompt> <userinput>hg tip</userinput>
 changeset:   1:be452d95a1d0
-tag:         tip
-user:        Bryan O'Sullivan &lt;bos@serpentine.com&gt;
-date:        Fri Jun 05 15:49:15 2009 +0000
-summary:     Aggiunta l'etichetta v1.0 per il changeset c93791f54ca9
+etichetta:   tip
+utente:      Bryan O'Sullivan &lt;bos@serpentine.com&gt;
+data:        Fri Jun 05 15:49:15 2009 +0000
+sommario:    Aggiunta l'etichetta v1.0 per il changeset c93791f54ca9
 
 <prompt>$</prompt> <userinput>hg tags</userinput>
 tip                                1:be452d95a1d0

it/examples/ch04-diff.rename.basic.it

 <!-- BEGIN ch04/diff.rename.basic -->
-<screen><prompt>$</prompt> <userinput>hg rename a b</userinput>
+<screen><prompt>$</prompt> <userinput>hg rename foo bar</userinput>
 <prompt>$</prompt> <userinput>hg diff</userinput>
-diff -r b01d46ff402d a
---- a/a	Fri Jun 05 15:49:22 2009 +0000
+diff -r b01d46ff402d foo
+--- foo/foo	Fri Jun 05 15:49:22 2009 +0000
 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
 @@ -1,1 +0,0 @@
 -a
-diff -r b01d46ff402d b
+diff -r b01d46ff402d bar
 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
-+++ b/b	Fri Jun 05 15:49:23 2009 +0000
++++ bar/bar	Fri Jun 05 15:49:23 2009 +0000
 @@ -0,0 +1,1 @@
 +a
 </screen>

it/examples/ch04-diff.rename.git.it

 <!-- BEGIN ch04/diff.rename.git -->
 <screen><prompt>$</prompt> <userinput>hg diff -g</userinput>
-diff --git a/a b/b
-cambiamento di nome da a
-cambiamento di nome a b
+diff --git foo/foo bar/bar
+cambiamento di nome da foo
+cambiamento di nome a bar
 </screen>
 <!-- END ch04/diff.rename.git -->

it/examples/ch04-resolve.heads.it

 <!-- BEGIN ch04/resolve.heads -->
 <screen><prompt>$</prompt> <userinput>hg heads</userinput>
 changeset:   2:6e8cd0b94b4c
-tag:         tip
-parent:      0:05f41910a168
-user:        Bryan O'Sullivan &lt;bos@serpentine.com&gt;
-date:        Fri Jun 05 15:49:28 2009 +0000
-summary:     destra
+etichetta:   tip
+genitore:    0:05f41910a168
+utente:      Bryan O'Sullivan &lt;bos@serpentine.com&gt;
+data:        Fri Jun 05 15:49:28 2009 +0000
+sommario:    destra
 
 changeset:   1:ab0fbd8c502d
-user:        Bryan O'Sullivan &lt;bos@serpentine.com&gt;
-date:        Fri Jun 05 15:49:27 2009 +0000
-summary:     sinistra
+utente:      Bryan O'Sullivan &lt;bos@serpentine.com&gt;
+data:        Fri Jun 05 15:49:27 2009 +0000
+sommario:    sinistra
 
 </screen>
 <!-- END ch04/resolve.heads -->

it/examples/issue29.go.it

 aggiungo b/b
 creata una nuova testa
 <prompt>$</prompt> <userinput>hg merge</userinput>
-fallimento: è una directory: /tmp/problema29jbjGH5/problema29/b
+fallimento: è una directory: /tmp/problema29/b
 </screen>
 <!-- END issue29.go -->

it/examples/rename.divergent.rename.bob.it

 <!-- BEGIN rename.divergent.rename.bob -->
 <screen><prompt>$</prompt> <userinput>cd ../bruno</userinput>
 <prompt>$</prompt> <userinput>hg mv foo quux</userinput>
-<prompt>$</prompt> <userinput>hg ci -m 'Riominato foo a quux.'</userinput>
+<prompt>$</prompt> <userinput>hg ci -m 'Rinominato foo a quux.'</userinput>
 </screen>
 <!-- END rename.divergent.rename.bob -->
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.