# HG changeset patch # User gpiancastelli # Date 1250883742 -7200 # Node ID 0a49072e8c7fda403cb90b7b2359f63acc2aac35 # Parent 96d16156860924cc58160f6b1ef9b45491a680ca Final editing for chapters 4-7. diff -r 96d161568609 -r 0a49072e8c7f it/ch04-concepts.xml --- a/it/ch04-concepts.xml Fri Aug 21 21:42:02 2009 +0200 +++ b/it/ch04-concepts.xml Fri Aug 21 21:42:22 2009 +0200 @@ -29,7 +29,7 @@ - Gestire i file archiviati + Gestire i file monitorati Mercurial usa una struttura chiamata manifest (in italiano, manifesto) per collezionare informazioni sui file di cui tiene traccia. Ogni voce nel manifest contiene informazioni sui file presenti in un singolo changeset e registra quali file sono contenuti nel changeset, la revisione di ogni file e alcuni altri metadati sui file. @@ -45,7 +45,7 @@ Nell'ambito di un changelog, di un manifest, o di un filelog, ogni revisione mantiene un puntatore al suo genitore diretto (o ai suoi due genitori, se è una revisione di unione). Come ho già detto, esistono anche relazioni tra revisioni attraverso queste strutture, e tali relazioni sono di natura gerarchica. - Per ogni changeset nel repository, esiste esattamente una revisione memorizzata nel changelog. Ogni revisione del changelog contiene un puntatore a una singola revisione del manifest. Una revisione del manifest include un puntatore a una singola revisione di ogni filelog archiviato quando il changeset è stato creato. Queste relazioni sono illustrate nella . + Per ogni changeset nel repository, esiste esattamente una revisione memorizzata nel changelog. Ogni revisione del changelog contiene un puntatore a una singola revisione del manifest. Una revisione del manifest include un puntatore a una singola revisione di ogni filelog registrato quando il changeset è stato creato. Queste relazioni sono illustrate nella .
Relazioni tra i metadati @@ -81,13 +81,13 @@ In più, Mercurial tratta ogni scrittura come parte di una transazione che può coinvolgere un qualsiasi numero di file. Una transazione è atomica: o l'intera transazione ha successo e i suoi effetti sono visibili in lettura in un unico passo, oppure l'operazione viene completamente annullata. Questa garanzia di atomicità significa che se state eseguendo due copie di Mercurial, una che sta leggendo dati e l'altra che sta scrivendo, la copia che agisce in lettura non vedrà mai un risultato parzialmente scritto che potrebbe confonderla. - Il fatto che Mercurial operi solo aggiungendo dati alla fine dei file rende più facile fornire questa garanzia transazionale. Più è facile fare cose come queste, più dovreste avere fiducia che vengano fatte correttamente. + Il fatto che Mercurial operi solo aggiungendo dati alla fine dei file rende più facile fornire questa garanzia transazionale. Più è facile fare cose come queste, più dovreste avere fiducia nel fatto che vengano eseguite correttamente. Reperimento veloce - Mercurial evita astutamente un'insidia comune a tutti i primi sistemi di controllo di revisione: il problema del reperimento inefficiente. La maggior parte dei sistemi di controllo di revisione memorizza i contenuti di una revisione come una serie incrementale di modifiche rispetto a una fotografia. (Alcuni basano la fotografia sulla revisione più vecchia, altri su quella più nuova.) Per ricostruire una revisione specifica, dovete leggere prima la fotografia e poi ognuna delle revisioni tra la fotografia e la revisione che volete. Più cronologia accumula un file, più revisioni dovete leggere, quindi più tempo viene impiegato per ricostruire una particolare revisione. + Mercurial evita astutamente un'insidia comune a tutti i primi sistemi di controllo di revisione: il problema del reperimento inefficiente. La maggior parte dei sistemi di controllo di revisione memorizza i contenuti di una revisione come una serie incrementale di modifiche rispetto a una fotografia. (Alcuni basano la fotografia sulla revisione più vecchia, altri su quella più recente.) Per ricostruire una revisione specifica, dovete leggere prima la fotografia e poi ognuna delle revisioni tra la fotografia e la revisione che volete. Più cronologia accumula un file, più revisioni dovete leggere, quindi più tempo viene impiegato per ricostruire una particolare revisione.
Fotografia di un revlog, con delta incrementali @@ -130,7 +130,7 @@ Nella , potete vedere un esempio della struttura concettuale di un revlog. I filelog, i manifest e i changelog hanno tutti questa identica struttura e differiscono solo per il tipo di dati memorizzati in ogni delta e fotografia. - La prima revisione in un revlog (nella parte inferiore dell'immagine) presenta un identificatore nullo in entrambi gli spazi riservati ai genitori. Per una revisione normale, lo spazio del primo genitore contiene l'identificatore della revisione genitore e lo spazio del secondo contiene l'identificatore nullo, indicando che la revisione possiede un solo vero genitore. Due revisioni qualsiasi che possiedano lo stesso genitore si chiamano rami. Una revisione che rappresenta un'unione tra rami ha due identificatori di revisione normali negli spazi dedicati ai propri genitori. + La prima revisione in un revlog (nella parte inferiore dell'immagine) presenta un identificatore nullo in entrambi gli spazi riservati ai genitori. Per una revisione normale, lo spazio del primo genitore contiene l'identificatore della revisione genitore e lo spazio del secondo contiene l'identificatore nullo, indicando che la revisione possiede un solo vero genitore. Due revisioni qualsiasi che possiedano lo stesso genitore si chiamano rami. Una revisione che rappresenta un'unione tra rami ha due identificatori di revisione normali negli spazi dedicati ai propri genitori.
La struttura concettuale di un revlog @@ -146,16 +146,16 @@ Nella directory di lavoro, Mercurial mantiene una fotografia dei file contenuti nel repository scattata su un changeset particolare. - La directory di lavoro sa quale changeset contiene. Quando aggiornate la directory di lavoro per contenere un particolare changeset, Mercurial cerca la revisione appropriata del manifest per trovare quali file aveva registrato nel momento in cui quel changeset è stato inserito e qual era la revisione corrente di ogni file in quel momento. Poi, ricrea una copia di tutti quei file, con gli stessi contenuti che avevano quando il changeset è stato inserito. - - Il dirstate (letteralmente, stato della directory) è una struttura speciale che contiene le informazioni possedute da Mercurial sulla directory di lavoro. Viene mantenuto sotto forma di un file chiamato .hg/dirstate all'interno di un repository. Il dirstate contiene i dettagli del changeset a cui la directory di lavoro è aggiornata e di tutti i file di cui Mercurial sta tenendo traccia nella directory di lavoro. Il dirstate permette a Mercurial anche di notare velocemente i file modificati, registrando le loro date e dimensioni al momento dell'aggiornamento. + La directory di lavoro sa quale changeset contiene. Quando aggiornate la directory di lavoro per contenere un particolare changeset, Mercurial cerca la revisione appropriata del manifest per trovare quali file aveva registrato nel momento in cui quel changeset è stato inserito e qual era la revisione corrente di ogni file in quel momento. Poi, ricrea una copia di tutti quei file con gli stessi contenuti che avevano quando il changeset è stato inserito. + + Il dirstate (letteralmente, stato della directory) è una struttura speciale che contiene le informazioni possedute da Mercurial sulla directory di lavoro. Viene mantenuto sotto forma di un file chiamato .hg/dirstate all'interno di un repository. Il dirstate contiene i dettagli del changeset a cui la directory di lavoro è aggiornata e di tutti i file che Mercurial sta monitorando nella directory di lavoro. Il dirstate permette a Mercurial anche di notare velocemente i file modificati, registrando le loro date e dimensioni al momento dell'aggiornamento. Il dirstate riserva spazio per due genitori, esattamente come una revisione di un revlog, in modo da poter rappresentare sia una normale revisione (con un genitore) che un'unione di due revisioni precedenti. Quando usate il comando hg update, il changeset a cui aggiornate la directory di lavoro viene memorizzato nello spazio del primo genitore e l'identificatore nullo nello spazio del secondo. Quando incorporate un altro changeset tramite hg merge, il primo genitore rimane lo stesso e il secondo genitore diventa il changeset che state incorporando. Il comando hg parents vi dice quali sono i genitori del dirstate. Cosa succede quando eseguite un commit - Il dirstate mantiene le informazioni sui genitori per altri scopi oltre alla mera contabilità. Mercurial usa i genitori del dirstate come i genitori di un nuovo changeset quando effettuate un commit. + Il dirstate mantiene le informazioni sui genitori per altri scopi in aggiunta alla mera contabilità. Mercurial usa i genitori del dirstate come i genitori di un nuovo changeset quando effettuate un commit.
La directory di lavoro può avere due genitori @@ -287,11 +287,11 @@ Ordinamento e atomicità delle operazioni di lettura e scrittura - Quando si cerca di garantire che una lettura non veda scritture parziali, non è sufficiente limitarsi ad aggiungere in coda ai file le nuove informazioni. Se ricordate la , le revisioni in un changelog puntano alle revisioni nel manifest e le revisioni nel manifest puntano alle revisioni nel filelog. Questa gerarchia è intenzionale. - - Un'operazione di scrittura avvia una transazione modificando i dati nel filelog e nel manifest, senza modificare alcun dato contenuto nel changelog prima che di aver terminato con quelli. Un'operazione di lettura comincia leggendo i dati nel changelog, poi i dati nel manifest seguiti dai dati nel filelog. - - Dato che la scrittura ha sempre terminato di modificare i dati nel filelog e nel manifest prima di modificare il changelog, una lettura non vedrà mai il changelog puntare verso una revisione parzialmente modificata del manifest e non vedrà mai il manifest puntare verso una revisione parzialmente modificata del filelog. + Quando si cerca di garantire che una lettura non veda scritture parziali, non è sufficiente limitarsi ad aggiungere in coda ai file le nuove informazioni. Se ricordate la , le revisioni in un changelog puntano alle revisioni nel manifest e le revisioni nel manifest puntano alle revisioni nei filelog. Questa gerarchia è intenzionale. + + Un'operazione di scrittura avvia una transazione modificando i dati nei filelog e nel manifest, senza modificare alcun dato contenuto nel changelog prima che di aver terminato con quelli. Un'operazione di lettura comincia leggendo i dati nel changelog, poi i dati nel manifest seguiti dai dati nei filelog. + + Dato che la scrittura ha sempre terminato di modificare i dati nei filelog e nel manifest prima di modificare il changelog, una lettura non vedrà mai il changelog puntare verso una revisione parzialmente modificata del manifest e non vedrà mai il manifest puntare verso una revisione parzialmente modificata di un filelog. @@ -319,13 +319,13 @@ Mercurial adotta anche una strategia copy-on-write per clonare un repository su disco locale. Invece di copiare ogni file di revlog dal vecchio repository al nuovo, utilizza collegamenti fisici per indicare che due nomi puntano allo stesso file. Quando Mercurial sta per modificare uno dei file di un revlog, controlla per vedere se il numero di nomi che puntano al file è più grande di uno. Se è così, questo significa che più di un repository sta usando il file, quindi Mercurial ne crea una nuova copia riservata a questo repository. - Alcuni sviluppatori di sistemi per il controllo di revisione hanno fatto notare che la creazione di una copia privata completa di un file non usa lo spazio su disco in maniera molto efficiente. Sebbene questo sia vero, lo spazio su disco è piuttosto economico, e questo metodo consente di avere le prestazioni migliori rinviando la maggior parte della contabilità al sistema operativo. Molto probabilmente, una strategia alternativa ridurrebbe le prestazioni e aumenterebbe la complessità del software, ma velocità e semplicità sono aspetti chiave per la facilità nell'uso quotidiano. + Alcuni sviluppatori di sistemi per il controllo di revisione hanno fatto notare che la creazione di una copia privata completa di un file non sfrutta lo spazio su disco in maniera molto efficiente. Sebbene questo sia vero, lo spazio su disco è piuttosto economico, e questo metodo consente di avere le prestazioni migliori rinviando la maggior parte della contabilità al sistema operativo. Molto probabilmente, una strategia alternativa ridurrebbe le prestazioni e aumenterebbe la complessità del software, ma velocità e semplicità sono aspetti chiave per la facilità nell'uso quotidiano. Altre informazioni contenute nel dirstate - Dato che Mercurial non vi obbliga a dirgli quando state modificando un file, usa il dirstate per memorizzare alcune informazioni aggiuntive in modo da poter determinare efficientemente se avete modificato un file. Per ogni file nella directory di lavoro, Mercurial memorizza la data in cui ha registrato una modifica al file per l'ultima volta e la dimensione che il file aveva in quel momento. + Dato che Mercurial non vi obbliga a dirgli quando state modificando un file, usa il dirstate per memorizzare alcune informazioni aggiuntive in modo da poter determinare in maniera efficiente se avete modificato un file. Per ogni file nella directory di lavoro, Mercurial memorizza la data in cui ha registrato una modifica al file per l'ultima volta e la dimensione che il file aveva in quel momento. Quando utilizzate esplicitamente hg add, hg remove, hg rename, o hg copy su un file, Mercurial aggiorna il dirstate in modo che sappia cosa fare con quel file quando effettuate un commit. @@ -333,7 +333,7 @@ - Quando Mercurial controlla lo stato di un file nella directory di lavoro, per prima cosa confronta la data dell'ultima modifica del file con la data registrata nel dirstate che indica l'ultima volta in cui Mercurial ha registrato una modifica per quel file. Se le due date sono le stesse, il file non deve essere stato modificato, quindi Mercurial non ha bisogno di fare ulteriori controlli. + Quando Mercurial controlla lo stato di un file nella directory di lavoro, per prima cosa confronta la data dell'ultima modifica del file con la data memorizzata nel dirstate che indica l'ultima volta in cui Mercurial ha registrato una modifica per quel file. Se le due date sono le stesse, il file non deve essere stato modificato, quindi Mercurial non ha bisogno di fare ulteriori controlli. Se la dimensione del file è cambiata, il file deve essere stato modificato. Solo nel caso in cui la data di modifica sia cambiata, ma non la dimensione, Mercurial ha effettivamente bisogno di leggere i contenuti del file per vedere se è stato modificato. diff -r 96d161568609 -r 0a49072e8c7f it/ch05-daily.xml --- a/it/ch05-daily.xml Fri Aug 21 21:42:02 2009 +0200 +++ b/it/ch05-daily.xml Fri Aug 21 21:42:22 2009 +0200 @@ -5,11 +5,11 @@ Aggiungere file a un repository Mercurial - Mercurial lavora solo con i file che gli dite di gestire nel vostro repository. Il comando hg status vi dirà quali sono i file che Mercurial non conosce, usando un ? per mostrare questi file. + Mercurial lavora solo con i file che gli dite di amministrare nel vostro repository. Il comando hg status vi dirà quali sono i file che Mercurial non conosce, usando un ? per mostrare questi file. Per dire a Mercurial di tenere traccia di un file, usate il comando hg add. Una volta che avete aggiunto un file, la voce per quel file nell'elenco visualizzato da hg status cambia da ? ad A. - &interaction.daily.files.add; + &interaction.daily.files.add; Dopo aver eseguito hg commit, i file che avete aggiunto prima dell'inserimento non verranno più elencati dal comando hg status, perché il comportamento predefinito di hg status è quello di segnalarvi solo i file interessanti come (per esempio) quelli che avete modificato, rimosso, o rinominato. Se avete un repository che contiene migliaia di file, vorrete raramente sapere qualcosa dei file che Mercurial ha già registrato ma che non sono cambiati. (Potete comunque ottenere questa informazione, come vedremo più avanti.) @@ -51,7 +51,7 @@ &interaction.daily.files.remove; - Dopo che avete rimosso un file tramite hg remove, Mercurial non terrà più traccia di quel file anche se ricreate un file con lo stesso nome nella vostra directory di lavoro. Se ricreate davvero un file con lo stesso nome e volete che Mercurial registri il nuovo file, usate semplicemente hg add. Mercurial saprà che il nuovo file non è in alcun modo legato al vecchio file con lo stesso nome. + Dopo che avete rimosso un file tramite hg remove, Mercurial non terrà più traccia di quel file anche se ricreate un file con lo stesso nome nella vostra directory di lavoro. Se ricreate davvero un file con lo stesso nome e volete che Mercurial amministri il nuovo file, usate semplicemente hg add. Mercurial saprà che il nuovo file non è in alcun modo legato al vecchio file con lo stesso nome. La rimozione di un file non ha effetti sulla sua cronologia. @@ -74,7 +74,7 @@ &interaction.daily.files.missing; - Se il vostro repository contiene un file che hg status riporta come mancante, e volete che il file rimanga assente, potete eseguire hg remove in qualsiasi momento, per dire a Mercurial che volevate effettivamente rimuovere il file. + Se il vostro repository contiene un file che hg status segnala come mancante e volete che il file rimanga assente, potete eseguire hg remove in qualsiasi momento per dire a Mercurial che volevate effettivamente rimuovere il file. &interaction.daily.files.remove-after; @@ -383,9 +383,9 @@ Per esempio, un sistema distribuito di controllo di revisione non può, per sua natura, offrire un meccanismo di bloccaggio dei file. Quindi non esiste alcun meccanismo predefinito per evitare che due persone apportino cambiamenti in conflitto a un file binario. Se fate parte di un gruppo in cui diverse persone potrebbero modificare frequentemente i file binari, potrebbe non essere una buona idea impiegare Mercurial&emdash;o un qualsiasi altro sistema distribuito di controllo di revisione&emdash;per gestire quei file. - Quando memorizza le modifiche a un file, di solito Mercurial salva solo le differenze tra la versione corrente del file e quella precedente. Per la maggior parte dei file di testo questo approccio si rivela estremamente efficiente. Tuttavia, alcuni file (in particolare i file binari) sono fatti in modo tale che persino una piccola modifica al contenuto logico del file risulta nel cambiamento di molti o della maggior parte dei byte contenuti nel file. Per esempio, i file compressi sono particolarmente sensibili a questo effetto. Se le differenze tra ogni versione di un file e la successiva sono sempre grandi, Mercurial non riuscirà a memorizzare la cronologia del file in maniera molto efficiente. Questo potrebbe avere effetti sia sul bisogno di spazio di memorizzazione locale sia sulla quantità di tempo che viene impiegata per clonare un repository. - - Per avere un'idea di come questo problema potrebbe riguardarvi nella pratica, supponete di voler usare Mercurial per gestire un documento OpenOffice. OpenOffice memorizza i documenti su disco sotto forma di file zip compressi. Modificate anche solo una lettera nel vostro documento in OpenOffice e quasi ogni byte nell'intero file cambierà quando lo salverete. Ora supponete che le dimensioni di quel file siano di 2MB. Dato che la maggior parte del file cambia ogni volta che lo salvate, Mercurial dovrà memorizzare tutti i 2MB del file ogni volta che eseguite un commit, anche se dal vostro punto di vista forse solo poche parole vengono cambiate ogni volta. Un singolo file modificato frequentemente che non rispetti le assunzioni dei meccanismi di memorizzazione di Mercurial può facilmente avere un effetto fuori misura sulle dimensioni del repository. + Quando Mercurial memorizza le modifiche a un file, di solito salva solo le differenze tra la versione corrente del file e quella precedente. Per la maggior parte dei file di testo questo approccio si rivela estremamente efficiente. Tuttavia, alcuni file (in particolare i file binari) sono fatti in modo tale che persino una piccola modifica al contenuto logico del file risulta nel cambiamento di molti o della maggior parte dei byte contenuti nel file. Per esempio, i file compressi sono particolarmente sensibili a questo effetto. Se le differenze tra ogni versione di un file e la successiva sono sempre grandi, Mercurial non riuscirà a memorizzare la cronologia del file in maniera molto efficiente. Questo potrebbe avere effetti sia sul bisogno di spazio di memorizzazione locale sia sulla quantità di tempo che viene impiegata per clonare un repository. + + Per avere un'idea di come questo problema potrebbe riguardarvi nella pratica, supponete di voler usare Mercurial per gestire un documento OpenOffice. OpenOffice memorizza i documenti su disco sotto forma di file ZIP compressi. Modificate anche solo una lettera nel vostro documento in OpenOffice e quasi ogni byte nell'intero file cambierà quando lo salverete. Ora supponete che le dimensioni di quel file siano pari a 2MB. Dato che la maggior parte del file cambia ogni volta che lo salvate, Mercurial dovrà memorizzare tutti i 2MB del file ogni volta che eseguite un commit, anche se dal vostro punto di vista forse solo poche parole vengono cambiate ogni volta. Un singolo file modificato frequentemente che non rispetti le assunzioni dei meccanismi di memorizzazione di Mercurial può facilmente avere un effetto fuori misura sulle dimensioni del repository. Anche peggio, se due di voi modificano il documento OpenOffice su cui state lavorando, non c'è alcun modo utile di effettuare un'unione tra le diverse versioni. In effetti, non c'è nemmeno un buon modo di capire quali sono le differenze tra i vostri rispettivi cambiamenti. diff -r 96d161568609 -r 0a49072e8c7f it/ch06-collab.xml --- a/it/ch06-collab.xml Fri Aug 21 21:42:02 2009 +0200 +++ b/it/ch06-collab.xml Fri Aug 21 21:42:22 2009 +0200 @@ -2,7 +2,7 @@ Collaborare con altre persone - Essendo uno strumento completamente decentralizzato, Mercurial non impone alcuna politica su come le persone dovrebbero lavorare insieme. Tuttavia, se per voi il controllo di revisione distribuito è una novità, conoscere alcuni strumenti ed esempi può aiutarvi a ragionare sui possibili modelli di workflow da adottare. + Essendo uno strumento completamente decentralizzato, Mercurial non impone alcuna politica su come le persone dovrebbero lavorare insieme. Tuttavia, se per voi il controllo di revisione distribuito è una novità, conoscere alcuni strumenti ed esempi può aiutarvi a ragionare sui possibili modelli di workflow (letteralmente, flusso di lavoro) da adottare. L'interfaccia web di Mercurial @@ -11,7 +11,7 @@ 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 cominciano. 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 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 vengono compiute. 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 condividendo 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. @@ -23,7 +23,7 @@ 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. + 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, interfaccia di gateway comune) e WSGI (acronimo di Web Server Gateway Interface, interfaccia di gateway per server web). Leggete la per i dettagli sulle configurazioni di CGI e WSGI. @@ -46,7 +46,7 @@ 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 occasionali in cui un certo numero di persone si ritrova insieme in un'unico luogo (la stanza delle riunioni di un'azienda, la sala delle conferenze in un hotel, posti di questo tipo) e passa diversi giorni più o meno chiuso lì, a lavorare intensamente su una manciata di progetti. + Per esempio, molti progetti hanno un gruppo sparpagliato di collaboratori che si incontrano fisicamente solo di rado. Alcuni gruppi preferiscono superare l'isolamento del lavoro a distanza organizzando maratone occasionali in cui un certo numero di persone si ritrova insieme in un'unico luogo (la stanza delle riunioni di un'azienda, la sala delle conferenze in un hotel, posti di questo tipo) e passa diversi giorni più o meno chiuso lì, a lavorare intensamente su una manciata di progetti. Una maratona o una sessione di programmazione in un locale sono le occasioni perfette per usare il comando hg serve, dato che hg serve non richiede alcuna infrastruttura server elaborata. Potete cominciare a usare hg serve in pochi minuti, leggendo la più avanti. Poi vi basta comunicare ai vostri vicini l'esistenza di un server in esecuzione, fargli sapere l'URL a cui devono collegarsi, e avrete un modo rapido da predisporre per lavorare insieme. Gli altri potranno digitare il vostro URL nel proprio browser e revisionare velocemente i vostri cambiamenti, o estrarre la correzione di un bug dal vostro repository e verificarla, o clonare un ramo contenente una nuova funzione e provarla. @@ -60,7 +60,7 @@ 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 creato 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 di collaudare la correzione. Questo ci permette di rimandare la pubblicazione di cambiamenti potenzialmente pericolosi fino a quando non hanno subìto una ragionevole verifica. + In questo modello, può ancora avere senso che alcune persone propaghino i cambiamenti direttamente tra loro, senza passare dal repository centrale. Considerate il caso in cui io ho creato una correzione sperimentale di un bug, ma sono preoccupato che, se la pubblicassi sul repository centrale, tutti gli altri possano successivamente danneggiare i propri alberi nel momento in cui la estraggono. Per ridurre il danno potenziale, posso chiedervi di clonare temporaneamente il mio repository in un vostro repository privato e di collaudare la correzione. Questo ci permette di rimandare la pubblicazione di cambiamenti potenzialmente pericolosi fino a quando non hanno subìto una ragionevole verifica. Se un gruppo sta mantenendo il repository sui propri server in questo tipo di scenario, di solito i membri useranno il protocollo ssh per trasmettere in sicurezza i cambiamenti al repository centrale, come documentato nella . 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. @@ -72,7 +72,7 @@ Per esempio, un servizio di hosting ben ingegnerizzato consentirà agli sviluppatori di clonare le proprie copie di un repository con un singolo clic, in modo da farli lavorare in spazi separati e lasciarli condividere i propri cambiamenti quando sono pronti. - In più, un buon servizio di hosting permetterà alle persone di comunicare tra loro, per esempio per segnalare che questo albero contiene modifiche pronte per la tua revisione. + In più, un buon servizio di hosting permetterà ai propri utentei di comunicare tra loro, per esempio per segnalare che questo albero contiene modifiche pronte per la tua revisione. @@ -104,7 +104,7 @@ &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 indietro a quello stesso repository. + 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; @@ -120,7 +120,7 @@ Rami di funzione - 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. + Per progetti di dimensioni più grandi, un modo efficace per gestire i cambiamenti è quello di dividere un gruppo in piccoli sottogruppi. Ogni sottogruppo gestisce un proprio ramo condiviso, clonato da un singolo ramo principale usato dall'intero progetto. Le persone che lavorano su un singolo ramo sono tipicamente piuttosto isolate dagli sviluppi che avvengono negli altri rami.
Rami di funzione @@ -166,9 +166,9 @@ 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. + Tipicamente, i sostenitori del modello a scrittura condivisa usano strumenti che impongono attivamente questo approccio. Se state usando uno strumento centralizzato di controllo di revisione come Subversion, non c'è alcun modo di scegliere il modello che userete: lo strumento vi fornisce un modello a scrittura condivisa e se volete fare qualcos'altro dovete strutturare il vostro metodo al di sopra di quel modello (per esempio, applicando una patch a mano). + + Un buon sistema distribuito di controllo di revisione supporterà entrambi i modelli. Voi e i vostri collaboratori potrete quindi organizzare il modo di lavorare insieme sulla base dei vostri bisogni e delle vostre preferenze, non delle acrobazie a cui vi costringono gli strumenti. Dove la collaborazione incontra la gestione dei rami @@ -306,7 +306,7 @@ 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. + Prima di provare a usare Mercurial per comunicare con un server ssh, è preferibile che vi assicuriate di poter usare i normali comandi ssh o putty per contattare il server. Se incontrate problemi usando direttamente questi comandi, Mercurial sicuramente non funzionerà e in più nasconderà il problema sottostante. Ogni volta che avete un problema relativo a ssh con Mercurial, per cominciare dovreste accertarvi nuovamente che i semplici comandi ssh lato client funzionino prima di preoccuparvi di eventuali problemi con Mercurial. La prima cosa di cui accertarsi sul lato server è che siate in grado di entrare nel sistema da un'altra macchina. Se non potete usare ssh o putty per entrare, il messaggio di errore che vi viene mostrato potrebbe darvi alcuni suggerimenti per capire che cosa non va. I problemi più comuni sono i seguenti. @@ -334,7 +334,7 @@ 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.) + Se gli script di accesso sul vostro server stampano messaggi informativi o altri tipi di testo anche quando eseguite comandi non interattivi come questo, dovreste correggerli prima di continuare, in modo che stampino solo se vengono eseguiti interattivamente. Altrimenti, questi messaggi come minimo confonderanno le stampe di Mercurial e nel caso peggiore potrebbero causare problemi durante l'esecuzione remota dei comandi Mercurial. Mercurial prova a individuare e ignorare questi messaggi durante le sessioni ssh non interattive, ma non è infallibile. (Se state modificando i vostri script di accesso sul vostro server, potete vedere se uno script di accesso viene eseguito in una shell interattiva controllando il codice restituito dal comando tty -s.) Dopo aver verificato che il buon vecchio ssh stia funzionando con il vostro server, il passo successivo è quello di assicurarsi che Mercurial sia in esecuzione sul server. Il comando seguente dovrebbe terminare con successo: @@ -351,7 +351,7 @@ 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 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 un'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 ospitati 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 un'immagine più chiara di quello che sta succedendo. Usare la compressione con ssh @@ -370,12 +370,12 @@ Compression yes HostName hg.example.com - Questo definisce l'alias hg per il nome della macchina. Quando usate l'alias sulla riga di comando ssh o in un URL ssh di Mercurial, ssh si connetterà a hg.example.com e userà la compressione. In questo modo, potete ottenere sia un nome più corto da digitare sia la compressione, che dal canto loro sono entrambe buone cose.. + Questo definisce l'alias hg per il nome della macchina. Quando usate l'alias sulla riga di comando ssh o in un URL ssh di Mercurial, ssh si connetterà a hg.example.com e userà la compressione. In questo modo, potete ottenere sia un nome più corto da digitare sia la compressione, che dal canto loro sono entrambe buone cose. - Servire i dati attraverso HTTP usando CGI + Condividere 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. @@ -404,7 +404,7 @@ 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 considerevole esperienza nel configurare Apache, dovreste considerare l'uso del server web lighttpd invece di Apache. Le configurazioni di Apache hanno la reputazione ben meritata di essere complicate e di confondere gli utenti. Mentre Apache è dotato di un numero maggiore di funzioni rispetto a lighttpd, buona parte di queste funzioni non è rilevante per servire repository Mercurial. E lighttpd è innegabilmente molto più facile da affrontare di Apache. + Se non avete un server web installato e non avete una considerevole esperienza nel configurare Apache, dovreste considerare l'uso del server web lighttpd invece di Apache. Le configurazioni di Apache hanno la reputazione ben meritata di essere complicate e di confondere gli utenti. Sebbene Apache sia dotato di un numero maggiore di funzioni rispetto a lighttpd, buona parte di queste funzioni non è rilevante per servire repository Mercurial. E lighttpd è innegabilmente molto più facile da affrontare di Apache. @@ -423,7 +423,7 @@ 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://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 sul sistema operativo Fedora 7, con un'installazione vergine di Apache e un account utente che ho creato espressamente per effettuare questo esercizio. + 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 sul sistema operativo Fedora 7, con un'installazione vergine di Apache e un account utente 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. @@ -478,16 +478,16 @@ Lo script hgwebdir.cgi si basa su un file di configurazione esterno. Per default, cerca un file chiamato hgweb.config nella stessa directory in cui si trova. Dovrete creare questo file e renderlo leggibile agli altri. Il formato di questo file è simile a quello di un file ini di Windows, riconoscibile dal modulo ConfigParser 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: + Il modo più facile di configurare hgwebdir.cgi è tramite una sezione chiamata collections che vi consentirà di pubblicare automaticamente tutti i repository contenuti nelle directory che nominate. La sezione dovrebbe somigliare a questa: [collections] /mia/radice = /mia/radice - Mercurial la interpreta guardando al nome della directory sul lato destro del segno =, 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. + Mercurial la interpreta guardando al nome della directory sul lato destro del segno =, individuando i repository nella gerarchia contenuta in quella directory e usando il testo sul lato sinistro per eliminare il testo corrispondente dai nomi che elencherà effettivamente nell'interfaccia web. I componenti del percorso che rimangono dopo questa eliminazione formano un percorso virtuale. Dato l'esempio precedente, se abbiamo un repository il cui percorso locale è /mia/radice/questo/repository, lo script CGI eliminerà la parte /mia/radice iniziale dal nome e pubblicherà il repository con il percorso virtuale questo/repository. Se l'URL per il nostro script CGI è http://nomemacchina/~nomeutente/hgwebdir.cgi, l'URL completo per quel repository sarà http://nomemacchina/~nomeutente/hgwebdir.cgi/questo/repository. Se sostituiamo /mia/radice sul lato sinstro di questo esempio con /mia, allora hgwebdir.cgi eliminerà solo /mia dal nome del repository e ci darà il percorso virtuale radice/questo/repository invece di questo/repository. - Lo script hgwebdir.cgi cercherà i repository ricorsivamente in ogni directory elencata nella sezione collections del suo file di configurazione, ma non navigherà ricorsivamente nei repository che trova. + 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.[NdT] A partire dalla versione 1.3, Mercurial supporta i repository innestati. 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. @@ -496,8 +496,8 @@ In aggiunta al meccanismo basato su collections, lo script hgwebdir.cgi vi consente di pubblicare una lista specifica di repository. Per fare questo, create una sezione paths con un contenuto simile al seguente. [paths] -repo1 = /mio/percorso/a/qualche/repository -repo2 = /qualche/percorso/a/un/altro +repo1 = /mio/percorso/vero/qualche/repository +repo2 = /qualche/percorso/verso/un/altro In questo caso, il percorso virtuale (il componente che apparirà in un URL) è sul lato sinistro di ogni definizione, mentre il percorso del repository è sulla destra. Notate che non c'è bisogno che esista alcuna relazione tra il percorso virtuale che scegliete e l'ubicazione di un repository sul vostro file system. Se lo desiderate, potete usare entrambe le sezioni collections e paths contemporaneamente in un unico file di configurazione. diff -r 96d161568609 -r 0a49072e8c7f it/ch07-filenames.xml --- a/it/ch07-filenames.xml Fri Aug 21 21:42:02 2009 +0200 +++ b/it/ch07-filenames.xml Fri Aug 21 21:42:22 2009 +0200 @@ -10,12 +10,12 @@ A livello di implementazione, Mercurial usa un unico meccanismo per gestire i nomi dei file. Tutti i comandi si comportano in maniera uniforme rispetto ai nomi dei file e lavorano nel modo seguente. Se indicate esplicitamente nomi di file esistenti sulla riga di comando, Mercurial lavora esattamente con quei file, come vi aspettereste. - - &interaction.filenames.files; + + &interaction.filenames.files; Quando fornite un nome di directory, Mercurial interpreterà questa azione come la volontà di operare su tutti i file in questa directory e nelle sue sottodirectory. Mercurial considera i file e le sottodirectory in una directory secondo l'ordine alfabetico. Quando incontra una sottodirectory, attraverserà quella sottodirectory prima di continuare con la directory corrente. - &interaction.filenames.dirs; + &interaction.filenames.dirs; @@ -42,7 +42,7 @@ L'esempio di hg add nella sezione precedente illustra qualcos'altro che è utile sapere sui comandi Mercurial. Se un comando opera su un file che non avete nominato esplicitamente sulla riga di comando, di solito stamperà il nome del file in modo che non veniate sorpresi da quello che sta succedendo. - In questo caso, Mercurial segue il principio della minima sorpresa. Se avete fornito il nome esatto di un file sulla riga di comando, non ha senso ripetervelo. Se Mercurial sta agendo implicitamente su un file, e.g. perché non avete fornito alcun nome, o su una directory, o su un pattern (si veda più avanti), ritiene sia più sicuro farvi sapere su quali file sta lavorando. + In questo caso, Mercurial segue il principio della minima sorpresa. Se avete fornito il nome esatto di un file sulla riga di comando, non ha senso ripetervelo. Se Mercurial sta agendo implicitamente su un file, per esempio perché non avete fornito alcun nome, o su una directory, o su un pattern (si veda più avanti), ritiene sia più sicuro farvi sapere su quali file sta lavorando. Potete ridurre al silenzio i comandi che si comportano in questo modo usando l'opzione . Potete anche dire loro di stampare il nome di tutti i file, anche quelli che avete nominato esplicitamente, usando l'opzione . @@ -52,11 +52,11 @@ Oltre a lavorare con i nomi di file e directory, Mercurial vi consente di usare i pattern per identificare i file. La gestione dei pattern da parte di Mercurial è espressiva. - Su sistemi di tipo Unix (Linux, Mac OS X, etc.), di solito è la shell ad occuparsi di trovare le corrispondenze tra i pattern e i nomi dei file. Su questi sistemi, dovete esplicitamente dire a Mercurial che un nome è un pattern. Su Windows, la shell non si occupa di espandere i pattern, quindi Mercurial identificherà automaticamente i nomi che sono pattern e li espanderà per voi. + Su sistemi di tipo Unix (Linux, Mac OS X, etc.), di solito è la shell che si occupa di trovare le corrispondenze tra i pattern e i nomi dei file. Su questi sistemi, dovete esplicitamente dire a Mercurial che un nome è un pattern. Su Windows, la shell non si occupa di espandere i pattern, quindi Mercurial identificherà automaticamente i nomi che sono pattern e li espanderà per voi. Per fornire un pattern al posto di un nome ordinario sulla riga di comando, il meccanismo è semplice: sintassi:corpodelpattern - Cioè, un pattern viene identificato da una breve stringa di testo che indica il tipo del pattern, seguita dai due punti, seguiti dall'effettivo pattern. + Quindi, un pattern viene identificato da una breve stringa di testo che indica il tipo del pattern, seguita dai due punti, seguiti dall'effettivo pattern. Mercurial supporta due tipi di sintassi per i pattern. Quello usato più spesso è chiamato glob: è lo stesso tipo di pattern usato dalla shell Unix e dovrebbe essere familiare anche agli utenti del prompt dei comandi di Windows. @@ -142,7 +142,7 @@ Per fare in modo che Mercurial ignori permanentemente quei file, create un file chiamato .hgignore alla radice del vostro repository. Dovreste registrare questo file tramite hg add in modo che Mercurial ne tenga traccia insieme al resto dei contenuti del vostro repository, dato che anche i vostri collaboratori potrebbero trovarlo utile. - Mercurial si aspetta che il file .hgignore contenga una lista di espressioni regolari, una per riga. Le linee vuote vengono saltate. La maggior parte delle persone preferisce descrivere i file che vuole ignorare utilizzando la sintassi glob che abbiamo descritto in precedenza, quindi un tipico file .hgignore comincerà con questa direttiva: + Mercurial si aspetta che il file .hgignore contenga una lista di espressioni regolari, una per riga. Le righe vuote vengono saltate. La maggior parte delle persone preferisce descrivere i file che vuole ignorare utilizzando la sintassi glob che abbiamo descritto in precedenza, quindi un tipico file .hgignore comincerà con questa direttiva: syntax: glob @@ -179,33 +179,33 @@ Completa insensibilità alle maiuscole. Le versioni maiuscole e minuscole di una lettera sono trattate come se fossero identiche, sia quando un file viene creato sia durante i successivi accessi. Questo è il funzionamento comune dei vecchi sistemi basati su DOS. - Conservazione delle maiuscole, ma insensibilità ad esse. Quando un file o una directory vengono creati, le maiuscole nel loro nome vengono memorizzate e possono essere recuperate e visualizzate dal sistema operativo. Quando un file esistente viene cercato, le maiuscole nel suo nome vengono ignorate. Questa è la situazione standard su Windows e MacOS. I nomi foo e FoO identificano lo stesso file. Questo trattamento intercambiabile delle lettere maiuscole e minuscole è anche chiamato ripiegamento delle maiuscole. + Conservazione delle maiuscole, ma insensibilità a esse. Quando un file o una directory vengono creati, le maiuscole nel loro nome vengono memorizzate e possono essere recuperate e visualizzate dal sistema operativo. Quando un file esistente viene cercato, le maiuscole nel suo nome vengono ignorate. Questa è la situazione standard su Windows e MacOS. I nomi foo e FoO identificano lo stesso file. Questo trattamento intercambiabile delle lettere maiuscole e minuscole è anche chiamato ripiegamento delle maiuscole (in inglese, case folding). Sensibilità alle maiuscole. Le lettere maiuscole di un nome sono significative in ogni momento. I nomi foo e FoO identificano due file differenti. Questo è il modo in cui i sistemi Linux e Unix lavorano normalmente. - Su sistemi di tipo Unix è possibile avere uno qualsiasi o tutti e tre i modi di gestire le maiuscole in azione allo stesso tempo. Per esempio, se usate Linux per operare su una chiave USB formattata con un file system FAT32, il sistema operativo gestirà i nomi su quel file system in modo da conservare le maiuscole senza essere sensibile ad esse. + Su sistemi di tipo Unix è possibile avere uno qualsiasi o tutti e tre i modi di gestire le maiuscole in azione allo stesso tempo. Per esempio, se usate Linux per operare su una chiave USB formattata con un file system FAT32, il sistema operativo gestirà i nomi su quel file system in modo da conservare le maiuscole senza essere sensibile a esse. Memorizzazione del repository sicura e portabile - Il meccanismo di memorizzazione dei repository Mercurial è sicuro per le maiuscole. Traduce i nomi dei file in modo che possano essere memorizzati senza problemi sia su file system sensibili alle maiuscole sia su quelli insensibili alle maiuscole. Questo significa che, per esempio, potete usare i normali strumenti per la copia di file per trasferire un repository Mercurial su una chiave USB, e spostare la chiavetta e il repository avanti e indietro tra un Mac, un PC con Windows e una macchina Linux senza problemi. + Il meccanismo di memorizzazione dei repository Mercurial è sicuro per le maiuscole. Traduce i nomi dei file in modo che possano essere memorizzati senza problemi sia su file system sensibili alle maiuscole sia su quelli insensibili alle maiuscole. Questo significa che, per esempio, potete usare i normali strumenti per la copia di file per trasferire un repository Mercurial su una chiave USB, e spostare la chiave e il repository avanti e indietro tra un Mac, un PC con Windows e una macchina Linux senza problemi. Riconoscere i conflitti tra maiuscole e minuscole - Quando opera sulla directory di lavoro, Mercurial segue la politica di denominazione del file system su cui la directory di lavoro si trova. Se il file system conserva le maiuscole ma è insensibile ad esse, Mercurial tratterà i nomi che differiscono solo per le maiuscole come se fossero uguali. + Quando opera sulla directory di lavoro, Mercurial segue la politica di denominazione del file system su cui la directory di lavoro si trova. Se il file system conserva le maiuscole ma è insensibile a esse, Mercurial tratterà i nomi che differiscono solo per le maiuscole come se fossero uguali. È importante ricordare che questo approccio permette di eseguire su un file system sensibile alle maiuscole (tipicamente Linux o Unix) il commit di un changeset che creerà problemi per gli utenti di file system insensibili alle maiuscole (di solito Windows e MacOS). Se un utente Linux inserisce nel repository le modifiche a due file, uno chiamato miofile.c e l'altro chiamato MioFile.c, questi file verranno memorizzati correttamente. E gli stessi file verranno correttamente rappresentati come due file separati nella directory di lavoro di altri utenti Linux. - Se un utente Windows o Mac estrae questo changeset, inizialmente non avrà alcun problema, perché il meccanismo di memorizzazione di un repository Mercurial è sicuro per le maiuscole. Tuttavia, appena tenta di aggiornare la directory di lavoro a quel changeset tramite hg update, o a unire il proprio lavoro con quel changeset tramite hg merge, Mercurial individuerà il conflitto tra i due nomi di file che il file system tratterebbe come lo stesso nome e impedirà all'aggiornamento o all'unione di avvenire. + Se un utente Windows o Mac estrae questo changeset, inizialmente non avrà alcun problema, perché il meccanismo di memorizzazione di un repository Mercurial è sicuro per le maiuscole. Tuttavia, appena tenta di aggiornare la directory di lavoro a quel changeset tramite hg update, o di unire il proprio lavoro con quel changeset tramite hg merge, Mercurial individuerà il conflitto tra i due nomi di file che il file system tratterebbe come lo stesso nome e impedirà all'aggiornamento o all'unione di avvenire. Correggere un conflitto tra maiuscole e minuscole - Se state usando Windows o Mac in un ambiente misto dove alcuni dei vostri collaboratori usano Linux o Unix, e Mercurial riporta un conflitto di ripiegamento delle maiuscole (indicandolo con il termine inglese case folding nel messaggio di errore) quando provate a eseguire hg update o hg merge, la procedura per correggere il problema è semplice. + Se state usando Windows o Mac in un ambiente misto dove alcuni dei vostri collaboratori usano Linux o Unix, e Mercurial riporta un conflitto di ripiegamento delle maiuscole quando provate a eseguire hg update o hg merge, la procedura per correggere il problema è semplice. Trovate la macchina Linux o Unix più vicina, clonatevi il repository problematico e usate il comando hg rename di Mercurial per cambiare i nomi di qualsiasi file o directory che crea complicazioni, in modo da non causare più alcun conflitto di ripiegamento delle maiuscole. Inserite queste modifiche nel repository, eseguite hg pull o hg push attraverso i vostri sistemi Windows o MacOS e usate hg update per aggiornare la directory di lavoro alla revisione che contiene i nomi senza conflitti. diff -r 96d161568609 -r 0a49072e8c7f it/examples/branching.tag.it --- a/it/examples/branching.tag.it Fri Aug 21 21:42:02 2009 +0200 +++ b/it/examples/branching.tag.it Fri Aug 21 21:42:22 2009 +0200 @@ -2,10 +2,10 @@ $ hg tag v1.0 $ hg tip changeset: 1:be452d95a1d0 -tag: tip -user: Bryan O'Sullivan <bos@serpentine.com> -date: Fri Jun 05 15:49:15 2009 +0000 -summary: Aggiunta l'etichetta v1.0 per il changeset c93791f54ca9 +etichetta: tip +utente: Bryan O'Sullivan <bos@serpentine.com> +data: Fri Jun 05 15:49:15 2009 +0000 +sommario: Aggiunta l'etichetta v1.0 per il changeset c93791f54ca9 $ hg tags tip 1:be452d95a1d0 diff -r 96d161568609 -r 0a49072e8c7f it/examples/ch04-diff.rename.basic.it --- a/it/examples/ch04-diff.rename.basic.it Fri Aug 21 21:42:02 2009 +0200 +++ b/it/examples/ch04-diff.rename.basic.it Fri Aug 21 21:42:22 2009 +0200 @@ -1,14 +1,14 @@ -$ hg rename a b +$ hg rename foo bar $ hg diff -diff -r b01d46ff402d a ---- a/a Fri Jun 05 15:49:22 2009 +0000 +diff -r b01d46ff402d foo +--- foo/foo Fri Jun 05 15:49:22 2009 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,1 +0,0 @@ -a -diff -r b01d46ff402d b +diff -r b01d46ff402d bar --- /dev/null Thu Jan 01 00:00:00 1970 +0000 -+++ b/b Fri Jun 05 15:49:23 2009 +0000 ++++ bar/bar Fri Jun 05 15:49:23 2009 +0000 @@ -0,0 +1,1 @@ +a diff -r 96d161568609 -r 0a49072e8c7f it/examples/ch04-diff.rename.git.it --- a/it/examples/ch04-diff.rename.git.it Fri Aug 21 21:42:02 2009 +0200 +++ b/it/examples/ch04-diff.rename.git.it Fri Aug 21 21:42:22 2009 +0200 @@ -1,7 +1,7 @@ $ hg diff -g -diff --git a/a b/b -cambiamento di nome da a -cambiamento di nome a b +diff --git foo/foo bar/bar +cambiamento di nome da foo +cambiamento di nome a bar diff -r 96d161568609 -r 0a49072e8c7f it/examples/ch04-resolve.heads.it --- a/it/examples/ch04-resolve.heads.it Fri Aug 21 21:42:02 2009 +0200 +++ b/it/examples/ch04-resolve.heads.it Fri Aug 21 21:42:22 2009 +0200 @@ -1,16 +1,16 @@ $ hg heads changeset: 2:6e8cd0b94b4c -tag: tip -parent: 0:05f41910a168 -user: Bryan O'Sullivan <bos@serpentine.com> -date: Fri Jun 05 15:49:28 2009 +0000 -summary: destra +etichetta: tip +genitore: 0:05f41910a168 +utente: Bryan O'Sullivan <bos@serpentine.com> +data: Fri Jun 05 15:49:28 2009 +0000 +sommario: destra changeset: 1:ab0fbd8c502d -user: Bryan O'Sullivan <bos@serpentine.com> -date: Fri Jun 05 15:49:27 2009 +0000 -summary: sinistra +utente: Bryan O'Sullivan <bos@serpentine.com> +data: Fri Jun 05 15:49:27 2009 +0000 +sommario: sinistra diff -r 96d161568609 -r 0a49072e8c7f it/examples/issue29.go.it --- a/it/examples/issue29.go.it Fri Aug 21 21:42:02 2009 +0200 +++ b/it/examples/issue29.go.it Fri Aug 21 21:42:22 2009 +0200 @@ -15,6 +15,6 @@ aggiungo b/b creata una nuova testa $ hg merge -fallimento: è una directory: /tmp/problema29jbjGH5/problema29/b +fallimento: è una directory: /tmp/problema29/b diff -r 96d161568609 -r 0a49072e8c7f it/examples/rename.divergent.rename.bob.it --- a/it/examples/rename.divergent.rename.bob.it Fri Aug 21 21:42:02 2009 +0200 +++ b/it/examples/rename.divergent.rename.bob.it Fri Aug 21 21:42:22 2009 +0200 @@ -1,6 +1,6 @@ $ cd ../bruno $ hg mv foo quux -$ hg ci -m 'Riominato foo a quux.' +$ hg ci -m 'Rinominato foo a quux.'