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

bpietro noreply at red-bean.com
Wed Sep 13 03:39:39 CDT 2006


Author: bpietro
Date: Wed Sep 13 03:39:38 2006
New Revision: 2418

Modified:
   trunk/src/it/book/ch04.xml

Log:
proofread continued


Modified: trunk/src/it/book/ch04.xml
==============================================================================
--- trunk/src/it/book/ch04.xml	(original)
+++ trunk/src/it/book/ch04.xml	Wed Sep 13 03:39:38 2006
@@ -1336,8 +1336,7 @@
           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>
-<!-- stop flag -->
-<para>Proofread fino qui #$#$#$#$#$#</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
@@ -1347,7 +1346,7 @@
         <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
+          più una scelta 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
@@ -1444,7 +1443,7 @@
           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.
+          in deposito: modo in quale il deposito appare dopo N-essimo 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
@@ -1492,13 +1491,13 @@
 
         <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
+          ad una particolare versione, 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
+          a quel che già avete il delta garantisce di correttamente convertire
           vostra copia di lavoro nella struttura di lato destra.</para>
 
         <para lang="en">But <command>svn merge</command> has no such guarantees
@@ -1607,7 +1606,7 @@
         <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
+          Nella <xref linkend="svn.tour.cycle.resolve"/>, abbiamo visto che
           un aggiornamento (update) produce file nominati
           <filename>filename.mine</filename>,
           <filename>filename.rOLDREV</filename> e
@@ -1714,10 +1713,10 @@
         <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
+          tuttavia, si può volere che comando <literal>merge</literal> compara
+          due strutture che non sono in relazione.  Per esempio, si può importare
           due strutture del codice sorgente che rappresentano due rilasci pubblici
-          d'un progetto software (vedi <xref linkend="svn.advanced.vendorbr"/>).
+          d'un progetto software (vedi la <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>
@@ -1732,11 +1731,11 @@
           <command>svn diff</command> to behave like the
           <literal>merge</literal> command.)</para>
 
-        <para>In tale situazione, si chiede a <command>svn
+        <para>In tali situazioni, 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
+          <option>--ignore-ancestry</option> al vostro comando di fusione,
+          e 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
@@ -1893,7 +1892,7 @@
 
 
       <para lang="en">Here's the final merging procedure, then:</para>
-      <para>Qui c'è la procedura di fusione finale, ??then?:</para>
+      <para>Qui c'è la procedura di fusione finale, allora:</para>
 
       <screen>
 $ cd calc/trunk
@@ -1946,7 +1945,7 @@
         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"/>,
+        Ma come era discusso nella <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>
@@ -1977,9 +1976,9 @@
         <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>
+        tra le versioni 341 e 405 erano già precedentemente fuse nel tronco
+        come versione 406, sapete adesso che volete fondere solo cambiamenti
+        del ramo fatte dopo—comparando versioni 406 e <literal>HEAD</literal>.</para>
 
       <screen>
 $ cd calc/trunk
@@ -2075,8 +2074,8 @@
 
       <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 opzione <option>-r</option>, potete chiedere a
+        delle versioni lo chiamano <firstterm>changeset</firstterm>).
+        Usando opzione <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>
@@ -2140,10 +2139,10 @@
         <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
+        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
+        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.
@@ -2155,7 +2154,7 @@
           <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
+            permanente. Ma prima ciò accada, vedi la
             <xref linkend="svn.reposadmin.maint.tk.svndumpfilter"/>
             per possibile raggiro.</para>
         </footnote>
@@ -2670,9 +2669,9 @@
           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"/>).
+          nella <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
+          quale intervallo di versioni era stato già fuso (come dimostrato nella
           <xref linkend="svn.branchmerge.commonuses.wholebr"/>).  Può sembrare
           spaventoso, ma in verità è abbastanza semplice da fare.</para>
 
@@ -2734,9 +2733,10 @@
           <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 con pocco spessore.
-          Un ramo capace di contenere una modifica a volta.</para>
-
+          una copia di lavoro se non un ramo privato pocco capiente.
+          Un ramo capace di contenere solo una modifica alla volta.</para>
+<!-- proofread stopflag, need to be visible -->
+<para>Proofread stopflag #$#$#$#$#$#</para>
       </sect3>
 
     </sect2>
@@ -2761,7 +2761,7 @@
       location:</para>
 
     <para>Il comando <command>svn switch</command> trasforma una
-      copia di lavoro esistente in moda da riflettere diverso ramo.  Anche se
+      copia di lavoro esistente in modo 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)




More information about the svnbook-dev mailing list