[svnbook commit] r2412 - trunk/src/it/book
bpietro
noreply at red-bean.com
Mon Sep 11 07:31:09 CDT 2006
Author: bpietro
Date: Mon Sep 11 07:31:09 2006
New Revision: 2412
Modified:
trunk/src/it/book/ch04.xml
Log:
first proofread (cca half of it)
Modified: trunk/src/it/book/ch04.xml
==============================================================================
--- trunk/src/it/book/ch04.xml (original)
+++ trunk/src/it/book/ch04.xml Mon Sep 11 07:31:09 2006
@@ -9,7 +9,7 @@
you are familiar, then hopefully you'll find it interesting to
see how Subversion implements these ideas.</para>
- <para>Ramificazioni, etichette e fusioni sono concetti comuni a
+ <para>Ramificazioni, targhe(etichette) e fusioni sono concetti comuni a
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
@@ -56,7 +56,7 @@
<para>Che cosa fatte in questa situazione? Una cosa ovvia:
fatte la seconda copia del vostro documento e cominciate mantenere
le due copie separatamente. Quando uno o altro dipartimento
- chede di fare modifiche, voi le fatte in una o altra copia.</para>
+ chede di fare modifiche, voi le fatte nell'una o l'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
@@ -67,7 +67,7 @@
<para>Spesso vi capita di dover fare lo stesso cambiamento in tutte e due
copie. Per es. avete scoperto errore di battitura nella prima copia,
molto probabilmente lo stesso errore è anche nell'altra. Dopo tutto,
- le due copie sono quasi identiche, diferiscono solo nelle piccole,
+ le due copie sono quasi identiche, differiscono solo nelle piccole,
specifiche parti.</para>
<para lang="en">This is the basic concept of a
@@ -79,7 +79,7 @@
linkend="svn.branchmerge.whatis.dia-1"/>).</para>
<para>Questo è il concetto base di
- <firstterm>ramo</firstterm>—leteralmente, una linea di
+ <firstterm>ramo</firstterm>—leteralmente una linea di
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
@@ -123,8 +123,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 <xref linkend="svn.basic.in-action.revs"/>.</para>
+ <quote>revisione</quote>). Se no, tornate a leggere riguardo le
+ revisioni la <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
@@ -139,7 +139,7 @@
Ricordate che voi e vostra collaboratrice, Sally, state condividere
un deposito che contiene due progetti,
<filename>paint</filename> e <filename>calc</filename>.
- Da notare che in <xref linkend="svn.branchmerge.using.dia-1"/>, comunque,
+ Da notare che nella <xref linkend="svn.branchmerge.using.dia-1"/>, comunque,
ogni cartella di progetto adesso contiene sottocartelle denominate
<filename>trunk</filename> e <filename>branches</filename>.
La ragione di ciò diventa presto chiara.</para>
@@ -186,8 +186,8 @@
nell progetto. Il problema è che voi non volete interferire con lavoro di
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 a Sally.</para>
+ è sempre usabile. Se voi cominciate pubblicare i vostri cambiamenti
+ 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
@@ -226,9 +226,9 @@
(magari avete le copie di lavoro del <filename>/calc/trunk</filename>
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
- nel sviluppo del software è permettere a vostri compagni di vedere
+ E per la stessa ragione, è difficile condividere i vostri cambiamenti in corso
+ con qualcun altro. <quote>La regola d'arte</quote> comune
+ nel sviluppo del software è permettere ai vostri compagni di vedere
il vostro lavoro man mano come procede. Se nessuno vede i vostri
commit intermediari, avete perso potenziale ??feedback?.
Alla fine, quando avete finito con tutti i vostri cambiamenti,
@@ -247,8 +247,8 @@
on.</para>
<para>La soluzione migliore è creare vostro ramo, o linea di
- sviluppo, nel deposito. Questo vi permette di salvare vostro
- lavoro fatto-a-metà[??incompiuto?] frequentemente senza interferire con altri,
+ sviluppo, nel deposito. Questo vi permette di salvare frequentemente
+ vostro lavoro incompiuto 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>
@@ -278,8 +278,8 @@
Subversion è capace non solo di copiare i singoli file,
ma anche intere cartelle. Nel nostro caso, volete fare una copia
della cartella <filename>/calc/trunk</filename>. Dove la mettiamo?
- Dovunque desideriate—è un aspetto di politica del progetto.
- Diciamo che il vostro team ha stabilito la politica di creare rami
+ Dovunque desideriate—è un aspetto di regole del progetto.
+ Diciamo che il vostro gruppo ha stabilito la regola di creare rami
nella area del deposito <filename>/calc/branches</filename>,
e voi volete chiamare vostro ramo <literal>my-calc-branch</literal>.
State per creare nuova cartella,
@@ -340,9 +340,9 @@
nella nuova cartella di lavoro, <filename>branches/my-calc-branch</filename>.
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
+ al deposito. Notare anche che il segno <quote>+</quote> vicino la lettera
A. Questo indica che la aggiunta pianificata è una <emphasis>copia</emphasis>
- di qualcosa, non qualcosa di nuovo. Quando fatte il commit degli vostri
+ di qualcosa, non qualcosa di nuovo. Quando pubblicate i vostri
cambiamenti, Subversion creerà
<filename>/calc/branches/my-calc-branch</filename> nel deposito
copiando <filename>/calc/trunk</filename>, invece di re-inviare tramite
@@ -390,7 +390,7 @@
<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
+ Come mostrato nella <xref
linkend="svn.branchmerge.using.create.dia-1"/>. Notare che il secondo
metodo, tuttavia, fa anche commit <emphasis>immediato</emphasis>.
<footnote>
@@ -400,8 +400,8 @@
copiare elementi solo dentro lo stesso deposito.</para>
</footnote>
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>
+ checkout di grande parte del deposito. Infatti, questa tecnica addirittura
+ non richiede neanche di avere una copia di lavoro.</para>
<figure id="svn.branchmerge.using.create.dia-1">
<title>Deposito con la nuova copia</title>
@@ -448,9 +448,9 @@
documents.)</para>
<para>E per questo spesso sentirette utenti di Subversion parlare
- delle <quote>copie economiche</quote>. Non importa quanto è
+ delle <quote>copie a basso costo</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à di 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.
@@ -505,7 +505,7 @@
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>.
- (Assicuratevi di leggere <xref
+ (Assicuratevi di leggere la <xref
linkend="svn.branchmerge.switchwc"/> più avanti in questo capitolo:
il comando <command>svn switch</command> è un modo alternativo di creare
copia di lavoro di un ramo.)</para>
@@ -538,13 +538,13 @@
<itemizedlist>
<listitem><para>
- Fatte modifica di
+ Fatta la modifica di
<filename>/calc/branches/my-calc-branch/button.c</filename>,
che crea revisione 342.</para>
</listitem>
<listitem><para>
- Fatte modifica di
+ Fatta la modifica di
<filename>/calc/branches/my-calc-branch/integer.c</filename>,
che crea revisione 343.</para>
</listitem>
@@ -561,7 +561,7 @@
<filename>integer.c</filename>.</para>
<para>Ci sono adesso due linee di sviluppo independenti, mostrate
- in <xref linkend="svn.branchmerge.using.work.dia-1"/>, che toccano
+ nella <xref linkend="svn.branchmerge.using.work.dia-1"/>, che toccano
<filename>integer.c</filename>.</para>
<!-- <figure id="svn.branchmerge.using.work.dia-1">
@@ -692,7 +692,7 @@
<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
+ <para>Ci sono due lezioni importanti che dovete ricordare
da questa sezione.</para>
<orderedlist>
@@ -702,7 +702,7 @@
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,
+ <para>Diversamente da molti altri sistemi di controllo delle versioni,
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
@@ -743,8 +743,8 @@
development.</para>
<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>
+ voi lavorate su un ramo privato e Sally lavora su <firstterm>tronco</firstterm>
+ (<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.
@@ -754,10 +754,10 @@
complete.</para>
<para>Per progetti che hanno grande numero di contribuenti, è comune
- per molta gente di avere copie di lavoro del trunk.
+ per molta gente di avere copie di lavoro del tronco.
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
+ che potrebbero disturbare il tronco, procedura standard è di creare
+ un ramo privato e pubblicare 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
@@ -769,7 +769,7 @@
without a huge number of conflicts.</para>
<para>Allora, la notizia buona è che voi e Sally non vi disturbate
- a vicenda. La notizia cativa è che è molto facile slittare
+ a vicenda. La 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
@@ -783,12 +783,12 @@
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
+ <para>Invece, voi e Sally potette 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>
+ può essere copiato dietro nel tronco.</para>
<!-- =============================================================== -->
@@ -813,11 +813,11 @@
<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
+ Senza dubbio, vostra copia dello stesso file ancora ha gli stessi
+ errori. È probabile che le vostre future modifiche 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
+ Meglio incorporare le modifiche di Sally adesso,
<emphasis>prima</emphasis> che cominciate lavoro troppo pesante
sugli stessi posti.</para>
@@ -832,7 +832,7 @@
<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
+ Capitolo 3). Entrambi comandi sono capaci di comparare qualsiasi
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>
@@ -888,8 +888,8 @@
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
+ uguale. Invece di mostrare le differenze sullo schermo,
+ tuttavia, le applica direttamente nella vostra
copia di lavoro come <emphasis>modifiche locali</emphasis>:</para>
<screen>
@@ -911,7 +911,7 @@
<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
+ <quote>copiate</quote> dal tronco 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>
@@ -923,12 +923,12 @@
decide that the merge was a bad idea altogether, simply give up
and <command>svn revert</command> the local change.</para>
- <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
+ <para>In un altro scenario, è possibile che le cose possono non andare
+ così bene e perciò <filename>integer.c</filename> può entrare
+ nello stato di conflitto. Potette 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>
+ se decidete che fusione era del tutto una cativa idea,
+ semplicemente passare sopra 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
@@ -939,7 +939,7 @@
<firstterm>porting</firstterm> changes.</para>
<para>Ma assumendo che avete ispezionato le modifiche incorporate,
- potete pubblicare modifica con <command>svn commit</command>
+ potete pubblicarle 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
@@ -963,7 +963,7 @@
<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
+ <para>Come vedrete nella prossima sezione, questa è molto importante
<quote>regola d'arte</quote> da seguire.</para>
<sidebar>
@@ -1024,7 +1024,7 @@
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
+ diff</command> mostra solo patch in un format0 limitato, così ci sono
alcune idee che semplicemente non può esprimere.
<footnote>
<para>In futuro, progetto Subversion pianifica du usare
@@ -1052,8 +1052,7 @@
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,
+ le modifiche della struttura. Se la destinazione non è specificata,
assume che state provando di fare una delle seguenti comuni
operazioni:</para>
@@ -1110,7 +1109,7 @@
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.copychanges.keyconcept">
<!-- <title>The Key Concept Behind Merging</title> -->
- <title>Concetto chiave dietro ??Merging?</title>
+ <title>Concetto chiave dietro la fusione</title>
<para lang="en">You've now seen an example of the <command>svn
merge</command> command, and you're about to see several
@@ -1126,14 +1125,14 @@
<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
+ la fusione, 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ù
+ Non avere paura, 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>
+ agisce.</para>
<para lang="en">The main source of confusion is the
<emphasis>name</emphasis> of the command. The term
@@ -1190,7 +1189,7 @@
<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.
+ alla copia di lavoro destinataria come modifiche 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>.
@@ -1224,7 +1223,7 @@
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
+ <para>La prima sintassi elenca 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
@@ -1304,10 +1303,10 @@
<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.
+ dovete tracciare 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
+ Come era dimostrato nel esempio precedente, è raccomandato
+ che vostro messaggio menziona 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.
@@ -1335,9 +1334,10 @@
<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>
-
+ 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
More information about the svnbook-dev
mailing list