X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=build.tex;h=5b5d460ccdc9fbea2434cae29d3ae15833b971ad;hp=a9f8b30f2bc6dc32cbab87c6bb9fb1ac9c0a440d;hb=193d612d40c5f81f5559ea6e11e70f6b6e51fb39;hpb=c4e84d074b7b59b920ab493e32d61d5f3ae2ff15

diff --git a/build.tex b/build.tex
index a9f8b30..5b5d460 100644
--- a/build.tex
+++ b/build.tex
@@ -17,7 +17,7 @@ che vengono utilizzati per programmare in ambito Linux, ed in particolare gli
 strumenti per la compilazione e la costruzione di programmi e librerie, e gli
 strumenti di gestione dei sorgenti e di controllo di versione.
 
-Questo materiale è ripreso da un vecchio articolo, ed al momento è molto
+Questo materiale è ripreso da un vecchio articolo, ed al momento è molto
 obsoleto.
 
 
@@ -28,7 +28,7 @@ Il comando \texttt{make} serve per automatizzare il processo di costruzione di
 un programma ed effettuare una compilazione intelligente di tutti i file
 relativi ad un progetto software, ricompilando solo i file necessari ed
 eseguendo automaticamente tutte le operazioni che possono essere necessarie
-alla produzione del risultato finale.\footnote{in realtà \texttt{make} non si
+alla produzione del risultato finale.\footnote{in realtà \texttt{make} non si
   applica solo ai programmi, ma in generale alla automazione di processi di
   costruzione, ad esempio anche la creazione dei file di questa guida viene
   fatta con \texttt{make}.}
@@ -38,42 +38,42 @@ alla produzione del risultato finale.\footnote{in realt
 \label{sec:make_intro}
 
 Con \texttt{make} si possono definire i simboli del preprocessore C che
-consentono la compilazione condizionale dei programmi (anche in Fortran); è
+consentono la compilazione condizionale dei programmi (anche in Fortran); è
 pertanto possibile gestire la ricompilazione dei programmi con diverse
 configurazioni con la modifica di un unico file.
 
 La sintassi normale del comando (quella che si usa quasi sempre, per le
-opzioni vedere la pagina di manuale) è semplicemente \texttt{make}. Questo
+opzioni vedere la pagina di manuale) è semplicemente \texttt{make}. Questo
 comando esegue le istruzioni contenute in un file standard (usualmente
 \texttt{Makefile}, o \texttt{makefile} nella directory corrente).
 
-Il formato normale dei comandi contenuti in un \texttt{Makefile} è:
+Il formato normale dei comandi contenuti in un \texttt{Makefile} è:
 \begin{verbatim}
 bersaglio: dipendenza1 dipendenza2 ...
         regola1
         regola2
         ...
 \end{verbatim}
-dove lo spazio all'inizio deve essere un tabulatore (metterci degli spazi è un
+dove lo spazio all'inizio deve essere un tabulatore (metterci degli spazi è un
 errore comune, fortunatamente ben segnalato dalle ultime versioni del
 programma), il bersaglio e le dipendenze nomi di file e le regole comandi di
 shell.
 
-Il concetto di base è che se uno dei file di dipendenza è più recente (nel
+Il concetto di base è che se uno dei file di dipendenza è più recente (nel
 senso di tempo di ultima modifica) del file bersaglio quest'ultimo viene
 ricostruito di nuovo usando le regole elencate nelle righe successive.
 
 Il comando \texttt{make} ricostruisce di default il primo bersaglio che viene
 trovato nella scansione del \texttt{Makefile}, se in un \texttt{Makefile} sono
-contenuti più bersagli indipendenti, si può farne ricostruire un altro che non
+contenuti più bersagli indipendenti, si può farne ricostruire un altro che non
 sia il primo passandolo esplicitamente al comando come argomento, con qualcosa
 del tipo di: \texttt{make altrobersaglio}.
 
 Si tenga presente che le dipendenze stesse possono essere dichiarate come 
-bersagli dipendenti da altri file; in questo modo è possibile creare una 
+bersagli dipendenti da altri file; in questo modo è possibile creare una 
 catena di ricostruzioni. 
 
-In esempio comune di quello che si fa è mettere come primo bersaglio il
+In esempio comune di quello che si fa è mettere come primo bersaglio il
 programma principale che si vuole usare, e come dipendenze tutte gli oggetti
 delle funzioni subordinate che utilizza, con i quali deve essere collegato; a
 loro volta questi oggetti sono bersagli che hanno come dipendenza i relativi
@@ -132,11 +132,11 @@ clean:
 \end{verbatim}
 \normalsize
 
-Anzitutto i commenti, ogni linea che inizia con un \texttt{\#} è un
+Anzitutto i commenti, ogni linea che inizia con un \texttt{\#} è un
 commento e non viene presa in considerazione.
 
 Con \texttt{make} possono essere definite delle variabili, da potersi riusare
-a piacimento, per leggibilità si tende a definirle tutte maiuscole,
+a piacimento, per leggibilità si tende a definirle tutte maiuscole,
 nell'esempio ne sono definite varie: \small
 \begin{verbatim}
 FC=g77
@@ -150,7 +150,7 @@ OBJ=cnoise.o fit2.o pedsig.o loop.o badstrp.o cutcn.o readevnt.o \
 \end{verbatim}
 \normalsize
 
-La sintassi è \texttt{NOME=}, alcuni nomi però hanno un significato speciale
+La sintassi è \texttt{NOME=}, alcuni nomi però hanno un significato speciale
 (nel caso \texttt{FC}, \texttt{FLAGS}, \texttt{CC}, \texttt{CFLAGS}) in quanto
 sono usati da \texttt{make} nelle cosiddette \textsl{regole implicite} (su cui
 torneremo dopo).
@@ -165,7 +165,7 @@ nel makefile abbiamo usato:
 \begin{verbatim}
         $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS) 
 \end{verbatim}
-e questo significa che la regola verrà trattata come se avessimo scritto 
+e questo significa che la regola verrà trattata come se avessimo scritto 
 esplicitamente i valori delle variabili.
 
 Veniamo ora alla parte principale del makefile che esegue la costruzione del
@@ -178,7 +178,7 @@ readfile.o: readfile.c
 $(OBJ): commondef.f
 \end{verbatim}
 
-Il primo bersaglio del makefile, che definisce il bersaglio di default, è il
+Il primo bersaglio del makefile, che definisce il bersaglio di default, è il
 programma di riduzione dei dati; esso dipende dal suo sorgente da tutti gli
 oggetti definiti dalla variabile \texttt{OBJ}, dal file di definizioni
 \texttt{commondef.f} e dalla routine C \texttt{readfile.o}; si noti il
@@ -193,48 +193,48 @@ librerie.
 Il secondo bersaglio definisce le regole per la compilazione della routine
 in C; essa dipende solo dal suo sorgente. Si noti che per la compilazione
 vengono usate le variabili relative al compilatore C. Si noti anche che se
-questa regola viene usata, allora lo sarà anche la precedente, dato che
+questa regola viene usata, allora lo sarà anche la precedente, dato che
 \texttt{riduzione} dipende da \texttt{readfile.o}.
 
-Il terzo bersaglio è apparentemente incomprensibile dato che vi compare
+Il terzo bersaglio è apparentemente incomprensibile dato che vi compare
 solo il riferimento alla variabile \texttt{OBJ} con una sola dipendenza e
-nessuna regola, essa però mostra le possibilità (oltre che la
-complessità) di \texttt{make} connesse alla presenza di quelle regole
+nessuna regola, essa però mostra le possibilità (oltre che la
+complessità) di \texttt{make} connesse alla presenza di quelle regole
 implicite a cui avevamo accennato.
 
-Anzitutto una peculiarità di \texttt{make} è che si possono anche usare più
+Anzitutto una peculiarità di \texttt{make} è che si possono anche usare più
 bersagli per una stessa regola (nell'esempio quelli contenuti nella variabile
 \texttt{OBJ} che viene espansa in una lista); in questo caso la regola di
-costruzione sarà applicata a ciascuno che si potrà citare nella regola stessa
+costruzione sarà applicata a ciascuno che si potrà citare nella regola stessa
 facendo riferimento con la variabile automatica: \texttt{\$@}.  L'esempio
-usato per la nostra costruzione però sembra non avere neanche la regola di
+usato per la nostra costruzione però sembra non avere neanche la regola di
 costruzione.
 
 Questa mancanza sia di regola che di dipendenze (ad esempio dai vari sorgenti) 
-illustra le capacità di funzionamento automatico di \texttt{make}.
-Infatti è facile immaginarsi che un oggetto dipenda da un sorgente, e che 
+illustra le capacità di funzionamento automatico di \texttt{make}.
+Infatti è facile immaginarsi che un oggetto dipenda da un sorgente, e che 
 per ottenere l'oggetto si debba compilare quest'ultimo.
 
-Il comando \texttt{make} sa tutto questo per cui quando un bersaglio è un
-oggetto (cioè ha un nome tipo \texttt{qualcosa.o}) non è necessario
+Il comando \texttt{make} sa tutto questo per cui quando un bersaglio è un
+oggetto (cioè ha un nome tipo \texttt{qualcosa.o}) non è necessario
 specificare il sorgente, ma il programma lo va a cercare nella directory
-corrente (ma è possibile pure dirgli di cercarlo altrove, il caso è trattato
-nel manuale).  Nel caso specifico allora si è messo come dipendenza solo il
+corrente (ma è possibile pure dirgli di cercarlo altrove, il caso è trattato
+nel manuale).  Nel caso specifico allora si è messo come dipendenza solo il
 file delle definizioni che viene incluso in ogni subroutine.
 
 Inoltre come dicevamo in genere per costruire un oggetto si deve compilarne il
 sorgente; \texttt{make} sa anche questo e sulla base dell'estensione del
-sorgente trovato (che nel caso sarà un \texttt{qualcosa.f}) applica la regola
-implicita.  In questo caso la regola è quella di chiamare il compilatore
+sorgente trovato (che nel caso sarà un \texttt{qualcosa.f}) applica la regola
+implicita.  In questo caso la regola è quella di chiamare il compilatore
 fortran applicato al file oggetto e al relativo sorgente, questo viene fatto
-usando la variabile \texttt{FC} che è una delle variabili standard usata dalle
+usando la variabile \texttt{FC} che è una delle variabili standard usata dalle
 regole implicite (come \texttt{CC} nel caso di file \texttt{.c}); per una
-maggiore flessibilità poi la regola standard usa anche la variabile
+maggiore flessibilità poi la regola standard usa anche la variabile
 \texttt{FFLAGS} per specificare, a scelta dell'utente che non ha che da
 definirla, quali flag di compilazione usare (nella documentazione sono
 riportate tutte le regole implicite e le relative variabili usate).
 
-In questo modo è stato possibile usare una sola riga per indicare la serie di
+In questo modo è stato possibile usare una sola riga per indicare la serie di
 dipendenze e relative compilazioni delle singole subroutine; inoltre con l'uso
 della variabile \texttt{OBJ} l'aggiunta di una nuova eventuale routine
 \texttt{nuova.f} comporta solo l'aggiunta di \texttt{nuova.o} alla definizione
@@ -244,60 +244,60 @@ di \texttt{OBJ}.
 \section{Source Control Management}
 \label{sec:build_scm}
 
-Uno dei problemi più comuni che si hanno nella programmazione è quella di
+Uno dei problemi più comuni che si hanno nella programmazione è quella di
 poter disporre di un sistema che consenta di tenere conto del lavoro
 effettuato, di tracciare l'evoluzione del codice, e, soprattutto nel caso di
-progetti portati avanti da più persone, consentire un accesso opportunamente
+progetti portati avanti da più persone, consentire un accesso opportunamente
 coordinato fra i vari partecipanti alla base comune dei sorgenti dello
 sviluppo.
 
 I programmi che servono a questo scopo vanno sotto il nome comune di SCM
 (\textit{Source Control Manager}), e ne esistono di diversi tipi con diverse
-filosofie progettuali, in particolare nelle modalità con cui gestiscono
+filosofie progettuali, in particolare nelle modalità con cui gestiscono
 l'accesso alla base di codice comune da parte dei singoli programmatori che vi
 accedono.
 
-Fra questi uno dei più usati, nonostante la sua architettura sia considerata
-superata, è Subversion, un sistema di archiviazione centralizzata del codice
+Fra questi uno dei più usati, nonostante la sua architettura sia considerata
+superata, è Subversion, un sistema di archiviazione centralizzata del codice
 che consente di tenere traccia di tutte le modifiche e di condividere un
 archivio comune per progetti portati avanti da diverse persone.
 
 \subsection{Introduzione a Subversion}
 \label{sec:build_subversion}
 
-Subversion è basato sul concetto di \textit{repository}, un archivio
+Subversion è basato sul concetto di \textit{repository}, un archivio
 centralizzato in cui vengono riposti e da cui vengono presi i sorgenti dei
 programmi. L'archivio tiene traccia delle diverse versioni registrate; i
 programmatori inviano le modifiche usando una copia locale che hanno nella
 loro directory di lavoro.
 
-Subversion può gestire più di un progetto all'interno di un singolo server,
+Subversion può gestire più di un progetto all'interno di un singolo server,
 ciascuno dei quali viene associato ad un \textit{repository} distinto, ma si
 possono anche creare sotto-progetti suddividendo un \textit{repository} in
-diverse directory; ma ciascun progetto avrà meccanismi di controllo (ad 
+diverse directory; ma ciascun progetto avrà meccanismi di controllo (ad 
 esempio quelli che consentono di inviare email all'inserimento di nuovo
 codice) comuni.
 
 Una delle caratteristiche che contraddistinguono Subversion dal suo
-predecessore CVS è quella di essere gestibile in maniera molto flessibile
-l'accesso al repository, che può avvenire sia in maniera diretta facendo
-riferimento alla directory in cui questo è stato installato che via rete,
-tramite diversi protocolli. L'accesso più comune è fatto direttamente via
-HTTP, utilizzando opportune estensioni del protocollo DAV, ma è possibile
+predecessore CVS è quella di essere gestibile in maniera molto flessibile
+l'accesso al repository, che può avvenire sia in maniera diretta facendo
+riferimento alla directory in cui questo è stato installato che via rete,
+tramite diversi protocolli. L'accesso più comune è fatto direttamente via
+HTTP, utilizzando opportune estensioni del protocollo DAV, ma è possibile
 passare attraverso SSH o fornire un servizio di rete dedicato.\footnote{esiste
-  all'uopo il programma \texttt{svnserve}, ma il suo uso è sconsigliato per le
-  scarse prestazioni e le difficoltà riscontrate a gestire accessi di utenti
-  diversi; la modalità di accesso preferita resta quella tramite le estensioni
+  all'uopo il programma \texttt{svnserve}, ma il suo uso è sconsigliato per le
+  scarse prestazioni e le difficoltà riscontrate a gestire accessi di utenti
+  diversi; la modalità di accesso preferita resta quella tramite le estensioni
   al protocollo DAV.}
 
-In generale è comunque necessario preoccuparsi delle modalità di accesso al
-codice soltanto in fase di primo accesso al \textit{repository}, che occorrerà
+In generale è comunque necessario preoccuparsi delle modalità di accesso al
+codice soltanto in fase di primo accesso al \textit{repository}, che occorrerà
 identificare o con il pathname alla directory dove questo si trova o con una
 opportuna URL (con il comune accesso via web del tutto analoga a quella che si
-usa in un browser), dopo di che detto indirizzo sarà salvato nella propria
-copia locale dei dati ed il riferimento diventerà implicito.
+usa in un browser), dopo di che detto indirizzo sarà salvato nella propria
+copia locale dei dati ed il riferimento diventerà implicito.
 
-Il programma prevede infatti che in ogni directory che si è ottenuta come
+Il programma prevede infatti che in ogni directory che si è ottenuta come
 copia locale sia presente una directory \texttt{.svn} contenente tutti i dati
 necessari al programma. Inoltre il programma usa la directory
 \texttt{.subversion} nella home dell'utente per mantenere le configurazioni
@@ -306,7 +306,7 @@ generali del client e le eventuali informazioni di autenticazione.
 Tutte le operazioni di lavoro sul \textit{repository} vengono effettuate lato
 client tramite il comando \texttt{svn} che vedremo in
 sez.~\ref{sec:build_subversion} ma la creazione e la inizializzazione dello
-stesso (così come la gestione lato server) devono essere fatte tramite il
+stesso (così come la gestione lato server) devono essere fatte tramite il
 comando \texttt{svnadmin} eseguito sulla macchina che lo ospita. In generale
 infatti il comando \texttt{svn} richiede che si faccia riferimento ad un
 \textit{repository} (al limite anche vuoto) esistente e questo deve essere
@@ -314,13 +314,13 @@ opportunamente creato.
 
 Il comando \texttt{svnadmin} utilizza una sintassi che richiede sempre
 l'ulteriore specificazione di un sotto-comando, seguito da eventuali altri
-argomenti. L'inizializzazione di un \textit{repository} (che sarà creato
+argomenti. L'inizializzazione di un \textit{repository} (che sarà creato
 sempre vuoto) viene eseguita con il comando:
 \begin{verbatim}
 svnadmin create /path/to/repository
 \end{verbatim}
-dove \texttt{/path/to/repository} è la directory dove verranno creati e
-mantenuti tutti i file, una volta creato il \textit{repository} si potrà
+dove \texttt{/path/to/repository} è la directory dove verranno creati e
+mantenuti tutti i file, una volta creato il \textit{repository} si potrà
 iniziare ad utilizzarlo ed inserirvi i contenuti con il comando \texttt{svn}. 
 
 Non essendo questo un testo di amministrazione di sistema non tratteremo qui i
@@ -333,33 +333,33 @@ Srl.\footnote{rispettivamente disponibili su \url{svn.tigris.org} e
 \subsection{Utilizzo di \texttt{svn}}
 \label{sec:build_svn_use}
 
-Una volta che si abbia a disposizione un \textit{repository} si potrà creare
+Una volta che si abbia a disposizione un \textit{repository} si potrà creare
 un nuovo progetto sottoposto a controllo di versione importando al suo interno
-i dati disponibili. In genere è pratica comune suddividere il contenuto di un
+i dati disponibili. In genere è pratica comune suddividere il contenuto di un
 repository in tre directory secondo il seguente schema:
 \begin{basedescript}{\desclabelwidth{2.7cm}\desclabelstyle{\nextlinelabel}}
 \item[\texttt{trunk}] contiene la versione corrente i sviluppo, su cui vengono
   effettuate normalmente le modifiche e gli aggiornamenti;
 \item[\texttt{tags}] contiene le diverse versioni \textsl{fotografate} ad un
   certo istante del processo di sviluppo, ad esempio in occasione del rilascio
-  di una versione stabile, così che sia possibile identificarle facilmente;
+  di una versione stabile, così che sia possibile identificarle facilmente;
 \item[\texttt{branches}] contiene \textsl{rami} alternativi di sviluppo, ad
   esempio quello delle correzioni eseguite ad una versione stabile, che
   vengono portati avanti in maniera indipendente dalla versione principale.
 \end{basedescript}
 
-Questa suddivisione consente di sfruttare la capacità di Subversion di creare
+Questa suddivisione consente di sfruttare la capacità di Subversion di creare
 senza spesa copie diverse del proprio contenuto, pertanto in genere si pone il
 proprio progetto di sviluppo sotto \texttt{trunk}, e si copia quest'ultima in
 occasione delle varie versioni di rilascio in altrettante sottocartelle di
 \texttt{tags} e qualora si voglia aprire un ramo alternativo di sviluppo
-basterà copiarsi il punto di partenza del ramo sotto \texttt{branches} e
+basterà copiarsi il punto di partenza del ramo sotto \texttt{branches} e
 iniziare ad eseguire le modifiche su di esso.
 
 Le operazioni di gestione di un progetto con Subversion vengono eseguite con
 il comando \texttt{svn}, che analogamente al precedente \texttt{svnadmin}
 utilizza una sintassi basata sulla specificazione degli opportuni
-sotto-comandi. Si sono riportati quelli più importanti in
+sotto-comandi. Si sono riportati quelli più importanti in
 tab.~\ref{tab:svn_mainsubcommands}. 
 
 \begin{table}[htb]
@@ -394,26 +394,26 @@ tab.~\ref{tab:svn_mainsubcommands}.
   \label{tab:svn_mainsubcommands}
 \end{table}
 
-In genere però è piuttosto raro iniziare un progetto totalmente da zero, è
-molto più comune avere una qualche versione iniziale dei propri file
-all'interno di una cartella. In questo caso il primo passo è quello di
+In genere però è piuttosto raro iniziare un progetto totalmente da zero, è
+molto più comune avere una qualche versione iniziale dei propri file
+all'interno di una cartella. In questo caso il primo passo è quello di
 eseguire una inizializzazione del \textit{repository} importando al suo
-interno quanto già esistente.  Per far questo occorre eseguire il comando:
+interno quanto già esistente.  Per far questo occorre eseguire il comando:
 \begin{verbatim}
 svn import [/pathname] URL
 \end{verbatim}
-questo può essere eseguito direttamente nella directory contenente la versione
+questo può essere eseguito direttamente nella directory contenente la versione
 iniziale dei propri sorgenti nel qual caso il comando richiede come ulteriore
 argomento la directory o la URL con la quale indicare il \textit{repository}
-da usare. Alternativamente si può passare come primo argomento il pathname
+da usare. Alternativamente si può passare come primo argomento il pathname
 della directory da importare, seguito dall'indicazione della URL del
 \textit{repository}.
 
 Si tenga presente che l'operazione di importazione inserisce sul
 \textit{repository} il contenuto completo della directory indicata, compresi
-eventuali file nascosti e sotto-directory. È anche possibile eseguire
-l'importazione di più directory da inserire in diverse sezioni del
-\textit{repository}, ma un tal caso ciascuna importazione sarà vista con una
+eventuali file nascosti e sotto-directory. È anche possibile eseguire
+l'importazione di più directory da inserire in diverse sezioni del
+\textit{repository}, ma un tal caso ciascuna importazione sarà vista con una
 diversa \textit{release}. Ad ogni operazione di modifica del
 \textit{repository} viene infatti assegnato un numero progressivo che consente
 di identificarne la storia delle modifiche e riportarsi ad un dato punto della
@@ -421,55 +421,55 @@ stessa in ogni momento successivo.\footnote{a differenza di CVS Subversion non
   assegna un numero di versione progressivo distinto ad ogni file, ma un
   numero di \textit{release} progressivo ad ogni cambiamento globale del
   repository, pertanto non esiste il concetto di versione di un singolo file,
-  quanto di stato di tutto il \textit{repository} ad un dato momento, è
+  quanto di stato di tutto il \textit{repository} ad un dato momento, è
   comunque possibile richiedere in maniera indipendente la versione di ogni
   singolo file a qualunque \textit{release} si desideri.}
 
-Una volta eseguita l'importazione di una versione iniziale è d'uopo cancellare
+Una volta eseguita l'importazione di una versione iniziale è d'uopo cancellare
 la directory originale e ripartire dal progetto appena creato. L'operazione di
 recuperare ex-novo di tutti i file che fanno parte di un progetto, chiamata
 usualmente \textit{checkout}, viene eseguita con il
-comando:\footnote{alternativamente si può usare l'abbreviazione \texttt{svn
+comando:\footnote{alternativamente si può usare l'abbreviazione \texttt{svn
     co}.}
 \begin{verbatim}
 svn checkout URL [/pathname]
 \end{verbatim}
-che creerà nella directory corrente una directory corrispondente al nome
+che creerà nella directory corrente una directory corrispondente al nome
 specificato in coda alla URL passata come argomento, scaricando l'ultima
-versione dei file archiviati sul repository; alternativamente si può
+versione dei file archiviati sul repository; alternativamente si può
 specificare come ulteriore argomento la directory su cui scaricare i file.
 
-Sia in caso di \texttt{import} che di \texttt{checkout} è sempre possibile
+Sia in caso di \texttt{import} che di \texttt{checkout} è sempre possibile
 operare su una qualunque sotto cartella contenuta all'interno di un
-\textit{repository}, ignorando totalmente quello che sta al di sopra, basterà
+\textit{repository}, ignorando totalmente quello che sta al di sopra, basterà
 indicare in sede di importazione o di estrazione iniziale un pathname o una
 URL che identifichi quella parte del progetto.
 
-Se quando si effettua lo scaricamento non si vuole usare la versione più
-aggiornata, ma una versione precedente si può usare l'opzione \texttt{-r}
-seguita da un numero che scaricherà esattamente quella \textit{release},
-alternativamente al posto del numero si può indicare una data, e verrà presa
-la \textit{release} più prossima a quella data. 
+Se quando si effettua lo scaricamento non si vuole usare la versione più
+aggiornata, ma una versione precedente si può usare l'opzione \texttt{-r}
+seguita da un numero che scaricherà esattamente quella \textit{release},
+alternativamente al posto del numero si può indicare una data, e verrà presa
+la \textit{release} più prossima a quella data. 
 
 A differenza di CVS Subversion non supporta l'uso di \textsl{etichette}
-associate ad una certa versione del proprio progetto, per questo è invalso
+associate ad una certa versione del proprio progetto, per questo è invalso
 l'uso di strutturare il repository secondo lo schema illustrato inizialmente;
-è infatti molto semplice (e non comporta nessun tipo di aggravio) creare delle
+è infatti molto semplice (e non comporta nessun tipo di aggravio) creare delle
 copie complete di una qualunque parte del \textit{repository} su un'altra
-parte dello stesso, per cui se si è eseguito lo sviluppo sulla cartella
-\texttt{trunk} sarà possibile creare banalmente una versione con etichetta
+parte dello stesso, per cui se si è eseguito lo sviluppo sulla cartella
+\texttt{trunk} sarà possibile creare banalmente una versione con etichetta
 \texttt{label} (o quel che si preferisce) semplicemente con una copia eseguita
 con:
 \begin{verbatim}
 svn cp trunk tags/label
 \end{verbatim}
 
-Il risultato di questo comando è la creazione della nuova cartella
-\texttt{label} sotto \texttt{tags}, che sarà assolutamente identica, nel
+Il risultato di questo comando è la creazione della nuova cartella
+\texttt{label} sotto \texttt{tags}, che sarà assolutamente identica, nel
 contenuto (e nella sua storia) a quanto presente in \texttt{trunk} al momento
 dell'esecuzione del comando. In questo modo, una volta salvate le
-modifiche,\footnote{la copia viene eseguita localmente verrà creata anche sul
-  \textit{repository} solo dopo un \textit{commit}.} si potrà ottenere la
+modifiche,\footnote{la copia viene eseguita localmente verrà creata anche sul
+  \textit{repository} solo dopo un \textit{commit}.} si potrà ottenere la
 versione \texttt{label} del proprio progetto semplicemente eseguendo un
 \textit{checkout} di \texttt{tags/label} in un'altra
 directory.\footnote{ovviamente una volta presa la suddetta versione si deve
@@ -477,7 +477,7 @@ directory.\footnote{ovviamente una volta presa la suddetta versione si deve
   questo se si deve modificare una versione etichettata si usa
   \texttt{branches}.}
 
-Una volta creata la propria copia locale dei programmi, è possibile lavorare
+Una volta creata la propria copia locale dei programmi, è possibile lavorare
 su di essi ponendosi nella relativa directory, e apportare tutte le modifiche
 che si vogliono ai file ivi presenti; due comandi permettono inoltre di
 schedulare la rimozione o l'aggiunta di file al
@@ -494,17 +494,17 @@ che non viene dato il comando:\footnote{in genere anche questo viene
 \begin{verbatim}
 svn commit [file]
 \end{verbatim}
-ed è possibile eseguire il \textit{commit} delle modifiche per un singolo
+ed è possibile eseguire il \textit{commit} delle modifiche per un singolo
 file, indicandolo come ulteriore argomento, mentre se non si indica nulla
 verranno inviate tutte le modifiche presenti.
 
-Si tenga presente però che il \textit{commit} non verrà eseguito se nel
+Si tenga presente però che il \textit{commit} non verrà eseguito se nel
 frattempo i file del \textit{repository} sono stati modificati; in questo caso
-\texttt{svn} rileverà la presenza di differenze fra la propria
-\textit{release} e quella del \textit{repository} e chiederà che si effettui
-preventivamente un aggiornamento. Questa è una delle operazioni di base di
+\texttt{svn} rileverà la presenza di differenze fra la propria
+\textit{release} e quella del \textit{repository} e chiederà che si effettui
+preventivamente un aggiornamento. Questa è una delle operazioni di base di
 Subversion, che in genere si compie tutte le volte che si inizia a lavorare,
-il comando che la esegue è:
+il comando che la esegue è:
 \begin{verbatim}
 svn update
 \end{verbatim}
@@ -521,8 +521,8 @@ con quelle presenti sulla versione del \textit{repository}.
 Fintanto che sono state modificate parti indipendenti di un file di testo in
 genere il processo di \textit{merging} ha successo e le modifiche vengono
 incorporate automaticamente in conseguenza dell'aggiornamento, ma quando le
-modifiche attengono alla stessa parte di un file nel ci si troverà di fronte
-ad un conflitto ed a quel punto sarà richiesto al ``committente'' di
+modifiche attengono alla stessa parte di un file nel ci si troverà di fronte
+ad un conflitto ed a quel punto sarà richiesto al ``committente'' di
 intervenire manualmente sui file per i quali sono stati rilevati i conflitti
 per risolverli.
 
@@ -539,11 +539,11 @@ seguente:
 >>>>>>> r.122
 \end{verbatim}
 
-In questo caso si c'è stata una modifica sul file (mostrata nella parte
+In questo caso si c'è stata una modifica sul file (mostrata nella parte
 superiore) incompatibile con quella fatta nel \textit{repository} (mostrata
-nella parte inferiore). Prima di eseguire un \textit{commit} occorrerà
+nella parte inferiore). Prima di eseguire un \textit{commit} occorrerà
 pertanto integrare le modifiche e salvare nuovamente il file rimuovendo i
-marcatori, inoltre prima che il \textit{commit} ritorni possibile si dovrà
+marcatori, inoltre prima che il \textit{commit} ritorni possibile si dovrà
 esplicitare la risoluzione del conflitto con il comando:
 \begin{verbatim}
 svn resolved file
@@ -570,7 +570,7 @@ svn resolved file
 \end{table}
 
 
-Infine per capire la situazione della propria copia locale si può utilizzare
+Infine per capire la situazione della propria copia locale si può utilizzare
 il comando \texttt{svn status} che confronta i file presenti nella directory
 locale rispetto alla ultima versione scaricata dal \textit{repository} e per
 tutti quelli che non corrispondono stampa a schermo delle informazioni di