build.tex

   1 %% build.tex
   2 %%
   3 %% Copyright (C) 1999-2018 Simone Piccardi.  Permission is granted to copy,
   4 %% distribute and/or modify this document under the terms of the GNU Free
   5 %% Documentation License, Version 1.1 or any later version published by the
   6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
   7 %% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
   8 %% license is included in the section entitled "GNU Free Documentation
   9 %% License".
  10 %%
  11
  12 \chapter{Gli strumenti di ausilio per la programmazione}
  13 \label{cha:build_manage}
  14
  15 Tratteremo in questa appendice in maniera superficiale i principali strumenti
  16 che vengono utilizzati per programmare in ambito Linux, ed in particolare gli
  17 strumenti per la compilazione e la costruzione di programmi e librerie, e gli
  18 strumenti di gestione dei sorgenti e di controllo di versione.
  19
  20 Questo materiale è ripreso da un vecchio articolo, ed al momento è molto
  21 obsoleto.
  22
  23
  24 \section{L'uso di \texttt{make} per l'automazione della compilazione}
  25 \label{sec:build_make}
  26
  27 Il comando \texttt{make} serve per automatizzare il processo di costruzione di
  28 un programma ed effettuare una compilazione intelligente di tutti i file
  29 relativi ad un progetto software, ricompilando solo i file necessari ed
  30 eseguendo automaticamente tutte le operazioni che possono essere necessarie
  31 alla produzione del risultato finale.\footnote{in realtà \texttt{make} non si
  32   applica solo ai programmi, ma in generale alla automazione di processi di
  33   costruzione, ad esempio anche la creazione dei file di questa guida viene
  34   fatta con \texttt{make}.}
  35
  36
  37 \subsection {Introduzione a \texttt{make}}
  38 \label{sec:make_intro}
  39
  40 Con \texttt{make} si possono definire i simboli del preprocessore C che
  41 consentono la compilazione condizionale dei programmi (anche in Fortran); è
  42 pertanto possibile gestire la ricompilazione dei programmi con diverse
  43 configurazioni con la modifica di un unico file.
  44
  45 La sintassi normale del comando (quella che si usa quasi sempre, per le
  46 opzioni vedere la pagina di manuale) è semplicemente \texttt{make}. Questo
  47 comando esegue le istruzioni contenute in un file standard (usualmente
  48 \texttt{Makefile}, o \texttt{makefile} nella directory corrente).
  49
  50 Il formato normale dei comandi contenuti in un \texttt{Makefile} è:
  51 \begin{verbatim}
  52 bersaglio: dipendenza1 dipendenza2 ...
  53         regola1
  54         regola2
  55         ...
  56 \end{verbatim}
  57 dove lo spazio all'inizio deve essere un tabulatore (metterci degli spazi è un
  58 errore comune, fortunatamente ben segnalato dalle ultime versioni del
  59 programma), il bersaglio e le dipendenze nomi di file e le regole comandi di
  60 shell.
  61
  62 Il concetto di base è che se uno dei file di dipendenza è più recente (nel
  63 senso di tempo di ultima modifica) del file bersaglio quest'ultimo viene
  64 ricostruito di nuovo usando le regole elencate nelle righe successive.
  65
  66 Il comando \texttt{make} ricostruisce di default il primo bersaglio che viene
  67 trovato nella scansione del \texttt{Makefile}, se in un \texttt{Makefile} sono
  68 contenuti più bersagli indipendenti, si può farne ricostruire un altro che non
  69 sia il primo passandolo esplicitamente al comando come argomento, con qualcosa
  70 del tipo di: \texttt{make altrobersaglio}.
  71
  72 Si tenga presente che le dipendenze stesse possono essere dichiarate come
  73 bersagli dipendenti da altri file; in questo modo è possibile creare una
  74 catena di ricostruzioni.
  75
  76 In esempio comune di quello che si fa è mettere come primo bersaglio il
  77 programma principale che si vuole usare, e come dipendenze tutte gli oggetti
  78 delle funzioni subordinate che utilizza, con i quali deve essere collegato; a
  79 loro volta questi oggetti sono bersagli che hanno come dipendenza i relativi
  80 sorgenti. In questo modo il cambiamento di una delle funzioni subordinate
  81 comporta solo la ricompilazione della medesima e del programma finale.
  82
  83
  84 \subsection{Utilizzo di \texttt{make}}
  85
  86 Il comando \texttt{make} mette a disposizione una serie molto complesse di
  87 opzioni e di regole standard predefinite e sottintese, che permettono una
  88 gestione estremamente rapida e concisa di progetti anche molto complessi; per
  89 questo piuttosto che fare una replica del manuale preferisco commentare un
  90 esempio di \texttt{makefile}, quello usato per ricompilare i programmi di
  91 analisi dei dati dei test su fascio del tracciatore di Pamela.
  92
  93 \small
  94 \begin{verbatim}
  95 #----------------------------------------------------------------------
  96 #
  97 # Makefile for a Linux System:
  98 # use GNU FORTRAN compiler g77
  99 # Makefile done for tracker test data
 100 #
 101 #----------------------------------------------------------------------
 102 # Fortran flags
 103 FC=g77
 104 FFLAGS= -fvxt -fno-automatic -Wall -O6 -DPC # -DDEBUG
 105 CC=gcc
 106 CFLAGS= -Wall -O6
 107 CFLADJ=-c #-DDEBUG
 108 #
 109 # FC            Fortran compiler for standard rules
 110 # FFLAGS        Fortran flags for standard rules
 111 # CC            C Compiler for standard rules
 112 # CFLAGS        C compiler flags for standard rules
 113 LIBS=  -L/cern/pro/lib -lkernlib -lpacklib -lgraflib -lmathlib
 114 OBJ=cnoise.o fit2.o pedsig.o loop.o badstrp.o cutcn.o readevnt.o \
 115 erasepedvar.o readinit.o dumpval.o writeinit.o
 116
 117 riduzione: riduzione.F $(OBJ) commondef.f readfile.o
 118         $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS)
 119
 120 readfile.o: readfile.c
 121         $(CC) $(CFLAGS) -o readfile.o readfile.c
 122
 123 $(OBJ): commondef.f
 124
 125 .PHONY : clean
 126 clean:
 127         rm -f *.o
 128         rm -f *~
 129         rm -f riduzione
 130         rm -f *.rz
 131         rm -f output
 132 \end{verbatim}
 133 \normalsize
 134
 135 Anzitutto i commenti, ogni linea che inizia con un \texttt{\#} è un
 136 commento e non viene presa in considerazione.
 137
 138 Con \texttt{make} possono essere definite delle variabili, da potersi riusare
 139 a piacimento, per leggibilità si tende a definirle tutte maiuscole,
 140 nell'esempio ne sono definite varie: \small
 141 \begin{verbatim}
 142 FC=g77
 143 FFLAGS= -fvxt -fno-automatic -Wall -O6 -DPC # -DDEBUG
 144 CC=gcc
 145 CFLAGS= -Wall -O6
 146 CFLADJ=-c #-DDEBUG
 147 ...
 148 LIBS=  -L/cern/pro/lib -lkernlib -lpacklib -lgraflib -lmathlib
 149 OBJ=cnoise.o fit2.o pedsig.o loop.o badstrp.o cutcn.o readevnt.o \
 150 \end{verbatim}
 151 \normalsize
 152
 153 La sintassi è \texttt{NOME=}, alcuni nomi però hanno un significato speciale
 154 (nel caso \texttt{FC}, \texttt{FLAGS}, \texttt{CC}, \texttt{CFLAGS}) in quanto
 155 sono usati da \texttt{make} nelle cosiddette \textsl{regole implicite} (su cui
 156 torneremo dopo).
 157
 158 Nel caso specifico, vedi anche i commenti, abbiamo definito i comandi di
 159 compilazione da usare per il C e il Fortran, e i rispettivi flag, una variabile
 160 che contiene il pathname e la lista delle librerie del CERN e una variabile con una
 161 lista di file oggetto.
 162
 163 Per richiamare una variabile si usa la sintassi \texttt{\$(NOME)}, ad esempio
 164 nel makefile abbiamo usato:
 165 \begin{verbatim}
 166         $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS)
 167 \end{verbatim}
 168 e questo significa che la regola verrà trattata come se avessimo scritto
 169 esplicitamente i valori delle variabili.
 170
 171 Veniamo ora alla parte principale del makefile che esegue la costruzione del
 172 programma:
 173 \begin{verbatim}
 174 riduzione: riduzione.F $(OBJ) commondef.f readfile.o
 175         $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS)
 176 readfile.o: readfile.c
 177         $(CC) $(CFLAGS) -o readfile.o readfile.c
 178 $(OBJ): commondef.f
 179 \end{verbatim}
 180
 181 Il primo bersaglio del makefile, che definisce il bersaglio di default, è il
 182 programma di riduzione dei dati; esso dipende dal suo sorgente da tutti gli
 183 oggetti definiti dalla variabile \texttt{OBJ}, dal file di definizioni
 184 \texttt{commondef.f} e dalla routine C \texttt{readfile.o}; si noti il
 185 \texttt{.F} del sorgente, che significa che il file prima di essere compilato
 186 viene fatto passare attraverso il preprocessore C (cosa che non avviene per i
 187 \texttt{.f}) che permette di usare i comandi di compilazione condizionale del
 188 preprocessore C con la relativa sintassi. Sotto segue il comando di
 189 compilazione che sfrutta le variabili definite in precedenza per specificare
 190 quale compilatore e opzioni usare e specifica di nuovo gli oggetti e le
 191 librerie.
 192
 193 Il secondo bersaglio definisce le regole per la compilazione della routine
 194 in C; essa dipende solo dal suo sorgente. Si noti che per la compilazione
 195 vengono usate le variabili relative al compilatore C. Si noti anche che se
 196 questa regola viene usata, allora lo sarà anche la precedente, dato che
 197 \texttt{riduzione} dipende da \texttt{readfile.o}.
 198
 199 Il terzo bersaglio è apparentemente incomprensibile dato che vi compare
 200 solo il riferimento alla variabile \texttt{OBJ} con una sola dipendenza e
 201 nessuna regola, essa però mostra le possibilità (oltre che la
 202 complessità) di \texttt{make} connesse alla presenza di quelle regole
 203 implicite a cui avevamo accennato.
 204
 205 Anzitutto una peculiarità di \texttt{make} è che si possono anche usare più
 206 bersagli per una stessa regola (nell'esempio quelli contenuti nella variabile
 207 \texttt{OBJ} che viene espansa in una lista); in questo caso la regola di
 208 costruzione sarà applicata a ciascuno che si potrà citare nella regola stessa
 209 facendo riferimento con la variabile automatica: \texttt{\$@}.  L'esempio
 210 usato per la nostra costruzione però sembra non avere neanche la regola di
 211 costruzione.
 212
 213 Questa mancanza sia di regola che di dipendenze (ad esempio dai vari sorgenti)
 214 illustra le capacità di funzionamento automatico di \texttt{make}.
 215 Infatti è facile immaginarsi che un oggetto dipenda da un sorgente, e che
 216 per ottenere l'oggetto si debba compilare quest'ultimo.
 217
 218 Il comando \texttt{make} sa tutto questo per cui quando un bersaglio è un
 219 oggetto (cioè ha un nome tipo \texttt{qualcosa.o}) non è necessario
 220 specificare il sorgente, ma il programma lo va a cercare nella directory
 221 corrente (ma è possibile pure dirgli di cercarlo altrove, il caso è trattato
 222 nel manuale).  Nel caso specifico allora si è messo come dipendenza solo il
 223 file delle definizioni che viene incluso in ogni subroutine.
 224
 225 Inoltre come dicevamo in genere per costruire un oggetto si deve compilarne il
 226 sorgente; \texttt{make} sa anche questo e sulla base dell'estensione del
 227 sorgente trovato (che nel caso sarà un \texttt{qualcosa.f}) applica la regola
 228 implicita.  In questo caso la regola è quella di chiamare il compilatore
 229 fortran applicato al file oggetto e al relativo sorgente, questo viene fatto
 230 usando la variabile \texttt{FC} che è una delle variabili standard usata dalle
 231 regole implicite (come \texttt{CC} nel caso di file \texttt{.c}); per una
 232 maggiore flessibilità poi la regola standard usa anche la variabile
 233 \texttt{FFLAGS} per specificare, a scelta dell'utente che non ha che da
 234 definirla, quali flag di compilazione usare (nella documentazione sono
 235 riportate tutte le regole implicite e le relative variabili usate).
 236
 237 In questo modo è stato possibile usare una sola riga per indicare la serie di
 238 dipendenze e relative compilazioni delle singole subroutine; inoltre con l'uso
 239 della variabile \texttt{OBJ} l'aggiunta di una nuova eventuale routine
 240 \texttt{nuova.f} comporta solo l'aggiunta di \texttt{nuova.o} alla definizione
 241 di \texttt{OBJ}.
 242
 243
 244 \section{Source Control Management}
 245 \label{sec:build_scm}
 246
 247 Uno dei problemi più comuni che si hanno nella programmazione è quella di
 248 poter disporre di un sistema che consenta di tenere conto del lavoro
 249 effettuato, di tracciare l'evoluzione del codice, e, soprattutto nel caso di
 250 progetti portati avanti da più persone, consentire un accesso opportunamente
 251 coordinato fra i vari partecipanti alla base comune dei sorgenti dello
 252 sviluppo.
 253
 254 I programmi che servono a questo scopo vanno sotto il nome comune di SCM
 255 (\textit{Source Control Manager}), e ne esistono di diversi tipi con diverse
 256 filosofie progettuali, in particolare nelle modalità con cui gestiscono
 257 l'accesso alla base di codice comune da parte dei singoli programmatori che vi
 258 accedono.
 259
 260 Fra questi uno dei più usati, nonostante la sua architettura sia considerata
 261 superata, è Subversion, un sistema di archiviazione centralizzata del codice
 262 che consente di tenere traccia di tutte le modifiche e di condividere un
 263 archivio comune per progetti portati avanti da diverse persone.
 264
 265 \subsection{Introduzione a Subversion}
 266 \label{sec:build_subversion}
 267
 268 Subversion è basato sul concetto di \textit{repository}, un archivio
 269 centralizzato in cui vengono riposti e da cui vengono presi i sorgenti dei
 270 programmi. L'archivio tiene traccia delle diverse versioni registrate; i
 271 programmatori inviano le modifiche usando una copia locale che hanno nella
 272 loro directory di lavoro.
 273
 274 Subversion può gestire più di un progetto all'interno di un singolo server,
 275 ciascuno dei quali viene associato ad un \textit{repository} distinto, ma si
 276 possono anche creare sotto-progetti suddividendo un \textit{repository} in
 277 diverse directory; ma ciascun progetto avrà meccanismi di controllo (ad
 278 esempio quelli che consentono di inviare email all'inserimento di nuovo
 279 codice) comuni.
 280
 281 Una delle caratteristiche che contraddistinguono Subversion dal suo
 282 predecessore CVS è quella di essere gestibile in maniera molto flessibile
 283 l'accesso al repository, che può avvenire sia in maniera diretta facendo
 284 riferimento alla directory in cui questo è stato installato che via rete,
 285 tramite diversi protocolli. L'accesso più comune è fatto direttamente via
 286 HTTP, utilizzando opportune estensioni del protocollo DAV, ma è possibile
 287 passare attraverso SSH o fornire un servizio di rete dedicato.\footnote{esiste
 288   all'uopo il programma \texttt{svnserve}, ma il suo uso è sconsigliato per le
 289   scarse prestazioni e le difficoltà riscontrate a gestire accessi di utenti
 290   diversi; la modalità di accesso preferita resta quella tramite le estensioni
 291   al protocollo DAV.}
 292
 293 In generale è comunque necessario preoccuparsi delle modalità di accesso al
 294 codice soltanto in fase di primo accesso al \textit{repository}, che occorrerà
 295 identificare o con il pathname alla directory dove questo si trova o con una
 296 opportuna URL (con il comune accesso via web del tutto analoga a quella che si
 297 usa in un browser), dopo di che detto indirizzo sarà salvato nella propria
 298 copia locale dei dati ed il riferimento diventerà implicito.
 299
 300 Il programma prevede infatti che in ogni directory che si è ottenuta come
 301 copia locale sia presente una directory \texttt{.svn} contenente tutti i dati
 302 necessari al programma. Inoltre il programma usa la directory
 303 \texttt{.subversion} nella home dell'utente per mantenere le configurazioni
 304 generali del client e le eventuali informazioni di autenticazione.
 305
 306 Tutte le operazioni di lavoro sul \textit{repository} vengono effettuate lato
 307 client tramite il comando \texttt{svn} che vedremo in
 308 sez.~\ref{sec:build_subversion} ma la creazione e la inizializzazione dello
 309 stesso (così come la gestione lato server) devono essere fatte tramite il
 310 comando \texttt{svnadmin} eseguito sulla macchina che lo ospita. In generale
 311 infatti il comando \texttt{svn} richiede che si faccia riferimento ad un
 312 \textit{repository} (al limite anche vuoto) esistente e questo deve essere
 313 opportunamente creato.
 314
 315 Il comando \texttt{svnadmin} utilizza una sintassi che richiede sempre
 316 l'ulteriore specificazione di un sotto-comando, seguito da eventuali altri
 317 argomenti. L'inizializzazione di un \textit{repository} (che sarà creato
 318 sempre vuoto) viene eseguita con il comando:
 319 \begin{verbatim}
 320 svnadmin create /path/to/repository
 321 \end{verbatim}
 322 dove \texttt{/path/to/repository} è la directory dove verranno creati e
 323 mantenuti tutti i file, una volta creato il \textit{repository} si potrà
 324 iniziare ad utilizzarlo ed inserirvi i contenuti con il comando \texttt{svn}.
 325
 326 Non essendo questo un testo di amministrazione di sistema non tratteremo qui i
 327 dettagli della configurazione del server per l'accesso via rete al
 328 \textit{repository}, per i quali si rimanda alla documentazione del progetto
 329 ed alla documentazione sistemistica scritta per Truelite
 330 Srl.\footnote{rispettivamente disponibili su \url{svn.tigris.org} e
 331   \url{labs.truelite.it/truedoc}.}
 332
 333 \subsection{Utilizzo di \texttt{svn}}
 334 \label{sec:build_svn_use}
 335
 336 Una volta che si abbia a disposizione un \textit{repository} si potrà creare
 337 un nuovo progetto sottoposto a controllo di versione importando al suo interno
 338 i dati disponibili. In genere è pratica comune suddividere il contenuto di un
 339 repository in tre directory secondo il seguente schema:
 340 \begin{basedescript}{\desclabelwidth{2.7cm}\desclabelstyle{\nextlinelabel}}
 341 \item[\texttt{trunk}] contiene la versione corrente i sviluppo, su cui vengono
 342   effettuate normalmente le modifiche e gli aggiornamenti;
 343 \item[\texttt{tags}] contiene le diverse versioni \textsl{fotografate} ad un
 344   certo istante del processo di sviluppo, ad esempio in occasione del rilascio
 345   di una versione stabile, così che sia possibile identificarle facilmente;
 346 \item[\texttt{branches}] contiene \textsl{rami} alternativi di sviluppo, ad
 347   esempio quello delle correzioni eseguite ad una versione stabile, che
 348   vengono portati avanti in maniera indipendente dalla versione principale.
 349 \end{basedescript}
 350
 351 Questa suddivisione consente di sfruttare la capacità di Subversion di creare
 352 senza spesa copie diverse del proprio contenuto, pertanto in genere si pone il
 353 proprio progetto di sviluppo sotto \texttt{trunk}, e si copia quest'ultima in
 354 occasione delle varie versioni di rilascio in altrettante sottocartelle di
 355 \texttt{tags} e qualora si voglia aprire un ramo alternativo di sviluppo
 356 basterà copiarsi il punto di partenza del ramo sotto \texttt{branches} e
 357 iniziare ad eseguire le modifiche su di esso.
 358
 359 Le operazioni di gestione di un progetto con Subversion vengono eseguite con
 360 il comando \texttt{svn}, che analogamente al precedente \texttt{svnadmin}
 361 utilizza una sintassi basata sulla specificazione degli opportuni
 362 sotto-comandi. Si sono riportati quelli più importanti in
 363 tab.~\ref{tab:svn_mainsubcommands}.
 364
 365 \begin{table}[htb]
 366   \centering
 367   \footnotesize
 368   \begin{tabular}[c]{|l|l|p{8cm}|}
 369     \hline
 370      \multicolumn{2}{|c|}{\textbf{Sotto-comando}}& \textbf{Significato} \\
 371     \hline
 372     \hline
 373     \texttt{import}  &  --       & Importa i file della directory corrente sul
 374                                    \textit{repository}.\\
 375     \texttt{checkout}&\texttt{co}& Scarica una versione del progetto dal
 376                                    \textit{repository}.\\
 377     \texttt{commit}  &\texttt{ci}& Invia le modifiche effettuate localmente al
 378                                    \textit{repository}.\\
 379     \texttt{add}     &  --       & Richiede l'aggiunta un file o una directory
 380                                    al \textit{repository}.\\
 381     \texttt{remove}  &\texttt{rm}& Richiede la rimozione un file o una
 382                                    directory dal \textit{repository}.\\
 383     \texttt{copy}    &\texttt{cp}& Richiede la copia un file o una cartella del
 384                                    progetto (mantenendone la storia).\\
 385     \texttt{move}    &\texttt{mv}& Richiede lo spostamento un file o una
 386                                    directory (equivalente ad un \texttt{cp}
 387                                    seguito da un \texttt{rm}).\\
 388     \texttt{update}  &  --       & Aggiorna la copia locale.\\
 389     \texttt{resolved}&  --       & Rimuove una situazione di conflitto presente
 390                                    su un file.\\
 391     \hline
 392   \end{tabular}
 393   \caption{Tabella riassuntiva dei principali sotto-comandi di \texttt{svn}.}
 394   \label{tab:svn_mainsubcommands}
 395 \end{table}
 396
 397 In genere però è piuttosto raro iniziare un progetto totalmente da zero, è
 398 molto più comune avere una qualche versione iniziale dei propri file
 399 all'interno di una cartella. In questo caso il primo passo è quello di
 400 eseguire una inizializzazione del \textit{repository} importando al suo
 401 interno quanto già esistente.  Per far questo occorre eseguire il comando:
 402 \begin{verbatim}
 403 svn import [/pathname] URL
 404 \end{verbatim}
 405 questo può essere eseguito direttamente nella directory contenente la versione
 406 iniziale dei propri sorgenti nel qual caso il comando richiede come ulteriore
 407 argomento la directory o la URL con la quale indicare il \textit{repository}
 408 da usare. Alternativamente si può passare come primo argomento il pathname
 409 della directory da importare, seguito dall'indicazione della URL del
 410 \textit{repository}.
 411
 412 Si tenga presente che l'operazione di importazione inserisce sul
 413 \textit{repository} il contenuto completo della directory indicata, compresi
 414 eventuali file nascosti e sotto-directory. È anche possibile eseguire
 415 l'importazione di più directory da inserire in diverse sezioni del
 416 \textit{repository}, ma un tal caso ciascuna importazione sarà vista con una
 417 diversa \textit{release}. Ad ogni operazione di modifica del
 418 \textit{repository} viene infatti assegnato un numero progressivo che consente
 419 di identificarne la storia delle modifiche e riportarsi ad un dato punto della
 420 stessa in ogni momento successivo.\footnote{a differenza di CVS Subversion non
 421   assegna un numero di versione progressivo distinto ad ogni file, ma un
 422   numero di \textit{release} progressivo ad ogni cambiamento globale del
 423   repository, pertanto non esiste il concetto di versione di un singolo file,
 424   quanto di stato di tutto il \textit{repository} ad un dato momento, è
 425   comunque possibile richiedere in maniera indipendente la versione di ogni
 426   singolo file a qualunque \textit{release} si desideri.}
 427
 428 Una volta eseguita l'importazione di una versione iniziale è d'uopo cancellare
 429 la directory originale e ripartire dal progetto appena creato. L'operazione di
 430 recuperare ex-novo di tutti i file che fanno parte di un progetto, chiamata
 431 usualmente \textit{checkout}, viene eseguita con il
 432 comando:\footnote{alternativamente si può usare l'abbreviazione \texttt{svn
 433     co}.}
 434 \begin{verbatim}
 435 svn checkout URL [/pathname]
 436 \end{verbatim}
 437 che creerà nella directory corrente una directory corrispondente al nome
 438 specificato in coda alla URL passata come argomento, scaricando l'ultima
 439 versione dei file archiviati sul repository; alternativamente si può
 440 specificare come ulteriore argomento la directory su cui scaricare i file.
 441
 442 Sia in caso di \texttt{import} che di \texttt{checkout} è sempre possibile
 443 operare su una qualunque sotto cartella contenuta all'interno di un
 444 \textit{repository}, ignorando totalmente quello che sta al di sopra, basterà
 445 indicare in sede di importazione o di estrazione iniziale un pathname o una
 446 URL che identifichi quella parte del progetto.
 447
 448 Se quando si effettua lo scaricamento non si vuole usare la versione più
 449 aggiornata, ma una versione precedente si può usare l'opzione \texttt{-r}
 450 seguita da un numero che scaricherà esattamente quella \textit{release},
 451 alternativamente al posto del numero si può indicare una data, e verrà presa
 452 la \textit{release} più prossima a quella data.
 453
 454 A differenza di CVS Subversion non supporta l'uso di \textsl{etichette}
 455 associate ad una certa versione del proprio progetto, per questo è invalso
 456 l'uso di strutturare il repository secondo lo schema illustrato inizialmente;
 457 è infatti molto semplice (e non comporta nessun tipo di aggravio) creare delle
 458 copie complete di una qualunque parte del \textit{repository} su un'altra
 459 parte dello stesso, per cui se si è eseguito lo sviluppo sulla cartella
 460 \texttt{trunk} sarà possibile creare banalmente una versione con etichetta
 461 \texttt{label} (o quel che si preferisce) semplicemente con una copia eseguita
 462 con:
 463 \begin{verbatim}
 464 svn cp trunk tags/label
 465 \end{verbatim}
 466
 467 Il risultato di questo comando è la creazione della nuova cartella
 468 \texttt{label} sotto \texttt{tags}, che sarà assolutamente identica, nel
 469 contenuto (e nella sua storia) a quanto presente in \texttt{trunk} al momento
 470 dell'esecuzione del comando. In questo modo, una volta salvate le
 471 modifiche,\footnote{la copia viene eseguita localmente verrà creata anche sul
 472   \textit{repository} solo dopo un \textit{commit}.} si potrà ottenere la
 473 versione \texttt{label} del proprio progetto semplicemente eseguendo un
 474 \textit{checkout} di \texttt{tags/label} in un'altra
 475 directory.\footnote{ovviamente una volta presa la suddetta versione si deve
 476   aver cura di non eseguire nessuna modifica a partire dalla stessa, per
 477   questo se si deve modificare una versione etichettata si usa
 478   \texttt{branches}.}
 479
 480 Una volta creata la propria copia locale dei programmi, è possibile lavorare
 481 su di essi ponendosi nella relativa directory, e apportare tutte le modifiche
 482 che si vogliono ai file ivi presenti; due comandi permettono inoltre di
 483 schedulare la rimozione o l'aggiunta di file al
 484 \textit{repository}:\footnote{a differenza di CVS si possono aggiungere e
 485   rimuovere, ed anche spostare con \texttt{svn mv}, sia file che directory.}
 486 \begin{verbatim}
 487 svn add file1.c
 488 svn remove file2.c
 489 \end{verbatim}
 490 ma niente viene modificato sul \textit{repository} fintanto che non viene
 491 eseguito il cosiddetto \textit{commit} delle modifiche, vale a dire fintanto
 492 che non viene dato il comando:\footnote{in genere anche questo viene
 493   abbreviato, con \texttt{svn ci}.}
 494 \begin{verbatim}
 495 svn commit [file]
 496 \end{verbatim}
 497 ed è possibile eseguire il \textit{commit} delle modifiche per un singolo
 498 file, indicandolo come ulteriore argomento, mentre se non si indica nulla
 499 verranno inviate tutte le modifiche presenti.
 500
 501 Si tenga presente però che il \textit{commit} non verrà eseguito se nel
 502 frattempo i file del \textit{repository} sono stati modificati; in questo caso
 503 \texttt{svn} rileverà la presenza di differenze fra la propria
 504 \textit{release} e quella del \textit{repository} e chiederà che si effettui
 505 preventivamente un aggiornamento. Questa è una delle operazioni di base di
 506 Subversion, che in genere si compie tutte le volte che si inizia a lavorare,
 507 il comando che la esegue è:
 508 \begin{verbatim}
 509 svn update
 510 \end{verbatim}
 511
 512 Questo comando opera a partire dalla directory in cui viene eseguito e ne
 513 aggiorna il contenuto (compreso quello di eventuali sotto-directory) alla
 514 versione presente, scaricando le ultime versioni dei file esistenti o nuovi
 515 file o directory aggiunte, cancellando eventuali file e directory rimossi dal
 516 \textit{repository}.  Esso inoltre esso cerca, in caso di presenza di
 517 modifiche eseguite in maniera indipendente sulla propria copia locale, di
 518 eseguire un \textsl{raccordo} (il cosiddetto \textit{merging}) delle stesse
 519 con quelle presenti sulla versione del \textit{repository}.
 520
 521 Fintanto che sono state modificate parti indipendenti di un file di testo in
 522 genere il processo di \textit{merging} ha successo e le modifiche vengono
 523 incorporate automaticamente in conseguenza dell'aggiornamento, ma quando le
 524 modifiche attengono alla stessa parte di un file nel ci si troverà di fronte
 525 ad un conflitto ed a quel punto sarà richiesto al ``committente'' di
 526 intervenire manualmente sui file per i quali sono stati rilevati i conflitti
 527 per risolverli.
 528
 529 Per aiutare il committente nel suo compito quando l'operazione di
 530 aggiornamento fallisce nel raccordo delle modifiche lascia sezioni di codice
 531 in conflitto opportunamente marcate e separate fra loro come nell'esempio
 532 seguente:
 533 \begin{verbatim}
 534 <<<<<<< .mine
 535         $(CC) $(CFLAGS) -o pamacq pamacq.c -lm
 536 =======
 537         $(CC) $(CFLAGS) -o pamacq pamacq.c
 538
 539 >>>>>>> r.122
 540 \end{verbatim}
 541
 542 In questo caso si c'è stata una modifica sul file (mostrata nella parte
 543 superiore) incompatibile con quella fatta nel \textit{repository} (mostrata
 544 nella parte inferiore). Prima di eseguire un \textit{commit} occorrerà
 545 pertanto integrare le modifiche e salvare nuovamente il file rimuovendo i
 546 marcatori, inoltre prima che il \textit{commit} ritorni possibile si dovrà
 547 esplicitare la risoluzione del conflitto con il comando:
 548 \begin{verbatim}
 549 svn resolved file
 550 \end{verbatim}
 551
 552 \begin{table}[htb]
 553   \centering
 554   \footnotesize
 555   \begin{tabular}[c]{|c|l|}
 556     \hline
 557     \textbf{Flag} & \textbf{Significato} \\
 558     \hline
 559     \hline
 560     \texttt{?}& File sconosciuto.\\
 561     \texttt{M}& File modificato localmente.\\
 562     \texttt{A}& File aggiunto.\\
 563     \texttt{C}& File con conflitto.\\
 564 %    \const{G}& File con modifiche integrate.\\
 565 %    \const{}& .\\
 566     \hline
 567   \end{tabular}
 568   \caption{Caratteri associati ai vari stati dei file.}
 569   \label{tab:svn_status}
 570 \end{table}
 571
 572
 573 Infine per capire la situazione della propria copia locale si può utilizzare
 574 il comando \texttt{svn status} che confronta i file presenti nella directory
 575 locale rispetto alla ultima versione scaricata dal \textit{repository} e per
 576 tutti quelli che non corrispondono stampa a schermo delle informazioni di
 577 stato nella forma di un carattere seguito dal nome del file, secondo quanto
 578 illustrato in tab.~\ref{tab:svn_status}.
 579
 580
 581
 582
 583 % LocalWords:  make Makefile makefile shell FC FLAGS CFLAGS pathname CERN SCM
 584 % LocalWords:  OBJ commondef readfile FFLAGS Cuncurrent Version System CVS home
 585 % LocalWords:  adidsp geometry muonacq andaranno CVSROOT startup cvs ssh rsh to
 586 % LocalWords:  project tag Root commit update merging Locally Modified Added co
 587 % LocalWords:  Needs Patch Merge log rtag checkout module altrobersaglio Source
 588 % LocalWords:   Control Subversion repository DAV svnserve URL svn subversion
 589 % LocalWords:  client sez svnadmin Truelite Srl trunk tags branches tab add rm
 590 % LocalWords:  remove copy cp move resolved label
 591
 592
 593
 594 %%% Local Variables:
 595 %%% mode: latex
 596 %%% TeX-master: "gapil"
 597 %%% End: