[svnbook commit] r2403 - trunk/src/it/book

bpietro noreply at red-bean.com
Tue Sep 5 11:57:45 CDT 2006


Author: bpietro
Date: Tue Sep  5 11:57:44 2006
New Revision: 2403

Modified:
   trunk/src/it/book/appa.xml
   trunk/src/it/book/appc.xml
   trunk/src/it/book/ch01.xml
   trunk/src/it/book/ch04.xml
   trunk/src/it/book/copyright.xml

Log:
chap 04 all done - need proofread

Modified: trunk/src/it/book/appa.xml
==============================================================================
--- trunk/src/it/book/appa.xml	(original)
+++ trunk/src/it/book/appa.xml	Tue Sep  5 11:57:44 2006
@@ -57,7 +57,7 @@
   <!-- ================================================================= -->
   <sect1 id="svn.forcvs.directories">
     <title>Directory Versions</title>
-    
+
     <para>Subversion tracks tree structures, not just file contents.
       It's one of the biggest reasons Subversion was written to
       replace CVS.</para>
@@ -100,7 +100,7 @@
       that would be a lie too; there may be other changes to
       <filename>foo</filename> we haven't yet received, because we
       haven't updated yet.</para>
-    
+
     <para>Subversion deals with this problem by quietly tracking
       committed adds and deletes in the <filename>.svn</filename>
       area.  When you eventually run <command>svn update</command>,
@@ -110,7 +110,7 @@
       say that you have a <quote>perfect</quote> revision of a
       directory.</emphasis> Most of the time, your working copy will
       contain <quote>imperfect</quote> directory revisions.</para>
-    
+
     <para>Similarly, a problem arises if you attempt to commit
       property changes on a directory.  Normally, the commit would
       bump the working directory's local revision number.  But again,
@@ -142,9 +142,9 @@
       directory, except that it also stores read-only,
       <quote>pristine</quote> copies of your files.  This allows you
       to do many things off-line:</para>
-    
+
     <variablelist>
-      
+
       <varlistentry>
         <term><command>svn status</command></term>
         <listitem>
@@ -342,7 +342,7 @@
 
 
     <warning>
-      <para>Since Subversion treats branches and tags as ordinary
+      <para lang="en">Since Subversion treats branches and tags as ordinary
         directories, always remember to check out the
         <literal>trunk</literal>
         (<literal>http://svn.example.com/repos/calc/trunk/</literal>)
@@ -354,6 +354,16 @@
         have.<footnote><para>That is, providing you don't run out of
         disk space before your checkout
         finishes.</para></footnote></para>
+    <para>Perché in Subversion rami e targhe sono cartelle ordinarie,
+        ricordati sempre di tirar fuori (check out) il
+        <literal>tronco</literal>
+        (<literal>http://svn.example.com/repos/calc/trunk/</literal>)
+        del tuo progetto, e non progetto stesso
+        (<literal>http://svn.example.com/repos/calc/</literal>).
+        Se fai errore di tirar fuori intero progetto, finirai con
+        la copia di lavoro contenente oltre tronco anche ogni ramo e targa.
+        <footnote><para>Proprio così, ma solo se prima di finire checkout
+            non si esaurisce lo spazio sul tuo disco fisso.</para></footnote></para>
     </warning>
 
   </sect1>
@@ -370,7 +380,7 @@
       directories.  Properties are arbitrary name/value pairs
       associated with files and directories in your working
       copy.</para>
-    
+
     <para>To set or get a property name, use the <command>svn
       propset</command> and <command>svn propget</command>
       subcommands.  To list all properties on an object, use
@@ -415,7 +425,7 @@
       binary-differencing algorithm, regardless of whether they
       contain textual or binary data.  That means that all files are
       stored differentially (compressed) in the repository.</para>
-    
+
     <para>CVS users have to mark binary files with
       <option>-kb</option> flags, to prevent data from being garbled
       (due to keyword expansion and line-ending translations).  They
@@ -546,7 +556,7 @@
 </appendix>
 
 <!--
-local variables: 
+local variables:
 sgml-parent-document: ("book.xml" "appendix")
 end:
 -->

Modified: trunk/src/it/book/appc.xml
==============================================================================
--- trunk/src/it/book/appc.xml	(original)
+++ trunk/src/it/book/appc.xml	Tue Sep  5 11:57:44 2006
@@ -1,9 +1,10 @@
 <appendix id="svn.3rdparty">
-  <title>Third Party Tools</title>
+  <!-- <title>Third Party Tools</title> -->
+  <title>Strumenti dai terzi</title>
 
   <simplesect>
 
-    <para>Subversion's modular design (covered in <xref
+    <para lang="en">Subversion's modular design (covered in <xref
       linkend="svn.developer.layerlib"/>) and the availability of
       language bindings (as described in <xref
       linkend="svn.developer.usingapi.otherlangs"/>) make it a likely
@@ -13,12 +14,22 @@
       Subversion website (<ulink
         url="http://subversion.tigris.org/project_links.html"/>).</para>
 
+    <para>Il design modulare di Subversion (coperto in <xref
+      linkend="svn.developer.layerlib"/>) e disponibilità di
+      binding per vari linguaggi di programmazione (come descritto in <xref
+      linkend="svn.developer.usingapi.otherlangs"/>) fanno di lui probabile
+      candidato per uso come una estensione o backend per altri programmi.
+      Per la lista di molti strumenti da terzi che usano le funzionalità di
+      Subversion dietro le quinte, controllate la pagina di likn sul sito web di
+      Subversion (<ulink
+      url="http://subversion.tigris.org/project_links.html"/>).</para>
+
   </simplesect>
 
 </appendix>
 
 <!--
-local variables: 
+local variables:
 sgml-parent-document: ("book.xml" "appendix")
 end:
 -->

Modified: trunk/src/it/book/ch01.xml
==============================================================================
--- trunk/src/it/book/ch01.xml	(original)
+++ trunk/src/it/book/ch01.xml	Tue Sep  5 11:57:44 2006
@@ -20,14 +20,14 @@
       per poi cancellare i cambiamenti il giorno seguente. Ma l'utilità
       di un software di versionamento si estende ben fuori dai limiti
       del mondo dello sviluppo software. Ovunque è possibile incontrare
-      persone che utilizzano il computer per gestire informazioni che 
+      persone che utilizzano il computer per gestire informazioni che
       cambiano di frequente, lì trova spazio il controllo di versione.
       E qui entra in gioco Subversion.</para>
 
     <para lang="en">This chapter contains a high-level introduction to
       Subversion—what it is; what it does; how to get it.</para>
 
-    <para>Questo capitolo contiene un'introduzione di alto livello a 
+    <para>Questo capitolo contiene un'introduzione di alto livello a
       Subversion—cos'è; cosa fa; come ottenerlo.</para>
 
   </simplesect>
@@ -39,7 +39,7 @@
   <sect1 id="svn.intro.whatis">
 
     <title>Cos'è Subversion?</title>
-      
+
     <para lang="en">Subversion is a free/open-source version control system.
       That is, Subversion manages files and directories over time.  A
       tree of files is placed into a central
@@ -58,10 +58,10 @@
       ad un file server, in più esso ricorda qualsiasi cambiamento
       fatto ai files e alle directories. Ciò permette di ripristinare
       vecchie versioni o esaminare lo storico dei cambiamenti dei dati.
-      Per questo motivo, molte persone pensano che un sistema di 
+      Per questo motivo, molte persone pensano che un sistema di
       versionamento assomigli ad una sorta di <quote>macchina del
       tempo</quote>.</para>
-    
+
     <para lang="en">Subversion can access its repository across networks, which
       allows it to be used by people on different computers.  At some
       level, the ability for various people to modify and manage the
@@ -78,13 +78,19 @@
       la possibilità per più persone di modificare e gestire lo
 nebiac
       la possibilità per più persone di modificare e maneggiare lo
-      stesso elenco di dati, ognuno dalle rispettive postazioni, 
+      stesso elenco di dati,
+[bpietro-
+      la possibilità per più persone di modificare e gestire lo
+      stesso insieme di dati]
+      ognuno dalle rispettive postazioni,
       alimenta la collaborazione. Miglioramenti possono intervenire
       più velocemente se non tutte le modifiche devono per forza
       passare per un unico canale. E dato che il lavoro è sotto controllo,
-      di versione non c'è da temere che la qualità sia il prezzo da 
-      pagare—se vengono applicate alla data alcune modifiche 
-      non corrette, basta annullare tali cambiamenti.</para>
+      di versione non c'è da temere che la qualità sia il prezzo da
+      pagare—se vengono applicate alla data
+[bpietro-
+      ai dati]
+      alcune modifiche non corrette, basta annullare tali cambiamenti.</para>
 
     <para lang="en">Some version control systems are also software configuration
       management (SCM) systems.  These systems are specifically
@@ -99,20 +105,21 @@
       beyond.</para>
 
     <para>Alcuni sistemi per il controllo di versione sono anche
-      sistemi 'software configuration management' (SCM). Questi 
+      sistemi 'software configuration management' (SCM). Questi
 nebiac
-      sistemi di software configuration management (SCM). Questi 
-      sistemi sono orientati specificatamente alla gestione di 
+      sistemi di software configuration management (SCM). Questi
+      sistemi sono orientati specificatamente alla gestione di
 nebiac
-      sistemi sono tagliati specificatamente alla gestione di 
+      sistemi sono tagliati specificatamente alla gestione di
       alberature di codice sorgente, e hanno molte caratteristiche
       che sono specifiche allo sviluppo software—come
       comprendere nativamente i linguaggi di programmazione o
       integrare strumenti per la compilazione del software.
-      Subversion, tuttavia, non è uno di questi sistemi. E' un 
-      sistema generale che può essere utilizzato per gestire 
+      Subversion, tuttavia, non è uno di questi sistemi. E' un
+      sistema generale
+[bpietro- sistema generico] che può essere utilizzato per gestire
       <emphasis>qualsiasi</emphasis> insieme di files. Per qualcuno
-      questi files possono contenere codice sorgente—per 
+      questi files possono contenere codice sorgente—per
       altri qualunque cosa, dalla lista della spesa a montaggi video
       digitali, e così via.</para>
 
@@ -147,7 +154,7 @@
 
     <para>All'inizio del 2000, CollabNet,
       Inc. (<ulink url="http://www.collab.net"/>) iniziò a cercare
-      sviluppatori per scrivere un software che sostituisse CVS. 
+      sviluppatori per scrivere un software che sostituisse CVS.
       CollabNet offre una suite di software collaborativi chiamata
       CollabNet Enterprise Edition (CEE)
       <footnote>
@@ -155,18 +162,18 @@
         Edition (CTE) pensata per gruppi più piccoli.</para>
       </footnote>
       di cui un componente è il controllo di versione. Sebbene
-      CEE usasse proprio CVS come suo  sistema di 
+      CEE usasse proprio CVS come suo  sistema di
       versionamento iniziale, fin dall'inizio fu chiaro che tale software
 nebiac (2 righe)
-      CEE usasse proprio CVS come suo iniziale sistema di 
+      CEE usasse proprio CVS come suo iniziale sistema di
       versionamento, fin dall'inizio fu chiaro che tale software
-      portava con se alcune limitazioni e CollabNet capì che 
+      portava con se alcune limitazioni e CollabNet capì che
       avrebbe dovuto trovare qualcosa di meglio.
-      Sfortunatamente, CVS nel frattempo era ampiamente diventato 
+      Sfortunatamente, CVS nel frattempo era ampiamente diventato
       lo standard <foreignphrase>de facto</foreignphrase> nel
       mondo dell'open source, poichè non c'è nulla di meglio, per
       lo meno non sotto una licenza free. Così CollabNet decise di
-      di scrivere da zero un nuovo sistema per il controllo di 
+      di scrivere da zero un nuovo sistema per il controllo di
       versione, mantenendo l'idea base di CVS, evitando i suoi bugs
       e aggiungendo features.</para>
 
@@ -195,18 +202,18 @@
       frustrating experiences with CVS, and welcomed the chance to
       finally do something about it.</para>
 
-    <para>Nel febbraio del 2000, fu contattato Karl Fogel, l'autore 
+    <para>Nel febbraio del 2000, fu contattato Karl Fogel, l'autore
       del libro <citetitle>Sviluppare Open Source con CVS</citetitle>
       (Coriolis, 1999), al quale fu chiesto se avesse avuto piacere
-      di lavorare su questo nuovo progetto. Coincidenza volle che, 
+      di lavorare su questo nuovo progetto. Coincidenza volle che,
       in quel periodo, Karl, stava già lavorando a un progetto per
       un nuovo sistema di versionamento con il suo amico Jim Blandy.
-      Nel 1995, i due avevano fondato la Cyclic Software, una 
+      Nel 1995, i due avevano fondato la Cyclic Software, una
       compagnia che si occupava di stipulare contratti di supporto
-      all'utilizzo di CVS, e sebbene più tardi essi cedettero la 
-      loro attività, continuarono ancora ad utilizzare, per lavoro, 
+      all'utilizzo di CVS, e sebbene più tardi essi cedettero la
+      loro attività, continuarono ancora ad utilizzare, per lavoro,
       CVS ogni giorno. La loro frustrazione con CVS, condusse Jim a
-      pensare seriamente ad un modo migliore per gestire dati 
+      pensare seriamente ad un modo migliore per gestire dati
       versionati; egli aveva già non solo ideato il nome
       <quote>Subversion</quote>, ma anche la concezione base del
       repository. Quando CollabNet li contattò, Karl accettò
@@ -215,13 +222,13 @@
       potersi dedicare al progetto a tempo indeterminato. CollabNet assunse
       Karl e Ben Collins-Sussman e il lavoro vero e proprio sul
       progetto inizio nel mese di maggio. Con l'aiuto di alcuni
-      ben piazzati sostenitori, da Brian Behlendorf e Jason Robbins 
+      ben piazzati sostenitori, da Brian Behlendorf e Jason Robbins
       of CollabNet, a Greg Stein (al tempo sviluppatore indipendente
       attivo nel processo di specifica di WebDAV/DeltaV), Subversion
       in breve tempo attrasse intorno a se una gruppo di attivi
-      sviluppatori. Ciò dimostrava che molte persone avevano le 
-      stesse frustranti esperienze con CVS, e accolsero con 
-      entusiasmo la possibilità di fare finalmente qualcosa per 
+      sviluppatori. Ciò dimostrava che molte persone avevano le
+      stesse frustranti esperienze con CVS, e accolsero con
+      entusiasmo la possibilità di fare finalmente qualcosa per
       migliorarlo.</para>
 
     <para lang="en">The original design team settled on some simple goals.  They
@@ -233,7 +240,7 @@
       similar enough that any CVS user could make the switch with
       little effort.</para>
 
-    <para>Il team di sviluppo originario si concentrò su alcuni 
+    <para>Il team di sviluppo originario si concentrò su alcuni
       semplici obiettivi. Essi non volevano introdurre un nuovo
       approccio nella metodologia del controllo di versione, essi
       volevano solamente migliorare CVS. Decisero che Subversion
@@ -242,7 +249,7 @@
       sue più ovvie debolezze. E sebbene il loro software non avesse
       bisogno di presentarsi come una copia di CVS, sarebbe comunque
       dovuto essere abbastanza simile per permettere che qualsiasi
-      utente di CVS, potesse cambiare e utilizzare Subversion con 
+      utente di CVS, potesse cambiare e utilizzare Subversion con
       pochissima fatica.</para>
 
     <para lang="en">After fourteen months of coding, Subversion became
@@ -250,14 +257,14 @@
       Subversion developers stopped using CVS to manage Subversion's
       own source code, and started using Subversion instead.</para>
 
-    <para>Dopo quattordici mesi passati a scrivere codice, 
+    <para>Dopo quattordici mesi passati a scrivere codice,
       Subversion divenne <quote>autogestente (self-hosted)</quote> il 31 agosto 2001.
 nebiac
       Subversion divenne <quote>self-hosted</quote> il 31 agosto 2001.
-      Da quel momento, cioè, gli sviluppatori smisero di utilizzare 
-      CVS per gestire il codice di Subversion e iniziarono ad 
+      Da quel momento, cioè, gli sviluppatori smisero di utilizzare
+      CVS per gestire il codice di Subversion e iniziarono ad
       utilizzare Subversion stesso.</para>
- 
+
     <para lang="en">While CollabNet started the project, and still funds a large
       chunk of the work (it pays the salaries of a few full-time
       Subversion developers), Subversion is run like most open-source
@@ -270,15 +277,15 @@
 
     <para>Mentre CollabNet iniziava il progetto e tuttora finanzia la
       maggior parte del lavoro (paga lo stipendio di un piccolo gruppo
-      di sviluppatori che lavorano su Subversion a tempo pieno), Subversion 
-      viene portato avanti come la maggior parte dei progetti open-source, 
-      gestito attraverso un insieme di regole aperto e trasparente  che 
+      di sviluppatori che lavorano su Subversion a tempo pieno), Subversion
+      viene portato avanti come la maggior parte dei progetti open-source,
+      gestito attraverso un insieme di regole aperto e trasparente  che
 nebiac
-      gestito attraverso un aperto e trasparente insieme di regole che 
+      gestito attraverso un aperto e trasparente insieme di regole che
       incoraggiano la meritocrazia. La licenza di copyright di CollabNet
       rispetta pienamente le linee guida Debian Free Software. In altre
-      parole, chiunque è libero di scaricare, modificare e redistribuire 
-      Subversion come preferisce; senza richiedere alcun permesso da 
+      parole, chiunque è libero di scaricare, modificare e redistribuire
+      Subversion come preferisce; senza richiedere alcun permesso da
       CollabNet o chiunque altro.</para>
 
   </sect1>
@@ -299,13 +306,13 @@
       linkend="svn.basic"/>, in which we provide a gentle introduction
       to version control in general.</para>
 
-    <para>Discutere delle caratteristiche che Subversion porta 
+    <para>Discutere delle caratteristiche che Subversion porta
       al tavolo del controllo di versione, è spesso utile approfondire
       in che modo tali peculiarità apportino miglioramenti alla struttura
-      di CVS. Se non si ha familiarità con CVS, si rischia di non 
-      comprenderne a dovere l'efficacia. Se, poi, il lettore non ha 
+      di CVS. Se non si ha familiarità con CVS, si rischia di non
+      comprenderne a dovere l'efficacia. Se, poi, il lettore non ha
       dimestichezza con il controllo di versione in generale, i suoi occhi
-      potrebbero coprirsi di una patina a meno che non si legga prima 
+      potrebbero coprirsi di una patina a meno che non si legga prima
       <xref linkend="svn.basic"/>, nel quale viene fornita una precisa
       introduzione al generale concetto di versionamento.</para>
 
@@ -323,7 +330,7 @@
             versioned.</para>
 
           <para>Solo CVS traccia la storia dei soli files, mentre
-            Subversion implementa il versionamento di un filesystem 
+            Subversion implementa il versionamento di un filesystem
             <quote>virtuale</quote> che traccia i cambiamenti nel tempo
             degli interi alberi directory. I files <emphasis>e</emphasis> le
             directories vengono quindi versionati.</para>
@@ -344,9 +351,9 @@
             delete, copy, and rename both files and directories.  And
             every newly added file begins with a fresh, clean
             history all its own.</para>
-          
-          <para>Dal momento che CVS è limitato al versionamento dei 
-            soli files, operazioni come copia e rinomina—che 
+
+          <para>Dal momento che CVS è limitato al versionamento dei
+            soli files, operazioni come copia e rinomina—che
             dovrebbero essere propri dei files, ma che poi non sono
             altro che modifiche ai contenuti di ciò che contiene una
             directory—non sono supportate in CVS.
@@ -369,17 +376,17 @@
             chunks, and prevents problems that can occur when only a
             portion of a set of changes is successfully sent to the
             repository.</para>
-         
-  	  <para>Un insieme di modifiche o vengono inserite nel repository
-  	    tutte insieme o non ne viene inserita nessuna. Ciò permette agli 
-  	    sviluppatori di costruire ed effettuare commit di cambiamenti come 
+
+          <para>Un insieme di modifiche o vengono inserite nel repository
+            tutte insieme o non ne viene inserita nessuna. Ciò permette agli
+            sviluppatori di costruire ed effettuare commit di cambiamenti come
 nebiac
-  	    sviluppatori di costruire e committare i cambiamenti come 
- 	    un blocco logico unico, prevenendo problemi che possono 
- 	    occorrere quando solo una parte d'un insieme di modifiche 
+            sviluppatori di costruire e committare i cambiamenti come
+            un blocco logico unico, prevenendo problemi che possono
+            occorrere quando solo una parte d'un insieme di modifiche
 nebiac
- 	    occorrere quando solo una parte di un set di modifiche 
- 	    vengono inviate con successo al repository.</para>
+            occorrere quando solo una parte di un set di modifiche
+            vengono inviate con successo al repository.</para>
         </listitem>
       </varlistentry>
 
@@ -392,13 +399,13 @@
             pairs you wish.  Properties are versioned over time, just
             like file contents.</para>
 
-	  <para>
-	  Ogni file e directory ha un set di proprietà—chiavi
-	    e rispettivi valori—associati ad esso. L'utilizzatore
-	    può creare e memorizzare qualsiasi coppia di chiave/valore 
-	    che preferisce, arbitrariamente. Le proprietà sono
-	    soggette a versionamento esattamente come il file a cui sono
-	    associate.</para>
+          <para>
+          Ogni file e directory ha un set di proprietà—chiavi
+            e rispettivi valori—associati ad esso. L'utilizzatore
+            può creare e memorizzare qualsiasi coppia di chiave/valore
+            che preferisce, arbitrariamente. Le proprietà sono
+            soggette a versionamento esattamente come il file a cui sono
+            associate.</para>
         </listitem>
       </varlistentry>
 
@@ -417,18 +424,18 @@
             speaks a custom protocol which can be easily tunneled over
             SSH.</para>
 
-	  <para>Subversion ha una nozione astratta di accesso al
-	    repository, che rende semplice per chiunque implementare 
-	    nuovi meccanismi di rete. Inoltre è possibile 
-	    integrarlo con Apache HTTP Server, come modulo di
-	    estensione. Ciò conferisce a Subversion un grande 
-	    vantaggio in stabilità e interoperabilità, oltrechè un
-	    accesso istantaneo alle caratteristiche che tale webserver
-	    mette a disposizione—autenticazione, autorizzazione,
-	    wire compression, e così via. E' tuttavia disponibile 
+          <para>Subversion ha una nozione astratta di accesso al
+            repository, che rende semplice per chiunque implementare
+            nuovi meccanismi di rete. Inoltre è possibile
+            integrarlo con Apache HTTP Server, come modulo di
+            estensione. Ciò conferisce a Subversion un grande
+            vantaggio in stabilità e interoperabilità, oltrechè un
+            accesso istantaneo alle caratteristiche che tale webserver
+            mette a disposizione—autenticazione, autorizzazione,
+            wire compression, e così via. E' tuttavia disponibile
             anche un processo server standalone proprio di Subversion
-	    più leggero. Questo server è progettato su un protocollo 
-	    proprio che può essere facilmente veicolato su SSH.</para>
+            più leggero. Questo server è progettato su un protocollo
+            proprio che può essere facilmente veicolato su SSH.</para>
         </listitem>
       </varlistentry>
 
@@ -443,13 +450,13 @@
             repository, and differences are transmitted in both
             directions across the network.</para>
 
-	  <para>Subversion esprime le differenze di un file usando 
-	    un algoritmo di differenziazione binario, che lavora
-	    ugualmente sia sui files di testo (leggibili dall'uomo) 
-	    che sui files binari (illeggibili dall'uomo). Entrambi
-	    i tipi di files sono memorizzati ugualmente compressi
-	    nel repository e le differenze sono trasmesse in 
-	    entrambi i casi attraverso la rete.</para>
+          <para>Subversion esprime le differenze di un file usando
+            un algoritmo di differenziazione binario, che lavora
+            ugualmente sia sui files di testo (leggibili dall'uomo)
+            che sui files binari (illeggibili dall'uomo). Entrambi
+            i tipi di files sono memorizzati ugualmente compressi
+            nel repository e le differenze sono trasmesse in
+            entrambi i casi attraverso la rete.</para>
         </listitem>
       </varlistentry>
 
@@ -463,21 +470,21 @@
             take only a very small, constant amount of time.
           </para>
 
-	  <para>Il costo in termini di tempo e spazio dedicato al 
+          <para>Il costo in termini di tempo e spazio dedicato al
 nebiac: direi di non mettere le doppie virgolette, cosa dici?
-	   Il "costo" in termini di tempo e spazio dedicato al 
-	    branching e al tagging non deve essere proporzionale 
-	    alla grandezza del progetto. Subversion crea branches e 
-  	    tags utilizzando un meccanismo simile all'hard-link unix 
-	    (collegamento) per copiare il progetto. In questo modo, 
-	    tali operazioni occupano solo una quantità di tempo 
-	    molto piccolo e costante.
+           Il "costo" in termini di tempo e spazio dedicato al
+            branching e al tagging non deve essere proporzionale
+            alla grandezza del progetto. Subversion crea branches e
+            tags utilizzando un meccanismo simile all'hard-link unix
+            (collegamento) per copiare il progetto. In questo modo,
+            tali operazioni occupano solo una quantità di tempo
+            molto piccolo e costante.
 nebiac
-	    molto breve e costante.
-	    </para>
+            molto breve e costante.
+            </para>
         </listitem>
       </varlistentry>
-      
+
       <varlistentry>
         <term>Versatilità</term>
         <listitem>
@@ -487,11 +494,11 @@
             maintainable and usable by other applications and
             languages.</para>
 
-	  <para>Subversion non ha alcun bagaglio storico; esso è 
-	    implementato come una collezione di librerie C condivise
-	    con delle APIs ben definite. Ciò lo rende estremamente 
-	    manutenibile e usabile da altre applicazioni e in 
-	    altre lingue.</para>
+          <para>Subversion non ha alcun bagaglio storico; esso è
+            implementato come una collezione di librerie C condivise
+            con delle APIs ben definite. Ciò lo rende estremamente
+            manutenibile e usabile da altre applicazioni e in
+            altre lingue.</para>
         </listitem>
       </varlistentry>
 
@@ -508,7 +515,7 @@
 
     <para><xref linkend="svn.intro.architecture.dia-1"/>  illustra ciò che si può chiamare
       una vista <quote>dall'altezza di un miglio</quote> dell'architettura di Subversion.</para>
-    
+
     <figure id="svn.intro.architecture.dia-1">
       <title>Architettura di Subversion</title>
       <graphic fileref="images/ch01dia1.png"/>
@@ -525,15 +532,15 @@
           repository.  Others bypass the network altogether and access the
       repository directly.
     </para>
-    
+
     <para>
-    Ad un estremo c'è il repository Subversion che contiene tutti i vostri dati 
-    sotto controllo di versione. All'altro estremo c'è il vostro client Subversion, 
-    che gestisce le specchiature locali di parte dei dati sotto controllo 
-    di versione (chiamate  <quote>copie locali</quote>). 
-    Tra questi estremi vi sono diversi percorsi tramite vari strati per l'Accesso al Repository 
-    (AR). Alcune di queste strade attraversano reti di computer e reti di server che che a loro volta 
-    accedono il repository.  
+    Ad un estremo c'è il repository Subversion che contiene tutti i vostri dati
+    sotto controllo di versione. All'altro estremo c'è il vostro client Subversion,
+    che gestisce le specchiature locali di parte dei dati sotto controllo
+    di versione (chiamate  <quote>copie locali</quote>).
+    Tra questi estremi vi sono diversi percorsi tramite vari strati per l'Accesso al Repository
+    (AR). Alcune di queste strade attraversano reti di computer e reti di server che che a loro volta
+    accedono il repository.
     Altre scavalcano del tutto la rete ed accedono direttamente il repository.
     </para>
 
@@ -560,14 +567,14 @@
       the Apache httpd server runs on: Windows, Linux, all flavors of
       BSD, Mac OS X, Netware, and others.
       </para>
-     
+
     <para>
       Subversion è costruito su uno strato portabile chiamato APR—
       la libreria Apache Portable Runtime. La libreria APR fornisce tutte le interfaccie
-      per le funzioni richieste da Subversion per funzionare su diversi sistemi operativi: 
+      per le funzioni richieste da Subversion per funzionare su diversi sistemi operativi:
       l'accesso al disco, alla rete, la gestione della memoria e così via.
-      Anche se Subversion è in grado di utilizzare Apache come uno dei possibili componenti lato server, 
-      la sua dipendenza da APR <emphasis>non</emphasis> significa che Apache sia un 
+      Anche se Subversion è in grado di utilizzare Apache come uno dei possibili componenti lato server,
+      la sua dipendenza da APR <emphasis>non</emphasis> significa che Apache sia un
       componente rihiesto per funzionare. Significa, comunque, che come Apache, i client
       ed i server di Subversion funzionano su ogni sistema operativo sul quale gira il server httpd Apache:
       Windows, Linux, tutte le varianti di BSD, MAc OS X, Netware ed altri.
@@ -595,7 +602,7 @@
       Se siete utenti di un sistema operativo di tipo Unix, per ottenere Subversion potete utilizzare
       i sistemi di distribuzione nativi per il vostro sistema (RPMs. DEBs, ports tree, etc.).
      </para>
-     
+
      <para lang="en">
     Alternately, you can build Subversion directly from source
       code.  From the Subversion website, download the latest
@@ -615,19 +622,19 @@
       </para>
 
     <para>
-	Come alternativa, si può costruire Subversion direttamente dai codici sorgenti.
-	Scaricate l'ultima release del codice sorgente dal sito web di Subversion.
-	Dopo averlo spacchettato, seguite le istruzioni contenute nel file 
-	<filename>INSTALL</filename> per costruirlo.
-	Da notare che un pacchetto di sorgenti rilasciato, contiene tutto ciò di 
-	cui si necessiti per costruire un client a linea di comando in grado di parlare con
-	un repository remoto (in particolare, apr, apr-util, e le librerie neon).
-	Ma parti opzionali di Subversion hanno molte altre dipendenze, come il DB Berkeley ed anche
-	Apace httpd. 
-	Se volete realizzare una costruzione completa, siate sicuri di avere tutti i pacchetti 
-	descritti nel file <filename>INSTALL</filename>.
-	Se avete intenzione di lavorare su Subversion stesso, potete utilizzare il client
-	per ottenere l'ultima copia dei sorgenti allineata con la frontiera degli sviluppi.
+        Come alternativa, si può costruire Subversion direttamente dai codici sorgenti.
+        Scaricate l'ultima release del codice sorgente dal sito web di Subversion.
+        Dopo averlo spacchettato, seguite le istruzioni contenute nel file
+        <filename>INSTALL</filename> per costruirlo.
+        Da notare che un pacchetto di sorgenti rilasciato, contiene tutto ciò di
+        cui si necessiti per costruire un client a linea di comando in grado di parlare con
+        un repository remoto (in particolare, apr, apr-util, e le librerie neon).
+        Ma parti opzionali di Subversion hanno molte altre dipendenze, come il DB Berkeley ed anche
+        Apace httpd.
+        Se volete realizzare una costruzione completa, siate sicuri di avere tutti i pacchetti
+        descritti nel file <filename>INSTALL</filename>.
+        Se avete intenzione di lavorare su Subversion stesso, potete utilizzare il client
+        per ottenere l'ultima copia dei sorgenti allineata con la frontiera degli sviluppi.
       Ciò è documentato in <xref
       linkend="svn.developer.contrib.get-code"/>.
       </para>
@@ -640,8 +647,8 @@
   <sect1 id="svn.intro.components">
 
     <title>I Componenti di Subversion</title>
-    
-    <para lang="en"> 
+
+    <para lang="en">
       Subversion, once installed, has a number of different
       pieces.  The following is a quick overview of what you get.
       Don't be alarmed if the brief descriptions leave you scratching
@@ -649,11 +656,11 @@
       in this book devoted to alleviating that confusion.
      </para>
 
-    <para lang="en"> 
+    <para lang="en">
     Subversion, una volta installato,  possiede un certo numero di differenti
     pezzi. Segue un veloce riferimento al riguardo.
     Non allarmatevi se le brevi descrizioni vi lasciano dei grattacapi—
-    in questo libro ci sono <emphasis>molte</emphasis> altre pagine 
+    in questo libro ci sono <emphasis>molte</emphasis> altre pagine
     dedicate ad alleviare la vostra confusione.
     </para>
 
@@ -672,8 +679,8 @@
         <listitem>
           <para lang="en">A program for reporting the state (in terms of
             revisions of the items present) of a working copy.</para>
-	    
-          <para>Un programma per conoscere lo stato (in termini di 
+
+          <para>Un programma per conoscere lo stato (in termini di
             revisione degli elementi presenti) di una copia di lavoro.</para>
         </listitem>
       </varlistentry>
@@ -682,7 +689,7 @@
         <term>svnlook</term>
         <listitem>
           <para lang="en">A tool for inspecting a Subversion repository.</para>
-	  
+
           <para>Un tool per ispezionare una repository Subversion.</para>
         </listitem>
       </varlistentry>
@@ -691,7 +698,7 @@
         <term>svnadmin</term>
         <listitem>
           <para lang="en">A tool for creating, tweaking or repairing a Subversion </para>
-	  
+
           <para>Un tool per creare, operare e riparare una repository Subversion.</para>
         </listitem>
       </varlistentry>
@@ -711,8 +718,8 @@
           <para lang="en">A plug-in module for the Apache HTTP Server, used to
             make your repository available to others over a
             network.</para>
-	    
-          <para>Un modulo plug-in per il Server Apache HTTP, usato per rendere disponibile ad altri la 
+
+          <para>Un modulo plug-in per il Server Apache HTTP, usato per rendere disponibile ad altri la
             vostra repository via rete.</para>
         </listitem>
       </varlistentry>
@@ -724,7 +731,7 @@
             daemon process or invokable by SSH; another way to make
             your repository available to others over a network.</para>
 
-          <para >Un programma server specializzato per essere eseguito come un processo demone 
+          <para >Un programma server specializzato per essere eseguito come un processo demone
           oppure essere invocato tramite SSH; un altro modo per rendere accessibile via rete
           ad altri il vostro repository.</para>
         </listitem>
@@ -733,9 +740,9 @@
 
     <para lang="en">Assuming you have Subversion installed correctly, you should
       be ready to start.  The next two chapters will walk you through
-      the use of <command>svn</command>, Subversion's command-line client 
+      the use of <command>svn</command>, Subversion's command-line client
       program.</para>
-      
+
     <para>Assumendo di avere Subversion correttamente installato, dovreste essere pronti a partire.
     I prossimi due capitoli vi condurranno attraverso l'uso di <command>svn</command> il client command line
     di Subversion.
@@ -749,7 +756,7 @@
   <sect1 id="svn.intro.quickstart">
 
     <title>Un rapido inizio</title>
-    
+
     <para lang="en">Some people have trouble absorbing a new technology by
       reading the sort of <quote>top down</quote> approach provided by
       this book.  This section is a very short introduction to
@@ -759,13 +766,13 @@
       running.  Along the way, we give links to the relevant chapters
       of this book.</para>
 
-	<para>Alcune persone hanno dei problemi ad assorbire una nuova tecnologia 
-	tramite l'approccio <quote>top down</quote> di questo libro.  
-	Questa sezione è un'introduzione a Subversion molto sintetica, ed è pensata per
-	fornire una possibilità  in più a chi è abituato ad imparare con un approccio <quote>bottom up</quote>.
-	Se si preferisce imparare sperimentando, gli esempi seguenti vi permetteranno di essere
-	subito operativi.
-	Strada facendo, saranno evidenziati i collegamenti ai capitoli più importanti di questo libro.
+        <para>Alcune persone hanno dei problemi ad assorbire una nuova tecnologia
+        tramite l'approccio <quote>top down</quote> di questo libro.
+        Questa sezione è un'introduzione a Subversion molto sintetica, ed è pensata per
+        fornire una possibilità  in più a chi è abituato ad imparare con un approccio <quote>bottom up</quote>.
+        Se si preferisce imparare sperimentando, gli esempi seguenti vi permetteranno di essere
+        subito operativi.
+        Strada facendo, saranno evidenziati i collegamenti ai capitoli più importanti di questo libro.
         </para>
 
 
@@ -775,7 +782,7 @@
       before going any further.</para>
 
     <para>Se per voi sono nuovi sia l'insieme dei concetti di controllo di versione, sia il modello
-         <quote>copia-modifica-fusione (copy-modify-merge)</quote> usato sia da CVS che da Subversion, 
+         <quote>copia-modifica-fusione (copy-modify-merge)</quote> usato sia da CVS che da Subversion,
          allora dovreste leggere <xref linkend="svn.basic"/>
       prima di andare avanti.</para>
 
@@ -788,7 +795,7 @@
         later (run <command>svn --version</command> to check.)</para>
 
       <para>Il seguente esempio assume di avere  pronti all'uso <command>svn</command>, il client a linea di comando di Subversion,
-        e <command>svnadmin</command>, il tool di amministrazione.  
+        e <command>svnadmin</command>, il tool di amministrazione.
         Si assume anche che stiate usando Subversion 1.2 o successivo
         (usare il comando <command>svn --version</command> per controllare.)</para>
     </note>
@@ -796,7 +803,7 @@
     <para lang="en">Subversion stores all versioned data in a central
       repository.  To begin, create a new repository:</para>
 
-    <para>Subversion memorizza tutti i dati sotto controllo di versione in un repository centrale. 
+    <para>Subversion memorizza tutti i dati sotto controllo di versione in un repository centrale.
     Per iniziare, creiamo un nuovo repoitory:</para>
 
     <screen>
@@ -835,7 +842,7 @@
       ever talking about some directory (or collection of directories)
       in the repository.</para>
 
-    <para>Subversion non ha il concetto di <quote>progetto</quote>.  
+    <para>Subversion non ha il concetto di <quote>progetto</quote>.
     Il repository è solo un filesystem virtuale versionato, un albero di directory molto vasto
     che può conservare ciò che si desidera. Alcuni sistemisti preferiscono memorizzare
     solo un progetto per repository alti memorizzano più progetti in un repository
@@ -843,12 +850,12 @@
     I pregi di ogni approcci sono discussi in  <xref linkend="svn.reposadmin.projects.chooselayout"/>.
     Ad ogni modo il repository gestisce solo file e directory,
     in tal senso è copito degli umani interpretare le particolari directory,
-    come <quote>projects</quote>.  
+    come <quote>projects</quote>.
     Per questo ogni qual volta in questo libro venga fatto riferimento ai progetti,
     si tenga presente che è come se si parlasse di directory (od insiemi di directories) nel
     repository.</para>
 
-	
+
     <para lang="en"> In this example, we assume that you already have some sort
       of project (a collection of files and directories) that you wish
       to import into your newly created Subversion repository.  Begin
@@ -867,9 +874,9 @@
     <para> In questo esempio,  si assume di avere una qualche sorta di progetto
     (un insieme di files e directories) che vorreste importare in un repository
     appena creato.
-    Iniziamo organizzandoli in una sola directory chiamata <filename>myproject</filename> 
+    Iniziamo organizzandoli in una sola directory chiamata <filename>myproject</filename>
     (oppure un qualunque altro nome vi piaccia).
-    Per ragioni che saranno chiare tra poco (vedi <xref linkend="svn.branchmerge"/>), 
+    Per ragioni che saranno chiare tra poco (vedi <xref linkend="svn.branchmerge"/>),
     l'alberatura del vostro progetto dovrà  contenere tre directory di livello piu' alto
     chiamate <filename>branches</filename>,
       <filename>tags</filename>, and
@@ -903,7 +910,7 @@
       (see <xref linkend="svn.tour.other.import"/>):</para>
 
       <para>Non appena la vostra struttura di directory è pronta, importatela in una
-        repository svn con il comando <command>svn import</command> 
+        repository svn con il comando <command>svn import</command>
       (see <xref linkend="svn.tour.other.import"/>):</para>
 <screen>
 $ svn import /tmp/myproject file:///path/to/repos/myproject -m "initial import"
@@ -915,7 +922,7 @@
 Adding         /tmp/myproject/trunk/Makefile
 …
 Committed revision 1.
-$ 
+$
 </screen>
 
     <para lang="en">Now the repository contains this tree of data.  As mentioned
@@ -943,11 +950,11 @@
       <para>Notare che la directory originaria <filename>/tmp/myproject</filename>
       non e' cambiata; Subversion non lo sa.  (Infatti, potete anche cancellare quella
       directory se volete.)  Per essere in grado di iniziare a manipolare i dati nel repository,
-      avete bisogno di creare una nuova <quote>copia di lavoro (working copy)</quote> dei dati, 
-      una sorta di spazio di lavoro privato. 
+      avete bisogno di creare una nuova <quote>copia di lavoro (working copy)</quote> dei dati,
+      una sorta di spazio di lavoro privato.
       Domandate a Subversion di effettuare un  <quote>check out</quote> della copia di lavoro
       della directory <filename>myproject/trunk</filename> memorizzata nel repository:</para>
-  
+
 
     <screen>
 $ svn checkout file:///path/to/repos/myproject/trunk myproject
@@ -964,7 +971,7 @@
       back into the repository.</para>
 
     <para>Ora avete una copia personale di parte del repository
-    in una nuova directory chiamata <filename>myproject</filename>.  
+    in una nuova directory chiamata <filename>myproject</filename>.
     Potete modificare i files nella copia di lavoro e poi sottomettere a svn (commit)
     i cambiamenti nel repository.</para>
 
@@ -994,7 +1001,7 @@
     <para lang="en">For a full tour of all the things you can do with your
       working copy, read <xref linkend="svn.tour"/>.</para>
 
-    <para>Per un tour completo riguado tutte le cose che si possono fare con la copia locale, 
+    <para>Per un tour completo riguado tutte le cose che si possono fare con la copia locale,
     leggere <xref linkend="svn.tour"/>.</para>
 
     <para lang="en">At this point, you have the option of making your repository
@@ -1003,7 +1010,7 @@
       server processes available and how to configure them.</para>
 
     <para> A questo punto, potete scegliere di rendere accessibile il vostro repository via rete.
-    Consultare anche <xref linkend="svn.serverconfig"/> per imparare riguardo i diversi tipi di processi server disponibili 
+    Consultare anche <xref linkend="svn.serverconfig"/> per imparare riguardo i diversi tipi di processi server disponibili
       e come configurarli.</para>
 
   </sect1>
@@ -1012,7 +1019,7 @@
 </chapter>
 
 <!--
-local variables: 
+local variables:
 sgml-parent-document: ("book.xml" "chapter")
 end:
 -->

Modified: trunk/src/it/book/ch04.xml
==============================================================================
--- trunk/src/it/book/ch04.xml	(original)
+++ trunk/src/it/book/ch04.xml	Tue Sep  5 11:57:44 2006
@@ -10,11 +10,11 @@
       see how Subversion implements these ideas.</para>
 
     <para>Ramificazioni, etichette e fusioni sono concetti comuni a
-      quasi tutti sistemi di controllo di versione.  Se non si conoscono
+      quasi tutti sistemi di controllo delle versioni.  Se non si conoscono
       abbastanza queste idee, forniamo noi la buona introduzione in
       questo capitolo. Se le conoscete già, si spera che troverete interesante
       di vedere come Subversion implementa queste idee.</para>
-    
+
     <para lang="en">Branching is a fundamental part of version control.  If
       you're going to allow Subversion to manage your data, then this
       is a feature you'll eventually come to depend on.  This chapter
@@ -26,7 +26,7 @@
       dipenderete da questa caratteristica. In questo capitolo si assume
       che siete già al corrente di concetti base di Subversion
       (<xref linkend="svn.basic"/>).</para>
-    
+
   </simplesect>
 
   <!-- ================================================================= -->
@@ -44,9 +44,9 @@
     <para>Supponiamo che vostro compito è mantenere un certo documento per
       un dipartimento della vostra società. Un giorno un altro dipartimento
       chiede lo stesso documento, ma con alcune parti
-      <quote>modificate</quote> per loro, perché in quel dipartimento alcune
-      cose le fanno in modo legermente diverso.</para>
-    
+      <quote>modificate</quote> per loro, perché in quel dipartimento le
+      cose fanno in modo legermente diverso.</para>
+
     <para lang="en">What do you do in this situation?  You do the obvious thing:
       you make a second copy of your document, and begin maintaining
       the two copies separately.  As each department asks you to make
@@ -55,9 +55,9 @@
 
     <para>Che cosa fatte in questa situazione?  Una cosa ovvia:
       fatte la seconda copia del vostro documento e cominciate mantenere
-      queste due copie separatamente. Quando uno o altro dipartimento
+      le due copie separatamente. Quando uno o altro dipartimento
       chede di fare modifiche, voi le fatte in una o altra copia.</para>
-    
+
     <para lang="en">You often want to make the same change to both copies.  For
       example, if you discover a typo in the first copy, it's very
       likely that the same typo exists in the second copy.  The two
@@ -69,7 +69,7 @@
       molto probabilmente lo stesso errore è anche nell'altra. Dopo tutto,
       le due copie sono quasi identiche, diferiscono solo nelle piccole,
       specifiche parti.</para>
-    
+
     <para lang="en">This is the basic concept of a
       <firstterm>branch</firstterm>—namely, a line of
       development that exists independently of another line, yet still
@@ -83,7 +83,7 @@
       sviluppo che esiste independemente dall'altra, anche se sempre
       condividono la storia comune se si guarda abbastanza indietro in tempo.
       Un ramo sempre comincia la sua vita come copia di qualcosa e
-      muovendosi da questo punto genera la sua propria storia
+      prosegue da questo punto generando la sua propria storia
       (vedi <xref linkend="svn.branchmerge.whatis.dia-1"/>).</para>
 
       <figure id="svn.branchmerge.whatis.dia-1">
@@ -102,14 +102,14 @@
 
     <para>Subversion ha i comandi per aiutarvi mantenere rami paralleli
       di vostri file e cartelle. Vi permette di creare rami copiando i vostri dati
-      e ricordare che le copie sono in relazione con altre. Vi aiuta anche
-      di dupplicare cambiamenti da un ramo ad altro. Infine, vi permette
-      di creare parti della vostra copia di lavoro che riflettono rami
-      differenti così che potete <quote>mescolare e abbinare</quote>
-      le linee differenti dello sviluppo nel vostro lavoro giornaliero.</para>
-  
+      e si ricorda che le copie sono in relazione con altre. Vi aiuta anche
+      di dupplicare cambiamenti da un ramo ad altro. Infine, può
+      creare parti della vostra copia di lavoro che riflettono rami
+      diversi così che potete <quote>mescolare e abbinare</quote>
+      le linee diverse dello sviluppo nel vostro lavoro giornaliero.</para>
+
   </sect1>
-  
+
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <!-- ================================================================= -->
@@ -124,8 +124,8 @@
     <para>A questo punto dovete già capire come ogni commit crea
       in deposito un albero di filesystem completamente nuovo (chiamato una
       <quote>revisione</quote>).  Se no, tornate dietro a leggere riguardo le
-      revisioni in <xref linkend="svn.basic.in-action.revs"/>.</para>
-    
+      revisioni <xref linkend="svn.basic.in-action.revs"/>.</para>
+
     <para lang="en">For this chapter, we'll go back to the same example from
       Chapter 2.  Remember that you and your collaborator, Sally, are
       sharing a repository that contains two projects,
@@ -134,7 +134,7 @@
       project directory now contains subdirectories named
       <filename>trunk</filename> and <filename>branches</filename>.
       The reason for this will soon become clear.</para>
-    
+
     <para>Per questo capitolo torniamo allo stesso esempio del Capitolo 2.
       Ricordate che voi e vostra collaboratrice, Sally, state condividere
       un deposito che contiene due progetti,
@@ -143,10 +143,15 @@
       ogni cartella di progetto adesso contiene sottocartelle denominate
       <filename>trunk</filename> e <filename>branches</filename>.
       La ragione di ciò diventa presto chiara.</para>
-    
-      <figure id="svn.branchmerge.using.dia-1">
+
+      <!-- <figure id="svn.branchmerge.using.dia-1">
         <title>Starting repository layout</title>
         <graphic fileref="images/ch04dia2.png"/>
+      </figure> -->
+
+      <figure id="svn.branchmerge.using.dia-1">
+        <title>Forma iniziale del deposito</title>
+        <graphic fileref="images/ch04dia2.png"/>
       </figure>
 
     <para lang="en">As before, assume that Sally and you both have working
@@ -160,12 +165,12 @@
 
     <para>Come prima, assumiamo che tutti e due, Sally e voi, avete
       copia di lavoro del progetto <quote>calc</quote>. Specificamente,
-      entrambi avete copia di lavoro di <filename>/calc/trunk</filename>.
+      entrambi avete una copia di lavoro di <filename>/calc/trunk</filename>.
       Tutti i file del progetto sono in questa sottocartella invece nella
       cartella <filename>/calc</filename> stessa, perché vostro gruppo ha deciso
       che <filename>/calc/trunk</filename> è il posto dove va posizionata la
       <quote>linea principale</quote> dello sviluppo.</para>
-    
+
     <para lang="en">Let's say that you've been given the task of performing a
       radical reorganization of the project.  It will take a long time
       to write, and will affect all the files in the project.  The
@@ -179,11 +184,11 @@
     <para>Diciamo che vi hanno dato lavoro di radicale riorganizazione del
       progetto. Questo prende lungo tempo per scriverlo e toccherà tutti i file
       nell progetto. Il problema è che voi non volete interferire con lavoro di
-      Sally, che sta correggendo piccoli errori qua e là. Ella dipende sul fatto
+      Sally, che sta correggendo piccoli errori qua e là. Ella dipende dall fatto
       che l'ultima versione del progetto (in <filename>/calc/trunk</filename>)
       è sempre usabile. Se voi cominciate commit dei vostri cambiamenti
-      pezzo-per-pezzo, sicuramente rompete le cose per Sally.</para>
-    
+      pezzo-per-pezzo, sicuramente rompete le cose a Sally.</para>
+
     <para lang="en">One strategy is to crawl into a hole: you and Sally can stop
       sharing information for a week or two.  That is, start gutting
       and reorganizing all the files in your working copy, but don't
@@ -217,9 +222,9 @@
       molto sicuro. A molte persone piace conservare suo lavoro
       nel deposito frequentemente, nel caso che accidentalmente succede
       qualcosa brutto alla loro copia di lavoro. Seconda, non è molto
-      flessibile. Se state svolgendo vostro lavoro su differenti computer
+      flessibile. Se state svolgendo vostro lavoro su diversi computer
       (magari avete le copie di lavoro del <filename>/calc/trunk</filename>
-      su due macchine differenti), avete bisogno di copiare manualmente
+      su due macchine diverse), avete bisogno di copiare manualmente
       i vostri cambiamenti avanti e dietro o fare il lavoro solo su un computer.
       E per la stessa ragione, è difficile condividere i vostri cambiamenti-in-corso
       con qualcun altro. <quote>Miglior attegiamento</quote> comune
@@ -229,11 +234,11 @@
       Alla fine, quando avete finito con tutti i vostri cambiamenti,
       potete magari trovare molto difficile di ri-fondere vostro lavoro finale
       con il resto del corpo principale del codice della vostra società.
-      Sally (o altri) poteva fare molti diversi cambiamenti nel deposito
-      che sono difficili a incorporare nella vostra copia di
+      Sally (o altri) poteva fare molti altri cambiamenti nel deposito
+      che sono difficili da incorporare nella vostra copia di
       lavoro—specialmente se fatte <command>svn update</command>
       dopo settimane di isolamento.</para>
-    
+
     <para lang="en">The better solution is to create your own branch, or line of
       development, in the repository.  This allows you to save your
       half-broken work frequently without interfering with others, yet
@@ -243,15 +248,15 @@
 
     <para>La soluzione migliore è creare vostro ramo, o linea di
       sviluppo, nel deposito.  Questo vi permette di salvare vostro
-      lavoro fatto-a-metà frequentemente senza interferire con altri,
+      lavoro fatto-a-metà[??incompiuto?] frequentemente senza interferire con altri,
       ma nello stesso tempo selettivamente condividere le informazioni
       con i vostri collaboratori. Vediamo in seguito esattamente come questo
       approcio funziona.</para>
-    
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.using.create">
       <title>Creare un ramo</title>
-      
+
       <para lang="en">Creating a branch is very simple—you make a copy of
         the project in the repository using the <command>svn
         copy</command> command.  Subversion is not only able to copy
@@ -279,18 +284,18 @@
         e voi volete chiamare vostro ramo <literal>my-calc-branch</literal>.
         State per creare nuova cartella,
         <filename>/calc/branches/my-calc-branch</filename>, che nasce come
-        cop lang="en"ia di <filename>/calc/trunk</filename>.</para>
-      
+        copia di <filename>/calc/trunk</filename>.</para>
+
       <para lang="en">There are two different ways to make a copy.  We'll
         demonstrate the messy way first, just to make the concept
         clear.  To begin, check out a working copy of the project's
         root directory, <filename>/calc</filename>:</para>
 
-      <para>Ci sono due modi differenti di fare una copia. Vi dimostriamo
+      <para>Ci sono due modi diversi di fare una copia. Vi dimostriamo
         prima quello ingarbugliato, solo per fare chiaro il concetto.
         Per cominciare, tiriamo fuori una copia di lavoro della cartella
         principale del progetto, <filename>/calc</filename>:</para>
-      
+
       <screen>
 $ svn checkout http://svn.example.com/repos/calc bigwc
 A  bigwc/trunk/
@@ -307,7 +312,7 @@
 
       <para>Creare una copia è adesso semplice ??matter? di passare due
         percorsi di copia di lavoro al comando <command>svn copy</command>:</para>
-      
+
       <screen>
 $ cd bigwc
 $ svn copy trunk branches/my-calc-branch
@@ -333,16 +338,16 @@
       <para>In questo caso, il comando <command>svn copy</command>
         copia ricorsivamente cartella di lavoro <filename>trunk</filename>
         nella nuova cartella di lavoro, <filename>branches/my-calc-branch</filename>.
-        Come si può vedere dal comendo <command>svn status</command>,
+        Come si può vedere dal comando <command>svn status</command>,
         la nuova cartella è adesso pianificata per essere aggiunta
         al deposito. Notare anche che il segno <quote>+</quote> vicono la lettera
-        A.  Questo indica che la aggiunta pianificata è una <emphasis>copy</emphasis>
+        A.  Questo indica che la aggiunta pianificata è una <emphasis>copia</emphasis>
         di qualcosa, non qualcosa di nuovo. Quando fatte il commit degli vostri
         cambiamenti, Subversion creerà
         <filename>/calc/branches/my-calc-branch</filename> nel deposito
         copiando <filename>/calc/trunk</filename>, invece di re-inviare tramite
         la rete tutti i dati dalla cartella di lavoro:</para>
-      
+
       <screen>
 $ svn commit -m "Creating a private branch of /calc/trunk."
 Adding         branches/my-calc-branch
@@ -354,9 +359,9 @@
         copy</command> is able to operate directly on two URLs.</para>
 
       <para>E adesso il metodo più semplice di creare un ramo, di cui
-        dovevamo parlare per primo: <command>svn
+        si doveva parlare per primo: <command>svn
         copy</command> può operare direttamente su due URL.</para>
-    
+
       <screen>
 $ svn copy http://svn.example.com/repos/calc/trunk \
            http://svn.example.com/repos/calc/branches/my-calc-branch \
@@ -371,7 +376,7 @@
         <filename>/calc/trunk</filename>.  This is shown in <xref
         linkend="svn.branchmerge.using.create.dia-1"/>.  Notice that the second method,
         however, performs an <emphasis>immediate</emphasis> commit.
-        <footnote> 
+        <footnote>
           <para>Subversion does not support
             cross-repository copying.  When using URLs with <command>svn
             copy</command> or <command>svn move</command>, you can only
@@ -381,14 +386,14 @@
         check out a large mirror of the repository.  In fact, this
         technique doesn't even require you to have a working copy at
         all.</para>
-      
+
       <para>Realmente non c'è differenza tra questi due metodi.
         Entrambe le procedure creano una nuova cartella nella revisione 341 e
         la nuova cartella è una copia di <filename>/calc/trunk</filename>.
         Come mostrato in <xref
         linkend="svn.branchmerge.using.create.dia-1"/>.  Notare che il secondo
         metodo, tuttavia, fa anche commit <emphasis>immediato</emphasis>.
-        <footnote> 
+        <footnote>
           <para>Subversion non supporta la copia tra due depositi
             (cross-repository). Usando gli URL con <command>svn
             copy</command> o <command>svn move</command>, si possono
@@ -397,15 +402,15 @@
         Questa è una procedura più semplice, perché non richiede di fare
         checkout di grande parte del deposito.  Infatti, questa tecnica
         non richiede addirittura neanche di avere la copia di lavoro.</para>
-      
+
       <figure id="svn.branchmerge.using.create.dia-1">
         <title>Deposito con la nuova copia</title>
         <graphic fileref="images/ch04dia3.png"/>
       </figure>
-      
+
       <sidebar>
         <title>Le copie economiche</title>
-                
+
         <para lang="en">Subversion's repository has a special design.  When you
           copy a directory, you don't need to worry about the
           repository growing huge—Subversion doesn't actually
@@ -418,7 +423,7 @@
           changes—the rest of the files continue to exist as
           links to the original files in the original
           directory.</para>
-      
+
         <para>Il deposito di Subversion ha un design speciale.
           Quando si fa la copia della cartella, non dovete preoccuparvi
           della massice crescita del deposito—Subversion in verità
@@ -430,7 +435,7 @@
           della cartella copiata, solo quel file cambia—il resto
           dei file continua esistere come i link ai file originali nella
           cartella originale.</para>
-        
+
         <para lang="en">This is why you'll often hear Subversion users talk
           about <quote>cheap copies</quote>.  It doesn't matter how
           large the directory is—it takes a very tiny, constant
@@ -445,29 +450,29 @@
         <para>E per questo spesso sentirette utenti di Subversion parlare
           delle <quote>copie economiche</quote>. Non importa quanto è
           grande la cartella—fare la sua copia prende sempre
-          molto piccola, costante, quantità del tempo. Infatti, questa
+          molto piccola, costante quantità del tempo. Infatti, questa
           caratteristica è la base del funzionamento di commit in Subversion:
           ogni revisione è <quote>copia economica</quote> della
           revisione precedente, con dentro poche voci pigramente cambiate.
           (Per leggere di più, visitate il sito web di Subversion e leggete
-          di metodo <quote>bubble up</quote>negli documenti riguardo design
+          di metodo <quote>bubble up</quote> negli documenti riguardo design
           di Subversion.)</para>
-        
+
         <para lang="en">Of course, these internal mechanics of copying and
           sharing data are hidden from the user, who simply sees
           copies of trees.  The main point here is that copies are
           cheap, both in time and space.  Make branches as often as
           you want.</para>
-        
+
         <para>Ovviamente, questo mecanismo interno di copiatura e
           condivisione dei dati è per utenti nascosto, loro semplicemente vedono
           le copie delle strutture. Qui il punto cardinale è che le copie
-          sono economiche, parlando di spazio e tempo. Fatte i rami ogni volta
+          sono economiche, parlando di tempo e spazio. Fatte i rami ogni volta
           che volete.</para>
       </sidebar>
 
     </sect2>
-    
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.using.work">
       <title>Lavorare con il vostro ramo</title>
@@ -477,7 +482,7 @@
 
       <para>Adesso che avete creato un ramo del progetto, potete tirare fuori
         (check out) una nuova copia di lavoro per cominciar ad usarla:</para>
-      
+
       <screen>
 $ svn checkout http://svn.example.com/repos/calc/branches/my-calc-branch
 A  my-calc-branch/Makefile
@@ -496,7 +501,7 @@
         creating a working copy of a branch.)</para>
 
       <para>Non c'è niente speciale di questa copia di lavoro; semplicemente
-        rispecchia una cartella differente del deposito.
+        rispecchia una cartella diversa del deposito.
         Quando pubblicate le vostre modifiche (commit), tuttavia, Sally
         non può nenche vederle quando fa aggiornamento (update). La sua
         copia di lavoro è di <filename>/calc/trunk</filename>.
@@ -510,7 +515,7 @@
 
       <para>Facciamo finta che le settimane passano e succedono sequenti pubblicazioni
         (commit):</para>
-      
+
       <!--<itemizedlist>
         <listitem><para>
           You make a change to
@@ -537,33 +542,46 @@
             <filename>/calc/branches/my-calc-branch/button.c</filename>,
             che crea revisione 342.</para>
         </listitem>
-        
+
         <listitem><para>
             Fatte modifica di
             <filename>/calc/branches/my-calc-branch/integer.c</filename>,
             che crea revisione 343.</para>
         </listitem>
-        
+
         <listitem><para>
             Sally modifica
             <filename>/calc/trunk/integer.c</filename>, che crea
             revisione 344.</para>
         </listitem>
       </itemizedlist>
-      
-      <para>There are now two independent lines of development, shown
+
+      <para lang="en">There are now two independent lines of development, shown
         in <xref linkend="svn.branchmerge.using.work.dia-1"/>, happening on
         <filename>integer.c</filename>.</para>
 
-      <figure id="svn.branchmerge.using.work.dia-1">
+      <para>Ci sono adesso due linee di sviluppo independenti, mostrate
+        in <xref linkend="svn.branchmerge.using.work.dia-1"/>, che toccano
+        <filename>integer.c</filename>.</para>
+
+      <!-- <figure id="svn.branchmerge.using.work.dia-1">
         <title>The branching of one file's history</title>
         <graphic fileref="images/ch04dia4.png"/>
+      </figure> -->
+
+      <figure id="svn.branchmerge.using.work.dia-1">
+        <title>Ramificazione della storia d'un file</title>
+        <graphic fileref="images/ch04dia4.png"/>
       </figure>
 
-      <para>Things get interesting when you look at the history of
+      <para lang="en">Things get interesting when you look at the history of
         changes made to your copy of
         <filename>integer.c</filename>:</para>
 
+      <para>Le cose diventano interessanti quando guardate la storia delle
+        modifiche della vostra copia di
+        <filename>integer.c</filename>:</para>
+
       <screen>
 $ pwd
 /home/user/my-calc-branch
@@ -600,7 +618,7 @@
 ------------------------------------------------------------------------
 </screen>
 
-      <para>Notice that Subversion is tracing the history of your
+      <para lang="en">Notice that Subversion is tracing the history of your
         branch's <filename>integer.c</filename> all the way back
         through time, even traversing the point where it was copied.
         It shows the creation of the branch as an event in the
@@ -609,6 +627,15 @@
         copied.  Now look what happens when Sally runs the same
         command on her copy of the file:</para>
 
+      <para>Notare che Subversion tiene traccia della storia di
+        <filename>integer.c</filename> del vostro ramo dietro tutto il tempo,
+        attraversando anche il punto dov'è stato copiato.
+        Mostra la creazione del ramo come evento nella storia,
+        perché <filename>integer.c</filename> era stato implicitamente copiato
+        quando tutto il <filename>/calc/trunk/</filename> era stato copiato.
+        Adesso guardate che sucede quando Sally avvia lo stesso comando
+        sulla sua copia del file:</para>
+
       <screen>
 $ pwd
 /home/sally/calc
@@ -638,7 +665,7 @@
 ------------------------------------------------------------------------
 </screen>
 
-      <para>Sally sees her own revision 344 change, but not the change
+      <para lang="en">Sally sees her own revision 344 change, but not the change
         you made in revision 343.  As far as Subversion is concerned,
         these two commits affected different files in different
         repository locations.  However, Subversion
@@ -647,25 +674,42 @@
         341, they used to be the same file.  That's why you and Sally
         both see the changes made in revisions 303 and 98.</para>
 
+      <para>Sally vede la sua modifica nella versione 344, ma non la modifica
+        che voi avete fatto nella versione 343. ??As far as Subversion is concerned,?
+        questi due commit riguardano i file diversi nelle diverse locazioni
+        del deposito.  Tuttavia, Subversion <emphasis>mostra</emphasis> che questi
+        due file condividono una storia comune. Prima che era fatta copia del ramo
+        nella versione 341, essi erano l'unico file. E per questo entrambi, voi e Sally,
+        vedete le modifiche fatte nelle versioni 303 e 98.</para>
+
     </sect2>
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.using.concepts">
-      <title>The Key Concepts Behind Branches</title> 
+    <!-- <title>The Key Concepts Behind Branches</title> -->
+      <title>Concetti chiave dietro i rami</title>
 
-      <para>There are two important lessons that you should remember
+      <para lang="en">There are two important lessons that you should remember
         from this section.</para>
 
+      <para>Ci sono due lezioni importanti che covete ricordare
+        da questa sezione.</para>
+
       <orderedlist>
         <listitem>
-          <para>Unlike many other version control systems,
+          <para lang="en">Unlike many other version control systems,
             Subversion's branches exist as <emphasis>normal filesystem
             directories</emphasis> in the repository, not in an extra
             dimension.  These directories just happen to carry some
             extra historical information.</para>
+          <para>Diversamente da molti altri sistemi di controllo di vesione,
+            rami di Subversion esistono  come <emphasis>normali cartelle
+            del filesystem</emphasis> in deposito, non in una dimensione extra.
+            Succede solo che queste cartelle portano qualche
+            storica informazione extra.</para>
         </listitem>
         <listitem>
-          <para>Subversion has no internal concept of a
+          <para lang="en">Subversion has no internal concept of a
             branch—only copies.  When you copy a directory, the
             resulting directory is only a <quote>branch</quote>
             because <emphasis>you</emphasis> attach that meaning to
@@ -673,6 +717,12 @@
             it differently, but to Subversion it's just an ordinary
             directory that happens to have been created by
             copying.</para>
+          <para>Subversion non ha un concetto interno dei rami—solo copie.
+            Quando copiate una cartella, la cartella risultante
+            è un <quote>ramo</quote> solo perché <emphasis>voi</emphasis> le date
+            questo significato. Potete pensare alla cartella diversamente o
+            trattarla diversamente, ma per Subversion essa è solo normale
+            cartella, a quall'è successo di esser creata tramite copiatura.</para>
         </listitem>
       </orderedlist>
 
@@ -684,42 +734,69 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.branchmerge.copychanges">
-    <title>Copying Changes Between Branches</title>
+    <!-- <title>Copying Changes Between Branches</title> -->
+    <title>Copiare modifiche tra i rami</title>
 
-    <para>Now you and Sally are working on parallel branches of the
+    <para lang="en">Now you and Sally are working on parallel branches of the
       project: you're working on a private branch, and Sally is
       working on the <firstterm>trunk</firstterm>, or main line of
       development.</para>
 
-    <para>For projects that have a large number of contributors, it's
+    <para>Adesso voi e Sally state lavorando sui rami paralleli del progetto:
+      voi lavorate su un ramo privato e Sally lavora su
+      <firstterm>trunk</firstterm>, o linea principale dello sviluppo.</para>
+
+    <para lang="en">For projects that have a large number of contributors, it's
       common for most people to have working copies of the trunk.
       Whenever someone needs to make a long-running change that is
       likely to disrupt the trunk, a standard procedure is to create a
       private branch and commit changes there until all the work is
       complete.</para>
 
-    <para>So, the good news is that you and Sally aren't interfering
+    <para>Per progetti che hanno grande numero di contribuenti, è comune
+      per molta gente di avere copie di lavoro del trunk.
+      Ogni volta che qualcuno ha bisogno di fare ??long-running? modifiche,
+      che potrebbero disturbare il trunk, procedura standard è di creare
+      un ramo privato e pubblicare (commit) le modifiche là finché tutto
+      il lavoro no è completo.</para>
+
+    <para lang="en">So, the good news is that you and Sally aren't interfering
       with each other.  The bad news is that it's very easy to drift
       <emphasis>too</emphasis> far apart.  Remember that one of the
       problems with the <quote>crawl in a hole</quote> strategy is
       that by the time you're finished with your branch, it may be
       near-impossible to merge your changes back into the trunk
       without a huge number of conflicts.</para>
-    
-    <para>Instead, you and Sally might continue to share changes as
+
+    <para>Allora, la notizia buona è che voi e Sally non vi disturbate
+      a vicenda. La notizia cativa è che è molto facile slittare
+      <emphasis>tropo</emphasis> lontano.  Ricordate che uno dei problemi
+      della strategia <quote>nascondersi in una buca</quote> è
+      che quando avrete finito con il vostro ramo, potrebbe essere
+      quasi impossibile fondere vostre modifiche nel tronco principale senza
+      largo numero di conflitti.</para>
+
+    <para lang="en">Instead, you and Sally might continue to share changes as
       you work.  It's up to you to decide which changes are worth
       sharing; Subversion gives you the ability to selectively
       <quote>copy</quote> changes between branches.  And when you're
       completely finished with your branch, your entire set of branch
       changes can be copied back into the trunk.</para>
-    
+
+    <para>??Instead?, voi e Sally potrette continuare di scambiarsi modifiche
+      mentre lavorate.  Spetta a voi decidere qualle modifiche vale la pena
+      condividere; Subversion vi dà l'abilità di <quote>copiare</quote>
+      modifiche tra i rami selettivamente.  E quando avrete completamente
+      finito con il vostro ramo, vostro completto insieme di modifiche del ramo
+      può essere copiato dietro nel tronco (trunk).</para>
+
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.copychanges.specific">
-      <title>Copying Specific Changes</title>
-      
+      <!-- <title>Copying Specific Changes</title> -->
+      <title>Copiare modifiche specifiche</title>
 
-      <para>In the previous section, we mentioned that both you and
+      <para lang="en">In the previous section, we mentioned that both you and
         Sally made changes to <filename>integer.c</filename> on
         different branches.  If you look at Sally's log message for
         revision 344, you can see that she fixed some spelling errors.
@@ -731,7 +808,20 @@
         now, <emphasis>before</emphasis> you start working too heavily
         in the same places.</para>
 
-      <para>It's time to use the <command>svn merge</command> command.
+      <para>Nella precedente sezione, abbiamo menzionato che
+        entrambi, voi e Sally avete fatto modifiche su
+        <filename>integer.c</filename> nei rami diversi.
+        Se date un sguardo al messaggio di log di Sally (versione
+        344), potete vedere che ella ha corretto qualche errore di battitura.
+        Senza dubbio, vostra copy dello stesso file ancora ha gli stessi
+        errori.  È probabile che le vostr future modifich al file toccheranno
+        gli stessi posti che hanno errori di battitura, così sorgeranno alcuni
+        potenziali conflitti, quando un giorno andrete a fondere il vostro ramo.
+        Meglio incorporare le modifiche di Sally adesso
+        <emphasis>prima</emphasis> che cominciate lavoro troppo pesante
+        sugli stessi posti.</para>
+
+      <para lang="en">It's time to use the <command>svn merge</command> command.
         This command, it turns out, is a very close cousin to the
         <command>svn diff</command> command (which you read about in
         Chapter 3).  Both commands are able to compare any two objects
@@ -739,13 +829,21 @@
         you can ask <command>svn diff</command> to show you the exact
         change made by Sally in revision 344:</para>
 
+      <para>È ora di usare comando <command>svn merge</command>.
+        Questo comando, come si vedrà, è cugino molto stretto del
+        comando <command>svn diff</command> (di quale avete letto nel
+        Capitolo 3).  Entrambi comandi sono capaci di comparare aulsiasi
+        due oggetti in deposito e descrivere le differenze. Per esempio,
+        potete chiedere a <command>svn diff</command> di mostrare
+        esatta modifica fatta da Sally nella versione 344:</para>
+
       <screen>
 $ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk
 
 Index: integer.c
 ===================================================================
---- integer.c	(revision 343)
-+++ integer.c	(revision 344)
+--- integer.c   (revision 343)
++++ integer.c   (revision 344)
 @@ -147,7 +147,7 @@
      case 6:  sprintf(info->operating_system, "HPFS (OS/2 or NT)"); break;
      case 7:  sprintf(info->operating_system, "Macintosh"); break;
@@ -761,34 +859,39 @@
      high = high << 8;  /* interpret MSB correctly */
 -    total = low + high; /* add them togethe for correct total */
 +    total = low + high; /* add them together for correct total */
- 
+
      info->extra_header = (unsigned char *) my_malloc(total);
      fread(info->extra_header, total, 1, gzfile);
 @@ -241,7 +241,7 @@
       Store the offset with ftell() ! */
- 
+
    if ((info->data_offset = ftell(gzfile))== -1) {
 -    printf("error: ftell() retturned -1.\n");
 +    printf("error: ftell() returned -1.\n");
      exit(1);
    }
- 
+
 @@ -249,7 +249,7 @@
    printf("I believe start of compressed data is %u\n", info->data_offset);
    #endif
-   
+
 -  /* Set postion eight bytes from the end of the file. */
 +  /* Set position eight bytes from the end of the file. */
- 
+
    if (fseek(gzfile, -8, SEEK_END)) {
      printf("error: fseek() returned non-zero\n");
 </screen>
-      
-      <para>The <command>svn merge</command> command is almost exactly
+
+      <para lang="en">The <command>svn merge</command> command is almost exactly
         the same.  Instead of printing the differences to your
         terminal, however, it applies them directly to your working
         copy as <emphasis>local modifications</emphasis>:</para>
-    
+
+      <para>Il comando <command>svn merge</command> è quasi esattamente
+        uguale.  Invece di mostrare le differenze sullo schermo
+        terminal, tuttavia, le applica direttamente nella vostra
+        copia di lavoro come <emphasis>modifiche locali</emphasis>:</para>
+
       <screen>
 $ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk
 U  integer.c
@@ -797,7 +900,7 @@
 M  integer.c
 </screen>
 
-      <para>The output of <command>svn merge</command> shows that your
+      <para lang="en">The output of <command>svn merge</command> shows that your
         copy of <filename>integer.c</filename> was patched.  It now
         contains Sally's change—the change has been
         <quote>copied</quote> from the trunk to your working copy of
@@ -805,24 +908,51 @@
         At this point, it's up to you to review the local modification
         and make sure it works correctly.</para>
 
-      <para>In another scenario, it's possible that things may not have
+      <para>L'output di <command>svn merge</command> mostra che vostra
+        copia di <filename>integer.c</filename> era stata modificata. Adesso
+        contiene le modifiche di Sally—le modifiche erano state
+        <quote>copiate</quote> dal tronco(trunk) nella copia di lavoro
+        del vostro ramo privato e adesso esistono come modifiche locali.
+        A questo punto, tocca a voi rivedere le modifiche locali ed assicurare
+        che funzionano correttamente.</para>
+
+      <para lang="en">In another scenario, it's possible that things may not have
         gone so well, and that <filename>integer.c</filename> may have
         entered a conflicted state.  You might need to resolve the
         conflict using standard procedures (see Chapter 3), or if you
         decide that the merge was a bad idea altogether, simply give up
         and <command>svn revert</command> the local change.</para>
 
-      <para>But assuming that you've reviewed the merged change, you can
+      <para>In un altro scenario, è possibile che le cose possono no andare
+        cos' bene e perciò <filename>integer.c</filename> può entrare
+        nello stato di conflitto.  Potrette avere bisogno di risolvere
+        il conflitto usando procedure standard (vedi Capitolo 3), oppure
+        se decidete che fusione era una cativa idea ??altogether?,
+        semplicemente ??give up? e scartare con <command>svn revert</command>
+        le modifiche locali.</para>
+
+      <para lang="en">But assuming that you've reviewed the merged change, you can
         <command>svn commit</command> the change as usual.  At that
         point, the change has been merged into your repository branch.
         In version control terminology, this act of copying changes
         between branches is commonly called
         <firstterm>porting</firstterm> changes.</para>
 
-      <para>When you commit the local modification, make sure your log
+      <para>Ma assumendo che avete ispezionato le modifiche incorporate,
+        potete pubblicare modifica con <command>svn commit</command>
+        come al solito. A questo punto, la modifica sarà fusa dentro
+        il vostro ramo del deposito. Nella terminologia di controlo delle
+        versioni, questo atto di copiatura delle modifiche tra i rami
+        è comunemnte chaimato <firstterm>porting</firstterm> dele modifiche.</para>
+
+      <para lang="en">When you commit the local modification, make sure your log
         message mentions that you're porting a specific change from
         one branch to another.  For example:</para>
 
+      <para>Facendo commit delle modifiche locali, assicuratevi che
+        vostro messaggio menziona che state portando una modifica specifica
+        da un ramo ad altro. Per esempio:</para>
+
       <screen>
 $ svn commit -m "integer.c: ported r344 (spelling fixes) from trunk."
 Sending        integer.c
@@ -830,18 +960,28 @@
 Committed revision 360.
 </screen>
 
-      <para>As you'll see in the next sections, this is a very
+      <para lang="en">As you'll see in the next sections, this is a very
         important <quote>best practice</quote> to follow.</para>
 
+      <para>Come verdrete nella prossima sezione, questa è molto importante
+        <quote>regola d'arte</quote> da seguire.</para>
+
       <sidebar>
-        <title>Why Not Use Patches Instead?</title>
-        
-        <para>A question may be on your mind, especially if you're a
+        <!-- <title>Why Not Use Patches Instead?</title> -->
+        <title>Perché non usare invece Patch?</title>
+
+        <para lang="en">A question may be on your mind, especially if you're a
           Unix user: why bother to use <command>svn merge</command> at
           all?  Why not simply use the operating system's
           <command>patch</command> command to accomplish the same job?
           For example:</para>
 
+        <para>Potete pensare a una domanda, specialmente se siete utenti
+          Unix: perchè disturbarsi con <command>svn merge</command>?
+          Perché semplicemente non usare comando di sistema operativo
+          <command>patch</command> per svolgere lo stesso lavoro?
+          Per esempio:</para>
+
         <screen>
 $ svn diff -r 343:344 http://svn.example.com/repos/calc/trunk > patchfile
 $ patch -p0  < patchfile
@@ -853,7 +993,7 @@
 done
 </screen>
 
-        <para>In this particular case, yes, there really is no
+        <para lang="en">In this particular case, yes, there really is no
           difference.  But <command>svn merge</command> has special
           abilities that surpass the <command>patch</command> program.
           The file format used by <command>patch</command> is quite
@@ -874,9 +1014,29 @@
           changes in tree structure and properties by directly applying
           them to your working copy.</para>
 
+        <para>In questo caso particolare, sì, veramente non c'è
+          differenza.  Ma <command>svn merge</command> ha le
+          abilità speciali che sorpassano il programma <command>patch</command>.
+          Formato di file usato da <command>patch</command> è un po'
+          limitato; è capace di maneggare contenuto del file.  Non c'è
+          modo di rappresentare modifiche delle <emphasis>strutture</emphasis>,
+          come aggiunta, rimozione o cambio del nome dei file e delle
+          cartelle.  Se la modifica di Sally ha, diciamo, aggiunto una
+          nuova cartella, output di <command>svn diff</command>
+          non la menziona neanche.  <command>svn
+          diff</command> mostra solo patch-format limitato, così ci sono
+          alcune idee che semplicemente non può esprimere.
+          <footnote>
+            <para>In futuro, progetto Subversion pianifica du usare
+              (o inventare) patch format estesso che descrive modifiche
+              delle struture e properietà.</para>
+          </footnote>
+          Il comando <command>svn merge</command>, tuttavia, può esprimere
+          modifiche della struttura e properietà applicandole direttamente
+          sulla vostra copia di lavoro.</para>
       </sidebar>
-      
-      <para>A word of warning: while <command>svn diff</command> and
+
+      <para lang="en">A word of warning: while <command>svn diff</command> and
         <command>svn merge</command> are very similar in concept, they
         do have different syntax in many cases.  Be sure to read about
         them in Chapter 9 for details, or ask <command>svn
@@ -886,31 +1046,60 @@
         specified, it assumes you are trying to perform one of the
         following common operations:</para>
 
+      <para>Una parola di avvertimento: anche se <command>svn diff</command> e
+        <command>svn merge</command> sono nel concetto molto simili, hanno
+        in molti casi la sintassi diversa.  Assicuratevi di leggere dettagli
+        nel Capitolo 9 o chiedete lumi a <command>svn help</command>.
+        Per esempio, <command>svn merge</command> richiede percorso
+        di copia di lavoro come destinazione, i.e. un posto dove può applicare
+        le modifiche della struttura,
+        it should apply the tree-changes.  Se la destinazione non è specificata,
+        assume che state provando di fare una delle seguenti comuni
+        operazioni:</para>
+
       <orderedlist>
         <listitem>
-          <para>You want to merge directory changes into your current
+          <para lang="en">You want to merge directory changes into your current
             working directory.</para>
+          <para>Volete fondere modifiche delle cartelle nella vostra
+            cartella di lavoro.</para>
         </listitem>
         <listitem>
-          <para>You want to merge the changes in a specific file into
-            a file by the same name which exists in your current working 
+          <para lang="en">You want to merge the changes in a specific file into
+            a file by the same name which exists in your current working
             directory.</para>
+          <para>Volete fondere le modifiche d'un file specifico
+            dentro un file con lo stesso nome che esiste nella vostra
+            cartella di lavoro.</para>
         </listitem>
       </orderedlist>
 
-      <para>If you are merging a directory and haven't specified a
+      <para lang="en">If you are merging a directory and haven't specified a
         target path, <command>svn merge</command> assumes the first case
         above and tries to apply the changes into your current
         directory.  If you are merging a file, and that file (or a file
         by the same name) exists in your current working directory,
         <command>svn merge</command> assumes the second case and tries
         to apply the changes to a local file with the same name.</para>
-      
-      <para>If you want changes applied somewhere else, you'll
+
+      <para>Se state fondendo una cartella e non avete specificato percorso
+        di destinazione, <command>svn merge</command> assume il primo caso
+        sopra e prova applicare le modifiche dentro vostra cartella attuale.
+        Se state fondendo un file e questo file (o un file con lo stesso nome)
+        esiste dentro vostra cartella attuale,
+        <command>svn merge</command> assume il secondo caso e prova
+        applicare le modifiche dentro file locale con lo stesso nome.</para>
+
+      <para lang="en">If you want changes applied somewhere else, you'll
         need to say so.  For example, if you're sitting in the parent
         directory of your working copy, you'll have to specify the
         target directory to receive the changes:</para>
-      
+
+      <para>Se volete applicare le modifiche in un altro posto, dovete dirlo.
+        Per esempio, se siete nella cartella parente della vostra copia di
+        lavoro, dovete specificare cartella destinazione per ricevere
+        le modifiche:</para>
+
       <screen>
 $ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk my-calc-branch
 U   my-calc-branch/integer.c
@@ -920,9 +1109,10 @@
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.copychanges.keyconcept">
-      <title>The Key Concept Behind Merging</title>
+<!--       <title>The Key Concept Behind Merging</title> -->
+      <title>Concetto chiave dietro ??Merging?</title>
 
-      <para>You've now seen an example of the <command>svn
+      <para lang="en">You've now seen an example of the <command>svn
           merge</command> command, and you're about to see several
           more.  If you're feeling confused about exactly how merging
           works, you're not alone.  Many users (especially those new
@@ -933,7 +1123,19 @@
           understanding exactly how <command>svn merge</command>
           behaves.</para>
 
-      <para>The main source of confusion is the
+        <para>Abbiamo visto un esempio di comando <command>svn
+            merge</command>, e stiamo per vedere di più.
+          Se vi sentite confusi riguardo come funziona esattamente
+          ??merging?, non siete soli. Molti utenti (specialmente
+          quelli nuovi a cotrollo delle versioni) rimangono inizialmente
+          perplessi riguardo la giusta sintassi del comando e come
+          e quando usare questa caratteristica.
+          ??But fear not?, questo comando è in verità molto più
+          semplice che si pensa. C'è una tecnica molto semplice
+          per capire esattamente come <command>svn merge</command>
+          ??behaves?.</para>
+
+      <para lang="en">The main source of confusion is the
         <emphasis>name</emphasis> of the command.  The term
         <quote>merge</quote> somehow denotes that branches are
         combined together, or that there's some sort of mysterious
@@ -943,25 +1145,40 @@
         two repository trees are compared, and the differences are
         applied to a working copy.</para>
 
-      <para>The command takes three arguments:</para>
+      <para>La fonte primaria della confusione è il
+        <emphasis>nome</emphasis> del comando.  Il termine
+        <quote>merge</quote>(fondere) qualche volta denota che i rami sono
+        combinati tra loro, oppure che ci sta qualche sorta di misterioso
+        ??blending of data going on?.  Non è il caso.  Più appropriato
+        nome per questo comando forse sarebbe
+        <command>svn diff-and-apply</command>(trova-differenze-e-applicale),
+        perché questo è tutto che accade: due strutture del deposito sono comparate
+        e le differenze sono applicate alla copia di lavoro.</para>
+
+      <para lang="en">The command takes three arguments:</para>
+      <para>Il comando prende tre argomenti:</para>
 
       <orderedlist>
 
-        <listitem><para>An initial repository tree (often called the
+        <listitem><para lang="en">An initial repository tree (often called the
         <firstterm>left side</firstterm> of the
-        comparison),</para></listitem>
+        comparison),</para><para>Una struttura del deposito iniziale (spesso chiamata il
+        <firstterm>lato sinistro</firstterm> della comparazione),</para></listitem>
 
-        <listitem><para>A final repository tree (often called the
+        <listitem><para lang="en">A final repository tree (often called the
         <firstterm>right side</firstterm> of the
-        comparison),</para></listitem>
+        comparison),</para><para>Una struttura del deposito finale (spesso chiamata il
+        <firstterm>lato destro</firstterm>  della comparazione),</para></listitem>
 
-        <listitem><para>A working copy to accept the differences as
+        <listitem><para lang="en">A working copy to accept the differences as
         local changes (often called the <firstterm>target</firstterm>
-        of the merge).</para></listitem>
-        
+        of the merge).</para><para>Una copia di lavoro per ricevere le differenze
+        come modifiche locali (spesso chiamata la <firstterm>destinazione</firstterm>
+        della fusione).</para></listitem>
+
       </orderedlist>
 
-      <para>Once these three arguments are specified, the two trees
+    <para lang="en">Once these three arguments are specified, the two trees
         are compared, and the resulting differences are applied to the
         target working copy as local modifications.  When the command
         is done, the results are no different than if you had
@@ -971,21 +1188,35 @@
         you don't like the results, you can simply <command>svn
         revert</command> all of the changes.</para>
 
-      <para>The syntax of <command>svn merge</command> allows you to
+    <para>Una volta specificati questi tre argomenti, le due strutture
+      sono comparate e le differenze risultanti sono applicate
+      alla copia di lavoro destinataria come midifiche locali.
+      Quando il comando finisce il suo lavoro, il risultato non è diverso
+      da come aveste editato i file manualmente o aveste da soli avviato
+      svariati comandi <command>svn add</command> o <command>svn delete</command>.
+      Se il risultato vi piace, potete fare commit. Se non vi piace,
+      con semplice comando <command>svn revert</command> scartate tutte le
+      modifiche.</para>
+
+      <para lang="en">The syntax of <command>svn merge</command> allows you to
         specify the three necessary arguments rather flexibly.  Here
         are some examples:</para>
 
-      <screen>      
+      <para>La sintassi di comando <command>svn merge</command> vi permete
+        di specificare i tre argomenti necessari in modo molto flessibile
+        Qui ci sono alcuni esempi:</para>
+
+      <screen>
 $ svn merge http://svn.example.com/repos/branch1@150 \
             http://svn.example.com/repos/branch2@212 \
             my-working-copy
-            
+
 $ svn merge -r 100:200 http://svn.example.com/repos/trunk my-working-copy
 
 $ svn merge -r 100:200 http://svn.example.com/repos/trunk
 </screen>
 
-      <para>The first syntax lays out all three arguments explicitly,
+      <para lang="en">The first syntax lays out all three arguments explicitly,
         naming each tree in the form <emphasis>URL at REV</emphasis> and
         naming the working copy target.  The second syntax can be used
         as a shorthand for situations when you're comparing two
@@ -993,17 +1224,26 @@
         how the working-copy argument is optional; if omitted, it
         defaults to the current directory.</para>
 
+      <para>La prima sintassi ??lays out? tutti e tre argomenti
+        esplicitamente, nominando ogni struttura in forma <emphasis>URL at REV</emphasis>
+        e nominando la copia di lavoro ricevente. La seconda sintassi
+        può essere usata, quando state comparando due versioni diverse
+        dello stesso URL. L'ultima sintassi mostra che argomento 'copia di lavoro'
+        è facoltativo; se omesso, il suo valore predefinito è la cartella
+        attuale.</para>
 
     </sect2>
-    
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.copychanges.bestprac">
-      <title>Best Practices for Merging</title>
+      <!--  <title>Best Practices for Merging</title> -->
+      <title>Regole d'arte per fusione</title>
 
       <sect3 id="svn.branchmerge.copychanges.bestprac.track">
-        <title>Tracking Merges Manually</title>
+        <!--  <title>Tracking Merges Manually</title> -->
+        <title>Tenere a mano traccia delle fusioni</title>
 
-        <para>Merging changes sounds simple enough, but in practice it
+        <para lang="en">Merging changes sounds simple enough, but in practice it
           can become a headache.  The problem is that if you
           repeatedly merge changes from one branch to another, you
           might accidentally merge the same change
@@ -1013,21 +1253,43 @@
           does nothing.  But if the already-existing change has been
           modified in any way, you'll get a conflict.</para>
 
-        <para>Ideally, your version control system should prevent the
+        <para>Fondere modifiche suona abbastanza semplice, ma in prattica
+          può diventare mal di testa.  Il problema è che se ripetutamente
+          fondete modifiche da un ramo ad altro, potete accidentalmente
+          fondere la stessa modifica <emphasis>due volte</emphasis>.
+          Se succede questo, a volte tutto va bene. Quando Subversion applica
+          le modifiche su un file, tipicamente si accorge che il file queste
+          modifiche ha già e non fa niente.  Ma se la già esistente modifica
+          era ulteriormente modificata, otente un conflitto.</para>
+
+        <para lang="en">Ideally, your version control system should prevent the
           double-application of changes to a branch.  It should
           automatically remember which changes a branch has already
           received, and be able to list them for you.  It should use
           this information to help automate merges as much as
           possible.</para>
 
-        <para>Unfortunately, Subversion is not such a system.  Like
+        <para>Idealmente, vostro sistema di controlo delle versioni
+          dovrebbe prevenire la doppia applicazione delle modifiche su un ramo.
+          Dovrebbe automaticamente ricordare quale modifiche il ramo ha già
+          ricevuto ed essere capace di elencarle per voi. Dovrebbe
+          usare queste informazioni per automatizzare le fusioni
+          quanto più possibile.</para>
+
+        <para lang="en">Unfortunately, Subversion is not such a system.  Like
           CVS, Subversion does not yet record any information about
           merge operations.  When you commit local modifications, the
           repository has no idea whether those changes came from
           running <command>svn merge</command>, or from just
           hand-editing the files.</para>
 
-        <para>What does this mean to you, the user?  It means that
+        <para>Sfortunatamente, un sistema così non è Subversion.  Come il
+          CVS, Subversion non memorizza ancora nessuna informazione riguardo
+          operazioni di fusioni.  Quando fatte commit delle modifiche locali,
+          il deposito non ha idea se queste modifiche arrivano da
+          <command>svn merge</command> eseguito o da editazione a mano dei file.</para>
+
+        <para lang="en">What does this mean to you, the user?  It means that
           until the day Subversion grows this feature, you'll have to
           track merge information yourself.  The best place to do this
           is in the commit log-message.  As demonstrated in the
@@ -1040,26 +1302,55 @@
           that won't be redundant with previously ported
           changes.</para>
 
-        <para>In the next section, we'll show some examples of this
+        <para>Che cosa significa questo per voi, utente?  Significa che
+          fino al giorno in cui Subversion avrà questa capacità,
+          dovete traccare informazioni riguardo le fusioni da soli.
+          Il posto migliore dove farlo è messaggio di commit.
+          Come era dimostrato nel esempi precedente, è raccomandato
+          che vostro messaggio manziona specifico numero della revisione
+          (o rango delle revisioni) che state fondendo nel vostro ramo.
+          In futuro potete avviare comando <command>svn log</command>
+          per vedere quale modifiche contiene già il vostro ramo.
+          Questo vi permete di costruire con cura prossimi comandi
+          <command>svn merge</command> che non saranno redundanti
+          con le modifiche già riportate in precedenza.</para>
+
+        <para lang="en">In the next section, we'll show some examples of this
           technique in action.</para>
 
+        <para>Nella prossima sezione mostreremo in azione alcuni esempi
+          di questa tecnica.</para>
+
       </sect3>
-      
+
       <sect3 id="svn.branchmerge.copychanges.bestprac.preview">
-        <title>Previewing Merges</title>
-        
-        <para>Because merging only results in local modifications,
+        <!-- <title>Previewing Merges</title> -->
+        <title>Anteprima delle fusioni</title>
+
+        <para lang="en">Because merging only results in local modifications,
           it's not usually a high-risk operation.  If you get the
           merge wrong the first time, simply <command>svn
-          revert</command> the changes and try again.</para>
-        
-        <para>It's possible, however, that your working copy might
+            revert</command> the changes and try again.</para>
+
+        <para>Perché risultato delle fusioni sono soltanto
+          le modifiche locali, questa non è normalmente una operazione
+          ad alto rischio.  Se vi capita di fondere male prima volta,
+          semplicemente buttate via le modifiche, <command>svn
+          revert</command> e provate di nuovo.</para>
+
+        <para lang="en">It's possible, however, that your working copy might
           already have local modifications.  The changes applied by a
           merge will be mixed with your pre-existing ones, and running
           <command>svn revert</command> is no longer an option.  The
           two sets of changes may be impossible to separate.</para>
 
-        <para>In cases like this, people take comfort in being able to
+        <para>È possibile, comunque, che vostra copia di lavoro contiene anche
+          le modifiche locali. Le modifiche applicate da merge saranno mischiate
+          tra le vostre e avviare comando <command>svn revert</command> non è
+          più un ascelta pratticabile.  Potrebbe essere impossibile separare
+          i due insiemi delle modifiche.</para>
+
+        <para lang="en">In cases like this, people take comfort in being able to
           predict or examine merges before they happen.  One simple
           way to do that is to run <command>svn diff</command> with
           the same arguments you plan to pass to <command>svn
@@ -1068,15 +1359,30 @@
           <option>--dry-run</option> option to the merge
           command:</para>
 
-        <screen>
+        <para>In casi come questo, le persone si confortano con la possibilità
+          di prevedere o esaminare fusione prima che accade. Un semplice
+          modo per farlo è avviare <command>svn diff</command>
+          con gli stessi argomenti che avete in mente di passare a
+          <command>svn merge</command>, come abbiamo già mostrato nel nostro
+          primo esempio. Altro metodo di anteprima è aggiungere la opzione
+          <option>--dry-run</option>(a secco) al comando merge:</para>
+
+<!--        <screen>
 $ svn merge --dry-run -r 343:344 http://svn.example.com/repos/calc/trunk
 U  integer.c
 
 $ svn status
 #  nothing printed, working copy is still unchanged.
+</screen>-->
+<screen>
+  $ svn merge --dry-run -r 343:344 http://svn.example.com/repos/calc/trunk
+  U  integer.c
+
+  $ svn status
+  # non stampa niente, copia di lavoro è ancora intatta.
 </screen>
 
-        <para>The <option>--dry-run</option> option doesn't actually
+        <para lang="en">The <option>--dry-run</option> option doesn't actually
           apply any local changes to the working copy.  It only shows
           status codes that <emphasis>would</emphasis> be printed in a
           real merge.  It's useful for getting a <quote>high
@@ -1084,12 +1390,20 @@
           times when running <command>svn diff</command> gives too
           much detail.</para>
 
+        <para>La opzione <option>--dry-run</option> in verità non applica
+          nessuna modifica locale alla copia di lavoro.  Mostra solo output
+          che <emphasis>sarebbe</emphasis> mostrato con la fusione vera.
+          Questo è utile per avere una previsione ad <quote>alto
+          livello</quote> della potenziale fusione, per quelle volte dove
+          comando <command>svn diff</command> dà troppi dettagli.</para>
+
       </sect3>
 
       <sidebar>
-        <title>Subversion and Changesets</title>
+        <!-- <title>Subversion and Changesets</title> -->
+        <title>Subversion e gli changeset</title>
 
-        <para>Everyone seems to have a slightly different definition
+        <para lang="en">Everyone seems to have a slightly different definition
           of <quote>changeset</quote>, or at least a different
           expectation of what it means for a version control system to
           have <quote>changeset features</quote>.  For our purpose,
@@ -1099,7 +1413,18 @@
           to metadata.  In more common speak, a changeset is just a
           patch with a name you can refer to.</para>
 
-        <para>In Subversion, a global revision number N names a tree
+        <para>Sembra che ciascuno ha la definizione degli
+           <quote>changeset</quote> legermente diversa, o almeno
+          diverse aspettative di che cosa significa per sistema
+          di controlo delle versioni avere <quote>capacità di changeset</quote>
+          (insieme delle modifiche). Per nostro scopo, diciamo che un
+          changeset è solo una collezione delle modifiche
+          con un nome unico.  Le modifiche possono includere editazioni testuali
+          del contenuto dei file, modificazioni della struttura o cambiamenti
+          dei metadati. In parole povere, un changeset è solo un
+          ??patch? con nome con quale portremo riferirsi ad esso.</para>
+
+        <para lang="en">In Subversion, a global revision number N names a tree
           in the repository: it's the way the repository looked after
           the Nth commit.  It's also the name of an implicit
           changeset: if you compare tree N with tree N-1, you can
@@ -1117,19 +1442,44 @@
           from one branch to another by naming them in the merge
           arguments: <command>svn merge -r9237:9238</command> would
           merge changeset #9238 into your working copy.</para>
+
+        <para>In Subversion, numero globale di versione N nomina una struttura
+          in deposito: modo in quale il deposito appare dopo Nessimo commit.
+          Ed è anche il nome di un implicito changeset: comparando struttura
+          N con struttura N-1, potete ricavare esatto ??patch? che era applicato.
+          Per questa ragione è semplice pensare <quote>revisione N</quote> non
+          solo come struttura ma nello stesso modo changeset. ##### If you use an issue
+          tracker to manage bugs, you can use the revision numbers to
+          refer to particular patches that fix bugs—for example,
+          <quote>this issue was fixed by revision 9238.</quote>.
+          Somebody can then run <command>svn log -r9238</command> to
+          read about the exact changeset which fixed the bug, and run
+          <command>svn diff -r9237:9238</command> to see the patch
+          itself.  And Subversion's <literal>merge</literal> command
+          also uses revision numbers.  You can merge specific changesets
+          from one branch to another by naming them in the merge
+          arguments: <command>svn merge -r9237:9238</command> would
+          merge changeset #9238 into your working copy.</para>
       </sidebar>
 
       <sect3 id="svn.branchmerge.copychanges.bestprac.merge">
-        <title>Merge Conflicts</title>
+        <!-- <title>Merge Conflicts</title> -->
+        <title>Conflitti delle fusioni</title>
 
-        <para>Just like the <command>svn update</command> command,
+        <para lang="en">Just like the <command>svn update</command> command,
           <command>svn merge</command> applies changes to your working
           copy.  And therefore it's also capable of creating
           conflicts.  The conflicts produced by <command>svn
-          merge</command>, however, are sometimes different, and this
+            merge</command>, however, are sometimes different, and this
           section explains those differences.</para>
 
-        <para>To begin with, assume that your working copy has no
+        <para>Così come comando <command>svn update</command>,
+          anche <command>svn merge</command> applica modifiche alla vostra
+          copia di lavoro. E perciò è capace generare conflitti. I conflitti
+          prodotti da <command>svn merge</command>, tuttavia, sono a volte
+          diversi e questa sezione spiega queste differenze.</para>
+
+        <para lang="en">To begin with, assume that your working copy has no
           local edits.  When you <command>svn update</command> to a
           particular revision, the changes sent by the server will
           always apply <quote>cleanly</quote> to your working copy.
@@ -1140,7 +1490,18 @@
           delta is guaranteed to correctly convert your working copy
           into the right-hand tree.</para>
 
-        <para>But <command>svn merge</command> has no such guarantees
+        <para>Per cominciare, si assume che vostra copia di lavoro
+          non ha editazioni locali. Quando la aggiornate (<command>svn update</command>)
+          ad una perticolare revisione, le modifiche mandate dal server
+          si applicano sempre alla vostra copia di lavoro in modo
+          <quote>pulito</quote>.
+          Il server produce un ??delta? comparando due strutture: un'instantanea
+          virtuale della vostra copia di lavoro e struttura della revisione a quale
+          siete interessati. Perché lato sinistra della comparazione è uguale
+          a quel che già avete il delta garantisce di dorrettamente convertire
+          vostra copia di lavoro nella struttura di lato destra.</para>
+
+        <para lang="en">But <command>svn merge</command> has no such guarantees
           and can be much more chaotic: the user can ask the server to
           compare <emphasis>any</emphasis> two trees at all, even ones
           that are unrelated to the working copy!  This means there's
@@ -1153,6 +1514,20 @@
           <quote>failed hunks</quote>, <command>svn merge</command>
           will complain about <quote>skipped targets</quote>:</para>
 
+        <para>Ma <command>svn merge</command> non ha tali garanzie
+          e può essere più caotico: utente può chidere al server di
+          comparare <emphasis>qualsiasi</emphasis> due strutture, anche
+          tali che non hanno nessun legame con la copia di lavoro.
+          Questo significa che qui c'è largo potenziale per errori umani.
+          Utenti possono a volte comparare due strutture sbagliate,
+          creando delta che non si applica pulitamente.
+          <command>svn merge</command> farà il meglio per applicare più
+          possibile il delta, ma su alcune parti questo potrà essere
+          impossibile. Nello stesso modo come comando Unix
+          <command>patch</command> a volte si lamenta di ??<quote>failed hunks</quote>?,
+          <command>svn merge</command> può accusare <quote>skipped targets</quote>
+          (destinazioni saltate):</para>
+
         <screen>
 $ svn merge -r 1288:1351 http://svn.example.com/repos/branch
 U  foo.c
@@ -1164,7 +1539,7 @@
 $
 </screen>
 
-        <para>In the previous example it might be the case that
+        <para lang="en">In the previous example it might be the case that
           <filename>baz.c</filename> exists in both snapshots of the
           branch being compared, and the resulting delta wants to
           change the file's contents, but the file doesn't exist in
@@ -1178,7 +1553,21 @@
           revert, and re-run <command>svn merge</command> with
           different arguments.</para>
 
-        <para>Also notice that the previous example shows a conflict
+        <para>Nel esempio precedente può essere caso che
+          <filename>baz.c</filename> esiste in entrambe instantanee del
+          ramo comparato e delta risultante vuole cambiare il contenuto del
+          file, ma il file non esiste nella copia di lavoro.
+          Qualunque sia causa, il messaggio
+          <quote>skipped</quote>(saltato) significa che
+          con alta probabilità utente sta comparando le strutture sbagliate;
+          questo è un segno classico del 'errore del conducente'.
+          Quando accade ciò, è semplice invertire ricorsivamente tutte le
+          modifiche create dalla fusione (<command>svn revert --recursive</command>),
+          cancellare ogni file o cartella rimasta senza controllo delle versioni
+          dopo revert e rifare <command>svn merge</command> con argomenti
+          diversi.</para>
+
+        <para lang="en">Also notice that the previous example shows a conflict
           happening on <filename>glorb.h</filename>.  We already
           stated that the working copy has no local edits: how can a
           conflict possibly happen?  Again, because the user can use
@@ -1187,7 +1576,16 @@
           changes that don't cleanly apply to a working file, even if
           the file has no local modifications.</para>
 
-        <para>Another small difference between <command>svn
+        <para>Notare ancora che precedente esempio mostra un conflitto
+          accaduto su <filename>glorb.h</filename>.  Abbiamo già stabilito
+          che copia di lavoro non ha editazioni locali: come può allora
+          accadere un conflitto?  Di nuovo, perché l'utente può usare
+          <command>svn merge</command> per definire ed applicare qualsiasi
+          delta vecchio a copia di lavoro, tale delta può contenere modifiche
+          testuali che non si applicano in modo pulito al file di lavoro,
+          anche se il file non ha le modifiche locali.</para>
+
+        <para lang="en">Another small difference between <command>svn
           update</command> and <command>svn merge</command> are the
           names of the full-text files created when a conflict
           happens.  In <xref linkend="svn.tour.cycle.resolve"/>, we saw
@@ -1206,19 +1604,45 @@
           update versus ones that happened as a result of a
           merge.</para>
 
+        <para>Altra piccola differenza tra <command>svn update</command> e
+          <command>svn merge</command> sono i nomi
+          dei file testuali creati quando accade un conflitto.
+          In <xref linkend="svn.tour.cycle.resolve"/>, abbiamo visto che
+          un aggiornamento (update) produce file nominati
+          <filename>filename.mine</filename>,
+          <filename>filename.rOLDREV</filename> e
+          <filename>filename.rNEWREV</filename>.  Quando comando <command>svn
+            merge</command> produce un conflitto, ??though?, crea
+          tre file nominati <filename>filename.working</filename>,
+          <filename>filename.left</filename> e
+          <filename>filename.right</filename>.  Qui i
+          termini <quote>left</quote> e <quote>right</quote> descrivono
+          da quale lato della comparazione delle strutture proviene il file.
+          In qualsiasi caso, questi nomi diversi vi aiuteranno
+          distinguere tra conflitti che accadono come risultato d'un
+          aggiornamento (update) e tali che accadono come risultato d'una
+          fusione (merge).</para>
+
       </sect3>
-      
+
       <sect3 id="svn.branchmerge.copychanges.bestprac.ancestry">
-        <title>Noticing or Ignoring Ancestry</title>
+        <!-- <title>Noticing or Ignoring Ancestry</title> -->
+        <title>Notare o ignorare ascendenza</title>
 
-        <para>When conversing with a Subversion developer, you might
+        <para lang="en">When conversing with a Subversion developer, you might
           very likely hear reference to the term
           <firstterm>ancestry</firstterm>.  This word is used to
           describe the relationship between two objects in a
           repository: if they're related to each other, then one
           object is said to be an ancestor of the other.</para>
 
-        <para>For example, suppose you commit revision 100, which
+        <para>Parlando con sviluppatori di Subversion, uno può
+          molto probabilmente sentire riferimento al termine
+          <firstterm>ascendenza</firstterm>(ancestry).  Questa parola è usata per
+          descrivere la relazione tra due oggetti nel deposito:
+          se sono in relazione si dice che uno è antenato dell'altro.</para>
+
+        <para lang="en">For example, suppose you commit revision 100, which
           includes a change to a file <filename>foo.c</filename>.
           Then <filename>foo.c at 99</filename> is an
           <quote>ancestor</quote> of <filename>foo.c at 100</filename>.
@@ -1231,7 +1655,20 @@
           different objects in the repository.  They share no history
           or <quote>ancestry</quote>.</para>
 
-        <para>The reason for bringing this up is to point out an
+        <para>Per esempio, supponiamo che voi depositate la versione 100,
+          che include una modifica a file <filename>foo.c</filename>.
+          Dopo questo il file <filename>foo.c at 99</filename> è un
+          <quote>antenato</quote> di <filename>foo.c at 100</filename>.
+          Caso oposto, supponiamo che depositate la cancellazione del
+          <filename>foo.c</filename> nella versione 101 e dopo aggiugete
+          nuovo file con lo stesso nome nella versione 102.  In questo caso,
+          <filename>foo.c at 99</filename> e
+          <filename>foo.c at 102</filename> possono apparire in relazione
+          (hanno lo stesso percorso e nome), ma in verità sono oggetti
+          del deposito completamente diversi. Non condividono nessuna storia
+          o <quote>ascendenza</quote>.</para>
+
+        <para lang="en">The reason for bringing this up is to point out an
           important difference between <command>svn diff</command> and
           <command>svn merge</command>.  The former command ignores
           ancestry, while the latter command is quite sensitive to it.
@@ -1244,12 +1681,25 @@
           delete the old file, then add the new file;  the output would
           indicate a deletion followed by an add:</para>
 
+        <para>La ragione per spiegare questo è di puntare il dito
+          sulla differenza importante tra <command>svn diff</command> e
+          <command>svn merge</command>.  Il primo comando ignora
+          ascendenza, invece il secondo è assai sensibile ad essa.
+          Per esempio, chiedendo a <command>svn diff</command> di
+          comparare revisioni 99 e 102 di <filename>foo.c</filename>,
+          potete vedere differenze basate sulle linee; il comando
+          <literal>diff</literal> ciecamente compara i due file.
+          Ma se chiedete a <command>svn merge</command> di comparare
+          gli stessi oggetti, lui si accorge che non sono in relazione
+          e prima provede a cancellare quello vecchio e poi aggiunge
+          nuovo; output indicherà una cancellazione seguita da una aggiunta:</para>
+
         <screen>
 D  foo.c
 A  foo.c
 </screen>
 
-        <para>Most merges involve comparing trees that are ancestrally
+        <para lang="en">Most merges involve comparing trees that are ancestrally
           related to one another, and therefore <command>svn
           merge</command> defaults to this behavior.  Occasionally,
           however, you may want the <literal>merge</literal> command to
@@ -1261,7 +1711,18 @@
           trees, you'd see the entire first tree being deleted,
           followed by an add of the entire second tree!</para>
 
-        <para>In these situations, you'll want <command>svn
+        <para>Molte fusioni coinvolgono comparazioni delle strutture che sono
+          genealogicamente relazionate tra loro, e perciò <command>svn
+            merge</command> ha come predefinito questo comportamento.  Occasionalmente,
+          tuttavia, si può volere che comando<literal>merge</literal> compara
+          due strutture che non sono in relazione.  Per esempio, si poò importare
+          due strutture del codice sorgente che rappresentano due rilasci pubblici
+          d'un progetto software (vedi <xref linkend="svn.advanced.vendorbr"/>).
+          Chiedendo a <command>svn merge</command> di comparare queste due strutture,
+          si vede prima la cancellazione completta della prima struttura,
+          seguita da aggiunta di tutta la seconda struttura!</para>
+
+        <para lang="en">In these situations, you'll want <command>svn
           merge</command> to do a path-based comparison only, ignoring
           any relations between files and directories.  Add the
           <option>--ignore-ancestry</option> option to your merge
@@ -1271,6 +1732,16 @@
           <command>svn diff</command> to behave like the
           <literal>merge</literal> command.)</para>
 
+        <para>In tale situazione, si chiede a <command>svn
+            merge</command> di fare comparazione basata solo sui nomi, ignorando
+          qualsiasi relazione tra i file e cartelle.  Si aggiunge opzione
+          <option>--ignore-ancestry</option> al vostro comando di fusione
+          command, a quello si comporterà esattamente come <command>svn
+            diff</command>.  (E al contrario, la opzione
+          <option>--notice-ancestry</option> causerà che
+          <command>svn diff</command> aggirà come comando
+          <literal>merge</literal>.)</para>
+
       </sect3>
 
     </sect2>
@@ -1282,17 +1753,23 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.branchmerge.commonuses">
-    <title>Common Use-Cases</title>
+    <!-- <title>Common Use-Cases</title> -->
+    <title>Casi di uso comuni</title>
 
-    <para>There are many different uses for branching and <command>svn
+    <para lang="en">There are many different uses for branching and <command>svn
       merge</command>, and this section describes the most common ones
       you're likely to run into.</para>
 
+    <para>Ci sono molti usi diversi per ramificazione e fusione(<command>svn
+        merge</command>) e questa sezione descrive i più comuni tra essi, che
+      probabilmente potete incontrare.</para>
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.commonuses.wholebr">
-      <title>Merging a Whole Branch to Another</title>
+      <!-- <title>Merging a Whole Branch to Another</title> -->
+      <title>Fondere ramo intero nel altro</title>
 
-      <para>To complete our running example, we'll move forward in
+      <para lang="en">To complete our running example, we'll move forward in
         time.  Suppose several days have passed, and many changes have
         happened on both the trunk and your private branch.  Suppose
         that you've finished working on your private branch; the
@@ -1300,7 +1777,16 @@
         merge all of your branch changes back into the trunk for
         others to enjoy.</para>
 
-      <para>So how do we use <command>svn merge</command> in this
+      <para>Per complettare nostro esempio in corso, ci moviamo avanti
+        nel tempo. Supponiamo che sono passati diversi giorni, e sono
+        accadute molte modifiche su tutte e due strutture, il tronco
+        e vostro ramo privato.  Supponiamo che avete finito il lavoro
+        su vostro ramo privato; nuova caratteristica o riparazione del bug
+        è finalmente completta e adesso volete fondere tutte le modifiche
+        del vostro ramo dietro tronco, così che gl'altri possono
+        assaporarle.</para>
+
+      <para lang="en">So how do we use <command>svn merge</command> in this
         scenario?  Remember that this command compares two trees, and
         applies the differences to a working copy.  So to receive the
         changes, you need to have a working copy of the trunk.  We'll
@@ -1308,19 +1794,39 @@
         around (fully updated), or that you recently checked out a
         fresh working copy of <filename>/calc/trunk</filename>.</para>
 
-      <para>But which two trees should be compared?  At first glance,
+      <para>Allora, come usiamo <command>svn merge</command> in questo
+        scenario?  Ricordate che questo comando compara due strutture ed
+        applica le differenze alla copia di lavoro.  Perciò per scoprire
+        le modifiche, avete bisogno della copia di lavoro del tronco.
+        Assumiamo che o avete ancora quella originale da qualche parte
+        (complettamente aggiornata) o che di recente avete tirato fuori
+        (checkout) una fresca copia di <filename>/calc/trunk</filename>.</para>
+
+      <para lang="en">But which two trees should be compared?  At first glance,
         the answer may seem obvious: just compare the latest trunk
         tree with your latest branch tree.  But beware—this
         assumption is <emphasis>wrong</emphasis>, and has burned many
         a new user!  Since <command>svn merge</command> operates like
-        <command>svn diff</command>, comparing the latest trunk and 
+        <command>svn diff</command>, comparing the latest trunk and
         branch trees will <emphasis>not</emphasis> merely describe
         the set of changes you made to your branch.  Such a comparison
         shows too many changes: it would not only show the addition of
         your branch changes, but also the <emphasis>removal</emphasis>
         of trunk changes that never happened on your branch.</para>
 
-      <para>To express only the changes that happened on your branch,
+      <para>Ma quale due strutture devono essere comparate?  A primo sguardo,
+        la risposta sembra ovvia: comparare l'ultima struttura di tronco
+        con l'ultima del ramo.  Ferma!—questa
+        ??assunzione? è <emphasis>sbagliata</emphasis>, e ha bruciato molti
+        principianti! Perché <command>svn merge</command> opera come
+        <command>svn diff</command>, comparare le ultime strutture
+        di tronco e ramo <emphasis>non</emphasis> descriverà soltanto
+        l'insieme delle modifiche fatte sul ramo.  Comparazione come questa
+        mostra trope modifiche: mostrerebbe non solo le agguinte delle
+        vostre modifiche del ramo, ma anche le <emphasis>rimozioni</emphasis>
+        delle modifiche del tronco che non sono mai accadute su vostro ramo.</para>
+
+      <para lang="en">To express only the changes that happened on your branch,
         you need to compare the initial state of your branch to its
         final state.  Using <command>svn log</command> on your branch,
         you can see that your branch was created in revision 341.  And
@@ -1330,8 +1836,17 @@
         branch directory, and apply those differences to a working
         copy of the trunk.</para>
 
+      <para>Per scoprire solo le modifiche che son accadute nel vostro ramo,
+        dovete comparare lo stato iniziale del ramo con il suo stato finale.
+        Usando <command>svn log</command> sul vostro ramo,
+        potete vedere che vostro ramo era stato creato nella versione 341.
+        E lo stato finale è semplicemente ??a matter of? usare la versione
+        <literal>HEAD</literal>.  Questo significa che dovete comparare versione
+        341 e <literal>HEAD</literal> della cartella del vostro ramo
+        e applicare quelle differenze all copia di lavoro del tronco.</para>
+
       <tip>
-        <para>A nice way of finding the revision in which a branch was
+        <para lang="en">A nice way of finding the revision in which a branch was
           created (the <quote>base</quote> of the branch) is to use the
           <option>--stop-on-copy</option> option to <command>svn
           log</command>.  The log subcommand will normally show every
@@ -1342,7 +1857,19 @@
           as <command>svn log</command> detects that its target was
           copied or renamed.</para>
 
-        <para>So in our continuing example,</para>
+        <para>Un bel modo per trovare la versione nella quale era stato
+          creato un ramo (la <quote>base</quote> del ramo) è usare opzione
+          <option>--stop-on-copy</option> nel <command>svn
+            log</command>.  Sottocomando log normalmente mostrerà ogni cambiamento
+          fatto sul ramo, andando dietro anche prima della copiatura che
+          ha creato il ramo. Così normalmente, vedremmo anche la parte della
+          storia dal tronco. Lo <option>--stop-on-copy</option> fermerà
+          output di log appena <command>svn log</command> scopre che il suo
+          bersaglio era copiato o rinominato.</para>
+
+        <para lang="en">So in our continuing example,</para>
+
+        <para>Così nel nostro esempi continuo,</para>
 
         <screen>
 $ svn log --verbose --stop-on-copy \
@@ -1355,14 +1882,18 @@
 
 $
 </screen>
-        
-        <para>As expected, the final revision printed by this command
+
+        <para lang="en">As expected, the final revision printed by this command
           is the revision in which <filename>my-calc-branch</filename>
           was created by copying.</para>
+        <para>Come aspettato, l'ultima versione stampata da questo comando
+          è la versione in cui <filename>my-calc-branch</filename>
+          era stato creato copiandolo.</para>
       </tip>
 
 
-      <para>Here's the final merging procedure, then:</para>
+      <para lang="en">Here's the final merging procedure, then:</para>
+      <para>Qui c'è la procedura di fusione finale, ??then?:</para>
 
       <screen>
 $ cd calc/trunk
@@ -1389,12 +1920,17 @@
 Committed revision 406.
 </screen>
 
-      <para>Again, notice that the commit log message very
+      <para lang="en">Again, notice that the commit log message very
         specifically mentions the range of changes that was merged
         into the trunk.  Always remember to do this, because it's
         critical information you'll need later on.</para>
 
-      <para>For example, suppose you decide to keep working on your
+      <para>Di nuovo, notare che messaggio di commit menziona molto
+        specificamente intervallo delle modifiche che sono state
+        fuse nel tronco.  Ricordate sempre di farlo, perché più tardi avrete bisogno
+        di questa critica informazione.</para>
+
+      <para lang="en">For example, suppose you decide to keep working on your
         branch for another week, in order to complete an enhancement
         to your original feature or bug fix.  The repository's
         <literal>HEAD</literal> revision is now 480, and you're ready
@@ -1405,10 +1941,23 @@
         branch since the last time you merged.  The trick is to figure
         out what's new.</para>
 
-      <para>The first step is to run <command>svn log</command> on the
+      <para>Per esempio, supponiamo che decidete di proseguire lavoro
+        sul vostro ramo per altra settimana, onde complettare un miglioramento
+        alla vostra caratteristica o bugfix.  La versione
+        <literal>HEAD</literal> del deposito è adesso 480, e voi siete pronti
+        a fare altra fusione dal vostro ramo privato al tronco.
+        Ma come era discusso in <xref linkend="svn.branchmerge.copychanges.bestprac"/>,
+        non volete fondere le modifiche che avevate già fuso prima; volete solo
+        fondere tutto il <quote>nuovo</quote> dal vostro ramo
+        a partire dalla ultima fusione.  Il trucco sta nel scoprire che cosa è 'il nuovo'.</para>
+
+      <para lang="en">The first step is to run <command>svn log</command> on the
         trunk, and look for a log message about the last time you
         merged from the branch:</para>
 
+      <para>Il primo passo è avviare <command>svn log</command> su tronco
+        e cercare messaggio riguardo l'ultima fusione dal ramo:</para>
+
       <screen>
 $ cd calc/trunk
 $ svn log
@@ -1420,13 +1969,18 @@
 ------------------------------------------------------------------------
 …
 </screen>
-      
-      <para>Aha!  Since all branch-changes that happened between
+
+      <para lang="en">Aha!  Since all branch-changes that happened between
         revisions 341 and 405 were previously merged to the trunk as
         revision 406, you now know that you want to merge only the
         branch changes after that—by comparing revisions 406 and
         <literal>HEAD</literal>.</para>
 
+      <para>Aha!  Poiché tutte modifiche del ramo che sono state fatte
+        tra le versioni 341 e 405 erano già precedentemente fuse nel tronco,
+        sapete adesso che volete fondere solo cambiamenti del ramo fatte
+        dopo—comparando versioni 406 e <literal>HEAD</literal>.</para>
+
       <screen>
 $ cd calc/trunk
 $ svn update
@@ -1447,19 +2001,26 @@
 Committed revision 481.
 </screen>
 
-      <para>Now the trunk contains the complete second wave of changes
+      <para lang="en">Now the trunk contains the complete second wave of changes
         made to the branch.  At this point, you can either delete your
         branch (we'll discuss this later on), or continue working on
         your branch and repeat this procedure for subsequent
         merges.</para>
 
+      <para>Adesso il tronco contiene la completta seconda ondata delle
+        modifiche fatte sul ramo. A questo punto, potete o cancellare
+        vostro ramo (discutteremmo questo più avanti), o continuare lavoro
+        su vostro ramo e ripetere questa procedura con le fusioni
+        venture.</para>
+
     </sect2>
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.commonuses.undo">
-      <title>Undoing Changes</title>
+      <!-- <title>Undoing Changes</title> -->
+      <title>Disfare i cambiamenti</title>
 
-      <para>Another common use for <command>svn merge</command> is to
+      <para lang="en">Another common use for <command>svn merge</command> is to
         roll back a change that has already been committed.  Suppose
         you're working away happily on a working copy of
         <filename>/calc/trunk</filename>, and you discover that the
@@ -1471,6 +2032,18 @@
         repository.  All you need to do is to specify a
         <emphasis>reverse</emphasis> difference:</para>
 
+      <para>Altro uso comune per <command>svn merge</command> è di
+        riavvolgere dietro (disfare) le modifiche che sono state
+        già depositate. Supponiamo che state proseguendo beatamente lavori
+        sulla copia di lavoro del <filename>/calc/trunk</filename>,
+        e avete scoperto che la modifica fatta nella versione 303,
+        che ha cambiato <filename>integer.c</filename>, è complettamente
+        sbagliata.  Non doveva essere mai depositata. Potete usare
+        <command>svn merge</command> per <quote>disfare</quote> la
+        modifica nella vostra copia e dopo depositare la modifica locale.
+        Tutto di cui avete bisogno è specificare la diffrenza
+        <emphasis>rovesciata</emphasis>:</para>
+
 
       <screen>
 $ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
@@ -1490,7 +2063,7 @@
 Committed revision 350.
 </screen>
 
-      <para>One way to think about a repository revision is as a
+      <para lang="en">One way to think about a repository revision is as a
         specific group of changes (some version control systems call
         these <firstterm>changesets</firstterm>).  By using the
         <option>-r</option> switch, you can ask <command>svn
@@ -1499,8 +2072,18 @@
         change, we're asking <command>svn merge</command> to apply
         changeset #303 to our working copy
         <emphasis>backwards</emphasis>.</para>
-    
-      <para>Keep in mind that rolling back a change like this is just
+
+      <para>Un modo di pensare alle versioni del deposito è
+        come allo specifico gruppo delle modifiche (alcuni sistemi di controllo
+        delle versioni li chiamano <firstterm>changeset</firstterm>).
+        Usando ??switch? <option>-r</option>, potete chiedere a
+        <command>svn merge</command> di applicare un changeset, o tutto intervallo di
+        changeset, alla vostra copia di lavoro.  Nel nostro caso di disfare
+        cambiamenti, stiamo chiedendo a <command>svn merge</command>
+        di applicare changeset nr.303 sulla nostra copia di lavoro
+        <emphasis>al rovescio</emphasis>.</para>
+
+      <para lang="en">Keep in mind that rolling back a change like this is just
         like any other <command>svn merge</command> operation, so you
         should use <command>svn status</command> and <command>svn
         diff</command> to confirm that your work is in the state you
@@ -1509,13 +2092,26 @@
         committing, this particular changeset is no longer reflected
         in the <literal>HEAD</literal> revision.</para>
 
-      <para>Again, you may be thinking: well, that really didn't undo
+      <para>Tenete in mente che disfare (riavvolgere dietro) una modifica
+        è come ogni altra operazione <command>svn merge</command>, così
+        dovete usare <command>svn status</command> e <command>svn
+          diff</command> per confermare che vostro lavoro è nello stato voluto,
+        e poi usare <command>svn commit</command> per spedire la versione finale
+        al deposito. Dopo deposizione quello particolare changeset non è più
+        presente nella versione <literal>HEAD</literal>.</para>
+
+      <para lang="en">Again, you may be thinking: well, that really didn't undo
         the commit, did it?  The change still exists in revision 303.
         If somebody checks out a version of the
         <filename>calc</filename> project between revisions 303 and
         349, they'll still see the bad change, right?</para>
 
-      <para>Yes, that's true.  When we talk about
+      <para>Di nuovo, potete pensare: Insomma, questo in verità non disfa
+        una deposizione, dico bene? La modifica ancora esiste nella versione 303.
+        Se qualcuno tira fuori una versione di progetto <filename>calc</filename>
+        tra versioni 303 e 349, può ancora vedere la modifica errata, vero?</para>
+
+      <para lang="en">Yes, that's true.  When we talk about
         <quote>removing</quote> a change, we're really talking about
         removing it from <literal>HEAD</literal>.  The original change
         still exists in the repository's history.  For most
@@ -1540,20 +2136,53 @@
         </footnote>
       </para>
 
+      <para>Sì, questo è vero.  Quando abbiamo parlato di
+        <quote>rimuovere</quote> una modifica, in verità abbiamo parlato
+        di rimuoverla dalla versione <literal>HEAD</literal>.
+        Il cambiamento originale ancora esiste nella storia del deposito.
+        Per la maggioranza delle situazioni questo basta. Tanto molte persone
+        sono interessate solo di usare <literal>HEAD</literal> del progetto.
+        Ci sono, comunque, casi speciali, in cui veramente volete distruggere
+        ogni traccia della deposizione avvenuta (Magari qualcuno ha
+        accidentalmente pubblicato un documento riservato.)
+        Si scopre che non è così facile, perché Subversion era stato
+        volutamente disegnato per non perdere mai le informazioni.
+        Versioni sono strutture ad albero immutabili basati una sull'altra.
+        Togliendo una revisione dalla storia può causare un effetto domino,
+        creando chaos in tutte le subsequenti versioni e possibilmente
+        invalidare tutte le copie di lavoro.
+        <footnote>
+          <para>Progetto Subversion pianifica tuttavia di implementare
+            un giorno il comando <command>svnadmin obliterate</command>
+            che può accontentare una richiesta della cancellazione
+            permanente. Ma prima ciò accada, vedi
+            <xref linkend="svn.reposadmin.maint.tk.svndumpfilter"/>
+            per possibile raggiro.</para>
+        </footnote>
+      </para>
+
     </sect2>
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.commonuses.resurrect">
-      <title>Resurrecting Deleted Items</title>
+      <!-- <title>Resurrecting Deleted Items</title> -->
+      <title>Risuscitare elementi cancellati</title>
 
-      <para>The great thing about version control systems is that
+      <para lang="en">The great thing about version control systems is that
         information is never lost.  Even when you delete a file or
         directory, it may be gone from the <literal>HEAD</literal>
         revision, but the object still exists in earlier revisions.
         One of the most common questions new users ask is, <quote>How
         do I get my old file or directory back?</quote>.</para>
 
-      <para>The first step is to define exactly <emphasis
+     <para>La cosa grande nei sistemi di controllo delle versioni è
+       che la informazione non si perde mai.  Addirittura quando cancellate
+       un file o cartella, può sparire dalla versione <literal>HEAD</literal>,
+       ma l'elemento sempre esiste nelle versioni precedenti.
+       Una delle più comuni domande degli nuovi utenti è <quote>Come posso
+       riavere mio vecchio file o cartella?</quote>.</para>
+
+      <para lang="en">The first step is to define exactly <emphasis
         role="bold">which</emphasis> item you're trying to resurrect.
         Here's a useful metaphor: you can think of every object in the
         repository as existing in a sort of two-dimensional coordinate
@@ -1562,7 +2191,16 @@
         every version of your file or directory can be defined by a
         specific coordinate pair.</para>
 
-      <para>Subversion has no <filename>Attic</filename> directory
+      <para>Il primo passo è di definire precisamente <emphasis
+        role="bold">quale</emphasis> elemento state provando di
+        risuscitare. Qui c'è una utile metafora: potete pensare
+        ad ogni oggetto del deposito come essistesse in una sorta
+        di spazio bidimensionale. La prima coordinata è la particolare
+        versione e la seconda è il percorso e nome dentro questa versione.
+        Così ogni versione del vostro file o cartella può essere
+        definita da una copia di coordinate specifica.</para>
+
+      <para lang="en">Subversion has no <filename>Attic</filename> directory
         like CVS does,
         <footnote>
           <para>Because CVS doesn't version trees, it creates an
@@ -1580,6 +2218,24 @@
         to examine the log output (via <command>grep</command>, or
         perhaps via an incremental search in an editor).</para>
 
+      <para>Subversion no ha cartella <filename>Attic</filename>
+        come la tiene CVS,
+        <footnote>
+          <para>Perché CVS non fa le versioni delle strutture, crea una
+            area <filename>Attic</filename> in ogni cartella del deposito
+            come modo di ricordare i file cancellati.</para>
+        </footnote>
+        e perciò dovete usare <command>svn log</command> per scoprire
+        la copia esatta di coordinate del elemento da risuscitare.
+        Una strategia buona è di avviare <command>svn log --verbose</command>
+        nella cartella che abitulamente conteneva vostro elemento cancellato.
+        La opzione <option>--verbose</option> mostra la lista di tutte le
+        modifiche in ogni versione; tutto di cui avete bisogno è trovare
+        versione in cui l'elemento era stato cancellato. Potete farlo a vista
+        o usando qualche strumento per essaminare output di log
+        (tramite <command>grep</command>, o forse con una ricerca incrementale
+        in un editore).</para>
+
       <screen>
 $ cd parent-dir
 $ svn log --verbose
@@ -1595,7 +2251,7 @@
 …
 </screen>
 
-      <para>In the example, we're assuming that you're looking for a
+      <para lang="en">In the example, we're assuming that you're looking for a
         deleted file <filename>real.c</filename>.  By looking through
         the logs of a parent directory, you've spotted that this file
         was deleted in revision 808.  Therefore, the last version of
@@ -1604,11 +2260,22 @@
         <filename>/calc/trunk/real.c</filename> from revision
         807.</para>
 
-      <para>That was the hard part—the research.  Now that you
+      <para>Nel esempio abbiamo assunto che state cercando file cancellato
+        <filename>real.c</filename>.  Scorrendo tra log della sua
+        cartella parente, avete scoperto che questo file era stato cancellato
+        nella versione 808. In consequenza, l'ultima versione che lo
+        contiene è quella subito prima. Conclusione: dovete risuscitare
+        <filename>/calc/trunk/real.c</filename> della versione
+        807.</para>
+
+      <para lang="en">That was the hard part—the research.  Now that you
         know what you want to restore, you have two different
         choices.</para>
-      
-      <para>One option is to use <command>svn merge</command> to apply
+
+      <para>Quella era la parte dura—la ricerca.  Adesso che sappiamo
+        che cosa riprendere, abbiamo due diverse scelte.</para>
+
+      <para lang="en">One option is to use <command>svn merge</command> to apply
         revision 808 <quote>in reverse</quote>.  (We've already
         discussed how to undo changes, see <xref
         linkend="svn.branchmerge.commonuses.undo"/>.)  This would have the effect of
@@ -1616,7 +2283,15 @@
         The file would be scheduled for addition, and after a commit,
         the file would again exist in <literal>HEAD</literal>.</para>
 
-      <para>In this particular example, however, this is probably not
+      <para>Una opzione è usare <command>svn merge</command> per applicare
+        versione 808 <quote>al rovescio</quote>.  (Abbiamo già discusso
+        come disfare le modifiche, vedi <xref
+        linkend="svn.branchmerge.commonuses.undo"/>.)  Questo potrebbe
+        avere effetto di ri-aggiungere <filename>real.c</filename>
+        come una modifica locale. Il file sarà pianificato per aggiunta
+        e dopo deposizione essisterà di nuovo nel <literal>HEAD</literal>.</para>
+
+      <para lang="en">In this particular example, however, this is probably not
         the best strategy.  Reverse-applying revision 808 would not
         only schedule <filename>real.c</filename> for addition, but
         the log message indicates that it would also undo certain
@@ -1627,12 +2302,29 @@
         scale well.  What if there were 90 files changed in revision
         808?</para>
 
-      <para>A second, more targeted strategy is not to use
+      <para>In questo esempio particolare, ??however?, questa probabilmente
+        non è la strategia migliore.  Applicazione al rovescio
+        della versione 808 non solo pianificherà <filename>real.c</filename>
+        per aggiunta, ma il messagio di log indica che disfarà anche
+        certe modifiche del file <filename>integer.c</filename>, ciò che
+        non vogliamo.  Naturalmente, potete fare fusione al rovescio
+        di versione 808 e dopo disfare modifiche locali del file
+        <filename>integer.c</filename> con <command>svn revert</command>,
+        ma questa tecnica non si adatta bene al aumento del lavoro.
+        Cosa fare se ci fossero 90 file modificati nella versione 808?</para>
+
+      <para lang="en">A second, more targeted strategy is not to use
         <command>svn merge</command> at all, but rather the
         <command>svn copy</command> command.  Simply copy the exact
         revision and path <quote>coordinate pair</quote> from the
         repository to your working copy:</para>
 
+      <para>Una seconda strategia, più mirata, è di non usare del tutto
+        <command>svn merge</command>, ma invece il comando
+        <command>svn copy</command>.  Semplicemete copiate esatte
+        <quote>coordinate</quote> (revisone e percorso-nome)
+        dal deposito alla vostra copia di lavoro:</para>
+
       <screen>
 $ svn copy --revision 807 \
            http://svn.example.com/repos/calc/trunk/real.c ./real.c
@@ -1646,7 +2338,7 @@
 Committed revision 1390.
 </screen>
 
-      <para>The plus sign in the status output indicates that the item
+      <para lang="en">The plus sign in the status output indicates that the item
         isn't merely scheduled for addition, but scheduled for
         addition <quote>with history</quote>.  Subversion remembers
         where it was copied from.  In the future, running <command>svn
@@ -1656,17 +2348,32 @@
         <filename>real.c</filename> isn't really new; it's a direct
         descendant of the original, deleted file.</para>
 
-      <para>Although our example shows us resurrecting a file, note
+      <para>Il segno più nel output di status indica che l'elemento
+        non è solo pianificato per aggiunta, ma per aggiunta
+        <quote>con storico</quote>.  Subversion si ricorda
+        da dove era stato copiato.  In futuro, usando <command>svn
+          log</command> su di questo file attraversiammo dietro la sua
+        resurrezione e vedremmo tutta la sua storia che aveva prima della versione
+        807.  In altre parole, questo nuovo
+        <filename>real.c</filename> non è veramente nuovo; è un discendente
+        diretto dell'file originale cancellato.</para>
+
+      <para lang="en">Although our example shows us resurrecting a file, note
         that these same techniques work just as well for resurrecting
         deleted directories.</para>
 
+      <para>Nonostante nostro esempio ci mostra resurrezione di un file, notare
+        che la stessa tecnica serve anche per resurrezione delle cartelle
+        cancellate.</para>
+
     </sect2>
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.commonuses.patterns">
-      <title>Common Branching Patterns</title>
+      <!-- <title>Common Branching Patterns</title> -->
+      <title>Tipi comuni di ramificazione</title>
 
-      <para>Version control is most often used for software
+      <para lang="en">Version control is most often used for software
         development, so here's a quick peek at two of the most common
         branching/merging patterns used by teams of programmers.  If
         you're not using Subversion for software development, feel
@@ -1677,11 +2384,26 @@
         Subversion; they're applicable to any version control system.
         Still, it may help to see them described in Subversion
         terms.</para>
-      
+
+      <para>Controllo delle versioni è molto spesso usato per sviluppo
+        del software, così abbiamo qui ??a quick peek? di due più comuni
+        archetipi di ramificazione usati dai team di programmatori.
+        Se non usate Subversion per sviluppo di software, sentitevi liberi
+        di saltare questa sezione.[alternativa: Se non
+        è il vostro caso, potete tranquilmente saltare questa sezione.]
+        Se siete sviluppatore di software alle prime armi con l'uso di
+        controllo delle versioni, prestate molta attenzione,
+        perché questi archetipi sono spesso considerati regola d'arte
+        dalla gente esperta [alternativa: gente con le OO (nooo, troppo volgare)].
+        Queste procedure non sono specifiche di Subversion; sono applicabili
+        a qualsiasi sistema di controllo delle versioni. Tuttavia,
+        può essere d'aiuto vederle descritte in termini di Subversion.</para>
+
       <sect3 id="svn.branchmerge.commonuses.patterns.release">
-        <title>Release Branches</title>
-      
-        <para>Most software has a typical lifecycle: code, test,
+        <!-- <title>Release Branches</title> -->
+        <title>Rami di rilascio</title>
+
+        <para lang="en">Most software has a typical lifecycle: code, test,
           release, repeat.  There are two problems with this process.
           First, developers need to keep writing new features while
           quality-assurance teams take time to test supposedly-stable
@@ -1693,32 +2415,59 @@
           that bugfix without having to wait for a major new
           release.</para>
 
-        <para>Here's where version control can help.  The typical
+        <para>Molti software hanno un tipico ciclo di vita: scrittura, test,
+          rilascio; ripetere.  Ci sono due problemi con questo processo.
+          Prima, sviluppatori devono continuare a scrivere nuove funzioni
+          mentre i team di controllo di qualità prendono tempo per testare
+          presunte stabili versioni del software.  Nuovo lavoro non si può
+          fermare mentre si fanno i test. Secondo, il team quasi sempre
+          deve fornire supporto per vecchie, già rilasciate versioni del
+          software; quando si scopre un errore nel codice nuovo, con
+          molta probabilità esiste anche nelle versioni rilasciate
+          e i clienti vogliono avere questi bug risolti senza aspettare
+          rilascio della nuova versione.</para>
+
+        <para lang="en">Here's where version control can help.  The typical
           procedure looks like this:</para>
 
+        <para>Ed è qui che controllo delle versioni può aiutare. La tipica procedura
+          assomiglia a questo:</para>
+
       <itemizedlist>
 
         <listitem>
-          <para><emphasis>Developers commit all new work to the
+          <para lang="en"><emphasis>Developers commit all new work to the
                 trunk.</emphasis>
 
               Day-to-day changes are committed to
               <filename>/trunk</filename>: new features, bugfixes, and
               so on.</para>
+            <para><emphasis>Sviluppatori fanno commit di tutto lavoro nuovo
+                nel tronco.</emphasis>
+
+              Giorno dopo giorno modifiche sono pubblicate nel
+              <filename>/trunk</filename>: nuove capacità, fix dei bug e così
+              via.</para>
         </listitem>
 
         <listitem>
-          <para><emphasis>The trunk is copied to a
+          <para lang="en"><emphasis>The trunk is copied to a
                 <quote>release</quote> branch.</emphasis>
 
               When the team thinks the software is ready for release
               (say, a 1.0 release), then <filename>/trunk</filename>
               might be copied to
               <filename>/branches/1.0</filename>.</para>
+          <para><emphasis>Il tronco è copiato nel ramo
+              <quote>rilascio</quote>.</emphasis>
+
+            Quando il team pensa che il software è pronto per rilascio
+            (diciamo, una vers. 1.0), il <filename>/trunk</filename>
+            può essere copiato su <filename>/branches/1.0</filename>.</para>
         </listitem>
 
         <listitem>
-          <para><emphasis>Teams continue to work in parallel.</emphasis>
+          <para lang="en"><emphasis>Teams continue to work in parallel.</emphasis>
 
               One team begins rigorous testing of the release branch,
               while another team continues new work (say, for version
@@ -1727,20 +2476,35 @@
               forth as necessary.  At some point, however, even that
               process stops.  The branch is <quote>frozen</quote> for
               final testing right before a release.</para>
+         <para><emphasis>I team continuarono lavorare in parallelo.</emphasis>
+
+              Un team comincia rigorosi test del ramo rilascio,
+              mentre altro team continua nuovo lavoro (diciamo per la versione
+              2.0) su <filename>/trunk</filename>.  Quando si scoprono i bug
+              in entrambi locazioni, correzioni sono portate avanti e dietro
+              secondo la necessità.  Ad un certo punto, comunque, anche questo
+              processo si ferma.  Il ramo è <quote>congelato</quote> per
+              test finale subito prima del rilascio.</para>
         </listitem>
-          
+
         <listitem>
-          <para><emphasis>The branch is tagged and released.</emphasis>
+          <para lang="en"><emphasis>The branch is tagged and released.</emphasis>
 
               When testing is complete,
               <filename>/branches/1.0</filename> is copied to
               <filename>/tags/1.0.0</filename> as a reference
               snapshot.  The tag is packaged and released to
               customers.</para>
+         <para><emphasis>Il ramo è targato e rilasciato.</emphasis>
+
+              Quando i test sono completati,
+              <filename>/branches/1.0</filename> è copiato su
+              <filename>/tags/1.0.0</filename> come instantanea di riferimento.
+              Ramo targato è impachettato e rilasciato ai clienti.</para>
         </listitem>
 
         <listitem>
-          <para><emphasis>The branch is maintained over time.</emphasis>
+          <para lang="en"><emphasis>The branch is maintained over time.</emphasis>
 
               While work continues on <filename>/trunk</filename> for
               version 2.0, bugfixes continue to be ported from
@@ -1750,23 +2514,41 @@
               1.0.1 release: <filename>/branches/1.0</filename> is
               copied to <filename>/tags/1.0.1</filename>, and the tag
               is packaged and released.</para>
+            <para><emphasis>Il ramo è mantenuto durante il tempo.</emphasis>
+
+              Mentre lavoro continua su <filename>/trunk</filename> per
+              la versione 2.0, i bugfix continuano ad essere portati da
+              <filename>/trunk</filename> a
+              <filename>/branches/1.0</filename>.  Quando si accumulano abbastanza
+              correzioni, i capi possono decidere di rilasciare
+              vers. 1.0.1: <filename>/branches/1.0</filename> è
+              copiato su <filename>/tags/1.0.1</filename>, la targa
+              è impachettata e rilasciata.</para>
         </listitem>
 
         </itemizedlist>
 
-        <para>This entire process repeats as the software matures:
+        <para lang="en">This entire process repeats as the software matures:
           when the 2.0 work is complete, a new 2.0 release branch is
           created, tested, tagged, and eventually released.  After
           some years, the repository ends up with a number of release
           branches in <quote>maintenance</quote> mode, and a number
           of tags representing final shipped versions.</para>
 
+        <para>L'intero processo si ripete quando il software matura:
+          quando lavoro 2.0 è completo, è creato nuovo ramo di rilascio 2.0,
+          testato, targato e alla fine rilasciato. Dopo alcuni anni il
+          deposito finisce con certo numero di rami di rilascio in stato di
+          <quote>mantenimento</quote> e certo numero di targhe che rappresentano
+          le versioni finali spedite.</para>
+
       </sect3>
 
       <sect3 id="svn.branchmerge.commonuses.patterns.feature">
-        <title>Feature Branches</title>
-      
-        <para>A <firstterm>feature branch</firstterm> is the sort of
+        <!-- <title>Feature Branches</title> -->
+        <title>Rami di 'caratteristica'</title>
+
+        <para lang="en">A <firstterm>feature branch</firstterm> is the sort of
           branch that's been the dominant example in this chapter, the
           one you've been working on while Sally continues to work on
           <filename>/trunk</filename>.  It's a temporary branch
@@ -1777,7 +2559,26 @@
           the trunk, then ultimately deleted.  They have a finite span
           of usefulness.</para>
 
-        <para>Again, project policies vary widely concerning exactly
+        <para>Un <firstterm>ramo di caratteristica</firstterm> è il tipo di ramo
+          che era esempio dominante in questo capitolo, quello su quale
+          voi avete lavorato mentre Sally continuava lavorare su
+          <filename>/trunk</filename>.  È un ramo temporaneo
+          creato per lavorare su una modifica complessa senza interferire con
+          la stabilità di <filename>/trunk</filename>.  A differenza di
+          rami di rilascio (che possono avere bisogno di supporto
+          per sempre<footnote>
+            <para>Ndt. Non è vero, il team può anche decidere e pubblicare
+              diciamo dopo rilascio di versione 8.0 che a partire
+              da 1 genaio del anno venturo cesserà il supporto per
+              la versione 3.0 e precedenti. Già successo su molti software
+              di grandi nomi. Poi le targhe 1.0, 2.0 e 3.0 possono essere
+              copiate su supporti di backup e cancellate dal deposito.)
+            </para>
+          </footnote>),
+          rami di caratteristica nascono, sono ussati per un po', fusi dietro il
+          tronco e infine cancellati.  Hanno un arco di vita utile limitato.</para>
+
+        <para lang="en">Again, project policies vary widely concerning exactly
           when it's appropriate to create a feature branch.  Some
           projects never use feature branches at all: commits to
           <filename>/trunk</filename> are a free-for-all.  The
@@ -1792,7 +2593,22 @@
           exceptionally stable and usable trunk at all times, but at
           the cost of tremendous process overhead.</para>
 
-        <para>Most projects take a middle-of-the-road approach.  They
+        <para>Di nuovo, le regole del progetto variano largamente
+          riguardo esattamente quando è appropriato create un ramo di
+          caratteristica. Alcuni progetti non usano questi rami per niente:
+          depositare (commit) su <filename>/trunk</filename> è libero
+          per tutti. Vantaggio di questo sistema è la
+          semplicità—nessuno deve imparare ramificazione e fusione.
+          Svantaggio è che contenuto fresco del tronco (HEAD) è spesso
+          instabile o non usabile. Altri progetti ramificano ad estremo:
+          nessuna modifica è <emphasis>mai</emphasis> pubblicata su tronco
+          direttamente. Anche la modifica più triviale è creata su ramo
+          a vita breve, revisionata con cura e solo dopo fusa al tronco.
+          Dopo quel ramo 'monouso' è cancellato. Questo sistema garantisce
+          tronco eccezionalmente stabile e usabile in ogni momento, ma al costo di
+          tremendo sovracarico del processo di sviluppo.</para>
+
+        <para lang="en">Most projects take a middle-of-the-road approach.  They
           commonly insist that <filename>/trunk</filename> compile and
           pass regression tests at all times.  A feature branch is
           only required when a change requires a large number of
@@ -1806,7 +2622,22 @@
           incremental changes to the branch, they can be easily
           reviewed by peers.</para>
 
-        <para>Finally, there's the issue of how to best keep a feature
+        <para>Molti progetti addottano approccio 'via di mezzo'.  Comunemente
+          insistono che <filename>/trunk</filename> si può compilare e
+          passa tutti i test in ogni momento. Un ramo di caratteristica
+          è richiesto solo quando modifica porta grande numero di commit
+          destabilizzanti. Buona regola ferrea è di rispondere
+          a questa domanda: se il sviluppatore lavora per giorni in isolamento
+          e dopo pubblica larga modifica tutta in un colpo
+          (così che <filename>/trunk</filename> non sarà mai destabilizzato),
+          la modifica non sarebbe tropo grande per revisionare?  Se la risposta
+          a questa domanda è di <quote>sì</quote>, allora le modifiche
+          devono essere sviluppate in un ramo di caratteristica.
+          Man mano che il sviluppatore pubblica modifiche incrementali
+          sul ramo, queste possono essere facilmente revisionate dai
+          collaboratori.</para>
+
+        <para lang="en">Finally, there's the issue of how to best keep a feature
           branch in <quote>sync</quote> with the trunk as work
           progresses.  As we mentioned earlier, there's a great risk
           to working on a branch for weeks or months; trunk changes
@@ -1814,7 +2645,15 @@
           development differ so greatly that it may become a nightmare
           trying to merge the branch back to the trunk.</para>
 
-        <para>This situation is best avoided by regularly merging
+        <para>All fine, c'è anche la questione come meglio tenere un ramo
+          di caratteristica in <quote>sincronia</quote> col tronco man mano
+          che lavoro procede.  Abbiamo menzionato prima, c'è un grande rischio
+          di lavorare su un ramo per settimane o mesi; modifiche continuano
+          confluire anche al tronco, al punto che le due linee di sviluppo
+          differiscono così tanto che può essere un incubo provare di fondere
+          ramo dentro il tronco.</para>
+
+        <para lang="en">This situation is best avoided by regularly merging
           trunk changes to the branch.  Make up a policy: once a week,
           merge the last week's worth of trunk changes to the branch.
           Take care when doing this; the merging needs to be
@@ -1826,7 +2665,18 @@
           may sound intimidating, but it's actually pretty easy to
           do.</para>
 
-        <para>At some point, you'll be ready to merge the
+        <para>Questa situazione si può evitare meglio con regolare
+          fusione delle modifiche del tronco dentro il ramo. Stabilite una regola:
+          una volta alla settimana fondere ultime modifiche del tronco dentro il ramo.
+          Prestate attenzione facendo questo; la fusione deve essere documentata
+          a mano per evitare il problema delle fusioni ripetute (come descritto
+          in <xref linkend="svn.branchmerge.copychanges.bestprac.track"/>).
+          Dovete scrivere con cura messaggi di merge con esatti dettagli di
+          quale intervallo di versioni era stato già fuso (come dimostrato su
+          <xref linkend="svn.branchmerge.commonuses.wholebr"/>).  Può sembrare
+          spaventoso, ma in verità è abbastanza semplice da fare.</para>
+
+        <para lang="en">At some point, you'll be ready to merge the
           <quote>synchronized</quote> feature branch back to the
           trunk.  To do this, begin by doing a final merge of the
           latest trunk changes to the branch.  When that's done, the
@@ -1835,6 +2685,15 @@
           special case, you would merge by comparing the branch with
           the trunk:</para>
 
+        <para>Ad un certo punto, sarete pronti per fondere il vostro
+          ramo di caratteristica <quote>sincronizato</quote> dietro nel
+          tronco.  Per fare questo, cominciate facendo fusione finale
+          delle ultime modifiche del tronco dentro vostro ramo.
+          Qundo sarà fatto, le ultime versioni del ramo e del tronco
+          saranno identiche, eccezion fatta per le vostre modifiche
+          del ramo. Così in questo caso speciale, potete fondere
+          comparando il ramo con il tronco:</para>
+
         <screen>
 $ cd trunk-working-copy
 
@@ -1850,13 +2709,18 @@
 …
 </screen>
 
-        <para>By comparing the <literal>HEAD</literal> revision of the
+        <para lang="en">By comparing the <literal>HEAD</literal> revision of the
           trunk with the <literal>HEAD</literal> revision of the
           branch, you're defining a delta that describes only the
           changes you made to the branch; both lines of development
           already have all of the trunk changes.</para>
 
-        <para>Another way of thinking about this pattern is that your
+        <para>Comparando versione <literal>HEAD</literal> del tronco
+          con la versione <literal>HEAD</literal> del ramo, avete definito
+          un delta che descrive solo le modifiche che avete fatto sul ramo;
+          tutte e due linee dello sviluppo già hanno le modifiche del tronco.</para>
+
+        <para lang="en">Another way of thinking about this pattern is that your
           weekly sync of trunk to branch is analogous to running
           <command>svn update</command> in a working copy, while the
           final merge step is analogous to running <command>svn
@@ -1865,6 +2729,14 @@
           private branch?  It's a branch that's only capable of
           storing one change at a time.</para>
 
+        <para>Altro modo di pensare di questo archetipo è che la sincronizzazione
+          settimanale del tronco sul ramo è analoga a
+          <command>svn update</command> sulla copia di lavoro, mentre
+          il passo di fusione finale è analogo a <command>svn commit</command>
+          dalla copia di lavoro. Doppo tutto, che altro <emphasis>è</emphasis>
+          una copia di lavoro che non un ramo privato molto ??shallow??
+          Un ramo capace di contenere una modifica a volta.</para>
+
       </sect3>
 
     </sect2>
@@ -1875,9 +2747,10 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.branchmerge.switchwc">
-    <title>Switching a Working Copy</title>
+    <!-- <title>Switching a Working Copy</title> -->
+    <title>Cambiare una copia di lavoro</title>
 
-    <para>The <command>svn switch</command> command transforms an
+    <para lang="en">The <command>svn switch</command> command transforms an
       existing working copy into a different branch.  While this
       command isn't strictly necessary for working with branches, it
       provides a nice shortcut to users.  In our earlier example,
@@ -1887,6 +2760,16 @@
       <filename>/calc/trunk</filename> to mirror the new branch
       location:</para>
 
+    <para>Il comando <command>svn switch</command> trasforma una
+      copia di lavoro esistente in moda da riflettere diverso ramo.  Anche se
+      questo comando non è strettamente necessario per lavorare con
+      i rami, fornisce ai utenti una bella scorciatoia. In uno dei primi esempi
+      dopo aver creato vostro privato ramo, avete tirato fuori (check out)
+      una fresca copia della nuova cartella del deposito. Invece,
+      potete semplicemente chiedere a Subversion di cambiare vostra
+      copia di lavoro del <filename>/calc/trunk</filename> per riflettere
+      nuovo ramo:</para>
+
     <screen>
 $ cd calc
 
@@ -1903,7 +2786,7 @@
 URL: http://svn.example.com/repos/calc/branches/my-calc-branch
 </screen>
 
-    <para>After <quote>switching</quote> to the branch, your working
+    <para lang="en">After <quote>switching</quote> to the branch, your working
       copy is no different than what you would get from doing a fresh
       checkout of the directory.  And it's usually more efficient to
       use this command, because often branches only differ by a small
@@ -1911,28 +2794,50 @@
       necessary to make your working copy reflect the branch
       directory.</para>
 
-    <para>The <command>svn switch</command> command also takes a
+    <para>Dopo <quote>switching</quote> [cerco una traduzione calzante]
+      al ramo, vostra copia di lavoro
+      non è diversa da tale che potevate ottenere facendo checkout fresco fresco
+      della cartella. E molte volte è anche più efficace di usare questo comando,
+      perche spesso rami differiscono di piccolo grado. Il server manda
+      solo un insieme minimo delle modifiche necessari per allineare
+      vostra copia di lavoro con la cartella del ramo.</para>
+
+    <para lang="en">The <command>svn switch</command> command also takes a
       <option>--revision</option> (<option>-r</option>) option, so you
       need not always move your working copy to the <quote>tip</quote>
       of the branch.</para>
 
-    <para>Of course, most projects are more complicated than our
+    <para>Il comando <command>svn switch</command> prende anche una opzione
+      <option>--revision</option> (<option>-r</option>), so you
+      need not always move your working copy to the <quote>tip</quote>
+      of the branch.</para>
+
+    <para lang="en">Of course, most projects are more complicated than our
       <filename>calc</filename> example, containing multiple
       subdirectories.  Subversion users often follow a specific
       algorithm when using branches:</para>
 
+    <para>Certo, molti progetti sono più complicati di nostro esempio
+      <filename>calc</filename>, contendo sottocartelle multiple.
+      Utenti di Subversion spesso seguono un algoritmo specifico
+      quando usano i rami:</para>
+
       <orderedlist>
         <listitem>
-          <para>Copy the project's entire <quote>trunk</quote> to a
+          <para lang="en">Copy the project's entire <quote>trunk</quote> to a
             new branch directory.</para>
+          <para>Copiare tutto il <quote>trunk</quote> del progetto
+            nella cartella del nuovo ramo.</para>
         </listitem>
         <listitem>
-          <para>Switch only <emphasis>part</emphasis> of the trunk
+          <para lang="en">Switch only <emphasis>part</emphasis> of the trunk
             working copy to mirror the branch.</para>
+          <para>Cambiare(switch) solo <emphasis>una parte</emphasis> della
+            copia di lavoro del tronco per rispechiare il ramo.</para>
         </listitem>
       </orderedlist>
-    
-    <para>In other words, if a user knows that the branch-work only
+
+    <para lang="en">In other words, if a user knows that the branch-work only
       needs to happen on a specific subdirectory, they use
       <command>svn switch</command> to move only that subdirectory to
       the branch.  (Or sometimes users will switch just a single
@@ -1944,14 +2849,35 @@
       working copy</quote>—not only can working copies contain a
       mixture of working revisions, but a mixture of repository
       locations as well.</para>
-    
-    <para>If your working copy contains a number of switched subtrees
+
+    <para>In altre parole, se un utente sa che lavoro sul ramo
+      è neccessario solo in una specifica sottocartella, usa
+      <command>svn switch</command> per spostare solo quella
+      sottocartella sul ramo.  (O qualche volta utenti cambiano(switch)
+      solo un file di lavoro sul ramo!)  In quel modo, continuano a
+      ricevere normali aggiornamenti del <quote>trunk</quote>
+      per maggior parte della loro copia di lavoro, ma la parte
+      ??switchata? :) rimarrà imune (finché qualcuno non deposita
+      cambiamenti su loro raomo).  Questa caratteristica aggiunge completamente
+      nuova dimensione al concetto di <quote>copia di lavoro
+      mista</quote>—mom solo la copia di lavoro può contenere
+      una miscella delle revisioni, ma con la stessa facilità anche
+      miscella delle locazioni del deposito.</para>
+
+    <para lang="en">If your working copy contains a number of switched subtrees
       from different repository locations, it continues to function as
       normal.  When you update, you'll receive patches to each subtree
       as appropriate.  When you commit, your local changes will still
       be applied as a single, atomic change to the repository.</para>
 
-    <para>Note that while it's okay for your working copy to reflect a
+    <para>Nonostante vostra copia di lavoro contiene una quantità delle
+      sottostrutture ??switchate? da diversi posti del deposito, continua
+      funzionare normalmente.  Durante aggiornamenti riceve modifiche
+      per ogni sottostruttura dal posto giusto. Quando depositate, vostre
+      modifiche locali sono ancora applicate come una singola, atomica
+      modifica del deposito.</para>
+
+    <para lang="en">Note that while it's okay for your working copy to reflect a
       mixture of repository locations, these locations must all be
       within the <emphasis>same</emphasis> repository.  Subversion
       repositories aren't yet able to communicate with one another;
@@ -1963,24 +2889,50 @@
       See the <command>svn switch</command> section in <xref
       linkend="svn.ref"/> for more information and an example.</para>
       </footnote></para>
-    
+
+    <para>Da notare: anche se è consentito alla vostra copia di lavoro
+      di riflettere miscella dei posti del deposito, questi posti
+      devono tutti provenire dal <emphasis>unico</emphasis> deposito.
+      I depositi di Subversion non sono ancora capaci di communicare
+      tra loro; questa caratteristica è pianificata oltre
+      Subversion 1.0.<footnote><para><emphasis>Potete</emphasis>, comunque,
+      usare <command>svn switch</command> con la opzione
+      <option>--relocate</option> se URL del vostro server cambia e
+      voi non volete abbandonare una copia di lavoro esistente.
+      Vedi sezione <command>svn switch</command> in <xref
+      linkend="svn.ref"/> per avere più informazioni e un esempio.</para>
+      </footnote></para>
+
     <sidebar>
+      <!-- <title>Switches and Updates</title> -->
       <title>Switches and Updates</title>
-      
-      <para>Have you noticed that the output of <command>svn
+
+      <para lang="en">Have you noticed that the output of <command>svn
         switch</command> and <command>svn update</command> look the
         same?  The <literal>switch</literal> command is actually a
         superset of the update command.</para>
 
-      <para>When you run <command>svn update</command>, you're asking
+      <para>Avete notato che output di <command>svn
+          switch</command> e <command>svn update</command> sembrano
+        uguali?  Il comando <literal>switch</literal> è in verità
+        un soprainsieme del comando update.</para>
+
+      <para lang="en">When you run <command>svn update</command>, you're asking
         the repository to compare two trees.  The repository does so,
         and then sends a description of the differences back to the
         client.  The only difference between <command>svn
         switch</command> and <command>svn update</command> is that the
         <literal>update</literal> command always compares two identical
         paths.</para>
-      
-      <para>That is, if your working copy is a mirror of
+
+      <para>Quando lanciate <command>svn update</command>, state chiedendo
+        al deposito di comparare due strutture. Il deposito lo fa e spedisce
+        descrizione delle differenze dietro al client . L'unica
+        differenza tra <command>svn switch</command> e <command>svn update</command>
+        è che il comando <literal>update</literal> compara sempre
+        due indirizz identici.</para>
+
+      <para lang="en">That is, if your working copy is a mirror of
         <filename>/calc/trunk</filename>, then <command>svn
         update</command> will automatically compare your working copy
         of <filename>/calc/trunk</filename> to
@@ -1992,18 +2944,39 @@
         <emphasis>other</emphasis> branch-directory in the
         <literal>HEAD</literal> revision.</para>
 
-      <para>In other words, an update moves your working copy through
+      <para>Proprio così, se la vostra copia di lavoro rispecchia
+        <filename>/calc/trunk</filename>, <command>svn
+          update</command> automaticamente comparerà vostra
+        copia di <filename>/calc/trunk</filename> con
+        <filename>/calc/trunk</filename> della revisione
+        <literal>HEAD</literal>.  Se state ??switching? vostra
+        copia di lavoro ad un ramo, <command>svn switch</command>
+        comparerà vostra copia di lavoro di
+        <filename>/calc/trunk</filename> con qualche
+        <emphasis>altra</emphasis> cartella (quella del ramo) della
+        revisione <literal>HEAD</literal>.</para>
+
+      <para lang="en">In other words, an update moves your working copy through
         time.  A switch moves your working copy through time
         <emphasis>and</emphasis> space.</para>
+      <para>In altre parole, un aggiornamento sposta vostra copia
+        di lavoro in tempo.  Un switch spota vostra copia di lavoro
+        in tempo <emphasis>e</emphasis> spazio.</para>
     </sidebar>
 
-    <para>Because <command>svn switch</command> is essentially a
+    <para lang="en">Because <command>svn switch</command> is essentially a
       variant of <command>svn update</command>, it shares the same
       behaviors; any local modifications in your working copy are
       preserved when new data arrives from the repository.  This
       allows you to perform all sorts of clever tricks.</para>
 
-    <para>For example, suppose you have a working copy of
+    <para>Perché <command>svn switch</command> è esenzialmente
+      una variante di <command>svn update</command>, condivide lo
+      stesso comportamento; qualsiasi modifica locale nella vostra copia
+      di lavoro è conservata quando arrivano nuovi dati dal deposito.
+      Questo vi permette di fare ogni sorta di truchetti intelligenti.</para>
+
+    <para lang="en">For example, suppose you have a working copy of
       <filename>/calc/trunk</filename> and make a number of changes to
       it.  Then you suddenly realize that you meant to make the
       changes to a branch instead.  No problem!  When you <command>svn
@@ -2011,6 +2984,13 @@
       changes will remain.  You can then test and commit them to the
       branch.</para>
 
+    <para>Per esempio, supponiamo che avete copia di lavoro di
+      <filename>/calc/trunk</filename> e fatte una quantità di cambiamenti.
+      Solo dopo scoprite che avete pensavate di fare modifiche
+      sulla copia del ramo.  No problem!  Dopo <command>svn
+        switch</command> della vostra copia su ramo, i cambiamenti locali
+      restano.  Potete testarli e poi depositarli sul ramo.</para>
+
   </sect1>
 
 
@@ -2018,31 +2998,52 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.branchmerge.tags">
-    <title>Tags</title>
+    <!-- <title>Tags</title> -->
+    <title>Targhe</title>
 
-    <para>Another common version control concept is a
+    <para lang="en">Another common version control concept is a
       <firstterm>tag</firstterm>.  A tag is just a
       <quote>snapshot</quote> of a project in time.  In Subversion,
       this idea already seems to be everywhere.  Each repository
       revision is exactly that—a snapshot of the filesystem
       after each commit.</para>
 
-    <para>However, people often want to give more human-friendly names
+    <para>Altro concetto comune del controllo delle versioni è
+      <firstterm>tag</firstterm>(targa).  Una targa è solo
+      un'<quote>instantanea</quote>  del progetto nel tempo.  In Subversion,
+      questa idea ??already? sembra di essere presente ovunque. Ogni versione
+      nel deposito è proprio questo—un'instantanea del filesystem
+      dopo ogni commit.</para>
+
+    <para lang="en">However, people often want to give more human-friendly names
       to tags, like <literal>release-1.0</literal>.  And they want to
       make snapshots of smaller subdirectories of the filesystem.
       After all, it's not so easy to remember that release-1.0 of a
       piece of software is a particular subdirectory of revision
       4822.</para>
 
+    <para>However, gente spesso vuole dare alle targe nomi più
+      comprensibili, come <literal>release-1.0</literal>.  E vogliono
+      fare instantanee di sottocartelle più piccole. Dopo tutto,
+      non è così facile ricordarsi che rilascio-1.0 d'un pezzo
+      di software è una particolare sottocartella della versione
+      4822.</para>
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.tags.mksimple">
-      <title>Creating a Simple Tag</title>
+      <!-- <title>Creating a Simple Tag</title> -->
+      <title>Creare una targa semplice</title>
 
-      <para>Once again, <command>svn copy</command> comes to the
+      <para lang="en">Once again, <command>svn copy</command> comes to the
         rescue.  If you want to create a snapshot of
         <filename>/calc/trunk</filename> exactly as it looks in the
         <literal>HEAD</literal> revision, then make a copy of it:</para>
 
+      <para>Ancora una volta, <command>svn copy</command>
+        vi dà una mano.  Se volete creare un'instantanea di
+        <filename>/calc/trunk</filename> esattamente come compare nella
+        versione <literal>HEAD</literal>, fate una copia di esso:</para>
+
       <screen>
 $ svn copy http://svn.example.com/repos/calc/trunk \
            http://svn.example.com/repos/calc/tags/release-1.0 \
@@ -2051,9 +3052,9 @@
 Committed revision 351.
 </screen>
 
-      <para>This example assumes that a
+      <para lang="en">This example assumes that a
         <filename>/calc/tags</filename> directory already exists.  (If it
-        doesn't, see <xref linkend="svn.ref.svn.c.mkdir"/>).
+        doesn't, vedi <xref linkend="svn.ref.svn.c.mkdir"/>).
         After the copy completes, the new
         <filename>release-1.0</filename> directory is forever a
         snapshot of how the project looked in the
@@ -2066,7 +3067,22 @@
         want, you can specify it by passing <option>-r 350</option> to
         the <command>svn copy</command> command.</para>
 
-      <para>But wait a moment: isn't this tag-creation procedure the
+      <para>Questo esempio presume che cartella
+        <filename>/calc/tags</filename> già esiste.  (Se no,
+        vedi <xref linkend="svn.ref.svn.c.mkdir"/>).
+        Dopo che la copia è completata, la nuova cartella
+        <filename>release-1.0</filename> è per sempre
+        un'instantanea come il progetto appariva nella versione
+        <literal>HEAD</literal> in momento della copiatura.
+        Certo, potete forse volere di essere più precisi nello
+        stabilire quale versione copiare, in caso che qualcun altro
+        aveva depositato cambiamenti quando non avete guardato.
+        Sapendo che la versione 350 di
+        <filename>/calc/trunk</filename> è proprio quella voluta,
+        potete specificarlo passando opzione <option>-r 350</option> al
+        comando <command>svn copy</command>.</para>
+
+      <para lang="en">But wait a moment: isn't this tag-creation procedure the
         same procedure we used to create a branch?  Yes, in fact, it
         is.  In Subversion, there's no difference between a tag and a
         branch.  Both are just ordinary directories that are created
@@ -2077,7 +3093,18 @@
         remains a snapshot.  If people start committing to it, it
         becomes a branch.</para>
 
-      <para>If you are administering a repository, there are two
+      <para>Ma aspettate un po': la procedura di creare una targa non è la
+        stessa come creare un ramo? Sì, infatti, lo è.  In Subversion
+        non c'è differenza tra targa e ramo. Entrambi sono ordinarie cartelle
+        e sono creati tramite copiatura.
+        Uguale come per i rami, l'unica ragione che una cartella
+        copiata è una <quote>targa</quote> è perché
+        <emphasis>esseri umani</emphasis> hanno deciso di trattarla
+        in quel modo: finché nessuno fa commit su questa cartella, rimane
+        per sempre un'instantanea.  Se la gente comincia a depositare dentro
+        (commit), diventa un ramo.</para>
+
+      <para lang="en">If you are administering a repository, there are two
         approaches you can take to managing tags.  The first approach
         is <quote>hands off</quote>: as a matter of project policy,
         decide where your tags will live, and make sure all users know
@@ -2092,17 +3119,38 @@
         simply undo the change as discussed in the previous section.
         This is version control, after all.</para>
 
+      <para>Se state amministrando un deposito, ci sono due approci da prendere
+        per maneggiare targhe.  Il primo approcio è
+        <quote>alzare le mani</quote>: nelle regole del progetto decidete
+        dove vivranno le targhe e assicurate che tutti utenti capiscono
+        come trattare le cartelle che copiano lì. (Proprio così,
+        assicuratevi che sanno di non fare commit su di essi. Ndt. E se qualcosa
+        va storto, alzate le mani e gridate: ve lo avevo detto)  Il secondo
+        approcio è più paranoico. Potete usare uno dei script di controllo
+        d'accesso forniti con Subversion per prevenire che nell'area delle targhe
+        nessuno può fare altro che creare nuove copie.
+        (Vedi <xref linkend="svn.serverconfig"/>.)  L'approcio paranoico,
+        comunque, non è tanto necessario.  Se un utente accidentalmente
+        fa un commit nella cartella delle targhe, potete semplicemente disfare
+        la modifica come abbiamo discuso nella sezione precedente.
+        Oltrettuto, stiamo usando controllo delle versioni, no?</para>
+
     </sect2>
-    
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.tags.mkcomplex">
-      <title>Creating a Complex Tag</title>
-      
-      <para>Sometimes you may want your <quote>snapshot</quote> to be
+      <!-- <title>Creating a Complex Tag</title> -->
+      <title>Creare una targa complessa</title>
+
+      <para lang="en">Sometimes you may want your <quote>snapshot</quote> to be
         more complicated than a single directory at a single
         revision.</para>
-      
-      <para>For example, pretend your project is much larger than our
+
+      <para>Qualche volta potete desiderare che vostra
+        <quote>instantanea</quote> sarà più complicata di una singola
+        cartella della singola revisione.</para>
+
+      <para lang="en">For example, pretend your project is much larger than our
         <filename>calc</filename> example: suppose it contains a
         number of subdirectories and many more files.  In the course
         of your work, you may decide that you need to create a working
@@ -2115,8 +3163,30 @@
         hodgepodge of repository locations from different revisions.
         But after testing, you know it's the precise combination of
         data you need.</para>
+#$#
+      <para>For example, pretend your project is much larger than our
+        <filename>calc</filename> example: suppose it contains a
+        number of subdirectories and many more files.  In the course
+        of your work, you may decide that you need to create a working
+        copy that is designed to have specific features and bug fixes.
+        You can accomplish this by selectively backdating files or
+        directories to particular revisions (using <command>svn update
+          -r</command> liberally), or by switching files and directories
+        to particular branches (making use of <command>svn
+          switch</command>).  When you're done, your working copy is a
+        hodgepodge of repository locations from different revisions.
+        Ma dopo i test, sapete che questa è la precisa combinazione dei dati
+        che vi serve.</para>
+
+      <para lang="en">Time to make a snapshot.  Copying one URL to another won't
+        work here.  In this case, you want to make a snapshot of your
+        exact working copy arrangement and store it in the repository.
+        Luckily, <command>svn copy</command> actually has four
+        different uses (which you can read about in Chapter 9),
+        including the ability to copy a working-copy tree to the
+        repository:</para>
 
-      <para>Time to make a snapshot.  Copying one URL to another won't
+      <para>Ora di scattare un'instantanea.  Copying one URL to another won't
         work here.  In this case, you want to make a snapshot of your
         exact working copy arrangement and store it in the repository.
         Luckily, <command>svn copy</command> actually has four
@@ -2133,12 +3203,17 @@
 Committed revision 352.
 </screen>
 
+      <para lang="en">Now there is a new directory in the repository,
+        <filename>/calc/tags/mytag</filename>, which is an exact
+        snapshot of your working copy—mixed revisions, URLs,
+        and all.</para>
+
       <para>Now there is a new directory in the repository,
         <filename>/calc/tags/mytag</filename>, which is an exact
         snapshot of your working copy—mixed revisions, URLs,
         and all.</para>
 
-      <para>Other users have found interesting uses for this feature.
+      <para lang="en">Other users have found interesting uses for this feature.
         Sometimes there are situations where you have a bunch of local
         changes made to your working copy, and you'd like a
         collaborator to see them.  Instead of running <command>svn
@@ -2150,6 +3225,18 @@
         working copy, or use <command>svn merge</command> to receive
         your exact changes.</para>
 
+      <para>Other users have found interesting uses for this feature.
+        Sometimes there are situations where you have a bunch of local
+        changes made to your working copy, and you'd like a
+        collaborator to see them.  Instead of running <command>svn
+          diff</command> and sending a patch file (which won't capture
+        tree changes, symlink changes or changes in properties), you can
+        instead use <command>svn copy</command> to <quote>upload</quote>
+        your working copy to a private area of the repository.  Your
+        collaborator can then either checkout a verbatim copy of your
+        working copy, or use <command>svn merge</command> to receive
+        your exact changes.</para>
+
     </sect2>
 
   </sect1>
@@ -2158,9 +3245,10 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.branchmerge.maint">
-    <title>Branch Maintenance</title>
+    <!-- <title>Branch Maintenance</title> -->
+    <title>Mantenimento dei rami</title>
 
-    <para>You may have noticed by now that Subversion is extremely
+    <para lang="en">You may have noticed by now that Subversion is extremely
       flexible.  Because it implements branches and tags with the same
       underlying mechanism (directory copies), and because branches
       and tags appear in normal filesystem space, many people find
@@ -2168,10 +3256,27 @@
       flexible.  In this section, we'll offer some suggestions for
       arranging and managing your data over time.</para>
 
+    <para>Forse avete già notato che Subversion è estremamente
+      flessibile.  Perché implementa rami e targhe con lo stesso mecanismo
+      sottostante (copiatura delle cartelle) e perché rami e targhe
+      appaiono nello spazio ordinario del filesistem, molte persone
+      trovano Subversion spaventoso.  È quasi <emphasis>troooopo</emphasis>
+      flessibile.  In this section, we'll offer some suggestions for
+      arranging and managing your data over time.</para>
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.maint.layout">
-      <title>Repository Layout</title>
-      
+      <!-- <title>Repository Layout</title> -->
+      <title>Forma del deposito</title>
+
+      <para lang="en">There are some standard, recommended ways to organize a
+        repository.  Most people create a <filename>trunk</filename>
+        directory to hold the <quote>main line</quote> of development,
+        a <filename>branches</filename> directory to contain branch
+        copies, and a <filename>tags</filename> directory to contain
+        tag copies.  If a repository holds only one project, then
+        often people create these top-level directories:</para>
+
       <para>There are some standard, recommended ways to organize a
         repository.  Most people create a <filename>trunk</filename>
         directory to hold the <quote>main line</quote> of development,
@@ -2186,6 +3291,11 @@
 /tags
 </screen>
 
+      <para lang="en">If a repository contains multiple projects, admins
+        typically index their layout by project (see <xref
+        linkend="svn.reposadmin.projects.chooselayout"/> to read more about
+        <quote>project roots</quote>):</para>
+
       <para>If a repository contains multiple projects, admins
         typically index their layout by project (see <xref
         linkend="svn.reposadmin.projects.chooselayout"/> to read more about
@@ -2200,6 +3310,17 @@
 /calc/tags
 </screen>
 
+      <para lang="en">Of course, you're free to ignore these common layouts.
+        You can create any sort of variation, whatever works best for
+        you or your team.  Remember that whatever you choose, it's not
+        a permanent commitment.  You can reorganize your repository at
+        any time.  Because branches and tags are ordinary directories,
+        the <command>svn move</command> command can move or rename
+        them however you wish.  Switching from one layout to another
+        is just a matter of issuing a series of server-side moves; if
+        you don't like the way things are organized in the repository,
+        just juggle the directories around.</para>
+
       <para>Of course, you're free to ignore these common layouts.
         You can create any sort of variation, whatever works best for
         you or your team.  Remember that whatever you choose, it's not
@@ -2211,6 +3332,18 @@
         you don't like the way things are organized in the repository,
         just juggle the directories around.</para>
 
+      <para lang="en">Remember, though, that while moving directories may be
+        easy to do, you need to be considerate of your users as well.
+        Your juggling can be disorienting to users with existing
+        working copies.  If a user has a working copy of a particular
+        repository directory, your <command>svn move</command>
+        operation might remove the path from the latest revision.
+        When the user next runs <command>svn update</command>, she will
+        be told that her working copy represents a path that no
+        longer exists, and the user will be forced to <command>svn
+        switch</command> to the new location.
+        </para>
+
       <para>Remember, though, that while moving directories may be
         easy to do, you need to be considerate of your users as well.
         Your juggling can be disorienting to users with existing
@@ -2222,12 +3355,22 @@
         longer exists, and the user will be forced to <command>svn
         switch</command> to the new location.
         </para>
-      
+
     </sect2>
-    
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.maint.lifetime">
-      <title>Data Lifetimes</title>
+      <!-- <title>Data Lifetimes</title> -->
+      <title>Arco di vita dei dati</title>
+
+      <para lang="en">Another nice feature of Subversion's model is that
+        branches and tags can have finite lifetimes, just like any
+        other versioned item.  For example, suppose you eventually
+        finish all your work on your personal branch of the
+        <filename>calc</filename> project.  After merging all of your
+        changes back into <filename>/calc/trunk</filename>, there's
+        no need for your private branch directory to stick around
+        anymore:</para>
 
       <para>Another nice feature of Subversion's model is that
         branches and tags can have finite lifetimes, just like any
@@ -2245,7 +3388,7 @@
 Committed revision 375.
 </screen>
 
-      <para>And now your branch is gone.  Of course it's not really
+      <para lang="en">And now your branch is gone.  Of course it's not really
         gone: the directory is simply missing from the
         <literal>HEAD</literal> revision, no longer distracting
         anyone.  If you use <command>svn checkout</command>,
@@ -2253,13 +3396,28 @@
         to examine an earlier revision, you'll still be able to see
         your old branch.</para>
 
-      <para>If browsing your deleted directory isn't enough, you can
+      <para>E adesso vostro ramo è andato.  Certo, in verità non è
+        sparito: la cartella semplicemente manca nella versione
+        <literal>HEAD</literal>, non distraendo più nessuno.
+        Usando <command>svn checkout</command>,
+        <command>svn switch</command>, o <command>svn list</command>
+        per essaminare le versioni precedenti, potete ancora vedere
+        vostro vecchio ramo.</para>
+
+      <para lang="en">If browsing your deleted directory isn't enough, you can
         always bring it back.  Resurrecting data is very easy in
         Subversion.  If there's a deleted directory (or file) that
         you'd like to bring back into <literal>HEAD</literal>, simply
         use <command>svn copy -r</command> to copy it from the old
         revision:</para>
 
+      <para>Se non vi basta navigare nella cartella cancellata,
+        potete sempre richiamarla dietro.  Risurrezione dei dati
+        è in Subversion molto semplice.  If there's a deleted directory (or file) that
+        you'd like to bring back into <literal>HEAD</literal>, simply
+        use <command>svn copy -r</command> to copy it from the old
+        revision:</para>
+
       <screen>
 $ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch \
                   http://svn.example.com/repos/calc/branches/my-calc-branch
@@ -2267,6 +3425,20 @@
 Committed revision 376.
 </screen>
 
+      <para lang="en">In our example, your personal branch had a relatively
+        short lifetime: you may have created it to fix a bug or
+        implement a new feature.  When your task is done, so is the
+        branch.  In software development, though, it's also common to
+        have two <quote>main</quote> branches running side-by-side for
+        very long periods.  For example, suppose it's time to release
+        a stable version of the <filename>calc</filename> project to the
+        public, and you know it's going to take a couple of months to
+        shake bugs out of the software.  You don't want people to add
+        new features to the project, but you don't want to tell all
+        developers to stop programming either.  So instead, you create
+        a <quote>stable</quote> branch of the software that won't
+        change much:</para>
+
       <para>In our example, your personal branch had a relatively
         short lifetime: you may have created it to fix a bug or
         implement a new feature.  When your task is done, so is the
@@ -2289,6 +3461,17 @@
 Committed revision 377.
 </screen>
 
+      <para lang="en">And now developers are free to continue adding
+        cutting-edge (or experimental) features to
+        <filename>/calc/trunk</filename>, and you can declare a
+        project policy that only bug fixes are to be committed to
+        <filename>/calc/branches/stable-1.0</filename>.  That is, as
+        people continue to work on the trunk, a human selectively
+        ports bug fixes over to the stable branch.  Even after the
+        stable branch has shipped, you'll probably continue to
+        maintain the branch for a long time—that is, as long
+        as you continue to support that release for customers.</para>
+
       <para>And now developers are free to continue adding
         cutting-edge (or experimental) features to
         <filename>/calc/trunk</filename>, and you can declare a
@@ -2312,7 +3495,7 @@
   <!--  <title>Summary</title>  -->
     <title>Sommario</title>
 
-    <para>We've covered a lot of ground in this chapter.  We've
+    <para lang="en">We've covered a lot of ground in this chapter.  We've
       discussed the concepts of tags and branches, and demonstrated
       how Subversion implements these concepts by copying directories
       with the <command>svn copy</command> command.  We've shown how
@@ -2323,20 +3506,29 @@
       might manage the organization and lifetimes of branches in a
       repository.</para>
 
+    <para>Abbiamo coperto molto delle basi in questo capitolo. Abbiamo
+      discusso i concetti delle targe e dei rami e dimostrato come
+      Subversion implementa questi concetti tramite copie delle cartelle
+      con comando <command>svn copy</command>.  Abbiamo mostrato come
+      usare <command>svn merge</command> per copiare modifiche da
+      un ramo ad altro o disfare (riavvolgere dietro) modifiche errate.
+      Abbiamo ??gone over? uso di <command>svn switch</command> per creare
+      copie di lavoro miste, provenienti da diverse locazioni.
+      E abbiamo parlato di come uno può maneggare la organizzazione e
+      ciclo di vita dei rami nel deposito.</para>
+
     <para lang="en">Remember the Subversion mantra: branches and tags are cheap.
       So use them liberally!</para>
 
-    <para>Ricordate il mantra di Subversion: rami ed etichette sono a basso costo.
-      Allora usateli liberalmente!</para>
-    
+    <para>Ricordate il mantra di Subversion: rami e targhe sono a basso costo.
+      Allora usateli ??liberalmente?!</para>
+
   </sect1>
 
 </chapter>
 
 <!--
-local variables: 
+local variables:
 sgml-parent-document: ("book.xml" "chapter")
 end:
 -->
-
-

Modified: trunk/src/it/book/copyright.xml
==============================================================================
--- trunk/src/it/book/copyright.xml	(original)
+++ trunk/src/it/book/copyright.xml	Tue Sep  5 11:57:44 2006
@@ -5,12 +5,12 @@
     <programlisting>
 
 Copyright (c) 2002-2005
-Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato.  
+Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato.
 
 Questo lavoro è licenziato sotto la licenza Creative Commons Attribution.
 Per vedere una copia di questa licenza consultare il sito
 http://creativecommons.org/licenses/by/2.0/ od inviate una lettera
-a 
+a
 Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305,
 USA.
 
@@ -20,16 +20,16 @@
 
 Siete liberi di:
 
-    * riprodurre, distribuire, comunicare al pubblico, esporre in pubblico, rappresentare, eseguire e recitare quest'opera 
+    * riprodurre, distribuire, comunicare al pubblico, esporre in pubblico, rappresentare, eseguire e recitare quest'opera
     * di modificare quest'opera
     * di usare quest'opera per fini commerciali
 
 Sotto le seguenti condizioni:
-	
+
 Attribuzione. Devi attribuire la paternità dell'opera nei modi indicati dall'autore o da chi ti ha dato l'opera in licenza.
-	
 
-    * Ogni volta che si utilizzi o distribuisca quest'opera, si deve farlo secondo i termini di questa licenza, 
+
+    * Ogni volta che si utilizzi o distribuisca quest'opera, si deve farlo secondo i termini di questa licenza,
     che va comunicata con chiarezza.
 
     * In ogni caso, puoi concordare col titolare dei diritti d'autore utilizzi di quest'opera non consentiti da questa licenza.
@@ -41,7 +41,6 @@
 Quanto sopra è una sintesi del seguente testo integrale della licenza che viene
 riportato in lingua originale inglese.
 
-Ndt. Se vuoi sapere di più su Creative Commons, visita il sito <ulink url="http://www.creativecommons.it" />
 ====================================================================
 
 Creative Commons Legal Code
@@ -309,7 +308,7 @@
 </appendix>
 
 <!--
-local variables: 
+local variables:
 sgml-parent-document: ("book.xml" "")
 end:
 -->




More information about the svnbook-dev mailing list