Subversion 1.5: una ventata di freschezza

Il rilascio della nuova versione di Subversion, la scorsa settimana, è passato quasi inosservato se si considera il numero di utenti del più famoso software per la gestione del codice e delle revisioni.
Eppure Subversion 1.5 è tutt'altro che una semplice mini-release e le sue novità  contribuiranno certamente a prolungare la vita di questo software che, nonostante succulente alternative, è ancora lontano dalla fine che è toccata al predecessore CSV... se mai quel giorno arriverà .

La nuova release, infatti, porta un tocco di freschezza a Subversion come non accadeva da molto tempo, almeno un paio d'anni. Una tra le novità  più importanti, forse proprio la più importante, è sostanziale rinnovamento nella gestione delle branch.
Da sempre sistemi distribuiti come Mercurial e GIT hanno vantato una maggiore flessibilità  in questo campo rispetto al concorrente, offrendo un supporto allo sviluppo di versioni parallelo molto più efficace.

Subversion 1.5 colma molte delle lacune del predecessore introducendo:

• Repeated Merge: l'abilità  di eseguire ripetutamente il merge del ramo A nel ramo B. Subversion 1.5 si preoccupa di mantenere uno storico dei cambiamenti applicati per evitare di rieseguire accidentalmente il merge di changeset già  integrati, con risultati spesso completamente imprevedibili.
• Cherry Picking: l'abilità  di eseguire il merge dal ramo A nel ramo B (e viceversa) di singoli commit. Ancora una volta, Subversion si preoccuperò  di mantenere traccia di quali changeset sono già  stati applicati per prevenire incongruenze o errori.
• Manual Merge Recording: l'abilità  di contrassegnare manualmente singoli changeset come già  applicati in modo da evitare, come di consueto, merge multipli o inutili caccia al changeset.
• Merge Rollback: l'abilità  di annullare senza troppi problemi l'effetto di un merge.

Una delle conseguenze più apprezzabili di queste novità , sempre per quanto riguarda il supporto alle branch, è chiaramente dimostrata dall'articolo Subversion 1.5 merge-tracking in a nutshell che sintetizzo in seguito.

Ipotizziamo il caso che vi troviate a creare una branch branchURL partendo da trunkURL.

$ svn cp trunkURL branchURL
$ svn switch branchURL

A questo punto applicate delle modifiche alla branch

# ...edit files
$ svn commit
# ...edit files
$ svn commit

e decidete di eseguire il merge dei cambiamenti in trunk.

$ svn merge trunkURL
--- Merging r3452 through r3580 into '.':
U button.c
U integer.c
...
$ svn commit

Siete soddisfatti delle modifiche ma per qualche motivo la funzionalità  si rivela incompleta e decidete che non siete ancora pronti ad abbandonare lo sviluppo intrapreso con la branch branchURL.
A questo punto si prospettano 3 alternative:

1. Continuare a lavorare sulla branch, come dovrebbe essere da logica, consapevoli del mal di pancia che vi aspetterà  ogni qual volta deciderete di applicare in modo incrementale le nuove modifiche dalla branch alla trunk
2. Cancellare la branch e ricrearne una nuova, dalla copia di trunk aggiornata. Soluzione immediata, risolve i mal di pancia citati in precedenza, ma a lungo andare è macchinoso oltre che insensato
3. Continuare a lavorare sulla trunk sfruttando le modifiche applicate. Anche in questo caso, la scelta è insensata considerato lo scopo delle branch

Subversion 1.5 offre finalmente una quarta soluzione, o meglio, corregge i problemi relativi alla prima. Con il comando merge --reintegrate è possibile integrare in modo differenziale le modifiche della branch senza dover specificare ogni volta il numero della revisione dell'ultimo merge.

Chi utilizza GIT, ad esempio, troverà  una certa familiarità  con il comando git-rebase. Sono quasi certo che anche Mercurial offra un simile supporto ma non ho ancora approfondito a sufficienza l'utilizzo per i dovuti paragoni del caso.

$ svn switch trunkURL
$ svn merge --reintegrate branchURL
--- Merging differences between repository URLs into '.':
U button.c
U integer.c
...
$ svn commit

I miglioramenti non si fermano qui e vale la pena consultare l'elenco delle modifiche o la versione aggiornata di Version Control with Subversion per ulteriori informazioni.

Per chi, per abitudine o esigenza, lavora spesso su branch parallele l'upgrade alla nuova release è assolutamente fondamentale. A dimostrazione dell'interesse verso Subversion 1.5, gli sviluppatori delle principali client per Subversion sono già  al lavoro per supportare le novità . Capofila il famosissimo TortoiseSVN per Windows che non si è fatto attendere rilasciando TortoiseSVN 1.5.

Chi da tempo è passato a sistemi distribuiti come GIT e Mercurial probabilmente non è mai arrivato a leggere la fine di questo post. O forse lo ha fatto, per il semplice gusto di poter sottolineare come "altri già  fanno questo e quello, non è mica una novità ".
In effetti, questo è vero per quasi tutte le caratteristiche descritte relative al merge, tuttavia Subversion è da anni uno dei sistemi SCM più apprezzati ed è incomiabile lo sforzo del team di sviluppo che, non dimentichiamoci, ha saputo creare uno strumento in grado di strappare il podio a CVS e mantenerlo tutt'ora quando altrettanto blasonati SCM ancora neppure esistevano.

Come anticipato in apertura, Subversion è ben lontato dall'essere considerato l'ultima ruota del carro e la roadmap si prospetta decisamente interessante includendo anche un non meglio precisato sistema ibrido distribuito/centralizzato.
Sono certo che, per almeno il 70% degli utenti, l'uso di Subversion 1.5 sarà  in grado di continuare a soddisfare la quasi totalità  delle principali esigenze quotidiane. Per il restante 30%, le alternative non mancano di certo.