Storia

Il Configuration Management nasce negli anni ’50 nell’ambito dell’industria aerospaziale. Alla fine degli anni ’70 inizia ad essere applicato all’ingegneria del software.

L’SCM consiste in delle pratiche che hanno l’obiettivo di rendere sistematico il processo di sviluppo tenendo traccia dei cambiamenti in modo che il podotto sia in ogni istante in uno stato (configurazione) ben definito.

Dunque l’SMC ci permette di controllare le revisioni degli artifact e il risultato di tali revisioni, questo processo è molto utile per la generazione di un prodotto a partire da una configurazione ben determinata.

Manufatti

Gli “oggetti” di cui si controlla l’evoluzione sono detti configuration item o manufatti; generalmente sono file. Se si cambia nome a un file è come eliminarne uno e partire da zero con uno nuovo. Originariamente i tool tracciavano i file indipendentemente, senza un senso logico (una configurazione) comune.

• anni ’80: strumenti locali (SCCS, …)
• anni ’90: strumenti client-server centralizzati (CVS, subversion, …)
• anni ’00: strumenti distribuiti peer-to-peer (git, mercurial, bazaar, …)

git nasce da un’esigenza di Linus Torvalds con il kernel Linux.

Centralizzato vs decentralizzato

Il mondo open source preferisce un approccio decentralizzato al version control. Perché?

• è possibile lavorare offline;
• è molto più veloce, perché la rete non fa più da bottleneck;
• supporta diversi modi di lavorare:
  • simil centralizzato: un repository viene considerato “di riferimento”;
  • due peer che collaborano direttamente;
  • gerarchico a più livelli (kernel Linux).

Non c’è sincronizzazione automatica, ma ci sono comandi espliciti per fare merge tra repository remote. In git, per via della sua struttura modulare, è possibile utilizzare il proprio algoritmo merge rispetto a quelli già inclusi.