Come già visto il numero di build viene passato esternamente dalla build machine, ma il numero di revisione deve invece essere calcolato dallo script ad ogni build. La revisione probabilmente è la più importante delle quattro parti, perché deve sempre essere pari al numero di revisione del controllo di codice sorgente utilizzato.
Questo requisito è fondamentale, immaginiamo questo scenario: abbiamo installato dieci versioni differenti di un programma in dieci fabbriche diverse e nessuna delle versioni è eguale, perché ogni volta viene installata l'ultima versione disponibile. Se la fabbrica numero cinque chiama lamentando un problema, è importante poter determinare in maniera univoca la versione in esecuzione in quella specifica fabbrica. Grazie ad una corretta gestione del numero di revisione è sufficiente esaminare il numero di versione del file degli assembly, se questo numero è ad esempio x.x.x.2343 basta recuperare la versione 2324 dal proprio gestore di codice sorgente e replicare il bug nel codice della fabbrica cinque.
Questo semplice esempio mostra l'importanza del revisione. Purtroppo non è possibile avere un task unico per recuperare questo valore dato che ogni programma di gestione codice è differente dagli altri. Lo script common.build contiene, a titolo di esempio, un target che recupera la revisione di SubVersion.
<target name="build.assembly.getrevision.svn">
<!-- try to update the revision -->
<exec
program="svn"
commandline='info "${path.src}" --xml'
output="_revision.xml"
failonerror="false" />
<xmlpeek
file="_revision.xml"
xpath="/info/entry/@revision"
property="project.version.revision"
failonerror="false" />
<delete file="_revision.xml" failonerror="false" />
<echo message="INFO: Using Subversion revision number: ${project.version.revision}"/>
</target>
Questo esempio è interessante perché fa uso del task <exec> che permette di eseguire un comando e ridirezionare l'output su di un file. Nel caso di subversion il comando da eseguire è:
svn info directory --xml
che effettua un dump delle informazioni sul repository nella directory indicata. Naturalmente affinché questo task possa essere eseguito è necessario avere precedentemente installato il client di subversion, oppure si può anche includere il client direttamente in una cartella del progetto chiamata solitamente buildtools.
L'output che si ottiene da questa azione è un file XML contenente tutte le informazioni sul progetto, ecco un esempio delle prime righe che si trovano in questo file.
<?xml version="1.0"?>
<info>
<entry kind="dir"
path="C:DevelopSvnGianMariaArticoliHtml.itNantArticolo2Sample1MyLibrary"
revision="418">
<url>svn://10.8.0.1/GianMaria/Articoli/Html.it/Nant/Articolo2/Sample1/MyLibrary</url>
<repository>
Il numero di versione è quindi presente nell'attributo revision del nodo <entry> delle <info>.
Anche in questo caso nant mostra tutta la sua potenza con il task <xmlpeek> che consente di recuperare parti di file XML semplicemente specificandone la posizione con XPath. Anche senza essere maestri di XPath, per recuperare il numero di versione è sufficiente utilizzare la stringa /info/entry/@revision.
Entrambi i task <exec> e <xmlpeek> hanno inoltre l'attributo failonerror="false" in questo modo se le operazioni falliscono la compilazione non viene interrotta.
Questa impostazione viene fatta soprattutto per le librerie opensource, dove gli utilizzatori solitamente scaricano una versione in file .zip, e quindi scollegata dal controllo di codice sorgente.
Il suggerimento è che nella macchina di build, e per progetti aziendali il failonerror venga invece impostato a true. In questo modo se il recupero del numero di versione fallisce anche il processo di build si arresta, se si lascia invece il valore false, se il recupero del numero di versione fallisce la revisione verrebbe posta pari a zero, perdendo così tutti i vantaggi discussi in precedenza.
