Subversion non è particolarmente schizzinoso relativamente al tipo di dati di cui si deve occupare. Altri sistemi di controllo dei sorgenti possono essere più specifici, ad esempio essere dedicati a un determinato linguaggio di programmazione e includere magari anche un debugger o un compilatore automatico; Subversion non è così.
Qualunque server Subversion può ospitare contemporaneamente sorgenti PHP e HTML, ma anche normale documentazione, guide, articoli, e perfino immagini, brani musicali, e qualsiasi altro file vi venga in mente. Potremmo utilizzarlo anche per salvare le nostre macchine virtuali.
L'unica importante distinzione è tra i file di tipo mergeable e binari. I primi sono sostanzialmente file di testo, in cui le diverse modifiche provenienti da diversi autori possono essere valutate e unite riga per riga, come spiegheremo più avanti. Gli altri file, invece, vengono considerati da Subversion come "monoblocco" e verranno sempre sostituiti interamente (stiamo parlando ad esempio di immagini o brani musicali). In questo secondo caso perdiamo la possibilità di unire le modifiche fatte da diversi utenti, ma rimane valido il controllo di versione vero e proprio, cioè la conservazione automatica e il rapido accesso alle versioni precedenti.
Detto tutto questo, non cadiamo nell'errore di considerare Subversion un semplice sistema di archiviazione e distribuzione. Il suo obiettivo principale è quello di gestire i cambiamenti nel tempo, tenendo a portata di mano una copia di ciascuna versione e dandoci la possibilità di tracciare chi e quando ha introdotto certe modifiche.
Modelli di versionamento
Molti sistemi di controllo dei sorgenti adottano la tecnica Lock-Modify-Unlock, che io ho ribattezzato tecnica "della Biblioteca": ogni volta che qualcuno vuole modificare un file deve ritirarlo, come se prendesse a prestito un libro, e gli altri programmatori non hanno più alcuna possibilità di accesso al file; dovranno aspettare che il primo utente completi le modifiche e riconsegni il file.
L'esperienza ha suggerito invece agli sviluppatori di CVS – e di conseguenza anche di Subversion – di adottare la soluzione Copy-Modify-Merge: i file non vengono bloccati dal primo che li apre, ma rimangono disponibili per chiunque.
Questa soluzione si basa sull'idea che quando persone diverse stanno lavorando sullo stesso file, solitamente stanno affrontando problematiche diverse e quindi devono modificare parti diverse del file.
Quindi, Subversion ci lascia lavorare contemporaneamente sui file, e al momento del commit (l'invio al server dei file modificati) tenta di unire le diverse modifiche, controllando la presenza di eventuali conflitti (modifiche che si sovrascrivono). Se ne trova, blocca il salvataggio, avverte lo sviluppatore, e – come vedremo – offre degli strumenti per identificare e risolvere rapidamente tali conflitti.
Come si può intuire, la soluzione Copy-Modify-Merge si applica solo ai file di tipo mergeable. Negli altri casi, ad esempio un'immagine, la modifica contemporanea non ha senso in quanto si risolverebbe sempre in un conflitto e una delle due versioni andrebbe comunque buttata via.
Per evitare questo, Subversion ci consente di usare anche il modello Lock-Modify-Unlock; dobbiamo però forzarlo noi, attraverso l'utilizzo di un comando apposito.
