Confronto tra gli strumenti a supporto del Concurrent Versioning System: CVS, SVN e GIT

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Confronto tra gli strumenti a supporto del Concurrent Versioning System: CVS, SVN e GIT"

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Ingegneria del software Confronto tra gli strumenti a supporto del Concurrent Versioning System: CVS, SVN e GIT Anno Accademico 2011/2012 Candidato: Pantaleone Nespoli matr. N

2

3 Indice Introduzione 4 Capitolo 1. Concurrent Versioning System Lock/Modify/Unlock Copy/Modify/Merge 9 Capitolo 2. Sistemi software per il controllo di versione CVS Storia Caratteristiche Comandi principali SVN Storia Caratteristiche Comandi principali GIT Storia Caratteristiche Comandi principali Atri progetti Mercurial Monotone 25 Capitolo 3. Confronto tra i sistemi per il controllo di versione Criticità CVS SVN GIT Progetti correlati 30 Conclusioni 32 Bibliografia 34 Sitografia 35 III

4 Inserire il titolo della tesi di laurea come intestazione Introduzione La gestione della configurazione (configuration managment) consiste nello sviluppare ed utilizzare gli standard e le procedure per gestire un sistema software in evoluzione: occorre controllare tali sistemi, perché perdere traccia delle modifiche apportate in taluna versione, crea problemi che portano ad ulteriori perdite economiche, in termini di costi aggiuntivi e di forza lavoro. In tutti i modelli di processi di sviluppo, essa è uno step fondamentale per la certificazione di qualità sia in ISO 9000 che nei CMM e CMMI; un esempio è IEEE , standard per i piani della gestione della configurazione[1]. Le procedure di gestione della configurazione definiscono come registrare ed elaborare le proposte di modifica al sistema, come correlarle ai componenti, e i meccanismi utilizzati per identificare le versioni del sistema. Ci sono diverse ragioni che portano allo sviluppo di diverse configurazioni per uno stesso sistema: esse possono essere prodotte per diverse piattaforme, possono incorporare funzioni specifiche richieste da un dato cliente, o altro ancora. La gestione della configurazione si divide in quattro attività fondamentali: pianificazione della gestione, gestione delle modifiche, gestione delle versioni e delle release e costruzione del sistema stesso. 4

5 Inserire il titolo della tesi di laurea come intestazione La pianificazione descrive gli standard e le procedure che dovrebbero essere utilizzate; esso dovrebbe essere organizzato in diverse sezioni con diversi obiettivi: Definire cosa dovrebbe essere gestito (oggetti della configurazione) e lo schema che si dovrebbe utilizzare per identificare queste entità; Stabilire chi è responsabile delle procedure di gestione della configurazione; Definire politiche di gestione che tutti i membri del team devono utilizzare; Specificare gli strumenti da utilizzare ed i processi adatti per utilizzare questi strumenti; Descrivere la struttura del database di configurazione utilizzato per registrare le informazioni. La gestione delle modifiche si occupa di verificare che le modifiche siano applicate al sistema in modo controllato. Le procedure di questo passo analizzano costi e benefici delle modifiche proposte (utilizzando il modulo CFR, change request form), approvano le modifiche realmente utili e registrano quali componenti del sistema sono stati modificati. I processi coinvolti nella gestione delle versioni e delle release identificano e registrano le versioni di un sistema. Una versione è un istanza di un sistema, che differisce per funzionalità, prestazioni o correzioni da altre istanze. Le versioni devono essere identificate in modo non ambiguo, utilizzando tecniche specifiche: Numerazione delle versioni; Identificazione basata su attributi: ogni componente ha un nome ed un insieme di attributi, eventualmente ordinati, associati ad ogni versione; Identificazione orientata alle modifiche: ogni componente ha un nome come nel caso precedente, ma è anche associato a uno o più richieste di modifica. Una release è, invece, una versione distribuita ai clienti. Essa non è solo codice eseguibile, ma può includere anche file di configurazione, file di dati, programma di installazione, documentazione (in formato elettronico o cartaceo), imballaggio e 5

6 Inserire il titolo della tesi di laurea come intestazione pubblicità associate. I gestori delle release devono trovare il giusto compromesso tra costo di distribuzione delle stesse e frequenza di distribuzione, in modo da mantenere vivo il mercato e non ledere gli interessi dei clienti. Per la costruzione del sistema, il supporto degli strumenti CASE (computer-aided software engineering) è fondamentale: la combinazione di questi strumenti crea i workbench per la gestione della configurazione che ne supportano tutte le attività; riscontriamo due tipologie fondamentali: Workbench aperti: gli strumenti per ogni stadio del processo sono integrati attraverso procedure aziendali standard per il loro uso. Molti di questi strumenti sono opensource e specifici per il loro uso (bug-tracking, gestione delle versioni, strumenti per il build); Workbench integrati: forniscono funzionalità integrate per la gestione delle versioni, per costruzione del sistema e per il tracciamento delle modifiche; tuttavia gli ambienti di sviluppo presenti sul mercato sono complessi e costosi. Gestire le versioni significa elaborare grandi quantitativi di informazioni, assicurandosi che le modifiche del sistema siano registrate e controllate. Gli strumenti di gestione delle versioni controllano un repository il cui contenuto è immutabile; per lavorare su un oggetto di configurazione occorre, quindi, prima estrarlo dalla repository e inserirlo in una directory di lavoro. Successivamente al lavoro apportato, si reinserisce nella repository creando automaticamente una nuova versione. Tutti i sistemi di gestione della versioni forniscono un insieme di funzionalità simili: identificazione delle versioni, gestione della memorizzazione, registrazione dello storico delle modifiche, sviluppo indipendente (gestioni dei branch e delle versioni concorrenti) e supporto di progetto (gestioni di progetti concorrenti). Tale elaborato di tesi si occuperà di approfondire aspetti riguardanti lo sviluppo corretto di versioni concorrenti, analizzandone le problematiche e fornendo una panoramica ampia riguardo gli strumenti a supporto. 6

7 Capitolo 1 Concurrent Versioning System Il Concurrent Versioning System (CVS) è un sistema di controllo delle versioni di un progetto, legato alla produzione ed alla modifica di file. In pratica, esso permette ad un gruppo di persone di lavorare simultaneamente sullo stesso gruppo di file, generalmente sorgenti di un programma, mantenendo il controllo dell evoluzione delle modifiche che vengono apportate. Per attuare questo obiettivo, il sistema CVS mantiene un deposito centrale (repository) dal quale i collaboratori di un progetto possono ottenere una copia del lavoro. I collaboratori modificano il file della propria copia di lavoro e sottopongono le loro modifiche al sistema CVS che le integra nel deposito. Il compito di un sistema CVS non si limita a questo: è possibile, nella fattispecie, ricostruire la storia delle modifiche apportate ad un gruppo di file, oltre ad essere anche possibile ottenere una copia che faccia riferimento ad una versione precedente di quel lavoro. I sistemi di controllo di versione devono risolvere lo stesso problema fondamentale: riuscire a far interagire gli utenti evitando che essi possano interferire accidentalmente. Consideriamo lo scenario illustrato in figura 1.1. Supponiamo di avere due collaboratori, che chiameremo Harry e Sally, che decidono di modificare lo stesso file del repository nello stesso momento. Se Harry salva le sue modifiche nel repository per primo, è molto probabile che Sally possa accidentalmente sovrascriverle con la propria versione aggiornata del file. Mentre la versione di Harry del file non verrà persa per sempre (il sistema tiene memoria di ogni cambiamento), qualsiasi modifica apportata da Harry non sarà presente nella nuova versione del 7

8 file di Sally, perché lei non ha ricevuto le modifiche apportate da Harry. Ovviamente, questa è una situazione che vorremmo evitare. Le soluzione proposte agli sviluppatori sono due modelli concettualmente diversi: il modello lock/modify/unlock e il modello copy/modify/merge [2]. Fig. 1.1: esempio scrittura concorrente 1.1 Lock/Modify/Unlock In questo modello, il repository permette ad una sola persona alla volta di modificare un file. Questa politica di esclusione è gestita attraverso dei blocchi (lock). Harry deve bloccare un file prima di apportare modifiche allo stesso. Se Harry ha bloccato il file, Sally non potrà accedervi e bloccarlo a sua volta, non riuscendo ad apportare ulteriori modifiche. Tutto ciò che può fare è leggere il file ed aspettare che Harry abbia terminato il proprio lavoro e rilasci il blocco. In seguito, Sally può bloccare nuovamente il file e procedere con le proprie modifiche. Fig. 1.2 Modello Lock/Modify/Unlock Questo modello, però, risulta restrittivo, e spesso diventa un ostacolo per i collaboratori: 8

9 Il blocco potrebbe creare problemi di natura amministrativa: se Harry dimentica di sbloccare il file, Sally dovrà contattare un amministratore per far rilasciare il blocco di Harry. La situazione causa notevole spreco in termini di tempo e costi aggiuntivi; Il blocco potrebbe creare inutili serializzazioni: esso non permette ai collaboratori di lavorare in maniera simultanea sul file, anche se le modifiche apportate non si influenzano in nessun modo. Tuttavia in questa situazione, il dispendio è notevole. Il blocco potrebbe creare un falso senso di sicurezza: se Harry e Sally bloccano rispettivamente un file A ed un file B, che dipendono uno dall altro, è possibile che le modifiche apportate siano semanticamente incompatibili. La soluzione del blocco non è stata in grado di prevenire il problema: bloccando i file, i collaboratori hanno la sensazione di lavorare in modo sicuro ed isolato, e non si preoccupano di discutere eventuali cambiamenti incompatibili in anticipo. 1.2 Copy/Modify/Merge In questo modello, il client di ogni utente comunica con il repository e crea la propria copia di lavoro (working copy o sandbox), una riproduzione dei file e della directory di lavoro effettuando un operazione di check out. Gli utenti possono, poi, lavorare in modo parallelo, modificando le proprie copie private ed effettuando il commit. Altri programmatori potrebbero richiedere aggiornamenti della loro copia (update) al repository o generare delle ulteriori versioni. Infine, tali copie vengono fuse (merge) in una versione finale. Spesso il sistema per il controllo di versione assiste nella fase di integrazione, ma alla fine è un essere umano il responsabile di fare in modo che questo processo si compia correttamente. 9

10 Fig. 1.3 Modello Copy/Modify/Merge Cosa accade se le modifiche di Sally, di fatto, si sovrappongono a quelle di Harry? Questa situazione è chiamata conflitto. Quando Harry chiede al proprio client di fondere le ultime modifiche del repository nella sua copia di lavoro, la propria copia è etichettata come in uno stato di conflitto: egli sarà in grado di vedere entrambi gli insiemi di cambiamenti e scegliere manualmente tra questi. Una volta che Harry ha risolto manualmente i cambiamenti sovrapposti (possibilmente dopo una aver discusso con gli altri collaboratori), può salvare in maniera sicura il file integrato nella repository. In alternativa, è possibile scegliere di mantenere entrambe le versioni come alternative, generando un branch. Questo modello appare caotico, ma nella pratica funziona senza difficoltà. L utente può lavorare in parallelo con gli altri collaboratori, in quanto i conflitti in sistemi di grandi dimensioni sono rari. Inoltre, la quantità di tempo necessario per risolvere i conflitti è decisamente inferiore a quella persa nell uso di un sistema a blocchi. Alla fine, tutto si riconduce ad un fattore critico: la comunicazione tra gli utenti. Quando la comunicazione è scarna, i conflitti sia sintattici che semantici aumentano esponenzialmente, intaccando così la qualità del sistema. 10

11 Capitolo 2 Sistemi software per il controllo di versione Analizzeremo adesso gli strumenti software a supporto del Concurrent Versioning System, avendo cura di esaltare gli aspetti più importanti riguardanti le tematiche dell elaborato. 2.1 CVS Il Concurrent Versions System (CVS) è un software che implementa un sistema di controllo versione: mantiene al corrente di tutto il lavoro e di tutti i cambiamenti in un insieme di file, permettendo a diversi sviluppatori di collaborare. Esso consente di gestire a linea di comando le principali operazioni previste dai modelli lock/modify/unlock e copy/modify/merge Storia Cvs nasce come un mucchio di shell scripts scritti da Dick Grune, che utilizzò questo sistema per cooperare con i suoi studenti ad un progetto[3]: non riuscendo mai ad avere gli stessi orari, Grune ideò un sistema che permettesse loro di collaborare senza trovarsi fisicamente insieme. Mentre il codice attuale è totalmente differente da quello presente negli shell scripts, molti degli algoritmi di risoluzione dei conflitti sono tuttora presenti. Il codice che si è evoluto nella versione corrente del CVS è stato ideato nell aprile del 1989 da Briam Berliner, aiutato in seguito da Jeff Polk, e rilasciato a favore della comunità sotto GPL (GNU General Public License). Attualmente, un gruppo di volontari si occupa dello sviluppo del codice CVS e della correzione dei bug. 11

12 2.1.2 Caratteristiche Il CVS utilizza un architettura client-server: il lato server gestisce una repository contenente sia tutti i file da gestire, sia tutte le informazioni sulle versioni; esso memorizza tutte le versioni in un singolo file in un modo intelligente che conserva solo le differenze tra le versioni. Il client, invece, si connette al server per ottenere una propria copia del file (working copy o sandbox) nella propria directory di lavoro (working directory); al termine della modifica, lo reinserisce all interno della repository (commit). Generalmente, server e client girano su macchine diverse, ma è possibile anche trovare il server su una delle macchine client. All interno della repository sono salvati gli history files per ogni file sotto controllo di versione, etichettati con una v alla fine del nome: questi file contengono, tra le altre cose, informazioni per ricreare ogni versione del file, tutti i messaggi di commit e l username della persona che ha effettuato il commit. Il sistema CVS assegna automaticamente un numero di versione unico ad ogni file (1.1, 3.2.1), incrementando di un unità il numero più a destra ad ogni modifica (1.1, 1.2, 1.3 e così via). Nel caso la numerazione di default non sia soddisfacente, il client può rinominare a proprio piacimento il numero di versione, utilizzando il l opzione -r del commit. È possibile dare anche un nome simbolico ad alcune versioni, utilizzando il comando tag: esso permette, oltre ad annotare le versioni, di inserire informazioni aggiuntive; il tag risulta molto utile per distinguere tra loro le diverse release di un software. CVS non è limitato ad uno sviluppo lineare: esso permette di isolare i cambiamenti su una linea separata ed indipendente di sviluppo, conosciuto come ramo (branch). Ogni branch ha un proprio numero, ottenuto inserendo un numero intero al numero di versione da cui il ramo parte. Quando si modifica un file su un ramo, tali modifiche non vengono visualizzate sul tronco principale o altri rami, ma è possibile fondere i cambiamenti utilizzando il flag j branchname sul comando update. Il branch risulta molto utile per sviluppare, anche contemporaneamente, più versioni dello stesso lavoro, con scopi diversi: ad esempio, possiamo utilizzare un branch per il bug-tracking e un branch per lo sviluppo di nuove funzioni. 12

13 Riguardo alla gestione dei conflitti, CVS utilizza un modello di default chiamato unreserved checkout: in questo modello, più sviluppatori possono lavorare sulla propria sandbox simultaneamente. La prima persona che effettua il commit non ha modo di sapere se altre persone stanno lavorando sullo stesso file; le successive, invece, riceveranno un messaggio di errore quando provano ad effettuare il commit. Il sistema, in modo semiautomatico, consiglia agli sviluppatori successivi di effettuare un update/merging della versione del file nella repository; al termine, essi possiederanno una versione locale che tiene conto delle proprie modifiche e di quelle degli altri utenti. Di tale versione sarà possibile effettuare un commit, andando così a creare una versione successiva. Ad ogni modo, gli stati di un file sono visibili dagli sviluppatori con il comando status, così da poter effettuare sempre la corretta operazione senza intaccare la coerenza del sistema; da questo punto di vista, CVS cerca di facilitare la comunicazione, senza porre vincoli restrittivi come nel caso del sistema a blocchi Comandi principali La sintassi utilizzata per i comandi è: cvs [cvs_options] cvs_command [command_options] [command_args] cvs : il nome del programma; cvs_options : opzioni che influenzano i comandi; cvs_command : il comando vero e proprio; command_options : opzioni per il comando specificato; command_args : argomenti per il comando. Di seguito, riportiamo una lista dei comandi più comunemente utilizzati: add : aggiunge file o directory alla repository; diviene effettivo quando viene effettuato il commit. admin : interfaccia CVS per classificare strutture amministrative. annotate : specifica quale revisione modifica linee di un file. checkout : crea una working directory contenente copue dei file specificati nella richiesta. commit : inserisce i file modificati nella repository. 13

14 diff : mostra le differenze tra diverse versioni di un file. export : simile a checkout, utilizzato per esportare una copia da CVS. history : mostra gli stati dei file e degli utenti. import : importa sorgenti esterne nel CVS. init : crea una repository se non esiste. log : stampa le informazioni di log per i file. login : prompt per inserire la password dell utente. logout : rimuove la entry in.cvspass dalla repository. release : indica che il modulo non è più in uso. remove : elimina file dalla working directory, oppure intere directory. status: mostra le informazioni sui file. tag : aggiunge un tag simbolico ad una versione del file. update : sincronizza il proprio lavoro con la repository. 2.2 SVN Subversion (noto come svn, che è il nome del suo client a riga di comando) è un sistema di controllo versione libero e open-source, progettato da CollabNet Inc. con lo scopo di essere il naturale successore di CVS; esso è un sistema che permette di gestire qualsiasi insieme di file, contenenti sia codice sorgente che altro[2] Storia All inizio del 2000, CollabNet Inc. iniziò a cercare sviluppatori per scrivere un software che sostituisse CVS. CollabNet offre una suite di software collaborativi chiama CollabNet Enterprise Edition (CEE); sebbene CEE usasse CVS per il controllo di versione, le limitazioni apparivano evidenti. Nel frattempo, CVS era diventato uno standard de facto nel mondo open-source, così CollabNet decise di scrivere da zero un nuovo sistema, mantenendo l idea di base di CVS, ma evitando i suoi bug e aggiungendo alcune funzionalità. Il team di sviluppo, composto da Karl Fogel, Jim Blandy, Ben Collins- Sussman, si concentrò a pieno tempo sul progetto, e il 31 Agosto 2001 Subversion divenne 14

15 self-hosting ; nel febbraio 2004 venne rilasciata al pubblico la prima versione di Subversion Caratteristiche Subversion è un sistema client/server centralizzato per la condivisione di informazioni: al centro c è la repository, che è l archivio principale di dati. Esso memorizza qualsiasi cambiamento scritto in esso nella forma di un filesystem ad albero. Come server centralizzato è possibile utilizzato un server Web Apache, tramite il protocollo WebDAV/DeltaV, oppure un server indipendente basato su TCP/IP. Fig. 2.1 Architettura SVN Ad un estremo c è il repository SVN contenente tutti i dati sotto controllo di versione; all altro estremo c è il client SVN, che controlla le copie locali. I percorsi che portano da un estremo all altro sono i metodi di accesso alla repository, che può avvenire tramite rete 15

16 o direttamente in locale, nel caso il repository sia locale appunto. A partire dalla versione 1.1, SVN gestisce due tipologie diverse di repository: la prima memorizza tutto in un database, l altra invece memorizza le informazioni direttamente nel filesystem (perciò chiamata FSFS). Vantaggi e svantaggi sono strettamente dipendenti dall uso che si intende fare, ricordando che i programmi che hanno accesso alla repository sono totalmente inconsapevoli del tipo di memorizzazione, ma che la struttura intrinseca porta differenze evidenti (dimensioni, velocità, scalabilità ). Subversion implementa un filesystem virtuale versionato che traccia i cambiamenti nel corso del tempo degli alberi delle intere directory; in questo modo, sia file che directory vengono versionate, ed è possibile effettuare su entrambe operazioni di aggiunta, cancellazione, copia e rinomina. Anche i metadati vengono posti sotto controllo di versione, come i file a cui sono associati. Per quanto concerne i numeri di versione, anche SVN utilizza un sistema di incremento numerico lineare (1.1, 1.2 ), inoltre permette di utilizzare un numero di chiavi per ricercare velocemente una particolare versione (la prima, la più recente, la precedente a), e per trovare la data in cui è stata effettuata la revisione. Un altra caratteristica senza dubbio interessante è l atomicità dei commit: un commit interrotto non lascia la repository in uno stato di incoerenza. Ciò permette agli sviluppatori di costruire ed effettuare cambiamenti come un blocco logico unico, prevenendo eventuali problemi che possono occorrere quando solo un set di modifiche vengono inviate con successo. SVN utilizza un meccanismo molto efficiente per effettuare tag e branch: l idea di base è che il costo in termini di tempo e spazio dedicato al branching e al tagging non deve essere proporzionale alla grandezza del progetto, ma alla dimensione delle modifiche. Il sistema crea branch e tag utilizzando un meccanismo simile all hard-link unix (collegamento) per copiare il progetto; in questo modo, tali operazioni utilizzano una quantità di tempo molto breve e costante. Esso è capace, inoltre, di copiare non solo singoli file, ma intere cartelle, anche se non supporta la copia tra due differenti depositi (cross-repository); ciò avviene in relazione al fatto che SVN non ha un concetto interno di branch, ma solo di copia: esso 16

17 memorizza tutta la storia riguardante quella copia, creando di fatto un ramo alternativo di progetto. In merito al modello di sviluppo, SVN utilizza copy/modify/merge per evitare i limiti che comporta il modello a blocchi; conseguentemente, ha bisogno di gestire eventuali conflitti affiorati effettuando il merging. Innanzitutto, previene l utente dall effettuare un merging erroneo tra due strutture totalmente diverse: esso infatti mostra un messaggio skipped target per indicare che altre destinazioni sono state saltate. In caso di conflitto reale, SVN assiste l utente con tre operazioni: Visualizza il file con una C per indicare il conflitto (anche durante l update); Se considera che il file possa essere fuso, inserisce dei marcatori di conflitto (conflict markers), stringhe speciali di testo che delimitano gli estremi del conflitto per rendere visibili le aree sovrapponibili; Per ogni file che ha avuto in conflitto, mette nella propria copia di lavoro tre file extra che non sono sotto controllo di versione: filename.mine (il file prima dell aggiornamento), filename.roldrev (il file nella versione BASE prima dell aggiornamento) e filename.rnewrev (il file ricevuto all aggiornamento). L utente può scegliere di compiere una delle seguenti azioni: Sistemare il conflitto a mano ; Usare uno dei file temporanei per sovrascrivere la propria copia di lavoro; Eseguire il comando svn revert per annullare le modifiche fatte in locale. Una volta risolto il conflitto, è necessario informare il sistema eseguendo il comando svn resolved: vengono così rimossi tutti i file temporanei e SVN considera il conflitto come risolto. Opzionalmente, il sistema permette anche di utilizzare il meccanismo dei blocchi per trattare file particolarmente delicati, ad esempio i file binari, dove è spesso impossibile fondere eventuali modifiche apportate da più sviluppatori Comandi principali La sintassi utilizzata per i comandi è: svn <subcommand> [options] [args] svn : il nome del programma; 17

18 subcommand : il comando vero e proprio; options : opzioni per il comando specificato; args : argomenti per il comando. Di seguito, riportiamo una lista dei comandi più comunemente utilizzati: add : aggiunge file, directory o link simbolici alla propria copia di lavoro. blame : mostra autore e informazioni dei revisione in-line per i file o URL specificati. cat : mostra i contenuti dei file o URL specificati. checkout : preleva dalla repository la propria copia di lavoro. cleanup : pulisce ricorsivamente la propria copia di lavoro, rimuovendo tutti i blocchi e terminando le operazioni incomplete. commit : invia le modifiche della propria copia di lavoro alla repository. copy : copia un file o una directory in una copia di lavoro o nella repository. delete : elimina un elemento da una copia di lavoro o dalla repository. diff : mostra le differenze tra due diversi path. export : esporta un albero delle directory. help : aiuto! import : importa un file o un intero albero senza controllo di versione nella repository. info : mostra informazioni su un oggetto locale o remoto. list : elenca le entry della directory specificata nella repository. lock : blocca file o URL nella repository. log : mostra i messaggi di log merge : applica le differenze tra due sorgenti. mkdir : crea una nuova directory sotto controllo di versione. move : sposta file o directory. propdel : rimuove proprietà da un oggetto. propedit : inserisce proprietà per uno o più oggetti sotto controllo di versione. propget : stampa il valore delle proprietà. 18

19 proplist : elenca tutte le proprietà. propset : setta una proprietà ad un determinato valore. resolve : rimuove lo stato conflicted dalla copie o directory di lavoro. revert : annulla tutte le modifiche locali. status : stampa lo stato delle copie o directory di lavoro. switch : aggiorna la copia di lavoro da un URL differente. unlock : blocca file o URL nella repository. update : aggiorna la copia di lavoro. 2.3 GIT Fig. 2.2 Esempio comandi SVN Git è un sistema software open-source di controllo di versione distribuito creato da Linus Torvalds. Il progetto era stato pensato inizialmente solo come motore a basso livello per poter scrivere un front-end; tuttavia in seguito si è evoluto, diventando un sistema completo di controllo versione, utilizzabile direttamente da linea di comando. Anche esso è sotto licenza GPL (GNU General Public License)[4]. 19

20 2.3.1 Storia Il nome di GIT è stato dato dallo stesso Linus Torvalds, riferendosi ad un termine gergale britannico che indica una persona stupida o sgradevole; il sito ufficiale di GIT fornisce spiegazioni alternative, attribuendo il nome alla difficoltà di utilizzo delle prime versioni. Lo sviluppo del sistema è iniziato dopo che diversi sviluppatori del kernel di Linux sono stati costretti ad abbandonare l accesso ai sorgenti tramite il sistema proprietario BitKeeper, diventato non più gratuito. Torvalds voleva un sistema distribuito che potesse usare come BitKeeper, ma nessuno dei sistemi disponibili soddisfaceva gratuitamente i suoi bisogni, con particolare attenzione alle prestazioni, alla salvaguardia dalla corruzione dei dati (sia intenzionale che accidentale). Lo sviluppo di GIT è cominciato nell aprile del 2005; il 16 giugno dello stesso anno è stato rilasciata la versione del kernel Linux, la prima gestita con GIT. Torvalds ha pensato deliberatamente di evitare gli approcci convenzionali, rendendo il sistema fortemente innovativo. Nel luglio del 2005 ha ceduto la manutenzione a Junio Hamano, che è il responsabile della versione 1.0 rilasciata nel dicembre 2005, ed attuale manutentore Caratteristiche La prima caratteristica di questo sistema è senz altro il server distribuito: ogni utente possiede essenzialmente un backup completo del server principale. Le modifiche sono copiate da una repository all altra, e sono importate come rami addizionali, e possono essere fusi allo stesso modo dei rami sviluppati localmente. Con questa architettura, GIT non ha un singolo point of failure, in quanto le copie possono sostituire l intero server principale in caso di incidente o corruzione dei dati; ovviamente, i workflow devono essere gestiti in maniera efficace. Inoltre, i repository possono essere facilmente pubblicati tramite i protocolli esistenti (alta compatibilità): HTTP, FTP, SSH, rsync o uno speciale protocollo GIT. GIT possiede anche un emulazione del server CVS, che consente di utilizzare gli esistenti client CVS per accedere alle repository proprie. GIT ha due strutture dati, un indice (index) modificabile che mantiene informazioni sul contenuto della prossima revisione, che costituisce di fatto lo strato intermedio tra DB e l albero di lavoro, ed un append-only object DB che contiene quattro tipologie di oggetti: 20

21 Un oggetto blob è il contenuto di un file; tali oggetti non hanno nome, data, ora, né altri metadati. Il sistema memorizza ogni versione di un file come un oggetto blob distinto; Un oggetto tree è l equivalente di una directory; Un oggetto commit collega gli oggetti albero in una cronologia. Contiene il nome di un oggetto albero, data e ora, messaggio di archiviazione (log message) ed i nomi di eventuali commit genitori; Un oggetto tag è un contenitore che contiene riferimenti ad un altro oggetto e può contenere metadati aggiuntivi riferiti ad un altro oggetto. Esso è comunemente usato per memorizzare una firma digitale di un oggetto commit per il rilascio dei dati gestiti da GIT. Fig. 2.3 Architettura GIT Ogni oggetto è identificato da un codice hash del suo contenuto: esso viene inserito nel DB in una directory corrispondente alle prime due cifre del suo codice hash, le restanti cifre costituiscono il nome del file che contiene tale oggetto. All aggiunta di un nuovo oggetto, questo viene memorizzato per intero dopo averlo compresso con zlib. Ciò che, però, realmente rende questo sistema innovativo è il modello di branching e merging utilizzato: permette agli sviluppatori di avere più rami locali che possono essere del tutto indipendenti, incentivando così un forte sviluppo non lineare del progetto. La 21

22 creazione, il merging e l eliminazione di queste linee di sviluppo avvengono in pochi secondi, e possono essere attraversate e visualizzate senza problemi grazie all uso degli strumenti propri del sistema. Le tecniche per effettuare il merging sono intercambiabili: GIT, infatti, possiede un modello di merging incompleto, con diversi algoritmi per portarlo a termine. Nel caso in cui tutti gli algoritmi dovessero fallire, ciò viene comunicato all utente che deve effettuare un merging manuale. Inoltre, GIT offre un alternativa al merging chiamata rebasing, dal nome del comando rebase[5]; all invocazione del comando, il sistema effettua i seguenti passi: identifica ogni commit antenato del commit corrente, ma non del nuovo commit; determina cosa è cambiato per ognuno di questi commit; imposta l intestazione corrente in modo da puntare al nuovo commit; per ogni cambiamento trovato, riapplica tali cambiamenti e crea un nuovo commit. Il rebasing ha come suo vantaggio il fatto che non c è creazione di un commit, ma può essere problematico poiché l intestazione effettuata su di esso non può essere inviata alla repository remota. Fig. 2.4 Workflow GIT Come voluto dal suo creatore, GIT possiede prestazioni molto elevate: è tipicamente un ordine di grandezza più veloce degli altri sistemi di controllo di versione, addirittura due ordini per alcune operazioni. Ciò comporta una gestione efficiente dei grandi progetti, poiché esso non diminuisce le sue prestazioni all aumentare della grandezza degli stessi. Il vantaggio principale viene dall architettura stessa: comunicare localmente è molto più veloce che comunicare con un server centralizzato presente su un altra macchina. Il data model utilizzato da GIT assicura l integrità del progetto: su ogni file o commit è effettuata una checksum, e possono essere ritrovati in base a questa. Una versione dipende 22

23 dalla completa cronologia di sviluppo che ha portato a committarla; una volta che essa è stata pubblicata, non è più possibile cambiare le vecchie versioni senza che ciò venga notato. La struttura è simile ad un hash tree, ma con dati addizionali presenti sui nodi e sulle foglie Comandi principali La sintassi utilizzata per i comandi è: git <command> [options] [args] svn : il nome del programma; command : il comando vero e proprio; options : opzioni per il comando specificato; args : argomenti per il comando. Di seguito, riportiamo una lista dei comandi più comunemente utilizzati: add : aggiunge file dalla directory di lavoro all indice. archive : crea un file zip con il contenuto di un albero dalla propria repository. blame : mostra un file con le annotazioni su ogni riga. branch : elenca i rami esistenti. Crea un nuovo ramo se il nome specificato nella richiesta è previsto. cat-file : usato per visualizzare il tipo di un oggetto tramite il suo valore di hash. checkout : abbandona le modifiche fatte ad un file nella cartella di lavoro, sovrascrivendolo con quello presente nell ultima versione. clone : effettua una copia della repository GIT da remoto. commit : prende tutte le modifiche presenti nell indice, crea un nuovo oggetto commit che punta ad esso e setta il ramo al nuovo commit. Prevede l aggiunta obbligatoria del messaggio riferito al commit. config : setta i valori di configurazione dell utente. diff : mostra le differenze tra file nella repository, nella directory o nell indice. fetch : prende tutti gli oggetti dal repository che non sono presenti in quello locale. fsck : identifica gli oggetti corrotti tramite controllo di integrità. grep : cerca attraverso gli alberi per contenuto. 23

24 init : inizializza una repository GIT, creando una sola cartella.git nella radice. instaweb : lancia un web server con un interfaccia nella repository locale e automaticamente direziona un web browser in essa. log : mostra la lista dei commit su un ramo; esiste anche una versione grafica gitk. ls-tree : mostra un oggetto albero, inclusi il nome di ogni oggetto e il valore di hash del blob o albero che punta ad esso. merge : fonde uno o più rami nel ramo corrente e automaticamente crea un nuovo commit se non ci sono conflitti. prune : rimuove gli oggetti che non sono più puntati da alcun oggetto in un ramo. pull : prende file dalla repository remota e li fonde con i file in quella locale; equivalente ad utilizzare la sequenza fetch/merge. push : inserisce tutti gli oggetti locali modificati nel repository remoto. rebase : alternativa al merge, sposta la base di un albero innestandola altrove. reset : resetta l indice e la directory di lavoro allo stato dell ultimo commit. rm : rimuove file dall indice e dalla directory di lavoro. remote : mostra tutte le versioni remote della repository. show : mostra le informazioni di un oggetto GIT. stash : salva temporaneamente le modifiche senza committarle. status : mostra lo stato dei file nell indice. tag : etichetta un commit specifico con un semplice messaggio. 2.4 Altri progetti Per completezza della trattazione, citeremo altri sistemi di controllo di versione comunemente utilizzati, risaltandone le caratteristiche principali Mercurial Mercurial è un software multipiattaforma di controllo di versione distribuito, creato da Matt Mackall e rilasciato sotto GNU General Public License (GPL). Esso è quasi completamente scritto in Python, ma include anche un implementazione diff binaria scritta 24

25 in C; il programma ha un interfaccia da linea di comando, ma incorpora anche un elementare interfaccia web. Il sistema offre alcuni dei vantaggi tipici dei sistemi di controllo di versione distribuiti: Possibilità di lavoro degli sviluppatori anche in assenza di connessione di rete; Velocità di esecuzione dei comandi; Sicurezza del codice, poiché ogni sviluppatore possiede una copia intera della storia del progetto, che funge da backup locale per tutti gli altri utenti; Possibilità di scelta da parte del team di sviluppo di un flusso di lavoro arbitrario, non necessariamente lineare; Le funzionalità possono essere aumentate, importandole dal sito o scrivendo di proprio pugno; Facilità di utilizzo Monotone Monotone è un software open-source per il controllo di versione distribuito, scritto in C++. L idea principale al centro del progetto è di costruire un sistema che prediligesse l integrità rispetto alle prestazioni elevate peculiari ad un sistema distribuito: esso, infatti, utilizza molte primitive crittografiche per tracciare le versioni dei file (utilizzando codice hash, rendendole quindi non lineari) e per autenticare le azioni degli utenti (utilizzando la firma crittografica RSA). Monotone supporta fortemente i workflow diverge/merge, permettendo di committare il lavoro prima di effettuare il merge. Esso, però, supporta esclusivamente il protocollo netsync, ritenuto più robusto ed efficiente, e condivide alcuni concetti di base con rsync e cvsup. La facilità di utilizzo è un altra delle sue caratteristiche importanti, dovuto al set di comandi simili al più rinominato sistema CVS, di cui permette di importare interi progetti; inoltre utilizza interfacce grafiche stabili, supportate su diversi sistemi. 25

26 Capitolo 3 Confronto tra i sistemi per il controllo di versione I sistemi di controllo di versione analizzati finora sono solo una piccola parte di tutti quelli attualmente disponibili sulla rete; una domanda, a questo punto, sorge spontanea: Perché così tanti? Sono realmente necessari? Le risposte sono molteplici, e solo dopo un accurato confronto, potremo riuscire a comprenderle meglio. La differenza principale, e senza dubbio quella che prima risalta agli occhi di un osservatore, è l architettura dei sistemi appena citati: centralizzata per CVS e SVN, distribuita per GIT. Due filosofie completamente diverse nell approccio al controllo di versione, che portano con sé pregi e difetti: CVS e SVN hanno la necessità di conservare in locale solo le informazioni per raggiungere il repository remoto; tutte le modifiche vengono conservate direttamente su quello remoto, e vengono propagate tramite un commit; GIT necessita, invece, di avere una copia del repository in locale per poter condividere le proprie informazioni di versione; all atto della modifica ha bisogno prima di portarla in locale (tramite commit), e successivamente nel server remoto (tramite push). Altra differenza concettuale è il modello di dati utilizzato per gestire le modifiche ai file: CVS e SVN trattano le informazioni di versione come una catena di modifiche lineare applicate ai singoli file: in caso di commit, vengono tracciate solo le 26

27 variazioni dei file realmente modificati rispetto alla versione precedente (utilizzando la compressione delta); GIT considera i dati come una serie di snapshot (fotografie) del filesystem sotto controllo di versione: ogni volta che viene eseguito un commit, esso analizza i cambiamenti dei file sotto controllo, creando una struttura logica ad albero che mappa la struttura del filesystem stesso. La struttura dati creata sarà composta dai file modificati rispetto alla precedente versione, ed un riferimento all ultima versione modificata dei file che non sono stati oggetto di un commit: così per ogni commit, avremo uno snapshot di tutto il repository. Se da un lato è evidente la maggiore complessità di un sistema distribuito rispetto ad uno centralizzato, esso comporta vantaggi specifici: Prestazioni elevate; Maggiore flessibilità: gli sviluppatori possono lavorare anche in assenza di connessione di rete disponendo del DB in locale; Integrità dei dati, utilizzando una codifica hash; Sicurezza: disponendo di diverse copie locali dei server remoti, esistono più punti di fallimento in caso di guasti o malfunzionamenti. Inoltre, è da sottolineare come GIT rappresenti realmente un innovazione concettuale nel mondo dei sistemi di controllo di versione: con un approccio totalmente diverso, focalizzandosi su idee ben precise, è riuscito a catturare l attenzione di tantissimi utenti che lo utilizzano per lo sviluppo di software collettivo. 3.1 Criticità Andremo adesso ad analizzare le criticità dei sistemi nello specifico, elencando caso per caso i problemi più evidenti CVS Diverse caratteristiche di CVS sono state spesso soggette a critiche da parte degli sviluppatori; è da tenere, comunque, in conto che il sistema è stato progettato alla fine degli anni 80, in cui visioni di hardware e software erano molto diversi da quelle attuali. 27

28 3.1.2 SVN Le versioni create da un commit riguardano i singoli file, invece che abbracciare l intera collezione di file di un progetto o l intero repository; tale problema può essere in parte risolto con l uso dei tag. Il sistema non mette sotto controllo di versione lo spostamento o il cambiamento di nome di file o directory; ciò deriva principalmente da un problema cronologico, in quanto negli anni 80 il refactoring era molto meno comune nei processi sw. Nessun controllo di versione per i link simbolici. I commit non sono atomici. Le operazioni di branching sono dispendiose; CVS assume che la maggior parte delle operazioni avvengano sul ramo principale, con rami secondari dalla vita breve. Il sistema è ideato per trattare principalmente file di testo, e successivamente è stato modificato per supportare anche i file binari. Subversion nasce come naturale evoluzione (se vogliamo temporale) di CVS: esso, infatti, ne importa gran parte delle caratteristiche fondamentali, andando ove possibile a migliorare pecche concettuali e strutturali: Il controllo di versione è esteso anche alle intere directory, e vengono versionate anche aggiunte, copie, cancellazioni e cambiamenti di nome di file e directory; I commit effettuati sono atomici, quindi sono visti dagli sviluppatori come un blocco logico unico, e non lasciano il repository in uno stato di inconsistenza in caso di errore. Anche i metadati vengono posti sotto controllo di versione; modifica attuata in seguito alle necessità dei tempi moderni. É possibile integrare il repository con un server http Apache, rendendolo di fatto più stabile e facilitandone l interoperabilità. Le operazioni di branching e tagging sono meno dispendiose, in quanto proporzionali alla grandezza della modifica, e non a quella del progetto. 28

29 Ovviamente, anche tale sistema è affetto da problematiche: Implementa le operazioni di ridenominazione di file o directory come una copia del nuovo nome ed una cancellazione del precedente: solo il nome cambia, tutti i dati relazionati alla cronologia delle modifiche restano identici, ed il sistema utilizza ancora il vecchio nome nelle precedenti versioni dell albero. Manca delle principali feature di amministrazione e gestione del repository. Salva copie addizionali dei dati sulla macchina locale, creando problemi nel caso di progetti o file molto grandi, o nel caso di sviluppatori che lavorano su più rami contemporaneamente. Non memorizza la data delle modifiche apportate ai file, ma le date dei check-out e dei check-in GIT Abbiamo già ampiamente parlato delle innovazioni introdotte da GIT nel mondo dei sistemi di controllo versione; andiamo adesso ad analizzare le problematiche rilevate dagli utilizzatori del sistema: GIT memorizza ogni nuovo oggetto in un file distinto; ciò potrebbe causare un problema di inefficienza nonostante la compressione. Questo problema viene risolto da una sorta di impacchettamento (packs), che immagazzinano molti oggetti in un solo file, con la supposizione che file con lo stesso nome sono simili (ma funziona bene anche se la supposizione è errata). L impacchettamento deve avvenire, però, periodicamente, per mantenere alta l efficienza; Il sistema effettua istantanee degli interi alberi delle directory, rifiutando di lavorare sui singoli file come i sistemi precedenti, che applicano la compressione delta; ciò comporta ovviamente rilevanti conseguenze: diventa più costoso esaminare la cronologia delle modifiche di un singolo file rispetto a quella dell intero progetto; i cambiamenti dei nomi di file e directory vengono gestiti in modo implicito invece che esplicito: ciò può essere visto come un vantaggio rispetto ai 29

30 sistemi come CVS, ma richiede più lavoro di CPU per analizzare la cronologia. 3.2 Progetti correlati Nella trattazione dei sistemi di controllo di versione, è doveroso citare i software correlati al versioning: TortoiseCVS, un front-end client per Windows che rende l uso di CVS più facile ed intuitivo; non include un server CVS, ma supporta la creazione di repository CVS locali, fornendo supporto anche per operazioni di alto livello; TortoiseSVN, un client grafico Subversion per Windows, integrabile anche con Microsoft Visual Studio; nel 2007 ha vinto il premio di sourceforge.net come strumento più utile per gli sviluppatori votato dalla comunità; TortoiseGIT, che allo stesso modo dei precedenti è implementato come shell grafica di GIT per Windows; GIT-gui, una GUI (Graphic User Interface) per le operazioni più comuni di GIT; tale progetto è incorporato in GIT dalla versione 1.5.0, e si può lanciare tramite il comando git gui; Subclipse, progetto che integra Subversion come plug-in Eclipse. In ultima analisi, citeremo strumenti che non sono propriamente per il controllo di versione, ma aiutano gli sviluppatori di software a collaborare: sourceforge.net, una delle prime e più diffuse piattaforme web per il supporto gratuito alla realizzazione collaborativa di software; essa è nativamente integrabile con CVS; Google code, alternativa moderna a sourceforge, offre supporto allo sviluppo e all integrazione del software con tutti gli strumenti Google; offre inoltre hosting gratuito con SVN, Mercurial, Github; Dropbox, software multipiattaforma gratuito cloud based che offre un servizio di file hosting e sincronizzazione automatica di file tramite web; si basa sul protocollo 30

31 crittografico SSL e i file immagazzinati vengono cifrati tramite AES. Molto utilizzato nel web, nel 2012 ha raggiunto i 100 milioni di utenti. SkyDrive, servizio commerciale offerto da Windows Live, consente agli utenti di utilizzare un hard disk virtuale di 7 GB. 31

32 Conclusioni Le tematiche succintamente analizzate nel seguente elaborato di tesi riguardano gli aspetti più rilevanti del Concurrent Versioning System e degli strumenti correlati ad esso. Anche se agli occhi di un lettore non esperto, la trattazione di tale aspetto della vita del software potrebbe apparire superflua rispetto ad altri step più considerevoli, come la stesura del codice stesso; tuttavia questa fase assume sempre più rilievo nella progettazione. Le motivazioni vanno ricercate principalmente nei costi effettivi che questo stadio, e più generale i processi riguardanti la revisione del software, possiedono nelle moderne aziende di software design, per le quali questi processi risultano essere sempre di più un punto focale. A tale premessa, per effettuare una riflessione completa, non possiamo esimerci dal tenere in considerazione l enorme diffusione del world wide web, in quanto esso, data la facilità di accesso, è divenuto di uso estremamente comune; ciò ha generato ovviamente una serie di conseguenze sia positive che negative. Se da un lato l offerta di sistemi e strumenti collegati al controllo di versione risulta così ampia, e per lo più open source, dall altro non è così inusuale imbattersi in progetti di basso profilo, ideati e prodotti da mani non esperte e titolate. Per cui, come accade anche in tanti altri campi, sarebbe preferibile affidarsi a sistemi accreditati e referenziati da sviluppatori esperti, che fruiscono di tali strumenti già da diversi anni, piuttosto che sperimentare strumenti improvvisati e dalle prestazioni incognite. 32

33 In ultima analisi, obbiettivo di tale elaborato è fornire una risposta mirata all interrogativo posto in apertura del terzo capitolo: Perché coesistono così tanti sistemi? Sono realmente necessari? ; e soprattutto, quesito che ci poniamo adesso: qual è il migliore? La risposta più adeguata a tale domanda è un ingegneristico dipende. Le argomentazioni a supporto di tale affermazione vanno ricercate essenzialmente non tanto nelle modalità di utilizzo, rese intuitive dalle interfacce grafiche che rendono tali sistemi sempre più userfriendly, ma nei bisogni che essi soddisfano presso l utente finale: in tale scenario, la varietà di strumenti utilizzabili rappresenta senza dubbio un vantaggio, in quanto in base al progetto da sviluppare collaborativamente, è possibile scegliere quello che si adatta maggiormente alle relative esigenze. Prediligere elevate prestazioni, piuttosto che stabilità del sistema o sicurezza/integrità dei dati possono essere le chiavi d accesso per una scelta oculata da parte dei fruitori. 33

34 Bibliografia [1] Ian Sommerville, 2005, Gestione della configurazione in Ingegneria del software, Edizione 7. [2] B. Collins-Sussman, B. Fitzpatrick, C. Pilato, 2005, Controllo di versione con Subversion per Subversion 1.2. [3] Per Cederqvist, Version Managment with CVS per CVS [4] Scott Chacon, 2009, Pro Git. [5] Charles Duan, 2010, Understandeing Git conceptually. 34

35 Sitografia https://code.google.com/p/tortoisegit; https://code.google.com/intl/it; https://www.dropbox.com; https://skydrive.live.com; 35

Gestione della configurazione del software

Gestione della configurazione del software Gestione della configurazione del software 1 Indice Concetti di gestione della configurazione Versione e Configurazione Memorizzazione delle versioni Baseline e Release Alcune pratiche consigliate 2 1

Dettagli

Tecnologie Open Source. Subversion

Tecnologie Open Source. Subversion Tecnologie Open Source Subversion Materiale di riferimento Version Control with Subversion Rilasciato sotto licenza CC all'indirizzo: http://svnbook.red-bean.com/ Pragmatic Version Control using Subversion

Dettagli

III.2 Come condividere risultati

III.2 Come condividere risultati III.2 Come condividere risultati Università di Ferrara Dipartimento di Economia e Management Insegnamento di Informatica Ottobre 6, 2015 Argomenti 1 Di cosa si tratta Tipologie 2 Ai fine del progetto Comandi

Dettagli

Gestione della Configurazione

Gestione della Configurazione Gestione della Configurazione - Ingegneria del Software 2 Gestione della Configurazione 1 Riferimenti Sommerville, Capitolo 29 - Ingegneria del Software 2 Gestione della Configurazione 2 1 Gestione della

Dettagli

Sistemi per il controllo versione del software (VCS)

Sistemi per il controllo versione del software (VCS) Sistemi per il controllo versione del software (VCS) dott. Fabio Calefato 1 Indice Concetti alla base del controllo versione Versione e Configurazione Memorizzazione delle versioni Baseline e Release Alcune

Dettagli

Software testing. Lezione 8 Configuration Management Federica Spiga federica_spiga@yahoo.it. A.A. 2010-2011 Autori: F.Spiga

Software testing. Lezione 8 Configuration Management Federica Spiga federica_spiga@yahoo.it. A.A. 2010-2011 Autori: F.Spiga 1 Software testing Lezione 8 Configuration Management Federica Spiga federica_spiga@yahoo.it A.A. 2010-2011 Autori: F.Spiga 2 Configuration Management Attività ausiliaria che abbraccia tutto il processo

Dettagli

Server Galileo. http://galileo.dmi.unict.it/

Server Galileo. http://galileo.dmi.unict.it/ Server Galileo http://galileo.dmi.unict.it/ Gestione progetti Wiki Subversion Iscrizione a Galileo Per registrarsi è sufficiente iscriversi da questa pagina: https://galileo.dmi.unict.it/iscrizioni/ L'account

Dettagli

SVN server, per Florim, è installato su server di test, anche se la sua configurazione può avvenire in qualsiasi ambiente.

SVN server, per Florim, è installato su server di test, anche se la sua configurazione può avvenire in qualsiasi ambiente. Siti FLORIM SVN Subversion Il sistema di versioning viene illustrato nell immagine seguente: Sistema locale dello sviluppatore, si parla di working copy ( copia dei file dal server in produzione) SVN server,

Dettagli

Ingegneria del Software - Il Ciclo Lungo

Ingegneria del Software - Il Ciclo Lungo Ingegneria del Software - Il Ciclo Lungo Alessandro Martinelli alessandro.martinelli@unipv.it 10 Marzo 2014 Il Ciclo Lungo Il Versioning e la Condivisione di Codice Organizzazione dei Pacchetti La Modellazione

Dettagli

Corso Git 2014. Riccardo Binetti me@rbino.com. 22 Ottobre 2014. Riccardo Binetti Corso Git 2014 22 Ottobre 2014 1 / 38

Corso Git 2014. Riccardo Binetti me@rbino.com. 22 Ottobre 2014. Riccardo Binetti Corso Git 2014 22 Ottobre 2014 1 / 38 Corso Git 2014 Riccardo Binetti me@rbino.com 22 Ottobre 2014 Riccardo Binetti Corso Git 2014 22 Ottobre 2014 1 / 38 Perché usare un VCS Questo codice funziona bene, però chissà se funzionerebbe se togliessi

Dettagli

Prova Finale Controllo delle versioni

Prova Finale Controllo delle versioni Prova Finale Controllo delle versioni 1 Controllo delle versioni: a cosa serve? Tenere traccia dei cambiamenti Semplificare la collaborazione Gestione di diverse diramazioni (branch) di sviluppo Differen3

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Programmazione Java Avanzata

Programmazione Java Avanzata Programmazione Java Avanzata Concetti di Java, parte 2 Ing. Giuseppe D'Aquì Testi Consigliati Java ( R. Liguori, P. Liguori), O'Reilly Hops Tecniche Nuove (2008) Java Tutorials [http://download.oracle.com/javase/tutorial/java/]

Dettagli

Iniziamo la panoramica sul funzionamento dell'svn sulla suite S.A.

Iniziamo la panoramica sul funzionamento dell'svn sulla suite S.A. Tutorial utilizzo SVN su piattaforma S.A. Uno dei requisiti principali dello sviluppo di progetti in Team è la necessità di avere uno spazio nel quale condividere il progetto con tutti i TeamMates. Subversion

Dettagli

Fabio Zanasi. 12 maggio 2010

Fabio Zanasi. 12 maggio 2010 Figura: 1 / 26 12 maggio 2010 Cos è? è un sistema di controllo delle versioni (version control system). è un software open-source per ambienti Unix, Windows, OS-X. è lo strumento ideale per gestire il

Dettagli

Alma Mater Studiorum Università di Bologna. Controllo di versione. S. Golovchenko (UNIBO) INGEGNERIA DEI SISTEMI SOFTWARE 2015 1 / 18

Alma Mater Studiorum Università di Bologna. Controllo di versione. S. Golovchenko (UNIBO) INGEGNERIA DEI SISTEMI SOFTWARE 2015 1 / 18 Alma Mater Studiorum Università di Bologna Controllo di versione 2015 S. Golovchenko (UNIBO) INGEGNERIA DEI SISTEMI SOFTWARE 2015 1 / 18 Sviluppo collaborativo Organizzazione del processo di sviluppo Per

Dettagli

Small Software Factories

Small Software Factories NEWITS SERVIZI PER LE NUOVE TECNOLOGIE DELL INFORMAZIONE Small Software Factories Sviluppare software in piccole realtà per grandi clienti Software Configuration Management 1 Software Configuration Management

Dettagli

Corso di Alfabetizzazione Informatica

Corso di Alfabetizzazione Informatica Corso di Alfabetizzazione Informatica Lezione 6 a.a. 2010/2011 Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono: diversi

Dettagli

Problema: Workflow per lo sviluppo su più piattaforme contemporaneamente, tipo java e android o java ed eclipse.

Problema: Workflow per lo sviluppo su più piattaforme contemporaneamente, tipo java e android o java ed eclipse. Problema: Workflow per lo sviluppo su più piattaforme contemporaneamente, tipo java e android o java ed eclipse. In questo scenario, lo sviluppatore deve rigenerare ad ogni modifica il file tuprolog.jar

Dettagli

Luca Ottaviano. Everyday Git

Luca Ottaviano. Everyday Git Luca Ottaviano Everyday Git Usare Git per lo sviluppo embedded Firenze, 24 settembre 2012 Chi sono Luca Ottaviano lottaviano@develer.com @lucaotta Sviluppatore su sistemi embedded presso Develer Qt certified

Dettagli

LABORATORIO DI TELEMATICA

LABORATORIO DI TELEMATICA LABORATORIO DI TELEMATICA COGNOME: Ronchi NOME: Valerio NUMERO MATRICOLA: 41210 CORSO DI LAUREA: Ingegneria Informatica TEMA: Analisi del protocollo FTP File Transfer Protocol File Transfer Protocol (FTP)

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

Pillole di Bazaar. user manual

Pillole di Bazaar. user manual Pillole di Bazaar user manual consolidata pubblica v.1.0 del 20 ott 2009 autori: luciano de falco alfano Sommario Sommario...1 Obiettivi e contesto...1 Un esempio di flusso di lavoro...2 Un po' di terminologia...3

Dettagli

Sistemi Operativi. Organizzazione logica ed implementazione di un File System

Sistemi Operativi. Organizzazione logica ed implementazione di un File System Modulo di Sistemi Operativi per il corso di Master RISS: Ricerca e Innovazione nelle Scienze della Salute Unisa, 17-26 Luglio 2012 Sistemi Operativi Organizzazione logica ed implementazione di un File

Dettagli

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato SCP: SCHEDULER LAYER a cura di Alberto Boccato PREMESSA: Negli ultimi tre anni la nostra scuola ha portato avanti un progetto al quale ho partecipato chiamato SCP (Scuola di Calcolo Parallelo). Di fatto

Dettagli

I Principali Servizi del Protocollo Applicativo

I Principali Servizi del Protocollo Applicativo 1 I Principali Servizi del Protocollo Applicativo Servizi offerti In questa lezione verranno esaminati i seguenti servizi: FTP DNS HTTP 2 3 File Transfer Protocol Il trasferimento di file consente la trasmissione

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Sistemi Operativi Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono:

Dettagli

White Paper 1. INTRODUZIONE...2 2. TECNOLOGIE SOFTWARE IMPIEGATE...2 3. APPROCCIO PROGETTUALE...10 3. RISULTATI...10

White Paper 1. INTRODUZIONE...2 2. TECNOLOGIE SOFTWARE IMPIEGATE...2 3. APPROCCIO PROGETTUALE...10 3. RISULTATI...10 Soluzioni software di EDM "Electronic Document Management" Gestione dell archiviazione, indicizzazione, consultazione e modifica dei documenti elettronici. Un approccio innovativo basato su tecnologie

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

APPENDICE 8 AL CAPITOLATO TECNICO. Strumenti, standard e modalità d uso per la gestione configurazione

APPENDICE 8 AL CAPITOLATO TECNICO. Strumenti, standard e modalità d uso per la gestione configurazione CONSIP S.p.A. APPENDICE 8 AL CAPITOLATO TECNICO Strumenti, standard e modalità d uso per la gestione configurazione Capitolato relativo all affidamento dei servizi di Sviluppo, Manutenzione e Gestione

Dettagli

Manuale LiveBox CLIENT DESKTOP (WINDOWS)

Manuale LiveBox CLIENT DESKTOP (WINDOWS) 2014 Manuale LiveBox CLIENT DESKTOP (WINDOWS) LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di

Dettagli

Gestione progetti. software. Ingegneria Informatica e dell'informazione. Michelangelo Diligenti. diligmic@dii.unisi.it

Gestione progetti. software. Ingegneria Informatica e dell'informazione. Michelangelo Diligenti. diligmic@dii.unisi.it Gestione progetti software Michelangelo Diligenti Ingegneria Informatica e dell'informazione diligmic@dii.unisi.it Sommario Cosa fare quando il progetto software diviene grande?.cc e.h Makefiles per gestire

Dettagli

Cos è GIOELCOTT. Modalità d uso del software

Cos è GIOELCOTT. Modalità d uso del software Giornale Elettronico dei Lavori e Gestione delle Planimetrie con l uso di Coni Ottici GIOELAV + GIOELCOTT (Versione 2.0.0) Cos è GIOELAV? E una piattaforma software, residente in cloud, per la registrazione

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Il Sistema Operativo Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela Fogli Cos

Dettagli

Gestione del database Gidas

Gestione del database Gidas Gestione del database Gidas Manuale utente Aggiornamento 20/06/2013 Cod. SWUM_00535_it Sommario 1. Introduzione... 3 2. Requisiti e creazione del Database Gidas... 3 2.1.1. SQL Server... 3 2.1.2. Requisiti

Dettagli

Subversion. Giovanni Lagorio lagorio@disi.unige.it

Subversion. Giovanni Lagorio lagorio@disi.unige.it Subversion Giovanni Lagorio lagorio@disi.unige.it Licenza Questi lucidi sono rilasciati sotto la licenza Creative Commons Attribuzione-Non commerciale-non opere derivate 3.0 Unported. Per leggere una copia

Dettagli

Laboratorio di Sistemi Operativi Progetto d Esame AA 2010/11

Laboratorio di Sistemi Operativi Progetto d Esame AA 2010/11 Laboratorio di Sistemi Operativi Progetto d Esame AA 2010/11 Versione 1.0 Corso di Laurea in Informatica Applicata Maggio 2011 1 Introduzione Oltre ad un compito scritto, che copre il modulo teorico, il

Dettagli

SISTEMI OPERATIVI. Realizzazione del file system. Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) (MODULO DI INFORMATICA II)

SISTEMI OPERATIVI. Realizzazione del file system. Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) (MODULO DI INFORMATICA II) SISTEMI OPERATIVI (MODULO DI INFORMATICA II) Realizzazione del file system Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) Università degli Studi di Bergamo a.a. 2012-13 Sommario Realizzazione

Dettagli

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

Dettagli

BASI DI DATI. Queste slides sono un adattamento di quelle di Luca Anselma e Gian Luca Pozzato, cui va il mio ringraziamento

BASI DI DATI. Queste slides sono un adattamento di quelle di Luca Anselma e Gian Luca Pozzato, cui va il mio ringraziamento BASI DI DATI Queste slides sono un adattamento di quelle di Luca Anselma e Gian Luca Pozzato, cui va il mio ringraziamento BASI DI DATI (DATABASE, DB) Una delle applicazioni informatiche più utilizzate,

Dettagli

Funzioni del Sistema Operativo

Funzioni del Sistema Operativo Il Software I componenti fisici del calcolatore (unità centrale e periferiche) costituiscono il cosiddetto Hardware (ferramenta). La struttura del calcolatore può essere schematizzata come una serie di

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

LBINT. http://www.liveboxcloud.com

LBINT. http://www.liveboxcloud.com 2014 LBINT http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

Dettagli

Capitolo 3: Strutture dei sistemi operativi

Capitolo 3: Strutture dei sistemi operativi Capitolo 3: Strutture dei sistemi operativi Componenti del sistema Servizi di un sistema operativo Chiamate del sistema Programmi di sistema Struttura del sistema Macchine virtuali Progettazione e realizzazione

Dettagli

Capitolo 1 Introduzione a Gambas

Capitolo 1 Introduzione a Gambas Capitolo 1 Introduzione a Gambas Gambas è stato creato inizialmente da Benoit Minisini, un residente della periferia di Parigi. Secondo Benoit, Gambas è un linguaggio Basic con estensioni per la programmazione

Dettagli

Università degli Studi di Verona. Linux Ubuntue ilcompilatorec. Dicembre 2014 - Sergio Marin Vargas. Dipartimento di Biotecnologie

Università degli Studi di Verona. Linux Ubuntue ilcompilatorec. Dicembre 2014 - Sergio Marin Vargas. Dipartimento di Biotecnologie Università degli Studi di Verona Dipartimento di Biotecnologie Laurea in Biotecnologie Corso di Informatica2014/2015 Linux Ubuntue ilcompilatorec Dicembre 2014 - Sergio Marin Vargas Caratteristiche di

Dettagli

Classificazione del software

Classificazione del software Classificazione del software Classificazione dei software Sulla base del loro utilizzo, i programmi si distinguono in: SOFTWARE Sistema operativo Software applicativo Sistema operativo: una definizione

Dettagli

2.1 Introduzione ai linguaggi di marcatura

2.1 Introduzione ai linguaggi di marcatura Fondamenti di Informatica Sistemi di Elaborazione delle Informazioni Informatica Applicata 2.1 Introduzione ai linguaggi di marcatura Antonella Poggi Anno Accademico 2012-2013 DIPARTIMENTO DI SCIENZE DOCUMENTARIE

Dettagli

INFIN OLTRE LA SEMPLICE ARCHIVIAZIONE

INFIN OLTRE LA SEMPLICE ARCHIVIAZIONE OLTRE LA SEMPLICE ARCHIVIAZIONE INFIN Ricezione, Acquisizione, Protocollazione, Classificazione, Condivisione, Distribuzione e Gestione dei processi documentali. I TUOI DOCUMENTI DIVENTANO INFORMAZIONI

Dettagli

Modalità d uso del software

Modalità d uso del software Giornale Elettronico dei Lavori e Gestione delle Planimetrie con l uso di Coni Ottici GIOELAV + GIOEMAP (Versione 2.0.1) Cos è GIOELAV? E una piattaforma software, residente in cloud, per la registrazione

Dettagli

Manuale LiveBox CLIENT DESKTOP (WINDOWS)

Manuale LiveBox CLIENT DESKTOP (WINDOWS) 2015 Manuale LiveBox CLIENT DESKTOP (WINDOWS) LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di

Dettagli

Il Provvedimento del Garante

Il Provvedimento del Garante Il Provvedimento del Garante Il provvedimento del Garante per la Protezione dei dati personali relativo agli Amministratori di Sistema (AdS) Misure e accorgimenti prescritti ai titolari dei trattamenti

Dettagli

Manuale LiveBox WEB AMMINISTRATORE DI SISTEMA. http://www.liveboxcloud.com

Manuale LiveBox WEB AMMINISTRATORE DI SISTEMA. http://www.liveboxcloud.com 2015 Manuale LiveBox WEB AMMINISTRATORE DI SISTEMA http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi

Dettagli

Web File System Manuale utente Ver. 1.0

Web File System Manuale utente Ver. 1.0 Web File System Manuale utente Ver. 1.0 Via Malavolti 31 41100 Modena Tel. 059-2551137 www.keposnet.com Fax 059-2558867 info@keposnet.com Il KDoc è un Web File System cioè un file system accessibile via

Dettagli

Gestione progetti software

Gestione progetti software Gestione progetti software Michelangelo Diligenti Ingegneria Informatica e dell'informazione diligmic@dii.unisi.it Sommario Cosa fare quando il progetto software diviene grande?.cc e.h Makefiles per gestire

Dettagli

Basic Standard Suite WEB. Contatto. fidelizzare

Basic Standard Suite WEB. Contatto. fidelizzare Basic Standard Suite WEB organizzare collaborazione Memorizzare Comunicare CONDIVISIONE QuALSIASI Contatto fidelizzare Dovunque Gestione ricerca Attività File è la soluzione software di nuova concezione

Dettagli

Sistema Operativo Chrome: Analisi degli aspetti peculiari.

Sistema Operativo Chrome: Analisi degli aspetti peculiari. tesi di laurea Sistema Operativo Chrome: Analisi degli aspetti peculiari. Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana candidato Lina Cocomello Matr. 534/000565 Obiettivi. Che cos

Dettagli

Il sistema operativo

Il sistema operativo Il sistema operativo Percorso di Preparazione agli Studi di Ingegneria Università degli Studi di Brescia Docente: Massimiliano Giacomin Cos è un Sistema Operativo? Per capirlo, immaginiamo inizialmente

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

C) supponendo che la scuola voglia collegarsi in modo sicuro con una sede remota, valutare le possibili soluzioni (non risolto)

C) supponendo che la scuola voglia collegarsi in modo sicuro con una sede remota, valutare le possibili soluzioni (non risolto) PROGETTO DI UNA SEMPLICE RETE Testo In una scuola media si vuole realizzare un laboratorio informatico con 12 stazioni di lavoro. Per tale scopo si decide di creare un unica rete locale che colleghi fra

Dettagli

APPENDICE B Le Active Server Page

APPENDICE B Le Active Server Page APPENDICE B Le Active Server Page B.1 Introduzione ad ASP La programmazione web è nata con la Common Gateway Interface. L interfaccia CGI tuttavia presenta dei limiti: ad esempio anche per semplici elaborazioni

Dettagli

Sistemi Distribuiti. Informatica B. Informatica B

Sistemi Distribuiti. Informatica B. Informatica B Sistemi Distribuiti Introduzione Che cos è un sistema distribuito? Un sistema distribuito è una collezione di computer indipendenti che appare all utente come un solo sistema coerente Da notare: le macchine

Dettagli

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000 VERITAS StorageCentral 1 USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000 1. Panoramica di StorageCentral...3 2. StorageCentral riduce il costo totale di proprietà per lo storage di Windows...3 3. Panoramica

Dettagli

Software. Algoritmo. Algoritmo INFORMATICA PER LE DISCIPLINE UMANISTICHE 2 (13042)

Software. Algoritmo. Algoritmo INFORMATICA PER LE DISCIPLINE UMANISTICHE 2 (13042) INFORMATICA PER LE DISCIPLINE UMANISTICHE 2 (13042) Gli elaboratori utilizzano memoria per Dati da elaborare Istruzioni eseguite dall elaboratore software differenti risoluzione problemi differenti Algoritmo

Dettagli

Software. Definizione, tipologie, progettazione

Software. Definizione, tipologie, progettazione Software Definizione, tipologie, progettazione Definizione di software Dopo l hardware analizziamo l altra componente fondamentale di un sistema di elaborazione. La macchina come insieme di componenti

Dettagli

DATA: 21-09-08 CLASSE: V a EL. TITOLO: ELABORAZIONE DEL SISTEMA OPERATIVO PER mp0

DATA: 21-09-08 CLASSE: V a EL. TITOLO: ELABORAZIONE DEL SISTEMA OPERATIVO PER mp0 DATA: 21-09-08 CLASSE: V a EL. TITOLO: ELABORAZIONE DEL SISTEMA OPERATIVO PER mp0 nelle lezioni precedenti abbiamo preso in esame tutte le caratteristiche e le funzionalità del microprocessore didattico

Dettagli

Corso di Web programming Modulo T3 A2 - Web server

Corso di Web programming Modulo T3 A2 - Web server Corso di Web programming Modulo T3 A2 - Web server 1 Prerequisiti Pagine statiche e dinamiche Pagine HTML Server e client Cenni ai database e all SQL 2 1 Introduzione In questa Unità si illustra il concetto

Dettagli

Università di Bologna CdS Laurea Magistrale in Ingegneria Informatica II Ciclo - A.A. 2010/2011 Corso di Sistemi Mobili M (6 cfu)

Università di Bologna CdS Laurea Magistrale in Ingegneria Informatica II Ciclo - A.A. 2010/2011 Corso di Sistemi Mobili M (6 cfu) Sistemi Mobili M Università di Bologna CdS Laurea Magistrale in Ingegneria Informatica II Ciclo - A.A. 2010/2011 Corso di Sistemi Mobili M (6 cfu) 08 Cenni di Sincronizzazione Dati e SyncML Docente: Paolo

Dettagli

Parte II: Reti di calcolatori Lezione 9

Parte II: Reti di calcolatori Lezione 9 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 9 Martedì 1-04-2014 1 Applicazioni P2P

Dettagli

Istruzioni di installazione di IBM SPSS Modeler Server 15per Windows

Istruzioni di installazione di IBM SPSS Modeler Server 15per Windows Istruzioni di installazione di IBM SPSS Modeler Server 15per Windows IBM SPSS Modeler Server può essere installato e configurato per l esecuzione in modalità di analisi distribuita insieme ad altre installazioni

Dettagli

Documento di Presentazione

Documento di Presentazione Pag. 1 di 42 Documento di Presentazione SOMMARIO LE CARATTERISTICHE GENERALI DI ULISSEWEB 1 Obiettivo 1 1.1 Le procedure di Ulisse 1 1.2 L accesso a Ulisse 2 1.3 La definizione degli account utente 2 1.4

Dettagli

Utilizzo Gestione dei file

Utilizzo Gestione dei file Utilizzo Gestione dei file Info su questo bollettino tecnico L'intento di questo bollettino tecnico è di aiutare gli sviluppatori FileMaker esperti a comprendere meglio e ad applicare le migliori metodologie

Dettagli

Introduzione al sistema operativo. Laboratorio Software 2008-2009 C. Brandolese

Introduzione al sistema operativo. Laboratorio Software 2008-2009 C. Brandolese Introduzione al sistema operativo Laboratorio Software 2008-2009 C. Brandolese Che cos è un sistema operativo Alcuni anni fa un sistema operativo era definito come: Il software necessario a controllare

Dettagli

2. Strutture dei Sistemi Operativi

2. Strutture dei Sistemi Operativi 1 2. Strutture dei Sistemi Operativi Quali servizi un generico sistema operativo mette a disposizione degli utenti, e dei programmi che gli utenti vogliono eseguire? interfaccia col sistema operativo stesso

Dettagli

Fondamenti di Informatica

Fondamenti di Informatica Fondamenti di Informatica Il software Dipartimento di Ingegneria dell Informazione Universitàdegli Studi di Parma SOFTWARE I componenti fisici del calcolatore (unità centrale e periferiche) costituiscono

Dettagli

Sistema di spedizione per azienda logistica LBDS

Sistema di spedizione per azienda logistica LBDS CONFIGURATION MANAGEMENT PLAN Sistema di spedizione per azienda logistica LBDS Gruppo Laboratorio di Ingegneria del Software 2 Anno Accademico2009/2010 Gruppo Kairos: Maiero Matteo, Bertoni Alan, Zolli

Dettagli

Il sistema operativo Linux installato sul vostro computer non è un unico, grande

Il sistema operativo Linux installato sul vostro computer non è un unico, grande CAPITOLO 2 Scegliere una distribuzione di Linux Il sistema operativo Linux installato sul vostro computer non è un unico, grande programma, ma un insieme di molti programmi. Potete ottenere autonomamente

Dettagli

Il Livello delle Applicazioni

Il Livello delle Applicazioni Il Livello delle Applicazioni Il livello Applicazione Nello stack protocollare TCP/IP il livello Applicazione corrisponde agli ultimi tre livelli dello stack OSI. Il livello Applicazione supporta le applicazioni

Dettagli

Implementazione del File System

Implementazione del File System Implementazione del file system Implementazione del File System Struttura del file system. Realizzazione del file system. Implementazione delle directory. Metodi di allocazione. Gestione dello spazio libero.

Dettagli

Valutazione della piattaforma di storage multiprotocollo EMC Celerra NS20

Valutazione della piattaforma di storage multiprotocollo EMC Celerra NS20 Valutazione della piattaforma di storage multiprotocollo EMC Celerra NS20 Resoconto commissionato da EMC Corporation Introduzione In breve EMC Corporation ha incaricato Demartek di eseguire una valutazione

Dettagli

Tecnologie Web per lo sviluppo software. Stefano Parmesan WebValley 2010 Transacqua (TN) Italy

Tecnologie Web per lo sviluppo software. Stefano Parmesan WebValley 2010 Transacqua (TN) Italy Tecnologie Web per lo sviluppo software Stefano Parmesan WebValley 2010 Transacqua (TN) Italy 1 Tecnologie Web per lo sviluppo software Grande fermento nel Web: Pubblicazione e Informazione (blog, wiki,...);

Dettagli

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router Rete di reti (interrete, internet) 2 Prof. Roberto De Prisco TEORIA - Lezione 8 Rete di reti e Internet Università degli studi di Salerno Laurea e Diploma in Informatica Una rete di comunicazione è un

Dettagli

Ministero dell Istruzione dell Università e della Ricerca M070 ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE

Ministero dell Istruzione dell Università e della Ricerca M070 ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE Pag. 1/1 Sessione ordinaria 2010 Seconda prova scritta Ministero dell Istruzione dell Università e della Ricerca M070 ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE CORSO DI ORDINAMENTO Indirizzo: INFORMATICA

Dettagli

Reti di Calcolatori PROTOCOLLO FTP. File. File Transfer Protocol Modello FTP Operazioni FTP Comandi del protocollo Esempi di Client FTP avanzati

Reti di Calcolatori PROTOCOLLO FTP. File. File Transfer Protocol Modello FTP Operazioni FTP Comandi del protocollo Esempi di Client FTP avanzati Reti di Calcolatori PROTOCOLLO FTP D. Talia RETI DI CALCOLATORI - UNICAL 8-1 File Modello FTP Operazioni FTP Comandi del protocollo Esempi di Client FTP avanzati D. Talia RETI DI CALCOLATORI - UNICAL 8-2

Dettagli

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema Introduzione File System Distribuito

Dettagli

File System Distribuiti

File System Distribuiti File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema 20.1 Introduzione File System Distribuito

Dettagli

Guida all uso di Mozilla Thunderbird

Guida all uso di Mozilla Thunderbird Mailconnect Mail.2 L EVOLUZIONE DELLA POSTA ELETTRONICA Guida all uso di Mozilla Thunderbird in unione alle soluzioni Mailconnect/Mail.2 PERCHÉ USARE MOZILLA THUNDERBIRD DOWNLOAD E CONFIGURAZIONE GENERALE

Dettagli

Database. Si ringrazia Marco Bertini per le slides

Database. Si ringrazia Marco Bertini per le slides Database Si ringrazia Marco Bertini per le slides Obiettivo Concetti base dati e informazioni cos è un database terminologia Modelli organizzativi flat file database relazionali Principi e linee guida

Dettagli

Manuale di riferimento di HP Web Jetadmin Database Connector Plug-in

Manuale di riferimento di HP Web Jetadmin Database Connector Plug-in Manuale di riferimento di HP Web Jetadmin Database Connector Plug-in Informazioni sul copyright 2004 Copyright Hewlett-Packard Development Company, L.P. Sono vietati la riproduzione, l'adattamento e la

Dettagli

Articolo di spiegazione FileMaker Replica di un ambiente di autenticazione esterna per lo sviluppo

Articolo di spiegazione FileMaker Replica di un ambiente di autenticazione esterna per lo sviluppo Articolo di spiegazione FileMaker Replica di un ambiente di autenticazione esterna per lo sviluppo Pagina 1 Replica di un ambiente di autenticazione esterna per lo sviluppo La sfida Replicare un ambiente

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

Reti di Calcolatori PROTOCOLLO FTP

Reti di Calcolatori PROTOCOLLO FTP Reti di Calcolatori PROTOCOLLO FTP D. Talia RETI DI CALCOLATORI - UNICAL 8-1 File File Transfer Protocol Modello FTP Operazioni FTP Comandi del protocollo Esempi di Client FTP avanzati D. Talia RETI DI

Dettagli

MySQL Controllare gli accessi alla base di dati A cura di Silvio Bonechi per http://www.pctrio.com

MySQL Controllare gli accessi alla base di dati A cura di Silvio Bonechi per http://www.pctrio.com MySQL Controllare gli accessi alla base di dati A cura di Silvio Bonechi per http://www.pctrio.com 15.03.2006 Ver. 1.0 Scarica la versione pdf ( MBytes) Nessuno si spaventi! Non voglio fare né un manuale

Dettagli

Manuale accesso a B.Point SaaS

Manuale accesso a B.Point SaaS Manuale accesso a B.Point SaaS Manuale utente INDICE: 1. Introduzione... 1-3 2. Tipi di client... 2-4 Premessa... 2-4 Peculiarità e compatibilità con i browser... 2-4 Configurazione del tipo di Client...

Dettagli

Informazioni generali sul corso

Informazioni generali sul corso abaroni@yahoo.com Informazioni generali sul corso Introduzione a BusinessObjects Enterprise XI - Release 2 Chi sono. Io? Adolfo Baroni E-mail: abaroni@yahoo.com 2 Pagina 1 Obiettivi del corso hamministrazione

Dettagli

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

Strumenti per la gestione della configurazione del software

Strumenti per la gestione della configurazione del software tesi di laurea Anno Accademico 2005/2006 relatore Ch.mo prof. Porfirio Tramontana correlatore Ch.mo ing. Luigi Suarato candidato Pasquale Palumbo Matr. 534/000021 MANUTENZIONE DEL SOFTWARE Il Configuration

Dettagli

Manuale Utente CryptoClient

Manuale Utente CryptoClient Codice Documento: CERTMOB1.TT.DPMU12005.01 Firma Sicura Mobile Telecom Italia Trust Technologies S.r.l. - Documento Pubblico Tutti i diritti riservati Indice degli argomenti... 1 Firma Sicura Mobile...

Dettagli

Piattaforma Applicativa Gestionale. Certificazione ad hoc REVOLUTION su sistema operativo Microsoft Windows 7

Piattaforma Applicativa Gestionale. Certificazione ad hoc REVOLUTION su sistema operativo Microsoft Windows 7 Piattaforma Applicativa Gestionale Certificazione ad hoc REVOLUTION su sistema operativo Microsoft Windows 7 D O C U M E N T A Z I O N E F A S T P A T C H - A D H O C R E V O L U T I O N COPYRIGHT 2000-2010

Dettagli

Software e Sistemi Operativi Prof. Maurizio Naldi A.A. 2015/16

Software e Sistemi Operativi Prof. Maurizio Naldi A.A. 2015/16 Software e Sistemi Operativi Prof. Maurizio Naldi A.A. 2015/16 Cosa vedremo Il software applicativo Categorie di SW Il sistema operativo Gestione programmi in esecuzione (processi) Gestione memoria Gestione

Dettagli