[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