[svnbook commit] r2318 - trunk/src/it/book
zup
noreply at red-bean.com
Fri Jul 14 14:35:28 CDT 2006
Author: zup
Date: Fri Jul 14 14:35:27 2006
New Revision: 2318
Modified:
trunk/src/it/book/ch02.xml
Log:
fixed maximum lines length.
Modified: trunk/src/it/book/ch02.xml
==============================================================================
--- trunk/src/it/book/ch02.xml (original)
+++ trunk/src/it/book/ch02.xml Fri Jul 14 14:35:27 2006
@@ -600,7 +600,9 @@
two essential pieces of information in the
<filename>.svn/</filename> administrative area:</para>
- <para>Per ogni file nella direcotory di lavoro, Subversion registra due porzioni di informazione essenziali nell' area di amministrazione <filename>.svn/</filename> :</para>
+ <para>Per ogni file nella direcotory di lavoro, Subversion registra
+ due porzioni di informazione essenziali nell' area di amministrazione
+ <filename>.svn/</filename>:</para>
<itemizedlist>
<listitem>
@@ -608,14 +610,16 @@
called the file's <firstterm>working
revision</firstterm>), and</para>
- <para>il numero di revisione su cui è basata la copia di lavoro (detta <firstterm>revisione di lavoro</firstterm> del file), e </para>
+ <para>il numero di revisione su cui è basata la copia di lavoro
+ (detta <firstterm>revisione di lavoro</firstterm> del file), e </para>
</listitem>
<listitem>
<para lang="en">a timestamp recording when the local copy was last
updated by the repository.</para>
- <para>una marca temporale relativa a quando la copia locale è stata aggiornata con il repository</para>
+ <para>una marca temporale relativa a quando la copia locale è stata
+ aggiornata con il repository</para>
</listitem>
</itemizedlist>
@@ -623,7 +627,9 @@
Subversion can tell which of the following four states a
working file is in:</para>
- <para>Date queste informazioni, comunicando con il repository, Subversion può decidere in quale dei seguenti quattro stati si trova un file nella copia di lavoro: </para>
+ <para>Date queste informazioni, comunicando con il repository,
+ Subversion può decidere in quale dei seguenti quattro stati
+ si trova un file nella copia di lavoro: </para>
<variablelist>
@@ -639,8 +645,11 @@
<command>svn update</command> of the file will do
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> del file non farà nulla, e un comando <command>svn update</command> del file non farà nulla.</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>
+ del file non farà nulla, e un comando <command>svn update</command>
+ del file non farà nulla.</para>
</listitem>
</varlistentry>
@@ -656,9 +665,14 @@
thus an <command>svn commit</command> of the file will
succeed in publishing your changes, and an <command>svn
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 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.</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
+ 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.
+ </para>
</listitem>
</varlistentry>
@@ -674,10 +688,14 @@
commit</command> of the file will do nothing, and an
<command>svn update</command> of the file will fold the
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 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 caricherà gli ultimi cambiamenti nella copia di lavoro.</para>
+
+ <para>Il file non è stato modificato nella directory di lavoro,
+ me 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
+ caricherà gli ultimi cambiamenti nella copia di lavoro.
+ </para>
</listitem>
</varlistentry>
@@ -694,9 +712,16 @@
changes. If Subversion can't complete the merge in a
plausible way automatically, it leaves it to the user to
resolve the conflict.</para>
- <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 <command>svn update</command> tenterà di incorporare le modifiche pubbliche con le modifiche locali.
- Se Subversion non può completare la fusione automatica in un modo coerente, lascerà all'utente il compito di risolvere il conflitto.
+
+ <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
+ <command>svn update</command> tenterà di incorporare
+ le modifiche pubbliche con le modifiche locali.
+ Se Subversion non può completare la fusione automatica
+ in un modo coerente, lascerà all'utente il compito di
+ risolvere il conflitto.
</para>
</listitem>
</varlistentry>
@@ -708,8 +733,11 @@
of any item in your working copy. For more information on
that command, see <xref linkend="svn.tour.cycle.examine.status" />.</para>
- <para>Potrebbe sembrare eccessivo tenter tracca di tutto questo, ma il comando <command>svn status</command> mostrerà la stato di ogni elemento nella copia di lavoro.
- Per altre informazioni su questo comando, si veda <xref linkend="svn.tour.cycle.examine.status" />.
+ <para>Potrebbe sembrare eccessivo tenter tracca di tutto questo,
+ ma il comando <command>svn status</command> mostrerà la stato
+ di ogni elemento nella copia di lavoro.
+ Per altre informazioni su questo comando, si veda
+ <xref linkend="svn.tour.cycle.examine.status" />.
</para>
</sect2>
@@ -727,9 +755,14 @@
the earlier example showing mixed revisions perplexed you,
here's a primer on both why the feature exists and how to make
use of it.</para>
- <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.
- Sfortunatamente questa flessibilità tende a confondere alcuni utenti. Segue quindi un'introduzione sul perchè esiste questa caratteristica e su come utilizzarla.
+
+ <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.
+ Sfortunatamente questa flessibilità tende a confondere alcuni utenti.
+ Segue quindi un'introduzione sul perchè esiste questa caratteristica
+ e su come utilizzarla.
</para>
<sect3 id="svn.basic.in-action.mixedrevs.update-commit">
@@ -745,9 +778,14 @@
then <command>svn update</command> should gracefully merge
repository changes into your own, rather than forcing you to
publish them.</para>
- <para>Una delle regole fondamentali di Subversion è che un'azione di <quote>invio</quote> non causa una <quote>ricezione</quote>, nè viceversa.
- Il fatto che ci siano le condizioni per inviare nuove modifiche al repository non significa che si sia pronti 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
+
+ <para>Una delle regole fondamentali di Subversion è che un'azione
+ di <quote>invio</quote> non causa una <quote>ricezione</quote>,
+ nè viceversa. Il fatto che ci siano le condizioni per inviare
+ nuove modifiche al repository non significa che si sia pronti
+ 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.
</para>
@@ -758,8 +796,11 @@
made more complicated by the fact that directories
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. Ciò inoltre è reso più complicato dal fatto che anche le directory stesse sono versionate.
+ <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.
+ Ciò inoltre è reso più complicato dal fatto che anche le
+ directory stesse sono versionate.
</para>
<para lang="en">For example, suppose you have a working copy entirely at
@@ -787,16 +828,27 @@
can the latest changes be downloaded, and the whole working
copy be marked as revision 15.</para>
- <para>Ad esempio, si suppone di avere una copia di lavoro completamente allineata alla revisione 10. Il file <filename>foo.html</filename>
- viene modificato e successivamente viene eseguito un <command>svn commit</command> il quale crea la revisione numero 15 nel repository.
- Visto l'esito positivo del comando di commit, molti utenti potrebbero pensare che la copia di lavorazione sia interamente allineata con la revisione 15, ma non è cosiì!
- Molti cambiamenti potrebbero essersi verificati nel repository tra la revisione 10 e la 15. Il client non sa nulla di questi cambiamenti in quanto
- non si è ancora eseguito il comando <command>svn update</command>, e il comando <command>svn commit</command> non riceve nessun cambiamento.
- 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"
- 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. Solo eseguendo un <command>svn update</command> si possono scaricare
- gli utlimissim cambiamenti, e tutta la copia di lavorazione sarà contrassegnata alla revisone 15.
+ <para>Ad esempio, si suppone di avere una copia di lavoro completamente
+ allineata alla revisione 10. Il file <filename>foo.html</filename>
+ viene modificato e successivamente viene eseguito un
+ <command>svn commit</command> il quale crea la revisione numero 15 nel repository.
+ Visto l'esito positivo del comando di commit, molti utenti potrebbero
+ pensare che la copia di lavorazione sia interamente allineata con la
+ revisione 15, ma non è così! Molti cambiamenti potrebbero essersi verificati
+ nel repository tra la revisione 10 e la 15.
+ Il client non sa nulla di questi cambiamenti in quanto
+ non si è ancora eseguito il comando <command>svn update</command>,
+ e il comando <command>svn commit</command> non riceve nessun cambiamento.
+ 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"
+ 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.
+ Solo eseguendo un <command>svn update</command> si possono scaricare
+ gli utlimissim cambiamenti, e tutta la copia di lavorazione
+ sarà contrassegnata alla revisone 15.
</para>
</sect3>
@@ -818,11 +870,16 @@
<xref linkend="svn.tour.cycle.examine.status"/> for more
information.)</para>
- <para>Di fatto <emphasis>ogni volta</emphasis> che si esegue il comando <command>svn commit</command>
- la copia di lavorazione si viene a trovare in un insieme misto di revisioni. Gli elementi che sono appena stati inviati al repository avranno
- la revisione di lavorazione più alta di ogni altro. Dopo diversi commit (senza operazioni di aggiornamento intermedie) la copia di lavorazione
- conterrà una vasta combinazione di revisioni. Anche se una sola persona sta usando il repository, si continuerà a verficare questo fenomeno.
- Per esaminare la miscela delle revisioni di lavorazione, si può usare il comando <command>svn status --verbose</command>
+ <para>Di fatto <emphasis>ogni volta</emphasis> che si esegue
+ il comando <command>svn commit</command> la copia di lavorazione
+ si viene a trovare in un insieme misto di revisioni.
+ Gli elementi che sono appena stati inviati al repository avranno
+ la revisione di lavorazione più alta di ogni altro.
+ Dopo diversi commit (senza operazioni di aggiornamento intermedie)
+ la copia di lavorazione conterrà una vasta combinazione di revisioni.
+ Anche se una sola persona sta usando il repository, si continuerà
+ a verficare questo fenomeno. Per esaminare la miscela delle revisioni
+ di lavorazione, si può usare il comando <command>svn status --verbose</command>
(per maggiori informazioni vedere <xref linkend="svn.tour.cycle.examine.status"/>).
</para>
@@ -842,13 +899,18 @@
shown.</para>
<para>
- 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 <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 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> da molto tempo),
- allora viene mostrata la storia della <emphasis>precedente</emphasis> versione dell'oggetto.
-
+ 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
+ <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
+ 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>
+ da molto tempo), allora viene mostrata la storia della
+ <emphasis>precedente</emphasis> versione dell'oggetto.
</para>
</sect3>
@@ -868,11 +930,17 @@
the feature which allows you to move any portion of your
working copy forward and backward in history.</para>
- <para>Se il progetto è piuttosto complesso, a volte è meglio 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 è 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> — questa è caratteristica che permette di muovere ogni porzione della copia di lavorazione
- avanti e indietro nella storia.
+ <para>Se il progetto è piuttosto complesso, a volte è meglio
+ 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
+ è 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> —
+ questa è caratteristica che permette di muovere ogni porzione
+ della copia di lavorazione avanti e indietro nella storia.
</para>
</sect3>
@@ -885,7 +953,9 @@
working copy, there are limitations to this
flexibility.</para>
- <para>Qualunque uso si faccia delle revisioni miste nella copia di lavorazione, ci sono sempre delle limitazioni a questa flessibilità.</para>
+ <para>Qualunque uso si faccia delle revisioni miste nella
+ copia di lavorazione, ci sono sempre delle limitazioni
+ a questa flessibilità.</para>
<para lang="en">First, you cannot commit the deletion of a file or
directory which isn't fully up-to-date. If a newer
@@ -894,9 +964,11 @@
accidentally destroying changes you've not yet
seen.</para>
- <para>Primo, non si può effettuare la commit della cancellazione di un file o directory che non sia completamente aggiornato.
- Se nel repository esiste una versione più recente, il tentativo di elimnazione verrà rifiutato, per evitare la distruzione accidentale
- di modifiche che non si sono ancora viste.</para>
+ <para>Primo, non si può effettuare la commit della cancellazione
+ di un file o directory che non sia completamente aggiornato.
+ Se nel repository esiste una versione più recente, il tentativo
+ di elimnazione verrà rifiutato, per evitare la distruzione accidentale
+ di modifiche che non si sono ancora viste.</para>
<para lang="en">Second, you cannot commit a metadata change to a
directory unless it's fully up-to-date. You'll learn
@@ -907,10 +979,14 @@
change to an out-of-date directory may destroy properties
you've not yet seen.</para>
- <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 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.
+ <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
+ 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.
</para>
</sect3>
@@ -938,7 +1014,8 @@
the client working copy, and the array of repository
revision trees.</para>
- <para>Si sono introdotte le nozioni di repository centrale, copia di lavorazione e serie di alberi di revisione.</para>
+ <para>Si sono introdotte le nozioni di repository centrale,
+ copia di lavorazione e serie di alberi di revisione.</para>
</listitem>
@@ -948,8 +1025,9 @@
another, using the <quote>copy-modify-merge</quote>
model.</para>
- <para>Si è visto qualche semplice esempio di come due collaboratori possono usare Subversion per pubblicare e ricevere
- le modifiche da uno all'altro secono il modello <quote>copia-modifica-integra</quote>.
+ <para>Si è visto qualche semplice esempio di come due collaboratori
+ possono usare Subversion per pubblicare e ricevere le modifiche
+ da uno all'altro secono il modello <quote>copia-modifica-integra</quote>.
</para>
</listitem>
@@ -957,7 +1035,8 @@
<para lang="en">We've talked a bit about the way Subversion tracks and
manages information in a working copy.</para>
- <para>Si è parlato di come Subversion traccia e gestisce le informazioni in una copia di lavorazione</para>
+ <para>Si è parlato di come Subversion traccia e gestisce
+ le informazioni in una copia di lavorazione</para>
</listitem>
</itemizedlist>
@@ -967,9 +1046,11 @@
should now be ready to jump into the next chapter, which is a
detailed tour of Subversion's commands and features.</para>
- <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 dettagliata dei comandi e delle caratteristiche
- di Subversion.
+ <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
+ dettagliata dei comandi e delle caratteristiche di Subversion.
</para>
</sect1>
More information about the svnbook-dev
mailing list