Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

Come utilizzare le funzionalità avanzate di Subversion

Come configurare e gestire le proprietà, le password e le autorizzazioni, le etichette e i rami di codice in Subversion
Come configurare e gestire le proprietà, le password e le autorizzazioni, le etichette e i rami di codice in Subversion
Link copiato negli appunti

In un precedente articolo abbiamo introdotto Subversion, un sistema server avanzato per tenere traccia del codice dei propri progetti, siano essi di programmazione classica siano essi di applicazioni per il Web. In questo secondo articolo serie tratteremo alcune funzionalità avanzate dell'SVN, come:

  • Gestione delle proprietà

  • Password e Autorizzazioni

  • Tagging e Branching

Il client utilizzato sarà TortoiseSVN, come nel primo articolo, e tutti i riferimenti ad operazioni da svolgere tramite il client saranno eseguite tramite questo software.

Gestione delle proprietà

SVN permette di definire le singole proprietà di ogni path, ovvero cartelle e file, per permettere agli sviluppatori di automatizzare certe operazioni. Ad esempio è possibile definire il tipo di EOL, ovvero End Of Line, da usare con file non binari, convertendoli in automatico in formato Dos, Unix o Mac, ovvero avendo come terminatore della riga rn, CRLF, n, LF, o r, CR.

Queste modifiche non devono essere eseguite direttamente sul Repository ma sulla vostra Working Copy e poi inviarle. Per fare queste modifiche è necessario usare un client SVN che supporti le proprietà. Nel nostro caso possiamo:

  • Fare click col bottone destro sul file o sulla cartella che ci interessa configurare

  • Selezionare Proprietà dal menu

  • Tra le tab in alto nella finestra appena comparsa selezionare Subversion

Nella scheda selezionata sono presenti vari informazioni sulla storia dell'elemento selezionato, oltre alle proprietà, che si trovano in fondo alla pagina. Ogni proprietà è definita da un namespace, il nome prima del carattere due punti, ed il nome della proprietà, a destra.

Tra le proprietà più importanti vi sono:

  • svn:ignore, che definisce quali path ignorare

  • svn:keywords, che contiene un'elenco di parole chiavi da sostituire all'interno del file con dei dati provenienti dal repository

  • svn:eol-style, che, come anche detto su, permette di definire il tipo di EOL usato nei file

È anche possibile creare delle proprietà non gestite direttamente da SVN, ma utilizzate da software esterni che ad ogni commit vanno a ciclarsi l'intero albero per eseguire delle specifiche operazioni in base a queste proprietà.

Password e Autorizzazioni

Un'altra funzionalità sicuramente importante di Subversion è la possibilità di definire, oltre agli utenti che possono accedere al repository, a quali percorsi gli utenti o gruppi di utenti possono accedere, permettendo quindi una certa flessibilità in situazioni dove sono presenti più gruppi di lavoro autonomi che operano sullo stesso repository.

Come accennato nel primo articolo, all'interno della cartella conf, presente all'interno del repository, è possibile trovare altri due file, oltre al file di configurazione principale:

  • passwd: che contiene l'elenco di utenti e password di accesso;

  • authz: dove è possibile definire i gruppi di utenti e le autorizzazioni d'accesso ai singoli percorsi;

Il file contenente le password, di default, è il seguente:

### This file is an example password file for svnserve.
### Its format is similar to that of svnserve.conf. As shown in the
### example below it contains one section labelled [users].
### The name and password for each user follow, one account per line.
# [users]
# harry = harryssecret
# sally = sallyssecret

Come si può vedere la struttura del file è estremamente semplice: ogni riga contiene un solo utente e la password va inserita, dopo il carattere uguale, in chiaro. Inoltre, queste righe, devono essere inserite sotto la riga [users]. Il carattere cancelletto ('#') va rimosso in quanto indica che la riga è per intero un commento e fa quindi esclusa. Ad esempio, se volessimo dare accesso a tre utenti, chiamati daniele, francesco e giulio, il file passwd dovrebbe contenere il testo seguente:

[users]
daniele = password_di_daniele
francesco = password_di_francesco
giulio = password_di_giulio

Una volta eseguita quest'operazione è necessario modificare il file svnserve.conf per disabilitare l'accesso in scrittura, e volendo anche quello in lettura, agli utenti anonimi in modo da permettere le modifiche al repository soltanto agli utenti autorizzati. Inoltre è anche necessario abilitare il database delle password.

Per disabilitare l'accesso degli utenti anonimi cercare il parametro anon-access e cambiare il valore da write a read, per togliere l'accesso in scrittura, o a none, per non permettere completamente l'accesso ai non autorizzati. Per abilitare, invece, il database delle password basta aggiungere la seguente riga:

password-db = passwd

A questo punto, ogni volta che dovrete eseguire un'operazione di scrittura, ed anche di lettura se avete impostato anon-access su none, vi dovrete autenticare con Subversion. Usando TortoiseSVN, alla prima autenticazione, si potrà attivare l'opzione per il salvataggio dei dati di autenticazione in modo che questa venga eseguita in automatico per gli accessi successivi.

Per modificare i gruppi di lavoro o le autorizzazioni alle path presenti nel repository è possibile modificare il file authz, che di default contiene:

### This file is an example authorization file for svnserve.
### Its format is identical to that of mod_authz_svn authorization
### files.
### As shown below each section defines authorizations for the path and
### (optional) repository specified by the section name.
### The authorizations follow. An authorization line can refer to a
### single user, to a group of users defined in a special [groups]
### section, or to anyone using the '*' wildcard. Each definition can
### grant read ('r') access, read-write ('rw') access, or no access
### ('').
# [groups]
# harry_and_sally = harry,sally
# [/foo/bar]
# harry = rw
# * =
# [repository:/baz/fuz]
# @harry_and_sally = rw
# * = r

Questo file ha una struttura estremamente simile sia a svnserve.conf sia a passwd, e come questi è molto facile da modificare. Per gestire i gruppi basta aggiungere, modificare, rimuovere o commentare le righe presenti sotto la sezione [groups].

Il gruppo è composto dal nome, a sinistra, e dall'elenco di utenti separati da virgola, a destra dopo l'uguale. Per impostare le autorizzazioni dei percorsi è invece necessario definire delle sezioni contenenti il percorso stesso in formato UNIX ed inserire sotto questo quali utenti o gruppi possono eseguire le operazioni all'interno. È anche possibile definire l'operazione di default per tutti gli utenti non elencati tramite il carattere asterisco ('*').

Sono presenti 3 possibili opzioni è sono:

  • Read-Only: che corrisponde a r, e permette solo la lettura dei dati presenti in quel percorso

  • Read-Write: che corrisponde a rw, e permette sia scrittura sia lettura

  • None: per il quale non è necessario scrivere nulla dopo l'uguale, che disabilita completamente l'accesso

Se quindi volessimo creare un gruppo di lavoro composto da francesco e giulio dando loro la possibilità di modificare la path /Gruppo1 dovremmo modificare il file come segue:

[groups]
gruppo1 = francesco,giulio
[/]
* = rw
[/Gruppo1]
daniele = 

Come per la gestione delle password, anche per la gestione delle autorizzazione è necessario aggiungere il nome del file contenente le autorizzazioni ai percorsi, all'interno del file di configurazione svnserve.conf, aggiungendo la seguente riga:

authz-db = authz

Una volta eseguita questa operazione le modifiche alla path /Gruppo1, all'interno del repository, che si tratti di file o di cartelle, potranno essere eseguite soltanto dal gruppo1, ovvero da francesco e giulio.

Una cosa molto importante da ricordare, quando si definiscono le policy di accesso, è che ogni path eredita la configurazione della path padre di conseguenza la path /Gruppo1 è leggibile e scrivibile da tutti gli utenti che non si chiamano daniele! Se aggiungerete altri utenti questi avranno accesso alla cartella nella quale dovrebbe lavorare soltanto il gruppo1, quindi sarebbe meglio modificare in maniera più opportuna la policy specificando l'accesso esclusivo da parte del gruppo1 invece di escludere gli utenti che non hanno accesso.

Tagging e Branching

La gestione di progetti, molto spesso, richiede l'esecuzione di modifiche sul codice che non sia quello principale del repository o ancora richiede la possibilità di identificare una data revisione del repository con una versione ben precisa, versione che deve essere mantenuta per poter magari dare supporto ai clienti che ne fanno uso, creare dei fix e delle patch da spedire e cosi via.

Queste operazioni, per l'appunto, si chiamano:

  • Tagging: o etichettare, che per l'appunto permette di definire una data revisione come una specifica versione

  • Branching: o branca, ramo, che crea, partendo dal codice principale, un ramo avente lo stesso codice di base

In realtà le due operazioni fanno la stessa cosa: clonano il codice della propria working copy, dell'ultima revisione o di una revisione precedente in una cartella del repository stesso permettendo quindi di fare tutto ciò che si vuole su queste copie che comunque vengono conservate all'interno del repository.

Per poter lavorare meglio, di solito, si crea un cartella principale chiamata trunk, ovvero tronco, nella root del repository, che identifica il codice principale, mentre le branche del codice in vanno inserite in un'apposita cartella, anch'essa nella root, chiamata branches.

Facendo in questo modo si evita parecchia confusione e si evita di mischiare il codice principale con le sue copie. Per fare quest'operazione tramite il client è necessario:

  • Fare click col bottone destro del mouse nella cartella che contiene il codice o comunque nella cartella che si vuole clonare

  • Dal menu che compare selezionare la voce TortoiseSVN

  • Dal sottomenu selezionare Branch/Tag

Nella finestra che compare è necessario compilare le informazioni richieste, come ad esempio la cartella sorgente, la cartella di destinazione, una messaggio di log ed altro. Una volta eseguita questa operazione è necessario creare una nuova Working Copy che lavori sul codice appena clonato, operazione per la quale basta eseguire un normale checkout del codice sulla cartella appena creata piuttosto che sulla cartella del codice.

Conclusioni

Su Subversion si potrebbero scrivere pagine e pagine di articoli perchè è uno strumento infinitamente potente come molti di voi hanno sicuramente intuito. Può essere integrato con sistemi di tracciamento dei bug, come ad esempio Bugzilla, può essere integrato con sistemi di report automatici, report contenenti grafici delle modifiche al codice, o ancora può essere integrato con sistemi di build automatici, sistemi che in automatico creino per voi le nigth build del vostro codice, o tanto altro ancora.

L'effettivo limite di questo software è rappresentato più dalla vostra fantasia che dal programma stesso, essendo supportato da software potenti, flessibili e soprattutto estendibili. Per chi volesse approfondire questo favoloso strumento può scaricare il manuale in inglese- Inoltre, per maggiori approfondimenti, vi consiglio di visitare il sito principale di Subversion.


Ti consigliamo anche