Subversion. modalità d'uso di subversion. Federico Bernardin. Versione 1.0.0

Transcript

1 modalità d'uso di subversion Federico Bernardin Versione Questo documento descrive le modalità di utilizzo di un client subversion

2 Indice Indice Indice... 2 Termini fondamentali...3 La filosofia di subversion... 4 Modelli di versionamento...4 Componenti... 5 Caricamento dei dati nel repository... 6 Checkout vuoto...6 Importazione di un progetto... 6 Checkout: estrarre dati dal repository...7 Estrarre singoli file o cartelle...7 Caricare le modifiche... 8 Caricamento delle modifiche... 8 Update: aggiornare la copia locale...9 Cancellazione di una copia di valoro locale... 9 Navigare tra le versioni...10 Estrazione di una revisione specifica...10 Lavorare sullo storico...12 Verificare lo storico...12 Ripristinare una revisione precedente Conflitti e modifiche locali Risolvere i conflitti...14 Esaminare i cambiamenti locali...14 I lock e le sovrapposizioni...16 Parliamoci... e usiamo Subversion...16 I rami (branches) Creazione di un ramo Spostare un repository già creato...18 Unire i cambiamenti Merge basilare Merge successivi...19 Le etichette (tags) Altri utilizzi delle revisioni tag...21 La struttura del repository...22 La struttura interna...22 La struttura esterna...22 Gli script di hook Comandi utili lato server...25 svnadmin...25 svndumpfilter /5/2009 Pagina 2 di 35

3 Indice svnlook svnsync...26 Spazio su disco /5/2009 Pagina 3 di 35

4 Termini fondamentali Termini fondamentali Il primo è più importante concetto è quello del repository: il deposito dove risiedono i nostri dati. È possibile creare diversi repository su ogni server Subversion; vedremo come ciascuno di essi sia accessibile con un URL specifico. Per lavorare sui file si utilizza il client SVN per creare una copia di lavoro locale. Tale copia è quella su cui vengono effettuate le vere e proprie modifiche, che poi verranno caricate sul server. La creazione di una nuova copia di lavoro locale è detta checkout. Contrariamente ad altri sistemi di controllo di versione, in Subversion tale operazione non blocca niente sul server: semplicemente estrae i file per permetterci di cominciare a lavorare su di essi. Si possono fare quanti checkout si vogliono, anche solo per consultazione, eliminando poi la copia locale quando non ci serve più. Il caricamento delle modifiche locali sul server è detto commit. È quando effettuiamo un commit che entra in gioco il "filtro" di Subversion, con l'obiettivo di controllare e segnalare se le nostre modifiche vadano in conflitto con altre già presenti sul repository. Ogni commit andato a buon fine genera una nuova revisione, ovvero aumenta di 1 il numero di revisione del repository. Ogni repository parte alla revisione 0. L'aggiornamento di una copia locale già esistente è detto update. In maniera opposta al commit, si occupa di applicare alla nostra copia di lavoro le ultime modifiche caricare sul repository. Le operazioni di checkout, commit e update si effettuano con gli omonimi comandi. I rami (branches) sono versioni separate del progetto, solitamente diversificate per permettere l'implementazione di aggiunte o modifiche rispetto al ramo principale, mantenendo tale ramo principale intatto. Le etichette (tag) sono un modo per "fissare" definitivamente una revisione che ha un significato particolare, ad esempio il primo rilascio di un progetto. Per non doversi ricordare il numero di revisione, si può etichettare (appunto) la revisione con un nome specifico che risulti mnemonico per noi (es. "Versione di rilascio"). Nota: se "ramo" è una traduzione accettabile e abbastanza univoca dell'originale "branch", per il termine "tag" la questione è più complicata. "Etichetta" ci sembra forse la migliore scelta, nonostante nella guida ufficiale in italiano si usi il termine "targa", forse per assonanza. Di certo, vista la diffusione del termine originale anche nel nostro linguaggio, tutti vi capiranno se parlate di "revisioni taggate". Nel resto di questa guida useremo i termini "etichetta" e "tag" come sinonimi. 29/5/2009 Pagina 4 di 35

5 La filosofia di subversion La filosofia di subversion Subversion non è particolarmente schizzinoso relativamente al tipo di dati di cui si deve occupare. Altri sistemi di controllo dei sorgenti possono essere più specifici, ad esempio essere dedicati a un determinato linguaggio di programmazione e includere magari anche un debugger o un compilatore automatico; Subversion non è così. Qualunque server Subversion può ospitare contemporaneamente sorgenti PHP e HTML, ma anche normale documentazione, guide, articoli, e perfino immagini, brani musicali, e qualsiasi altro file vi venga in mente. Potremmo utilizzarlo anche per salvare le nostre macchine virtuali. L'unica importante distinzione è tra i file di tipo mergeable e binari. I primi sono sostanzialmente file di testo, in cui le diverse modifiche provenienti da diversi autori possono essere valutate e unite riga per riga, come spiegheremo più avanti. Gli altri file, invece, vengono considerati da Subversion come "monoblocco" e verranno sempre sostituiti interamente (stiamo parlando ad esempio di immagini o brani musicali). In questo secondo caso perdiamo la possibilità di unire le modifiche fatte da diversi utenti, ma rimane valido il controllo di versione vero e proprio, cioè la conservazione automatica e il rapido accesso alle versioni precedenti. Detto tutto questo, non cadiamo nell'errore di considerare Subversion un semplice sistema di archiviazione e distribuzione. Il suo obiettivo principale è quello di gestire i cambiamenti nel tempo, tenendo a portata di mano una copia di ciascuna versione e dandoci la possibilità di tracciare chi e quando ha introdotto certe modifiche. Modelli di versionamento Molti sistemi di controllo dei sorgenti adottano la tecnica Lock-Modify-Unlock, che io ho ribattezzato tecnica "della Biblioteca": ogni volta che qualcuno vuole modificare un file deve ritirarlo, come se prendesse a prestito un libro, e gli altri programmatori non hanno più alcuna possibilità di accesso al file; dovranno aspettare che il primo utente completi le modifiche e riconsegni il file. L'esperienza ha suggerito invece agli sviluppatori di CVS e di conseguenza anche di Subversion di adottare la soluzione Copy-Modify-Merge: i file non vengono bloccati dal primo che li apre, ma rimangono disponibili per chiunque. Questa soluzione si basa sull'idea che quando persone diverse stanno lavorando sullo stesso file, solitamente stanno affrontando problematiche diverse e quindi devono modificare parti diverse del file. Quindi, Subversion ci lascia lavorare contemporaneamente sui file, e al momento del commit (l'invio al server dei file modificati) tenta di unire le diverse modifiche, controllando la presenza di eventuali conflitti (modifiche che si sovrascrivono). Se ne trova, blocca il salvataggio, avverte lo sviluppatore, e come vedremo offre degli strumenti per identificare e risolvere rapidamente tali conflitti. Come si può intuire, la soluzione Copy-Modify-Merge si applica solo ai file di tipo 29/5/2009 Pagina 5 di 35

6 La filosofia di subversion mergeable. Negli altri casi, ad esempio un'immagine, la modifica contemporanea non ha senso in quanto si risolverebbe sempre in un conflitto e una delle due versioni andrebbe comunque buttata via. Per evitare questo, Subversion ci consente di usare anche il modello Lock-Modify-Unlock; dobbiamo però forzarlo noi, attraverso l'utilizzo di un comando apposito. 29/5/2009 Pagina 6 di 35

7 Caricamento dei dati nel repository Caricamento dei dati nel repository Checkout vuoto Se partiamo da zero, ovvero senza aver scritto una riga di codice o documentazione, possiamo usare fin da subito i comandi client di uso quotidiano, che approfondiremo più avanti nella guida. Per ora anticipiamo che probabilmente sfrutteremo il vostro client SVN preferito per fare un checkout e creare una copia di lavoro locale vuota; poi aggiungeremo localmente uno o più nuovi file, e comincerete a modificarli; infine, dopo una giornata di duro lavoro, effettueremo il commit, cioè la consegna dei dati al server Subversion, e i nuovi file verranno automaticamente inseriti nel repository. Importazione di un progetto Può capitare anche di avere un progetto già esistente, che si vuole importare nel repository per poterlo d'ora in poi gestire tramite Subversion. Ad esempio, nel mio caso ho già scritto diverse lezioni di questa guida prima di avere completamente pronta la struttura sul server, per cui ora mi ritrovo con diversi file html che devo caricare. Ci viene in aiuto il comando import: svn import /local/path/myproject -m Messaggio di importazione Diamo un'occhiata ai parametri. La cartella /local/path/myproject è quella in cui risiede il nostro progetto prima di essere inserito in Subversion. Dopo l'operazione di importazione, tale cartella locale può anche essere cancellata. Sarà infatti necessario accedere al server e creare una nuova copia di lavoro locale per poter lavorare correttamente con Subversion. è chiaramente il percorso del repository. Il messaggio di importazione è un parametro obbligatorio (così come lo sarà per il comando commit) che permette di specificare un commento che rimarrà legato all'operazione. Apparentemente banale, questo commento ci sarà enormemente utile quando dovremo cercare tra le varie revisioni quella che più ci interessa, quindi è il caso di scrivere qualcosa di appropriato. Se tutto è corretto, dovremmo veder apparire l'elenco dei file che vengono caricati sul repository, e infine il messaggio: Completed At revision: 1 29/5/2009 Pagina 7 di 35

8 Checkout: estrarre dati dal repository Checkout: estrarre dati dal repository La prima operazione per qualunque utente che voglia cominciare a lavorare su un progetto gestito su un server SubVersion è il checkout, ovvero la creazione di una copia di lavoro locale. Tale copia è una normale cartella del filesystem che contiene i file scaricati dal server; in aggiunta, però contiene una serie di informazioni che il client SVN usa per sapere cosa fare quando viene richiesta una operazione di aggiornamento o di salvataggio delle modifiche. La sintassi del comando di checkout è: svn checkout svn://repository /local/work/path parametri sono abbastanza chiari: il primo rappresenta il percorso con cui raggiungere il repository e il secondo è il percorso locale in cui creare la copia di lavoro. Se tale percorso locale non viene specificato, il checkout verrà effettuato nella cartella corrente. Nota: se non esiste, la cartella viene creata in automatico dal client SVN; se la cartella esiste già, è opportuno accertarsi che sia vuota. Spostiamoci quindi nella cartella in cui vogliamo creare la cartella di lavoro, effettuiamo il CheckOut con il nostro client SVN. Ci verrà richiesto o dovremo inserire il percorso del repository e la cartella locale. Eseguiamo l'operazione e ci viene segnalato l'elenco dei file estratti, nonché la relativa revisione. A questo punto abbiamo, ricreata in locale, la struttura del nostro progetto. Se abbiamo abilitata l'opzione di visualizzare i file nascosti, vediamo anche che in ogni cartella è presente una sottocartella.svn. Si tratta della cartella che contiene le informazioni di cui sopra. Tra le altre cose, vengono qui conservate le copie "originali" dei file (cioè quelle scaricate con l'ultimo checkout o update) che il client usa come confronto per rilevare le modifiche effettuate localmente; nonché le informazioni sulla revisione scaricata e sulla data e ora dell'ultimo update. Per ora non ci addentriamo troppo nella struttura di queste cartelle nascoste: ciò che conta è che non vanno modificate né cancellate, pena la perdita delle informazioni di SubVersion e la necessità di ricreare la copia di lavoro locale. Estrarre singoli file o cartelle Anziché estrarre tutto il contenuto del repository, è possibile specificare un determinato file o una determinata cartella, semplicemente inserendo il percorso completo, ad esempio nel nostro caso: 29/5/2009 Pagina 8 di 35

9 Checkout: estrarre dati dal repository svn checkout svn://svn.immaginario.info/skoda/trunk/index.php Anche in questo caso il percorso locale viene automaticamente precompilato, ma non comprende l'intero percorso del repository: si limita ad aggiungere alla cartella locale il nome del file o della cartella che stiamo estraendo. Nota: attenzione a non effettuare checkout successivi sulla stessa cartella, in caso contrario avremo la certezza di rovinare completamente la nostra copia di lavoro. Il comando giusto per aggiornare la nostra copia locale è svn update, che vedremo nella prossima lezione. 29/5/2009 Pagina 9 di 35

10 Caricare le modifiche Caricare le modifiche Abbiamo visto che nella nostra copia di lavoro esistono cartelle "speciali" che contengono le informazioni di versione. Grazie a questa localizzazione delle informazioni, gli altri file non hanno invece nulla di speciale e possono essere quindi modificati con qualsiasi strumento. Quindi, se stiamo parlando di codice o documentazione, possiamo aprire il file con il nostro editor preferito e lavorare normalmente. Il client SVN infatti entra in gioco solo nel momento in cui tentiamo di caricare le modifiche con un comando commit. È confrontando i file della copia di lavoro, con la copia "originale" presente nelle cartelle nascoste, che il client SVN è in grado di determinare quali file avete cambiato e quindi quali modifiche sono da caricare sul server. Cambia invece, e dobbiamo tenerlo ben presente, la modalità di ridenominazione, spostamento, cancellazione e aggiunta di file e cartelle. Per tutte queste operazioni, al posto dei classici comandi del filesystem, dovremo usare gli appositi comandi SVN: svn add svn delete svn copy svn move Subversion infatti, a differenza di CVS, è in grado di tenere traccia storica di questo genere di modifiche, ma non può farlo automaticamente. Supponiamo infatti di spostare un file in una diversa cartella della nostra copia di lavoro senza usare il comando apposito, ma semplicemente trascinando il file con il mouse. Al momento del commit, il client SVN si accorge che c'è un file in meno nella prima cartella e un file in più nella seconda cartella. Come può sapere se si tratta dello stesso file, o invece se il primo file sia stato cancellato e questo sia un nuovo file? Se invece usiamo il comando move, lo spostamento del file verrà registrato come modifica e trasmesso al repository, con due evidenti vantaggi: 1. il file porterà con sè lo storico delle proprie modifiche anche nella nuova posizione; 2. lo spostamento, come qualunque modifica, potrà essere annullato semplicemente ritornando a una revisione precedente. Caricamento delle modifiche Il comando vero e proprio per caricare le modifiche è: svn commit --message "Messaggio di log" /local/path 29/5/2009 Pagina 10 di 35

11 Caricare le modifiche Come al solito, se non si specifica il percorso verrà applicato alla cartella corrente. Tale cartella può anche essere solo una sottocartella del progetto, non è necessario caricare sempre l'intero albero. È obbligatorio tuttavia specificare un messaggio di commit, tipicamente usato per descrivere il tipo di modifiche apportate. È arrivato il momento di provare a caricare le modifiche effettuate dopo il primo checkout. Clicchiamo con il tasto destro sulla cartella di lavoro locale e selezioniamo l'opzione SVN Commit. Ci viene mostrato l'elenco delle modifiche da apportare, con la possibilità di caricarne solo alcune. Lasciamo tutto com'è e procediamo. Appare il solito elenco delle operazioni effettuate (in questo caso vengono caricati gli ultimi file modificati), e infine il messaggio che indica che siamo arrivati alla revisione 2. 29/5/2009 Pagina 11 di 35

12 Update: aggiornare la copia locale Update: aggiornare la copia locale Come abbiamo già visto, il checkout va effettuato solo per la prima estrazione. In seguito, per aggiornare la propria una copia di lavoro locale all'ultima versione presente sul repository si usa il comando: svn update Questo comando confronta il repository con la copia locale, ed effettua di conseguenza le seguenti operazioni: applica ai file locali eventuali modifiche effettuate agli stessi file sul repository aggiunge alla copia locale eventuali nuovi file e cartelle presenti sul repository; rimuove dalla copia locale eventuali file o cartelle rimossi dal repository; L'aggiornamento viene lanciato tipicamente all'inizio della propria sessione di lavoro, per garantirsi di avere a disposizione le ultime versioni di tutti i file. Va inoltre lanciato prima di effettuare un commit, per evitare l'errore out-of-date: questo messaggio indica che qualcun altro ha modificato e caricato sul server un file dopo che noi l'abbiamo scaricato l'ultima volta sul nostro computer, per cui la nostra copia originale (quella nascosta) non è più aggiornata. Con un update portiamo in locale le ultime modifiche (verificando anche eventuali conflitti) e poi potremo procedere al commit. Nota: nonostante vengano effettuate in rapida sequenza, le azioni di update e di commit sono nettamente separate e non influiscono l'una sull'altra. In altre parole, quando si caricano le proprie modifiche, non vengono automaticamente scaricate le modifiche presenti sul repository; e al contrario, quando scarichiamo le ultime versioni dei file, non vengono caricate le proprie modifiche (e anzi, potremmo decidere di buttarle quando ci accorgessimo che qualcun altro le ha già fatte meglio di noi). In ciascuna copia di lavoro, possono essere presenti file in stato "unversioned". Si tratta di file temporanei creati dagli editor, oppure di note personali o configurazioni locali del progetto, che non devono essere trasportate sul repository. E' anche lo stato in cui si trovano eventuali nuovi file creati a mano prima di essere "ufficialmente" aggiunti al progetto con il comando svn add. Tali file non impediscono la normale operatività, ma per il client SVN rimangono delle anomalie da segnalare. E' possibile invece specificare una lista di file o di pattern (usando caratteri jolly) per indicare al client SVN che siamo coscienti dell'esistenza di tali file e che ci va bene così. Cancellazione di una copia di lavoro locale Se una copia di lavoro locale non ci serve più, magari perchè frutto di un test di estrazione, perchè volevamo solo verificare un file, o perchè l'abbiamo involontariamente pasticciata e quindi dobbiamo ricrearla, possiamo eliminarla semplicemente cancellando la cartella corrispondente. Ovviamente eventuali modifiche locali andranno perse, quindi è opportuno farlo solo per 29/5/2009 Pagina 12 di 35

13 Update: aggiornare la copia locale una buona ragione, come quelle sopraelencate. Soprattutto è importante non cancellare una copia di lavoro solo perchè è un po' che non la guardiamo e non abbiamo idea di quanto sia aggiornata e di cosa contenga. Per questo lasciamo fare a SubVersion, altrimenti cosa l'abbiamo installato a fare? Con pochi semplici comandi siamo in grado rapidamente di sapere quali sono le modifiche locali di qualsiasi copia di lavoro, nonché di aggiornarla all'ultima versione e di avere un rapporto dettagliato degli eventuali conflitti. 29/5/2009 Pagina 13 di 35

14 Navigare tra le versioni Navigare tra le versioni Un repository appena creato è inizialmente vuoto, e si trova alla revisione 0. Ogni volta che sul server viene caricata anche una sola modifica, l'intero albero aumenta di una revisione. Ad esempio, come abbiamo visto, l'importazione di un progetto ha portato il repository alla revisione 1, e allo stesso modo, ogni volta che abbiamo eseguito un commit la revisione è aumentate di uno. È importante capire che la revisione si applica a tutto l'albero: si tratta di una istantanea del contenuto dei file ma anche del loro nome, della loro posizione, e delle cartelle esistenti. Ogni volta che viene caricata una qualsiasi modifica, a uno qualsiasi dei file, viene effettuata una nuova instantanea e tutti i file (anche quelli non modificati) vengono portati alla nuova revisione. Non c'è da stupirsi quindi se alcuni file rimangono uguali tra le diverse revisioni: evidentemente non erano oggetto di modifica, ma sono stati comunque portati alla nuova revisione. Estrazione di una revisione specifica Nei diversi comandi di estrazione dei dati ci si può riferire ad una specifica revisione, grazie al parametro -r: -r <numero_revisione> In particolare, è possibile creare o aggiornare una copia locale partendo non dall'ultima, ma da una specifica revisione, con i comandi: svn checkout -r <numero_revisione> svn update -r <numero_revisione> Esistono anche della parole chiave per indicare revisioni "speciali": HEAD, indica l'ultima revisione presente nel repository. È la revisione implicitamente utilizzata quando non ne viene specificata una BASE, indica la revisione "originale" presente sulla propria copia di lavoro. Non si riferisce al server, ma solo alla copia locale; non include eventuali modifiche locali effettuate nel frattempo COMMITTED, indica l'ultima revisione uguale o precedente a BASE, nella quale un oggetto è stato modificato. Si riferisce quindi sempre alla copia di lavoro locale: permette sostanzialmente di identificare la revisione creata con l'ultimo commit andato a buon fine 29/5/2009 Pagina 14 di 35

15 Navigare tra le versioni PREV, indica la revisione immediatamente precedente a COMMITTED È possibile anche specificare una data per riferirsi a una versione, usando parentesi graffe. Alcuni esempi sono: --revision {" :00"} --revision { } --revision {19:00} Automaticamente, SVN troverà la versione più aggiornata entro quella data. Nota: se si specifica una data senza specificare l'ora (es. --revision { }) SVN considera come orario 00:00 e quindi, di fatto, considera le revisioni registrate fino al giorno prima (nell'esempio, fino al 10 lug alle 23:59). Per esaminare temporaneamente una diversa revisione, dobbiamo ricordare di effettuare checkout in una cartella diversa rispetto a quella che ospita la nostra copia di lavoro corrente. Creiamo quindi una copia di lavoro temporanea che, una volta esaminata, possiamo tranquillamente cancellare. 29/5/2009 Pagina 15 di 35

16 Lavorare sullo storico Lavorare sullo storico Subversion è un sistema di versioning, cioè mantiene un archivio storico di tutte le versioni dei file. Esaminiamo i comandi di che ci permettono di agire sulle versioni, dalla visualizzazione dele modifiche effettuate, al confronto tra versioni differenti. Verificare lo storico svn log ci permette di visualizzare i messaggi di log associati a una o più revisioni, ad esempio: svn log -r 5:9 mostra i log delle revisioni dalla 5 alla 9 (incluse). Se usando questo comando si riceve un log vuoto, dobbiamo assicurarci di essere nella cartella principale del progetto e non in una sottocartella. svn diff, che, come abbiamo già visto, può essere usato per verificare le modifiche locali, serve anche per effettuare un confronto tra diverse revisioni, ad esempio: svn diff -r 5:6 nomefile ci mostra un confronto tra la versione 5 e la 6 del file indicato. Se specifichiamo una sola revisione, viene effettuato un confronto tra la nostra copia di lavoro e la revisione indicata: svn diff -r 5 Ripristinare una revisione precedente Le operazioni esaminate finora ci permettono di vedere le modifiche effettuate, sia quelle locali e non ancora caricate sul repository, sia quelle delle varie revisioni. Con queste operazioni possiamo procedere manualmente a correggere eventuali modifiche fatte per errore, e poi caricare la copia corretta sul server. Ma se il nostro obiettivo è semplicemente quello di prendere una vecchia revisione e farla diventare attuale (HEAD), esiste un metodo migliore rispetto a fare un checkout temporaneo e copiare/incollare le modifiche. Tale metodo è fornito dal comando svn merge. Usato da linea di comando, svn merge ha tre possibili forme, a seconda che si vogliano confrontare due diversi repository, oppure due revisioni del repository dal quale abbiamo 29/5/2009 Pagina 16 di 35

17 Lavorare sullo storico estratto la nostra copia di lavoro attuale, oppure una specifica revisione di un repository e una copia di lavoro. Il comando è molto potente, ma bisogna fare attenzione alla sintassi giusta. È utile consultare il manuale ufficiale di SubVersion per una spiegazione dettagliata delle varie opzioni ed esempi. 29/5/2009 Pagina 17 di 35

18 Conflitti e modifiche locali Conflitti e modifiche locali Risolvere i conflitti Come abbiamo accennato, SubVersion è in grado di accorgersi se le modifiche effettuate da diversi utenti si sovrappongono. In tal caso ci segnala il conflitto e ci chiede di risolverlo. Se il file è di tipo mergeable (quindi non un file binario) ci viene ancora più incontro, inserendo nel file stesso dei marcatori che evidenziano il conflitto, come nell'esempio qui riportato: <<<<<<<.mine codice copia locale codice copia locale ======= codice copia sul repository codice copia sul repository codice copia sul repository >>>>>>>.r2 La parte superiore mostra la versione locale del contenuto, mentre la parte inferiore mostra la versione del repository. Vengono inoltre creati nella nostra copia di lavoro altri tre file temporanei: nomefile.mine il nostro file locale, con le ultime modifiche che abbiamo cercato di caricare nomefile.rbase il file presente nella copia "nascosta", quindi prima delle modifiche locali nomefile.rhead l'ultimo file presente sul repository BASE e HEAD vengono sostituiti dai corrispondenti numeri di versione. Per risolvere il conflitto abbiamo quindi diverse strade: unire a mano le modifiche, sfruttando i marcatori inseriti da SubVersion sovrascrivere il file che crea conflitto con uno dei tre file temporanei sopra elencati usare il comando svn revert per annullare tutte le modifiche locali Se scegliamo la strada 1 o la 2, che sono modifiche manuali, dovremo poi avvertire SVN dell'avvenuta risoluzione usando il svn resolved nomefile. Esaminare i cambiamenti locali Ci sono diversi comandi che ci permettono di avere informazioni sulla nostra copia di lavoro locale senza nemmeno bisogno di collegarsi al repository. Per verificare lo stato della copia di lavoro è disponibile il comando svn status, che ci permette tra le altre cose di sapere quali file sono stati modificati, aggiunti, cancellati; 29/5/2009 Pagina 18 di 35

19 Conflitti e modifiche locali in pratica ci offre una anteprima di quello che succederebbe con un commit. Per visualizzare nel dettaglio le modifiche apportate a uno specifico file rispetto alla revisione BASE, è disponibile il svn diff. Vedremo che lo stesso comando può essere usato anche per confrontare revisioni diverse, ma in questo caso bisogna collegarsi al repository. Infine, per annullare le modifiche locali effettuate e tornare alla revisione BASE, è disponibile il comando svn revert. Tale comando annulla anche le operazioni di aggiunta/ eliminazione/spostamento dei file, a patto che siano state realizzate con i comandi SVN appropriati. 29/5/2009 Pagina 19 di 35

20 I lock e le sovrapposizioni I lock e le sovrapposizioni Nelle prime lezioni abbiamo introdotto il modello di versionamento Copy-Modify-Merge e abbiamo visto come questo non possa essere indistintamente applicato a tutti i file. In particolare la fusione di diverse modifiche non è disponibile per i file non-mergeable (immagini, o file binari). In questi casi la realizzazione contemporanea di modifiche da parte di diversi utenti non è un'opzione accettabile, perciò dobbiamo ricorrere all'aiuto del comando lock. svn lock filename -m "messaggio" Il comando stabilisce che un utente abbia l'esclusiva sulla modifica del file, bloccando tutti gli altri. Subversion non interpreta il lock in maniera particolarmente rigida. Infatti, qualunque utente (non solo l'amministratore) che abbia accesso in modifica al repository può rimuovere i lock altrui, o "rubarli" (si dice "rubare un lock" quando con la medesima operazione si toglie un lock altrui e se ne mette un proprio, senza lasciare un intervallo in cui qualcuno altro possa bloccare il file). L'idea di Subversion è che il blocco sia uno strumento di comunicazione più che di protezione: deve avvisare gli altri utenti che stiamo effettuando modifiche esclusive, ma si suppone che un collaboratore possa avere buoni motivi per rompere il lock e proseguire con le modifiche, e quindi glielo si lascia fare. Tecnicamente non viene effettuata nessuna modifica al file: il lock viene creato come file separato in una apposita cartella del repository, come vedremo più avanti quando ci occuperemo dell'amministrazione del repository. Parliamoci... e usiamo Subversion Il concetto di implementazione dei lock è un esempio abbastanza chiaro dello spirito che ha spinto i progettisti di Subversion a effettuare le proprie scelte. Nella guida ufficiale è espresso chiaramente come Subversion non possa sostituire il dialogo, la corretta pianificazione dei lavori e gli standard di nomenclatura. Ad esempio non può impedire che due programmatori diversi definiscano due funzioni con lo stesso nome in due parti diverse del file, una all'inzio e una alla fine: per il nostro server le modifiche non si sovrappongono e quindi va bene così. Questo però non riduce l'utilità di Subversion. Anzi, il programma riesce in vari modi a migliorare la nostra cooperazione, soprattutto se siamo un team disorganizzato: blocca le sovrapposizioni più evidenti (modifiche diverse alle stesse righe di codice); aiuta a scoprire rapidamente dove sono tali sovrapposizioni e a risolverle; permette facilmente e rapidamente di "fare ordine" in eventuali sovrapposizioni, tornando a versioni precedenti, annullando le modifiche locali, o confrontando 29/5/2009 Pagina 20 di 35

21 I lock e le sovrapposizioni varie revisioni dei file. Quindi, Subversion non sostituisce una efficiente organizzazione interna, ma è uno strumento che ci aiuta a implementarla e mantenerla. 29/5/2009 Pagina 21 di 35

22 I rami (branches) I rami (branches) Nei capitoli precedenti abbiamo esaminato le operazioni più comuni nell'utilizzo di Subversion; queste conoscenze possono bastare per un utilizzo basilare e soddisfare la maggior parte delle esigenze. Ad esempio chi lavora da solo e usa il prodotto solo come archivio e storico delle modifiche, potrebbe anche non aver mai bisogno di utilizzare le funzionalità avanzate di Subversion. Nelle prossime lezioni approfondiremo la gestione di diversi rami di uno stesso progetto, una caratteristica comune a tutti i software di controllo di versione. Un ramo nasce semplicemente come copia del progetto principale; ne condivide la storia fino al momento della separazione, ma procede poi temporaneamente o per sempre, a seconda delle esigenze, su un binario separato. I diversi rami rimangono comunque in qualche modo collegati, infatti è possibile trasportare le modifiche da un ramo all'altro o addirittura fondere completamente due o più rami. I motivi che portano all'uso dei rami sono tipicamente due: 1. La creazione di diverse versioni dello stesso progetto, da mantenere separate. Ad esempio, nel caso di questa guida, potremmo volerne realizzare una versione destinata al sistemista che si occupa di configurare e gestire il server e un'altra destinata al programmatore. Alcune parti saranno in comune; altre sarebbero presenti solo in uno dei due rami; altre ancora sarebbero presenti in entrambi, ma con un contenuto leggermente modificato. In questo caso dovremmo creare due rami separati, destinati a rimanere tali, trasportando dall'uno all'altro le modifiche che riguardano le parti comuni. 2. La creazione di un ambiente di sviluppo temporaneo, destinato prima o poi a essere fuso con il ramo principale. Il caso tipico è lo sviluppo di nuove funzionalità in un programma: visto che di solito questa fase richiede un certo tempo, non si può pensare di lavorare a lungo sulla propria copia locale senza caricare sul server le modifiche, ma d'altro canto non si vogliono mischiare le modifiche in corso con la versione funzionante presente nell'albero principale che deve rimanere disponibile per il debug quotidiano e per generare i rilasci. Si crea quindi un ramo secondario nel quale viene ospitata la versione di sviluppo. Quando questa versione sarà completa, i due rami saranno riuniti in uno solo. Specialmente nel secondo caso, è importante tenere sincronizzati spesso i due rami. Se infatti questo non avviene, i due binari si allontanano sempre di più e quando sarà il momento di unirli avremo un numero ingestibile di conflitti. E oltre ai conflitti veri e propri (intesi come sovrapposizioni delle modifiche) è sempre possibile che ci siano altre modifiche, in punti diversi dei file, che in qualche modo ci coinvolgono e ci costringono ad adattare il nostro codice. In questo caso, il dialogo tra gli sviluppatori è fondamentale. 29/5/2009 Pagina 22 di 35

23 Creazione di un ramo Creazione di un ramo Partiamo innanzitutto con una nota sulla denominazione delle cartelle del nostro progetto. Se prevediamo che il nostro repository possa avere più rami, è bene inserire al primo livello del repository due sottocartelle separate, una che contiene il ramo principale e una che contiene gli altri rami. Per convenzione, la cartella del ramo principale viene chiamata trunk e la cartella dedicata ai rami viene tipicamente chiamata branches. Si tratta solo di convenzioni, dunque possiamo sostituire i nomi a nostro piacimento, ma rispettare degli standard di nomenclatura usati in tutto il mondo non è una cattiva idea. La struttura ideale per il nostro repository diventa dunque: repos/guidasvn/trunk che contiene la versione originale della mia guida; repos/guidasvn/branches/sistemisti che contiene la versione per sistemisti; repos/guidasvn/branches/programmatori che contiene la versione per programmatori) Per creare un ramo separato, va usato il comando svn copy: svn copy URL1 URL2 -m "Messaggio" che nel nostro caso si declina: svn copy -m "Creazione ramo separato sistemisti" Va a questo punto chiarito un concetto importante. Per Subversion non esiste realmente il concetto di rami separati: se creiamo una copia di una cartella, per lui è semplicemente questo: la copia di una cartella. Siamo noi che, potendo fare checkout, update e commit di singole cartelle del repository, lo consideriamo un ramo separato e lavoriamo solo su quello. Ecco perchè è importante separare le cartelle e dargli una nomenclatura esplicativa: perchè ci serve per assegnare il concetto di "ramo" a quelle che per Subversion sono semplicemente cartelle diverse di uno stesso progetto, che come tutti gli elementi copiati condividono lo storico fino al momento della copia. Trattandosi sempre di uno stesso repository, inoltre, la numerazione delle revisioni rimane comune tra i rami: ad esempio se effettuiamo un commit sul ramo principale e generiamo la revisione 10, il commit successivo sul ramo secondario produrrà la revisione 11. Spostare un repository già creato Se abbiamo già messo del contenuto nel repository e vogliamo spostarlo per creare la 29/5/2009 Pagina 23 di 35

24 Creazione di un ramo struttura adeguata ad ospitare rami separati, possiamo utilizzare il comando svn move: svn move URL1 URL2 Questa operazione non richiede particolare attenzione per essere effettuata, ma è fondamentale che tutti gli utenti ne siano informati. La copia di lavoro locale infatti non può sapere di questo spostamento e quindi va aggiornata utilizzando il comando relocate che ci permette di specificare il nuovo URL. In alternativa, si può semplicemente eliminare e ricreare la copia di lavoro. 29/5/2009 Pagina 24 di 35

25 Unire i cambiamenti Unire i cambiamenti Ci sono diversi momenti in cui risulta necessario unire i cambiamenti tra diversi rami. Come abbiamo già detto, è bene mantenerli sincronizzati di tanto in tanto, per evitare di far crescere a dismisura il numero di conflitti. Inoltre, se si tratta dell'implementazione di nuove caratteristiche, prima o poi dovranno essere fuse con il ramo principale. Il trasporto delle modifiche tra rami viene effettuato con il comando svn merge. Nota: dalla versione 1.5 di SubVersion la gestione del trasporto delle modifiche tra i rami è stata notevolmente migliorata, e sulla guida ufficiale si raccomanda caldamente di aggiornare a questa versione: altrimenti tali operazioni di sincronizzazione diventano decisamente più complicate. Merge basilare La situazione più frequente è quella in cui l'utente che sta lavorando sul ramo secondario vuole trasportare sulla propria copia di lavoro le modifiche effettuare sul ramo principale, per affrontare e risolvere per tempo non solo i conflitti cioè le vere e proprie sovrapposizioni di modifiche ma anche altri cambiamenti che potrebbero richiedere adattamenti del proprio codice. Il comando: svn merge svn://svn.vd-devel/guidasvn/trunk esegue esattamente questo: verifica che l'url che stiamo chiedendo NON sia quello da cui abbiamo fatto il checkout ma ne è una copia; risale quindi all'ultima revisione in comune tra le due copie; rileva i cambiamenti effettuati a partire da quella revisione e li applica alla nostra copia locale, segnalandoci eventuali conflitti. Il comando merge è piuttosto potente. Tutto quello che dobbiamo fare noi è assicurarci, prima di eseguirlo, che tutti i cambiamenti locali sulla nostra copia di lavoro siano stati caricati con un commit sul ramo corrispondente (cioè il ramo secondario) e dopo l'esecuzione, esaminare con calma le modifiche apportate (col comando svn diff). Attenzione, però: per adesso l'unione delle modifiche è limitato alla copia di lavoro locale: quando avremo risolto i conflitti e verificate tutte le modifiche, dovremo effettuare il commit dei cambiamenti per sincronizzare definitivamente i due rami. Merge successivi L'operazione di sincronizzazione sopra descritta non avviene una volta sola: se il lavoro sul ramo secondario dura molto, sarà utile ripeterla frequentemente. Prima della versione 1.5, era necessario ricordarsi (magari spulciando i log) la revisione fino alla 29/5/2009 Pagina 25 di 35

26 Unire i cambiamenti quale ci si era già sincronizzati, e specificarla come parametro per indicare al comando merge da quale revisione cominciare a reperire i cambiamenti. Nelle ultime versioni di SubVersion invece le informazioni di merge vengono salvate come proprietà dei rami, in particolare, viene mantenuta l'ultima revisione a cui ci si è sincronizzati. Ricordiamo che per Subversion i rami sono normali cartelle, quindi possono avere associate delle proprietà (dette anche metadati). Il comando merge sfrutta questa possibilità per salvare una proprietà mergeinfo che verrà esaminata nei successivi merge, per evitare di riportare più volte gli stessi cambiamenti. Quindi invocando in seguito lo stesso comando usato per la prima sincronizzazione verranno uniti solo i cambiamenti successivi. Fusione tra due rami Uno dei due motivi principali e probabilmente il più frequente per creare rami separati è quello di avere un ambiente di sviluppo isolato temporaneo per realizzare una serie di importanti modifiche, come l'aggiunta di nuove funzionalità, che andranno poi unite al ramo principale. Supponiamo di aver fatto le cose per bene, e esserci tenuti frequentemente sincronizzati con il ramo principale per avere a disposizione le modifiche fatte da altri. Quello che ci rimane da fare ora è l'opposto: riportare le nostre modifiche. Il primo consiglio è quello di chiedere a tutti i collaboratori di sospendere temporaneamente i commit sul repository. Infatti, le prime volte che fonderemo diversi rami potremmo metterci un po', e per essere certi di fare tutto bene, è meglio evitare sovrapposizioni con altre modifiche su uno qualsiasi dei due rami. In ogni caso non rischiamo mai di perdere del lavoro. A Subversion non sfugge nulla. Tuttavia, se qualcuno carica una modifica durante il processo di fusione, e non ne siamo al corrente, potremmo trovare qualcosa che non torna e pensare di avere sbagliato qualcosa. Con l'aquisizione di maggior confidenza con Subversione con la gestione dei branch, fare molte cose contemporaneamente non sarà più un problema. La procedura consigliata è la seguente. Innanzitutto assicuriamoci di fare un'ultima sincronizzazione dal ramo principale verso il secondario, come spiegato nella lezione precedente. Riepiloghiamo i passaggi: 1. commit della copia di lavoro verso il ramo secondario, 2. merge del ramo principale sulla copia di lavoro, 3. risoluzione di conflitti e altre anomalie, 4. commit della copia di lavoro verso il ramo secondario. A questo punto scarichiamo altrove una nuova copia di lavoro del ramo principale. Non è obbligatorio crearla da zero con un checkout; se abbiamo a disposizione una copia di lavoro del ramo principale, è sufficiente aggiornarla con un update. Facciamo attenzione però a non mischiare la copia di lavoro del ramo secondario con quella del ramo principale. 29/5/2009 Pagina 26 di 35

27 Unire i cambiamenti A questa copia di lavoro (quella del ramo principale) applichiamo ora le modifiche effettuate al ramo secondario, sempre con il comando merge: svn merge --reintegrate URL_ramo_secondario Una volta risolti eventuali conflitti, avremo una copia di lavoro che include l'unione di entrambi i rami. A questo punto, è sufficiente effettuare un commit di questa copia di lavoro per avere sul ramo principale il risultato della fusione dei due rami. Di fatto, stiamo facendo in modo che i rami siano di nuovo uguali; ma con la la storia di tutte le modifiche salvata nelle varie revisioni e quindi facilmente recuperabile. Dopo un reintegrate, il ramo secondario è "secco". Non può più tenere traccia correttamente delle modifiche, per cui non ci si può lavorare. Dovete cancellarlo. Fortunatamente per Subversion il "ramo" altro non è che una cartella del progetto. Per cui: 1. è possibile cancellarlo semplicemente rimuovendo la cartella corrispondente. Andiamo sul server ed eseguiamo il comando svn delete URL_ramo_secondario; 2. lo storico rimane comunque, per cui possiamo sempre tornare a una certa revisione del vostro ramo secondario semplicemente recuperando la cartella associata da una delle revisioni in cui tale cartella ancora esisteva. Le etichette (tags) Nelle prime lezioni abbiamo scelto di tradurre in "etichetta", il termine originale "tag". Questo termine risulta comunque talmente diffuso da essere diventato internazionale. Si parla di tag riferendosi all'etichetta che si può associare a una revisione del nostro progetto che possiede un significato particolare, ad esempio la prima revisione rilasciata come "alpha". Certo, potremmo semplicemente annotare il numero della revisione, e visto che in Subversion tale revisione rimane sempre disponibile consultarla usando quel numero. Tuttavia si preferisce identificare in maniera più chiara e mnemonica la revisione, associando un nome autoesplicativo. Come altri concetti, anche questo non è una caratteristica esclusiva di Subversion, ma si applica a tutti i sistemi di controllo di versione. Subversion risolve la questione dei tag in maniera molto semplice, allo stesso modo dei rami: con una copia. Se infatti nella cartella principale del nostro repository, oltre alle cartelle trunk e branches creiamo anche una cartella tags, ecco che la procedura per creare un tag diventa uguale a quella per creare un ramo: svn copy -m "creazione versione alpha-1" 29/5/2009 Pagina 27 di 35

28 Unire i cambiamenti Questa comodità diventa ancora più sensata nel caso in cui si desideri etichettare non l'intero repository, ma una specifica sottocartella: copiandola altrove ci risulta più facile identificarla. Per far sì che questa cartella non sia più modificata in futuro, può essere utile attivare un sistema di controllo degli accessi sul repository (che vedremo più avanti). Comunque non c'è da preoccuparsi, se anche qualcuno dovesse accidentalmente o volontariamente modificare una revisione tag, possiamo annullare i cambiamenti e tornare alla revisione originale. Altri utilizzi delle revisioni tag Il comando copy permette di duplicare non solo le cartelle del repository, ma anche la copia di lavoro locale. Questo è chiaramente diverso da un commit (che unisce tutte le modifiche locali al repository) o da un export (un comando aggiuntivo che crea una copia di soli file, quindi priva di informazioni di versione): con tale comando vado a creare una copia esatta del contenuto della mia copia di lavoro, qualunque esso sia. La copia di lavoro locale offre molta flessibilità, e gli utenti avanzati di Subversion la sfruttano. Sulla copia locale possono essere presenti file e modifiche provenienti da diverse revisioni e da diversi repository, nonché modifiche locali. La nostra copia di lavoro può diventare un miscuglio difficile da ricreare, ma perfettamente funzionante, e potremmo anche essere interessati a fissare nel tempo questo preciso stato di cose utilizzando un tag. svn copy percorso_della_copia_locale URL_repository/tags/tag_personale Come per i rami, la cancellazione di un tag consiste semplicemente nella cancellazione della cartella associata. 29/5/2009 Pagina 28 di 35

29 La struttura del repository La struttura del repository Nelle prossime lezioni affrontiamo alcuni argomenti che possono interessare principalmente gli amministratori del server Subversion. Gli utenti finali (programmatori e autori) che usano semplicemente il client per scaricare e caricare modifiche sui progetti non hanno infatti bisogno di acquisire tali competenze, se non per propria curiosità. La struttura interna Vista dall'esterno - ad esempio navigandolo con il browser - la struttura del repository sembra corrispondere a quella che noi abbiamo creato per i dati contenuti. Se però andiamo a navigare il filesystem sul server e apriamo la cartella che ospita il repository, troveremo delle cartelle a noi sconosciute. Tali cartelle sono comuni a qualunque repository, e il significato di ciascuna è spiegato di seguito: conf contiene i file di configurazione del repository dav contiene i file di lavoro del modulo mod_dav_svn db contiene il vero e proprio archivio dei nostri dati hooks contiene gli script di "hook", che affronteremo nella prossima lezione locks contiene gli eventuali file di lock esistenti In aggiunta alle cartelle, sono presenti anche un file format che indica la versione del layout del repository (non c'entra nulla con le nostre revisioni, è ad uso del server Subversion), e un file README.txt il cui ruolo è abbastanza ovvio. Possiamo pensare a questa struttura di cartelle come a un vero e proprio filesystem separato, con le proprie regole e il proprio modo di organizzare i contenuti, che si colloca a un livello superiore rispetto al filesystem di base. La struttura esterna Una delle prime scelte da fare quando si crea un server Subversion e tra l'utilizzo di un unico repository per tutti i progetto, oppure la creazione di un repository per ogni progetto L'utilizzo di un unico repository può ridurre la manutenzione, ma pone dei limiti in termini di flessibilità: diversi progetti potrebbero avere esigenze diverse a livello di accesso e/o di script di automazione. Inoltre, il numero di revisione rimarrebbe comune tra diversi progetti, e questo potrebbe creare confusione. Il consiglio è senz'altro quello di creare repository diversi per progetti che non hanno nulla a che spartire. Conviene invece mantenere nello stesso repository, magari usando rami diversi, quei progetti che sono in qualche modo correlati, in modo da facilitare l'eventuale scambio di modifiche. Nelle lezioni precedenti abbiamo visto come sia consigliato creare le cartelle trunk, branches e tags nella cartella principale del progetto. Nel caso si scelga di mantenere un progetto in ogni repository, la cartella principale del progetto corrisponde alla cartella 29/5/2009 Pagina 29 di 35

30 La struttura del repository principale del repository: / trunk/ branches/ tags/ Nel caso di più progetti uniti nello stesso repository, dovremo invece creare prima le cartelle corrispondenti ai vari progetti, e poi le cartelle in questione: / guidasvn/ trunk/ branches/ tags/ guidahtml/ trunk/ branches/ tags/ Nulla ci vieta inoltre di creare ulteriori livelli per raggruppare meglio i nostri progetti: / guide/ guidasvn/ trunk/ branches/ tags/ guidahtml/ trunk/ branches/ tags/ / programmi/ mybackup/ trunk/ branches/ tags/ myeditor/ trunk/ branches/ tags/ 29/5/2009 Pagina 30 di 35

31 Gli script di hook Gli script di hook Per semplificare la gestione del repository e automatizzare alcune procedure, Subversion ci consente di creare degli script che vengano automaticamente invocati in corrispondenza di determinati eventi. In altre parole, ogni volta che viene effettuata una certa operazione sul repository, Subversion controlla se nella cartella hooks del repository sia presente un file eseguibile con un certo nome, e lo esegue. Tipicamente uno script esegue operazioni di validazione o notifica. Quindi si può fare in modo, ad esempio, che ogni commit sia segnalato via a un indirizzo specifico; oppure fare in modo che una modifica venga esaminata prima del caricamento, e rifiutata se non soddisfa certi criteri. Un altro esempio è quello di bloccare i commit sulle revisioni tag. I nomi degli script che vengono cercati corrispondono abbastanza chiaramente agli eventi a cui sono associati. Elenco degli eventi pre-commit pre-lock pre-revprop-change pre-unlock post-commit post-lock post-unlock post-revprop-change start-commit Una rapida spiegazione degli eventi elencati. Conosciamo già il commit; lock e unlock si riferiscono all'applicazione e rimozione di un lock su un file, che è possibile tramite l'omonimo comando; revprop-change si riferisce alla richiesta di modifica di una proprietà del repository. Per tutte le operazioni, esiste lo script "pre-", che viene eseguito prima e può interrompere l'esecuzione se ritorna un codice diverso da zero, e lo script "post-" che viene eseguito dopo e ovviamente non può interrompere niente, visto che l'operazione è già stata eseguita Unica eccezione è lo start-commit, che viene eseguito nel momento in cui il client rivolge al server la richiesta di creazione di una transazione, quindi prima ancora che tale transazione sia pronta per essere applicata al repository - e quindi prima ancora del pre-commit. Nella cartella hooks di qualunque repository appena installato sono presenti degli script shell di esempio nominati come sopra, ma con estensione.tmpl. Questi script di esempio contengono in forma di commento le spiegazioni necessarie per l'utilizzo e i parametri che gli vengono passati, nonchè esempi delle operazioni più frequenti. È chiaro quindi che il modo più immediato per cominciare a usare gli hook è quello di 29/5/2009 Pagina 31 di 35