SVN remoto a costo zero
Ok avete iniziato ad usare Tortoise SVN e, come suggerito da Abell, non avete affatto bisogno della parte Server (se siete da soli ovviamente). Potete tranquillamente gestire i progetti utilizzando le URL con prefisso "file:///". Fin qui nulla di nuovo.
Ma è comodo avere un server SVN remoto su Internet a cui appoggiarsi e in giro ce ne sono diversi. Purtroppo però hanno un costo mensile, non alto, ma certo nemmeno gratis :-)
E allora come trovare una soluzione a costo zero?
Semplice: basta unire Tortoise SVN e il fantastico servizio di repository remoto DropBox.
SVN su chiavetta per sviluppatori on-the-road
Può darsi che, come a me, anche a voi capiti di lavorare in diversi contesti e di sviluppare software su più computer. Avete il PC fisso a casa, il portatile che usate presso i clienti, il computer in ufficio, quello nella casa al mare, uno a casa dei vostri genitori e un mini-laptop che portate nelle scampagnate. Siete consapevoli dell'importanza di un sistema di controllo delle versioni e in ogni momento volete avere accesso al vostro software, perché potrebbe servirvi un pezzo di codice che avete usato in passato o perché vi è venuta in mente come risolvere un bug a cui pensate da due settimane.
Ecco la soluzione che ho trovato qualche anno fa e che, almeno per lo sviluppo individuale, trovo molto comoda:
create un repository subversion su una chiavetta USB formattata FAT.
TortoiseSVN
Il post di Abell mi ha fatto pensare che molti di voi non saranno così folli da gestire il SCM (Source Code Management) a riga di comando (giusto ABell, sfegatato Linuxiano...). E allora perché complicarsi la vita se avete il fantastico Winzozz?
Se non volete impazzire quindi nello gestire, con comandi a "manella", il vostro progetto con SVN (SubVersion) e siete su Windows (XP, VISTA o la versione che preferite) vi consiglio di utilizzare l'ottimo plug-in Tortoise SVN.
Versionamento di database
Uno dei riti di passaggio nella vita dello sviluppatore è l'adozione di un sistema di controllo delle versioni. Dopo aver appreso sulla propria pelle la necessità di una disciplina di backup, di solito a seguito di un evento traumatico quale la perdita di un mese di lavoro a causa di un delete un po' affrettato, il giovane sviluppatore comincia a disseminare i suoi dispositivi di supporto di file dai nomi poco edificanti quali torre-di-hanoi.zip, torre-di-hanoi-1.zip, torre-di-hanoi-138-bis.zip. Preso contatto con la nobile tradizione delll'ISO 8601, i file cominciano ad avere una forma un po' più coerente, quale torre-di-hanoi-2008-12-28.zip, il che gli evita di dover tenere conto dell'ultimo identificativo usato per un certo progetto e di cancellare i backup precedenti ad una certa data.
Il passaggio ad un sistema di controllo delle versioni quale subversion o uno dei suoi parenti più o meno stretti è un grande salto di qualità.
Il mio Makefile - I
Sviluppando in ambiente Linux, di solito per i miei progetti utilizzo dei Makefile che regolano una serie di processi automatici, come la compilazione, la messa in esercizio, il test, la generazione di file derivati etc.
Ad esempio, per un'applicazione web il comando make deploy scatena l'eventuale compilazione, la generazione di un pacchetto in formato deb o tgz, il trasferimento e l'installazione sul server, che di solito richiede un restart di Apache.
Di solito effettuo commit molto frequenti dei miei progetti, ma solo occasionalmente faccio un deploy. E a volte si pone il problema: quale versione è quella online? Avevo già effettuato la tal modifica? Avevo già integrato quella certa funzionalità?
Per tracciare i deploy e sapere qual'è la versione dell'applicazione in esercizio (o quale era in esercizio a un dato momento), è molto utile creare un tag nel sistema di controllo delle versioni.