Tool di sviluppo Source control system

1. DotNetMarche.Start () Tool di sviluppoSource control system Ricci Gian Maria ricci.gm@nablasoft.com 1° Workshop “DotNetMarche.Start ()” Giovedì 12 ottobre 2006

2. Cosa fa un source control system • Centralizza la memorizzazione di files • Permette a più utenti di lavorare contemporaneamente sugli stessi files • Gestisce il versioning dei file • Costituisce un backup condiviso del progetto Working copy (client 1) Working copy (client 2) Repository Working copy (client 3)

3. A chi è diretto un SCS • Team di sviluppo • Permette a più persone di lavorare sugli stessi files • Gestisce la concorrenza delle modifiche • Centralizza la posizione di tutti i file di un progetto • Singoli sviluppatori • Mantiene lo storico di tutte le versioni • Permette di creare snapshot di particolari momenti di vita di un progetto (Es: Beta, Release) • Gestisce deviazioni dal processo principale (branching) • È un implicito backup di un progetto. • Ogni sviluppatore dovrebbe utilizzare un Source control system per i propri progetti

4. V3 V3 V2 V3 V4 V4 Gestire la concorrenza con Lock Luigi Update/Lock Commit Repository Mario • Punti di forza • Evita completamente ogni conflitto di versione • Permette di conoscere chi sta lavorando ai vari file • Punti deboli • Riduce la concorrenza possibile • Richiede più attenzione per non dimenticare lock attivi

5. V4a V4a V4b V3 V3 V4a V5 V5 V5 V2 V3 V3 V3 Gestire la concorrenza senza lock Luigi Resolve Conflict Commit Update Repository Mario • Punti di forza • Minimizza la serializzazione delle modifiche • Evita la presenza di lock dimenticati • Forza un aumento della comunicazione • Punti deboli • In caso di conflitto è necessario un intervento manuale • Può creare problemi su tipi di file non “fondibili”

6. Pregi e difetti di Source Safe • Pregi • Elevata integrazione con il Visual Studio • Difetti • Scarse prestazioni in ambienti internet • Possibilità di corruzione repository per operazioni interrotte • È un prodotto a pagamento • Difficoltà di uso in ambiente internet • Bassa scalabilità per numero di utenti • Richiede un accesso costante al repository

7. Pregi e difetti di Subversion • Pregi • Prodotto gratuito • Prodotto in continua evoluzione • Elevate prestazioni anche in ambienti internet • Alta scalabilità • Buona integrazione con la shell (tortoise) • Non richiede un accesso costante al repository • Commit transazionali, il database non si corrompe per connessioni interrotte • Difetti • Scarsa o nulla integrazione con il Visual Studio

8. Source safe • Istallazione • Basta eseguire il setup e rispondere alle domande di rito • Gestione (programmi istallati) • Admin: Permette di creare repository nel file system e definire le credenziali di accesso ai vari repository creati • SourceSafe (browser): Permette di vedere il contenuto di un repository e di eseguire le varie operazioni di checkout/checkin, etc… • Analizzatori: Controllano lo stato del db per verificare e/o correggere errori • Solitamente è sufficiente lavorare all’interno del Visual Studio e lasciare che il plugin svolga il lavoro dietro le quinte in modo quasi trasparente.

9. Source safe – integrazione VS

10. Source safe – integrazione VS

11. Source safe – Console

12. Lavorare disconnessi in source safe È possibile lavorare disconnessi in Source Safe semplicemente togliendo l’attributo readonly ai file che si vogliono modificare. Al successivo GetLatest il Source Safe chiede per ogni file se si vuole scartare le modifiche oppure se si vuole fare un chekout del file nel repository per poi aggiornarlo con le proprie modifiche • Pro • Non è necessario avere una connessione continua al database aumentando la scalabilità • Contro • È possibile sovrascrivere le modifiche fatte da altri utenti durante il lavoro disconnesso a meno che non venga esplicitamente fatto il checkout prima di disconnettersi

13. Istallare Subversion • Subversion • Scaricare ed installare l’ultima versione • Scegliere una cartella del proprio server dove tenere i repository • Creare un repository con l’istruzione svnadmin create d:\svnrep\Test • Istallare il servizio con sc create svnserver binpath= “c:\..\bin\svnserve.exe --service --root d:\svnrep" displayname= "subversion server“ • Tortoise • Scaricare ed installare l’ultima versione • Testare con un repository browser se è possibile accedere al repository svn://localhost/Test

14. Configurare il repository • File path\conf\svnserve.conf • Contiene la configurazione del repository • Per una configurazione di default decommentare le seguenti linee • anon-access = none • auth-access = write • password-db = passwd • File path\conf\passwd • Contiene le password del repository • Le password sono memorizzate in chiaro come coppia utente=password

15. Repository Browser

16. CheckOut

17. Aggiunta di file al repository

18. Icone di subversion

19. Eseguire un commit

20. Modifiche concorrenti senza conflitto

21. Modifica concorrente con conflitto

22. Numeri di versione in subversion • Ad ogni operazione di update il subversion incrementa il numero di versione • Per commit di file multipli ad ogni file viene assegnato il nuovo numero di versione • Il repository locale tiene nella .svn la copia dei file relativi all’ultimo update per confronto con il repository • Alcune revisioni sono così importanti che hanno un modo particolare per essere individuate • Head: Rappresenta la versione attualmente più recente di un file o cartella • BASE: La versione presente attualmente nella cartella .svn della working copy • COMMITTED: L’ultima revisione in cui un file è stato cambiato prima di BASE • PREV: COMMITTED – 1, la precedente versione rispetto a COMMIT

23. Risolvere il conflitto

24. Controllare la storia di un file

25. Verificare lo stato dei file

26. Utilizzare lock in Subversion • Effettuare un lock impedisce agli altri utenti di effettuare il commit • I lock possono essere rotti (rimuovere un lock di un altro utente) o rubati (acquisire un lock anche se acquisito da un altro utente) • È buona norma inserire un commento ai lock e ricorrere al lock solo se strettamente necessario • È possibile utilizzare la proprietà svn:needs-lock per rendere read-only tutti i file che non hanno attualmente un lock impostato • È possibile impostare script di tipo hook nel server che avvertono in maniera esplicita, ad esempio via mail quando viene effettuato un lock

27. Tortoise svn:needs-lock

28. Comandi base • Check for modification: controlla quali file sono stati modificati • Revert: Annulla le ultime modifiche fatte • Get/Release Lock: Permette di lavorare in lock mode • Add: Aggiunge file al repository • Blame: Mostra per ogni file la lista dei cambiamenti con relativo autore • Create Patch: Crea un file in unified diff format delle modifiche attualmente fatte su un file. • Rename, Delete: Permettono di cancellare/rinominare i file dalla propria copia corrente, marcandoli come cancellati/rinominati • Revision Graph: mostra un grafico delle revisioni effettuate

29. Branch • Permette di gestire più versioni contemporaneamente dei file • Utile quando si ha la necessità di mantenere due versioni di uno stesso progetto che differiscono in pochi file • Utile per marcare una milestone dei propri progetti (in realtà è sufficente il numero di versione)

30. Comandi base

31. Aggiungere un progetto VS al repository • Creare la cartella nel repository dalla finestra Browse Repository • Effettuare il checkout della nuova cartella nella stessa cartella locale del progetto • Effettuare il commit selezionando dalla finestra di commit tutti i file tranne quelli delle cartelle bin e obj • Con il comando Add to ignore list indicare al tortoise che deve escludere le cartelle bin e obj

32. Aggiungere un progetto VS al repository

33. Buone pratiche da seguire • Includere se possibile un commento ad ogni checkout, in particolare se l’aggiornamento è connesso a qualche modifica sostanziale tipo l’implementazione di una nuova feature oppure la correzione di un bug • Effettuare un commit immediato dopo l’aggiunta di un file al progetto per evitare conflitti nel file di progetto • Effettuare lock durante la modifica di file che non possono essere sottoposti a merge, in generale file binari non testo.

34. Cosa includere nel repository • Cartella Tools • Includere l’installer di ogni tool necessario per lavorare al progetto • Includere se necessario una breve spiegazione all’istallazione ed al primo utilizzo • Cartella Libraries • Includere tutte le librerie di terze parti utilizzate nel progetto (nunit, nmock, enterprise-library, Atlas) • Cartella Docs • Includere tutti i file di documentazione, da diagrammi uml a semplici file testo che contengono informazioni sul progetto • Cartella References • Librerie sviluppate internamente che non hanno un installer • Versione decompressa delle librerie utilizzate (nunit, …) • In generale tutti gli assembly che vengono referenziati dai propri progetti • Cartella projects • I file di progetto, le solution, in generale tutto il codice sorgente.

35. Comandi base

36. Comandi base

37. Domande?

38. Slide e Materiale www.dotnetmarche.org Grazie!