Info:

twitter

Ultimi commenti: Comment feed

Tags:

Sponsor:

Archivio 2018:

Mag Feb Gen

Archivio 2017:

Dic Nov Ott Mag Apr Mar Feb Gen

Archivio 2016:

Dic Nov Ott Ago Mag Mar Feb Gen

Archivio 2015:

Nov Ott Set Mar Gen

Archivio 2014:

Dic Nov Ott Set Lug Giu Mag Apr Gen

Archivio 2013:

Dic Nov Set Ago Lug Giu Mag Apr Feb Gen

Archivio 2012:

Dic Nov Ott Set Ago Giu Mag Apr Mar Feb Gen

Archivio 2011:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2010:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2009:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2008:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2007:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2006:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Installare un server Mercurial su WHS

Dopo l’upgrade del serverozzo ho dovuto reinstallare il server Mercurial. Ho deciso di farlo da zero per segnarmi tutti i passi nel caso debba rifarlo su un altro (virtual) PC.

La procedura che ho usato è quella indicata in questo post che spiega come installare e configurare Python, dove prelevare i file e come configurare IIS in modo tale che il server sia accessibile via HTTP.

Dopo di che ci sono da notare un paio di cose: con la versione 1.3.1 di Mercurial va usata la versione 2.5.x di Python in quanto alcuni file binari sono compilati(*) con tale versione ed incompatibili con le successive.

La seconda cosa importante da notare è il fatto che il client mercurial per Windows supporta solo la basic authentication, per cui la coppia utente/password viaggia in rete in chiaro. Per i paranoici ci sono due possibili soluzioni:

  1. creare un utente ad hoc su WHS solo per Mercurial
  2. installare un certificato SSL

Io, avendo anche un’utenza DynDNS, ho voluto intraprendere la seconda strada. Se non ci si vuole procurare un certificato ufficiale che di solito costa un certo ammontare di $$ l’anno, si può usare un tool chiamato SelfSSL e che serve a generare un certificato SSL auto-certificante; il certificato va poi esportato su due file, uno contenente anche la chiave privata per future reinstallazioni del server, uno da installare su tutti i client in modo da evitare l’errore di “trusted root certificate authority” non riconosciuta.

Allego un paio di schermate come promemoria di dove sono tutti i setting da cambiare:

IIS management, right click sulle proprietà del sito, tab Directory Security:

image

Edit su Authentication and access control per abilitare la Basic Authentication e disabilitare l’accesso anonimo:

image

Cliccando “View Certificate” per esportare il certificato:

image

Il checkin completo di una nuova feature ha garantito che il tutto funziona a dovere come dovrebbe

-quack

(*) whatever it means.

Potrebbero interessarti anche:
Commenti (8):
1. Shance
sabato 31 ottobre 2009 alle 1:42 PM - firefox 3.5.4 OS X 10
   

Mi spieghi cosa fa e cosa è Mercurial? Parole tue, dai siti non ho capito.

   
2. Gabriele
sabato 31 ottobre 2009 alle 7:41 PM - firefox 3.5.4 Ubuntu 9.10
   

Mi spieghi cosa fa e cosa è Mercurial?

È un sistema di controllo di revisione dei codici sorgente. Ti permette di lavorare in più persone ad uno stesso progetto gestendo in modo furbo modifiche concorrenti e dandoti la possibilità di confrontare varie revisioni di ogni file e di mantenere "rami" separati del tuo codice (che so, la versione stabile - su cui fai solo bug fix - e quella di sviluppo).

Rispetto ad altri software simili, come CSV e SVN, Mercurial (e altri) non hanno un repository centrale ma tanti repository "alla pari".

Questo consente di evitare il collo di bottiglia che si viene a creare con un solo repository e dà maggiore libertà al singolo sviluppatore di lavorare su una propria copia di sviluppo, sincronizzandosi quando serve con gli altri.

Tieni conto anche che è possibile simulare il comportamento a repository centralizzato, qualora serva, predisponendo un repository speciale da cui tutti leggano e su cui le scritture vengano fatte dai vari sviluppatori solo quando le loro parti di codice sono funzionanti.

Detto questo, una domanda per Paperino.

Quali sistemi di controllo di versione usate al lavoro?

   
3. Paperino
domenica 1 novembre 2009 alle 5:10 AM - firefox 3.5.4 Windows 7
   

In principio usavamo uno interno (SLM) mentre qualche team usava VSS (che roba!). Adesso i grossi progetti (Win, SQL) utilizzano Source Depot, che è un altro tool interno basato sul codice sorgente di Perforce, mentre altri stanno passando a TFS che è molto più di un SCM (gestione dei bachi e del progetto integrata).

   
4. Gabriele
martedì 3 novembre 2009 alle 3:13 PM - firefox 3.5.4 Ubuntu 9.04
   

SLM, VSS, Source Depot, TFS

Tutta roba interna o anche qualcosa di cui si possano vedere le caratteristiche?

   
5. Edward
martedì 3 novembre 2009 alle 4:00 PM - firefox 3.5.4 Windows 7
   

@ Gabriele:

La voce Visual SourceSafe (VSS) sulla wiki conferma Paperino: SLM era un software interno di cui non si trova traccia (ma va' ), VSS e' stato commercializzato durante gli anni '90 e primi 2000 per essere poi soppiantato da SourceDepot, un derivato di Perforce, durante lo sviluppo di XP (quindi 1999-2000). Coding Horror ha scritto un libello contro VSS dal titolo Anything but SourceSafe, chiamandolo un software obsoleto fermo agli anni '90 peggiore di CVS: nessuna meraviglia che fosse adottato da pochi progetti in MS, piu' stupore per l'uso da parte di terzi. L'ultimo e' Team Foundation Sever (TFS) e' l'ultimo arrivato e Microsoft lo consiglia come sostituto di VSS.

In breve: SLM e SourceDepot sono prodoti per uso interno, mai venduti e dubito siano reperibili tramite canali al limite della legalita'; VSS e' stato commercializzato in passato e TFS lo e' ora (trial a 90 gg).

 

Edward

   
6. il nonno
martedì 3 novembre 2009 alle 4:11 PM - chrome 3.0.195.27 Windows 7
   

Confermo per esperianza personale che VSS fosse un prodotto terrificante...

   
7. Gabriele
martedì 3 novembre 2009 alle 9:41 PM - firefox 3.5.4 Ubuntu 9.10
   

 @Edward

Mi ero stupito perché Mercurial mi sembrava una scelta assai illuminata.

Voglio dire, non conosco nessuno degli altri prodotti, ma al di là delle loro funzionalità sembrano essere molto "integrati", ossia impongono molti requisiti sul tuo "ecosistema": integrazione fantastica con VS ma solo con quello, dati in SQL Server (e solo quello, magari anche in una certa versione), IIS per forza, importazione/esportazione in Excel (brividi, brividi) e così via.

Così se magari ti piace solo una parte del "pacchetto" sei costretto a prenderlo per intero o a farne a meno

Mercurial invece è agnostico in questo (perché mai un SCM ti dovrebbe imporre l'ide con cui editi i file?).

Mi domandavo se in MS avessero mai pensato di usare qualcosa del tipo di Mercurial, magari con delle patch.

   
8. Edward
martedì 3 novembre 2009 alle 10:52 PM - firefox 3.5.4 Windows 7
   

@ Gabriele:

Secondo me la risposta risiede in due aspetti:

1) Mercurial serve a Paperino per i suoi progetti (Blogoo e forse altri) e lo ha scelto proprio perche' e' distribuito (crea un mirror locale del repository) e gli consente di lavorare ovunque. Microsoft non e' coinvolta;

2) Le soluzioni Microsoft sono fortemente integrate con gli altri software dell'azienda, decisamente Windows-centriche; inoltre la politica aziendale e' ricorrere il piu' possibile ai propri prodotti, anche a quelli in sviluppo: in una parola, dogfooding. Probabilmente l'estrema specificita' di TFS e la dipendenza dagli SQL/Excel/ecc non e' percepita come uno svantaggio ma e' indice di una forte integrazione con i software usati quotidianamente dai programmatori per Windows. In altri termini, l'indipendenza di Mercurial sarebbe piu' un demerito che un pregio.

E' probabile che i team di progetti non collegati a Windows (es Office per Mac, .Net/Mono, collaborazioni, ecc.) usino altri vcs: sono curioso di conoscerli.

 

Edward

   
Lascia un commento:
Commento: (clicca su questo link per gli smiley supportati; regole di ingaggio per i commenti)
(opzionale, per il Gravatar)