1.1 --- a/it/ch01-intro.xml	Tue Jun 09 19:21:24 2009 +0200
     1.2 +++ b/it/ch01-intro.xml	Fri Jun 12 11:25:02 2009 +0200
     1.3 @@ -5,13 +5,13 @@
     1.4    <sect1>
     1.5      <title>Perché il controllo di revisione? Perché Mercurial?</title>
     1.6  
     1.7 -    <para id="x_6d">Il controllo di revisione è il processo di gestire multiple versioni di un pezzo di informazione. Nella sua forma più semplice, questo è qualcosa che molte persone fanno a mano: ogni volta che modificate un file, lo salvate con un nuovo nome che contiene un numero, ognuno più alto del numero della precedente versione.</para>
     1.8 -
     1.9 -    <para id="x_6e">Tuttavia, gestire multiple versioni anche solo di un singolo file è un'operazione propensa a errori, quindi strumenti software per aiutare ad automatizzare questo processo sono stati disponibili da lungo tempo. I primi strumenti automatizzati per il controllo di revisione erano designati ad assistere un singolo utente nella gestione delle revisioni di un singolo file. Nel corso delle ultime decadi, il campo d'azione degli strumenti di controllo di revisione si è grandemente esteso; ora sono in grado di gestire file multipli e di aiutare più persone a lavorare insieme. I migliori strumenti di controllo di revisione moderni non hanno alcun problema a fronteggiare migliaia di persone che lavorano insieme su progetti che consistono di centinaia di migliaia di file.</para>
    1.10 +    <para id="x_6d">Il controllo di revisione è il processo tramite il quale si gestiscono molteplici versioni di un pezzo di informazione. Nella sua forma più semplice, questo viene fatto a mano da molte persone, ogni volta che modificano un file e lo salvano con un nuovo nome che contiene un numero più alto del numero della precedente versione.</para>
    1.11 +
    1.12 +    <para id="x_6e">Tuttavia, gestire più versioni anche solo di un singolo file è un'operazione propensa a errori, quindi strumenti software per aiutare ad automatizzare questo processo sono stati disponibili da lungo tempo. I primi strumenti automatizzati per il controllo di revisione erano designati ad assistere un singolo utente nella gestione delle revisioni di un singolo file. Nel corso delle ultime decadi, il campo d'azione degli strumenti di controllo di revisione si è ampiamente esteso, e ora sono in grado di gestire un grande numero di file e di aiutare più persone a lavorare insieme. I migliori strumenti di controllo di revisione moderni non hanno alcun problema a fronteggiare gruppi di migliaia di persone che lavorano insieme su progetti composti da centinaia di migliaia di file.</para>
    1.13  
    1.14      <para id="x_6f">L'arrivo del controllo di revisione distribuito è relativamente recente, e finora questo nuovo campo è cresciuto grazie alla propensione delle persone a esplorare territorio malamente mappato.</para>
    1.15  
    1.16 -    <para id="x_70">Sto scrivendo un libro sul controllo di revisione distribuito perché credo che sia una materia importante che merita una guida sul campo. Ho scelto di trattare Mercurial perché è lo strumento più facile con cui conoscere il territorio, e tuttavia è in grado di scalare fino a soddisfare le richieste di ambienti reali e impegnativi dove molti altri strumenti di controllo di revisione si devono arrendere.</para>
    1.17 +    <para id="x_70">Sto scrivendo un libro sul controllo di revisione distribuito perché credo che sia una materia importante che merita una guida sul campo. Ho scelto di trattare Mercurial perché è lo strumento più facile con cui conoscere il territorio, e tuttavia è in grado di scalare fino a soddisfare le richieste di ambienti reali e impegnativi dove molti altri strumenti di controllo di revisione si sono dovuti arrendere.</para>
    1.18  
    1.19      <sect2>
    1.20        <title>Perché usare il controllo di revisione?</title>
    1.21 @@ -19,19 +19,19 @@
    1.22        <para id="x_71">Esiste un certo numero di ragioni per le quali voi o il vostro gruppo potreste voler usare uno strumento automatico per il controllo di revisione su un progetto.</para>
    1.23  
    1.24        <itemizedlist>
    1.25 -	<listitem><para id="x_72">Terrà traccia della storia e dell'evoluzione del vostro progetto, così voi non dovete farlo. Per ogni modifica, avrete un registro di <emphasis>chi</emphasis> l'ha fatta, <emphasis>perché</emphasis> l'ha fatta, <emphasis>quando</emphasis> è stata fatta e <emphasis>cosa</emphasis> è stato modificato.</para></listitem>
    1.26 +	<listitem><para id="x_72">Terrà traccia della storia e dell'evoluzione del vostro progetto, così voi non dovete farlo. Per ogni modifica, registrerà informazioni su <emphasis>chi</emphasis> l'ha fatta, <emphasis>perché</emphasis> l'ha fatta, <emphasis>quando</emphasis> è stata fatta e <emphasis>cosa</emphasis> è stato modificato.</para></listitem>
    1.27  	<listitem><para id="x_73">Quando state lavorando con altre persone, il software per il controllo di revisione facilita la collaborazione. Per esempio, quando due persone effettuano cambiamenti incompatibili più o meno simultaneamente, il software vi aiuterà a identificare e risolvere questi conflitti.</para></listitem>
    1.28  	<listitem><para id="x_74">Può aiutarvi a recuperare dai vostri errori. Se fate una modifica che più tardi si rivela essere un errore, potete ritornare a una versione precedente di uno o più file. In effetti, uno strumento di controllo di revisione <emphasis>davvero</emphasis> buono vi aiuterà a calcolare efficientemente il momento esatto in cui un problema è stato introdotto (si veda FIXME <!--<xref linkend="sec:undo:bisect"/>--> per i dettagli).</para></listitem>
    1.29 -	<listitem><para id="x_75">Vi aiuterà a lavorare simultaneamente su versioni multiple del vostro progetto e a gestire gli spostamenti tra una versione e l'altra.</para></listitem>
    1.30 +	<listitem><para id="x_75">Vi aiuterà a lavorare simultaneamente su molteplici versioni del vostro progetto e a gestire gli spostamenti tra una versione e l'altra.</para></listitem>
    1.31        </itemizedlist>
    1.32  
    1.33 -      <para id="x_76">La maggior parte di queste ragioni sono ugualmente valide&emdash;almeno in teoria&emdash;sia che lavoriate su un progetto da soli sia che lavoriate insieme a un centianio di altre persone.</para>
    1.34 -
    1.35 -      <para id="x_77">Un aspetto chiave della praticità del controllo di revisione a queste due scale differenti (<quote>hacker solitario</quote> e <quote>gruppo gigantesco</quote>) è come i suoi <emphasis>benefici</emphasis> si confrontano con i suoi <emphasis>costi</emphasis>. Uno strumento di controllo di revisione che sia difficile da capire e usare finirà per imporre un costo piuttosto alto.</para>
    1.36 -
    1.37 -      <para id="x_78">Un progetto di cinquecento persone è probabile che collassi sotto il proprio peso quasi immediatamente senza un processo e uno strumento di controllo di revisione. In questo caso, il costo di usare il controllo di revisione potrebbe difficilmente sembrare meritevole di considerazione, dato che <emphasis>senza</emphasis> di esso il fallimento del progetto è quasi garantito.</para>
    1.38 -
    1.39 -      <para id="x_79">D'altra parte, il <quote>lavoretto veloce</quote> di una singola persona potrebbe sembrare il posto meno adatto per impiegare uno strumento di controllo di revisione, perché sicuramente il costo di usarne uno deve essere vicino al costo complessivo del progetto. Giusto?</para>
    1.40 +      <para id="x_76">La maggior parte di queste ragioni sono ugualmente valide&emdash;almeno in teoria&emdash;sia che lavoriate su un progetto da soli sia che collaboriate insieme a un centianio di altre persone.</para>
    1.41 +
    1.42 +      <para id="x_77">Un aspetto chiave della praticità del controllo di revisione a queste due dimensioni di sviluppo differenti (<quote>programmatore solitario</quote> e <quote>gruppo gigantesco</quote>) è come i suoi <emphasis>benefici</emphasis> si confrontano con i suoi <emphasis>costi</emphasis>. Uno strumento di controllo di revisione che sia difficile da capire e usare finirà per imporre un costo piuttosto alto.</para>
    1.43 +
    1.44 +      <para id="x_78">&Egrave; probabile che un progetto di cinquecento persone collassi sotto il proprio peso quasi immediatamente senza un processo e uno strumento di controllo di revisione. In questo caso, il costo di usare il controllo di revisione potrebbe sembrare difficilmente meritevole di considerazione, dato che <emphasis>senza</emphasis> di esso il fallimento del progetto è quasi garantito.</para>
    1.45 +
    1.46 +      <para id="x_79">D'altra parte, il <quote>lavoretto veloce</quote> di una singola persona potrebbe sembrare il contesto meno adatto per impiegare uno strumento di controllo di revisione, perché sicuramente il costo di usarne uno deve essere vicino al costo complessivo del progetto. Giusto?</para>
    1.47  
    1.48        <para id="x_7a">Mercurial supporta in maniera unica <emphasis>entrambe</emphasis> queste dimensioni di sviluppo. Potete impararne le basi in pochi minuti appena, e grazie al suo basso overhead, potete applicare il controllo di revisione al più piccolo dei progetti con facilità. La sua semplicità significa che non avrete un sacco di concetti astrusi o di sequenze di comandi a competere per il vostro spazio mentale con qualsiasi cosa stiate <emphasis>davvero</emphasis> cercando di fare. Allo stesso tempo, le elevate prestazioni e la natura peer-to-peer di Mercurial vi permetteranno di scalare in maniera indolore per gestire grandi progetti.</para>
    1.49  
    1.50 @@ -42,13 +42,13 @@
    1.51      <sect2>
    1.52        <title>I molti nomi del controllo di revisione</title>
    1.53  
    1.54 -      <para id="x_7c">Il controllo di revisione è un campo talmente vario che ci si riferisce spesso attraverso molti nomi e acronimi. Ecco alcune delle variazioni più comuni che incontrerete:</para>
    1.55 +      <para id="x_7c">Il controllo di revisione è un campo talmente vario che ci si riferisce spesso attraverso numerosi nomi e acronimi. Ecco alcune delle variazioni più comuni che incontrerete:</para>
    1.56        <itemizedlist>
    1.57 -	<listitem><para id="x_7d">Controllo di revisione (RCS)</para></listitem>
    1.58 -	<listitem><para id="x_7e">Gestione della configurazione del software (SCM), o gestione della configurazione</para></listitem>
    1.59 -	<listitem><para id="x_7f">Gestione del codice sorgente</para></listitem>
    1.60 -	<listitem><para id="x_80">Controllo del codice sorgente, o controllo dei sorgenti</para></listitem>
    1.61 -	<listitem><para id="x_81">Controllo di versione (VCS)</para></listitem>
    1.62 +	<listitem><para id="x_7d">controllo di revisione (RCS)</para></listitem>
    1.63 +	<listitem><para id="x_7e">gestione della configurazione del software (SCM), o gestione della configurazione</para></listitem>
    1.64 +	<listitem><para id="x_7f">gestione del codice sorgente</para></listitem>
    1.65 +	<listitem><para id="x_80">controllo del codice sorgente, o controllo dei sorgenti</para></listitem>
    1.66 +	<listitem><para id="x_81">controllo di versione (VCS)</para></listitem>
    1.67        </itemizedlist>
    1.68        <para id="x_82">Alcune persone affermano che questi termini in realtà abbiano significati differenti, ma in pratica si sovrappongono così tanto che non c'è alcun modo concordato o persino utile di distinguerli.</para>
    1.69  
    1.70 @@ -58,13 +58,13 @@
    1.71    <sect1>
    1.72      <title>A proposito degli esempi in questo libro</title>
    1.73  
    1.74 -    <para id="x_84">Questo libro adotta un approccio inusuale agli esempi di codice. Tutti gli esempi sono <quote>vivi</quote>&emdash;ognuno di essi è in effetti il risultato di uno script di shell che esegue i comandi Mercurial che vedete. Ogni volta che una immagine del libro viene costruita dai suoi sorgenti, tutti gli script di esempio vengono automaticamente eseguiti, e i loro risultati correnti vengono confrontati con i loro risultati attesi.</para>
    1.75 -
    1.76 -    <para id="x_85">Il vantaggio di questo approccio è che gli esempi sono sempre accurati; essi descrivono <emphasis>esattamente</emphasis> il comportamento della versione di Mercurial che è menzionata sulla copertina del libro. Se aggiorno la versione di Mercurial che sto documentando, e l'uscita di qualche comando cambia, il processo di costruzione del libro fallisce.</para>
    1.77 -
    1.78 -    <para id="x_86">C'è un piccolo svantaggio in questo approccio, cioè che le date e gli orari che vedete negli esempi tendono a venire <quote>schiacciati</quote> insieme in un modo in cui non lo sarebbero se gli stessi comandi venissero digitati da un essere umano. Laddove un essere umano non può inviare più di un comando ogni pochi secondi, con qualsiasi marcatura temporale risultante analogamente spiegata, i miei script d'esempio automatizzati sono in grado di eseguire molti comandi in un secondo.</para>
    1.79 -
    1.80 -    <para id="x_87">Come conseguenza di questo fatto, molti commit consecutivi in un esempio possono mostrare di essere occorsi durante lo stesso secondo. Potete vedere questo capitare nell'esempio di <literal role="hg-ext">bisezione</literal> in FIXME <!--<xref linkend="sec:undo:bisect"/>-->, per esempio.</para>
    1.81 +    <para id="x_84">Questo libro tratta gli esempi di codice in maniera inusuale. Tutti gli esempi sono <quote>vivi</quote>&emdash;ognuno di essi è in effetti il risultato di uno script di shell che esegue i comandi Mercurial che vedete. Ogni volta che un'immagine del libro viene costruita dai suoi sorgenti, tutti gli script di esempio vengono automaticamente eseguiti e i loro risultati correnti vengono confrontati con i loro risultati attesi.</para>
    1.82 +
    1.83 +    <para id="x_85">Il vantaggio di questo approccio è che gli esempi sono sempre accurati, in quanto descrivono <emphasis>esattamente</emphasis> il comportamento della versione di Mercurial menzionata sulla copertina del libro. Se aggiorno la versione di Mercurial che sto documentando, e il risultato di qualche comando cambia, il processo di costruzione del libro fallisce.</para>
    1.84 +
    1.85 +    <para id="x_86">C'è un piccolo svantaggio in questo approccio, cioè che le date e gli orari che vedete negli esempi tendono a venire <quote>schiacciati</quote> insieme in modo anomalo, diversamente da quanto accadrebbe se gli stessi comandi venissero digitati da un essere umano. Laddove un essere umano non può inviare più di un comando ogni pochi secondi, le cui marcature temporali sarebbero analogamente intervallate, i miei script d'esempio automatizzati sono in grado di eseguire molti comandi in un secondo.</para>
    1.86 +
    1.87 +    <para id="x_87">Come conseguenza di questo fatto, potrebbe sembrare che molti commit consecutivi siano occorsi durante lo stesso secondo. Potete vedere questo capitare nell'esempio di <literal role="hg-ext">bisezione</literal> in FIXME <!--<xref linkend="sec:undo:bisect"/>-->, per esempio.</para>
    1.88  
    1.89      <para id="x_88">Quindi mentre leggete gli esempi non date troppo peso alle date e agli orari che vedete nell'uscita dei comandi. Ma potete <emphasis>decisamente</emphasis> fidarvi che il comportamento che vedete è consistente e riproducibile.</para>
    1.90  
    1.91 @@ -75,7 +75,7 @@
    1.92  
    1.93      <para id="x_89">Ci sono state alcune inconfondibili tendenze nello sviluppo e nell'utilizzo degli strumenti di controllo di revisione nelle ultime quattro decadi, man mano che le persone hanno acquisito familiarità con le capacità dei loro strumenti e sono state vincolate dalle loro limitazioni.</para>
    1.94  
    1.95 -    <para id="x_8a">La prima generazione ha cominciato col gestire singoli file su singoli computer. Sebbene questi strumenti rappresentassero un enorme avanzamento rispetto al controllo di revisione manuale effettuato ad hoc, il loro modello di locking (bloccaggio) e l'affidamento su di un singolo computer li limitarono a piccoli gruppi strettamente uniti.</para>
    1.96 +    <para id="x_8a">La prima generazione ha cominciato col gestire singoli file su singoli computer. Sebbene questi strumenti rappresentassero un enorme avanzamento rispetto al controllo di revisione manuale effettuato ad hoc, il loro modello di locking (bloccaggio) e l'affidamento su di un singolo computer limitarono il loro impiego a piccoli gruppi strettamente uniti.</para>
    1.97  
    1.98      <para id="x_8b">La seconda generazione ha rilassato questi vincoli spostandosi su architetture di rete e gestendo interi progetti alla volta. Man mano che i progetti diventarono grandi, gli strumenti incontrarono nuovi problemi. Con i client bisognosi di parlare con i server molto frequentemente, la scalabilità dei server divenne un problema per progetti di grandi dimensioni. Una connessione di rete inaffidabile poteva impedire agli utenti remoti di essere in grado di parlare al server del tutto. Man mano che i progetti open source cominciarono a rendere l'accesso in sola lettura disponibile a chiunque in forma anonima, persone senza privilegi di commit scoprirono che non potevano usare gli strumenti per interagire con un progetto in un modo naturale, in quanto non erano in grado di registrare le modifiche da loro effettuate.</para>
    1.99  
   1.100 @@ -85,46 +85,46 @@
   1.101    <sect1>
   1.102      <title>Alcuni vantaggi del controllo di revisione distribuito</title>
   1.103  
   1.104 -    <para id="x_8d">Sebbene gli stumenti distribuiti di controllo di revisione si siano mantenuti per diversi anni robusti e usabili tanto quanto le loro controparti delle generazioni precedenti, le persone che utilizzavano strumenti più vecchi non si sono ancora necessariamente accorte dei loro vantaggi. Ci sono diversi modi in cui gli strumenti distribuiti brillano rispetto a quelli centralizzati.</para>
   1.105 -
   1.106 -    <para id="x_8e">Per un singolo sviluppatore, gli strumenti distribuiti sono quasi sempre più veloci di quelli centralizzati. Questo accade per una semplice ragione: uno strumento centralizzato ha bisogno di utilizzare la rete per molte operazioni comuni, perché la maggior parte dei metadati sono memorizzati in una singola copia sul server centrale. Uno strumento distribuito memorizza tutti i suoi metadati localmente. A parità di altre condizioni, utilizzare la rete aggiunge un overhead a uno strumento centralizzato. Non sottostimate il valore di uno strumento veloce e reattivo: vi troverete a passare molto tempo interagendo con il vostro software di controllo di revisione.</para>
   1.107 -
   1.108 -    <para id="x_8f">Gli strumenti distribuiti sono indifferenti alle stravaganze della infrastruttura dei vostri server, sempre perché replicano i metadati in così tanti luoghi. Se usate un sistema centralizzato e il vostro server si guasta, fareste meglio a sperare che il vostro sistema di backup sia affidabile e che il vostro ultimo backup sia recente ed effettivamente funzionante. Con uno strumento distribuito, avete tanti backup disponibili sui computer di ogni singolo collaboratore.</para>
   1.109 +    <para id="x_8d">Sebbene gli stumenti per il controllo di revisione distribuito si siano mantenuti per diversi anni robusti e usabili tanto quanto le loro controparti delle generazioni precedenti, questo non vuol dire che le persone che utilizzavano strumenti più vecchi si siano necessariamente accorte dei loro vantaggi. Ci sono diversi modi in cui gli strumenti distribuiti brillano rispetto a quelli centralizzati.</para>
   1.110 +
   1.111 +    <para id="x_8e">Per un singolo sviluppatore, gli strumenti distribuiti sono quasi sempre più veloci di quelli centralizzati. Questo avviene per una semplice ragione: uno strumento centralizzato ha bisogno di utilizzare la rete per molte operazioni comuni, perché la maggior parte dei metadati sono memorizzati in una singola copia sul server centrale. Uno strumento distribuito memorizza tutti i suoi metadati localmente. A parità di altre condizioni, utilizzare la rete aggiunge un overhead a uno strumento centralizzato. Non sottostimate il valore di uno strumento veloce e reattivo: vi troverete a passare molto tempo interagendo con il vostro software di controllo di revisione.</para>
   1.112 +
   1.113 +    <para id="x_8f">Gli strumenti distribuiti sono indifferenti alle stravaganze dell'infrastruttura dei vostri server, sempre perché replicano i metadati in così tanti luoghi. Se usate un sistema centralizzato e il vostro server si guasta, fareste meglio a sperare che il vostro sistema di backup sia affidabile e che il vostro ultimo backup sia recente ed effettivamente funzionante. Con uno strumento distribuito, avete molti backup disponibili sui computer di ogni singolo collaboratore.</para>
   1.114  
   1.115      <para id="x_90">L'affidabilità della vostra rete influenzerà gli strumenti distribuiti molto meno rispetto a quelli centralizzati. Non potete nemmeno usare uno strumento centralizzato senza una connessione di rete, a parte alcuni comandi altamente vincolati. Con uno strumento distribuito, potreste persino non notare se la vostra connessione di rete cade mentre state lavorando. L'unica cosa che non sarete in grado di fare è comunicare con i repository su altri computer, qualcosa che è relativamente raro rispetto alle operazioni locali. Questo potrebbe essere significativo solo se avete un gruppo di collaboratori sparso in luoghi lontani.</para>
   1.116  
   1.117      <sect2>
   1.118        <title>Vantaggi per i progetti open source</title>
   1.119  
   1.120 -      <para id="x_91">Se siete affascinati da un progetto open source e decidete che vi piacerebbe cominciare a lavorarci sopra, e quel progetto usa uno strumento distribuito di controllo di revisione, siete immediatamente alla pari con il gruppo di persone che si considerano il <quote>cuore</quote> di quel progetto. Se loro pubblicano il proprio repository, potete immediatamente copiare la loro storia del progetto, cominciare a effettuare modifiche e registrare il vostro lavoro utilizzando gli stessi strumenti allo stesso modo dei membri del gruppo. Al contrario, con uno strumento centralizzato, siete costretti a usare il software in modalità di <quote>sola lettura</quote> a meno che qualcuno non vi conceda il permesso di effettuare il commit dei vostri cambiamenti al loro server centrale. Fino a quel momento, non sarete in grado di registrare i cambiamenti e le vostre modifiche rischieranno di venire corrotte ogni volta che provate ad aggiornare la vista del repository dal vostro client.</para>
   1.121 +      <para id="x_91">Se siete affascinati da un progetto open source e decidete che vi piacerebbe cominciare a lavorarci sopra, e quel progetto usa uno strumento distribuito di controllo di revisione, siete immediatamente alla pari con il gruppo di persone che si considerano il <quote>cuore</quote> di quel progetto. Se loro pubblicano il proprio repository, potete immediatamente copiare la loro cronologia del progetto, cominciare a effettuare modifiche e registrare il vostro lavoro utilizzando gli stessi strumenti allo stesso modo dei membri del gruppo. Al contrario, con uno strumento centralizzato, siete costretti a usare il software in modalità di <quote>sola lettura</quote> a meno che qualcuno non vi conceda il permesso di effettuare il commit dei vostri cambiamenti al loro server centrale. Fino a quel momento, non sarete in grado di registrare i cambiamenti e le vostre modifiche rischieranno di venire corrotte ogni volta che provate ad aggiornare la vista del repository dal vostro client.</para>
   1.122  
   1.123        <sect3>
   1.124  	<title>Il falso problema del forking</title>
   1.125  
   1.126  	<para id="x_92">&Egrave; stato suggerito che gli strumenti per il controllo di revisione distribuito espongano i progetti open source a un certo tipo di rischio in quanto rendono facile <quote>biforcare</quote> lo sviluppo di un progetto. Un fork capita quando ci sono differenze di opinione o di attitudine tra gruppi di sviluppatori che li portano a decidere di non poter lavorare insieme più a lungo. Ogni parte prende una copia più o meno completa del codice sorgente del progetto e prosegue per la propria strada.</para>
   1.127  
   1.128 -	<para id="x_93">Talvolta le parti di un fork decidono di riconciliare le loro differenze. Con uno strumento centralizzato di controllo di revisione, il processo <emphasis>tecnico</emphasis> di riconciliazione è doloroso e deve essere effettuato in gran parte a mano. Dovete decidere quale storia delle revisioni dovrà <quote>prevalere</quote> e introdurvi in qualche modo i cambiamenti dell'altro gruppo. Di solito, questo risulta nella perdita parziale o completa della storia delle revisioni di una delle due parti.</para>
   1.129 -
   1.130 -	<para id="x_94">Quello che gli strumenti distribuiti fanno rispetto alla biforcazione è che rendono la biforcazione <emphasis>l'unico</emphasis> modo per sviluppare un progetto. Ogni singolo cambiamento effettuato è un potenziale punto di biforcazione. La grande forza di questo approccio è che uno strumento per il controllo di revisione distribuito deve essere davvero bravo a <emphasis>fondere</emphasis> due fork, perché i fork sono assolutamente fondamentali: vengono effettuati in ogni momento.</para>
   1.131 -
   1.132 -	<para id="x_95">Se ogni frammento di lavoro che tutti fanno, in ogni momento, viene concepito in termini di biforcazioni e fusioni, allora ciò che il mondo open source chiama <quote>fork</quote> diventa un problema <emphasis>puramente</emphasis> sociale. Se gli strumenti distribuiti fanno qualcosa, quello che fanno è <emphasis>abbassare</emphasis> la probabilità di un fork:</para>
   1.133 +	<para id="x_93">Talvolta le parti di un fork decidono di riconciliare le loro differenze. Con uno strumento centralizzato di controllo di revisione, il processo <emphasis>tecnico</emphasis> di riconciliazione è doloroso e deve essere in gran parte effettuato a mano. Dovete decidere quale cronologia delle revisioni dovrà <quote>prevalere</quote> e introdurvi in qualche modo i cambiamenti dell'altro gruppo. Di solito, questo risulta nella perdita parziale o completa della cronologia delle revisioni di una delle due parti.</para>
   1.134 +
   1.135 +	<para id="x_94">Quello che gli strumenti distribuiti fanno rispetto alla biforcazione è che rendono la biforcazione <emphasis>l'unico</emphasis> modo per sviluppare un progetto. Ogni singolo cambiamento effettuato è un potenziale punto di biforcazione. La grande forza di questo approccio è che uno strumento per il controllo di revisione distribuito deve essere davvero bravo a <emphasis>unire</emphasis> due fork, perché i fork sono assolutamente fondamentali: vengono effettuati in ogni momento.</para>
   1.136 +
   1.137 +	<para id="x_95">Se ogni frammento di lavoro che tutti fanno, in ogni momento, viene concepito in termini di biforcazioni e unioni, allora ciò che il mondo open source chiama <quote>fork</quote> diventa un problema <emphasis>puramente</emphasis> sociale. Se gli strumenti distribuiti fanno qualcosa, quello che fanno è <emphasis>ridurre</emphasis> la probabilità di un fork:</para>
   1.138  	<itemizedlist>
   1.139 -	  <listitem><para id="x_96">Essi eliminano la distinzione sociale imposta dagli strumenti centralizzati: quella tra le persone all'interno del gruppo con i permessi di commit e le persone all'esterno del gruppo, senza tali permessi.</para></listitem>
   1.140 -	  <listitem><para id="x_97">Essi rendono più facile riconciliarsi dopo un fork sociale, perché l'unica cosa che viene coinvolta dal punto di vista del software di controllo di revisione è semplicemente un'altra fusione.</para></listitem>
   1.141 +	  <listitem><para id="x_96">eliminano la distinzione sociale imposta dagli strumenti centralizzati, cioè quella tra le persone all'interno del gruppo con i permessi di commit e le persone all'esterno del gruppo, senza tali permessi.</para></listitem>
   1.142 +	  <listitem><para id="x_97">rendono più facile riconciliarsi dopo un fork sociale, perché l'unica cosa che viene coinvolta dal punto di vista del software di controllo di revisione è semplicemente un'altra unione.</para></listitem>
   1.143      </itemizedlist>
   1.144  
   1.145 -	<para id="x_98">Alcune persone oppongono resistenza agli strumenti distribuiti perché vogliono mantenere uno stretto controllo sui propri progetti e credono che gli strumenti centralizzati diano loro questo controllo. Tuttavia, se siete tra quelli che credono a questo, e il vostro repository CVS o Subversion è disponibile pubblicamente, ci sono un sacco di strumenti disponibili che possono estrarre l'intera storia del vostro progetto (sebbene lentamente) e ricrearla da qualche altra parte al di là del vostro controllo. Quindi non solo il vostro controllo in questo caso è illusorio, ma state rinunciando all'abilità di collaborare fluidamente con chiunque si senta in dovere di duplicare la storia del vostro progetto.</para>
   1.146 +	<para id="x_98">Alcune persone oppongono resistenza agli strumenti distribuiti perché vogliono mantenere uno stretto controllo sui propri progetti e credono che gli strumenti centralizzati diano loro questo controllo. Tuttavia, se siete tra quelli che credono a questo, e il vostro repository CVS o Subversion è disponibile pubblicamente, esistono un sacco di strumenti che possono estrarre l'intera storia del vostro progetto (sebbene lentamente) e ricrearla da qualche altra parte al di là del vostro controllo. Quindi non solo il vostro controllo in questo caso è illusorio, ma state rinunciando alla possibilità di collaborare fluidamente con chiunque si senta in dovere di duplicare la storia del vostro progetto.</para>
   1.147  
   1.148        </sect3>
   1.149      </sect2>
   1.150      <sect2>
   1.151        <title>Vantaggi per i progetti commerciali</title>
   1.152  
   1.153 -      <para id="x_99">Molti progetti commerciali sono intrapresi da gruppi che sono dispersi attraverso il globo. Collaboratori che sono lontani da un server centrale vedranno un'esecuzione dei comandi più lenta e forse una minore affidabilità. I sistemi commerciali di controllo di revisione tentano di mitigare questi problemi con componenti aggiuntivi per la replicazione di siti remoti che sono tipicamente costosi da comprare e intrattabili da amministrare. Un sistema distribuito non soffre di questi problemi in prima istanza. Ancora meglio, potete facilmente configurare multipli server autoritari, diciamo uno per ogni sito, in modo che non ci siano comunicazioni ridondanti tra i repository durante i costosi collegamenti di rete a grande distanza.</para>
   1.154 -
   1.155 -      <para id="x_9a">I sistemi centralizzati per il controllo di revisione tendono ad avere una scalabilità relativamente bassa. Non è inusuale per un costoso sistema centralizzato cadere sotto il carico combinato di una sola dozzina di utenti concorrenti. Ancora una volta, la tipica risposta tende a essere un dispositivo di replicazione costoso e macchinoso. Dato che il carico su un server centrale&emdash;sempre che ne abbiate uno&emdash;è molte volte più basso con uno strumento distribuito (perché tutti i dati sono replicati ovunque), un singolo server economico può gestire i bisogni di un gruppo di lavoro molto più grande e la replicazione per il bilancio del carico diventa una semplice questione di scripting.</para>
   1.156 -
   1.157 -      <para id="x_9b">Se avete un impiegato nel campo, che sta risolvendo un problema nella sede di un cliente, beneficerà del controllo di revisione distribuito. Gli strumenti gli permetteranno di generare versioni personalizzare del software nel repository, provare soluzioni differenti isolandole l'una dall'altra e di cercare in maniera efficiente attraverso la storia delle revisioni le sorgenti di bug e regressioni nell'ambiente del cliente, il tutto senza aver bisogno di collegarsi alla rete della vostra azienda.</para>
   1.158 +      <para id="x_99">Molti progetti commerciali vengono intrapresi da gruppi che sono dispersi attraverso il globo. I collaboratori lontani da un server centrale vedranno un'esecuzione dei comandi più lenta e forse una minore affidabilità. I sistemi commerciali di controllo di revisione tentano di mitigare questi problemi tramite componenti aggiuntivi per la replicazione di siti remoti che sono tipicamente costosi da comprare e intrattabili da amministrare. Un sistema distribuito non soffre di questi problemi in prima istanza. Ancora meglio, potete facilmente configurare multipli server autoritari, diciamo uno per ogni sito, in modo che non ci siano comunicazioni ridondanti tra i repository durante i costosi collegamenti di rete a grande distanza.</para>
   1.159 +
   1.160 +      <para id="x_9a">I sistemi centralizzati per il controllo di revisione tendono ad avere una scalabilità relativamente bassa. Non è inusuale per un costoso sistema centralizzato cadere sotto il carico combinato di una sola dozzina di utenti concorrenti. Ancora una volta, la tipica risposta tende a essere un dispositivo di replicazione costoso e macchinoso. Dato che il carico su un server centrale&emdash;sempre che ne abbiate uno&emdash;è molto più basso con uno strumento distribuito (perché tutti i dati sono replicati ovunque), un singolo server economico può gestire i bisogni di un gruppo di lavoro molto più grande e la replicazione per il bilancio del carico diventa una semplice questione di scripting.</para>
   1.161 +
   1.162 +      <para id="x_9b">I vostri impiegati potranno beneficiare del controllo di versione distribuito anche quando stanno risolvendo un problema nella sede di un cliente. Gli strumenti permetteranno loro di generare versioni personalizzare del software nel repository, provare soluzioni differenti isolandole l'una dall'altra e cercare in maniera efficiente attraverso la cronologia delle revisioni le sorgenti di bug e regressioni nell'ambiente del cliente, il tutto senza aver bisogno di collegarsi alla rete della vostra azienda.</para>
   1.163  
   1.164      </sect2>
   1.165    </sect1>
   1.166 @@ -145,35 +145,35 @@
   1.167  
   1.168      <para id="x_a3">L'utilità di Mercurial non si limita ai piccoli progetti: è usato da progetti con centinaia di migliaia di collaboratori, ognuno contenente decine di migliaia di file e centinaia di megabyte di codice sorgente.</para>
   1.169  
   1.170 -    <para id="x_a4">Se le funzionalità principali di Mercurial non sono sufficienti per voi, è facile aggiungere. Mercurial è molto adatto alla programmazione delle proprie operazioni, e la sua pulita implementazione in Python rende faile aggiungere funzionalità sotto forma di estensioni. Esiste un certo numero di estensioni utili e pooplari già disponibili, che spaziano dal supporto alla identificazione dei bug al miglioramento delle prestazioni.</para>
   1.171 +    <para id="x_a4">Se le funzionalità principali di Mercurial non sono sufficienti per voi, è facile aggiungere. Mercurial è molto adatto alla programmazione delle proprie operazioni, e la sua pulita implementazione in Python rende facile aggiungere funzionalità sotto forma di estensioni. Esistono già un certo numero di estensioni utili e popolari, che spaziano dal supporto alla identificazione dei bug al miglioramento delle prestazioni.</para>
   1.172  
   1.173    </sect1>
   1.174    <sect1>
   1.175      <title>Un confronto tra Mercurial e altri strumenti</title>
   1.176  
   1.177 -    <para id="x_a5">Prima di proseguire, vi prego di tenere a mente che questa sezione riflette necessariamente la mia esperienza, i miei interessi e (oserei dire) i miei pregiudizi. Ho usato tutti i sistemi di controllo di revisione elencati sotto, in più casi per diversi anni alla volta.</para>
   1.178 +    <para id="x_a5">Prima di proseguire, vi prego di tenere a mente che questa sezione riflette necessariamente la mia esperienza, i miei interessi e (oserei dire) i miei pregiudizi. Ho usato tutti i sistemi di controllo di revisione qui elencati, in più casi per diversi anni alla volta.</para>
   1.179  
   1.180      <sect2>
   1.181        <title>Subversion</title>
   1.182  
   1.183        <para id="x_a6">Subversion è un sistema di controllo di revisione piuttosto popolare, sviluppato per sostituire CVS. Ha un'architettura client/server centralizzata.</para>
   1.184  
   1.185 -      <para id="x_a7">Subversion e Mercurial hanno comandi dal nome simile per effettuare le stesse operazioni, così se avete familiarità con uno dei due è facile imparare a usare l'altro. Entrambi gli strumenti sono portabili su tutti i sistemi operativi più popolari.</para>
   1.186 -
   1.187 -      <para id="x_a8">Prima della versione 1.5, Subversion non aveva alcun supporto utile per le fusioni. Al momento della scrittura, la sua funzionalità per il tracciamento delle fusioni è nuova e nota per essere <ulink
   1.188 +      <para id="x_a7">Subversion e Mercurial hanno comandi con nomi simile per effettuare le stesse operazioni, così se avete familiarità con uno dei due è facile imparare a usare l'altro. Entrambi gli strumenti sono portabili su tutti i sistemi operativi più popolari.</para>
   1.189 +
   1.190 +      <para id="x_a8">Prima della versione 1.5, Subversion non aveva alcun supporto utile per le unioni. Al momento della scrittura, la sua funzionalità per il tracciamento delle unioni è nuova e nota per essere <ulink
   1.191  	  url="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword">complicata e difettosa</ulink>.</para>
   1.192  
   1.193 -      <para id="x_a9">Mercurial ha un sostanzioso vantaggio in termini di prestazioni rispetto a Subversion su tutte le operazioni di controllo di revisione di cui ho effettuato il benchmark. Il suo vantaggio si misura in un intervallo che va da un fattore di due a un fattore di sei quando lo si confronta con il file store <emphasis>ra_local</emphasis> di Subversion 1.4.3, che è il metodo di accesso più veloce disponibile. In situazioni più realistiche che coinvolgono uno store basato su rete, Subversion sconterà uno svantaggio sostanzialmente più consistente. Dato che molti comandi di Subversion devono comunicare con il server e Subversion non è dotato di meccanismi utili di replicazione, la capacità del server e la banda di rete diventano colli di bottiglia per progetti di dimensioni moderate.</para>
   1.194 -
   1.195 -      <para id="x_aa">In più, Subversion si espone a un sostanziale overhead di storage per evitare transazioni di rete per alcune operazioni comuni, come trovare i file modificati (<literal>status</literal>) e visualizzare le modifiche rispetto alla revisione corrente (<literal>diff</literal>). Come risultato, una copia di lavoro di un repository Subversion è spesso della stesse dimensioni, se non più grande, di un repository Mercurial intero e della sua directory di lavoro, anche se il repository Mercurial contiene la cronologia completa del progetto.</para>
   1.196 -
   1.197 -      <para id="x_ab">Subversion è ampiamente supportato da strumenti di terze parti. Mercurial è considerevolmente indietro in quest'area. Il divario si sta chiudendo, tuttavia, e in effetti alcuni degli strumenti di interfaccia grafica di Mercurial attualmente offuscano i loro equivalenti per Subversion. Come Mercurial, Subversion è dotato di un eccellente manuale utente.</para>
   1.198 +      <para id="x_a9">Mercurial ha un sostanzioso vantaggio in termini di prestazioni rispetto a Subversion per tutte le operazioni di controllo di revisione di cui ho effettuato il benchmark. Il suo vantaggio si misura in un intervallo che va da un fattore di due a un fattore di sei quando lo si confronta con il file store <emphasis>ra_local</emphasis> di Subversion 1.4.3, che è il metodo di accesso più veloce disponibile. In situazioni più realistiche che coinvolgono uno store basato su rete, Subversion sconterà uno svantaggio sostanzialmente più consistente. Dato che molti comandi di Subversion devono comunicare con il server e Subversion non è dotato di meccanismi utili di replicazione, la capacità del server e la banda di rete diventano colli di bottiglia per progetti di dimensioni moderate.</para>
   1.199 +
   1.200 +      <para id="x_aa">In più, Subversion si espone a un sostanziale overhead di storage per evitare transazioni di rete per alcune operazioni comuni, come trovare i file modificati (<literal>status</literal>) e visualizzare le modifiche rispetto alla revisione corrente (<literal>diff</literal>). Come risultato, una copia di lavoro di un repository Subversion è spesso della stesse dimensioni, se non più grande, di un intero repository Mercurial più la sua directory di lavoro, anche nel caso in cui il repository Mercurial contenga la cronologia completa del progetto.</para>
   1.201 +
   1.202 +      <para id="x_ab">Subversion è ampiamente supportato da strumenti di terze parti. Mercurial è considerevolmente indietro in quest'area. Il divario si sta assottigliando, tuttavia, e in effetti alcuni degli strumenti di interfaccia grafica di Mercurial attualmente offuscano i loro equivalenti per Subversion. Come Mercurial, Subversion è dotato di un eccellente manuale d'uso.</para>
   1.203  
   1.204        <para id="x_ac">Dato che Subversion non memorizza la cronologia di revisione sul client, è molto adatto a gestire progetti che hanno a che fare con numerosi file binari opachi di grandi dimensioni. Se effettuate il check in di cinquanta revisioni di un file incomprimibile di 10MB, l'utilizzo di spazio sul lato client da parte di Subversion rimarrà costante. Lo spazio usato da qualunque SCM distribuito crescerà rapidamente in proporzione al numero delle revisioni, perché le differenze tra una revisione e l'altra sono grandi.</para>
   1.205  
   1.206 -      <para id="x_ad">In più, è spesso difficile o, più tipicamente, impossibile fondere differenti versioni di un file binario. L'abilità di Subversion di permettere a un utente di bloccare un file, in modo da ottenere temporaneamente i diritti esclusivi per effettuarvi camabiamenti, può essere un vantaggio significativo in progetti dove file binari vengono largamente utilizzati.</para>
   1.207 -
   1.208 -      <para id="x_ae">Mercurial può importare la cronologia di revisioni da un repository Subversion. Può anche esportare la propria cronologia di revisioni verso un repository Subversion. Questa caratteristica rende facile <quote>sentire l'acqua</quote> e usare Mercurial e Subverison in parallelo prima di decidere di cambiare. La conversione della cronologia è incrementale, così potete effettuare una conversione iniziale, poi piccole conversioni aggiuntive successivamente per introdurre nuovi cambiamenti.</para>
   1.209 +      <para id="x_ad">In più, è spesso difficile o, più tipicamente, impossibile unire differenti versioni di un file binario. L'abilità di Subversion di permettere a un utente di bloccare un file, in modo da ottenere temporaneamente i diritti esclusivi per effettuarvi camabiamenti, può essere un vantaggio significativo in progetti dove file binari vengono largamente utilizzati.</para>
   1.210 +
   1.211 +      <para id="x_ae">Mercurial può importare la cronologia delle revisioni da un repository Subversion. Può anche esportare la propria cronologia delle revisioni verso un repository Subversion. Questa caratteristica rende facile <quote>sentire l'acqua</quote> utilizzando Mercurial e Subverison in parallelo prima di decidere di cambiare. La conversione della cronologia è incrementale, così potete effettuare una conversione iniziale, poi piccole conversioni aggiuntive successivamente per introdurre nuovi cambiamenti.</para>
   1.212  
   1.213      </sect2>
   1.214      <sect2>
   1.215 @@ -185,9 +185,9 @@
   1.216  
   1.217        <para id="x_b1">In termini di prestazioni, Git è estremamente veloce. In molti casi, è più veloce di Mercurial, almeno sotto Linux, mentre Mercurial è più prestante in altre operazioni. Tuttavia, sotto Windows, le prestazioni e il livello generale di supporto offerto da Git sono, al momento della scrittura, molto più indietro rispetto a Mercurial.</para>
   1.218  
   1.219 -      <para id="x_b2">Mentre un repository Mercurial non ha bisogno di alcuna manutenzione, un repository Git richiede frequenti <quote>reimpacchettamenti</quote> manuali dei propri metadati. Senza questi, le prestazioni degradano, mentre l'utilizzo di spazio cresce rapidamente. Un server che contiene molti repository Git che non vengono rigorosamente e frequentemente reimpacchettati diventerà pesantemente legato al disco durante i backup, e ci sono state istanze di backup giornalieri che hanno impiegato molto di più di 24 ore come risultato. Un repository Git appena impacchettato è leggermente più piccolo di un repository Mercurial, ma un repository non impacchettato ha dimensioni maggiori di diversi ordini di grandezza.</para>
   1.220 -
   1.221 -      <para id="x_b3">Il cuore di Git è scritto in C. Molti comandi di Git sono implementati come script shell o Perl e la qualità di questi script varia grandemente. Ho incontrato diversi casi in cui gi script proseguivano ciecamente la propria esecuzione in presenza di errori che avrebbero dovuto essere fatali.</para>
   1.222 +      <para id="x_b2">Mentre un repository Mercurial non ha bisogno di alcuna manutenzione, un repository Git richiede frequenti <quote>reimpacchettamenti</quote> manuali dei propri metadati. Senza questi, le prestazioni degradano e l'utilizzo di spazio cresce rapidamente. Un server che contiene molti repository Git che non vengono rigorosamente e frequentemente reimpacchettati diventerà pesantemente legato al disco durante i backup, e ci sono state istanze di backup giornalieri che hanno impiegato molto più di 24 ore come risultato. Un repository Git appena impacchettato è leggermente più piccolo di un repository Mercurial, ma un repository non impacchettato ha dimensioni maggiori di diversi ordini di grandezza.</para>
   1.223 +
   1.224 +      <para id="x_b3">Il cuore di Git è scritto in C. Molti comandi di Git sono implementati come script di shell o in linguaggio Perl e la qualità di questi script varia grandemente. Ho incontrato diversi casi in cui gli script proseguivano ciecamente la propria esecuzione in presenza di errori che avrebbero dovuto essere fatali.</para>
   1.225  
   1.226        <para id="x_b4">Mercurial può importare la cronologia di revisione da un repository Git.</para>
   1.227  
   1.228 @@ -198,11 +198,11 @@
   1.229  
   1.230        <para id="x_b5">CVS è probabilmente lo strumento di controllo di revisione più largamente usato nel mondo. A causa della sua età e della sporcizia interna, è stato mantenuto solo alla leggera per molti anni.</para>
   1.231  
   1.232 -      <para id="x_b6">Ha un'architettura client/server centralizzata. Non raggruppa cambiamenti di file correlati in commit atomici, rendendo facile alle persone di <quote>guastare il software</quote>: una persona può effettuare con successo il commit di parte di un cambiamento e poi essere bloccata dalle necessità di una fusione, causando altre persone di vedere solo una porzione del lavoro che intendevano fare. Questo influisce anche su come si lavora con la cronologia del progetto. Se volete vedere tutte le modifiche che qualcuno ha effettuato come parte di un task, dovrete ispezionare manualmente le descrizioni e le marcature temporali dei cambiamenti fatti a ogni file coinvolto (sempre che sappiate quali fossero quei file).</para>
   1.233 +      <para id="x_b6">Ha un'architettura client/server centralizzata. Non raggruppa cambiamenti di file correlati in commit atomici, rendendo facile alle persone di <quote>guastare il software</quote>: una persona può effettuare con successo il commit di parte di un cambiamento e poi essere bloccata dalle necessità di un'unione, causando altre persone di vedere solo una porzione del lavoro che intendevano fare. Questo influisce anche su come si lavora con la cronologia del progetto. Se volete vedere tutte le modifiche che qualcuno ha effettuato come parte di un task, dovrete ispezionare manualmente le descrizioni e le marcature temporali dei cambiamenti fatti a ogni file coinvolto (sempre che sappiate quali fossero quei file).</para>
   1.234  
   1.235        <para id="x_b7">CVS ha una nozione confusa di etichette e rami di lavoro che non cercherò nemmeno di descrivere. Non supporta per bene il rinominare file o directory, rendendo facile corrompere un repository. Non ha quasi alcuna funzionalità per il controllo della consistenza interna, quindi tipicamente non è nemmeno possibile dire se un repository è corrotto. Non raccomanderei CVS per alcun progetto, nuovo o esistente.</para>
   1.236  
   1.237 -      <para id="x_b8">Mercurial può importare la cronologia di revisione da CVS. Tuttavia, ci sono alcune avvertenze da considerare; queste sono valide anche per qualsiasi altro strumento di controllo di revisione che importi da CVS. A causa della mancanza di cambiamenti atomici in CVS e mancanza di versioni per la gerarchia del filesystem, non è possibile ricostruire la cronologia di CVS in maniera completa e accurata; alcune supposizioni sono coinvolte, e le rinominazioni di solito non verranno mostrate. Dato che buona parte dell'amministrazione avanzata di CVS deve essere fatta a mano e quindi è propensa a errori, è comune per gli importatori di CVS incorrere in problemi multipli con repository corrotti (marcature temporali per le revisioni completamente fasulle e file che sono rimasti bloccati per più di un decennio sono solo due dei problemi meno interessanti che posso ricordare dalla mia esperienza personale).</para>
   1.238 +      <para id="x_b8">Mercurial può importare la cronologia di revisione da CVS. Tuttavia, ci sono alcune avvertenze da considerare; queste sono valide anche per qualsiasi altro strumento di controllo di revisione che importi da CVS. A causa della mancanza di cambiamenti atomici in CVS e mancanza di versioni per la gerarchia del filesystem, non è possibile ricostruire la cronologia di CVS in maniera completa e accurata; alcune supposizioni sono coinvolte, e le rinominazioni di solito non verranno mostrate. Dato che buona parte dell'amministrazione avanzata di CVS deve essere fatta a mano e quindi è propensa a errori, è comune per gli importatori di CVS incorrere in problemi multipli con repository corrotti (marcature temporali completamente fasulle per le revisioni e file che sono rimasti bloccati per più di un decennio sono solo due dei problemi meno interessanti che posso ricordare dalla mia esperienza personale).</para>
   1.239  
   1.240        <para id="x_b9">Mercurial può importare la cronologia di revisione da un repository CVS.</para>
   1.241  
   1.242 @@ -212,24 +212,24 @@
   1.243  
   1.244        <para id="x_ba">Perforce ha un'architettura client/server centralizzata, senza alcuna memorizzazione dei dati sul lato client. A differenza degli strumenti di controllo di revisione moderni, Perforce richiede che l'utente lanci un comando per comunicare al server di voler modificare un file qualsiasi.</para>
   1.245  
   1.246 -      <para id="x_bb">Le prestazioni di Perforce sono piuttosto buone per piccoli gruppi di lavoro, ma decadono rapidamente man mano che il numero di utenti cresce oltre le poche dozzine. Installazioni di Perforce di modeste dimensioni richiedono l'utilizzo di proxy per fronteggiare il carico generato dai loro utenti.</para>
   1.247 +      <para id="x_bb">Le prestazioni di Perforce sono piuttosto buone per piccoli gruppi di lavoro, ma decadono rapidamente man mano che il numero di utenti cresce oltre le poche dozzine. Installazioni di Perforce di modeste dimensioni richiedono l'utilizzo di proxy per fronteggiare il carico generato dai propri utenti.</para>
   1.248  
   1.249      </sect2>
   1.250      <sect2>
   1.251        <title>Scegliere uno strumento di controllo di revisione</title>
   1.252  
   1.253 -      <para id="x_bc">Con l'eccezione di CVS, tutti gli strumenti elencati sopra hanno forze uniche che li rendono adatti a particolari stili di lavoro. Non esiste un singolo strumento di controllo di revisione che sia il migliore in tutte le situazioni.</para>
   1.254 +      <para id="x_bc">Con l'eccezione di CVS, tutti gli strumenti elencati sopra hanno qualità uniche che li rendono adatti a particolari stili di lavoro. Non esiste un singolo strumento di controllo di revisione che sia il migliore in tutte le situazioni.</para>
   1.255  
   1.256        <para id="x_bd">Per fare un esempio, Subversion è una buona scelta per lavorare con file binari frequentemente modificati, a causa della sua natura centralizzata e del supporto per il locking dei file.</para>
   1.257  
   1.258 -      <para id="x_be">Personalmente trovo che le caratteristiche di Mercurial come la semplicità, le prestazioni, e un buon supporto per le fusioni, siano una combinazione irresistibile che mi ha servito bene per diversi anni.</para>
   1.259 +      <para id="x_be">Personalmente trovo che le caratteristiche di Mercurial come la semplicità, le prestazioni, e un buon supporto per le unioni, siano una combinazione irresistibile che mi ha servito bene per diversi anni.</para>
   1.260  
   1.261      </sect2>
   1.262    </sect1>
   1.263    <sect1>
   1.264      <title>Passare da un altro strumento a Mercurial</title>
   1.265  
   1.266 -    <para id="x_bf">Mercurial viene distribuito con una estensione chiamata <literal role="hg-ext">convert</literal>, che può importare incrementalmente la cronologia di revisione da diversi altri strumenti per il controllo di revisione. Con <quote>incrementale</quote> voglio dire che potete convertire tutta la cronologia di un progetto in un'unica seduta, poi rieseguire la conversione più tardi per ottenere i nuovi cambiamenti che sono successi dopo la conversione iniziale.</para>
   1.267 +    <para id="x_bf">Mercurial viene distribuito con una estensione chiamata <literal role="hg-ext">convert</literal>, che può importare incrementalmente la cronologia delle revisioni da diversi altri strumenti per il controllo di revisione. Con <quote>incrementale</quote> voglio dire che potete convertire tutta la cronologia di un progetto in un'unica seduta, poi rieseguire la conversione più tardi per ottenere i nuovi cambiamenti che sono avvenuti dopo la conversione iniziale.</para>
   1.268  
   1.269      <para id="x_c0">Gli strumenti di controllo di revisione supportati da <literal role="hg-ext">convert</literal> sono i seguenti:</para>
   1.270      <itemizedlist>
   1.271 @@ -250,17 +250,17 @@
   1.272  
   1.273      <para id="x_c8">Walter Tichy sviluppò un'alternativa free a SCCS nei primi anni '80; chiamò il suo programma RCS (acronimo di Revision Control System, sistema per il controllo di revisione). Come SCCS, RCS obbligava gli sviluppatori a lavorare in un singolo spazio di lavoro condiviso, e a bloccare i file per prevenire cambiamenti simultanei da parte di più persone.</para>
   1.274  
   1.275 -    <para id="x_c9">Più tardi negli anni '80, Dick Grune usò RCS come componente di costruzione per un insieme di script shell che chiamò inizialmente cmt, ma che poi rinominò CVS (acronimo di Concurrent Versions System, sistema di versioni concorrenti). La grande innovazione di CVS fu che permetteva agli sviluppatori di lavorare simultaneamente e in qualche modo indipendentemente nel loro spazio di lavoro personale. Gli spazi di lavoro personali evitavano agli sviluppatori di pestarsi i piedi tutte le volte, come capitava comunemente con SCCS e RCS. Ogni sviluppatore aveva la copia di ogni file nel progetto, e poteva modificare le proprie copie indipendentemente. Era necessario combinare le loro modifiche prima di effettuare il commit dei cambiamenti sul repository centrale.</para>
   1.276 -
   1.277 -    <para id="x_ca">Brian Berliner prese gli script originali di Grune e li riscrisse in C, rilasciando nel 1989 il codice che fin da allora è stato sviluppato come la moderna versione di CVS. CVS successivamente acquisì l'abilità di operare attraverso una connessione di rete, che gli conferì la propria architettura client/server. L'architettura di CVS è centralizzata; solo il server ha la copia della cronologia del progetto. Gli spazi di lavoro sui client contengono solamente copie delle versioni recenti dei file del progetto e i metadati che servono per sapere la locazione del server. CVS ha avuto un enorme succeso; probabilmente è il sistema di controllo di revisione più largamente utilizzato al mondo.</para>
   1.278 +    <para id="x_c9">Più tardi negli anni '80, Dick Grune usò RCS come componente di base per un insieme di script shell che chiamò inizialmente cmt, ma che poi rinominò CVS (acronimo di Concurrent Versions System, sistema di versioni concorrenti). La grande innovazione di CVS fu che permetteva agli sviluppatori di lavorare simultaneamente e in qualche modo indipendentemente nel loro spazio di lavoro personale. Gli spazi di lavoro personali evitavano agli sviluppatori di pestarsi i piedi tutte le volte, come capitava comunemente con SCCS e RCS. Ogni sviluppatore aveva la copia di ogni file nel progetto, e poteva modificare le proprie copie indipendentemente. Era necessario combinare le singole modifiche prima di introdurre i cambiamenti nel repository centrale.</para>
   1.279 +
   1.280 +    <para id="x_ca">Brian Berliner prese gli script originali di Grune e li riscrisse in C, rilasciando nel 1989 il codice che fin da allora è stato sviluppato come la moderna versione di CVS. CVS successivamente acquisì l'abilità di operare attraverso una connessione di rete, che gli conferì la propria architettura client/server. L'architettura di CVS è centralizzata; solo il server ha la copia della cronologia del progetto. Gli spazi di lavoro sui client contengono solamente copie delle versioni recenti dei file del progetto e i metadati che servono per conoscere la locazione del server. CVS ha avuto un enorme successo; probabilmente è il sistema di controllo di revisione più largamente utilizzato al mondo.</para>
   1.281  
   1.282      <para id="x_cb">All'inizio degli anni '90, Sun Microsystems sviluppò un primo sistema per il controllo di revisione distribuito chiamato TeamWare. Uno spazio di lavoro in TeamWare contiene una copia completa della cronologia del progetto. TeamWare non possiede alcuna nozione di un repository centrale. (CVS si basava su RCS per lo storage della cronologia; TeamWare usava SCCS.)</para>
   1.283  
   1.284 -    <para id="x_cc">Durante gli anni '90 crebbe la consapevolezza di un certo numero di problemi con CVS. Registra individualmente cambiamenti simultanei a file multipli, invece di raggrupparli insieme come una singola operazione logicamente atomica. Non gestisce bene la sua gerarchia di file; è facile incasinare un repository cambiando i nomi di file e directory. Ancora peggio, il suo codice sorgente è difficile da leggere e da mantenere, il che rese proibitivo il <quote>livello di dolore</quote> nel correggere questi problemi architetturali.</para>
   1.285 +    <para id="x_cc">Durante gli anni '90 crebbe la consapevolezza di un certo numero di problemi con CVS. Registra individualmente cambiamenti simultanei a file multipli, invece di raggrupparli insieme come una singola operazione logicamente atomica. Non gestisce bene la sua gerarchia di file; è facile incasinare un repository cambiando i nomi di file e directory. Ancora peggio, il suo codice sorgente è difficile da leggere e da mantenere, il che rese proibitiva la <quote>soglia di dolore</quote> nel correggere questi problemi architetturali.</para>
   1.286  
   1.287      <para id="x_cd">Nel 2001, Jim Blandy e Karl Fogel, due sviluppatori che avevano lavorato su CVS, diedero vita a un progetto per rimpiazzarlo con uno strumento che avrebbe avuto una migliore architettura e un codice più pulito. Il risultato, Subversion, non si allontana dal modello client/server centralizzato di CVS, ma aggiunge commit atomici per file multipli, una miglior gestione degli spazi di nomi e un certo numero di altre caratteristiche che lo rendono uno strumento generalmente migliore di CVS. Dal suo rilascio iniziale, la sua popolarità è rapidamente cresciuta.</para>
   1.288  
   1.289 -    <para id="x_ce">Più o meno simultaneamente, Graydon Hoare cominciò a lavorarre su un ambizioso sistema di controllo di reversione distribuito che chiamò Monotone. Mentre Monotone risolve molti dei problemi di progettazione di CVS e possiede una architettura peer-to-peer, va oltre ai primi (e ai seguenti) strumenti di controllo di revisione in un certo numero di modi innovativi. Usa hash crittografici come identificatori e ha una nozione integrale di <quote>trust</quote> per il codice che proviene da sorgenti differenti.</para>
   1.290 +    <para id="x_ce">Più o meno simultaneamente, Graydon Hoare cominciò a lavorare su un ambizioso sistema di controllo di reversione distribuito che chiamò Monotone. Mentre Monotone risolve molti dei problemi di progettazione di CVS e possiede un'architettura peer-to-peer, va oltre ai primi (e ai successivi) strumenti di controllo di revisione in un certo numero di modi innovativi. Usa hash crittografici come identificatori e ha una nozione integrale di <quote>trust</quote> per il codice che proviene da sorgenti differenti.</para>
   1.291  
   1.292      <para id="x_cf">Mercurial nacque nel 2005. Mentre alcuni aspetti della sua progettazione sono influenzati da Monotone, Mercurial si concentra su facilità d'uso, prestazioni elevate e scalabilità verso progetti molto grandi.</para>
   1.293    </sect1>