Software di controllo di revisione

Introduzione: perché serve un tool di controllo di revisione

Spesso a tali tool sono affiancati dei software di bug tracking, in grado cioè di raccogliere i bug trovati dagli utenti, elencarli, ordinarli per priorità eccetera. Un buon esempio di tali tool è Bugzilla^[8].

Un buon software di controllo di revisione deve anche essere in grado di risolvere i conflitti che nascono quando più sviluppatori (li chiameremo "Bill" Jobs e "Steve" Gates) modificano lo stesso codice, per adattarlo ad esigenze differenti. In generale ogni sviluppatore ha una sua "copia di lavoro" e un repository da cui prende i file che deve alterare (checkout) e inserisce versioni funzionanti (checkin) annotando quello che ha fatto.

Un aspetto importante e non trascurabile di tali strumenti è il supporto di tool visuali.
Infatti mentre un compilatore senza un ambiente visuale può essere ugualmente produttivo, un tool di controllo di revisione che non riesca a esprimere in modo grafico la complessità e le iterazioni tra le varie versioni di un progetto rende più difficile capire quali azioni intraprendere in caso di conflitti, soprattutto se il numero di sviluppatori è maggiore di due o tre.

Tool Open Source

CVS

Derivato da RCS, ne condivide i punti di debolezza, tra cui il fatto che gira male sotto Windows: la cygnus ha fatto il porting, ma per usarlo in modo distribuito è necessaria una macchina unix.

CVS è in grado di supportare in modo efficace i branch ("diramazioni" di sviluppo rispetto alle revisioni principali) e di eseguire complesse operazioni.

Per esempio è possibile estrarre il branch "Versione-Veloce" per la sottodirectory src/ottimizzato e l'ultima versione stabile su src/funzionoNonToccarmi.

Il fatto che possa eseguire l'aggiornamento dei soli file modificati lo rende ideale per chi dispone di lente connessioni (es via modem).

Il database di CVS è file based, la qual cosa comporta:

• CVS è intrusivo perché crea le famose directory "CVS" nella vostra copia di lavoro. Questa caratteristica è condivisa con quasi tutti i tool che esamineremo, e anche se non dà troppo fastidio va annotata.
• Se il database si corrompe, con un minimo di perizia è facile risolvere problemi (per esempio dei lock che non scadono). Parimenti è facile creare tool che si integrino con CVS, e quasi tutti gli IDE free e commerciali lo supportano nativamente o tramite plug-ins.
• La velocità non è il suo forte. Solo per sapere quali file sono stati modificati nella vostra copia di lavoro, preparatevi a delle attese.
• La semantica di lock è debolissima, non si possono fare checkout veramente riservati.
  Per la stessa ragione CVS non è atomico: cioè se "Bill" sta mettendo in checkin i file 1,2,3 e qualche millesimo di secondo dopo "Steve" esegue un update e il checkin del file 4, non vi è garanzia che Steve riceva TUTTI gli aggiornamenti: potrebbe ricevere solo i nuovi file 1,3. Allo stesso modo Bill potrebbe ricevere come non ricevere l'aggiornamento del file 4.
• CVS non versiona le directory, perché implementativamente le directory sono i suoi "database modules" e i loro nomi sono sono belli cablati nel repository.

1. Non è possibile cambiare il nome di un file. Per esempio se voglio spostare la revisione 3 di src/org/siforge/SmartSync.java in src/org/siforge/sm/SmartSync.java.
   La "geniale" soluzione di CVS consiste nel cancellare il primo file e creare il secondo. Il repository così registra che dalla data corrente non esiste più la revisione 3 di src/org/siforge/SmartSync.java ed è stato aggiunto un file diverso di nome src/org/siforge/sm/SmartSync.java con revisione 1.

   Registrare in modo sicuro che si tratta dello stesso file è impossibile: bisogna usare i commenti, e questo è scomodo.
   La soluzione corretta sarebbe quella di versionare le direcory src/org/siforge/ e src/org/siforge/sm/ registrando lo spostamento dell'oggetto SmartSync.java, che continua ad avere la sua revision history.

2. Cambiare il nome di una directory è ancora più tragico. Se si vuole spostare la directory src/ContengoMilleFileInMilleDirectory/ in src/modulo/ContengoMilleFileInMilleDirectory/ dovete farlo a mano ... spostando i singoli file come nel precedente punto (1).
   Si capisce che tale cosa diventa inapplicabile per progetti di medie dimensioni o con un vettore del cambiamento molto elevato sviluppati con metodologie "agili" come eXtreme Programming.

SubVersion

Risolve molti dei limiti di CVS ed inoltre:

• Il repository è un vero database.
• Supporta anche un interfaccia remota basata su WebDav.
• Permette di aggiungere proprietà ai singoli files.
• È pensato per una rapida transizione per chi conosce CVS: La sintassi dei comandi è molto simile a quella di CVS, e il team è conscio del fatto che dovrà costruire dei tool per consentire la migrazione da CVS.

	
/truck/projectA
/truck/projectB

/branches/projectA
/branches/projectB

/tags/projectA
/tags/projectB

svn cp http://repository/rep/truck/projectA http://repository/rep/tags/projectA/BETA1_5

Poiché il progetto è ancora in una fase iniziale, non è molto usato, promette bene anche se è un po' lento.
Non re-inventa la ruota ma si poggia su protocolli preesistenti per funzionare.

Tool Commerciali

BitKeeper

La sua adozione da parte di Linus Torvald per sviluppare il kernel Linux ha sollevato una polemica^[5] nel mondo GNU/Open Source.

È un tool che può funzionare in modo distribuito, e questo è il suo punto di forza.

Cerchiamo di descrivere in breve la licenza: è possibile comperare BitKeeper, oppure usarlo liberamente.
In quest'ultimo caso sono possibili due scelte:

• Single User con meno di 1000 file
• OpenLogging

Con l'OpenLogging invece non ci sono restrizioni di sorta, ma si legge:

[...]
DESCRIPTION
    Open  Logging  is the sending of metadata information to a
    centralized,  public   web   server   (http://www.openlog-
    ging.org), where it is sorted by project, date, and domain
    name,  and  published  so  that  others  may  follow  your
    progress.
[...]
WHAT IS SENT?
 => The ChangeSet file (comments and contents).
 => The  messages  which annotate modifications of the data
    (also known as check in  comments,  ChangeLog  entries,
    and/or log messages)
 => All  files  contained in the top level BitKeeper direc-
    tory in  a BitKeeper  repository,  in   particular  the
    BitKeeper/html  directory  and the BitKeeper/etc/config
    and BitKeeper/etc/logging_ok files.

WHAT IS NOT SENT?
    Your source code or other data managed by BitKeeper.

    Read that part again.  People frequently think  that  Open
    Logging means publishing their source code, but that isn't
    the case.
[...]

[One] reason is financial. BitKeeper has a dual use
model which allows both commercial and non-paying cus-
tomers to use the same software. Our goal is that the
Open Source community can use BitKeeper by paying a small
amount of privacy but no money, and that commercial cus-
tomers can use BitKeeper by paying money and keeping their
privacy. Open Logging is how this accomplished.

BitKeeper è disponibile per moltissime piattaforme (Unix, Windows, ecc) e supporta una debole integrazione con la shell di Windows.

Trattandosi di un prodotto commerciale si deve notare che non dispone di tool visuali molto ben integrati (si serve del Tcl/Tk per funzionare) anche se alla lunga possono risultare migliori di quelli di Visual Source Safe.

Non ha gli svantaggi di CVS, e sicuramente ne condivide molti dei pregi ma non è ne' carne ne' pesce: da una parte non si vede la necessità di comperarlo, perché lo si può usare gratis. Dall'altra gli sviluppatori open source sono allergici ad usarlo perché sentono violata la loro privacy.

ClearCase

Per ospitare il repository un server unix è la scelta più indicata perché è più stabile e sicuro.

La documentazione è ben fatta e compatta, considerando che il tool è notevolmente complesso.

ClearCase dispone di una ottima implementazione delle viste dinamiche, che gli consente di non soffrire in efficienza, purché lo si usi su una LAN ad almeno 10Mbit.

I punti deboli di ClearCase sono sostanzialmente due:

Visual Source Safe

Un grave difetto è l'assenza del supporto per branch paralleli.
Ciò che può fare è congelare una versione e permettere di partire con un nuovo "branch", ma non potendo lavorare su entrambi in parallelo. Ovvero, fare coesistere una "stable" e "developer" release su VSS è praticamente impossibile.
Si ricorda che tali funzionalità sono supportate anche dal "modesto" e gratuito CVS.

I tool visuali sono ridotti all'osso e il tool di linea di comando non ha la stessa potenza degli altri prodotti analizzati.

Generare un report automatico o integrare un tool di bug tracking è impossibile.

Sicuramente non è stato usato per sviluppare Windows95 (che aveva uno zoccolo duro di 500 programmatori sparsi per il pianeta).

Conclusioni: cosa scegliere

Una volta scelto un prodotto, è bene che esso sia usato per tutti i progetti, in modo da incoraggiare il riuso e l'integrazione del codice all'interno della stessa azienda.

In alcuni progetti può esservi la necessità di sincronizzare l'operato di sviluppatori distanti, disponendo solo di lente connessioni internet (es Modem/ADSL): in tal caso ClearCase/Visual Source Safe non sono la scelta ottimale; CVS e BitKeeper si comportano sicuramente meglio.

D'altronde se il progetto ha un team dinamico, per esempio con 8-10 sviluppatori ad alto skill e tempi stretti, giocare al piccolo "merge-man" con CVS è sconsigliato: ClearCase in quel caso può essere un ottimo investimento.

Volendo fare uno specchietto riassuntivo:

Informazioni sull'autore

Giovanni Giorgi, classe 1974. Dopo il diploma di liceo Classico, si è laureato in Informatica nel febbraio 2000, e attualmente lavora nel campo del software finanziario (trading on line, soluzioni web).
Appassionato di linguaggi di programmazione, si interessa anche di politica e letteratura.

È possibile consultare l'elenco degli articoli scritti da Giovanni Giorgi.

Altri articoli sul tema Tools di sviluppo.

Risorse

1. Sito ufficiale di CVS
   http://www.cvshome.org/
2. Il sito ufficiale di SubVersion.
   http://subersion.tigris.org
3. SubVersion è adatto al mio progetto? Pur essendo un software in "alfa" viene usato per ospiare se stesso ... cioè il repository di SubVersion è ospitato da SubVersion. A questo link trovate una serie di considerazioni su tale tool.
   http://subversion.tigris.org/project_faq.html#stable
4. BitKeeper si prende il disturbo di confrontarsi con gli altri tool: ma non credete che sia tutto oro colato!
   http://www.bitkeeper.com/Products.Comparisons.CVS.html
5. In questa notizia di Slashdot si rimanda a due articoli presentati su KernelTrap a fine maggio 2002, e che fanno riferimento ad una polemica tra Eric Raymond (cavaliere del GPL) e Linus riguardo la scelta di BitKeeper come sistema di controllo di revisione per Linux.
   http://developers.slashdot.org/article.pl?sid=02/05/28/1341229&mode=nocomment&tid=106
6. Lista dei prodotti ClearCase di Rational
   http://www.rational.com/products/clearcase/index.jsp
7. Il tutorial illustra l'uso di CVS ma è una buona introduzione anche per chi non sa cosa sia un tool di controllo di revisione e voglia averne un'idea rapida.
   http://www.cvshome.org/docs/manual/cvs_1.html#SEC1
8. Bugzilla è un tool per la raccolta e la gestione dei bugs. Testato sul complesso (e quindi tendenzialmente prone ai bachi) Mozilla, si dimostra flessibile e efficace.
   http://www.mozilla.org/projects/bugzilla/