[svnbook commit] r2410 - trunk/src/it/book
bpietro
noreply at red-bean.com
Sat Sep 9 07:40:11 CDT 2006
Author: bpietro
Date: Sat Sep 9 07:40:11 2006
New Revision: 2410
Modified:
trunk/src/it/book/appc.xml
trunk/src/it/book/ch04.xml
Log:
corrected some typos (ch04 & appc)
Modified: trunk/src/it/book/appc.xml
==============================================================================
--- trunk/src/it/book/appc.xml (original)
+++ trunk/src/it/book/appc.xml Sat Sep 9 07:40:11 2006
@@ -20,7 +20,7 @@
linkend="svn.developer.usingapi.otherlangs"/>) fanno di lui probabile
candidato per uso come una estensione o backend per altri programmi.
Per la lista di molti strumenti da terzi che usano le funzionalità di
- Subversion dietro le quinte, controllate la pagina di likn sul sito web di
+ Subversion dietro le quinte, controllate la pagina di link sul sito web di
Subversion (<ulink
url="http://subversion.tigris.org/project_links.html"/>).</para>
Modified: trunk/src/it/book/ch04.xml
==============================================================================
--- trunk/src/it/book/ch04.xml (original)
+++ trunk/src/it/book/ch04.xml Sat Sep 9 07:40:11 2006
@@ -3022,7 +3022,7 @@
piece of software is a particular subdirectory of revision
4822.</para>
- <para>However, gente spesso vuole dare alle targe nomi più
+ <para>??However?, gente spesso vuole dare alle targe nomi più
comprensibili, come <literal>release-1.0</literal>. E vogliono
fare instantanee di sottocartelle più piccole. Dopo tutto,
non è così facile ricordarsi che rilascio-1.0 d'un pezzo
@@ -3208,10 +3208,10 @@
snapshot of your working copy—mixed revisions, URLs,
and all.</para>
- <para>Now there is a new directory in the repository,
- <filename>/calc/tags/mytag</filename>, which is an exact
- snapshot of your working copy—mixed revisions, URLs,
- and all.</para>
+ <para>Adesso nel deposito c'è una nuova cartella,
+ <filename>/calc/tags/mytag</filename>, che è un'instantanea
+ esatta della vostra copia di lavoro—revisioni miste, URL,
+ e tutto il resto.</para>
<para lang="en">Other users have found interesting uses for this feature.
Sometimes there are situations where you have a bunch of local
@@ -3225,17 +3225,17 @@
working copy, or use <command>svn merge</command> to receive
your exact changes.</para>
- <para>Other users have found interesting uses for this feature.
- Sometimes there are situations where you have a bunch of local
- changes made to your working copy, and you'd like a
- collaborator to see them. Instead of running <command>svn
- diff</command> and sending a patch file (which won't capture
- tree changes, symlink changes or changes in properties), you can
- instead use <command>svn copy</command> to <quote>upload</quote>
- your working copy to a private area of the repository. Your
- collaborator can then either checkout a verbatim copy of your
- working copy, or use <command>svn merge</command> to receive
- your exact changes.</para>
+ <para>Altri utenti hanno trovato usi interessanti per questa caratteristica.
+ Di tanto in tanto sono le situazioni avete una manciata delle
+ modifiche locali fatte sulla vostra copia di lavoro e volete
+ farle vedere ai vostri collaboratori. Invece di usare
+ <command>svn diff</command> e mandarli file patch (che non può
+ catturare cambiamenti di cartelle, llink simbolici oppure
+ cambiamenti delle proprietà) potete usare <command>svn copy</command>
+ per <quote>caricare</quote> la vostra copia di lavoro nella
+ area privata del deposito. Vostro collaboratore può poi
+ o tirarsi fuori una copia identica (checkout) o usare
+ <command>svn merge</command> per ricevere le vostre modifiche.</para>
</sect2>
@@ -3261,8 +3261,8 @@
sottostante (copiatura delle cartelle) e perché rami e targhe
appaiono nello spazio ordinario del filesistem, molte persone
trovano Subversion spaventoso. È quasi <emphasis>troooopo</emphasis>
- flessibile. In this section, we'll offer some suggestions for
- arranging and managing your data over time.</para>
+ flessibile. In questa sezione vi offriamo alcune suggestioni di come
+ arrangiare e mantenere i vostri dati nel corso del tempo.</para>
<!-- =============================================================== -->
<sect2 id="svn.branchmerge.maint.layout">
@@ -3277,13 +3277,13 @@
tag copies. If a repository holds only one project, then
often people create these top-level directories:</para>
- <para>There are some standard, recommended ways to organize a
- repository. Most people create a <filename>trunk</filename>
- directory to hold the <quote>main line</quote> of development,
- a <filename>branches</filename> directory to contain branch
- copies, and a <filename>tags</filename> directory to contain
- tag copies. If a repository holds only one project, then
- often people create these top-level directories:</para>
+ <para>Ci sono alcuni standard, modi raccommandati per organizzare
+ un deposito. Molti creano una cartella <filename>trunk</filename>
+ per contenere <quote>linea principale</quote> dello sviluppo,
+ una cartella <filename>branches</filename> per contenere i rami
+ e una cartella <filename>tags</filename> per contenere le targhe.
+ Quando il deposito contiene solo un progetto, allora si creano
+ queste cartelle di alto livello:</para>
<screen>
/trunk
@@ -3296,10 +3296,10 @@
linkend="svn.reposadmin.projects.chooselayout"/> to read more about
<quote>project roots</quote>):</para>
- <para>If a repository contains multiple projects, admins
- typically index their layout by project (see <xref
- linkend="svn.reposadmin.projects.chooselayout"/> to read more about
- <quote>project roots</quote>):</para>
+ <para>Quando il deposito contiene più progetti, amministratori tipicamente
+ dividono la disposizione secondo i progetti (vedi <xref
+ linkend="svn.reposadmin.projects.chooselayout"/> per leggere di più
+ riguardo ??<quote>project roots</quote>?):</para>
<screen>
/paint/trunk
@@ -3344,7 +3344,7 @@
switch</command> to the new location.
</para>
- <para>Remember, though, that while moving directories may be
+ <para>Ricordatevi, though, that while moving directories may be
easy to do, you need to be considerate of your users as well.
Your juggling can be disorienting to users with existing
working copies. If a user has a working copy of a particular
@@ -3372,20 +3372,25 @@
no need for your private branch directory to stick around
anymore:</para>
- <para>Another nice feature of Subversion's model is that
- branches and tags can have finite lifetimes, just like any
- other versioned item. For example, suppose you eventually
- finish all your work on your personal branch of the
- <filename>calc</filename> project. After merging all of your
- changes back into <filename>/calc/trunk</filename>, there's
- no need for your private branch directory to stick around
- anymore:</para>
+ <para>Altra bella caratteristica del modello Subversionè che
+ i rami e targhe hanno la vita limitata, come qualsiasi altro
+ articolo[pezzo] versionato. Per esempio, supponiamo che
+ avete finito lavoro su vostro ramo personale di progetto
+ <filename>calc</filename>. Dopo fusione delle tutte vostre
+ modifiche indietro nel <filename>/calc/trunk</filename>,
+ non c'è più ragione per la essistenza del ramo privato:</para>
- <screen>
+<!-- <screen>
$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Removing obsolete branch of calc project."
Committed revision 375.
+</screen>-->
+<screen>
+ $ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
+ -m "Rimosso ramo obsoletto del progetto calc."
+
+ Committed revision 375.
</screen>
<para lang="en">And now your branch is gone. Of course it's not really
@@ -3439,19 +3444,19 @@
a <quote>stable</quote> branch of the software that won't
change much:</para>
- <para>In our example, your personal branch had a relatively
- short lifetime: you may have created it to fix a bug or
- implement a new feature. When your task is done, so is the
- branch. In software development, though, it's also common to
- have two <quote>main</quote> branches running side-by-side for
- very long periods. For example, suppose it's time to release
- a stable version of the <filename>calc</filename> project to the
- public, and you know it's going to take a couple of months to
- shake bugs out of the software. You don't want people to add
- new features to the project, but you don't want to tell all
- developers to stop programming either. So instead, you create
- a <quote>stable</quote> branch of the software that won't
- change much:</para>
+ <para>Nel nostro esempio, vostro ramo personale aveva la vita
+ relativamente breve: lo avete creato per bug fix o sviluppo
+ d'una nuova caratteristica. Quando vostro lavoro era fatto,
+ era finito anche il ramo. Nello sviluppo di software, invece,
+ è comune di avere due <quote>principali</quote> rami
+ affiancati per lungo periodo di tempo. Per esempio, supponiamo
+ che è giunta ora di rilasciare la versione stabile di progetto
+ <filename>calc</filename> al pubblico, e voi sapete che ci vorrà
+ qualche mese per cacciare via dal software gli errori.
+ Non volete che la gente aggiunga nuove caratteristiche al progetto,
+ ma non volete neanche fermare gli sviluppatori.
+ Allora, create un ramo<quote>stable</quote> del software
+ che non cambierà molto:</para>
<screen>
$ svn copy http://svn.example.com/repos/calc/trunk \
@@ -3472,16 +3477,17 @@
maintain the branch for a long time—that is, as long
as you continue to support that release for customers.</para>
- <para>And now developers are free to continue adding
- cutting-edge (or experimental) features to
- <filename>/calc/trunk</filename>, and you can declare a
- project policy that only bug fixes are to be committed to
- <filename>/calc/branches/stable-1.0</filename>. That is, as
- people continue to work on the trunk, a human selectively
- ports bug fixes over to the stable branch. Even after the
- stable branch has shipped, you'll probably continue to
- maintain the branch for a long time—that is, as long
- as you continue to support that release for customers.</para>
+ <para>Adesso gli sviluppatori sono liberi di continuare ad
+ aggiungere caratteristiche ??cutting-edge? (o sperimentali)
+ al <filename>/calc/trunk</filename>, e voi potete stabilire
+ la regola del progetto che solo i bug fix possono essere
+ pubblicati nel <filename>/calc/branches/stable-1.0</filename>.
+ Proprio così, mentre continua il lavoro sul tronco,
+ qualcuno a mano porta selettivamente i bug fix sul ramo
+ stabile. Anche dopo la uscita del ramo stabile al pubblico,
+ probabilmente continuerete mantenere il ramo per lungo
+ tempo—finché continuerà il supporto di questa versione
+ per i clienti.</para>
</sect2>
More information about the svnbook-dev
mailing list