Subversion. Giovanni Lagorio

Transcript

1 Subversion Giovanni Lagorio

2 Licenza Questi lucidi sono rilasciati sotto la licenza Creative Commons Attribuzione-Non commerciale-non opere derivate 3.0 Unported. Per leggere una copia della licenza visita il sito web o spedisci una lettera a Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. In due parole, possono essere liberamente usati, copiati e distribuiti purché: 1. Venga citata la fonte originale 2. Non vengano usati in ambito commerciale 3. Non vengano modificati in nessun modo

3 Version Control System Sistemi che mantengono la versione corrente e tutta la storia di sorgenti, pagine web, documentazione, (Quelli non preistorici) Permettono modifiche in parallelo senza locking In un certo senso, sono macchine del tempo (che potete usare solo all indietro ) È impensabile scrivere del software più grande di Ciao mondo, senza un VCS

4 Motivazioni Lavorare sul desktop, sul notebook, a volte sul netbook... e sincronizzare tutto in automatico...anche le modifiche dei vostri colleghi, che hanno lavorato allo stesso modo...ma solo le parti che volete! Chi lascia ad altri dei sorgenti che non compilano, andrebbe crocefisso in sala mensa! Non impazzire quando arriva un bug report per la versione e state lavorando sulla BTW, se il bug si manifesta sulla non più supportata e non sulla lo considerate risolto?

5 Nooooooooooooooo! Recuperate la versione incriminata (grazie al VCS) Scrivete uno unit-test che mostra il problema Trovate la causa (Se la 1.x è ancora supportata, risolvete il problema) Se la causa è ancora presente nella versione attuale: Scrivete uno unit-test che mostra il problema (che c era ancora, ma si era nascosto meglio) Mettete a posto il problema Salvate le modifiche sul VCS

6 Subversion Sistema di controllo delle versioni: tiene traccia della storia di file e directory (e di chi ha modificato cosa) all interno di un repository nasce nel 2000, come successore di CVS non vuole essere compatibile, ma simile per l utente open source e multipiattaforma gestisce qualsiasi tipo di file (ASCII e binari) Salvo pochissime eccezioni, è sensato solo su ASCII. Noi lo useremo per sorgenti e file di configurazione

7 Caratteristiche generali Gratis e ben documentato: svnbook.red-bean.com Ben supportato: esistono plugin per VS, Eclipse, ecc. Permette di lavorare concorrentemente Per ogni singola linea di codice è facile sapere quando è stato modificata, e da chi E facile ottenere uno snapshot (fotografia) di file e directory a un certo istante Per esempio, sapere com era Pippo.cs il 24/06/2008 alle 14.15? com era il progetto del gruppo 3 il giorno della consegna? (eh già, useremo subversion! )

8 Svantaggi/Cose da sapere By design, tutto quello che inserite in un repository Subversion è per sempre sebbene Subversion memorizzi solo i delta da una versione all altra, tutto ciò che si inserisce occupa spazio su disco (del server e sui suoi backup) NON viene eliminato cancellando i file coinvolti Ricordate il: com era Pippo.cs il 24/06/2008 alle 14.15? Morale: non inserite binari e/o file che possono essere rigenerati automaticamente Alcune operazioni richiedono di essere online

9 Se non si fosse capito... Lo spazio condiviso sul repository di TAP non deve essere usato per condividere: Warez, DivX, MP3, JPG, crack, keygen,... È illegale La ISO dell ultima ISO di Ubuntu È inefficiente (e fa esplodere le richieste di spazio sul server) Ogni abuso sarà severamente punito No, non riuscirete a cancellare le prove (se siete così bravi da riuscirci, per favore bucate un altro server fin dall inizio... )

10 Client grafico sì o no? Vediamo principalmente la versione a riga di comando perché è la più generale e utile in casi di emergenza Normalmente, si fa tutto da VS usando AnkhSVN: Per Windows un ottimo client grafico è TortoiseSVN, che si integra in explorer: In lab non è installato perché la 1.5 dava grossi problemi su alcune macchine (la 1.6 sembra ok)

11 File Server Per certi versi, un repository subversion è un file server (che si ricorda tutte le modifiche) Più client possono vedere e modificare una stessa versione Necessità di gestire modifiche simultanee (una modifica non deve sovrascriverne un altra) Se possibile, senza usare dei lock

12 Modello copy-modify-merge Ciascun utente: ottiene una working copy del repository facendone il checkout (comando: svn checkout...) lavora in locale il fatto che i file appartengano a un repository è irrilevante in questa fase può aggiornare la propria copia locale facendo un update (svn update...) può rendere definitive le proprie modifiche facendone il commit (svn commit...)

13 Modello copy-modify-merge

14 Merge Le fasi di merge sono eseguite esplicitamente da un utente, ma il merge è automatico Si assume che abbia senso! Per subversion sono semplicemente file di testo... Dove il merge non ha senso, si possono usare i lock Nota: se le modifiche avvengono su dei file binari, queste vanno sempre in conflitto In caso di conflitto (modifiche su una stessa porzione di file) sarà l utente a dover risolvere la situazione I conflitti sono estremamente rari e al 90% dovuti a problemi di comunicazione fra le persone

15 Come si identificano i repository? I repository vengono identificati da URL Attenzione a spazi ecc. (diventano %20 nell URL e il tutto va fra doppi apici nella shell); per esempio: svn checkout "file:///x /var/svn/repos%20subv" E possibile vedere, senza modificare, la versione più recente di un repository tramite qualsiasi webbrowser (quando il protocollo usato è HTTP/HTTPS) Il nostro repository è:

16 Parentesi sul nostro server Ogni gruppo avrà accesso a una sua directory, per esempio: Il certificato SSL è fatto in casa, quindi non viene riconosciuto automaticamente dai client subversion e dai web-browser La cosa più semplice è accettarlo permanentemente quando vi viene chiesto Per esempio, in AnhkSVN...

17 Scegliete Save certificate e poi premete Accept Connessione a Bart

18 Login Una volta accettato il certificato SSL, vi verranno chiesti username e pw Per comodità, salvate la password ( Remember my password ) Per cambiare la pw: change_subversion_password.php

19 Working Copy Si ottiene facendo il checkout (svn checkout... oppure svn co...) E una copia di (un sottoalbero) del file-system contenuto nel repository Un tipico repository viene suddiviso in tante directory, una per (i sorgenti di) ogni progetto/prodotto ospitato E una directory normalissima, l unica particolarità è una subdirectory.svn, detta administrative directory, gestita da Subversion svn export permette di copiare il contenuto senza.svn

20 Checkout $ svn checkout A calc/makefile A calc/integer.c A calc/button.c Checked out revision 56. $ ls -a calc Makefile button.c integer.c.svn/

21 Commit Dopo aver modificato, per esempio, button.c, possiamo rendere permanenti i cambiamenti con: $ svn commit button.c -m "Fixed a typo in button.c." Sending button.c Transmitting file data. Committed revision 57. $ Ogni commit è una transazione atomica

22 Descrizione nel Commit Al momento del commit, subversion chiederà di inserire una descrizione delle modifiche (si può passare via linea di comando con m... ) Questa descrizione può essere visualizzata quando si guarda la storia di un file o di una directory con il comando svn log, che elenca anche gli autori e le date delle modifiche In Ankh: View History dal menù contestuale

23 Update Chiunque faccia checkout vedrà l ultima versione dei file, chi aveva già fatto checkout può sincronizzare la working copy usando update: $ svn update U button.c Updated to revision 57. $

24 Revisioni Il numero di revisione è globale al repository e ogni commit lo incrementa Corrisponde alla versione di tutto il repository Quindi, non è detto che un certo file sia diverso da una revisione all altra

25 Come vengono tracciate le modifiche? Per ogni file subversion memorizza (in.snv): La working revision, ovvero la revisione su cui si basa la copia locale Un timestamp di quando è avvenuto l ultimo update Con queste informazioni, dialogando col server, può determinare lo stato del file, che può essere: unchanged/changed rispetto alla working revision current/out-of-date rispetto a quella sul repository (la HEAD revision)

26 Stato (svn status) dei file Unchanged and current, commit/update non avrebbero nessun effetto Locally changed and current, commit avrebbe successo e update non farebbe nulla Unchanged and out-of-date, commit non farebbe nulla, update lo aggiornerebbe Locally changed and out-of-date, commit fallirebbe con un errore out-of-date, mentre update cercherebbe di fare il merge

27 Revisioni miste Un commit non provoca update e viceversa Un utente può voler mandare le proprie modifiche senza necessariamente vedere le altre o, viceversa, può voler sincronizzare la propria copia locale senza mandare le proprie modifiche al server Ogni file nella working copy può avere una revisione diversa poiché: Ogni commit cambia la revisione dei file in questione (ma non degli altri!) Si può fare commit solo di file aggiornati (per es., non avrebbe senso cancellare un file senza averne visto le modifiche...)

28 Come si aggiungono file/dir? svn add permette di aggiungere file o directory (in realtà, di schedulare l aggiunta, le modifiche averranno al commit) Usando Ankh: automatico (creando i file da VS) svn import permette di importare una dir e le sue subdir all interno di un repository la directory in questione NON diventa una working copy (si deve comunque fare checkout) corrisponde ad add + commit (consigliati)

29 Due tipi di modifiche Del contenuto dei file; vengono gestite in automatico da subversion. Possiamo modificare i file come vogliamo, al momento di update/commit subversion farà un diff Strutturali : aggiunta/spostamento di file o directory. Dobbiamo usare i comandi di subversion per eseguirle In locale molte vengono eseguite subito, ma fino al commit il repository non viene modificato Eccezione: questo è vero lavorando su working copy, molti comandi possono lavorare direttamente con degli URL

30 Modifiche strutturali All interno della working copy si: copiano file con svn copy / cp spostano/rinominano file con svn move / mv / rename / ren cancellano file con svn remove / rm / delete / del si creano directory con svn mkdir Usando Ankh: come per add, tutto in automatico se l azione viene fatta da VS

31 Tipica sessione di lavoro: si... Aggiorna la copia locale: update Lavora in locale via editor/ide/altro... Controllano le differenze: svn status/svn diff In Ankh vedere la finestra Pending changes e il menù contestuale Show Changes Se si hanno dei ripensamenti, undo : svn revert Fa il merge, ed eventualmente, la risoluzione dei conflitti: svn update, svn resolve Rendono permanenti le modifiche: svn commit

32 Tipica sessione di lavoro: si... Aggiorna la copia locale: update Lavora in locale via editor/ide/altro... Controllano le differenze: svn status/svn diff In Ankh vedere la finestra Pending changes e il menù contestuale Show Changes Se si hanno dei ripensamenti, undo : svn revert Fa il merge, ed eventualmente, la risoluzione dei conflitti: svn update, svn resolve Queste operazioni non richiedono l accesso al server! (grazie a.svn) Rendono permanenti le modifiche: svn commit

33 In Ankh... update O dalla finestra Pending changes

34 Status/Diff Lo stato viene mostrato sotto forma di icona nel solution explorer Pending changes mostra tutti i cambiamenti schedulati e permette di fare commit/update

35 Revert/Commit Sono nel menù contestuale, sia nel solution explorer, sia nella finestra Pending changes

36 In caso di conflitti? I conflitti vengono marcati nel file e, inoltre, vengono creati tre file non versionati: <filename>.mine, l ultima versione locale, senza i marker del conflitto <filename>.r<oldrev>, l ultima versione scaricata in locale prima del conflitto <filename>.r<newrev>, la versione scaricata dal server (Ragionevolmente) Subversion non permette il commit finché il conflitto non viene risolto

37 Come si risolvono? A seconda del client, si può scegliere di: ignorare momentaneamente il problema (postpone) e poi risolverlo con svn resolve usare la propria versione usare la versione del repository andare in edit e risolvere a mano vedere le differenze e scegliere come risolvere fare un revert

38 In Anhk... L icona! indica un conflitto Installando tool come DiffMerge o WinMerge è possibile andare in edit

39 DiffMerge Strumento free per diff/merge (ma va? ) Per configurare AnhkSVN, da VS: Tools Options Source Control Subversion User tools External Diff Tool:...\DiffMerge.exe "%base" "%mine" /t1="base version" /t2="my version" External Merge Tool:...\DiffMerge.exe "%mine" "%base" "%theirs" /r="%merged" /t1="my version" /t2="result" /t3="their version"

40

41 Metadati Esiste la possibilità di associare meta-dati (versionati) ai file, sotto forma di property Ogni property è una coppia nome/valore I nomi che iniziano con svn: sono riservati. Per esempio, svn:ignore su una directory indica a svn status (e altri comandi) quali pattern ignorare In TAP non useremo (direttamente) questa caratteristica

42 praise/blame/annotate Tre sinonimi per uno stesso comando, che permette di vedere, linea per linea di un file, chi ha fatto l ultima modifica e quando Da Anhk:

43 Revisioni Oltre al numero che viene incrementato a ogni commit, ci sono modi più user-friendly per identificare le revisioni: HEAD, la versione più aggiornata sul repository BASE, la versione nella working copy (la versione senza eventuali modifiche locali) COMMITTED, la versione più recente in cui il file è cambiato PREV = COMMITTED-1 Date/ore fra graffe; per esempio: { }, {15:30}, {" :30"},...

44 Revisioni (cont) Alcuni comandi (per esempio, update) possono agire su una revisione qualsiasi, usando lo switch -r Quando non si specifica nulla, la revisione è HEAD Per esempio, svn up -r {16:30} fa l aggiornamento alla versione delle 16:30 Ma il commit si può fare solo con file che hanno revision HEAD, non potete fare un commit subito dopo per fare l undo (ne riparliamo dopo)

45 Coppie di versioni Altri comandi, per esempio, svn diff lavorano su coppie di versioni, espresse con <r1>:<r2> Per esempio, svn diff -r 10:20 Program.cs visualizza le differenze fra la revision 10 e la 20

46 Branching I branch (rami) sono versioni parallele di file o directory con una storia comune Per Subversion non sono altro che normalissime copie, create con svn copy Copiare i file in subversion è quasi gratis: non vengono duplicati i dati (sul server)

47 Struttura del repository Subversion non impone nessuna struttura Convenzionalmente si usa una directory per progetto/prodotto, con tre subdir: trunk, il ramo principale branches, altri rami, per sviluppo in parallelo tags, versioni particolari, taggate con un nome significativo Sono, comunque, directory normalissime che possono essere rinominate/spostate in ogni momento senza problemi (a parte la confusione per gli utenti)

48 Esempio Inserire i branch dentro a branches è solo una convenzione

49 PER CHI PUNTA ALLA LODE

50 Switching Il comando switch permette di saltare su un altro branch Equivale, ma è più efficiente, di svuotare la cartella corrente e fare un checkout del branch Switch fa un diff dell albero corrente e quello su cui si vuole switchare Il comando update è un caso particolare di switch, dove il path dei due alberi coincide (e cambiano solo le revision)

51 Consigli... Fare branch/switch di intere solution In teoria si potrebbero switchare singole directory, in pratica diventa ingestibile

52 Changeset Un changeset è un insieme di modifiche (ai dati e/o strutturali) Le revisioni (e le coppie di revisioni) identificano dei changeset; possiamo pensare alla r5411 come il delta di cambiamenti che ha portato dalla versione 5410 alla 5411 Nel comando merge, lo switch -c N equivale a -r N-1:N (o N:N-1, quando N è negativo)

53 Merging Con svn merge, su una working copy senza modifiche locali (verificarlo con svn status), è possibile unire una o più modifiche al proprio branch Per esempio, svn merge ^/trunk incorpora tutte le modifiche avvenute sul ramo principale (convenzionalmente, trunk) Chiaramente, subversion ricorda quelle già applicate La notazione ^/ è disponibile dall 1.6 e indica la root del repository Si noti che, come con update, si possono avere dei conflitti Tipicamente, conviene sincronizzare spesso il proprio branch con quello principale

54 Integrare le proprie modifiche su trunk Spesso, una volta finito lo sviluppo di un estensione, la si vuole unire al ramo principale (e poi cancellare il branch) Per l utente il procedimento è quasi uguale, in una versione aggiornata del trunk si esegue: svn merge --reintegrate ^/branches/my-... Per subversion è più complicato: non può applicare l intera sequenza di changeset, come prima, ma deve applicare quelli specifici del branch

55 In Subversion 1.5: Dopo --reintegrate Il branch diventa inusabile (non può ricevere changeset dal trunk e non può più essere reintegrato) Se si vuole continuare a sviluppare sul branch bisogna buttarlo via (delete) e farne una nuova copia (copy) Con l 1.6 sembra funzionare, ma la documentazione non è chiara (dice solo cosa succede con l 1.5)

56 In Ankh...

57 Undo Il meccanismo del merging può essere usato a rovescia per fare l undo di un changeset Per esempio, svn merge -c -303 ^/trunk elimina le modifiche fatte dal changeset 303 Come tutte le operazioni, non elimina davvero quel changeset, ma ne elimina gli effetti sulla working copy (e quindi su HEAD, dopo un commit) Ankh lo chiama Revert... (selezionando una revisione dall History Viewer)

58 Resuscitare file Si potrebbero recuperare dei file usando il merge a rovescia, ma non sarebbe facile (i changeset tipicamente contengono diverse modifiche) Il modo più semplice è usare copy, sfruttando l idea che un file in subversion è unicamente determinato da: Path (in quella revisione) Numero di revisione, specificata dopo Per esempio, svn copy ^/trunk/risposta.c@42./risposta.c

59 Resuscitare file (cont.) Usando questa tecnica il nuovo file mantiene l history (ovvero, con svn log si vede tutta la storia) Se vogliamo recuperare un file cancellato ma non mantenerne la storia, possiamo recuperare i dati con svn cat (sempre sfruttando la notazione path@revision) e poi add/commit

60 Tags Un tag è semplicemente una fotografia del repository in un dato momento Di fatto, ogni commit crea una revisione che non è altro che una fotografia di tutto il repository in quel dato momento. I numeri di revisione non sono userfriendly e può far comodo chiamare release 1.0 la r83612 In Subversion una revision taggata non è altro che una copia che si ottiene con svn copy