Aggiornamento date copyright più TODO 5.3

[gapil.git] / build.tex

diff --git a/build.tex b/build.tex
index 2c9d9c48657f4a1d5df2f4634e903a9727f68909..cec0b2db85a160121f3e283e6dceb636fba256d1 100644 (file)
--- a/build.tex
+++ b/build.tex
@@ -1,6 +1,6 @@
 %% build.tex
 %%
 %% build.tex
 %%

-%% Copyright (C) 1999-2010 Simone Piccardi.  Permission is granted to copy,
+%% Copyright (C) 1999-2019 Simone Piccardi.  Permission is granted to copy,

 %% distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
 %% distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",


@@ -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.
 
 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.
 
 
 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
 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}.}
   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
 \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
 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).
 
 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}
 \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.
 
 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
 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 
 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. 
 
 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
 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
 
 \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
 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
 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
 
 \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).
 (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}
 \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
 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}
 
 $(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
 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
 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}.
 
 \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
 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.
 
 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
 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
 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) 
 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.
 
 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
 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
 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
 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
 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).
 
 \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
 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}
 
 \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
 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
 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.
 
 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}
 
 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.
 
 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
 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
 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
 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.}
 
   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
 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
 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
 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
 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
 
 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}
 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
 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


@@ -331,35 +331,35 @@ Srl.\footnote{rispettivamente disponibili su \url{svn.tigris.org} e
   \url{labs.truelite.it/truedoc}.}
 
 \subsection{Utilizzo di \texttt{svn}}
   \url{labs.truelite.it/truedoc}.}
 
 \subsection{Utilizzo di \texttt{svn}}

-\label{sec:build_subversion}
+\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
 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
 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}
 
 \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
 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
 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]
 tab.~\ref{tab:svn_mainsubcommands}. 
 
 \begin{table}[htb]


@@ -394,26 +394,26 @@ tab.~\ref{tab:svn_mainsubcommands}.
   \label{tab:svn_mainsubcommands}
 \end{table}
 
   \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
 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}
 \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}
 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
 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
 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,
   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.}
 
   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
 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}
     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
 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.
 
 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
 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.
 
 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}
 
 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;
 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
 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}
 
 \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
 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
 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}.}
 
   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
 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}
 \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.
 
 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
 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,
 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}
 \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
 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.
 
 intervenire manualmente sui file per i quali sono stati rilevati i conflitti
 per risolverli.
 


@@ -539,11 +539,11 @@ seguente:
 >>>>>>> r.122
 \end{verbatim}
 
 >>>>>>> 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
 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
 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
 esplicitare la risoluzione del conflitto con il comando:
 \begin{verbatim}
 svn resolved file


@@ -570,7 +570,7 @@ svn resolved file
 \end{table}
 
 
 \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
 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