LaTeX e controllo delle versioni

Scrivo questo post più per avere un riferimento personale (l'età avanza e la memoria non è sempre affidabile) che per dire originalità. Se siete grandi esperti di versioning, potete evitare di proseguire la lettura.

Scenario: un matematico (ma ovviamente questo vale per tutti gli scienziati, eccetto probabilmente per gli informatici programmatori che crescono a pane e versioning) si accinge a scrivere un articolo.
Problema: come gestire le modifiche ai file LaTeX del dattiloscritto?

L'approccio classico si basa sulla moltiplicazione dei pani e dei pes... ehm, dei file. La ricetta più popolare è quella di aggiungere al nome del file la data (e l'ora) dell'ultimo salvataggio. Questo è un metodo senz'altro efficace, ma molto rudimentale e che mette a rischio la directory di lavoro.
Fortunatamente esistono strumenti stabili ed efficienti che ottimizzano l'idea fondamentale. La maggior parte di tali software è basata su uno schema gerarchico tronco-rami: c'è un server centrale e ci sono i client degli autori che prelevano il progetto e lo caricano dopo averlo modificato. Un approccio leggermente diverso è quello di git, che privilegia un approccio meno napoleonico e più distribuito, quindi adatto a progetti estremamente grandi e partecipati.
La caratteristica comune a tutti questi programmi è la gestione dei conflitti: se due collaboratori modificano simultaneamente il medesimo file, il sistema di controllo se ne accorge e chiede ai collaboratori di risolvere i conflitti, cioè di decidere quale versione sia quella definitiva. Naturalmente questo è un passaggio che solo un essere umano può affrontare, e quindi ciascun collaboratore vedrà le differenze fra il proprio file e quello altrui, e deciderà caso per caso come comportarsi.

Personalmente non ho mai sperimentato git, ma mi riprometto di farlo presto. Invece, la mia scelta è caduta sul più classico svn. Si tratta di un software di tipo centralizzato, che pretende un server di riferimento accessibile a tutti i collaboratori; i protocolli di accesso sono molteplici, e il più sicuro è probabilmente ssh. Vediamo un piccolo esempio concreto. Supponiamo che il server si chiami... server, e il client si chiami... client. Per prima cosa, dobbiamo accedere ad un terminale sul server. Per comodità sorvolerò sulla gestione dei permessi e degli utenti, ipotizzando di lavorare in una directory che tutti gli utenti autorizzati sul server possono leggere e scrivere.
La prima cosa da fare è creare uno spazio di lavoro per svn:

server$ mkdir svn && cd svn && svnadmin create

In questo modo, la directory svn/ è diventata una directory di lavoro, e possiamo facilmente verificare la presenza di directory nascoste che saranno usate da svn per raccogliere i dati di lavoro. Supponiamo poi di avere una directory $HOME/article contenente i file LaTeX del nostro articolo. Dobbiamo importare questi file nell'albero svn:

server$ svn import file:///$HOME/article

Se tutto è andato bene, vedremo a terminale che svn ha caricato nella directory svn/ tutti i file della directory $HOME/article. Perfetto, il server ormai è pronto.
Adesso, dobbiamo istruire il nostro client a dialogare con il server. Quindi creiamo una directory di lavoro:

client$ mkdir svn && cd svn

Qui non è più necessario importare alcunché, visto che possiamo già prelevare i sorgenti dal server svn:

client$ svn co svn+ssh://user@server/svn

avendo cura di sostituire, se necessario al path svn il full path di svn sul server. Potrebbe essere /home/user/svn oppure /var/svn, oppure /opt/svn, a seconda dei gusti.
Ok, è praticamente fatta! Adesso il nostro client possiede una copia dei file identica a quella del server. Facciamo le nostre modifiche, ricordando di iniziare sempre con il comando

client$ svn up

per evitare di modificare versioni obsolete. Dopo aver fatto le nostre modifiche, le carichiamo sul server con il comando

client$ svn ci -m "messaggio esplicativo"

dove "messaggio esplicativo" è un commento che ci aiuterà a ricordare maggiori dettagli della modifica. Una buona idea, anche se un po' arida, è quella di inserire nel messaggio data ed ora completa della modifica.

Questi sono i passi essenziali. Evidentemente, ciascun collaboratore scaricherà la prima versione dal server, e operarerà in maniera analoga sul proprio computer. Non mi soffermo sui dettagli della risoluzione di eventuali conflitti. Solitamente la stesura di un dattiloscritto scientifico non comporta conflitti particolarmente complessi, e quasi sempre la colpa è di un collaboratore smemorato che ha dimenticato di prelevare l'ultima release con il comando svn up.
Naturalmente svn consente di visualizzare i dettagli dell'evoluzione di ciascun file, di aggiungere e togliere file all progetto, ed anche di clonare completamente i sorgenti per non pasticciare troppo la copia principale. Occorre però avvertire che il cosiddetto branching dei progetti è molto più evoluto in git, ed infatti i grandi sviluppatori di codice informatico si sono progressivamente spostati su git o mercurial. Per i piccoli progetti, la mia sensazione è che svn sia eccellente, e più semplice da gestire.

Per concludere, un problema abbastanza comune può essere la disponibilità di un server pubblico da cui partire. Ovviamente i fornitori di spazio svn/git/mercurial/cvs abbondano, ma quasi sempre pretendono che i progetto ospitato sia open source. Evidentemente questo può creare imbarazzo ad uno scienziato che stia scrivendo un articolo o un libro, per questioni di riservatezza dei risultati. Cercando bene, si trovano server gratuiti che concedono piccoli spazi (dell'ordine di 50 Mb) privati, ma per progetti più grandi bisogna scucire il vil denaro. Fortunatamente, le università possiedono server da utilizzare per queste collaborazioni, ma dal mio piccolo osservatorio ho notato che svn è raramente installato per default.