In azienda è iniziato un progetto che durerà un paio di mesi. Il gruppo tecnico, formato da due sviluppatori tra cui me, lavora sia on-site che in ufficio. Ovviamente abbiamo l’esigenza di tenere sotto controllo il codice ma non possiamo utilizzare software come VisualSourceSafe, che si basano su un repository centrale.
Da qui l’idea di provare Mercurial: un sistema (scritto quasi totalmente in Python) che permette il controllo di versione decentralizzato.
I primi passi con Mercurial sono assolutamente soddisfacenti. Il setup in ambiente Windows è semplicissimo, basta infatti:
- Scaricare e si installare TortoiseHG, il porting in ambiente windows di Mercurial
- Scaricare e installare VisualHG, il plugin per Visual Studio 2008
- Attivare VisualHG su Visual Studio: Menù Tools > Options > Source Control > Aggiornare la voce “Current Source Control plug-in” selezionando VisualHG e cliccando Ok
Installati i componenti si può preparare un repository, selezionando una directory e – attraverso il menù contestuale – selezionando: TortoiseHG > Create Repository Here.
Questa operazione ovviamente può essere effettuata su una directory già esistente, ad esempio quella della Solution che sio vuole mettere sotto controllo. VisualStudio in fase di caricamento dei progetti riconoscerà automaticamente i file sotto controllo e mostrerà lo stato:
VisualHG attivato su Visual Studio 2008
Per approfondire i meccanismi di funzionamento di Mercurial vi consiglio l’ottima “Definitive Guide“, disponibile gratis online.
4 Comments
Avevo provato tempo fa a fare un mix un po’ forzato tra SVN e Groove (prodotto MS molto carino per il lavoro di gruppo distribuito senza l’aiuto di un server centrale), ma questo Mercurial mi pare più interessante. Lo provo e se fa schifo me la prenderò con te!
P.S. Posso partecipare anch’io alla stesura di articoli per Piuter?
Ok, aggiudicato: puoi prendertela con me, e puoi ovviamente partecipare
Mmm, bene, perché le prove che ho fatto con Mercurial, benché immediate, non mi hanno particolarmente colpito.
Sarà che avevo frainteso la questione del repository distribuito…
Premetto che sono un felice utente di SVN ma, come sai, non disdegno di provare quello che, almeno per me, sono novità.
Il problema qui non è Mercurial ma un repository distribuito generico…ma perché?
Di tutti i punti citati nella guida alla voce “A few of the advantages of distributed revision control”, nessuno mi ha convinto ed, anzi, alcuni sono veramente campati per aria. Esempio?
“Distributed tools are indifferent to the vagaries of your server infrastructure, again because they replicate metadata to so many locations.”
So many? Perché, le working copy di un repository centrale cosa sono? Inoltre, in entrambi i casi serve una connessione per aggiornare le copie locali.
“If you use a centralised system and your server catches fire, you’d better hope that your backup media are reliable, and that your last backup was recent and actually worked. With a distributed tool, you have many backups available on every contributor’s computer.”
Seeeee, va beh…rigiriamo la frittata. Un repo centrale è un backup in PIU’ rispetto alle working directory che gli sviluppatori hanno sulle loro macchine, ed è assente nel caso di Mercurial. Inoltre, per ovvi motivi, si presume che il server centrale sia mille volte più sicuro delle macchine di sviluppo.
E, sempre come sopra, perché siano aggiornate le copie locali sempre connetterti devi.
Potrei dicutere anche il resto delle affermazioni del paragrafo, ma non vorrei sembrare troppo polemico e lascio agli appassionati la lettura.
Aggiungo solo che un’organizzazione del genere del repository inserisce anche una non trascurabile problematica: bisogna essere in due, come nell’innesco di una bomba H nei film, per sapere di aver allineato il tutto. Con un repo centrale posso fare il mio lavoro, caricarlo su server, e andare felice in vacanza tranquillo che i miei colleghi usufruiranno del mio lavoro…con Mercurial no! Prima ci dobbiamo beccare in rete per allinearci sul repository, e poi posso andare in ferie felice.
Schivo le questioni filosofiche e cerco di mantenere il discorso sul lato pratico. Ho deciso di adottare Mercurial nel progetto che citavo perché ci permetteva di lavorare in maniera distribuita e paritaria, senza bisogno di un repository centrale, e perché la curva di apprendimento richiesta per poter iniziare a lavorarci con profitto è relativamente bassa.
In altri contesti potrebbe non essere la scelta migliore.
Il discorso repo centrale, repo distribuiti è in realtà un falso problema, dal momento che anche con Mercurial si può lavorare con un repository centrale (stile VSS, o meglio stile GIT). A proposito, conosci bitbucket?