L’aspetto più importante che dovete tenere presente per qualsiasi modello è il grado di conformità ai bisogni e alle capacità delle persone che lo useranno. Questo potrebbe sembrare ovvio, ma in ogni caso non potete comunque permettervi di dimenticarvelo nemmeno per un momento.

Una volta mi capitò di comporre un modello di workflow che a me sembrava perfettamente sensato, ma che provocò una notevole quantità di litigi e parecchia costernazione tra i membri del mio gruppo di sviluppo. Nonostante i miei tentativi di spiegare perché avessimo bisogno di un insieme complesso di ramificazioni e come i cambiamenti dovessero circolare tra i rami, alcuni membri del gruppo si ribellarono. Sebbene fossero persone intelligenti, non volevano fare attenzione ai vincoli sotto i quali stavamo operando, né affrontare le conseguenze di quei vincoli sui dettagli del modello che stavo difendendo.

Evitate di nascondere sotto il tappeto i prevedibili problemi di tipo tecnico o sociale. Qualunque schema adottiate, dovreste avere un piano per affrontare errori e scenari problematici. Prendete in considerazione l’idea di aggiungere meccanismi automatici per prevenire o risolvere velocemente i problemi che siete in grado di anticipare. Per esempio, se intendete avere un ramo con cambiamenti che non desiderate rilasciare al pubblico, fareste meglio a pensare fin dall’inizio alla possibilità che qualcuno possa accidentalmente incorporare quei cambiamenti in un ramo di release. Potete evitare questo particolare problema implementando un hook che prevenga l’unione di cambiamenti da rami non appropriati.

Non vorrei suggerire che un approccio in cui «tutto è permesso» sia qualcosa di sostenibile, ma è un modello che è facile da capire e funziona perfettamente in alcune situazioni inusuali.

Per esempio, molti progetti hanno un gruppo sparpagliato di collaboratori che si incontrano fisicamente solo di rado. Alcuni gruppi preferiscono superare l’isolamento del lavoro a distanza organizzando «maratone» occasionali in cui un certo numero di persone si ritrova insieme in un’unico luogo (la stanza delle riunioni di un’azienda, la sala delle conferenze in un hotel, posti di questo tipo) e passa diversi giorni più o meno chiuso lì, a lavorare intensamente su una manciata di progetti.

Una maratona o una sessione di programmazione in un locale sono le occasioni perfette per usare il comando hg serve, dato che hg serve non richiede alcuna infrastruttura server elaborata. Potete cominciare a usare hg serve in pochi minuti, leggendo la sezione chiamata «Condivisione informale con hg serve» più avanti. Poi vi basta comunicare ai vostri vicini l’esistenza di un server in esecuzione, fargli sapere l’URL a cui devono collegarsi, e avrete un modo rapido da predisporre per lavorare insieme. Gli altri potranno digitare il vostro URL nel proprio browser e revisionare velocemente i vostri cambiamenti, o estrarre la correzione di un bug dal vostro repository e verificarla, o clonare un ramo contenente una nuova funzione e provarla.

Il fascino, e allo stesso tempo il problema, di fare le cose ad hoc in questo modo è che solo le persone che sanno dell’esistenza dei vostri cambiamenti e sanno dove trovarli possono vederli. Un approccio informale di questo tipo non riesce proprio a scalare oltre una manciata di persone, perché ogni individuo ha bisogno di conoscere n diversi repository da cui estrarre modifiche.

Per progetti di dimensioni ridotte che stanno migrando da uno strumento centralizzato di controllo di revisione, forse il modo più facile per cominciare è far passare i cambiamenti attraverso un singolo repository centrale condiviso. Questo è anche il più comune «mattone da costruzione» per schemi di workflow più ambiziosi.

I collaboratori cominciano clonando una copia di questo repository, potendo estrarne i cambiamenti ogni volta che ne hanno bisogno. Alcuni sviluppatori (forse tutti) hanno il permesso di trasmettere le modifiche al repository quando sono pronte per essere viste da altre persone.

In questo modello, può ancora avere senso che alcune persone propaghino i cambiamenti direttamente tra loro, senza passare dal repository centrale. Considerate il caso in cui io ho creato una correzione sperimentale di un bug, ma sono preoccupato che, se la pubblicassi sul repository centrale, tutti gli altri possano successivamente danneggiare i propri alberi nel momento in cui la estraggono. Per ridurre il danno potenziale, posso chiedervi di clonare temporaneamente il mio repository in un vostro repository privato e di collaudare la correzione. Questo ci permette di rimandare la pubblicazione di cambiamenti potenzialmente pericolosi fino a quando non hanno subìto una ragionevole verifica.

Se un gruppo sta mantenendo il repository sui propri server in questo tipo di scenario, di solito i membri useranno il protocollo ssh per trasmettere in sicurezza i cambiamenti al repository centrale, come documentato nella sezione chiamata «Usare il protocollo di Shell Sicura (ssh)». Di solito, viene anche pubblicata una copia del repository in sola lettura via HTTP, come nella sezione chiamata «Condividere i dati attraverso HTTP usando CGI». Pubblicare via HTTP soddisfa le necessità di chi non ha accesso in scrittura e di chi preferisce usare un browser per navigare la cronologia del repository.

Una caratteristica meravigliosa dei servizi di hosting come Bitbucket è che non solo si occupano di gestire i dettagli della configurazione del server, come gli account utente, l’autenticazione e i protocolli sicuri di rete, ma offrono anche un’infrastruttura aggiuntiva per far funzionare al meglio questo modello.

Per esempio, un servizio di hosting ben ingegnerizzato consentirà agli sviluppatori di clonare le proprie copie di un repository con un singolo clic, in modo da farli lavorare in spazi separati e lasciarli condividere i propri cambiamenti quando sono pronti.

In più, un buon servizio di hosting permetterà ai propri utenti di comunicare tra loro, per esempio per segnalare che «questo albero contiene modifiche pronte per la tua revisione».

Qualsiasi progetto di dimensioni significative tende a fare progressi su più fronti contemporaneamente. Nel caso del software, un progetto passa comunemente attraverso una serie di release ufficiali periodiche. Una release potrebbe andare in fase di «manutenzione» per un po’ dopo la sua prima pubblicazione, finendo per contenere solo correzioni di bug, senza che vengano aggiunte nuove funzioni. Una o più release future potrebbero trovarsi in lavorazione in parallelo a queste revisioni di manutenzione. Normalmente le persone usano il termine «ramo» (in inglese, branch) per indicare una di queste direzioni leggermente differenti in cui lo sviluppo sta procedendo.

Mercurial è particolarmente adatto a gestire un certo numero di rami paralleli ma non identici. Ogni «direzione di sviluppo» può vivere nel proprio repository centrale e voi potete unire cambiamenti dall’uno all’altro repository quando ne avete bisogno. Dato che i repository sono tra loro indipendenti, i cambiamenti instabili in un ramo di sviluppo non avranno mai effetto su un ramo stabile a meno che qualcuno incorpori esplicitamente quei cambiamenti nel ramo stabile.

Ecco un esempio di come questo processo può funzionare in pratica. Diciamo che avete un «ramo principale» su un server centrale.

$ hg init principale
$ cd principale
$ echo 'Questa è una funzione noiosa.' > miofile
$ hg commit -A -m "Abbiamo raggiunto una pietra miliare importante!"
aggiungo miofile

Altre persone lo clonano, effettuano modifiche locali, le collaudano e le trasmettono indietro.

Una volta che il ramo principale raggiunge la milestone (letteralmente, pietra miliare) di una release, potete usare il comando hg tag per dare un nome permanente alla revisione di milestone.

$ hg tag v1.0
$ hg tip
changeset:   1:be452d95a1d0
etichetta:   tip
utente:      Bryan O'Sullivan <[email protected]>
data:        Fri Jun 05 15:49:15 2009 +0000
sommario:    Aggiunta l'etichetta v1.0 per il changeset c93791f54ca9

$ hg tags
tip                                1:be452d95a1d0
v1.0                               0:c93791f54ca9

Diciamo che alcune modifiche esterne vengono effettuate sul ramo principale.

$ cd ../principale
$ echo 'Questa è nuova ed eccitante!' >> miofile
$ hg commit -m "Aggiunge una nuova funzione."
$ cat miofile
Questa è una funzione noiosa.
Questa è nuova ed eccitante!

Grazie all’etichetta registrata sulla milestone, chi clonerà quel repository in futuro potrà usare hg update per ottenere una copia della directory di lavoro nello stato esatto in cui si trovava quando quella revisione etichettata è stata inserita.

$ cd ..
$ hg clone -U principale principale-vecchio
$ cd principale-vecchio
$ hg update v1.0
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ cat miofile
Questa è una funzione noiosa.

In più, immediatamente dopo che il ramo principale è stato etichettato, possiamo clonare il ramo principale sul server creando un nuovo ramo «stabile», anche quello sul server.

$ cd ..
$ hg clone -rv1.0 principale stabile
richiedo tutte le modifiche
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 1 cambiamenti a 1 file
aggiorno la directory di lavoro
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti

Se abbiamo bisogno di fare una modifica al ramo stabile, possiamo clonare quel repository, fare i nostri cambiamenti, effettuarne il commit e trasmetterli indietro a quello stesso repository.

$ hg clone stabile stabile-con-correzione
aggiorno la directory di lavoro
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$ cd stabile-con-correzione
$ echo 'Questa è una correzione a una funzione noiosa.' > miofile
$ hg commit -m "Corretto un bug."
$ hg push
trasmetto a /tmp/stabile
cerco i cambiamenti
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 1 cambiamenti a 1 file

Dato che i repository Mercurial sono indipendenti e che Mercurial non sposta automaticamente i cambiamenti da un repository a un altro, il ramo principale e quello stabile sono isolati tra loro. I cambiamenti che abbiamo fatto al ramo principale non «filtreranno» verso il ramo stabile e viceversa.

Vorremo spesso che tutte le nostre correzioni di bug nel ramo stabile compaiano anche nel ramo principale. Piuttosto che riscrivere una correzione sul ramo principale, possiamo semplicemente estrarre i cambiamenti dal ramo stabile e unirli a quello principale, così sarà Mercurial a introdurre per noi quelle correzioni di bug.

$ cd ../principale
$ hg pull ../stabile
estraggo da ../stabile
cerco i cambiamenti
aggiungo i changeset
aggiungo i manifest
aggiungo i cambiamenti ai file
aggiunti 1 changeset con 1 cambiamenti a 1 file (+1 teste)
(eseguite 'hg heads' per vedere le teste, 'hg merge' per unire)
$ hg merge
unisco miofile
0 file aggiornati, 1 file uniti, 0 file rimossi, 0 file irrisolti
(unione tra rami, ricordatevi di eseguire il commit)
$ hg commit -m "Incorpora la correzione del bug dal ramo stabile."
$ cat miofile
Questa è una correzione a una funzione noiosa.
Questa è nuova ed eccitante!

Il ramo principale conterrà ancora cambiamenti che non sono presenti nel ramo stabile, ma conterrà anche tutte le correzioni di bug provenienti dal ramo stabile. Il ramo stabile non viene toccato da quei cambiamenti, dato che le modifiche stanno passando solo dal ramo stabile a quello principale e non nell’altra direzione.

Per progetti di dimensioni più grandi, un modo efficace per gestire i cambiamenti è quello di dividere un gruppo in piccoli sottogruppi. Ogni sottogruppo gestisce un proprio ramo condiviso, clonato da un singolo ramo «principale» usato dall’intero progetto. Le persone che lavorano su un singolo ramo sono tipicamente piuttosto isolate dagli sviluppi che avvengono negli altri rami.

Figura 6.1. Rami di funzione

Quando si ritiene che una funzione particolare sia in una forma appropriata, qualche membro del sottogruppo di quella funzione estrae i cambiamenti dal ramo principale e li unisce al ramo della funzione, poi trasmette le modifiche indietro al ramo principale.

L’organizzazione di alcuni progetti può ricordare quella di un «treno»: le release sono fissate a intervalli di alcuni mesi e includono tutte le funzioni che sono pronte quando il «treno» è pronto a partire.

Questo modello assomiglia all’impiego dei rami di funzione, tranne per il fatto che quando un ramo di funzione perde un treno, qualche membro del gruppo di quella funzione estrae i cambiamenti che sono partiti con il treno della release e li unisce al ramo della funzione. Così, il gruppo continua a lavorare partendo da quella release, in modo che la funzione di cui è responsabile possa essere inclusa nella release successiva.

Il modello di sviluppo del kernel di Linux è caratterizzato da una struttura gerarchica poco profonda circondata da una nuvola di caos apparente. Dato che la maggior parte degli sviluppatori Linux usa git, uno strumento distribuito di controllo di revisione con caratteristiche simili a Mercurial, è utile descrivere come si lavora in quell’ambiente in modo che, se le idee vi piacciono, possiate tradurre il metodo da uno strumento all’altro.

Al centro della comunità siede Linus Torvalds, il creatore di Linux. Linus pubblica un singolo repository di sorgenti che è considerato il ramo «autoritativo» corrente dall’intera comunità di sviluppo. Chiunque può clonare l’albero di Linus, ma Linus è piuttosto selettivo per quanto riguarda gli alberi da cui estrae le modifiche.

Linus ha un certo numero di «luogotenenti di fiducia». Come regola generale, estrae qualunque cambiamento gli trasmettano, nella maggior parte dei casi senza nemmeno revisionare quelle modifiche. Alcuni di quei luogotenenti hanno accettato il ruolo di «manutentori» responsabili di specifici sottosistemi del kernel. Se un programmatore qualsiasi vuole che la propria modifica a un sottosistema del kernel finisca nell’albero di Linus, deve trovare il manutentore di quel sottosistema e chiedergli di accettarla. Se il manutentore revisiona le modifiche e accetta di prenderle, le passerà a Linus al momento giusto.

Ogni singolo luogotenente segue il proprio metodo per revisionare, accettare e pubblicare le modifiche, e per decidere quando passarle a Linus. In più, esistono diversi rami ben noti che vengono usati per scopi differenti. Per esempio, alcune persone mantengono repository «stabili» di vecchie versioni del kernel alle quali applicano correzioni critiche quando è necessario. Alcuni manutentori pubblicano molteplici alberi: uno per modifiche sperimentali, uno per cambiamenti che stanno per passare in alto, e così via. Altri pubblicano semplicemente un singolo albero.

Questo modello ha due caratteristiche importanti. La prima è quella di essere «a sola estrazione». Dovete chiedere, convincere, o implorare un altro sviluppatore di prendere una modifica da voi, perché non c’è quasi nessun albero a cui più di una persona possa trasmettere e non c’è modo di trasmettere cambiamenti a un albero controllato da qualcun altro.

La seconda è quella di essere basato su reputazione e approvazione. Se siete sconosciuti, Linus probabilmente ignorerà le vostre modifiche senza nemmeno rispondervi. Ma il manutentore di un sottosistema probabilmente le revisionerà e sarà disposto ad accettarle se rispettano i suoi criteri di conformità. Più modifiche «buone» presentate a un manutentore, più è probabile che si fidi del vostro giudizio e accetti i vostri cambiamenti. Se siete ben conosciuti e mantenete un ramo di lunga data per qualcosa che Linus non ha ancora accettato, le persone con interessi simili potranno incorporare regolarmente i vostri cambiamenti per rimanere aggiornati sul vostro lavoro.

Reputazione e approvazione non oltrepassano necessariamente i confini tecnici e sociali di un sottosistema. Se siete un programmatore rispettato ma specializzato nell’ambito della memorizzazione dei dati e provate a correggere un bug relativo all’infrastruttura di rete, un manutentore del sottosistema esaminerà minuziosamente quel cambiamento come se fosse stato realizzato da un completo sconosciuto.

Alle persone che provengono da esperienze con progetti più ordinari, il processo di sviluppo relativamente caotico del kernel di Linux sembra spesso completamente folle: subisce i capricci dei singoli, le persone apportano radicali cambiamenti ogni volta che lo ritengono opportuno e la velocità di sviluppo è sorprendente. Nonostante questo, Linux è un software molto apprezzato e di grande successo.

Nella comunità open source si tenta continuamente di stabilire, attraverso accese discussioni, se un modello di sviluppo in cui le persone non fanno altro che estrarre cambiamenti le une dalle altre sia «meglio» di un modello in cui più persone possono trasmettere modifiche a un repository condiviso.

Tipicamente, i sostenitori del modello a scrittura condivisa usano strumenti che impongono attivamente questo approccio. Se state usando uno strumento centralizzato di controllo di revisione come Subversion, non c’è alcun modo di scegliere il modello che userete: lo strumento vi fornisce un modello a scrittura condivisa e se volete fare qualcos’altro dovete strutturare il vostro metodo al di sopra di quel modello (per esempio, applicando una patch a mano).

Un buon sistema distribuito di controllo di revisione supporterà entrambi i modelli. Voi e i vostri collaboratori potrete quindi organizzare il modo di lavorare insieme sulla base dei vostri bisogni e delle vostre preferenze, non delle acrobazie a cui vi costringono gli strumenti.

Una volta che voi e il vostro gruppo avete configurato qualche repository condiviso e cominciato a propagare cambiamenti avanti e indietro tra i repository locali e quelli condivisi, comincerete ad affrontare una sfida correlata ma leggermente differente: quella di gestire le diverse direzioni in cui il vostro gruppo potrebbe muoversi contemporaneamente. Anche se questa materia è intimamente legata al modo in cui il vostro gruppo collabora, è abbastanza densa da meritare una trattazione separata, nel Capitolo 8, Gestire le release e lo sviluppo con i rami.

Dato che hg serve fornisce un accesso non autenticato in lettura a tutti i client, dovreste usarlo solo in un ambiente in cui non vi interessa, o potete interamente controllare, chi può accedere alla vostra rete ed estrarre dati dal vostro repository.

Il comando hg serve non sa nulla del firewall che potreste avere installato a protezione del vostro sistema o della vostra rete: non è in grado di scoprire se avete un firewall né di controllarlo. Se altre persone non riescono ad accedere a un’istanza di hg serve in esecuzione, la seconda cosa che dovreste fare (dopo aver verificato che stiano usando l’URL corretto) è controllare la configurazione del vostro firewall.

Per default, hg serve accetta connessioni in entrata sulla porta 8000. Se un altro processo sta già occupando la porta che volete usare, potete specificare una porta differente tramite l’opzione -p.

Normalmente, quando hg serve parte, non stampa alcuna informazione, cosa che potrebbe intimidirvi. Se volete avere una conferma che il comando stia eseguendo correttamente, e volete scoprire l’esatto URL che dovreste inviare ai vostri collaboratori, lanciate hg serve con l’opzione -v.

Un URL ssh tende ad avere la forma seguente:

ssh://[email protected]:22/hg/libro

Si rischia facilmente di fare confusione con il percorso locale contenuto negli URL ssh, dato che gli strumenti non hanno un modo standard per interpretarlo. Alcuni programmi si comportano in modo diverso rispetto ad altri quando operano su questi percorsi. Questa non è una situazione ideale, ma è difficile che possa cambiare, quindi leggete il paragrafo seguente con la dovuta attenzione.

Mercurial tratta il percorso di un repository sul server come se fosse relativo alla directory personale dell’utente remoto. Per esempio, se l’utente foo possiede una directory personale /home/foo sul server, allora un URL ssh che contiene un percorso bar si riferisce in realtà alla directory /home/foo/bar.

Se volete specificare un percorso relativo alla directory personale di un altro utente, potete usare un percorso che comincia con un carattere di tilde seguito dal nome utente (chiamiamolo altroutente) in questo modo.

ssh://server/~altroutente/hg/repo

E se proprio volete specificare un percorso assoluto sul server, iniziate il percorso con due caratteri di slash, come in questo esempio.

ssh://server//percorso/assoluto

Quasi tutti i sistemi di tipo Unix includono un’installazione di OpenSSH. Se state usando uno di questi sistemi, eseguite which ssh per scoprire se il comando ssh è installato (di solito si trova nella directory /usr/bin). Nell’improbabile eventualità in cui non sia presente, date un’occhiata alla documentazione del vostro sistema per capire come installarlo.

Su Windows, il pacchetto TortoiseHg comprende una versione dell’eccellente comando plink, realizzato da Simon Tatham, che non dovrebbe avere bisogno di ulteriori configurazioni.

Per evitare di dover ripetutamente digitare una password ogni volta che avete bisogno di usare il vostro client ssh, vi suggerisco di generare una coppia di chiavi.

	Le coppie di chiavi non sono obbligatorie
	Mercurial non sa nulla di autenticazione ssh o coppie di chiavi. Se volete, potete tranquillamente ignorare questa sezione e quella che segue fino a quando non vi stancherete di digitare ripetutamente le password ssh.

Quando generate una coppia di chiavi, di solito è altamente raccomandabile proteggerla con una frase di accesso chiamata passphrase. (L’unico caso in cui potreste non volerlo fare è quando state usando il protocollo ssh per attività automatiche su una rete sicura.)

In ogni caso, generare semplicemente la coppia di chiavi non basta, ma dovrete aggiungere la chiave pubblica all’insieme di chiavi autorizzate che appartiene a qualsiasi utente vogliate utilizzare per accedere al server remoto. Per i server che usano OpenSSH (la grande maggioranza), questo significa aggiungere la chiave pubblica a una lista contenuta in un file chiamato authorized_keys nella directory .ssh dell’utente.

Su un sistema di tipo Unix, la vostra chiave pubblica avrà una estensione .pub. Se state usando puttygen su Windows, potete salvare la chiave pubblica in un file di vostra scelta, o copiarla dalla finestra in cui è visualizzata e incollarla direttamente nel file authorized_keys.

Un agente di autenticazione è un demone che tiene le passphrase in memoria (quindi le dimenticherà se uscite dal sistema e poi rientrate). Un client ssh noterà se un agente è in esecuzione e gli richiederà una passphrase. Se non c’è alcun agente di autenticazione attivo, o se l’agente non ha memorizzato la passphrase necessaria, dovrete digitare la vostra passphrase ogni volta che Mercurial prova a comunicare con il server per vostro conto (per esempio, ogni volta che estraete o trasmettete cambiamenti).

Lo svantaggio di memorizzare le passphrase in un agente è che un aggressore ben preparato sarebbe in grado di recuperare il testo in chiaro delle vostre passphrase, a volte anche se il vostro sistema è stato riavviato. Dovreste giudicare da voi se questo è un rischio che potete correre. Di certo, un agente vi permette di risparmiare tempo evitandovi di digitare ripetutamente sempre lo stesso testo.

Dato che ssh può essere complicato da configurare se non siete esperti, un certo numero di cose potrebbero andare storte. Aggiungete Mercurial a tutto questo, e le possibilità di fare confusione aumenteranno ulteriormente. La maggior parte di questi potenziali problemi si presenta sul lato server, non sul lato client. La buona notizia è che, una volta che avete una configurazione funzionante, di solito continuerà a funzionare indefinitamente.

Prima di provare a usare Mercurial per comunicare con un server ssh, è preferibile che vi assicuriate di poter usare i normali comandi ssh o putty per contattare il server. Se incontrate problemi usando direttamente questi comandi, Mercurial sicuramente non funzionerà e in più nasconderà il problema sottostante. Ogni volta che avete un problema relativo a ssh con Mercurial, per cominciare dovreste accertarvi nuovamente che i semplici comandi ssh lato client funzionino prima di preoccuparvi di eventuali problemi con Mercurial.

La prima cosa di cui accertarsi sul lato server è che siate in grado di entrare nel sistema da un’altra macchina. Se non potete usare ssh o putty per entrare, il messaggio di errore che vi viene mostrato potrebbe darvi alcuni suggerimenti per capire che cosa non va. I problemi più comuni sono i seguenti.

Riepilogando, se avete problemi di comunicazione con il demone ssh del server, per prima cosa assicuratevi che ne esista uno in esecuzione. Su molti sistemi sarà installato ma disabilitato per default. Una volta che avete compiuto questo passo, dovreste controllare che il firewall del server sia configurato per consentire connessioni in entrata verso la porta su cui il demone ssh si trova in ascolto (di solito, la 22). Non preoccupatevi di altri errori di configurazione più esotici fino a quando non avete controllato questi due.

Se state usando un agente di autenticazione sul lato client per memorizzare le passphrase per le vostre chiavi, dovreste essere in grado di accedere al server senza che vi vengano chieste una passphrase o una password. Se vi viene comunque richiesta una passphrase, ecco alcune possibili cause.

Se vi viene richiesta la password per l’utente remoto, ecco altri possibili cause.

In un mondo ideale, dovreste essere in grado di eseguire il comando seguente con successo e ottenere come risultato la stampa di una riga contenente la data e l’ora correnti.

ssh mioserver date

Se gli script di accesso sul vostro server stampano messaggi informativi o altri tipi di testo anche quando eseguite comandi non interattivi come questo, dovreste correggerli prima di continuare, in modo che stampino solo se vengono eseguiti interattivamente. Altrimenti, questi messaggi come minimo confonderanno le stampe di Mercurial e nel caso peggiore potrebbero causare problemi durante l’esecuzione remota dei comandi Mercurial. Mercurial prova a individuare e ignorare questi messaggi durante le sessioni ssh non interattive, ma non è infallibile. (Se state modificando i vostri script di accesso sul vostro server, potete vedere se uno script di accesso viene eseguito in una shell interattiva controllando il codice restituito dal comando tty -s.)

Dopo aver verificato che il buon vecchio ssh stia funzionando con il vostro server, il passo successivo è quello di assicurarsi che Mercurial sia in esecuzione sul server. Il comando seguente dovrebbe terminare con successo:

ssh mioserver hg version

Se vedete un messaggio di errore invece del normale risultato di hg version, di solito questo accade perché non avete installato Mercurial in /usr/bin. Se questo è il caso, non preoccupatevi: non avete bisogno di farlo. Ma dovreste controllare alcuni possibili problemi.

Se riuscite a eseguire hg version attraverso una connessione ssh, ben fatto! Siete riusciti a configurare il client e il server. Ora dovreste essere in grado di usare Mercurial per accedere ai repository ospitati da quel nome utente su quel server. Se a questo punto incontrate qualche problema con Mercurial e ssh, provate a usare l’opzione --debug per avere un’immagine più chiara di quello che sta succedendo.

Mercurial non comprime i dati quando usa il protocollo ssh, perché il protocollo ssh può comprimere i dati in maniera trasparente. Tuttavia, il comportamento predefinito dei client ssh è quello di non richiedere la compressione.

Su qualsiasi rete diversa da una LAN veloce (persino una rete wireless), è probabile che l’uso della compressione velocizzi significativamente le operazioni di rete di Mercurial. Per esempio, qualcuno ha misurato che la compressione riduce il tempo necessario per creare un repository particolarmente grande attraverso una WAN da 51 minuti a 17 minuti.

Sia ssh che plink richiedono l’opzione -C per attivare la compressione. Potete facilmente modificare il vostro file ~/.hgrc in modo da abilitare la compressione per tutti gli utilizzi del protocollo ssh da parte di Mercurial. Per esempio, ecco come fare per l’ordinario comando ssh sui sistemi di tipo Unix.

[ui]
ssh = ssh -C

Se usate ssh su un sistema di tipo Unix, potete configurarlo per usare sempre la compressione quando comunicate con il vostro server. Per fare questo, modificate il vostro file .ssh/config (che potrebbe anche non esistere) come segue.

Host hg
  Compression yes
  HostName hg.example.com

Questo definisce l’alias hg per il nome della macchina. Quando usate l’alias sulla riga di comando ssh o in un URL ssh di Mercurial, ssh si connetterà a hg.example.com e userà la compressione. In questo modo, potete ottenere sia un nome più corto da digitare sia la compressione, che dal canto loro sono entrambe buone cose.

Prima di proseguire, prendetevi qualche momento per controllare alcuni aspetti delle impostazioni del vostro sistema.

Se non avete un server web installato e non avete una considerevole esperienza nel configurare Apache, dovreste considerare l’uso del server web lighttpd invece di Apache. Le configurazioni di Apache hanno la reputazione ben meritata di essere complicate e di confondere gli utenti. Sebbene Apache sia dotato di un numero maggiore di funzioni rispetto a lighttpd, buona parte di queste funzioni non è rilevante per servire repository Mercurial. E lighttpd è innegabilmente molto più facile da affrontare di Apache.

Su sistemi di tipo Unix, di solito gli utenti hanno una sottodirectory con un nome simile a public_html nella propria directory personale da cui possono servire pagine web. Un file chiamato foo in questa directory sarà accessibile tramite un URL della forma http://www.example.com/~nomeutente/foo.

Per cominciare, prendete lo script hgweb.cgi che dovrebbe essere presente nella vostra installazione di Mercurial. Se non riuscite a trovarne velocemente una copia sul vostro sistema, scaricatela da uno dei principali repository di Mercurial all’indirizzo http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi.

Dovrete copiare questo script nella vostra directory public_html e assicurarvi che sia eseguibile.

cp .../hgweb.cgi ~/public_html
chmod 755 ~/public_html/hgweb.cgi

L’argomento 755 passato a chmod ha un effetto un po’ più generale rispetto a quello di rendere lo script eseguibile: garantisce che lo script sia eseguibile da chiunque e che i permessi di scrittura per il «gruppo» e gli «altri» non siano concessi. Se lasciaste abilitati quei permessi, probabilmente il sottosistema suexec di Apache si rifiuterebbe di eseguire lo script. In effetti, suexec insiste sul fatto che anche la directory in cui risiede lo script non sia modificabile da altri.

chmod 755 ~/public_html

chmod 755 ~
find ~/public_html -type d -print0 | xargs -0r chmod 755
find ~/public_html -type f -print0 | xargs -0r chmod 644

<Directory /home/*/public_html>
  AllowOverride FileInfo AuthConfig Limit
  Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
  <Limit GET POST OPTIONS>
    Order allow,deny
    Allow from all
  </Limit>
  <LimitExcept GET POST OPTIONS>
    Order deny,allow Deny from all
  </LimitExcept>
</Directory>

AddHandler cgi-script .cgi

userdir.path = "public_html"
cgi.assign = (".cgi" => "" )

Lo script hgweb.cgi ha una fastidiosa restrizione che vi permette solo di pubblicare un singolo repository. Se volete pubblicarne più di uno senza complicarvi la vita con molteplici copie dello stesso script, ognuna con un nome diverso, la scelta migliore è quella di usare lo script hgwebdir.cgi.

La procedura per configurare hgwebdir.cgi è solo leggermente più complicata di quella per hgweb.cgi. Per prima cosa, dovete ottenere una copia dello script. Se non ne avete una sottomano, potete scaricala dal repository principale di Mercurial all’indirizzo http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi.

Dovrete copiare questo script nella vostra directory public_html e assicurarvi che sia eseguibile.

cp .../hgwebdir.cgi ~/public_html
chmod 755 ~/public_html ~/public_html/hgwebdir.cgi

Una volta effettuata questa configurazione di base, provando a visitare http://nomemacchina/~nomeutente/hgwebdir.cgi con il vostro browser, dovreste vedere una lista di repository vuota. Se ottenete una finestra bianca o un messaggio di errore, provate a ripercorrere la lista di possibili problemi già vista nella sezione chiamata «Che cosa potrebbe andare storto?».

Lo script hgwebdir.cgi si basa su un file di configurazione esterno. Per default, cerca un file chiamato hgweb.config nella stessa directory in cui si trova. Dovrete creare questo file e renderlo leggibile agli altri. Il formato di questo file è simile a quello di un file «ini» di Windows, riconoscibile dal modulo ConfigParser [ConfigParser] di Python.

Il modo più facile di configurare hgwebdir.cgi è tramite una sezione chiamata collections che vi consentirà di pubblicare automaticamente tutti i repository contenuti nelle directory che nominate. La sezione dovrebbe somigliare a questa:

[collections]
/mia/radice = /mia/radice

Mercurial la interpreta guardando al nome della directory sul lato destro del segno «=», individuando i repository nella gerarchia contenuta in quella directory e usando il testo sul lato sinistro per eliminare il testo corrispondente dai nomi che elencherà effettivamente nell’interfaccia web. I componenti del percorso che rimangono dopo questa eliminazione formano un «percorso virtuale».

Dato l’esempio precedente, se abbiamo un repository il cui percorso locale è /mia/radice/questo/repository, lo script CGI eliminerà la parte /mia/radice iniziale dal nome e pubblicherà il repository con il percorso virtuale questo/repository. Se l’URL per il nostro script CGI è http://nomemacchina/~nomeutente/hgwebdir.cgi, l’URL completo per quel repository sarà http://nomemacchina/~nomeutente/hgwebdir.cgi/questo/repository.

Se sostituiamo /mia/radice sul lato sinstro di questo esempio con /mia, allora hgwebdir.cgi eliminerà solo /mia dal nome del repository e ci darà il percorso virtuale radice/questo/repository invece di questo/repository.

Lo script hgwebdir.cgi cercherà i repository ricorsivamente in ogni directory elencata nella sezione collections del suo file di configurazione, ma non navigherà ricorsivamente nei repository che trova.^[4]

Il meccanismo delle collezioni nella sezione collections facilita la pubblicazione di molti repository in modalità «spara e dimentica». Dovete impostare lo script CGI e il file di configurazione una volta sola, dopodiché potete pubblicare o ritirare un repository in ogni momento semplicemente spostandolo dentro o fuori dalla gerarchia di directory in cui hgwebdir.cgi è configurato per guardare.

Specificare esplicitamente quali repository pubblicare

In aggiunta al meccanismo basato su collections, lo script hgwebdir.cgi vi consente di pubblicare una lista specifica di repository. Per fare questo, create una sezione paths con un contenuto simile al seguente.

[paths]
repo1 = /mio/percorso/vero/qualche/repository
repo2 = /qualche/percorso/verso/un/altro

In questo caso, il percorso virtuale (il componente che apparirà in un URL) è sul lato sinistro di ogni definizione, mentre il percorso del repository è sulla destra. Notate che non c’è bisogno che esista alcuna relazione tra il percorso virtuale che scegliete e l’ubicazione di un repository sul vostro file system.

Se lo desiderate, potete usare entrambe le sezioni collections e paths contemporaneamente in un unico file di configurazione.

	Fate attenzione ai percorsi virtuali duplicati
	Se diversi repository hanno lo stesso percorso virtuale, hgwebdir.cgi non segnalerà un errore, ma si comporterà in maniera imprevedibile.

L’interfaccia web di Mercurial permette agli utenti di scaricare un archivio di qualsiasi revisione. Questo archivio conterrà la fotografia della directory di lavoro scattata su quella revisione, ma non conterrà una copia dei dati del repository.

Per default, questa funzione è disabilitata. Per abilitarla, dovrete aggiungere un elemento allow_archive alla sezione web del vostro file ~/.hgrc come spiegato in dettaglio nella prossima sezione.

Le interfacce web di Mercurial (il comando hg serve e gli script hgweb.cgi e hgwebdir.cgi) hanno un certo numero di opzioni di configurazione che potete impostare. Queste opzioni appartengono a una sezione chiamata web.

Se state usando hgwebdir.cgi, potete inserire gli elementi di configurazione motd e style nella sezione web del file hgweb.config invece che nel file ~/.hgrc, nel caso lo troviate più conveniente.

Un file hgrc globale può essere utile nella situazione in cui gli utenti stanno estraendo cambiamenti posseduti da altri utenti. Per default, Mercurial non si fida della maggior parte degli elementi di configurazione contenuti nel file .hg/hgrc all’interno di un repository che è posseduto da un utente differente. Se cloniamo o estraiamo i cambiamenti da un repository di questo tipo, Mercurial stamperà un avvertimento dicendo che non si fida dei dati nel file .hg/hgrc di quel repository.

Se tutti i membri di uno specifico gruppo Unix fanno parte dello stesso gruppo di sviluppo e dovrebbero fidarsi l’uno delle impostazioni di configurazione dell’altro, o se vogliamo fidarci di alcuni utenti particolari, possiamo rimpiazzare il comportamento guardingo predefinito di Mercurial creando un file hgrc di sistema come il seguente:

# Salva questo file con un nome tipo /etc/mercurial/hgrc.d/trust.rc
[trusted]
# Fidati di tutte le voci in qualsiasi file hgrc posseduto
# dai gruppi "editors" o "www-data"
groups = editors, www-data

# Fidati delle voci nei file hgrc posseduti dai seguenti utenti.
users = apache, bobo