X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=build.tex;h=cec0b2db85a160121f3e283e6dceb636fba256d1;hp=51b8debaaa741165dd08ba72dced299c3a910b9e;hb=fa15a3f1ecd64efd8440e46d398fd9976abc3d25;hpb=fa8f6170f9e769b98378040e6e847e5a5db3b836

diff --git a/build.tex b/build.tex
index 51b8deb..cec0b2d 100644
--- a/build.tex
+++ b/build.tex
@@ -1,6 +1,6 @@
 %% build.tex
 %%
-%% Copyright (C) 1999-2007 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",
@@ -17,61 +17,63 @@ 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.
 
 
 \section{L'uso di \texttt{make} per l'automazione della compilazione}
+\label{sec:build_make}
 
 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}.}
 
 
 \subsection {Introduzione a \texttt{make}}
+\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
@@ -130,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
@@ -148,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).
@@ -163,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
@@ -176,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
@@ -191,233 +193,401 @@ 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 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 facendo riferimento con la variabile automatica: \texttt{\$@}.
-L'esempio usato per la nostra costruzione però sembra non avere neanche la
-regola di costruzione.
+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
+facendo riferimento con la variabile automatica: \texttt{\$@}.  L'esempio
+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
 di \texttt{OBJ}.
 
 
-\section{Cuncurrent Version System -- CVS}
-
-Il programma CVS è un sistema di archiviazione dei programmi che consente di
-tenere traccia di tutte le modifiche e di condividere un archivio comune per
-progetti portati avanti da diverse persone.
-
-\subsection{Introduzione}
-CVS è basato sul concetto di repositorio, un archivio 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. 
-
-CVS può gestire più di un progetto, esso organizza i progetti in
-\textsl{moduli} identificati dal nome della directory in cui sono messi i file
-relativi, ad esempio: 
-\small
+\section{Source Control Management}
+\label{sec:build_scm}
+
+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
+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
+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
+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
+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,
+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 
+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
+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
+  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à
+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.
+
+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
+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
+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
+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
+sempre vuoto) viene eseguita con il comando:
 \begin{verbatim}
-[piccardi@pcpamela ~]$ ls /usr/local/cvsroot/ 
-CVSROOT  adidsp  geometry  muonacq  pamela
+svnadmin create /path/to/repository
 \end{verbatim}
-\normalsize %$
-in questo caso si hanno i moduli \texttt{adidsp geometry muonacq pamela}; un
-utente potrà recuperare tutti i file relativi al modulo \texttt{pamela} che
-andaranno nella directory \texttt{pamela}; è anche possibile gestire una
-gerarchia di moduli, inseriti in un albero di directory.
-
-CVS ha una directory base dove tiene gli archivi (che nel è appunto
-\texttt{/usr/local/cvsroot}) e i vari file amministrativi; ogni progetto deve
-fare riferimento ad essa; in un progetto attivo essa viene memorizzata nei
-file amministrativi locali del progetto (ad esempio per un utente che ha il
-progetto \texttt{muonacq} nella sua home directory sarà in
-\texttt{\tild/muonacq/CVS}) e non è necessario specificarla; in generale essa
-viene tenuta dalla variabile di shell \texttt{CVSROOT} (inizializzata allo
-startup), o specificata direttamente dall'utente con l'apposita opzione
-\texttt{-d} (ex. \texttt{cvs -d /usr/local/cvsroot comando opzioni}).
-
-Normalmente l'archivio si tiene su una macchina remota e vi si accede via
-rete. Per repositori esterni esistono varie modalità di accesso, la via più
-semplice è quella dell'uso di \texttt{ssh} come rimpiazzo di \texttt{rsh} per
-l'accesso esterno; in tal caso la directory del repositorio si può accedere
-con la sintassi: \small
+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
+dettagli della configurazione del server per l'accesso via rete al
+\textit{repository}, per i quali si rimanda alla documentazione del progetto
+ed alla documentazione sistemistica scritta per Truelite
+Srl.\footnote{rispettivamente disponibili su \url{svn.tigris.org} e
+  \url{labs.truelite.it/truedoc}.}
+
+\subsection{Utilizzo di \texttt{svn}}
+\label{sec:build_svn_use}
+
+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
+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;
+\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
+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
+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
+tab.~\ref{tab:svn_mainsubcommands}. 
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|l|l|p{8cm}|}
+    \hline
+     \multicolumn{2}{|c|}{\textbf{Sotto-comando}}& \textbf{Significato} \\
+    \hline
+    \hline
+    \texttt{import}  &  --       & Importa i file della directory corrente sul
+                                   \textit{repository}.\\ 
+    \texttt{checkout}&\texttt{co}& Scarica una versione del progetto dal
+                                   \textit{repository}.\\
+    \texttt{commit}  &\texttt{ci}& Invia le modifiche effettuate localmente al 
+                                   \textit{repository}.\\
+    \texttt{add}     &  --       & Richiede l'aggiunta un file o una directory
+                                   al \textit{repository}.\\
+    \texttt{remove}  &\texttt{rm}& Richiede la rimozione un file o una 
+                                   directory dal \textit{repository}.\\
+    \texttt{copy}    &\texttt{cp}& Richiede la copia un file o una cartella del
+                                   progetto (mantenendone la storia).\\
+    \texttt{move}    &\texttt{mv}& Richiede lo spostamento un file o una 
+                                   directory (equivalente ad un \texttt{cp}
+                                   seguito da un \texttt{rm}).\\
+    \texttt{update}  &  --       & Aggiorna la copia locale.\\
+    \texttt{resolved}&  --       & Rimuove una situazione di conflitto presente
+                                   su un file.\\ 
+    \hline
+  \end{tabular}
+  \caption{Tabella riassuntiva dei principali sotto-comandi di \texttt{svn}.}
+  \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
+eseguire una inizializzazione del \textit{repository} importando al suo
+interno quanto già esistente.  Per far questo occorre eseguire il comando:
 \begin{verbatim}
-cvs -d :ext:utente@server:/usr/local/cvsroot comando
+svn import [/pathname] URL
+\end{verbatim}
+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
+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
+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
+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, è
+  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
+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
+    co}.}
+\begin{verbatim}
+svn checkout URL [/pathname]
+\end{verbatim}
+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ò
+specificare come ulteriore argomento la directory su cui scaricare i file.
+
+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à
+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. 
+
+A differenza di CVS Subversion non supporta l'uso di \textsl{etichette}
+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
+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
+\texttt{label} (o quel che si preferisce) semplicemente con una copia eseguita
+con:
+\begin{verbatim}
+svn cp trunk tags/label
 \end{verbatim}
-\normalsize
-
-questo però comporta che sulla macchina remota \texttt{server} sia installato
-il server \texttt{ssh} ed esista l'utente \texttt{utente} con privilegi di
-accesso ai file; inoltre sulla macchina ospite deve esser stata definita la
-variabile di shell \texttt{CVS\_RSH=ssh}.
-
-In questo modo ssh si collega alla macchina remota ed esegue il comando CVS con
-una connessione criptata dopo aver richiesto la password di \texttt{utente}. 
-
-
-\subsection{Utilizzo di \texttt{cvs}}
-
-Per creare un repositorio a partire da un gruppo di programmi esistente basta
-dare il comando \texttt{cvs import project tag release} nella directory dei
-sorgenti; verrà creato nel repositorio il modulo di nome \texttt{project} a
-cui poi si potrà accedere con i successivi comandi; \texttt{tag} è una
-etichetta di versione iniziale (ex. \texttt{1.1.1}) dato a tutto il blocco e
-\texttt{release} una etichetta di versione data ai programmi.
 
-Una volta creato il repositorio è d'uopo cancellare la directory e ripartire
-dal progetto appena creato. Per recuperare ex-novo tutti i file di un progetto
-il comando da dare è:
-\small
+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
+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
+  aver cura di non eseguire nessuna modifica a partire dalla stessa, per
+  questo se si deve modificare una versione etichettata si usa
+  \texttt{branches}.}
+
+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
+\textit{repository}:\footnote{a differenza di CVS si possono aggiungere e
+  rimuovere, ed anche spostare con \texttt{svn mv}, sia file che directory.}
 \begin{verbatim}
-cvs [-d ...] checkout project [-r rel] [-D date]
+svn add file1.c
+svn remove file2.c
 \end{verbatim}
-\normalsize che creerà la directory \texttt{project} nella directory corrente
-con l'ultima versione dei file archiviata; se non si vuole la versione più
-aggiornata, ma una versione precedente si può usare l'opzione \texttt{-r} che
-scaricherà la versione identificata dall'etichetta specificata (vedi la parte
-seguente sul comando \texttt{tag}) o l'opzione \texttt{-D} che scaricherà la
-versione più recente prima della data specificata.
-
-Una volta scaricato il progetto è possibile evitare di specificare la
-directory base del repositorio con l'opzione \texttt{-d} qualora i comandi
-vengano dati all'interno della directory creata, essa viene tenuta nel file
-\texttt{CVS/Root}, e può essere cambiata (qualora si usino più repositori)
-editando detto file.
-
-Una volta creata la propria copia locale dei programmi, è possibile lavorare
-su di essi stando nella relativa directory,
-e apportare tutte le modifiche che si vogliono; due comandi 
-permettono di schedulare la rimozione o l'aggiunta di file al repositorio:
-\small
+ma niente viene modificato sul \textit{repository} fintanto che non viene
+eseguito il cosiddetto \textit{commit} delle modifiche, vale a dire fintanto
+che non viene dato il comando:\footnote{in genere anche questo viene
+  abbreviato, con \texttt{svn ci}.}
 \begin{verbatim}
-cvs add file1.c
-cvs remove file2.c
+svn commit [file]
 \end{verbatim}
-\normalsize
-ma niente viene modificato nel repositorio fintanto che non viene dato il 
-comando \texttt{commit}: 
-\small
+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
+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
+Subversion, che in genere si compie tutte le volte che si inizia a lavorare,
+il comando che la esegue è:
 \begin{verbatim}
-cvs commit [file]
+svn update
 \end{verbatim}
-(è possibile mandare le modifiche anche per il singolo file). 
 
-Questi comandi comunque non effettuano le modifiche se i file del repositorio
-nel frattempo sono stati modificati; in questo caso rilevano le differenze e
-restituiscono un \textit{merging} delle versioni locale/globale nella
-directory di lavoro, che è compito del programmatore esaminare per eliminare
-eventuali contrasti.
-
-Per esempio viene eseguito un commit su una versione già modificata da un
-altro sul repositorio, il programma segnalerà che c'è un conflitto e
-chiederà al ``committente'' di intervenire sui file per i quali sono stati
-rilevati i conflitti .
-
-Le sezioni di codice in conflitto sono separate come:
+Questo comando opera a partire dalla directory in cui viene eseguito e ne
+aggiorna il contenuto (compreso quello di eventuali sotto-directory) alla
+versione presente, scaricando le ultime versioni dei file esistenti o nuovi
+file o directory aggiunte, cancellando eventuali file e directory rimossi dal
+\textit{repository}.  Esso inoltre esso cerca, in caso di presenza di
+modifiche eseguite in maniera indipendente sulla propria copia locale, di
+eseguire un \textsl{raccordo} (il cosiddetto \textit{merging}) delle stesse
+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
+intervenire manualmente sui file per i quali sono stati rilevati i conflitti
+per risolverli.
+
+Per aiutare il committente nel suo compito quando l'operazione di
+aggiornamento fallisce nel raccordo delle modifiche lascia sezioni di codice
+in conflitto opportunamente marcate e separate fra loro come nell'esempio
+seguente:
 \begin{verbatim}
-<<<<<<< Makefile
+<<<<<<< .mine
         $(CC) $(CFLAGS) -o pamacq pamacq.c -lm
 =======
         $(CC) $(CFLAGS) -o pamacq pamacq.c
 
->>>>>>> 1.22
+>>>>>>> r.122
+\end{verbatim}
+
+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à
+pertanto integrare le modifiche e salvare nuovamente il file rimuovendo i
+marcatori, inoltre prima che il \textit{commit} ritorni possibile si dovrà
+esplicitare la risoluzione del conflitto con il comando:
+\begin{verbatim}
+svn resolved file
 \end{verbatim}
-nel caso si c'è stata una modifica sul file (mostrata nella parte superiore)
-incompatibile con quella fatta nel repositorio (mostrata nella parte
-inferiore). Prima di eseguire un \textit{commit} occorre pertanto integrare le
-modifiche e risalvare il file; a questo punto il \textit{commit} diventa
-possibile.
-
-\subsection{I principali sotto comandi}
-
-I principali sottocomandi di \texttt{cvs} utilizzati per controllare lo stato
-dei sorgenti sono:
-
-\begin{itemize}
-\item \texttt{cvs update} \\
-  scarica le eventuali modifiche dei file del repositorio e le applica ai file
-  nella directory corrente. In caso di conflitti con modifiche locali effettua
-  un \textit{merging} con le caratteristiche esposte in precedenza.
-
-\item \texttt{cvs status} \\
-  compara i file nella directory locale con quelli del repositorio e stampa a
-  schermo le informazioni di stato di ciascuno di essi:
-\begin{itemize}
-\item \texttt{Locally Modified} il file è stato modificato localmente
-\item \texttt{Locally Added} il file è stato aggiunto localmente
-\item \texttt{Up to date} il file è identico
-\item \texttt{Needs Patch} il file è cambiato sul repositorio (va aggiornato)
-\item \texttt{Needs Merge} il file è cambiato sul repositorio e localmente, le
-  differenze vanno riunite prima del commit, in genere basta un \texttt{cvs
-    update}, ma in caso di conflitti questi vanno sanati.
-
-\end{itemize}
-
-\item \texttt{cvs log} \\
-  legge il giornale del modulo corrente; in questo modo si hanno le
-  informazioni sullo stato del progetto all'interno del repositorio, per
-  ciascun file è vengono mostrati informazioni generali su:
-\begin{itemize}
-\item release attuale
-\item presenza di eventuali ramificazioni
-\item lista di etichette simboliche
-\item i messaggi di commento salvati ad ogni \textit{commit}
-\end{itemize}
-
-\item \texttt{cvs rtag Etichetta modulo} \\
-  permette di associare una etichetta alla corrente versione dei file nel
-  progetto così come sono nel repositorio; in modo da poter ritornare a quello
-  stato del software con il comando \texttt{cvs checkout -rEtichetta module}.
-
-\end{itemize}
-
-%TODO mettere SVN al posto di CVS
-
-
-% LocalWords:  make Makefile makefile shell FC FLAGS CFLAGS pathname CERN
+
+\begin{table}[htb]
+  \centering
+  \footnotesize
+  \begin{tabular}[c]{|c|l|}
+    \hline
+    \textbf{Flag} & \textbf{Significato} \\
+    \hline
+    \hline
+    \texttt{?}& File sconosciuto.\\
+    \texttt{M}& File modificato localmente.\\
+    \texttt{A}& File aggiunto.\\
+    \texttt{C}& File con conflitto.\\
+%    \const{G}& File con modifiche integrate.\\
+%    \const{}& .\\
+    \hline
+  \end{tabular}
+  \caption{Caratteri associati ai vari stati dei file.}
+  \label{tab:svn_status}
+\end{table}
+
+
+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
+stato nella forma di un carattere seguito dal nome del file, secondo quanto
+illustrato in tab.~\ref{tab:svn_status}.
+
+
+
+
+% LocalWords:  make Makefile makefile shell FC FLAGS CFLAGS pathname CERN SCM
 % LocalWords:  OBJ commondef readfile FFLAGS Cuncurrent Version System CVS home
 % LocalWords:  adidsp geometry muonacq andaranno CVSROOT startup cvs ssh rsh to
-% LocalWords:  project tag Root commit update merging Locally Modified Added
-% LocalWords:  Needs Patch Merge log rtag checkout module
+% LocalWords:  project tag Root commit update merging Locally Modified Added co
+% LocalWords:  Needs Patch Merge log rtag checkout module altrobersaglio Source
+% LocalWords:   Control Subversion repository DAV svnserve URL svn subversion
+% LocalWords:  client sez svnadmin Truelite Srl trunk tags branches tab add rm
+% LocalWords:  remove copy cp move resolved label