Collaborare con altre persone

# HG changeset patch # User Giulio@puck # Date 1247849615 -7200 # Node ID 2ee9e03eddce7149578a7b714fa96d3fc436293d # Parent 8bb278d5f04750b10e10367d53a9427918c88dc1 Deep revision for Ch.6. diff -r 8bb278d5f047 -r 2ee9e03eddce it/ch06-collab.xml --- a/it/ch06-collab.xml Tue Jul 14 17:49:09 2009 +0200 +++ b/it/ch06-collab.xml Fri Jul 17 18:53:35 2009 +0200 @@ -2,53 +2,53 @@ Collaborare con altre persone - 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~. + Essendo uno strumento completamente decentralizzato, Mercurial non impone alcuna politica su come le persone dovrebbero lavorare insieme. Tuttavia, se siete nuovi al controllo di revisione distribuito, conoscere alcuni strumenti ed esempi può aiutarvi a ragionare sui possibili modelli di workflow da adottare. L'interfaccia web di Mercurial - Mercurial è dotato di una potente interfaccia web che fornisce diverse utili capacità. - - 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. - - Sempre per il consumo umano, l'interfaccia web fornisce feed RSS e Atom dei cambiamenti in un repository. Questo vi permette di abbonarvi 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. - - 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. - - 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 http://www.selenic.com/repo/hg. + Mercurial è dotato di una potente interfaccia web che possiede diverse caratteristiche utili. + + L'interfaccia web vi permette di navigare interattivamente 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 fornisce una rappresentazione grafica delle relazioni tra le unioni e i singoli cambiamenti. + + L'interfaccia web offre ai visitatori anche i feed RSS e Atom dei cambiamenti in un repository. Questo vi permette di abbonarvi a un repository usando il vostro lettore di feed preferito e di venire automaticamente informati sulle attività in quel repository non appena si svolgono. 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 da parte di chiunque stia servendo il repository. + + L'interfaccia web consente agli utenti remoti anche di clonare un repository, estrarne i cambiamenti e (quando il server è configurato per permetterlo) trasmettervi le proprie modifiche. Mercurial comprime aggressivamente i dati incapsulando il protocollo HTTP in modo da lavorare con grande efficienza persino attraverso connessioni di rete a banda ridotta. + + Il modo più facile di cominciare a usare l'interfaccia web è quello di aprire il vostro browser per visitare un repository esistente, come il repository principale di Mercurial all'indirizzo http://www.selenic.com/repo/hg. Se siete interessati a fornire un'interfaccia web ai vostri repository, esistono diversi buoni modi per farlo. - Il modo più facile e veloce di cominciare in un ambiente informale è quello di usare il comando hg serve, che è particolarmente adatto a un servizio leggero a breve termine. Leggete la più avanti per i dettagli su come usare questo comando. - - 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 http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting. - - 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 per i dettagli sulle configurazioni di CGI e WSGI. + In un ambiente informale, il modo più facile e veloce di cominciare è quello di usare il comando hg serve, che è particolarmente adatto per offrire un servizio leggero a breve termine. Leggete la più avanti per i dettagli su come usare questo comando. + + Per repository destinati a progetti di lunga durata che vorreste mantenere disponibili permanentemente, potete rivolgervi ai diversi servizi di hosting pubblici esistenti. Alcuni ospitano gratuitamente i progetti open source, mentre altri offrono un hosting commerciale a pagamento. Una lista aggiornata di questi servizi è disponibile all'indirizzo http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting. + + Se invece preferite tenere i repository sui vostri server, 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 per i dettagli sulle configurazioni di CGI e WSGI. Modelli di collaborazione - 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. + Con uno strumento adeguatamente flessibile, prendere decisioni sul workflow non è tanto una sfida tecnica quanto una sfida di ingegneria sociale. 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. Fattori da tenere a mente - 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. - - 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. - - 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. + L'aspetto più importante che dovete tenere a mente 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 quantità considerevole di litigi e 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 sociale o tecnico. 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. Anarchia informale - Non vorrei suggerire un approccio ~anything goes~ come qualcosa di sostenibile, ma è un modello che è facile da capire e funziona perfettamente in alcune situazioni inusuali. - - 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 maratone. 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. - - Una maratona o una sessione di programmazione in un caffè 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 momenti, leggendo la 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. + 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 sparso di collaboratori che si incontrano fisicamente solo di rado. Alcuni gruppi preferiscono superare l'isolamento del lavoro a distanza organizzando maratone occasionale in cui un certo numero di persone si ritrova insieme in un'unico posto (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 momenti, leggendo la 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 veloce 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 funzionalità e provarla. 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 n diversi repository da cui estrarre modifiche. @@ -56,71 +56,71 @@ Un singolo repository centrale - 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 mattone da costruzione per schemi di ~workflow~ più ambiziosi. - - 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. - - 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. - - Se un gruppo sta ~hosting~ il proprio repository in questo tipo di scenario, di solito le persone useranno il protocollo ssh per trasmettere in sicurezza i cambiamenti al repository centrale, come documentato nella . Di solito, viene anche pubblicata una copia del repository in sola lettura via HTTP, come nella . 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. - - - - Un repository centrale ~hosted~ - - Una cosa meravigliosa dei servizi ~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 ~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. - - In più, un buon servizio ~hosting~ permetterà alle persone di comunicare tra loro, per esempio per dire ci sono modifiche pronte per la tua revisione in questo albero. + 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 aver senso che alcune persone propaghino 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, 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 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 . Di solito, viene anche pubblicata una copia del repository in sola lettura via HTTP, come nella . 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. + + + + Un repository centrale su un servizio di hosting + + Una caratteristica meravigliosa dei servizi 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 hosting ben ingegnerizzato consentirà alle persone 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 hosting permetterà alle persone di comunicare tra loro, per esempio per segnalare che questo albero contiene modifiche pronte per la tua revisione. Lavorare con più rami - 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 mantenimento per un po' dopo la sua prima pubblicazione; le release in fase di mantenimento 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 ramo per riferirsi a una di queste direzioni leggermente differenti in cui lo sviluppo sta procedendo. - - Mercurial è particolarmente adatto a gestire un certo numero di rami simultanei ma non identici. Ogni direzione di sviluppo 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. - - Ecco un esempio di come questo può funzionare nella pratica. Diciamo che avete un ramo principale su un server centrale. + 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 funzionalità. Una o più release future potrebbero trovarsi in lavorazione in parallelo a queste revisioni di manutenzione. Normalmente le persone usano il termine ramo (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. &interaction.branching.init; - Le persone lo clonano, effettuano modifiche locali, le collaudano e le trasmettono indietro. - - Una volta che il ramo principale raggiunge la pietra miliare di una release, potete usare il comando hg tag per dare un nome permanente alla revisione pietra miliare. + 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. &interaction.branching.tag; - Diciamo che alcuni sviluppi esterni accodono sul ramo principale. + Diciamo che alcuni sviluppi esterni accadono sul ramo principale. &interaction.branching.main; - Usando l'etichetta registrata sulla pietra miliare, le persone che clonano quel repository in qualsiasi momento nel futuro possono usare hg update per ottenere una copia della directory di lavoro esattamente com'era quando quella revisoine etichettata è stata inserita. + Usando l'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. &interaction.branching.update; - In più, immediatamente dopo che il ramo principale è stato etichettato, possiamo clonare il ramo principale sul server in un nuovo ramo stabile, anche quello sul server. + 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. &interaction.branching.clone; - Se abbiamo bisogno di fare una modifica al ramo stabile, possiamo clonare quel repository, fare i nostri cambiamenti, effettuarne il commit, e trasmetterli là. + 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. &interaction.branching.stable; - Dato che repository Mercurial sono indipendenti e che Mercurial non sposta i cambiamenti in giro automaticamente, 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 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. + 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. &interaction.branching.merge; - 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. + 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. Rami di funzionalità - 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 principale usato dall'intero progetto. Le persone che lavorano su un singolo ramo sono tipicamente piuttosto isolate dagli sviluppi che accadono negli altri rami. + Per progetti di dimensioni più grandi, un modo efficace di 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 accadono negli altri rami.

Rami di funzionalità @@ -130,45 +130,45 @@ - 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. + Quando si ritiene che una funzionalità particolare sia in una forma appropriata, qualche membro del sottogruppo di quella funzionalità estrae i cambiamenti dal ramo principale e li unisce al ramo della funzionalità, poi trasmette le modifiche indietro al ramo principale. Il treno delle release - L'organizzazione di alcuni progetti può ricordare quella di un treno: le release sono fissate a intervalli di alcuni mesi, e tutte le funzionalità che sono pronte quando il treno è pronto a partire vengono incluse. - - 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. + L'organizzazione di alcuni progetti può ricordare quella di un treno: le release sono fissate a intervalli di alcuni mesi e includono tutte le funzionalità che sono pronte quando il treno è pronto a partire. + + Questo modello assomiglia all'impiego dei rami di funzionalità, tranne per il fatto che quando un ramo di funzionalità perde un treno, qualche membro del gruppo di quella funzionalità estrae i cambiamenti che sono partiti con il treno della release e li unisce al ramo della funzionalità, così il gruppo continua a lavorare partendo da quella release, in modo che la funzionalità di cui è responsabile possa essere inclusa nella release successiva. Il modello del kernel di Linux - 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 git, 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. - - Al centro della comunità siede Linus Torvalds, il creatore di Linux. 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 numero di luogotenenti fidati. 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 manutentori 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. - - 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 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 nesusn 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 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 buone 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. - - 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. - - 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. + 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 l'approccio 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 fidati. 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 ha il proprio approccio 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 adeguatezza. Più modifiche buone 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 potranno incorporare regolarmente i vostri cambiamenti per rimanere aggiornati sul vostro lavoro. + + Reputazione e approvazione non necessariamente oltrepassano 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 appropriato e la velocità di sviluppo è sorprendente. E però Linux è un software molto apprezzato e di grande successo. Collaborazione in sola lettura o in scrittura condivisa - 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 è 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 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). - - 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. + 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 costruire il vostro approccio 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 poterete quindi strutturare il modo di lavorare insieme sulla base dei vostri bisogni e delle vostre preferenze, non delle acrobazie a cui vi costringono gli strumenti. Dove la collaborazione incontra la gestione dei rami @@ -180,68 +180,68 @@ Il lato tecnico della condivisione - Il resto di questo capitolo è dedicato alla questione di condividere i cambiamenti con i vostri collaboratori. + Il resto di questo capitolo è dedicato alla condivisione dei cambiamenti con i vostri collaboratori. Condivisione informale con <command role="hg-cmd">hg serve</command> - Il comando hg serve 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. - - Eseguite hg serve 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 hg serve in esecuzione su un laptop somiglierà probabilmente a qualcosa come http://my-laptop.local:8000/. - - Il comando hg serve non è un server web ~general-purpose~, ma può fare solo due cose: + Il comando hg serve di Mercurial è meravigliosamente adatto per situazioni in cui i gruppi di sviluppo sono piccoli, localizzati e veloci. Rappresenta anche un modo fantastico per familiarizzare con l'uso dei comandi Mercurial attraverso la rete. + + Eseguite hg serve 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 di quel repository fino a quando non lo spegnerete. 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 hg serve in esecuzione su un computer portatile somiglierà probabilmente a qualcosa come http://mio-portatile.local:8000/. + + Il comando hg serve non è un server web di uso generale, ma può fare solo due cose: - Consentire alle persone di usare il proprio browser web per navigare la cronologia del repository che sta servendo. + consentire alle persone di usare il proprio browser web per navigare la cronologia del repository che sta servendo; - Parlare il protocollo di rete di Mercurial, in modo che le persone possano usare comandi come hg clone o hg pull su quel repository. + comunicare attraverso il protocollo di rete di Mercurial, in modo che le persone possano usare comandi come hg clone o hg pull su quel repository. In particolare, hg serve non permetterà agli utenti di modificare il vostro repository, perché è stato pensato per un uso in sola lettura. - Se state appena cominciando a usare Mercurial, non c'è nulla che vi impedisca di usare hg serve per servire un repository sul vostro computer, poi usare comandi come hg clone, hg incoming 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. + Se avete appena cominciato a lavorare con Mercurial, non c'è nulla che vi impedisca di usare hg serve per servire i dati di un repository sul vostro computer, poi usare comandi come hg clone, hg incoming 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. Alcune cose da tenere a mente - Dato che fornisce un accesso non autenticato in lettura a tutti i client, dovreste usare hg serve 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. - - 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 controllato che stiano usando l'URL corretto) è controllare la configurazione del vostro firewall. + Dato che fornisce un accesso non autenticato in lettura a tutti i client, dovreste usare hg serve solo in un ambiente in cui non vi interessa, o potete interamente controllare su, 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. Di 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 . - 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 trovare l'esatto URL che dovreste inviare ai vostri collaboratori, lanciate hg serve con l'opzione . + 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 . Usare il protocollo di Shell Sicura (ssh) - Potete estrarre e trasmettere cambiamenti in sicurezza attraverso la rete usando il protocollo di Shell Sicura (ssh). Per usarlo con successo, potreste dover fare un po' di configurazione sia sul lato client che sul lato server. - - 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. - - (Se avete familiarità con ssh, probabilmente troverete elementare parte del materiale che segue.) + Potete estrarre e trasmettere cambiamenti in sicurezza attraverso la rete usando il protocollo di Shell Sicura (ssh). Per usarlo con successo, potreste dover sistemare la configurazione sia del lato client che del lato server. + + Se non avete familiarità con ssh, sappiate che è il nome di un comando e 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. + + (Se avete familiarità con ssh, probabilmente troverete rudimentale la natura di parte del materiale che segue.) Come leggere e scrivere URL ssh - Un URL ssh tende a somigliare al seguente: + Un URL ssh tende ad avere la forma seguente: ssh://bos@hg.serpentine.com:22/hg/hgbook La parte ssh:// dice a Mercurial di usare il protocollo ssh. - Il componente bos@ indica con quale nome utente accedere al server. Potete ometterlo se il nome utente remoto è lo stesso del vostro nome utente locale. - - hg.serpentine.com vi dà il nome del server a cui accedere. + Il componente bos@ indica qual è il nome utente con cui accedere al server. Potete ometterlo se il nome utente remoto è lo stesso del vostro nome utente locale. + + hg.serpentine.com rappresenta il nome del server a cui accedere. :22 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 non state usando la porta 22. Il resto dell'URL è il percorso locale del repository sul server. - 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. - - Mercurial tratta il percorso a un repository sul server come relativo alla directory personale dell'utente remoto. Per esempio, se l'utente foo possiede una directory perosnale /home/foo sul server, allora un URL ssh che contenga un percorso di bar si riferisce in realtà alla directory /home/foo/bar. + 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 @@ -253,9 +253,9 @@ Trovare un client ssh per il vostro sistema - Quasi tutti i sistemi di tipo Unix includono una 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. - - Sotto Windows, il pacchetto TortoiseHg comprende una versione dell'eccellente comando plink realizzato da Simon Tatham, e non dovreste avere bisogno di ulteriori configurazioni. + 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. + + Sotto Windows, il pacchetto TortoiseHg comprende una versione dell'eccellente comando plink, realizzato da Simon Tatham, che non dovrebbe avere bisogno di ulteriori configurazioni. @@ -266,35 +266,37 @@ Le coppie di chiavi non sono obbligatorie - 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. + 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. - Sotto un sistema di tipo Unix, il comando ssh-keygen dovrebbe funzionare. - Sotto Windows, se state usando TortoiseHg, potreste dover scaricare il comando puttygen dal sito web di PuTTY per generare una coppia di chiavi. Leggete la documentazione di puttygen per i dettagli su come usare il comando. + Su un sistema di tipo Unix, il comando ssh-keygen dovrebbe servire allo scopo. + + + Per generare una coppia di chiavi sotto Windows, se state usando TortoiseHg potreste dover scaricare il comando puttygen dal sito web di PuTTY. Leggete la documentazione di puttygen per i dettagli su come usare il comando. - Quando generate una coppia di chiavi, di solito è altamente 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.) - - 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 authorized_keys nella loro directory .ssh. - - Su un sistema di tipo Unix, la vostra chiave pubblica avrà una estensione .pub. Se state usando puttygen sotto Windows, potete salvare la chiave pubblica in un file di vostra scelta, o incollarla dalla finestra in cui è visualizzata direttamente nel file authorized_keys. + 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 sotto 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. Usare un agente di autenticazione 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). - 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. + 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. Su sistemi di tipo Unix, l'agente è chiamato ssh-agent e spesso viene eseguito automaticamente quando entrate nel sistema. Dovrete usare il comando ssh-add per aggiungere una nuova passphrase alla memoria dell'agente. - Sotto Windows, se state usando TortoiseHg, il comando pageant funziona come un agente. Come con puttygen, avrete bisogno di scaricare pageant dal sito web di PuTTY e di leggere la sua documentazione. Il comando pageant aggiunge un'icona alla vostra tray di sistema che vi permetterà di gestire le passphrase memorizzate. + Sotto Windows, se state usando TortoiseHg, il comando pageant funziona come un agente. Come con puttygen, avrete bisogno di scaricare pageant dal sito web di PuTTY e di leggere la sua documentazione. Il comando pageant aggiunge alla vostra area di notifica un'icona che vi permetterà di gestire le passphrase memorizzate. @@ -302,19 +304,19 @@ Configurare adeguatamente il server - 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. - - Prima di provare a usare Mercurial per comunicare con un server ssh, è preferibile che prima vi assicuriate di poter usare i normali comandi ssh o putty 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 prima di preoccuparvi di sapere se c'è un problema 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 cosa c'è che non va. I problemi più comuni sono i seguenti. + 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 quel che è peggio è che 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. - Se avete un errore di tipo connection refused (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. - - Se avete un errore di tipo no route to host (???), questo significa che avete un indirizzo sbagliato per il server o un firewall seriamente chiuso che non ammetterà l'esistenza del server. - - Se avete un errore di tipo permission denied (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. + Se l'errore è di tipo connection refused (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. + + Se l'errore è di tipo no route to host (macchina remota non raggiungibile), questo significa che avete un indirizzo sbagliato per il server o un firewall con impostazioni talmente restrittive da impedirgli di vedere il server. + + Se l'errore è di tipo permission denied (permesso negato), potreste aver digitato in maniera inesatta il nome utente sul server, o la passphrase della vostra chiave, o la password dell'utente remoto. - 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. + 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 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. @@ -322,23 +324,23 @@ Potreste aver memorizzato la passphrase per la chiave sbagliata. - Se vi viene richiesta la password per l'utente remoto, ecco altri possibili problemi da controllare. + Se vi viene richiesta la password per l'utente remoto, ecco altri possibili cause. - La directory personale dell'utente o la sua directory .ssh potrebbero avere permessi eccessivamente liberali. Come risultato, il demone ssh non si fiderà né leggerà il file authorized_keys. Per esempio, una directory personale o una directory .ssh con il permesso di scrittura per il gruppo dell'utente impostato causerà spesso questo sintomo. - - Il file authorized_keys 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à. + La directory personale dell'utente o la sua directory .ssh potrebbero avere permessi eccessivamente liberali. Come risultato, il demone ssh non si fiderà dei contenuti del file authorized_keys e quindi non lo leggerà. Per esempio, una directory personale o una directory .ssh con il permesso di scrittura di gruppo abilitato causerà spesso questo sintomo. + + Il file authorized_keys dell'utente potrebbe avere un problema. Se l'utente non è l'unico proprietario del file o qualcun altro può scrivere sul file, il demone ssh non si fiderà dei suoi contenuti e quindi non lo leggerà. - 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. - ssh myserver date - - 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 ssh 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 tty -s.) - - 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: - - ssh myserver 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. + 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, o peggio, potrebbero potenzialmente causare problemi durante l'esecuzione remota dei comandi Mercurial. Mercurial prova a scoprire 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. Mercurial è veramente installato sul server? So che sembra una cosa ovvia, ma vale la pena di controllare! @@ -349,16 +351,16 @@ La variabile d'ambiente PYTHONPATH 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. - 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 ~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 per avere una immagine più chiara di quello che sta succedendo. + 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 ospitato da quel nome utente su quel server. Se a questo punto incontrate qualche problema con Mercurial e ssh, provate a usare l'opzione per avere una immagine più chiara di quello che sta succedendo. Usare la compressione con ssh 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. - 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. - - Sia ssh che plink accettano l'opzione per attivare la compressione. Potete facilmente modificare il vostro file ~/.hgrc per 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. + 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 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 @@ -368,31 +370,31 @@ Compression yes HostName hg.example.com - Questo definisce un alias per il nome della macchina, hg. Quando usate quel nome sulla riga di comando ssh o in un URL ssh di Mercurial, ssh si connetterà a hg.example.com 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é. + 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. Questo vi fornisce sia un nome più corto da digitare sia la compressione, che sono entrambe buone cose di per sé. - Servire attraverso HTTP usando CGI - - Il modo più semplice per ~host~ un repository è quello di usare un server web e il supporto CGI di Mercurial. + Servire i dati attraverso HTTP usando CGI + + Il modo più semplice per condividere uno o più repository in modo permanente è quello di usare un server web e il supporto CGI di Mercurial. A seconda di quanto siete ambiziosi, configurare l'interfaccia CGI di Mercurial può portarvi via da pochi momenti a diverse ore. - 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. + Cominceremo con il più semplice degli esempi per poi farci 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. Si richiede alta sopportazione del dolore - 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. - - 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. + Configurare un server web è un'attività complessa, intricata e altamente dipendente dal sistema. Non mi sarebbe possibile 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. + + Se non avete uno stomaco abbastanza forte da aggiustare continuamente le configurazioni, o un bisogno impellente di gestire i vostri servizi, potreste voler provare uno dei servizi di hosting pubblici che ho menzionato in precedenza. Lista di controllo per la configurazione di un server web - Prima di proseguire, prendetevi alcuni momenti per controllare alcuni aspetti delle impostazioni del vostro sistema. + Prima di proseguire, prendetevi qualche momento per controllare alcuni aspetti delle impostazioni del vostro sistema. 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. @@ -402,68 +404,68 @@ 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. - Se non avete un server web installato e non avete una sostanziale esperienza nel configurare Apache, dovreste considerare l'uso del server web lighttpd invece di Apache. Apache ha una reputazione ben meritata per configurazioni barocche e confuse. Mentre lighttpd è meno capace in alcuni modi rispetto ad Apache, la maggior parte di queste capacità non è rilevante per servire repository Mercurial. E lighttpd è innegabilmente molto più facile da cominciare di Apache. + Se non avete un server web installato e non avete una sostanziale 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 barocche e confuse. Mentre Apache è dotato di maggiori funzionalità rispetto a lighttpd, buona parte di queste funzionalità non è rilevante per servire repository Mercurial. E lighttpd è innegabilmente molto più facile da approcciare di Apache. Configurazione CGI di base - Su sistemi di tipo Unix, è comune per gli utenti di avere 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 a un URL della forma http://www.example.com/~username/foo. - - Per cominciare, trovate 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. + 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 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 anche sul fatto che la directory in cui risiede lo script non sia modificabile da altri. + 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 Che cosa <emphasis>potrebbe</emphasis> andare storto? - Una volta che avete copiato lo script CGI al suo posto, aprite un browser web e provate a visitare l'URL http://myhostname/~myuser/hgweb.cgi, ma 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. - - Il vostro server web potrebbe avere disabilitato le directory per utente. Se state usando Apache, cercate la direttiva UserDir nel vostro file di configurazione. Se non è presente, le directory per utente sono disabilitate. Se è presente, ma il suo valore è disabled, allora le directory per utente sono disabilitate. Altrimenti, la stringa che segue UserDir vi dà il nome della sottodirectory della vostra directory personale in cui Apache guarderà, per esempio public_html. - - 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 public_html, nonché leggere i file in essa contenuti. Ecco una ricetta veloce per aiutarvi a rendere i vostri permessi più appropriati. + Una volta che avete copiato lo script CGI al suo posto, aprite un browser web e provate a visitare l'URL http://nomemacchina/~nomeutente/hgweb.cgi, ma raccogliete le forze per affrontare un fallimento immediato. 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. Quelli che seguono sono tutti i problemi che ho incontrato su un sistema che esegue Fedora 7, con un'installazione vergine di Apache e un account utente che ho creato espressamente per effettuare questo esercizio. + + Il vostro server web potrebbe aver disabilitato le directory di pubblicazione per utente. Se state usando Apache, cercate la direttiva UserDir nel vostro file di configurazione. Se non è presente, o se è presente ma il suo valore è disabled, allora le directory per utente sono disabilitate. Altrimenti, la stringa che segue UserDir è il nome della sottodirectory della vostra directory personale che verrà letta da Apache, per esempio public_html. + + 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 public_html, nonché di leggere i file in essa contenuti. Ecco una ricetta veloce per aiutarvi a rendere i vostri permessi più appropriati. chmod 755 ~ find ~/public_html -type d -print0 | xargs -0r chmod 755 find ~/public_html -type f -print0 | xargs -0r chmod 644 - 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 troppo permissivi. Per esempio, il sottosistema suexec di Apache non eseguirà uno script che può essere modificato dal gruppo o dal resto del mondo. - - 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. + 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 troppo permissivi. Per esempio, il sottosistema suexec di Apache non eseguirà uno script che può essere modificato dal gruppo o dagli altri. + + Il vostro server web potrebbe essere configurato per disabilitare l'esecuzione di programmi CGI nella vostra directory di pubblicazione per utente. Ecco la configurazione per utente predefinita di Apache sul mio sistema Fedora. &ch06-apache-config.lst; - Se trovate un gruppo Directory simile a questo nella vostra configurazione di Apache, la direttiva da cercare in questo gruppo si chiama Options. Aggiungete ExecCGI alla fine di questa lista se non è presente e riavviate il server web. - - 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. + Se trovate un gruppo Directory simile a questo nella vostra configurazione di Apache, la direttiva da cercare in questo gruppo si chiama Options. Aggiungete ExecCGI alla fine di questa lista, se non è già presente, e riavviate il server web. + + Se vedete che Apache vi restituisce il testo dello script CGI invece di eseguirlo, potreste dover attivare (se è già presente) o aggiungere una direttiva come questa. AddHandler cgi-script .cgi - 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 mercurial. 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 hgweb.cgi e seguite le indicazioni che trovate per impostare correttamente la vostra variabile d'ambiente PYTHONPATH. - - Infine, otterrete sicuramente un'altra colorata traccia dello stack di esecuzione di Python: questa volta si lamenterà di non poter trovare /path/to/repository. Modificate il vostro script hgweb.cgi e sostituite la stringa /path/to/repository con il percorso completo del repository che volete servire. - - A questo punto, quando provate a ricaricare la pagina, dovrebbe presentarvisi una gradevole vista HTML della cronologia del vostro repository. Whew! + Può anche capitare che vi venga restituita una traccia colorata dello stack di esecuzione di Python dove l'interprete afferma di non poter importare un modulo relativo a mercurial. Questo è un concreto passo in avanti! Il server ora è in grado di eseguire il vostro script CGI. Questo errore può accadere soltanto se state eseguendo un'installazione privata di Mercurial invece di un'installazione di sistema. Ricordate che il server web esegue il programma CGI senza alcuna variabile di ambiente che date per scontata in una sessione interattiva. Se vi capita questo errore, aprite la vostra copia di hgweb.cgi e seguite le indicazioni che trovate per impostare correttamente la vostra variabile d'ambiente PYTHONPATH. + + Infine, otterrete sicuramente un'altra traccia colorata dello stack di esecuzione di Python: questa volta l'interprete si lamenterà di non poter trovare /path/to/repository. Modificate il vostro script hgweb.cgi per sostituire la stringa /path/to/repository con il percorso completo del repository che volete condividere. + + A questo punto, quando provate a ricaricare la pagina, vi si dovrebbe presentare una gradevole vista HTML della cronologia del vostro repository. Whew! Configurare lighttpd - Per completare i miei esperimenti, ho provato a configurare il sempre più popolare server web lighttpd 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 hgweb.cgi fosse propriamente modificato. - - Una volta messo in esecuzione Apache, riuscire a far servire il repository da lighttpd è stato un attimo (in altre parole, anche se state provando a usare lighttpd, dovreste leggere la sezione su Apache). Per prima cosa ho dovuto modificare la sezione mod_access del suo file di configurazione per abilitare mod_cgi e mod_userdir, che erano entrambi disabilitati di default sul mio sistema. Poi ho aggiunto alcune righe alla fine del file di configurazione, per configurare questi moduli. + Per completare i miei esperimenti, ho provato a configurare il sempre più popolare server web lighttpd per condividere lo stesso repository come appena descritto nel caso di Apache. Avevo già superato tutti i problemi illustrati con Apache, molti dei quali non sono dovuti a uno specifico server. Come risultato, ero piuttosto sicuro che i miei permessi per i file e le directory fossero corretti e che il mio script hgweb.cgi fosse adeguatamente modificato. + + Una volta messo in esecuzione Apache, riuscire a condividere il repository tramite lighttpd è stato un attimo (in altre parole, anche se state provando a usare lighttpd, dovreste leggere la sezione su Apache). Per prima cosa ho dovuto modificare la sezione mod_access del suo file di configurazione per abilitare mod_cgi e mod_userdir, che erano entrambi disabilitati di default sul mio sistema. Poi ho aggiunto alcune righe alla fine del file di configurazione per configurare questi moduli. userdir.path = "public_html" cgi.assign = (".cgi" => "" ) - Fatto questo, lighttpd ha funzionato immediatamente per me. Se avessi configurato lighttpd prima di Apache, mi sarei quasi certamente imbattuto negli stessi problemi di configurazione a livello di sistema incontrati con Apache. Tuttavia, ho trovato lighttpd 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 lighttpd. + Fatto questo, lighttpd ha funzionato immediatamente. Se avessi configurato lighttpd prima di Apache, mi sarei quasi certamente imbattuto negli stessi problemi di configurazione a livello di sistema incontrati con Apache. Tuttavia, ho trovato lighttpd 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 lighttpd. - Condividere molteplici repository con un solo script CGI - - Lo script hgweb.cgi 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 hgwebdir.cgi. + Condividere più repository con un solo script 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 differente, 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. @@ -472,38 +474,38 @@ cp .../hgwebdir.cgi ~/public_html chmod 755 ~/public_html ~/public_html/hgwebdir.cgi - Una volta effettuata questa configurazione di base, provate a visitare http://myhostname/~myuser/hgwebdir.cgi 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 . - - Lo script hgwebdir.cgi si basa su un file di configurazione esterno. Di default, cerca un file chiamato hgweb.config 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 ini di Windows, riconoscibile dal modulo ConfigParser web:configparser di Python. - - Il modo più facile di configurare hgwebdir.cgi è tramite una sezione chiamata collections. Questo pubblicherà automaticamente tutti i repository sotto le directory che nominate. La sezione dovrebbe somigliare a questo: + 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 . + + Lo script hgwebdir.cgi si basa su un file di configurazione esterno. Di 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 di Python. + + Il modo più facile di configurare hgwebdir.cgi è tramite una sezione chiamata collections. Questo pubblicherà automaticamente tutti i repository contenuti nelle directory che nominate. La sezione dovrebbe somigliare a questa: [collections] -/my/root = /my/root +/mia/radice = /mia/radice Mercurial la interpreta guardando al nome della directory sul lato destro del segno =, trovando 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 sia /my/root/this/repo, lo script CGI eliminerà la parte /my/root iniziale dal nome e pubblicherà il repository con il percorso virtuale this/repo. Se l'URL per il nostro script CGI è http://myhostname/~myuser/hgwebdir.cgi, l'URL completo per quel repository sarà http://myhostname/~myuser/hgwebdir.cgi/this/repo. - - Se sostituiamo /my/root sul lato sinstro di questo esempio con /my, allora hgwebdir.cgi eliminerà solo /my dal nome del repository e ci darà il percorso virtuale root/this/repo invece di this/repo. - - Lo script hgwebdir.cgi cercherà ricorsivamente in ogni directory elencata nella sezione collections del suo file di configurazione, ma non navigherà ricorsivamente nei repository che trova. - - Il meccanismo delle collezioni nella sezione collections facilita la pubblicazione di molti repository in modo ~fire and forget~. 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. + 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. + + 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 = /my/path/to/some/repo -repo2 = /some/path/to/another - 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. - - Se lo desiderate, potete usare entrambe le sezioni collections e paths simultaneamente in un unico file di configurazione. +repo1 = /mio/percorso/a/qualche/repository +repo2 = /qualche/percorso/a/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 hannolo stesso percorso virtuale, hgwebdir.cgi non riporterà un errore, ma si comporterà in maniera imprevedibile. + Se diversi repository hanno lo stesso percorso virtuale, hgwebdir.cgi non segnalerà un errore, ma si comporterà in maniera imprevedibile. @@ -513,37 +515,37 @@ 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. - Di default, questa funzionalità è disabilitata. Per abilitarla, dovrete aggiungere un elemento allow_archive alla sezione web del vostro file ~/.hgrc; vedete più oltre per i dettagli. + Di default, questa funzionalità è disabilitata. Per abilitarla, dovrete aggiungere un elemento allow_archive alla sezione web del vostro file ~/.hgrc come spiegato in dettaglio nella prossima sezione. Le opzioni di configurazione web - Le interfacce web di Mercurial (il comando hg serve e gli script hgweb.cgi e hgwebdir.cgi) hanno un certo numero di opzioni di configurazine che potete impostare. Queste appartengono a una sezione chiamata web. + 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 appartengono a una sezione chiamata web. - allow_archive: 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. + allow_archive: Determina qual è (e se c'è) il meccanismo di scaricamento che viene supportato da Mercurial. Se abilitate questa funzionalità, gli utenti dell'interfaccia web saranno in grado di scaricare un archivio di qualsiasi revisione stiano visitando nel repository. Per abilitare la funzionalità di archivio, questo elemento deve prendere la forma di una sequenza di parole scelte dalla lista seguente. - bz2: un archivio tar, compresso usando la compressione bzip2. Questo ha il miglior rapporto di compressione, ma usa più tempo di CPU sul server. + bz2: un archivio tar, compresso usando la compressione bzip2. Questo formato ha il miglior rapporto di compressione, ma usa più tempo di CPU sul server. gz: un archivio tar, compresso usando la compressione gzip. - zip: un archivio zip, compresso usando la compressione LZW. Questo formato ha il peggior rapporto di compressione, ma è largamente usando nel mondo Windows. + zip: un archivio zip, compresso usando la compressione LZW. Questo formato ha il peggior rapporto di compressione, ma è largamente usato nel mondo Windows. - Se fornite una lista vuota o se non avete una voce allow_archive questa funzionalità sarà disabilitata. Ecco un esempio di come abilitare tutti e tre i formati supportati. + Se fornite una lista vuota o se non avete una voce allow_archive, questa funzionalità sarà disabilitata. Ecco un esempio di come abilitare tutti e tre i formati supportati. [web] allow_archive = bz2 gz zip - allowpull: booleano. Determina se l'interfaccia web permette agli utenti remoti di usare i comandi hg pull e hg clone su questo repository via HTTP. Se impostato a no o a false, solo la parte orientata agli umani dell'interfaccia web sarà disponibile. + allowpull: booleano. Determina se l'interfaccia web permette agli utenti remoti di usare i comandi hg pull e hg clone su questo repository via HTTP. Se impostato a no o a false, solo la parte dedicata agli umani dell'interfaccia web sarà disponibile. contact: 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 .hg/hgrc del singolo repository, ma può anche avere senso utilizzarla in un file ~/.hgrc globale se tutti i repository hanno un singolo manutentore. maxchanges: intero. Il numero massimo predefinito di changeset da visualizzare in una singola pagina web. - maxfiles: intero. Il numero massimo predefinito di file modificati da mostrare in una singola pagina web. - - stripes: 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. - - style: controlla il template che Mercurial usa per visualizzare l'interfaccia web. Mercurial include diversi template web. + maxfiles: intero. Il numero massimo predefinito di file modificati da visualizzare in una singola pagina web. + + stripes: intero. Se l'interfaccia web mostra strisce a colori alternati per rendere più facile l'allineamento visuale delle righe quando state guardando una tabella, questo numero controlla il numero di righe in ogni striscia. + + style: controlla il template usato da Mercurial per visualizzare l'interfaccia web. Mercurial include diversi template web. coal è monocromatico. @@ -552,7 +554,7 @@ gitweb emula lo stile visivo dell'interfaccia web di git. - monoblue usa blu e grigi solidi. + monoblue usa blu e grigi uniformi. paper è il template predefinito. @@ -561,13 +563,13 @@ spartan è stato il template predefinito per lungo tempo. - Potete anche specificare un vostro template personalizzato; leggete il FIXME per i dettagli. Qui potete vedere come abilitare lo stile gitweb. + Potete anche specificare un vostro template personalizzato, come vedrete in dettaglio nel FIXME per i dettagli. Qui potete vedere come abilitare lo stile gitweb. [web] style = gitweb templates: percorso. La directory in cui cercare i file di template. Di default, Mercurial li cerca nella directory in cui è stato installato. - Se state usando hgwebdir.cgi, potete inserire alcuni elementi di configurazione nella sezione web del file hgweb.config invece che nel file ~/.hgrc per convenienza. Questi elementi sono motd e style. + 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. Opzioni specifiche per un singolo repository @@ -585,11 +587,11 @@ Alcuni degli elementi nella sezione web di un file ~/.hgrc possono essere usati solo con il comando hg serve. - accesslog: percorso. Il nome di un file in cui scrivere un registro degli accessi. Di default, il comando hg serve scrive queste informazioni sullo standard output, non su un file. Le voci del registro vengono scritte nel formato di file combined standard usato da quasi tutti i server web. + accesslog: percorso. Il nome di un file in cui scrivere un registro degli accessi. Normalmente, il comando hg serve scrive queste informazioni sul canale di uscita predefinito, non su un file. Le voci del registro vengono scritte nel formato combined che è uno standard usato da quasi tutti i server web. address: 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. - errorlog: percorso. Il nome di un file in cui scrivere un registro degli errori. Di default, il comando hg serve scrive queste informazioni sullo standard output, non su un file. + errorlog: percorso. Il nome di un file in cui scrivere un registro degli errori. Normalmente, il comando hg serve scrive queste informazioni sul canale di uscita predefinito, non su un file. ipv6: booleano. Indica se usare il protocollo IPv6. Di default, IPv6 non viene usato. @@ -602,26 +604,26 @@ È importante ricordare che un server web come Apache o lighttpd sarà in esecuzione sotto un identificatore di utente diverso dal vostro. Anche gli script CGI eseguiti dal vostro server, come hgweb.cgi, verranno solitamente eseguiti sotto quell'identificatore. - Se aggiungete elementi della sezione web al vostro file ~/.hgrc personale, gli script CGI non potranno leggere quel file ~/.hgrc. Quelle impostazioni quindi avranno effetto solo sul comportamento del comando hg serve quando voi lo eseguirete. Per fare in modo che gli script CGI vedano le vostre impostazioni, create un file ~/.hgrc nella directory personale dell'utente il cui identificatore viene usato per eseguire il vostro server web, oppure aggiungete quelle impostazioni a un file hgrc ~system-wide~. + Se aggiungete elementi della sezione web al vostro file ~/.hgrc personale, gli script CGI non potranno leggere quel file ~/.hgrc. Quelle impostazioni quindi avranno effetto solo sul comportamento del comando hg serve quando sarete voi a eseguirlo. Per fare in modo che gli script CGI vedano le vostre impostazioni, create un file ~/.hgrc nella directory personale dell'utente il cui identificatore viene usato per eseguire il vostro server web, oppure aggiungete quelle impostazioni a un file hgrc di sistema. - Configurazione ~system-wide~ - - 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. - - Se un file chiamato /etc/mercurial/hgrc 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 .rc in una directory chiamata /etc/mercurial/hgrc.d e applicherà le impostazioni di configurazione trovate in ognuno di quei file. - - - Rendere Mercurial più fiducioso - - Una situazione in cui un file hgrc 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 .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 del file .hg/hgrc di quel repository. - - Se tutti i membri di uno specifico gruppo Unix sono nello stesso gruppo di sviluppo e dovrebbero 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 hgrc ~system-wide~ come il seguente: - - # Save this as e.g. /etc/mercurial/hgrc.d/trust.rc + Configurazione di sistema + + 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 globali predefiniti, come il tema grafico da usare nell'interfaccia web. + + Se il file /etc/mercurial/hgrc esiste, Mercurial lo leggerà all'avvio e applicherà ogni impostazione di configurazione trovata in quel file. Cercherà anche i file il cui nome termina con l'estensione .rc in una directory chiamata /etc/mercurial/hgrc.d e applicherà le impostazioni di configurazione trovate in ognuno di quei file. + + + Rendere Mercurial meno prevenuto + + Un file hgrc globale può essere utile nella situazione in cui gli utenti stanno estraendo cambiamenti posseduti da altri utenti. Di 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"