Innanzitutto sarà meglio chiarire subito che non ho la minima intenzione di addentrarmi nella polemica tra chi denigra VSS e chi invece lo disprezza; non ho intenzione di proporlo come alternativa ad altri strumenti quali Subversion, Perforce e simili; chi volesse divertirsi alle spalle del povero VSS può frequentare un forum su CodeProject, aspettare al massimo qualche giorno e gustarsi il post (e relative risposte) di un utente che immancabilmente segnalerà qualche pecca del nostro eroe chiedendo al popolo della rete se esistono alternative.
Ma visto che VSS viene distribuito con lo stesso Visual Studio che usiamo per sviluppare, molti trovano naturale usarlo per il versioning dei sorgenti (ma anche della documentazione, delle risorse e quant’altro possa tornare utile allo sviluppo delle applicazioni).
Credo che la maggior parte delle persone abbia imparato ad usare VSS esclusivamente attraverso l’interfaccia grafica fornita dal Source Safe Explorer; di sicuro ciò è stato vero per me. Tuttavia è possibile usare Source Safe anche da linea di comando, il che ci consente di creare dei piccoli batch con i quali automatizzare le classiche attività quotidiane, quali la Get Latest Version dei progetti, fare il Check-Out/Check-In (ad esempio) dei file AssemblyInfo.* e così via.
Vediamo il caso della Get Latest Version: nella realtà dove lavoro (e vivo, mi verrebbe da aggiungere con una lacrima) alla mattina ogni sviluppatore fa una bella Get Latest Version di tutto il database per accogliere le modifiche fatte da alrri, ricompila il tutto per verificare che non ci siano problemi, poi comincia a lavorare. Tutto ciò può essere fatto secondo tradizione lanciando l’Explorer di Source Safe, posizionandosi sul progetto $/, clickando con il tasto destro del mouse e scegliendo dal menu contestuale la voce “Leggi ultima versione” mettendo il segno di spunta all’opzione “Includi sottoprogetti“.
L’alternativa è scrivere un file batch, che chiameremo ad esempio vssGetLatestVersion.bat, fatto circa così:
SET PATH=C:\Programmi\Microsoft Visual Studio\Common\VSS\win32;%PATH% SET HomeDrive=D SET HomeDir=\Projects\Samples SET SSDIR=\\Server\SourceSafe\Samples %HomeDrive%: CD %HomeDir% SS.EXE Cp $/ SS.EXE Workfold $/ %HomeDrive%:%HomeDir% SS.EXE Get * -R -I- -Ymarcoturrini
Cominciamo dalle istruzioni SET delle prime righe che servono ad impostare alcuni percorsi; in particolare l’istruzione della prima riga serve ad impostare correttamente il path (di fatto aggiungendolo al path attualmente esistente, anzi anteponendolo):
SET PATH=C:\Programmi\Microsoft Visual Studio\Common\VSS\win32;%PATH%
L’istruzione della seconda riga serve ad impostare correttamente il disco (unità logica o fisica) su cui si trova la directory di lavoro; ad esempio, io di solito imposto le mie cartelle di lavoro sul disco D:
SET HomeDrive=D
L’istruzione della terza riga serve ad impostare correttamente la directory di lavoro vera e propria, che risiede sul disco appena visto:
SET HomeDir=\Projects\Samples
Infine, l’ultima SET imposta la directory in cui si trova il database di SourceSafe:
SET SSDIR=\\Server\SourceSafe\Samples
Vorrei fare notare come, benché nella nostra realtà aziendale \\Server\SourceSafe sia mappato sui nostri p.c. come unità T:, SourceSafe sembri preferire che il percorso il percorso venga indicato nella forma non mappata.
Le due righe successive non fanno altro che “posizionare” il batch sul disco e sulla directory di lavoro:
%HomeDrive%: CD %HomeDir%
Ci siamo… quasi! Prima dobbiamo impostare il progetto root ($) come progetto corrente (l’impostazione del progetto corrente sta a Source Safe come l’impostazione della directory corrente sta al file system: indica che da questo momento operiamo all’interno di quel progetto)…
SS.EXE Cp $/
… poi impostare la directory di lavoro del progetto root ($)…
SS.EXE Workfold $/ %HomeDrive%:%HomeDir%
… ed infine eseguire la nostra Get latest version ricorsiva
SS.EXE Get * -R -I- -Ymarcoturrini
Adesso un po di teoria:
per eseguire dei comandi sul database di SourceSafe bisogna lanciare il programma SS.EXE (il nome è inquietante, lo riconosco, ma non l’ho scelto io) passandogli come primo parametro il comando da eseguire; in particolare:
| Comando | Descrizione |
|---|---|
Cp |
Imposta il progetto indicato come progetto corrente; come parametro accetta il nome del progetto da impostare come corrente |
Workfold |
Imposta la directory indicata come directory di lavoro del progetto corrente |
Get |
Legge i file del progetto corrente; per default legge l’ultima versione, ma usando l’argomento -Vn è possibile leggere i file relativi alla versione numero n; è possibile usare anche la forma -Vdgg-mm-aa (dove gg rappresenta il giorno, mm il mese e aa l’anno) |
Checkout |
Estrae dal database il/i file indicato/i |
Checkin |
Archivia il/i file indicato/i nel database |
Undocheckout |
Annulla l’estrazione dal database del/dei file indicato/i |
I comandi Get, Checkout, Checkin e Undochekout accettano alcuni parametri comuni:
- il nome del file, eventualmente con l’uso di wildcards, come in DOS
- l’opzione -R consente di operare ricursivamente sui progetti, quindi eseguire la lettura, estrazione, archiviazione o annullamento dell’estrazione anche sui sotto-progetti contenuti nel progetto corrente
- l’opzione -I- è molto utile negli script proprio perché disabilità ogni eventuale richiesta di input da parte dell’utente
- l’opzione -Ynome[,password]consente di specificare il nome utente e la password (se prevista) per accedere al database
A questo punto realizzare uno script per fare il Check-Out di un file è abbastanza semplice: l’unica accortezza da tenere presente è che è bene tenere allineati il progetto e la directory corrente; quindi, giusto per dare un esempio veloce:
SET PATH=C:\Programmi\Microsoft Visual Studio\Common\VSS\win32;%PATH% SET HomeDrive=D SET HomeDir=\Projects\Samples SET SSDIR=\\Server\SourceSafe\Samples %HomeDrive%: SS.EXE Cp $/ SS.EXE Workfold $/ %HomeDrive%:%HomeDir% CD %HomeDir%\Docs SS.EXE CheckOut $/Docs/Analisi.doc -Ymarcoturrini -I- CD %HomeDir%\Resources SS.EXE CheckOut $/Resources/Logo.bmp -Ymarcoturrini -I-
Analogamente per effettuare il Check-In dei file precedentemente estratti:
SET PATH=C:\Programmi\Microsoft Visual Studio\Common\VSS\win32;%PATH% SET HomeDrive=D SET HomeDir=\Projects\Samples SET SSDIR=\\Server\SourceSafe\Samples %HomeDrive%: SS.EXE Cp $/ SS.EXE Workfold $/ %HomeDrive%:%HomeDir% CD %HomeDir%\Docs SS.EXE Checkin $/Docs/Analisi.doc -Ymarcoturrini -I- CD %HomeDir%\Resources SS.EXE Checkin $/Resources/Logo.bmp -Ymarcoturrini -I-
Ed infine, allo stesso modo, per l’Undo Check-Out:
SET PATH=C:\Programmi\Microsoft Visual Studio\Common\VSS\win32;%PATH% SET HomeDrive=D SET HomeDir=\Projects\Samples SET SSDIR=\\Server\SourceSafe\Samples %HomeDrive%: SS.EXE Cp $/ SS.EXE Workfold $/ %HomeDrive%:%HomeDir% CD %HomeDir%\Docs SS.EXE UndoCheckOut $/Docs/Analisi.doc -Ymarcoturrini -I- CD %HomeDir%\Resources SS.EXE UndoCheckOut $/Resources/Logo.bmp -Ymarcoturrini -I-
Bello, vero? Soprattutto quando (come è capitato a me) i file da prendere in Check-Out (e poi rilasciare in Check-In) sono più di un ottantina in una sessantina di progetti.