[Mercurial.6] Clonare e lavorare su un progetto Mercurial già esistente

Riprendiamo la serie di mini-post dedicati a Mercurial. Prima di cominciare, voglio farvi un riassunto delle puntate precedenti, così potete balzare da un punto all’altro e vedere gli argomenti già trattati.

[Mercurial.1] Utilizzo di Mercurial per versionare i propri sorgenti

[Mercurial.2] Mercurial: come creare il proprio repository

[Mercurial.3] Creazione di un repository Mercurial per gestire una solution Visual Studio 2010

[Mercurial.4] Mercurial: icone dei files, cancellazione repository e plug-in per Visual Studio 2005/2008/2010

[Mercurial.5] Primi passi di Mercurial con un progetto Silverlight

Oggi vediamo questi argomenti:

1. come utilizzare un server Mercurial pre-esistente
2. come copiare in locale i sorgenti di un progetto già esistente
3. come effettuare modifiche al sorgente e…
4. …come rispedirle al server Mercurial del punto (1)

Come utilizzare un server Mercurial
Se vi ricordate bene i primi argomenti tirati in ballo quando si parla di Mercurial, noterete che si dice che per poter funzionare Mercurial non ha bisogno di un vero server, come invece accade con TFS. Ognuno dei PC che possiede il repository in locale è allo stesso tempo server & client. Quindi, la prima domanda è: perchè si vorrebbe avere un server centralizzato di Mercurial?

Io personalmente qualche risposta potrei anche darvela, ma sicuramente non rappresenta la giusta e sacrosanta verità. Io penso che un server centralizzato di Mercurial possa essere comunque utile per i seguenti motivi:

1. più facile gestirne i backup, perchè posso schedularlo sul server aziendale (se aspettiamo che ogni developer del team faccia il backup del proprio PC, “campa cavallo che l’erba cresce”, come dice un proverbio)
2. disponibilità sempre, dovunque e comunque dei sorgenti. Non è detto che siamo all’ultima versione disponibile, dal momento che ogni utente può averli modificati in locale, ma almeno i sorgenti ce li ho
3. ed altri motivi che adesso non mi vengono in mente 🙂

Torniamo a noi. Esiste il sito http://bitbucket.org/, che permette di pubblicare repository Mercurial in modo del tutto gratuito, esattamente come accade con CodePlex. Ora: supponiamo che un qualcuno abbia già creato un progetto disponibile su bitbucket: noi vogliamo semplicemente prendere i sorgenti, guardarli e lavorarci un po’: poi, se siamo autorizzati, vogliamo rispedire al server le nostre modifiche, per metterle a disposizione a tutti.

Con Mercurial le cose sono estremamente semplici.

Come copiare in locale i sorgenti di un progetto pre-esistente
Dunque, date un’occhiata a questa pagina Web: http://bitbucket.org/igordamiani/consoletest. Un mesetto fa circa ho creato un progetto “ConsoleTest” per studiare e fare i primi esperimenti con Mercurial. Adesso ciascuno di voi lo clonerà sul proprio PC. Come fare? Seguite i seguenti passi.

1. Andare in una directory a vostro piacimento (io utilizzerò X: perchè mi fa comodo così)
2. Create una cartella (ad esempio: “ConsoleTest”)
3. Cliccate con il pulsante destro del mouse, andate su TortoiseHG –> Clone…
4. Apparirà il tool per clonare un progetto

E’ sufficiente compilare il Source Path ed il Destination Path, poi premete Clone ed il gioco è fatto. Piccole precisazioni: il source path è l’URL del repository remoto, per cui potete semplicemente fare copia & incolla dal browser. Il destination path viene impostato automaticamente in base alla cartella che avete selezionato per dare il comando.

Al termine dell’esecuzione del comando Clone, la cartella X:ConsoleTest conterrà il progetto Visual Studio 2010, che potete aprire, guardare, compilare, eseguire e modificare.

Come effettuare modifiche al codice sorgente
Dunque, supponiamo che abbiate aperto ed eseguito il codice. Nel momento in cui vi scrivo, il Main() non fa altro che visualizzare sulla console l’elenco di tutti i processi installati e disponibile sul vostro sistema. Non è scopo di questo post spiegare come fare: basta leggere il codice! 🙂

Adesso, da bravi developer C#, cancellate il contenuto del Main() e scrivetene uno voi. Non importa cosa, l’importante è avere un Program.cs diverso dal mio. Basta avere un po’ di fantasia. Supponiamo di aver digitato questo:

 class Program

 {

 static void Main(string[] args)

 {

 DateTime today = DateTime.Now;

 Console.WriteLine("Oggi è il {0}.", today.ToShortDateString());

 if (today.Day == 2 && today.Month == 6)

 {

 Console.WriteLine("Buona Festa della Repubblica a tutti!");

 }

 Console.ReadKey();

 }

 }

Nulla di particolarmente sconvolgente. Adesso potete committare il codice. Ricordiamoci per l’ennesima volta che il commit avviene sul vostro repository locale, per cui potete fare & disfare il codice tutte le volte che volete, senza paura di intaccare il lavoro degli altri vostri colleghi. Per maggiori dettagli sull’operazione di commit, vi consiglio di dare un’occhiata ai miei precedenti post, soprattutto i [Mercurial.3] e [Mercurial.4], dove descrivo il plug-in per Visual Studio 2010.

Una volta che siete sicuri del vostro codice, potete finalmente buttare sul server la vostra modifica.

Come rispedire le modifiche al server Mercurial
Se avete fatto tutto come indicato, se adesso – stando in Visual Studio 2010 – andate sul tool HG Synchronize, vi appare la seguente schermata.

La schermata è piuttosto scarna. L’informazione più importante qua è il path del repository remoto, che non avete più bisogno di inserire, perchè TortoiseHG se la ricorda! 🙂 A questo punto cliccate sul pulsante Push e – previo inserimento di username & password – non fate altro che sincronizzare il repository remoto con le modifiche appena fatte. Il risultato è una cosa simile a questa:

Tutto qua. Adesso all’url http://bitbucket.org/igordamiani/consoletest potete vedere tutta la history dei changeset committati, vostri e degli altri utenti.

Conclusioni
Solo una cosa ancora da dire. Una delle cose più interessanti di Mercurial, a mio avviso, è che quando clonate un repository non avete solo l’ultima versione dei sorgenti, ma avete a tutti gli effetti l’intero repository in locale sul vostro PC. Cosa significa? Significa che anche in assenza di connessione ad Internet, potete vedere tutti i commit, potete fare il revert ad una certa versione dei sorgenti, potete leggere tutti i commenti inseriti nei commit. Quindi, se lavorate offline, avete tutta una serie di informazioni che magari con TFS non potete avere.

Send to Kindle