SVN: cos’è e come funziona

29 May 2009 » In informatica, php
Tag: branch, merge, repository, subversion, svn, tag

Fino a qualche mese fa nemmeno io sapevo più di tanto su Subversion e sugli strumenti di versioning in generale. Oltre ai concetti fondamentali non mi ero mai spinto, forse anche perchè per lavoro non mi sono mai trovato a doverli utilizzare. O meglio non li ho trovati nelle aziende per cui ho lavorato. Tuttavia averli avuti a disposizione ogni tanto avrebbe fatto davvero comodo. Vediamo perchè…

Innanzitutto va detto che Subversion è un version control system open source che si occupa di gestire file e directory e le modifiche che possono subire con il passare del tempo. Questo permette di recuperare una certa versione di un file, seguire l’evoluzione di certi contenuti nel tempo. Praticamente è una piccola macchina del tempo.

Subversion può lavorare in rete permettendo quindi a persone distanti anche migliaia di chilometri di lavorare sugli stessi file dello stesso progetto in modo semplice e sicuro. E’ possibile impostare diversi livelli di accesso a determinati file e directory. L’evoluzione dei dati gestiti da Subversion può essere molto rapida, tuttavia è altrettanto semplice risolvere un problema introdotto da una modifica tornando alla versione precedente del contenuto specifico.

Mi può servire?

Vi starete sicuramente chiedendo se Subversion è lo strumento che fa per voi. Capirlo è molto semplice.

Avete bisogno di archiviare vecchie versioni di file e directory con la possibilità di andare a ripescarle facilmente e di controllare la loro evoluzione nel tempo confrontando le singole modifiche dello stesso file in diverse versioni? Subversion fa per voi.

Avete la necessità di lavorare con altri colleghi sparsi in rete sugli stessi file, tenendo traccia di chi ha fatto una particolare modifica e quando? Subversion è lo strumento che fa per voi.

Vantaggi principali

Il problema principale derivante dal fatto di lavorare in team sullo stesso progetto senza uno strumento di versioning è quello delle sovrascritture dei file e quindi delle modifiche fatte dagli altri. Un’immagine ricavata dalla documentazione di Subversion è più esplicativa di mille parole:

Subversion si basa sul concetto copy-modify-merge e di working copy secondo i quali ogni utente lavora sulla propria copia locale del progetto prima di inviare le proprie modifiche al repository centrale. In questo modo è possibile lavorare in parallelo senza perdere tempo aspettanto l’unlock di un file come accade nel contesto lock-modify-unlock.

Chiaramente lavorando in parallelo sugli stessi file è possibile che si verifichino dei conflitti da risolvere manualmente se alcune modifiche sono in contrasto tra loro. Va anche detto che se il lavoro è ben distribuito non è frequente avere a che fare con dei conflitti da gestire, qualora ce ne fossero il tempo per gestirli sarebbe comunque minore al tempo perso in un sistema basato sui lock.

Concetti molto importanti sono quelli di branch e merge che permettono di avere rami paralleli di sviluppo e strumenti per la gestione semplice dei contenuti comuni oltre a permette di fondere poi i contenuti nuovamente in un unico ramo gestendo eventuli conflitti.

Per chiudere questa presentazione, assolutamente non esaustiva, cito anche il tag che rappresenta una vera e propria snapshot del progetto in un determinato momento. La creazione di un tag è associata molto spesso alla release del prodotto o di certe funzionalità aggiuntive di una certa entità. Puntanto quindi ad una specifica tag potremo ricavare il sistema come era in un determinato momento escludendo tutte le modifiche apportate in seguito.

Vantaggi per i piccoli team o per sviluppatori singoli

Personalmente non ho mai avuto la fortuna di lavorare in grandi team o su progetti molto vasti portati avanti da diverse persone. Questo ha comportato nella maggior parte dei casi che il progetto su cui stessi lavorando fosse tutto mio dall’inizio alla fine o che comunque nessuno avesse bisogno di scrivere codice su un file aperto da me. Anche le abitudini dell’azienda contano e purtroppo dove ho lavorato io nessuno mi ha mai “obbligato” ad usare uno strumento come Subversion.

Tuttavia anche lavorando da solo su un progetto molte volte ho sentito la necessità di poter utilizzare uno strumento di versioning per il semplice fatto di poter “tornare indietro” ed analizzare le modifiche fatte ad un file. Un semplice esempio può esprimere meglio il concetto:

Il cliente chiede di far visualizzare una galleria fotografica in un certo modo piuttosto elaborato rispetto alla versione attuale presente sul suo sito. Sappiamo tutti che il cliente non ha ben chiaro nè cosa vuole nè come dirlo, proprio per questo ci troveremo a sviluppare N versioni della galleria che man mano andranno a sovrascrivere la versione precedente. E’ altresì molto probabile che nessuno faccia una copia di backup di tutte le versioni ma si proceda per iterazioni rilasciando sempre ciò che si modifica.

Ad un certo punto il cliente decide che la versione N-x era quella giusta. Come fare? Senza versioning ci si deve augurare di ricordarsi alla meno peggio ciò che si era fatto (che può essere moooolto distante dalla versione attuale) e riscrivere il codice totalmente da zero. Con il versioning basta cercare la versione corretta del file e recuperarla o analizzare le differenze con la versione attuale per muoversi al meglio.

Altro esempio potrebbe essere quello di dover recuperare quel frammento di codice usato tempo fa e poi dismesso ma che ora serve nuovamente. Non è bello lasciare porzioni di codice commentato nei propri listati in attesa di essere forse riutilizzati, con il versioning si possono eliminare e andare a recuperarli quando e SE serviranno.

Anche la possibilità di sfruttare il branching di un progetto e quindi di portare avanti in modo parallelo lo sviluppo della nuova area del sito o della nuova funzionalità dell’applicazione e lo sviluppo/mantenimento di ciò che già esiste rappresenta un bel vantaggio. Mentre nel trunk continuiamo ad avere una versione completamente funzionante dell’applicazione, su cui eventualmente si eseguono piccoli bug fix o leggere modifiche, nel branch creato è possibile sviluppare in tutta calma le nuove funzionalità (che occupano un arco temporale anche di una certa entità) fino a quando saranno ultimate e fatte ricadere quindi nel trunk.

In questo modo non esistono più attività bloccanti che impediscono di fare altre cose perchè ora il codice “è cambiato”, c’è sempre una versione funzionante da poter utilizzare e su cui poter lavorare senza pensieri.

Concludendo

I progetti più attivi su cui lavoro ho già provveduto ad importarli sull’svn aziendale creato ad hoc. Checkout e commit sono ormai all’ordine del giorno ed i dati delle revisioni possono essere sfruttati per alimentare altre applicazioni come Trac o Redmine che permettono una più facile lettura di questa mole di informazioni. Visto che di questo si potrebbero scrivere altri N post non mi dilungo, se qualcuno è interessato possiamo parlarne nei commenti. I nuovi progetti invece partiranno da svn in modo “nativo” per mia gran gioia.

Tornare indietro? Non se ne parla nemmeno! Mai più senza SVN! E voi come rispondereste?

Commenti

Post recenti

Negli ultimi 12 mesi...

February 2010 (1)
November 2009 (2)
September 2009 (3)
August 2009 (2)
July 2009 (8)
June 2009 (10)
May 2009 (6)
April 2009 (10)
March 2009 (10)
February 2009 (10)
January 2009 (9)
December 2008 (19)