Come aggiornare da un repository su BDB 4.2 a FSFS

Il problema si pone se trasferite i vostri dati da una macchina che usa una versione di Subversion basata su BDB 4.2 (come la 1.1 che c'è su Debian Sarge) ad una versione basata su BDB 4.3 (come la 1.3 che c'è su Ubuntu Dapper). In questo caso il problema è l'incompatibilità del formato dei log di BDB che rende inutilizzabili i dati a svnadmin.

Le FAQ di subversion consigliano di procurarsi una versione di svnadmin collegata a BDB 4.2, in realtà è sufficiente avere i programmi di amministrazione per BDB 4.2, senza doversi andare a cercare una binario da un'altra macchina o distribuzione. La procedura da seguire è la seguente, che prevede di passare direttamente a FSFS (non si prenderà neanche in considerazione di usare BDB 4.3).

Il primo passo è assicurarsi che non vi siano accessi a Subversion (neanche in lettura) durante le operazioni, pena il rischio di corrompere il database dei dati. Pertanto si fermi Apache o qualunque altro servizio che possa accedere al repository e ci si assicuri che nessuno ci stia lavorando sopra direttamente; nei casi piu` comuni basta fermare Apache.

I passi successivi sono i seguenti, che prevedono in sequenza la creazione di una copia di sicurezza, il checkpointing del DB che inserisce i dati dispersi nei file di log, la ricostruzione del DB, che rende il tutto leggibile da BDB 4.3, e poi l'utilizzo classico di svnadmin per eseguire un dump, creare un nuovo repository, e caricarlo coi contenuti del dump:

cp -a /var/svn/repo /var/svn/repo_copy
db4.2_checkpoint -1 -h /var/svn/repo/db
db4.2_recover -h /var/svn/repo/db
svnadmin dump repo  > /var/backup/repo.dump
mv repo repo_old
svnadmin create /var/svn/repo
svnadmin load /var/svn/repo < /var/backup/repo.dump

Si noti che si è usato svnadmin create senza specificare tipo di repository, il default con la 1.3 infatti è FSFS; una volta compiuti questi passi si potrà verificare il corretto funzionamento dell'accesso al repository, e poi cancellare le copie ormai inutili.