[svnbook commit] r2464 - trunk/src/it/book
ender
noreply at red-bean.com
Tue Oct 10 06:21:24 CDT 2006
Author: ender
Date: Tue Oct 10 06:21:24 2006
New Revision: 2464
Modified:
trunk/src/it/book/ch02.xml
Log:
Checked and fixed zup-translated section (from section
"svn.basic.in-action.track-repos"> to the end)
Modified: trunk/src/it/book/ch02.xml
==============================================================================
--- trunk/src/it/book/ch02.xml (original)
+++ trunk/src/it/book/ch02.xml Tue Oct 10 06:21:24 2006
@@ -600,7 +600,7 @@
two essential pieces of information in the
<filename>.svn/</filename> administrative area:</para>
- <para>Per ogni file nella direcotory di lavoro, Subversion registra
+ <para>Per ogni file nella directory di lavoro, Subversion registra
due porzioni di informazione essenziali nell' area di amministrazione
<filename>.svn/</filename>:</para>
@@ -646,8 +646,8 @@
nothing.</para>
<para>Il file non è stato modificato nella directory di lavoro e
- nessun cambiamento è stato sottomesso al repository dalla sua
- revisione di lavoro. Un comando <command>svn commit</command>
+ nessuna modifica alla sua revisione di lavoro è stata sottomessa
+ al repository. Un comando <command>svn commit</command>
del file non farà nulla, e un comando <command>svn update</command>
del file non farà nulla.</para>
</listitem>
@@ -667,8 +667,8 @@
update</command> of the file will do nothing.</para>
<para>Il file è stato modificato nella directory di lavoro,
- e nessun cambiamento è stato sottomesso al repository dalla
- sua revisione di lavoro. Ci sono delle modifiche locali che devono
+ e nessuna modifica alla sua revisione di lavoro è stata sottomessa
+ al repository. Ci sono delle modifiche locali che devono
essere salvate sul repository, quindi un <command>svn commit</command>
del file pubblicherà con successo le modifiche,
e un <command>svn update</command> del file non farà nulla.
@@ -690,10 +690,10 @@
latest changes into your working copy.</para>
<para>Il file non è stato modificato nella directory di lavoro,
- me ha subito dei cambiamenti nel repository. Il file dovrebbe
+ ma ha subito dei cambiamenti nel repository. Il file dovrebbe
essere aggiornato per renderlo sincronizzato con l'attuale
revisione pubblica. Un <command>svn commit</command> del file
- non farà nulla, e un <command>svn commit</command> del file
+ non farà nulla, e un <command>svn update</command> del file
caricherà gli ultimi cambiamenti nella copia di lavoro.
</para>
</listitem>
@@ -716,7 +716,7 @@
<para>Il file è stato cambiato sia nella directory di lavoro,
sia nel repository. Un comando <command>svn commit</command>
del file fallirà con un errore di <quote>out-of-date</quote>.
- Il file dovrebbe prima essere aggoirnato; un comando
+ Il file dovrebbe prima essere aggiornato; un comando
<command>svn update</command> tenterà di incorporare
le modifiche pubbliche con le modifiche locali.
Se Subversion non può completare la fusione automatica
@@ -759,7 +759,7 @@
<para>Come principio generale, Subversion vuole essere il più flessibile possibile.
Una particolare flessibilità deriva dalla possibilità
di avere una copia di lavoro contenente file e directory
- con un MIX di differenti numeri di revisione.
+ con un insieme di differenti numeri di revisione.
Sfortunatamente questa flessibilità tende a confondere alcuni utenti.
Segue quindi un'introduzione sul perchè esiste questa caratteristica
e su come utilizzarla.
@@ -786,7 +786,7 @@
per ricevere quelle apportate dagli altri utenti.
Se si sta lavorando a delle modifiche, il comando <command>svn update</command>
deve integrare le eventali modifiche avvenute sul repository
- in quelle sui cui si sta lavroando, piuttosto che forzare a pubblicarle.
+ in quelle sui cui si sta lavorando, piuttosto che forzare la pubblicazione.
</para>
@@ -797,10 +797,10 @@
themselves are versioned.</para>
<para>La conseguenza principale di questa regola è che implica
- che una copia di lavoro deve fare un lavoro in più per tener traccia
- delle diverse revisioni, e deve anche tollerare le le diversità stesse.
+ che una copia di lavoro debba compiere attività supplementari per tener traccia
+ delle diverse revisioni, oltre a tollerare le diversità stesse.
Ciò inoltre è reso più complicato dal fatto che anche le
- directory stesse sono versionate.
+ directory stesse sono sotto controllo di versione.
</para>
<para lang="en">For example, suppose you have a working copy entirely at
@@ -842,12 +842,12 @@
D'altronde, se il comando <command>svn commit</command> scaricasse
automaticamente le nuove modifiche dal repository, allora sarebbe possibile
allineare tutta la copia di lavoro alla revisone 15— ma si verrebbe
- così ad infrangere la regola fondamentale che impone a "PUSH" E "PULL"
+ così ad infrangere la regola fondamentale che impone a invio e ricezione
di essere azioni separate. Quindi l'unica cosa sicura che il client
di Subversion può fare è ricordare che il file — <filename>foo.html</filename>—
- è della revisione 15. Il resto della copia di lavorazione rimane alla revisione 10.
+ è aggiornato alla revisione 15. Il resto della copia di lavorazione rimane alla revisione 10.
Solo eseguendo un <command>svn update</command> si possono scaricare
- gli utlimissim cambiamenti, e tutta la copia di lavorazione
+ gli utlimissimi cambiamenti, e tutta la copia di lavorazione
sarà contrassegnata alla revisone 15.
</para>
@@ -855,7 +855,7 @@
<sect3 id="svn.basic.in-action.mixedrevs.normal">
<!-- title>Mixed revisions are normal</title -->
- <title>E' normale avere reivisioni mischiate</title>
+ <title>E' normale avere revisioni miste</title>
<para lang="en">The fact is, <emphasis>every time</emphasis> you
run <command>svn commit</command>, your working copy ends
@@ -902,10 +902,10 @@
Spesso i nuovi utenti ignorano completamente che la loro copia di
lavorazione contiene diverse revisioni. Ciò può generare confusione,
perchè molti comandi sono sensibili alla revisione di lavorazione
- degli oggetti che devono esminare. Per esempio, il comando
+ degli oggetti che devono esaminare. Per esempio, il comando
<command>svn log</command> viene utilizzato per mostrare la storia
dei cambiamenti di un file o una directory (vedere <xref linkend="svn.tour.history.log"/>).
- Quando un utente invoca questo comando sulla copia di lavorazione
+ Quando un utente invoca questo comando sulla copia di lavoro
di un oggetto, si aspetta di vedere l'intera storia dell'oggetto stesso.
In realtà se la revisione di lavorazione è puittosto vecchia
(solitamente perchè non si è usato il comando <command>svn update</command>
@@ -934,8 +934,8 @@
forzare alcune porzioni della copia di lavorazione a
<quote>retrocedere</quote> a versioni precedenti;
nel Capitolo 3 si potrà vedere come fare. Si potrebbe voler
- testare una versione precedete di qualche componente contenuta
- in una sotto directory; oppure si vorrebbe capire quando un bug
+ testare una versione precedente di qualche componente contenuta
+ in una sotto directory; oppure si vorrebbe capire quando un difetto
è comparso per la prima volta in un certo file.
Questo è l'aspetto di un sistema di controllo delle versioni
che lo caratterizza come una <quote>macchina del tempo</quote> —
@@ -954,7 +954,7 @@
flexibility.</para>
<para>Qualunque uso si faccia delle revisioni miste nella
- copia di lavorazione, ci sono sempre delle limitazioni
+ copia di lavoro, ci sono sempre delle limitazioni
a questa flessibilità.</para>
<para lang="en">First, you cannot commit the deletion of a file or
@@ -982,8 +982,8 @@
<para>Secondo, non è possibile effettuare la commit
della modifica di un metadato su una directory senza che questa
sia completamente aggiornata. Nel capitolo 6 si imparerà
- ad assegnare le <quote>proprietà</quote> agli oggetti.
- La revisione di lavorazione di una directory definisce un insieme
+ ad assegnare <quote>proprietà</quote> agli oggetti.
+ La revisione di lavoro di una directory definisce un insieme
specifico di voci e proprietà, quindi effettuare la commit
della modifica di una proprietà a una directory non aggiornata
potrebbe distruggere qualche proprietà che non è ancora stata vista.
@@ -1006,7 +1006,7 @@
<para lang="en">We've covered a number of fundamental Subversion concepts in
this chapter:</para>
- <para>In questo capitolo si sono affrontati alcuni concetti fondamentali di Subversion:</para>
+ <para>In questo capitolo sono stati affrontati alcuni concetti fondamentali di Subversion:</para>
<itemizedlist>
<listitem>
@@ -1014,7 +1014,7 @@
the client working copy, and the array of repository
revision trees.</para>
- <para>Si sono introdotte le nozioni di repository centrale,
+ <para>Sono state introdotte le nozioni di repository centrale,
copia di lavorazione e serie di alberi di revisione.</para>
</listitem>
@@ -1049,7 +1049,7 @@
<para>A questo punto, si dovrebbe avere una buona idea di come
lavora Subversion nel senso più generale.
Dotati di questa conoscenza si dovrebbe essere ora pronti a
- passare al prossimo capitolo, che rappresenta una visita
+ passare al prossimo capitolo, che rappresenta un'analisi
dettagliata dei comandi e delle caratteristiche di Subversion.
</para>
More information about the svnbook-dev
mailing list