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

Federico Nebiacolombo federico.nebiacolombo at softeco.it
Thu Sep 7 07:19:48 CDT 2006


> chap 04 all done - need proofread
ok, I will take care about this on next week.
Thanks & bye
Nebiac

> -----Messaggio originale-----
> Da: svnbook-dev-bounces at red-bean.com
> [mailto:svnbook-dev-bounces at red-bean.com]Per conto di bpietro
> Inviato: Tuesday, September 05, 2006 6:58 PM
> A: svnbook-dev at red-bean.com
> Oggetto: [svnbook commit] r2403 - trunk/src/it/book
> 
> 
> 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:
>  -->
> 
> _______________________________________________
> svnbook-dev mailing list
> svnbook-dev at red-bean.com
> http://www.red-bean.com/mailman/listinfo/svnbook-dev
> 







More information about the svnbook-dev mailing list