Tutti i pezzi APPosto

Oggi vi parlo di Concurrent Versions System (CVS) o semplicemente controllo di versione, ovvero come gli sviluppatori si aiutano a lavorare sullo stesso progetto software contemporaneamente e senza pestarsi i piedi.

Attenzione, non sto parlando del software CVS che è soltanto uno dei tool in questo ambito, ma più generalmente di quei software (o meglio di quel mix di software e procedure) che aiutano a mantenere la cronologia del progetto e complessivamente l’ordine all’interno della giungla.

È davvero necessario? No, non strettamente ed è infatti possibile farne a meno sompiattando la tecnologia con una serie organizzata di backup, di finezze per la revisione del codice, di metodologie per il tracciamento degli avanzamenti e delle differenze, di una predisposizione all’organizzazione, al gioco di squadra ed alla condivisione delle informazioni. Se tutto questo è facile per voi fate pure, personalmente mi fermo già alla prima virgola.

Come funzionano

Ne esistono tanti e diversi (centralizzato/decentralizzato sono le due grandi famiglie), pertanto è necessario semplificare. Tutti sono composti da – o ricoprono nel tempo il ruolo di – un client ed un server. Ecco come funzionerebbero in un contesto classico:

1. i partecipanti al progetto accedono al servizio su un server. Alcuni lavorano su protocolli noti (HTTP, SSH), altri su protocolli proprietari;
2. essi scaricano tramite il servizio una copia totale o parziale dello storico del progetto in locale, generalmente all’interno in una cartella a scelta su disco;
3. i partecipanti modificano il progetto cambiando, aggiungendo o rimuovendo un qualsiasi contenuto all’interno della cartella;
4. il sistema CVS traccia file per file le differenza tra l’ultima modifica tracciata (snapshot) e le modifiche apportate;
5. l’utente decide quali file – aggiunti, cancellati o modificati – proporre al sistema come proposta di modifica del progetto;
6. l’utente crea un nuovo snapshot; il CVS ne associa l’username del creatore, un timestamp ed un identificativo univoco;
7. l’utente decide se inviare subito questo snapshot ad un server oppure se inviarne più snapshot alla volta, ovvero dilazionati nel tempo.

Che cosa può succedere di preoccupante durante questa prassi? Principalmente collisioni sulle modifiche. Questo avviene quando, a partire dallo stesso snapshot, due sviluppatori hanno sottoposto al sistema delle modifiche che non sono compatibili tra loro, cioè quando una fusione dei due file non è banale .

È molto semplice da comprendere: stiamo preparando la pasta, siamo in due a farlo, ma nessuno dei due è sempre presente per vedere il comportamento dell’altro. Sarà necessario che uno dei due, vedendo bollire l’acqua, chieda Hai già messo il sale? a meno che preferisca scottarsi.

Se la nostra pentola-server fosse provvista di un sistema CVS, il cuoco Antonino potrebbe provare a proporre la modifica immissione di sale e la pentola potrebbe rispondere:

• nessuno snapshot posteriore all’ultimo, OK! sale immesso ed accettato;
• attenzione, l’acqua è già stata salata da Benedetta in un momento seguente all’ultimo snapshot da te scaricato; vuoi scaricare gli ultimi snapshot prima di riprovare?

Così facendo non si rischierà mai una pasta insipida o doppiamente salata, a meno di deliberata intenzione.

Quali sistemi esistono

Ne abbiamo decine tra cui scegliere, ma quelli che più di tutti – per ragioni storiche o pratiche – permeano i progetti open source reperibili in rete sono:

• CVS
• Subversion
• GIT
• Mercurial
• Bazaar

Quale sistema di controllo versioni preferire dipende strettamente dalla natura del progetto, dalle macchine utilizzate e dalle necessità di utilizzo. La mia preferenza non deve influenzarvi:

Su quale sia il miglior controllo di versione da adottare, c’è chi nutre zero dubbi.

Questo è un inizio. Ci sono tanti altri argomenti inerenti ai CVS che varrebbe la pena porre al setaccio, come:

• differenza tra la gestione di codice sorgente e risorse (per esempio immagini, audio/video eccetera);
• tracciamento, valutazione ed approvazione delle modifiche;
• numerazione e tagging degli snapshot in ottica di rilascio;
• continuous integration ovvero supporto alla condivisione dei workspace;
• test automatici ovvero collaudo e valutazione automatica degli invii.

Li tratterò in un prossimo articolo.