| rev |
line source |
|
Giulio@743
|
1 <chapter id="cha:collab">
|
|
Giulio@743
|
2 <?dbhtml filename="collaborare-con-altre-persone.html"?>
|
|
Giulio@743
|
3 <title>Collaborare con altre persone</title>
|
|
Giulio@743
|
4
|
|
Giulio@743
|
5 <para id="x_44a">Come strumento completamente decentralizzato, Mercurial non impone alcuna politica su come le persone dovrebbero lavorare insieme. Tuttavia, se siete nuovi al controllo di revisione distribuito, può aiutarvi avere alcuni strumenti ed esempi in mente quando state pensando a possibili modelli di ~workflow~.</para>
|
|
Giulio@743
|
6
|
|
Giulio@743
|
7 <sect1>
|
|
Giulio@743
|
8 <title>L'interfaccia web di Mercurial</title>
|
|
Giulio@743
|
9
|
|
Giulio@743
|
10 <para id="x_44b">Mercurial è dotato di una potente interfaccia web che fornisce diverse utili capacità.</para>
|
|
Giulio@743
|
11
|
|
Giulio@743
|
12 <para id="x_44c">Per l'uso interattivo, l'interfaccia web vi permette di navigare un singolo repository o una collezione di repository. Potete vedere la cronologia di un repository, esaminare qualsiasi cambiamento (con i commenti e le differenze) e vedere il contenuto di qualsiasi file o directory. Potete persino ottenere una vista della cronologia che vi dà una visualizzazione grafica delle relazioni tra le unioni e i singoli cambiamenti.</para>
|
|
Giulio@743
|
13
|
|
Giulio@743
|
14 <para id="x_44d">Sempre per il consumo umano, l'interfaccia web fornisce feed RSS e Atom dei cambiamenti in un repository. Questo vi permette di <quote>abbonarvi</quote> a un repository usando il vostro lettore di feed preferito e di venire automaticamente notificati delle attività in quel repository appena accadono. Trovo questa possibilità molto più conveniente rispetto al modello di iscrizione a una mailing list a cui sono spedite le notifiche, in quanto non richiede alcuna configurazione aggiuntiva dalla parte di chiunque stia servendo il repository.</para>
|
|
Giulio@743
|
15
|
|
Giulio@743
|
16 <para id="x_44e">L'interfaccia web permette agli utenti remoti anche di clonare un repository, estrarne i cambiamenti e (quando il server è configurato per permetterlo) trasmettervi le proprie modifiche. Il ~tunneling~ di Mercurial sul protocollo HTTP comprime aggressivamente i dati, in modo da lavorare con grande efficienza persino attraverso connessioni di rete a banda ridotta.</para>
|
|
Giulio@743
|
17
|
|
Giulio@743
|
18 <para id="x_44f">Il modo più facile di cominciare a usare l'interfaccia web è quello di usare il vostro browser per visitare un repository esistente, come il repository principale di Mercurial all'indirizzo <ulink url="http://www.selenic.com/repo/hg">http://www.selenic.com/repo/hg</ulink>.</para>
|
|
Giulio@743
|
19
|
|
Giulio@743
|
20 <para id="x_450">Se siete interessati a fornire un'interfaccia web ai vostri repository, esistono diversi buoni modi per farlo.</para>
|
|
Giulio@743
|
21
|
|
Giulio@743
|
22 <para id="x_69d">Il modo più facile e veloce di cominciare in un ambiente informale è quello di usare il comando <command role="hg-cmd">hg serve</command>, che è particolarmente adatto a un servizio <quote>leggero</quote> a breve termine. Leggete la <xref linkend="sec:collab:serve"/> più avanti per i dettagli su come usare questo comando.</para>
|
|
Giulio@743
|
23
|
|
Giulio@743
|
24 <para id="x_69e">Per repository con una vita più lunga che vorreste mantenere disponibili permanentemente, esistono diversi servizi di ~hosting~ pubblici che potete usare. Alcuni sono gratis per progetti open source, mentre altri offrono un ~hosting~ commerciale a pagamento. Una lista aggiornata di questi servizi è disponibile all'indirizzo <ulink url="http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting">http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting</ulink>.</para>
|
|
Giulio@743
|
25
|
|
Giulio@743
|
26 <para id="x_6a0">Se invece preferite ~host~ i vostri repository, Mercurial è dotato di un supporto predefinito per diverse tecnologie di ~hosting~ popolari, in particolar modo CGI (acronimo di Common Gateway Interface) e WSGI (acronimo di Web Services Gateway Interface). Leggete la <xref linkend="sec:collab:cgi"/> per i dettagli sulle configurazioni di CGI e WSGI.</para>
|
|
Giulio@743
|
27 </sect1>
|
|
Giulio@743
|
28
|
|
Giulio@743
|
29 <sect1>
|
|
Giulio@743
|
30 <title>Modelli di collaborazione</title>
|
|
Giulio@743
|
31
|
|
Giulio@743
|
32 <para id="x_451">Con uno strumento adeguatamente flessibile, prendere decisioni sul ~workflow~ è molto più una sfida di ingegneria sociale che tecnica. Mercurial impone poche limitazioni su come potete strutturare il flusso di lavoro in un progetto, quindi sta a voi e al vostro gruppo impostare e procedere con un modello che corrisponda ai vostri particolari bisogni.</para>
|
|
Giulio@743
|
33
|
|
Giulio@743
|
34 <sect2>
|
|
Giulio@743
|
35 <title>Fattori da tenere a mente</title>
|
|
Giulio@743
|
36
|
|
Giulio@743
|
37 <para id="x_452">L'aspetto più importante di qualsiasi modello che dovete tenere a mente è quando bene corrisponde ai bisogni e alle capacità delle persone che le useranno. Questo potrebbe sembrare ovvio, ma anche così non potete comunque permettervi di dimenticarvelo nemmeno per un momento.</para>
|
|
Giulio@743
|
38
|
|
Giulio@743
|
39 <para id="x_453">Una volta ho messo insieme un modello di ~workflow~ che sembrava avere perfettamente senso per me, ma che ha causato una quantità considerevole di costernazione e litigi tra i membri del mio gruppo di sviluppo. Nonostante i miei tentativi di spiegare perché avessimo bisogno di un insieme complesso di ramificazioni, e di come i cambiamenti dovessero scorrere tra loro, 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 nei dettagli del modello che stavo difendendo.</para>
|
|
Giulio@743
|
40
|
|
Giulio@743
|
41 <para id="x_454">Evitate di nascondere i problemi sociali e tecnici prevedibili sotto il tappeto. Qualunque schema adottiate, dovreste pianificare per errori e scenari problematici. Prendete in considerazione l'idea di aggiungere meccanismi automatici per prevenire, o rimediare velocemente, i problemi che siete in grado di anticipare. Per esempio, se intendete avere un ramo con cambiamenti non-per-rilascio, fareste meglio a pensare fin dall'inizio alla possibilità che qualcuno possa accidentalmente incorporare quei cambiamenti in un ramo di rilascio. Potete evitare questo particolare problema scrivendo un ~hook~ che prevenga l'unione di cambiamenti da rami non appropriati.</para>
|
|
Giulio@743
|
42 </sect2>
|
|
Giulio@743
|
43
|
|
Giulio@743
|
44 <sect2>
|
|
Giulio@743
|
45 <title>Anarchia informale</title>
|
|
Giulio@743
|
46
|
|
Giulio@743
|
47 <para id="x_455">Non vorrei suggerire un approccio <quote>~anything goes~</quote> come qualcosa di sostenibile, ma è un modello che è facile da capire e funziona perfettamente in alcune situazioni inusuali.</para>
|
|
Giulio@743
|
48
|
|
Giulio@743
|
49 <para id="x_456">Per esempio, molti progetti hanno un gruppo ~loose-knit~ di collaboratori che solo di rado si incontrano fisicamente. Alcuni gruppi preferiscono superare l'isolamento del lavoro a distanza organizzando occasionali <quote>maratone</quote>. In una maratona, un certo numero di persone si ritrova insieme in un'unico posto (la stanza delle conferenze di un'azienda, la stanza di incontri in un hotel, posti di questo tipo) e passano diversi giorni più o meno chiusi lì, a lavorare intensamente su una manciata di progetti.</para>
|
|
Giulio@743
|
50
|
|
Giulio@743
|
51 <para id="x_457">Una maratona o una sessione di programmazione in un caffè sono le occasioni perfette per usare il comando <command role="hg-cmd">hg serve</command>, dato che <command role="hg-cmd">hg serve</command> non richiede alcuna infrastruttura server elaborata. Potete cominciare a usare <command role="hg-cmd">hg serve</command> in pochi momenti, leggendo la <xref linkend="sec:collab:serve"/> più avanti. Poi vi basta dire alle persone vicino a voi che state eseguendo un server, mandare l'URL in un messaggio istantaneo, e avrete un modo ~quick-turnaround~ per lavorare insieme. Loro 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 funzionalità e provarla.</para>
|
|
Giulio@743
|
52
|
|
Giulio@743
|
53 <para id="x_458">Il fascino, e 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 a una manciata di persone, perché ogni individuo ha bisogno di conoscere <emphasis>n</emphasis> diversi repository da cui estrarre modifiche.</para>
|
|
Giulio@743
|
54 </sect2>
|
|
Giulio@743
|
55
|
|
Giulio@743
|
56 <sect2>
|
|
Giulio@743
|
57 <title>Un singolo repository centrale</title>
|
|
Giulio@743
|
58
|
|
Giulio@743
|
59 <para id="x_459">Per progetti più piccoli che stanno migrando da uno strumento centralizzato di controllo di revisione, forse il modo più facile per cominciare è far fluire i cambiamenti attraverso un singolo repository centrale condiviso. Questo è anche il più comune <quote>mattone da costruzione</quote> per schemi di ~workflow~ più ambiziosi.</para>
|
|
Giulio@743
|
60
|
|
Giulio@743
|
61 <para id="x_45a">I collaboratori cominciano clonando una copia di questo repository. Possono estrarre i cambiamenti da esso ogni volta che ne hanno bisogno, e alcuni (forse tutti) sviluppatori hanno il permesso di trasmettere le modifiche al repository quando sono pronte per essere viste da altre persone.</para>
|
|
Giulio@743
|
62
|
|
Giulio@743
|
63 <para id="x_45b">In questo modello, può ancora aver senso per alcune persone propagare i cambiamenti direttamente tra loro, senza passare dal repository centrale. Considerate il caso in cui io ho una possibile correzione di un bug, ma sono preoccupato che, se la pubblicassi sul repository centrale, potrebbe successivamente danneggiare gli alberi di tutti gli altri nel momento in cui la estraggono. Per ridurre il danno potenziale, posso chiedervi di clonare il mio repository in un vostro repository temporaneo privato e collaudare la correzione. Questo ci permette di riandare la pubblicazione di cambiamenti potenzialmente pericolosi fino a quando hanno subito un ragionevole collaudo.</para>
|
|
Giulio@743
|
64
|
|
Giulio@743
|
65 <para id="x_45c">Se un gruppo sta ~hosting~ il proprio repository in questo tipo di scenario, di solito le persone useranno il protocollo <command>ssh</command> per trasmettere in sicurezza i cambiamenti al repository centrale, come documentato nella <xref linkend="sec:collab:ssh"/>. Di solito, viene anche pubblicata una copia del repository in sola lettura via HTTP, come nella <xref linkend="sec:collab:cgi"/>. Pubblicare via HTTP soddisfa il bisogno di persone che non hanno accesso in scrittura e di quelli che vogliono usare un browser per navigare la cronologia del repository.</para>
|
|
Giulio@743
|
66 </sect2>
|
|
Giulio@743
|
67
|
|
Giulio@743
|
68 <sect2>
|
|
Giulio@743
|
69 <title>Un repository centrale ~hosted~</title>
|
|
Giulio@743
|
70
|
|
Giulio@743
|
71 <para id="x_6a1">Una cosa meravigliosa dei servizi ~hosting~ come <ulink url="http://bitbucket.org/">Bitbucket</ulink> è 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.</para>
|
|
Giulio@743
|
72
|
|
Giulio@743
|
73 <para id="x_6a2">Per esempio, un servizio ~hosting~ ben ingegnerizzato permetterà alle persone di clonare le proprie copie di un repository con un singolo clic, in modo da lasciarli lavorare in spazi separati e condividere i propri cambiamenti quando sono pronti.</para>
|
|
Giulio@743
|
74
|
|
Giulio@743
|
75 <para id="x_6a3">In più, un buon servizio ~hosting~ permetterà alle persone di comunicare tra loro, per esempio per dire <quote>ci sono modifiche pronte per la tua revisione in questo albero</quote>.</para>
|
|
Giulio@743
|
76 </sect2>
|
|
Giulio@743
|
77
|
|
Giulio@743
|
78 <sect2>
|
|
Giulio@743
|
79 <title>Lavorare con più rami</title>
|
|
Giulio@743
|
80
|
|
Giulio@743
|
81 <para id="x_45d">Qualsiasi progetto di dimensioni significative tende a fare progressi su più fronti simultaneamente. Nel caso del software, è comune per un progetto passare attraverso periodiche release ufficiali. Una release potrebbe andare in <quote>mantenimento</quote> per un po' dopo la sua prima pubblicazione; le release in fase di <quote>mantenimento</quote> tendono a contenere solo correzioni di bug, non nuove funzionalità. In parallelo a queste revisioni di mantenimento, una o più release future potrebbero essere in lavorazione. Le persone normalmente usano il termine <quote>ramo</quote> per riferirsi a una di queste direzioni leggermente differenti in cui lo sviluppo sta procedendo.</para>
|
|
Giulio@743
|
82
|
|
Giulio@743
|
83 <para id="x_45e">Mercurial è particolarmente adatto a gestire un certo numero di rami simultanei ma non identici. Ogni <quote>direzione di sviluppo</quote> può vivere nel proprio repository centrale, e voi potete unire cambiamenti dall'uno all'altro quando ne avete bisogno. Dato che i repository sono tra loro indipendenti, 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.</para>
|
|
Giulio@743
|
84
|
|
Giulio@743
|
85 <para id="x_45f">Ecco un esempio di come questo può funzionare nella pratica. Diciamo che avete un <quote>ramo principale</quote> su un server centrale.</para>
|
|
Giulio@743
|
86
|
|
Giulio@743
|
87 &interaction.branching.init;
|
|
Giulio@743
|
88
|
|
Giulio@743
|
89 <para id="x_460">Le persone lo clonano, effettuano modifiche locali, le collaudano e le trasmettono indietro.</para>
|
|
Giulio@743
|
90
|
|
Giulio@743
|
91 <para id="x_461">Una volta che il ramo principale raggiunge la pietra miliare di una release, potete usare il comando <command role="hg-cmd">hg tag</command> per dare un nome permanente alla revisione pietra miliare.</para>
|
|
Giulio@743
|
92
|
|
Giulio@743
|
93 &interaction.branching.tag;
|
|
Giulio@743
|
94
|
|
Giulio@743
|
95 <para id="x_462">Diciamo che alcuni sviluppi esterni accodono sul ramo principale.</para>
|
|
Giulio@743
|
96
|
|
Giulio@743
|
97 &interaction.branching.main;
|
|
Giulio@743
|
98
|
|
Giulio@743
|
99 <para id="x_463">Usando l'etichetta registrata sulla pietra miliare, le persone che clonano quel repository in qualsiasi momento nel futuro possono usare <command role="hg-cmd">hg update</command> per ottenere una copia della directory di lavoro esattamente com'era quando quella revisoine etichettata è stata inserita.</para>
|
|
Giulio@743
|
100
|
|
Giulio@743
|
101 &interaction.branching.update;
|
|
Giulio@743
|
102
|
|
Giulio@743
|
103 <para id="x_464">In più, immediatamente dopo che il ramo principale è stato etichettato, possiamo clonare il ramo principale sul server in un nuovo ramo <quote>stabile</quote>, anche quello sul server.</para>
|
|
Giulio@743
|
104
|
|
Giulio@743
|
105 &interaction.branching.clone;
|
|
Giulio@743
|
106
|
|
Giulio@743
|
107 <para id="x_465">Se abbiamo bisogno di fare una modifica al ramo stabile, possiamo clonare <emphasis>quel</emphasis> repository, fare i nostri cambiamenti, effettuarne il commit, e trasmetterli là.</para>
|
|
Giulio@743
|
108
|
|
Giulio@743
|
109 &interaction.branching.stable;
|
|
Giulio@743
|
110
|
|
Giulio@743
|
111 <para id="x_466">Dato che repository Mercurial sono indipendenti e che Mercurial non sposta i cambiamenti in giro automaticamente, il ramo principale e quello stabile sono <emphasis>isolati</emphasis> tra loro. I cambiamenti che abbiamo fatto al ramo principale non <quote>filtreranno</quote> verso il ramo stabile e viceversa.</para>
|
|
Giulio@743
|
112
|
|
Giulio@743
|
113 <para id="x_467">Vorremo spesso che tutte le nostre correzioni di bug nel ramo stabile apparissero anche nel ramo principale. Piuttosto che riscrivere una correzione sul ramo stabile, possiamo semplicemente estrarre e unire i cambiamenti dal ramo stabile a quello principale, e Mercurial introdurrà quelle correzioni di bug per noi.</para>
|
|
Giulio@743
|
114
|
|
Giulio@743
|
115 &interaction.branching.merge;
|
|
Giulio@743
|
116
|
|
Giulio@743
|
117 <para id="x_468">Il ramo principale conterrà ancora modifiche che non sono presenti nel ramo stabile, ma conterrà anche tutte le correzioni provenienti dal ramo stabile. Il ramo stabile rimane inalterato da quei cambiamenti, dato che i cambiamenti stanno solo fluendo dal ramo stabile a quello principale e non nell'altra direzione.</para>
|
|
Giulio@743
|
118 </sect2>
|
|
Giulio@743
|
119
|
|
Giulio@743
|
120 <sect2>
|
|
Giulio@743
|
121 <title>Rami di funzionalità</title>
|
|
Giulio@743
|
122
|
|
Giulio@743
|
123 <para id="x_469">Per progetti più grandi, un modo efficace di gestire i cambiamenti è quello di dividere un gruppo in piccoli gruppi. Ogni gruppo ha un proprio ramo condiviso, clonato da un singolo ramo <quote>principale</quote> usato dall'intero progetto. Le persone che lavorano su un singolo ramo sono tipicamente piuttosto isolate dagli sviluppi che accadono negli altri rami.</para>
|
|
Giulio@743
|
124
|
|
Giulio@743
|
125 <figure id="fig:collab:feature-branches">
|
|
Giulio@743
|
126 <title>Rami di funzionalità</title>
|
|
Giulio@743
|
127 <mediaobject>
|
|
Giulio@743
|
128 <imageobject><imagedata width="100%" fileref="figs/feature-branches.png"/></imageobject>
|
|
Giulio@743
|
129 <textobject><phrase>XXX add text</phrase></textobject>
|
|
Giulio@743
|
130 </mediaobject>
|
|
Giulio@743
|
131 </figure>
|
|
Giulio@743
|
132
|
|
Giulio@743
|
133 <para id="x_46b">Quando si ritiene che una funzionalità particolare sia in una forma appropriata, qualcuno nel gruppo di quella funzionalità estrae e unisce i cambiamenti dal ramo principale al ramo della funzionalità, poi trasmette le modifiche indietro al ramo principale.</para>
|
|
Giulio@743
|
134 </sect2>
|
|
Giulio@743
|
135
|
|
Giulio@743
|
136 <sect2>
|
|
Giulio@743
|
137 <title>Il treno delle release</title>
|
|
Giulio@743
|
138
|
|
Giulio@743
|
139 <para id="x_46c">L'organizzazione di alcuni progetti può ricordare quella di un <quote>treno</quote>: le release sono fissate a intervalli di alcuni mesi, e tutte le funzionalità che sono pronte quando il <quote>treno</quote> è pronto a partire vengono incluse.</para>
|
|
Giulio@743
|
140
|
|
Giulio@743
|
141 <para id="x_46d">Questo modello assomiglia a lavorare con i rami di funzionalità. La differenza è che quando un ramo di funzionalità perde un treno, qualcuno nel gruppo di quella funzionalità estrae e unisce i cambiamenti che sono partiti con il treno della release nel ramo della funzionalità, e il gruppo continua il proprio lavoro a partire da quella release in modo che la loro funzionalità possa essere inclusa nella release successiva.</para>
|
|
Giulio@743
|
142 </sect2>
|
|
Giulio@743
|
143
|
|
Giulio@743
|
144 <sect2>
|
|
Giulio@743
|
145 <title>Il modello del kernel di Linux</title>
|
|
Giulio@743
|
146
|
|
Giulio@743
|
147 <para id="x_46e">Il modello di sviluppo del kernel di Linux ha una struttura gerarchica poco profonda, circondata da una nuvola di caos apparente. Dato che la maggior parte degli sviluppatori Linux usa <command>git</command>, uno strumento distribuito di controllo di revisione con caratteristiche simili a Mercurial, è utile descrivere il modo in cui il lavoro fluisce in quell'ambiente; se le idee vi piacciono, l'approccio si traduce bene attraverso gli strumenti.</para>
|
|
Giulio@743
|
148
|
|
Giulio@743
|
149 <para id="x_46f">Al centro della comunità siede Linus Torvalds, il creatore di Linux. Pubblica un singolo repository di sorgenti che è considerato il ramo <quote>autoritativo</quote> 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.</para>
|
|
Giulio@743
|
150
|
|
Giulio@743
|
151 <para id="x_470">Linus ha un numero di <quote>luogotenenti fidati</quote>. Come regola generale, estrae qualunque cambiamento gli trasmettano, nella maggior parte dei casi senza nemmeno revisionare quei cambiamenti. Alcuni di quei luogotenenti hanno accettato il ruolo di <quote>manutentori</quote> responsabili di specifici sottosistemi del kernel. Se un qualsiasi programmatore del kernel vuole fare una modifica a un sottosistema che vuole finisca nell'albero di Linus, deve trovare chi è il manutentore di quel sottosistema e chiedergli di accettare il suo cambiamento. Se il manutentore revisiona le modifiche e accetta di prenderle, le passerà a Linus al momento giusto.</para>
|
|
Giulio@743
|
152
|
|
Giulio@743
|
153 <para id="x_471">Ogni singolo luogotenente ha il proprio approccio per revisionare, accettare e pubblicare le modifiche, e per decidere quando passarle a Linus. In più, ci sono diversi rami ben noti che le persone usano per scopi differenti. Per esempio, alcune persone mantengono repository <quote>stabili</quote> 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.</para>
|
|
Giulio@743
|
154
|
|
Giulio@743
|
155 <para id="x_472">Questo modello ha due caratteristiche importanti. La prima è quella di essere <quote>a sola estrazione</quote>. Dovete chiedere, convincere, o implorare un altro sviluppatore di prendere una modifica da voi, perché non c'è quasi nesusn albero a cui più di una persona possa trasmettere, e non c'è modo di trasmettere cambiamenti a un albero controllato da qualcun altro.</para>
|
|
Giulio@743
|
156
|
|
Giulio@743
|
157 <para id="x_473">La seconda è quella di essere basato su reputazione e acclamazione. 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 passano i suoi criteri di adeguatezza. Più modifiche <quote>buone</quote> contribuite 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 ai vostri potranno incorporare i vostri cambiamenti regolarmente per rimanere aggiornati sul vostro lavoro.</para>
|
|
Giulio@743
|
158
|
|
Giulio@743
|
159 <para id="x_474">Reputazione e acclamazione non necessariamente oltrepassano i confini tecnici e sociali di un sottosistema. Se siete un programmatore di ~storage~ rispettato ma specializzato e provate a correggere un bug di ~networking~, quel cambiamento riceverà un esame minuzioso da un manutentore di rete paragonabile a quello di un cambiamento realizzato da un completo sconosciuto.</para>
|
|
Giulio@743
|
160
|
|
Giulio@743
|
161 <para id="x_475">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 appropriato e il ritmo di sviluppo è sorprendente. E però Linux è un software di grande successo e ben considerato.</para>
|
|
Giulio@743
|
162 </sect2>
|
|
Giulio@743
|
163
|
|
Giulio@743
|
164 <sect2>
|
|
Giulio@743
|
165 <title>Collaborazione in sola lettura o in scrittura condivisa</title>
|
|
Giulio@743
|
166
|
|
Giulio@743
|
167 <para id="x_476">Una continua fonte di accese discussioni nella comunità open source è se un modello di sviluppo in cui le persone non fanno altro che estrarre cambiamenti le une dalle altre è <quote>meglio</quote> di un modello in cui più persone possono trasmettere modifiche a un repository condiviso.</para>
|
|
Giulio@743
|
168
|
|
Giulio@743
|
169 <para id="x_477">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 dà un modello a scrittura condivisa e se volete fare qualcos'altro dovete produrre il vostro approccio sopra a quel modello (per esempio, applicando una patch a mano).</para>
|
|
Giulio@743
|
170
|
|
Giulio@743
|
171 <para id="x_478">Un buon sistema distribuito di controllo di revisione supporterà entrambi i modelli. Voi e i vostri collaboratori poterete quindi strutturare il modo di lavorare insieme sulla base dei vostri bisogni e delle vostre preferenze, non sulle contorsioni a cui vi costringono gli strumenti.</para>
|
|
Giulio@743
|
172 </sect2>
|
|
Giulio@743
|
173 <sect2>
|
|
Giulio@743
|
174 <title>Dove la collaborazione incontra la gestione dei rami</title>
|
|
Giulio@743
|
175
|
|
Giulio@743
|
176 <para id="x_479">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 <!--<xref linkend="chap:branch"/>-->FIXME.</para>
|
|
Giulio@743
|
177 </sect2>
|
|
Giulio@743
|
178 </sect1>
|
|
Giulio@743
|
179
|
|
Giulio@743
|
180 <sect1>
|
|
Giulio@743
|
181 <title>Il lato tecnico della condivisione</title>
|
|
Giulio@743
|
182
|
|
Giulio@743
|
183 <para id="x_47a">Il resto di questo capitolo è dedicato alla questione di condividere i cambiamenti con i vostri collaboratori.</para>
|
|
Giulio@743
|
184 </sect1>
|
|
Giulio@743
|
185
|
|
Giulio@743
|
186 <sect1 id="sec:collab:serve">
|
|
Giulio@743
|
187 <title>Condivisione informale con <command role="hg-cmd">hg serve</command></title>
|
|
Giulio@743
|
188
|
|
Giulio@743
|
189 <para id="x_47b">Il comando <command role="hg-cmd">hg serve</command> di Mercurial è meravigliosamente adatto per ambienti di gruppo piccoli, ~tight-knit (localizzati?)~ e ~fast-paced (veloci?)~. Fornisce anche un fantastico modo di ottenere la sensazione per l'uso dei comandi Mercurial attraverso la rete.</para>
|
|
Giulio@743
|
190
|
|
Giulio@743
|
191 <para id="x_47c">Eseguite <command role="hg-cmd">hg serve</command> all'interno di un repository e in meno di un secondo verrà attivato un server HTTP specializzato che accetterà connessioni da qualunque client e servirà i dati per quel repository fino a quando non lo terminerete. Chiunque conosca l'URL del server che avete appena attivato e sia in grado di accedere al vostro computer attraverso la rete potrà usare un browser web o lo stesso Mercurial per leggere i dati da quel repository. Un URL corrispondente a un'istanza di <command role="hg-cmd">hg serve</command> in esecuzione su un laptop somiglierà probabilmente a qualcosa come <literal>http://my-laptop.local:8000/</literal>.</para>
|
|
Giulio@743
|
192
|
|
Giulio@743
|
193 <para id="x_47d">Il comando <command role="hg-cmd">hg serve</command> non è un server web ~general-purpose~, ma può fare solo due cose:</para>
|
|
Giulio@743
|
194 <itemizedlist>
|
|
Giulio@743
|
195 <listitem><para id="x_47e">Consentire alle persone di usare il proprio browser web per navigare la cronologia del repository che sta servendo.</para>
|
|
Giulio@743
|
196 </listitem>
|
|
Giulio@743
|
197 <listitem><para id="x_47f">Parlare il protocollo di rete di Mercurial, in modo che le persone possano usare comandi come <command role="hg-cmd">hg clone</command> o <command role="hg-cmd">hg pull</command> su quel repository.</para>
|
|
Giulio@743
|
198 </listitem></itemizedlist>
|
|
Giulio@743
|
199 <para id="x_480">In particolare, <command role="hg-cmd">hg serve</command> non permetterà agli utenti di <emphasis>modificare</emphasis> il vostro repository, perché è stato pensato per un uso in sola lettura.</para>
|
|
Giulio@743
|
200
|
|
Giulio@743
|
201 <para id="x_481">Se state appena cominciando a usare Mercurial, non c'è nulla che vi impedisca di usare <command role="hg-cmd">hg serve</command> per servire un repository sul vostro computer, poi usare comandi come <command role="hg-cmd">hg clone</command>, <command role="hg-cmd">hg incoming</command> e così via per comunicare con quel server come se il repository fosse situato su una macchina remota. Questo può aiutarvi a familiarizzare velocemente con l'utilizzo dei comandi su repository ospitati in rete.</para>
|
|
Giulio@743
|
202
|
|
Giulio@743
|
203 <sect2>
|
|
Giulio@743
|
204 <title>Alcune cose da tenere a mente</title>
|
|
Giulio@743
|
205
|
|
Giulio@743
|
206 <para id="x_482">Dato che fornisce un accesso non autenticato in lettura a tutti i client, dovreste usare <command role="hg-cmd">hg serve</command> solo in un ambiente in cui non vi interessa, o avete completo controllo su, chi può accedere alla vostra rete ed estrarre dati dal vostro repository.</para>
|
|
Giulio@743
|
207
|
|
Giulio@743
|
208 <para id="x_483">Il comando <command role="hg-cmd">hg serve</command> 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 <command role="hg-cmd">hg serve</command> in esecuzione, la seconda cosa che dovreste fare (<emphasis>dopo</emphasis> aver controllato che stiano usando l'URL corretto) è controllare la configurazione del vostro firewall.</para>
|
|
Giulio@743
|
209
|
|
Giulio@743
|
210 <para id="x_484">Di default, <command role="hg-cmd">hg serve</command> 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 <option role="hg-opt-serve">-p</option>.</para>
|
|
Giulio@743
|
211
|
|
Giulio@743
|
212 <para id="x_485">Normalmente, quando <command role="hg-cmd">hg serve</command> parte, non stampa alcuna informazione, cosa che potrebbe intimidirvi. Se volete avere una conferma che il comando stia eseguendo correttamente, e trovare l'esatto URL che dovreste inviare ai vostri collaboratori, lanciate <command role="hg-cmd">hg serve</command> con l'opzione <option role="hg-opt-global">-v</option>.</para>
|
|
Giulio@743
|
213 </sect2>
|
|
Giulio@743
|
214 </sect1>
|
|
Giulio@743
|
215
|
|
Giulio@743
|
216 <sect1 id="sec:collab:ssh">
|
|
Giulio@743
|
217 <title>Usare il protocollo di Shell Sicura (ssh)</title>
|
|
Giulio@743
|
218
|
|
Giulio@743
|
219 <para id="x_486">Potete estrarre e trasmettere cambiamenti in sicurezza attraverso la rete usando il protocollo di Shell Sicura (<literal>ssh</literal>). Per usarlo con successo, potreste dover fare un po' di configurazione sia sul lato client che sul lato server.</para>
|
|
Giulio@743
|
220
|
|
Giulio@743
|
221 <para id="x_487">Se non avete familiarità con ssh, è il nome sia di un comando che di un protocollo di rete che vi permette di comunicare in sicurezza con un altro computer. Per usarlo con Mercurial, dovrete impostare uno o più account utente su un server in maniera che gli utenti remoti possano entrare ed eseguire comandi.</para>
|
|
Giulio@743
|
222
|
|
Giulio@743
|
223 <para id="x_488">(Se <emphasis>avete</emphasis> familiarità con ssh, probabilmente troverete elementare parte del materiale che segue.)</para>
|
|
Giulio@743
|
224
|
|
Giulio@743
|
225 <sect2>
|
|
Giulio@743
|
226 <title>Come leggere e scrivere URL ssh</title>
|
|
Giulio@743
|
227
|
|
Giulio@743
|
228 <para id="x_489">Un URL ssh tende a somigliare al seguente:</para>
|
|
Giulio@743
|
229 <programlisting>ssh://bos@hg.serpentine.com:22/hg/hgbook</programlisting>
|
|
Giulio@743
|
230 <orderedlist>
|
|
Giulio@743
|
231 <listitem><para id="x_48a">La parte <quote><literal>ssh://</literal></quote> dice a Mercurial di usare il protocollo ssh.</para>
|
|
Giulio@743
|
232 </listitem>
|
|
Giulio@743
|
233 <listitem><para id="x_48b">Il componente <quote><literal>bos@</literal></quote> indica con quale nome utente accedere al server. Potete ometterlo se il nome utente remoto è lo stesso del vostro nome utente locale.</para>
|
|
Giulio@743
|
234 </listitem>
|
|
Giulio@743
|
235 <listitem><para id="x_48c"><quote><literal>hg.serpentine.com</literal></quote> vi dà il nome del server a cui accedere.</para>
|
|
Giulio@743
|
236 </listitem>
|
|
Giulio@743
|
237 <listitem><para id="x_48d"><quote>:22</quote> idenifica il numero di porta del server a cui connettersi. La porta predefinita è la 22, quindi dovete utilizzare il carattere di due punti e il numero di porta solo se <emphasis>non</emphasis> state usando la porta 22.</para>
|
|
Giulio@743
|
238 </listitem>
|
|
Giulio@743
|
239 <listitem><para id="x_48e">Il resto dell'URL è il percorso locale del repository sul server.</para>
|
|
Giulio@743
|
240 </listitem></orderedlist>
|
|
Giulio@743
|
241
|
|
Giulio@743
|
242 <para id="x_48f">C'è ampio spazio per confusione con il componente del percorso 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.</para>
|
|
Giulio@743
|
243
|
|
Giulio@743
|
244 <para id="x_490">Mercurial tratta il percorso a un repository sul server come relativo alla directory personale dell'utente remoto. Per esempio, se l'utente <literal>foo</literal> possiede una directory perosnale <filename class="directory">/home/foo</filename> sul server, allora un URL ssh che contenga un percorso di <filename class="directory">bar</filename> si riferisce <emphasis>in realtà</emphasis> alla directory <filename class="directory">/home/foo/bar</filename>.</para>
|
|
Giulio@743
|
245
|
|
Giulio@743
|
246 <para id="x_491">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 <literal>altroutente</literal>) in questo modo.</para>
|
|
Giulio@743
|
247 <programlisting>ssh://server/~altroutente/hg/repo</programlisting>
|
|
Giulio@743
|
248
|
|
Giulio@743
|
249 <para id="x_492">E se proprio volete specificare un percorso <emphasis>assoluto</emphasis> sul server, iniziate il percorso con due caratteri di slash, come in questo esempio.</para>
|
|
Giulio@743
|
250 <programlisting>ssh://server//percorso/assoluto</programlisting>
|
|
Giulio@743
|
251 </sect2>
|
|
Giulio@743
|
252
|
|
Giulio@743
|
253 <sect2>
|
|
Giulio@743
|
254 <title>Trovare un client ssh per il vostro sistema</title>
|
|
Giulio@743
|
255
|
|
Giulio@743
|
256 <para id="x_493">Quasi tutti i sistemi di tipo Unix includono una installazione di OpenSSH. Se state usando uno di questi sistemi, eseguite <literal>which ssh</literal> per scoprire se il comando <command>ssh</command> è installato (di solito si trova nella directory <filename class="directory">/usr/bin</filename>). Nell'improbabile eventualità in cui non sia presente, date un'occhiata alla documentazione del vostro sistema per capire come installarlo.</para>
|
|
Giulio@743
|
257
|
|
Giulio@743
|
258 <para id="x_494">Sotto Windows, il pacchetto TortoiseHg comprende una versione dell'eccellente comando <command>plink</command> realizzato da Simon Tatham, e non dovreste avere bisogno di ulteriori configurazioni.</para>
|
|
Giulio@743
|
259 </sect2>
|
|
Giulio@743
|
260
|
|
Giulio@743
|
261 <sect2>
|
|
Giulio@743
|
262 <title>Generare una coppia di chiavi</title>
|
|
Giulio@743
|
263
|
|
Giulio@743
|
264 <para id="x_499">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.</para>
|
|
Giulio@743
|
265
|
|
Giulio@743
|
266 <tip>
|
|
Giulio@743
|
267 <title>Le coppie di chiavi non sono obbligatorie</title>
|
|
Giulio@743
|
268
|
|
Giulio@743
|
269 <para id="x_6a4">Mercurial non sa nulla di autenticazione ssh o coppie di chiavi. Potete, se volete, tranquillamente ignorare questa sezione e quella che segue fino a quando non vi stancherete di digitare ripetutamente le password ssh.</para>
|
|
Giulio@743
|
270 </tip>
|
|
Giulio@743
|
271
|
|
Giulio@743
|
272 <itemizedlist>
|
|
Giulio@743
|
273 <listitem>
|
|
Giulio@743
|
274 <para id="x_6a5">Sotto un sistema di tipo Unix, il comando <command>ssh-keygen</command> dovrebbe funzionare.</para>
|
|
Giulio@743
|
275 <para id="x_6a6">Sotto Windows, se state usando TortoiseHg, potreste dover scaricare il comando <command>puttygen</command> dal <ulink url="http://www.chiark.greenend.org.uk/~sgtatham/putty">sito web di PuTTY</ulink> per generare una coppia di chiavi. Leggete la <ulink url="http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter8.html#pubkey-puttygen">documentazione di <command>puttygen</command></ulink> per i dettagli su come usare il comando.</para>
|
|
Giulio@743
|
276 </listitem>
|
|
Giulio@743
|
277 </itemizedlist>
|
|
Giulio@743
|
278
|
|
Giulio@743
|
279 <para id="x_49a">Quando generate una coppia di chiavi, di solito è <emphasis>altamente</emphasis> raccomandabile proteggerla con una passphrase. (L'unico caso in cui potreste non volerlo fare è quando state usando il protocollo ssh per attività automatiche su una rete sicura.)</para>
|
|
Giulio@743
|
280
|
|
Giulio@743
|
281 <para id="x_49b">Generare semplicemente la coppia di chiavi non basta, comunque. Dovrete aggiungere la chiave pubblica all'insieme di chiavi autorizzate per qualsiasi utente stiate utilizzando per accedere al server remoto. Per i server che usando OpenSSH (la grande maggioranza), questo significa aggiungere la chiave pubblica a una lista contenuta in un file chiamato <filename role="special">authorized_keys</filename> nella loro directory <filename role="special" class="directory">.ssh</filename>.</para>
|
|
Giulio@743
|
282
|
|
Giulio@743
|
283 <para id="x_49c">Su un sistema di tipo Unix, la vostra chiave pubblica avrà una estensione <filename>.pub</filename>. Se state usando <command>puttygen</command> sotto Windows, potete salvare la chiave pubblica in un file di vostra scelta, o incollarla dalla finestra in cui è visualizzata direttamente nel file <filename role="special">authorized_keys</filename>.</para>
|
|
Giulio@743
|
284 </sect2>
|
|
Giulio@743
|
285 <sect2>
|
|
Giulio@743
|
286 <title>Usare un agente di autenticazione</title>
|
|
Giulio@743
|
287
|
|
Giulio@743
|
288 <para id="x_49d">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 (e.g. ogni volta che estraete o trasmettete cambiamenti).</para>
|
|
Giulio@743
|
289
|
|
Giulio@743
|
290 <para id="x_49e">Lo svantaggio di memorizzare le passphrase in un agente è che un ~attacker~ ben preparato sarebbe in grado di recuperare il testo semplice delle vostre passphrase, in alcuni casi persino se il vostro sistema è stato riavviato. Dovreste giudicare da voi se questo è un rischio che potete correre. Di certo vi permette di risparmiare tempo evitandovi di digitare ripetutamente sempre lo stesso testo.</para>
|
|
Giulio@743
|
291
|
|
Giulio@743
|
292 <itemizedlist>
|
|
Giulio@743
|
293 <listitem>
|
|
Giulio@743
|
294 <para id="x_49f">Su sistemi di tipo Unix, l'agente è chiamato <command>ssh-agent</command> e spesso viene eseguito automaticamente quando entrate nel sistema. Dovrete usare il comando <command>ssh-add</command> per aggiungere una nuova passphrase alla memoria dell'agente.</para>
|
|
Giulio@743
|
295 </listitem>
|
|
Giulio@743
|
296 <listitem>
|
|
Giulio@743
|
297 <para id="x_6a7">Sotto Windows, se state usando TortoiseHg, il comando <command>pageant</command> funziona come un agente. Come con <command>puttygen</command>, avrete bisogno di <ulink url="http://www.chiark.greenend.org.uk/%7Esgtatham/putty/download.html">scaricare <command>pageant</command></ulink> dal sito web di PuTTY e di leggere <ulink url="http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter9.html#pageant">la sua documentazione</ulink>. Il comando <command>pageant</command> aggiunge un'icona alla vostra tray di sistema che vi permetterà di gestire le passphrase memorizzate.</para>
|
|
Giulio@743
|
298 </listitem>
|
|
Giulio@743
|
299 </itemizedlist>
|
|
Giulio@743
|
300 </sect2>
|
|
Giulio@743
|
301
|
|
Giulio@743
|
302 <sect2>
|
|
Giulio@743
|
303 <title>Configurare adeguatamente il server</title>
|
|
Giulio@743
|
304
|
|
Giulio@743
|
305 <para id="x_4a0">Dato che ssh può essere complicata da configurare se non siete esperti, un certo numero di cose potrebbero andare storte. Aggiungete Mercurial a tutto questo, e ci sarà ancora più spazio per grattate di testa. 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.</para>
|
|
Giulio@743
|
306
|
|
Giulio@743
|
307 <para id="x_4a1">Prima di provare a usare Mercurial per comunicare con un server ssh, è preferibile che prima vi assicuriate di poter usare i normali comandi <command>ssh</command> o <command>putty</command> per contattare il server. Se incorrete in problemi usando direttamente questi comandi, Mercurial sicuramente non funzionerà e quel che è peggio oscuerà il problema sottostante. Ogni volta che avete un problema relativo a ssh con Mercurial, per prima cosa dovreste accertarvi nuovamente che i semplici comandi ssh lato client funzionino <emphasis>prima</emphasis> di preoccuparvi di sapere se c'è un problema con Mercurial.</para>
|
|
Giulio@743
|
308
|
|
Giulio@743
|
309 <para id="x_4a2">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 <command>ssh</command> o <command>putty</command> per entrare, il messaggio di errore che vi viene mostrato potrebbe darvi alcuni suggerimenti per capire cosa c'è che non va. I problemi più comuni sono i seguenti.</para>
|
|
Giulio@743
|
310 <itemizedlist>
|
|
Giulio@743
|
311 <listitem><para id="x_4a3">Se avete un errore di tipo <quote>connection refused</quote> (connessione rifiutata), questo significa che non c'è alcun demone SSH in esecuzione sul server, o che il server è inaccessibile a causa della configurazione del firewall.</para>
|
|
Giulio@743
|
312 </listitem>
|
|
Giulio@743
|
313 <listitem><para id="x_4a4">Se avete un errore di tipo <quote>no route to host</quote> (???), questo significa che avete un indirizzo sbagliato per il server o un firewall seriamente chiuso che non ammetterà l'esistenza del server.</para>
|
|
Giulio@743
|
314 </listitem>
|
|
Giulio@743
|
315 <listitem><para id="x_4a5">Se avete un errore di tipo <quote>permission denied</quote> (permesso negato), potreste aver digitato in maniera incorretta il nome utente sul server, o la passphrase della vostra chiave, o la password dell'utente remoto.</para>
|
|
Giulio@743
|
316 </listitem></itemizedlist>
|
|
Giulio@743
|
317 <para id="x_4a6">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 di default. Una volta che avete compiuto questo passo, dovreste controllare che il firewall del server sia configurato per consentire connessioni in entrata sulla 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.</para>
|
|
Giulio@743
|
318
|
|
Giulio@743
|
319 <para id="x_4a7">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.</para>
|
|
Giulio@743
|
320 <itemizedlist>
|
|
Giulio@743
|
321 <listitem><para id="x_4a8">Potreste aver dimenticato di usare <command>ssh-add</command> o <command>pageant</command> per memorizzare la passphrase.</para>
|
|
Giulio@743
|
322 </listitem>
|
|
Giulio@743
|
323 <listitem><para id="x_4a9">Potreste aver memorizzato la passphrase per la chiave sbagliata.</para>
|
|
Giulio@743
|
324 </listitem></itemizedlist>
|
|
Giulio@743
|
325 <para id="x_4aa">Se vi viene richiesta la password per l'utente remoto, ecco altri possibili problemi da controllare.</para>
|
|
Giulio@743
|
326 <itemizedlist>
|
|
Giulio@743
|
327 <listitem><para id="x_4ab">La directory personale dell'utente o la sua directory <filename role="special" class="directory">.ssh</filename> potrebbero avere permessi eccessivamente liberali. Come risultato, il demone ssh non si fiderà né leggerà il file <filename role="special">authorized_keys</filename>. Per esempio, una directory personale o una directory <filename role="special" class="directory">.ssh</filename> con il permesso di scrittura per il gruppo dell'utente impostato causerà spesso questo sintomo.</para>
|
|
Giulio@743
|
328 </listitem>
|
|
Giulio@743
|
329 <listitem><para id="x_4ac">Il file <filename role="special">authorized_keys</filename> dell'utente potrebbe avere un problema. Se qualcun altro oltre all'utente possiede o può scrivere su quel file, il demone ssh non si fiderà né lo leggerà.</para>
|
|
Giulio@743
|
330 </listitem></itemizedlist>
|
|
Giulio@743
|
331
|
|
Giulio@743
|
332 <para id="x_4ad">In un mondo ideale, dovreste essere in grado di eseguire il comando seguente con successo, e dovrebbe stampare esattamente una riga contenente la data e l'ora correnti.</para>
|
|
Giulio@743
|
333 <programlisting>ssh myserver date</programlisting>
|
|
Giulio@743
|
334
|
|
Giulio@743
|
335 <para id="x_4ae">Se, sul vostro server, avete script di accesso che stampano ~banner~ o altra spazzatura anche quando eseguite comandi non interattivi come questo, dovreste correggerli prima di continuare, in modo che stampino solo se vengono eseguiti interattivamente. Altrimenti, questi ~banner~ come minimo confonderanno le stampe di Mercurial. Peggio, potrebbero potenzialmente causare problemi durante l'esecuzione remota dei comandi Mercurial. Mercurial prova a scoprire e ignorare i ~banner~ in sessioni <command>ssh</command> non interattive, ma non è infallibile. (Se state modificando i vostri script di accesso sul vostro server, il modo solito per vedere se uno script di accesso viene eseguito in una shell interattiva è controllare il codice restituito dal comando <literal>tty -s</literal>.)</para>
|
|
Giulio@743
|
336
|
|
Giulio@743
|
337 <para id="x_4af">Una volta che avete verificato che il semplice vecchio ssh sta 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:</para>
|
|
Giulio@743
|
338
|
|
Giulio@743
|
339 <programlisting>ssh myserver hg version</programlisting>
|
|
Giulio@743
|
340
|
|
Giulio@743
|
341 <para id="x_4b0">Se vedete un messaggio di errore invece del normale risultato di <command role="hg-cmd">hg version</command>, di solito questo accade perché non avete installato Mercurial in <filename class="directory">/usr/bin</filename>. Se questo è il caso, non preoccupatevi; non avete bisogno di farlo. Ma dovreste controllare alcuni possibili problemi.</para>
|
|
Giulio@743
|
342 <itemizedlist>
|
|
Giulio@743
|
343 <listitem><para id="x_4b1">Mercurial è veramente installato sul server? So che sembra una cosa ovvia, ma vale la pena di controllare!</para>
|
|
Giulio@743
|
344 </listitem>
|
|
Giulio@743
|
345 <listitem><para id="x_4b2">Forse il percorso di ricerca della vostra shell (solitamente impostato attraverso la variabile d'ambiente <envar>PATH</envar>) è semplicemente configurato male.</para>
|
|
Giulio@743
|
346 </listitem>
|
|
Giulio@743
|
347 <listitem><para id="x_4b3">Forse la vostra variabile d'ambiente <envar>PATH</envar> è impostata per puntare all'ubicazione dell'eseguibile <command>hg</command> solo se l'accesso avviene tramite una sessione interattiva. Questo può capitare se state impostando il percorso nello script di accesso sbagliato. Leggete la documentazione della vostra shell per i dettagli.</para>
|
|
Giulio@743
|
348 </listitem>
|
|
Giulio@743
|
349 <listitem><para id="x_4b4">La variabile d'ambiente <envar>PYTHONPATH</envar> potrebbe aver bisogno di contenere il percorso ai moduli Python di Mercurial. Potrebbe non essere per niente impostata, potrebbe essere sbagliata, o potrebbe venire impostata solo se l'accesso è interattivo.</para>
|
|
Giulio@743
|
350 </listitem></itemizedlist>
|
|
Giulio@743
|
351
|
|
Giulio@743
|
352 <para id="x_4b5">Se riuscite a eseguire <command role="hg-cmd">hg version</command> 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 ~hosted~ da quel nome utente su quel server. Se a questo punto incorrete in qualche problema con Mercurial e ssh, provate a usare l'opzione <option role="hg-opt-global">--debug</option> per avere una immagine più chiara di quello che sta succedendo.</para>
|
|
Giulio@743
|
353 </sect2>
|
|
Giulio@743
|
354 <sect2>
|
|
Giulio@743
|
355 <title>Usare la compressione con ssh</title>
|
|
Giulio@743
|
356
|
|
Giulio@743
|
357 <para id="x_4b6">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 <emphasis>non</emphasis> richiedere la compressione.</para>
|
|
Giulio@743
|
358
|
|
Giulio@743
|
359 <para id="x_4b7">Attraverso qualsiasi rete diversa da una LAN veloce (persino una rete wireless), è probabile che usare la compressione velocizzi significativamente le operazioni di rete di Mercurial. Per esempio, attraverso una WAN, qualcuno ha misurato che la compressione riduce la quantità di tempo necessaria per creare un repository particolarmente grande da 51 minuti a 17 minuti.</para>
|
|
Giulio@743
|
360
|
|
Giulio@743
|
361 <para id="x_4b8">Sia <command>ssh</command> che <command>plink</command> accettano l'opzione <option role="cmd-opt-ssh">-C</option> per attivare la compressione. Potete facilmente modificare il vostro file <filename role="special">~/.hgrc</filename> per abilitare la compressione per tutti gli utilizzi del protocollo ssh da parte di Mercurial. Per esempio, ecco come fare per l'ordinario comando <command>ssh</command> sui sistemi di tipo Unix.</para>
|
|
Giulio@743
|
362 <programlisting>[ui]
|
|
Giulio@743
|
363 ssh = ssh -C</programlisting>
|
|
Giulio@743
|
364
|
|
Giulio@743
|
365 <para id="x_4b9">Se usate <command>ssh</command> 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 <filename role="special">.ssh/config</filename> (che potrebbe anche non esistere) come segue.</para>
|
|
Giulio@743
|
366
|
|
Giulio@743
|
367 <programlisting>Host hg
|
|
Giulio@743
|
368 Compression yes
|
|
Giulio@743
|
369 HostName hg.example.com</programlisting>
|
|
Giulio@743
|
370
|
|
Giulio@743
|
371 <para id="x_4ba">Questo definisce un alias per il nome della macchina, <literal>hg</literal>. Quando usate quel nome sulla riga di comando <command>ssh</command> o in un URL ssh di Mercurial, <command>ssh</command> si connetterà a <literal>hg.example.com</literal> e userà la compressione. Questo vi dà sia un nome più corto da digitare e la compressione, che sono entrambe buone cose di per sé.</para>
|
|
Giulio@743
|
372 </sect2>
|
|
Giulio@743
|
373 </sect1>
|
|
Giulio@743
|
374
|
|
Giulio@743
|
375 <sect1 id="sec:collab:cgi">
|
|
Giulio@743
|
376 <title>Servire attraverso HTTP usando CGI</title>
|
|
Giulio@743
|
377
|
|
Giulio@743
|
378 <para id="x_6a8">Il modo più semplice per ~host~ un repository è quello di usare un server web e il supporto CGI di Mercurial.</para>
|
|
Giulio@743
|
379
|
|
Giulio@743
|
380 <para id="x_4bb">A seconda di quanto siete ambiziosi, configurare l'interfaccia CGI di Mercurial può portarvi via da pochi momenti a diverse ore.</para>
|
|
Giulio@743
|
381
|
|
Giulio@743
|
382 <para id="x_4bc">Cominceremo con il più semplice degli esempi, e ci faremo strada verso una configurazione più complessa. Persino nel caso più semplice, quasi certamente finirete per avere bisogno di leggere e modificare la configurazione del vostro server web.</para>
|
|
Giulio@743
|
383
|
|
Giulio@743
|
384 <note>
|
|
Giulio@743
|
385 <title>Si richiede alta sopportazione del dolore</title>
|
|
Giulio@743
|
386
|
|
Giulio@743
|
387 <para id="x_4bd">Configurare un server web è un'attività complessa, intricata e altamente dipendente dal sistema. Non sarebbe possibile per me darvi istruzioni che coprano tutti i casi che incontrerete. Quindi, usate il vostro discernimento e il vostro giudizio nel leggere le sezioni che seguono. Siate preparati a commettere molti errori e a passare molto tempo a leggere il registro degli errori del vostro server.</para>
|
|
Giulio@743
|
388
|
|
Giulio@743
|
389 <para id="x_6a9">Se non avete uno stomaco abbastanza forte da aggiustare continuamente le configurazioni, o un bisogno impellente di ~host~ i vostri servizi, potreste volere provarne uno tra i servizi di ~hosting~ pubblici che ho menzionato in precedenza.</para>
|
|
Giulio@743
|
390 </note>
|
|
Giulio@743
|
391
|
|
Giulio@743
|
392 <sect2>
|
|
Giulio@743
|
393 <title>Lista di controllo per la configurazione di un server web</title>
|
|
Giulio@743
|
394
|
|
Giulio@743
|
395 <para id="x_4be">Prima di proseguire, prendetevi alcuni momenti per controllare alcuni aspetti delle impostazioni del vostro sistema.</para>
|
|
Giulio@743
|
396
|
|
Giulio@743
|
397 <orderedlist>
|
|
Giulio@743
|
398 <listitem><para id="x_4bf">Avete un server web installato? Mac OS X e alcune distribuzioni Linux includono Apache, ma molti altri sistemi potrebbero non avere un server web già installato.</para>
|
|
Giulio@743
|
399 </listitem>
|
|
Giulio@743
|
400 <listitem><para id="x_4c0">Se avete un server web installato, è davvero in esecuzione? Sulla maggior parte dei sistemi, se anche un server web è presente, sarà disabilitato per default.</para>
|
|
Giulio@743
|
401 </listitem>
|
|
Giulio@743
|
402 <listitem><para id="x_4c1">Il vostro server è configurato per consentirvi di eseguire programmi CGI nella directory dove pianificate di farlo? La maggior parte delle impostazioni di partenza dei server disabilitano esplicitamente la possibilità di eseguire programmi CGI.</para>
|
|
Giulio@743
|
403 </listitem></orderedlist>
|
|
Giulio@743
|
404
|
|
Giulio@743
|
405 <para id="x_4c2">Se non avete un server web installato e non avete una sostanziale esperienza nel configurare Apache, dovreste considerare l'uso del server web <literal>lighttpd</literal> invece di Apache. Apache ha una reputazione ben meritata per configurazioni barocche e confuse. Mentre <literal>lighttpd</literal> è meno capace in alcuni modi rispetto ad Apache, la maggior parte di queste capacità non è rilevante per servire repository Mercurial. E <literal>lighttpd</literal> è innegabilmente <emphasis>molto</emphasis> più facile da cominciare di Apache.</para>
|
|
Giulio@743
|
406 </sect2>
|
|
Giulio@743
|
407
|
|
Giulio@743
|
408 <sect2>
|
|
Giulio@743
|
409 <title>Configurazione CGI di base</title>
|
|
Giulio@743
|
410
|
|
Giulio@743
|
411 <para id="x_4c3">Su sistemi di tipo Unix, è comune per gli utenti di avere una sottodirectory con un nome simile a <filename class="directory">public_html</filename> nella propria directory personale, da cui possono servire pagine web. Un file chiamato <filename>foo</filename> in questa directory sarà accessibile a un URL della forma <literal>http://www.example.com/~username/foo</literal>.</para>
|
|
Giulio@743
|
412
|
|
Giulio@743
|
413 <para id="x_4c4">Per cominciare, trovate lo script <filename role="special">hgweb.cgi</filename> 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 <ulink url="http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi">http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi</ulink>.</para>
|
|
Giulio@743
|
414
|
|
Giulio@743
|
415 <para id="x_4c5">Dovrete copiare questo script nella vostra directory <filename class="directory">public_html</filename> e assicurarvi che sia eseguibile.</para>
|
|
Giulio@743
|
416 <programlisting>cp .../hgweb.cgi ~/public_html
|
|
Giulio@743
|
417 chmod 755 ~/public_html/hgweb.cgi</programlisting>
|
|
Giulio@743
|
418 <para id="x_4c6">L'argomento <literal>755</literal> passato a <command>chmod</command> ha un effetto un po' più generale rispetto a rendere lo script eseguibile: garantisce che lo script sia eseguibile da chiunque, e che i permessi di scrittura per il <quote>gruppo</quote> e gli <quote>altri</quote> <emphasis>non</emphasis> siano concessi. Se lasciaste abilitati quei permessi, probabilmente il sottosistema <literal>suexec</literal> di Apache si rifiuterebbe di eseguire lo script. In effetti, <literal>suexec</literal> insiste anche sul fatto che la <emphasis>directory</emphasis> in cui risiede lo script non sia modificabile da altri.</para>
|
|
Giulio@743
|
419 <programlisting>chmod 755 ~/public_html</programlisting>
|
|
Giulio@743
|
420
|
|
Giulio@743
|
421 <sect3 id="sec:collab:wtf">
|
|
Giulio@743
|
422 <title>Che cosa <emphasis>potrebbe</emphasis> andare storto?</title>
|
|
Giulio@743
|
423
|
|
Giulio@743
|
424 <para id="x_4c7">Una volta che avete copiato lo script CGI al suo posto, aprite un browser web e provate a visitare l'URL <literal>http://myhostname/~myuser/hgweb.cgi</literal>, <emphasis>ma</emphasis> raccogliete le forze per un fallimento istantaneo. C'è un'alta probabilità che la visita a questo URL fallisca e ci sono molte possibili ragioni per questo. In effetti, probabilmente vi imbatterete in quasi tutti i possibili errori descritti più avanti, quindi leggete attentamente. I seguenti sono tuti i problemi che ho incontrato su un sistema che esegue Fedora 7, con una installazione vergine di Apache e un account utente che ho creato espressamente per effettuare questo esercizio.</para>
|
|
Giulio@743
|
425
|
|
Giulio@743
|
426 <para id="x_4c8">Il vostro server web potrebbe avere disabilitato le directory per utente. Se state usando Apache, cercate la direttiva <literal>UserDir</literal> nel vostro file di configurazione. Se non è presente, le directory per utente sono disabilitate. Se è presente, ma il suo valore è <literal>disabled</literal>, allora le directory per utente sono disabilitate. Altrimenti, la stringa che segue <literal>UserDir</literal> vi dà il nome della sottodirectory della vostra directory personale in cui Apache guarderà, per esempio <filename class="directory">public_html</filename>.</para>
|
|
Giulio@743
|
427
|
|
Giulio@743
|
428 <para id="x_4c9">I vostri permessi di accesso ai file potrebbero essere troppo restrittivi. Il server web deve essere in grado di attraversare la vostra directory personale e le directory contenute nella vostra directory <filename class="directory">public_html</filename>, nonché leggere i file in essa contenuti. Ecco una ricetta veloce per aiutarvi a rendere i vostri permessi più appropriati.</para>
|
|
Giulio@743
|
429 <programlisting>chmod 755 ~
|
|
Giulio@743
|
430 find ~/public_html -type d -print0 | xargs -0r chmod 755
|
|
Giulio@743
|
431 find ~/public_html -type f -print0 | xargs -0r chmod 644</programlisting>
|
|
Giulio@743
|
432
|
|
Giulio@743
|
433 <para id="x_4ca">L'altra possibilità di errore con i permessi è che potreste ottenere una finestra completamente vuota quando provate a caricare lo script. In questo caso, è probabile che i vostri permessi di accesso siano <emphasis>troppo permissivi</emphasis>. Per esempio, il sottosistema <literal>suexec</literal> di Apache non eseguirà uno script che può essere modificato dal gruppo o dal resto del mondo.</para>
|
|
Giulio@743
|
434
|
|
Giulio@743
|
435 <para id="x_4cb">Il vostro server web potrebbe essere configurato per disabilitare l'esecuzione di programmi CGI nella vostra directory web per utente. Ecco la configurazione per utente predefinita di Apache sul mio sistema Fedora.</para>
|
|
Giulio@743
|
436
|
|
Giulio@743
|
437 &ch06-apache-config.lst;
|
|
Giulio@743
|
438
|
|
Giulio@743
|
439 <para id="x_4cc">Se trovate un gruppo <literal>Directory</literal> simile a questo nella vostra configurazione di Apache, la direttiva da cercare in questo gruppo si chiama <literal>Options</literal>. Aggiungete <literal>ExecCGI</literal> alla fine di questa lista se non è presente e riavviate il server web.</para>
|
|
Giulio@743
|
440
|
|
Giulio@743
|
441 <para id="x_4cd">Se vedete che Apache vi serve il testo dello script CGI invece di eseguirlo, potreste dover attivare (se è già presente) o aggiungere una direttiva come questa.</para>
|
|
Giulio@743
|
442 <programlisting>AddHandler cgi-script .cgi</programlisting>
|
|
Giulio@743
|
443
|
|
Giulio@743
|
444 <para id="x_4ce">La possibilità successiva è che vi potrebbe venire servita una colorata traccia dello stack di esecuzione di Python che afferma di non poter importare un modulo relativo a <literal>mercurial</literal>. Questo è un reale progresso! Il server ora è in grado di eseguire il vostro script CGI. Questo errore può accadere solo se state eseguendo una installazione privata di Mercurial invece di una installazione ~system-wide~. Ricordate che il server web esegue il programma CGI senza alcuna variabile di ambiente che date per scontata in una sessione interattiva. Se questo errore vi capita, modificate la vostra copia di <filename role="special">hgweb.cgi</filename> e seguite le indicazioni che trovate per impostare correttamente la vostra variabile d'ambiente <envar>PYTHONPATH</envar>.</para>
|
|
Giulio@743
|
445
|
|
Giulio@743
|
446 <para id="x_4cf">Infine, otterrete <emphasis>sicuramente</emphasis> un'altra colorata traccia dello stack di esecuzione di Python: questa volta si lamenterà di non poter trovare <filename class="directory">/path/to/repository</filename>. Modificate il vostro script <filename role="special">hgweb.cgi</filename> e sostituite la stringa <filename class="directory">/path/to/repository</filename> con il percorso completo del repository che volete servire.</para>
|
|
Giulio@743
|
447
|
|
Giulio@743
|
448 <para id="x_4d0">A questo punto, quando provate a ricaricare la pagina, dovrebbe presentarvisi una gradevole vista HTML della cronologia del vostro repository. Whew!</para>
|
|
Giulio@743
|
449 </sect3>
|
|
Giulio@743
|
450
|
|
Giulio@743
|
451 <sect3>
|
|
Giulio@743
|
452 <title>Configurare lighttpd</title>
|
|
Giulio@743
|
453
|
|
Giulio@743
|
454 <para id="x_4d1">Per completare i miei esperimenti, ho provato a configurare il sempre più popolare server web <literal>lighttpd</literal> per servire lo stesso repository come appena descritto con Apache. Avevo già superato tutti i problemi illustrati con Apache, molti dei quali non sono specifici per un server. Come risultato, ero piuttosto sicuro che i miei permessi per i file e le directory fossero buoni e che il mio script <filename role="special">hgweb.cgi</filename> fosse propriamente modificato.</para>
|
|
Giulio@743
|
455
|
|
Giulio@743
|
456 <para id="x_4d2">Una volta messo in esecuzione Apache, riuscire a far servire il repository da <literal>lighttpd</literal> è stato un attimo (in altre parole, anche se state provando a usare <literal>lighttpd</literal>, dovreste leggere la sezione su Apache). Per prima cosa ho dovuto modificare la sezione <literal>mod_access</literal> del suo file di configurazione per abilitare <literal>mod_cgi</literal> e <literal>mod_userdir</literal>, che erano entrambi disabilitati di default sul mio sistema. Poi ho aggiunto alcune righe alla fine del file di configurazione, per configurare questi moduli.</para>
|
|
Giulio@743
|
457 <programlisting>userdir.path = "public_html"
|
|
Giulio@743
|
458 cgi.assign = (".cgi" => "" )</programlisting>
|
|
Giulio@743
|
459 <para id="x_4d3">Fatto questo, <literal>lighttpd</literal> ha funzionato immediatamente per me. Se avessi configurato <literal>lighttpd</literal> prima di Apache, mi sarei quasi certamente imbattuto negli stessi problemi di configurazione a livello di sistema incontrati con Apache. Tuttavia, ho trovato <literal>lighttpd</literal> notevolmente più facile da configurare di Apache, anche se ho usato Apache per più di una decade e questa è stata la mia prima esperienza con <literal>lighttpd</literal>.</para>
|
|
Giulio@743
|
460 </sect3>
|
|
Giulio@743
|
461 </sect2>
|
|
Giulio@743
|
462
|
|
Giulio@743
|
463 <sect2>
|
|
Giulio@743
|
464 <title>Condividere molteplici repository con un solo script CGI</title>
|
|
Giulio@743
|
465
|
|
Giulio@743
|
466 <para id="x_4d4">Lo script <filename role="special">hgweb.cgi</filename> vi permette solo di pubblicare un singolo repository, che è una fastidiosa restrizione. Se volete pubblicarne più di uno senza rovinarvi con molteplici copie dello stesso script, ognuna con un nome differente, una scelta migliore è quella di usare lo script <filename role="special">hgwebdir.cgi</filename>.</para>
|
|
Giulio@743
|
467
|
|
Giulio@743
|
468 <para id="x_4d5">La procedura per configurare <filename role="special">hgwebdir.cgi</filename> è solo leggermente più complicata di quella per <filename role="special">hgweb.cgi</filename>. Per prima cosa, dovete ottenere una copia dello script. Se non ne avete una sottomano, potete scaricala dal repository principale di Mercurial all'indirizzo <ulink url="http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi">http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi</ulink>.</para>
|
|
Giulio@743
|
469
|
|
Giulio@743
|
470 <para id="x_4d6">Dovrete copiare questo script nella vostra directory <filename class="directory">public_html</filename> e assicurarvi che sia eseguibile.</para>
|
|
Giulio@743
|
471
|
|
Giulio@743
|
472 <programlisting>cp .../hgwebdir.cgi ~/public_html
|
|
Giulio@743
|
473 chmod 755 ~/public_html ~/public_html/hgwebdir.cgi</programlisting>
|
|
Giulio@743
|
474
|
|
Giulio@743
|
475 <para id="x_4d7">Una volta effettuata questa configurazione di base, provate a visitare <literal>http://myhostname/~myuser/hgwebdir.cgi</literal> con il vostro browser. Dovrebbe mostrare una lista vuota di repository. Se ottenete una finestra bianca o un messaggio di errore, provate a ripercorrere la lista di possibili problemi nella <xref linkend="sec:collab:wtf"/>.</para>
|
|
Giulio@743
|
476
|
|
Giulio@743
|
477 <para id="x_4d8">Lo script <filename role="special">hgwebdir.cgi</filename> si basa su un file di configurazione esterno. Di default, cerca un file chiamato <filename role="special">hgweb.config</filename> nella stessa directory in cui si trova. Dovrete creare questo file e renderlo leggibile al resto del mondo. Il formato di questo file è simile a quello di un file <quote>ini</quote> di Windows, riconoscibile dal modulo <literal>ConfigParser</literal> <citation>web:configparser</citation> di Python.</para>
|
|
Giulio@743
|
478
|
|
Giulio@743
|
479 <para id="x_4d9">Il modo più facile di configurare <filename role="special">hgwebdir.cgi</filename> è tramite una sezione chiamata <literal>collections</literal>. Questo pubblicherà automaticamente <emphasis>tutti</emphasis> i repository sotto le directory che nominate. La sezione dovrebbe somigliare a questo:
|
|
Giulio@743
|
480 <programlisting>[collections]
|
|
Giulio@743
|
481 /my/root = /my/root</programlisting>
|
|
Giulio@743
|
482 <para id="x_4da">Mercurial la interpreta guardando al nome della directory sul lato <emphasis>destro</emphasis> del segno <quote><literal>=</literal></quote>, trovando i repository nella gerarchia contenuta in quella directory e usando il testo sul lato <emphasis>sinistro</emphasis> per eliminare il testo corrispondente dai nomi che elencherà effettivamente nell'interfaccia web. I componenti del percorso che rimangono dopo questa eliminazione formano un <quote>percorso virtuale</quote>.</para>
|
|
Giulio@743
|
483
|
|
Giulio@743
|
484 <para id="x_4db">Dato l'esempio precedente, se abbiamo un repository il cui percorso locale sia <filename class="directory">/my/root/this/repo</filename>, lo script CGI eliminerà la parte <filename class="directory">/my/root</filename> iniziale dal nome e pubblicherà il repository con il percorso virtuale <filename class="directory">this/repo</filename>. Se l'URL per il nostro script CGI è <literal>http://myhostname/~myuser/hgwebdir.cgi</literal>, l'URL completo per quel repository sarà <literal>http://myhostname/~myuser/hgwebdir.cgi/this/repo</literal>.</para>
|
|
Giulio@743
|
485
|
|
Giulio@743
|
486 <para id="x_4dc">Se sostituiamo <filename class="directory">/my/root</filename> sul lato sinstro di questo esempio con <filename class="directory">/my</filename>, allora <filename role="special">hgwebdir.cgi</filename> eliminerà solo <filename class="directory">/my</filename> dal nome del repository e ci darà il percorso virtuale <filename class="directory">root/this/repo</filename> invece di <filename class="directory">this/repo</filename>.</para>
|
|
Giulio@743
|
487
|
|
Giulio@743
|
488 <para id="x_4dd">Lo script <filename role="special">hgwebdir.cgi</filename> cercherà ricorsivamente in ogni directory elencata nella sezione <literal>collections</literal> del suo file di configurazione, ma <emphasis>non</emphasis> navigherà ricorsivamente nei repository che trova.</para>
|
|
Giulio@743
|
489
|
|
Giulio@743
|
490 <para id="x_4de">Il meccanismo delle collezioni nella sezione <literal>collections</literal> facilita la pubblicazione di molti repository in modo <quote>~fire and forget~</quote>. 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 <filename role="special">hgwebdir.cgi</filename> è configurato per guardare.</para>
|
|
Giulio@743
|
491
|
|
Giulio@743
|
492 <sect3>
|
|
Giulio@743
|
493 <title>Specificare esplicitamente quali repository pubblicare</title>
|
|
Giulio@743
|
494
|
|
Giulio@743
|
495 <para id="x_4df">In aggiunta al meccanismo basato su <literal>collections</literal>, lo script <filename role="special">hgwebdir.cgi</filename> vi consente di pubblicare una lista specifica di repository. Per fare questo, create una sezione <literal>paths</literal> con un contenuto simile al seguente.</para>
|
|
Giulio@743
|
496 <programlisting>[paths]
|
|
Giulio@743
|
497 repo1 = /my/path/to/some/repo
|
|
Giulio@743
|
498 repo2 = /some/path/to/another</programlisting>
|
|
Giulio@743
|
499 <para id="x_4e0">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 ci sia alcuna relazione tra il percorso virtuale che scegliete e l'ubicazione di un repository sul vostro file system.</para>
|
|
Giulio@743
|
500
|
|
Giulio@743
|
501 <para id="x_4e1">Se lo desiderate, potete usare entrambe le sezioni <literal>collections</literal> e <literal>paths</literal> simultaneamente in un unico file di configurazione.</para>
|
|
Giulio@743
|
502
|
|
Giulio@743
|
503 <note>
|
|
Giulio@743
|
504 <title>Fate attenzione ai percorsi virtuali duplicati</title>
|
|
Giulio@743
|
505
|
|
Giulio@743
|
506 <para id="x_4e2">Se diversi repository hannolo stesso percorso virtuale, <filename role="special">hgwebdir.cgi</filename> non riporterà un errore, ma si comporterà in maniera imprevedibile.</para>
|
|
Giulio@743
|
507 </note>
|
|
Giulio@743
|
508 </sect3>
|
|
Giulio@743
|
509 </sect2>
|
|
Giulio@743
|
510
|
|
Giulio@743
|
511 <sect2>
|
|
Giulio@743
|
512 <title>Scaricare gli archivi dei sorgenti</title>
|
|
Giulio@743
|
513
|
|
Giulio@743
|
514 <para id="x_4e3">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.</para>
|
|
Giulio@743
|
515
|
|
Giulio@743
|
516 <para id="x_4e4">Di default, questa funzionalità è disabilitata. Per abilitarla, dovrete aggiungere un elemento <envar role="rc-item-web">allow_archive</envar> alla sezione <literal role="rc-web">web</literal> del vostro file <filename role="special">~/.hgrc</filename>; vedete più oltre per i dettagli.</para>
|
|
Giulio@743
|
517 </sect2>
|
|
Giulio@743
|
518 <sect2>
|
|
Giulio@743
|
519 <title>Le opzioni di configurazione web</title>
|
|
Giulio@743
|
520
|
|
Giulio@743
|
521 <para id="x_4e5">Le interfacce web di Mercurial (il comando <command role="hg-cmd">hg serve</command> e gli script <filename role="special">hgweb.cgi</filename> e <filename role="special">hgwebdir.cgi</filename>) hanno un certo numero di opzioni di configurazine che potete impostare. Queste appartengono a una sezione chiamata <literal role="rc-web">web</literal>.</para>
|
|
Giulio@743
|
522 <itemizedlist>
|
|
Giulio@743
|
523 <listitem><para id="x_4e6"><envar role="rc-item-web">allow_archive</envar>: Determina quale (e se) meccanismo di scaricamento viene supportato da Mercurial. Se abilitate questa funzionalità, gli utenti dell'interfaccia web saranno in grado di scaricare un archivio di qualsiasi revisione del repository stiano visitando. Per abilitare la funzionalità di archivio, questo elemento deve prendere la forma di una sequenza di parole scelte dalla lista seguente.</para>
|
|
Giulio@743
|
524 <itemizedlist>
|
|
Giulio@743
|
525 <listitem><para id="x_4e7"><literal>bz2</literal>: un archivio <command>tar</command>, compresso usando la compressione <literal>bzip2</literal>. Questo ha il miglior rapporto di compressione, ma usa più tempo di CPU sul server.</para>
|
|
Giulio@743
|
526 </listitem>
|
|
Giulio@743
|
527 <listitem><para id="x_4e8"><literal>gz</literal>: un archivio <command>tar</command>, compresso usando la compressione <literal>gzip</literal>.</para>
|
|
Giulio@743
|
528 </listitem>
|
|
Giulio@743
|
529 <listitem><para id="x_4e9"><literal>zip</literal>: un archivio <command>zip</command>, compresso usando la compressione LZW. Questo formato ha il peggior rapporto di compressione, ma è largamente usando nel mondo Windows.</para>
|
|
Giulio@743
|
530 </listitem>
|
|
Giulio@743
|
531 </itemizedlist>
|
|
Giulio@743
|
532 <para id="x_4ea">Se fornite una lista vuota o se non avete una voce <envar role="rc-item-web">allow_archive</envar> questa funzionalità sarà disabilitata. Ecco un esempio di come abilitare tutti e tre i formati supportati.</para>
|
|
Giulio@743
|
533 <programlisting>[web]
|
|
Giulio@743
|
534 allow_archive = bz2 gz zip</programlisting>
|
|
Giulio@743
|
535 </listitem>
|
|
Giulio@743
|
536 <listitem><para id="x_4eb"><envar role="rc-item-web">allowpull</envar>: booleano. Determina se l'interfaccia web permette agli utenti remoti di usare i comandi <command role="hg-cmd">hg pull</command> e <command role="hg-cmd">hg clone</command> su questo repository via HTTP. Se impostato a <literal>no</literal> o a <literal>false</literal>, solo la parte <quote>orientata agli umani</quote> dell'interfaccia web sarà disponibile.</para>
|
|
Giulio@743
|
537 </listitem>
|
|
Giulio@743
|
538 <listitem><para id="x_4ec"><envar role="rc-item-web">contact</envar>: stringa. Una stringa di testo libero (ma preferibilmente breve) che identifica la persona o il gruppo responsabile del repository. Questa stringa contiene spesso il nome e l'indirizzo email di una persona o di una mailing list. Spesso ha senso inserire questa voce nel file <filename role="special">.hg/hgrc</filename> del singolo repository, ma può anche avere senso utilizzarla in un file <filename role="special">~/.hgrc</filename> globale se tutti i repository hanno un singolo manutentore.</para>
|
|
Giulio@743
|
539 </listitem>
|
|
Giulio@743
|
540 <listitem><para id="x_4ed"><envar role="rc-item-web">maxchanges</envar>: intero. Il numero massimo predefinito di changeset da visualizzare in una singola pagina web.</para>
|
|
Giulio@743
|
541 </listitem>
|
|
Giulio@743
|
542 <listitem><para id="x_4ee"><envar role="rc-item-web">maxfiles</envar>: intero. Il numero massimo predefinito di file modificati da mostrare in una singola pagina web.</para>
|
|
Giulio@743
|
543 </listitem>
|
|
Giulio@743
|
544 <listitem><para id="x_4ef"><envar role="rc-item-web">stripes</envar>: intero. Se l'interfaccia web mostra strisce alternate per rendere più facile l'allineamento visuale delle righe quando state guardando una tabella, questo numero controlla il numero di righe in ogni striscia.</para>
|
|
Giulio@743
|
545 </listitem>
|
|
Giulio@743
|
546 <listitem><para id="x_4f0"><envar role="rc-item-web">style</envar>: controlla il template che Mercurial usa per visualizzare l'interfaccia web. Mercurial include diversi template web.</para>
|
|
Giulio@743
|
547 <itemizedlist>
|
|
Giulio@743
|
548 <listitem>
|
|
Giulio@743
|
549 <para id="x_6aa"><literal>coal</literal> è monocromatico.</para>
|
|
Giulio@743
|
550 </listitem>
|
|
Giulio@743
|
551 <listitem>
|
|
Giulio@743
|
552 <para id="x_6ab"><literal>gitweb</literal> emula lo stile visivo dell'interfaccia web di git.</para>
|
|
Giulio@743
|
553 </listitem>
|
|
Giulio@743
|
554 <listitem>
|
|
Giulio@743
|
555 <para id="x_6ac"><literal>monoblue</literal> usa blu e grigi solidi.</para>
|
|
Giulio@743
|
556 </listitem>
|
|
Giulio@743
|
557 <listitem>
|
|
Giulio@743
|
558 <para id="x_6ad"><literal>paper</literal> è il template predefinito.</para>
|
|
Giulio@743
|
559 </listitem>
|
|
Giulio@743
|
560 <listitem>
|
|
Giulio@743
|
561 <para id="x_6ae"><literal>spartan</literal> è stato il template predefinito per lungo tempo.</para>
|
|
Giulio@743
|
562 </listitem>
|
|
Giulio@743
|
563 </itemizedlist>
|
|
Giulio@743
|
564 <para id="x_6af">Potete anche specificare un vostro template personalizzato; leggete il <!--<xref linkend="chap:template"/>-->FIXME per i dettagli. Qui potete vedere come abilitare lo stile <literal>gitweb</literal>.</para>
|
|
Giulio@743
|
565 <programlisting>[web]
|
|
Giulio@743
|
566 style = gitweb</programlisting>
|
|
Giulio@743
|
567 </listitem>
|
|
Giulio@743
|
568 <listitem><para id="x_4f1"><envar role="rc-item-web">templates</envar>: percorso. La directory in cui cercare i file di template. Di default, Mercurial li cerca nella directory in cui è stato installato.</para>
|
|
Giulio@743
|
569 </listitem></itemizedlist>
|
|
Giulio@743
|
570 <para id="x_4f2">Se state usando <filename role="special">hgwebdir.cgi</filename>, potete inserire alcuni elementi di configurazione nella sezione <literal role="rc-web">web</literal> del file <filename role="special">hgweb.config</filename> invece che nel file <filename role="special">~/.hgrc</filename> per convenienza. Questi elementi sono <envar role="rc-item-web">motd</envar> e <envar role="rc-item-web">style</envar>.</para>
|
|
Giulio@743
|
571
|
|
Giulio@743
|
572 <sect3>
|
|
Giulio@743
|
573 <title>Opzioni specifiche per un singolo repository</title>
|
|
Giulio@743
|
574
|
|
Giulio@743
|
575 <para id="x_4f3">Alcuni elementi di configurazione della sezione <literal role="rc-web">web</literal> dovrebbero essere inseriti nel file <filename role="special">.hg/hgrc</filename> locale di un repository piuttosto che nel file <filename role="special">~/.hgrc</filename> globale o di un utente.</para>
|
|
Giulio@743
|
576 <itemizedlist>
|
|
Giulio@743
|
577 <listitem><para id="x_4f4"><envar role="rc-item-web">description</envar>: stringa. Una stringa di testo libero (ma preferibilmente breve) che descrive i contenuti o lo scopo del repository.</para>
|
|
Giulio@743
|
578 </listitem>
|
|
Giulio@743
|
579 <listitem><para id="x_4f5"><envar role="rc-item-web">name</envar>: stringa. Il nome da usare per il repository nell'interfaccia web. Questo rimpiazza il nome predefinito, che è l'ultimo componente del percorso di un repository.</para>
|
|
Giulio@743
|
580 </listitem></itemizedlist>
|
|
Giulio@743
|
581 </sect3>
|
|
Giulio@743
|
582
|
|
Giulio@743
|
583 <sect3>
|
|
Giulio@743
|
584 <title>Opzioni specifiche per il comando <command role="hg-cmd">hg serve</command></title>
|
|
Giulio@743
|
585
|
|
Giulio@743
|
586 <para id="x_4f6">Alcuni degli elementi nella sezione <literal role="rc-web">web</literal> di un file <filename role="special">~/.hgrc</filename> possono essere usati solo con il comando <command role="hg-cmd">hg serve</command>.</para>
|
|
Giulio@743
|
587 <itemizedlist>
|
|
Giulio@743
|
588 <listitem><para id="x_4f7"><envar role="rc-item-web">accesslog</envar>: percorso. Il nome di un file in cui scrivere un registro degli accessi. Di default, il comando <command role="hg-cmd">hg serve</command> scrive queste informazioni sullo standard output, non su un file. Le voci del registro vengono scritte nel formato di file <quote>combined</quote> standard usato da quasi tutti i server web.</para>
|
|
Giulio@743
|
589 </listitem>
|
|
Giulio@743
|
590 <listitem><para id="x_4f8"><envar role="rc-item-web">address</envar>: stringa. L'indirizzo locale su cui il server dovrebbe essere in ascolto per le connessioni in entrata. Di default, il server è in ascolto su tutti gli indirizzi.</para>
|
|
Giulio@743
|
591 </listitem>
|
|
Giulio@743
|
592 <listitem><para id="x_4f9"><envar role="rc-item-web">errorlog</envar>: percorso. Il nome di un file in cui scrivere un registro degli errori. Di default, il comando <command role="hg-cmd">hg serve</command> scrive queste informazioni sullo standard output, non su un file.</para>
|
|
Giulio@743
|
593 </listitem>
|
|
Giulio@743
|
594 <listitem><para id="x_4fa"><envar role="rc-item-web">ipv6</envar>: booleano. Indica se usare il protocollo IPv6. Di default, IPv6 non viene usato.</para>
|
|
Giulio@743
|
595 </listitem>
|
|
Giulio@743
|
596 <listitem><para id="x_4fb"><envar role="rc-item-web">port</envar>: intero. Il numero di porta TCP su cui il server dovrebbe essere in ascolto. Il numero di porta predefinito è 8000.</para>
|
|
Giulio@743
|
597 </listitem></itemizedlist>
|
|
Giulio@743
|
598 </sect3>
|
|
Giulio@743
|
599
|
|
Giulio@743
|
600 <sect3>
|
|
Giulio@743
|
601 <title>Scegliere il giusto file <filename role="special">~/.hgrc</filename> a cui aggiungere elementi della sezione <literal role="rc-web">web</literal></title>
|
|
Giulio@743
|
602
|
|
Giulio@743
|
603 <para id="x_4fc">È importante ricordare che un server web come Apache o <literal>lighttpd</literal> sarà in esecuzione sotto un identificatore di utente diverso dal vostro. Anche gli script CGI eseguiti dal vostro server, come <filename role="special">hgweb.cgi</filename>, verranno solitamente eseguiti sotto quell'identificatore.</para>
|
|
Giulio@743
|
604
|
|
Giulio@743
|
605 <para id="x_4fd">Se aggiungete elementi della sezione <literal role="rc-web">web</literal> al vostro file <filename role="special">~/.hgrc</filename> personale, gli script CGI non potranno leggere quel file <filename role="special">~/.hgrc</filename>. Quelle impostazioni quindi avranno effetto solo sul comportamento del comando <command role="hg-cmd">hg serve</command> quando voi lo eseguirete. Per fare in modo che gli script CGI vedano le vostre impostazioni, create un file <filename role="special">~/.hgrc</filename> nella directory personale dell'utente il cui identificatore viene usato per eseguire il vostro server web, oppure aggiungete quelle impostazioni a un file <filename role="special">hgrc</filename> ~system-wide~.</para>
|
|
Giulio@743
|
606 </sect3>
|
|
Giulio@743
|
607 </sect2>
|
|
Giulio@743
|
608 </sect1>
|
|
Giulio@743
|
609
|
|
Giulio@743
|
610 <sect1>
|
|
Giulio@743
|
611 <title>Configurazione ~system-wide~</title>
|
|
Giulio@743
|
612
|
|
Giulio@743
|
613 <para id="x_6b0">Sui sistemi di tipo Unix condivisi da molteplici utenti (come un server su cui le persone pubblicano i propri cambiamenti) ha spesso senso impostare alcuni comportamenti predefiniti globali, come il tema da usare nell'interfaccia web.</para>
|
|
Giulio@743
|
614
|
|
Giulio@743
|
615 <para id="x_6b1">Se un file chiamato <filename>/etc/mercurial/hgrc</filename> esiste, Mercurial lo leggerà all'avvio e applicherà ogni impostazione di configurazione trovata in quel file. Cercherà anche i file che finiscono con un'estensione <literal>.rc</literal> in una directory chiamata <filename>/etc/mercurial/hgrc.d</filename> e applicherà le impostazioni di configurazione trovate in ognuno di quei file.</para>
|
|
Giulio@743
|
616
|
|
Giulio@743
|
617 <sect2>
|
|
Giulio@743
|
618 <title>Rendere Mercurial più fiducioso</title>
|
|
Giulio@743
|
619
|
|
Giulio@743
|
620 <para id="x_6b2">Una situazione in cui un file <filename>hgrc</filename> globale può essere utile è se gli utenti stanno estraendo cambiamenti posseduti da altri utenti. Di default, Mercurial non si fida della maggior parte degli elementi di configurazione in un file <filename>.hg/hgrc</filename> 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 del file <filename>.hg/hgrc</filename> di quel repository.</para>
|
|
Giulio@743
|
621
|
|
Giulio@743
|
622 <para id="x_6b3">Se tutti i membri di uno specifico gruppo Unix sono nello stesso gruppo di sviluppo e <emphasis>dovrebbero</emphasis> fidarsi l'uno delle impostazioni di configurazione dell'altro, o vogliamo fidarci di alcuni utenti particolari, possiamo rimpiazzare il comportamento scettico predefinito di Mercurial creando un file <filename>hgrc</filename> ~system-wide~ come il seguente:</para>
|
|
Giulio@743
|
623
|
|
Giulio@743
|
624 <programlisting># Save this as e.g. /etc/mercurial/hgrc.d/trust.rc
|
|
Giulio@743
|
625 [trusted]
|
|
Giulio@743
|
626 # Fidati di tutte le voci in qualsiasi file hgrc posseduto
|
|
Giulio@743
|
627 # dai gruppi "editors" o "www-data"
|
|
Giulio@743
|
628 groups = editors, www-data
|
|
Giulio@743
|
629
|
|
Giulio@743
|
630 # Fidati delle voci nei file hgrc posseduti dai seguenti utenti.
|
|
Giulio@743
|
631 users = apache, bobo
|
|
Giulio@743
|
632 </programlisting>
|
|
Giulio@743
|
633 </sect2>
|
|
Giulio@743
|
634 </sect1>
|
|
Giulio@743
|
635 </chapter>
|
