# HG changeset patch
# User Giulio@puck
# Date 1246805556 -7200
# Node ID 242567e04489fab67595f59ec043b9e142d18a9a
# Parent 0edc45e721d545f88f264d044245d6dab2641bd8
Big revision of Ch.4.
diff -r 0edc45e721d5 -r 242567e04489 it/ch04-concepts.xml
--- a/it/ch04-concepts.xml Wed Jul 01 17:25:39 2009 +0200
+++ b/it/ch04-concepts.xml Sun Jul 05 16:52:36 2009 +0200
@@ -2,21 +2,21 @@
Dietro le quinte
- Diversamente da molti sistemi di controllo di revisione, i concetti su cui Mercurial è costruito sono abbastanza semplici che è facile capire come il software funziona realmente. Conoscere questi dettagli non è certamente necessario, quindi è certamente sicuro saltare questo capitolo. Tuttavia, penso che otterrete di più dal software con un modello mentale di quello che sta succedendo.
-
- Essere in grado di capire quello che accade dietro le quinte mi dà la confidenza che Mercurial sia stato attentamente progettato per essere sia sicuro che efficiente. E allo stesso modo è importante, se è facile per me tenere a mente una buona idea di quello che il software sta facendo mentre effettuo un'attività di controllo di revisione, è meno probabile che venga sorpreso dal suo comportamento.
-
- In questo capitolo, tratteremo inizialmente i concetti chiave dietro alla progettazione di Mercurial, poi continueremo discutendo alcuni dei dettagli più interessanti della sua implementazione.
+ Diversamente da molti sistemi di controllo di revisione, Mercurial è costruito sulla base di concetti abbastanza semplici da facilitare la comprensione del modo in cui il software funziona realmente. Conoscere questi dettagli non è certamente necessario, per cui potete tranquillamente saltare questo capitolo. Tuttavia, penso che otterrete di più dal software conoscendo il modello concettuale del suo funzionamento.
+
+ Essere in grado di capire quello che accade dietro le quinte mi dà una certa garanzia che Mercurial sia stato attentamente progettato per essere sia sicuro che efficiente. Analogamente, è importante che per me sia facile avere un'idea corretta di quello che il software sta facendo mentre svolgo un'attività di controllo di revisione, in modo da abbassare la probabilità di venire sorpreso dal suo comportamento.
+
+ Inizieremo questo capitolo parlando dei concetti chiave alla base della progettazione di Mercurial, poi proseguiremo discutendo alcuni dei dettagli più interessanti della sua implementazione.La registrazione della cronologia di Mercurial
- Tenere traccia della cronologia di un singolo file
-
- Quando Mercurial tiene traccia delle modifiche a un file, memorizza la cronologia di quel file in un oggetto di metadati chiamato filelog (letteralmente, registro del file). Ogni voce in un filelog contiene informazioni sufficienti a ricostruire una revisione del file di cui viene tenuta traccia. I filelog sono memorizzati come file nella directory .hg/store/data. Un filelog contiene due tipi di informazione: dati di revisione e un indice per aiutare Mercurial a trovare una revisione in maniera efficiente.
-
- Il filelog di un file che sia di grandi dimensioni o abbia una lunga cronologia viene memorizzato in due file separati per i dati (con un suffisso .d) e l'indice (con un suffisso .i). Per file di piccole dimensioni senza molta cronologia, i dati di revisione e l'indice vengono combinati in un singolo file .i. La corrispondenza tra un file nella directory di lavoro e il filelog che tiene traccia della sua cronologia nel repository è illustrata nella Memorizzare la cronologia di un singolo file
+
+ Quando Mercurial tiene traccia delle modifiche a un file, memorizza la cronologia di quel file in un oggetto di metadati chiamato filelog (letteralmente, registro del file). Ogni voce in un filelog contiene informazioni sufficienti a ricostruire una revisione del file di cui tiene traccia. I filelog sono memorizzati come file nella directory .hg/store/data. Un filelog contiene due tipi di informazione: dati di revisione, più un indice per aiutare Mercurial a trovare una revisione in maniera efficiente.
+
+ Il filelog di un file di grandi dimensioni o che abbia una lunga cronologia viene memorizzato in due file separati per i dati (con un suffisso .d) e l'indice (con un suffisso .i). Per file di piccole dimensioni con una cronologia ridotta, i dati di revisione e l'indice vengono combinati in un singolo file .i. La corrispondenza tra un file nella directory di lavoro e il filelog che tiene traccia della sua cronologia nel repository è illustrata nella .
- Gestire i file tracciati
-
- Mercurial usa una struttura chiamata manifest per collezionare informazioni sui file di cui tiene traccia. Ogni voce nel manifest contiene informaizoni sui file presenti in un singolo changeset. Una voce registra quali file sono presenti nel changeset, la revisione di ogni file e alcuni altri frammenti di metadati sui file.
+ Gestire i file archiviati
+
+ 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.Registrare le informazioni di changeset
- Il changelog (letteralmente, registro dei cambiamenti) contiene informazioni su tutti i changeset. Ogni revisione registra chi ha inserito un cambiamento, il commento del changeset, altri frammenti di informazione relativi al changeset e la revisione del manifest da usare.
+ Il changelog (letteralmente, registro dei cambiamenti) contiene informazioni su tutti i changeset. Ogni revisione memorizza chi ha inserito un cambiamento, il commento del changeset, altre informazioni relative al changeset e la revisione del manifest da usare.Relazioni tra le revisioni
- Nell'ambito di un changelog, di un manifest, o di un filelog, ogni revisione memorizza 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, ed esse hanno 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 memorizza un puntatore a una singola revisione di ogni filelog tracciato quando il changeset è stato creato. Queste relazioni sono illustrate nella .
+ 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 .
- Come mostrato in figura, non c'è una relazione uno a uno tra le revisioni nel changelog, nel manifest, o nel filelog. Se un file tracciato da Mercurial non è cambiato tra due changeset, la voce per quel file nelle due revisioni del manifest punterà alla stessa revisione nel suo filelog
- È possibile (sebbene inusuale) che il manifest rimanga lo stesso tra due changeset, nel qual caso le voci del changelog per quei changeset punteranno alla stessa revisione del manifest.
+ Come mostrato in figura, non c'è una relazione uno a uno tra le revisioni nel changelog, nel manifest, o nel filelog. Se un file registrato da Mercurial non è cambiato tra due changeset, la voce per quel file nelle due revisioni del manifest punterà alla stessa revisione nel suo filelog
+ È possibile (anche se inusuale) che il manifest rimanga lo stesso tra due changeset, nel qual caso le voci del changelog per quei changeset punteranno alla stessa revisione del manifest..
@@ -64,30 +64,30 @@
Memorizzazione sicura ed efficiente
- I puntelli dei changelog, dei manifest e dei filelog sono forniti da una singola struttura chiamata revlog (letteralmente, registro di revisione).
+ Il supporto su cui si basano i changelog, i manifest e i filelog viene fornito da una singola struttura chiamata revlog (letteralmente, registro di revisione).Memorizzazione efficiente
- Il revlog fornisce una memorizzazione efficiente delle revisioni usando un meccanismo di delta. Invece di memorizzare una copia completa di un file per ogni revisione, memorizza i cambiamenti necessari a trasformare una revisione più vecchia nella nuova revisione. Per molti tipi di dati di file, queste delta sono tipicamente una frazione percentuale della dimensione di un'intera copia di un file.
-
- Alcuni sistemi di controllo di revisione obsoleti possono lavorare solo con le delta di file di testo. Essi devono memorizzare file binari come fotografie complete o codificarli in una rappresentazione testuale, entrambi approcci dispendiosi. Mercurial può maneggiare in maniera efficiente le delta di file con contenuti binari arbitrari; non ha bisogno di trattare il testo in maniera speciale.
+ Il revlog permette di memorizzare le revisioni in maniera efficiente usando un meccanismo basato su differenze chiamate delta. Invece di registrare una copia completa di un file per ogni revisione, il revlog memorizza i cambiamenti necessari a trasformare una revisione più vecchia nella nuova revisione. Per molti tipi di file, queste delta sono tipicamente una frazione percentuale della dimensione di un'intera copia di un file.
+
+ Alcuni sistemi di controllo di revisione obsoleti possono lavorare solo con le delta di file di testo e sono costretti a memorizzare i file binari come copie complete o a codificarli in una rappresentazione testuale, entrambi approcci dispendiosi. Mercurial è in grado di gestire in maniera efficiente le delta di file con contenuti binari arbitrari, per cui non ha bisogno di trattare il testo in maniera speciale.Operazioni sicure
- Mercurial si limita ad aggiungere dati alla fine di un file di revlog. Non modifica mai una sezione di un file dopo che lo ha scritto. Questo è sia più robusto che più efficiente rispetto a schemi che hanno bisogno di modificare o riscrivere i dati.
-
- 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'intera operazione viene annullata. Questa garanzia di atomicità significa che se state eseguendo due copie di Mercurial, dove una sta leggendo dati e l'altra sta scrivendo, il lettore non vedrà mai un risultato parzialmente scritto che potrebbe confonderlo.
-
- Il fatto che Mercurial aggiunga solo ai file rende più facile fornire questa garanzia transazionale. Più è facile fare cose come queste, più dovreste essere fiduciosi che vengano fatte correttamente.
+ Mercurial si limita ad aggiungere dati alla fine di un file di revlog invece di modificarne una sezione dopo averlo memorizzato. Questo approccio è più robusto ed efficiente rispetto a sistemi che hanno bisogno di modificare o riscrivere i dati.
+
+ 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.Reperimento veloce
- Mercurial evita astutamente un tranello 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 contro una fotografia. (Alcuni basano la fotografia sulla revisione più vecchia, altri su quella più nuova.) Per ricostruire una revisione specifica, dovete prima leggere la fotografia, e poi ognuna delle revisioni tra la fotografia e la vostra revisione obiettivo. Più un file accumula cronologia, 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ù 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.
- L'innovazione che Mercurial applica a questo problema è semplice ma efficace. Una volta che la quantità totale di informazioni di delta memorizzata dall'ultima immagine supera una soglia fissata, Mercurial memorizza una nuova immagine (compressa, naturalmente) invece di un'altra delta. Questo rende possibile ricostruire velocemente qualsiasi revisione di un file. Questo approccio funziona così bene che in seguito è stato copiato da molti altri sistemi di controllo di revisione.
-
- La illustra l'idea. In una voce di un file indice per un revlog, Mercurial memorizza l'intervallo di voci dal file di dati che deve leggere per ricostruire una particolare revisione.
+ L'innovazione che Mercurial applica alla soluzione di questo problema è semplice ma efficace. Una volta che la quantità totale di informazioni di delta memorizzate dall'ultima fotografia supera una soglia fissata, Mercurial memorizza una nuova fotografia (compressa, naturalmente) invece di un'altra delta. Questo approccio consente di ricostruire velocemente qualsiasi revisione di un file e funziona così bene che in seguito è stato copiato da molti altri sistemi di controllo di revisione.
+
+ La illustra l'idea. In una voce contenuta nel file indice di un revlog, Mercurial memorizza l'intervallo di voci che deve leggere dal file di dati per ricostruire una particolare revisione.Digressione: l'influenza della compressione video
- Se avete familiarità con la compressione video o avete mai guardato un segnale televisivo attraverso un cavo digitale o un servizio satellitare, potreste sapere che la maggior parte degli schemi per la compressione video memorizzano ogni frame del video come una delta rispetto al frame precedente.
-
- Mercurial prende in prestito questa idea per fare in modo che sia possibile ricostruire una revisione da una fotografia e un piccolo numero di delta.
+ Se avete familiarità con la compressione video o avete mai osservato un segnale televisivo trasmesso attraverso un cavo digitale o un servizio satellitare, potreste sapere che la maggior parte degli schemi per la compressione video memorizzano ogni frame del video come una delta rispetto al frame precedente.
+
+ Mercurial prende in prestito questa idea per fare in modo che sia possibile ricostruire una revisione da una fotografia e da un ridotto numero di delta.Identificazione e integrità forte
- Insieme alle informazioni di delta o di fotografia, una voce di revlog contiene un hash crittografico dei dati che rappresenta. Questo rende difficile contraffarre i contenuti di una revisione e facile scoprire una accidentale corruzione.
-
- Gli hash forniscono più di un semplice controllo contro la corruzione; essi sono usati come identificatori per le revisioni. Gli hash di identificazione dei changeset che avete visto come utenti finali provengono dalle revisioni del changelog. Sebbene anche i filelog e il manifest facciano uso di hash, in questo caso Mercurial li impiega solo dietro le quinte.
-
- Mercurial verifica che gli hash siano corretti quando reperisce le revisioni dei file e quando estrae i cambiamenti da un altro repository. Se incontra un problema di integrità, lo segnalerà e bloccherà l'operazione che stava eseguendo.
-
- In aggiunta all'effetto che ha sull'efficienza del reperimento, l'uso di fotografie periodiche da parte di Mercurial rende i repository più robusti nei confronti della corruzione parziale dei dati. Se un revlog diventa parzialmente corrotto a causa di un errore hardware o di un bug di sistema, spesso rimane possibile ricostruire alcune o la maggior parte delle revisioni a partire dalle sezioni non corrotte del revlog che si trovano prima e dopo la sezione rovinata. Questo non sarebbe possibile con un modello di memorizzazione basato unicamente sulle delta.
+ Insieme alle informazioni di delta e di fotografia, una voce di revlog contiene un hash crittografico dei dati che rappresenta. Questo rende difficile contraffarre i contenuti di una revisione e facilita la scoperta di corruzioni accidentali dei dati.
+
+ Gli hash forniscono più di un semplice controllo contro la corruzione dei dati, infatti vengono usati come identificatori per le revisioni. Gli hash di identificazione dei changeset che avete visto come utenti finali provengono dalle revisioni del changelog. Sebbene anche i filelog e il manifest facciano uso di hash, in questo caso Mercurial li impiega solo dietro le quinte.
+
+ Mercurial verifica che gli hash siano corretti nel momento in cui reperisce le revisioni dei file o estrae i cambiamenti da un altro repository. Se incontra un problema di integrità, lo segnalerà e bloccherà l'operazione che stava eseguendo.
+
+ In aggiunta all'effetto che ha sull'efficienza del reperimento, l'uso di fotografie periodiche da parte di Mercurial rende i repository più robusti nei confronti della corruzione parziale dei dati. Se un revlog viene parzialmente rovinato da un errore hardware o da un bug di sistema, spesso rimane possibile ricostruire alcune o la maggior parte delle revisioni a partire dalle sezioni illese del revlog che si trovano prima e dopo la sezione rovinata. Questo non sarebbe possibile con un modello di memorizzazione basato unicamente sulle delta.
@@ -128,9 +128,9 @@
Ogni voce in un revlog di Mercurial conosce l'identità della propria revisione progenitrice diretta, di solito chiamata genitore. In effetti, una revisione contiene spazio non solo per un genitore, ma per due. Mercurial usa un hash speciale, chiamato identificatore nullo, per rappresentare l'idea non c'è alcun genitore qui. Questo hash è semplicemente una stringa di zero.
- Nella , potete vedere un esempio della struttura concettuale di un revlog. I filelog, i manifest e i changelog hanno tutti questa identica struttura; essi 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 i posti genitoriali. Per una revisione normale, il primo posto genitoriale contiene l'identificatore della revisione genitore e il secondo contiene l'identificatore nullo, indicando che la revisione possiede un solo vero genitore. Due revisioni qualsiasi che possiedano lo stesso identificatore di genitore sono rami. Una revisione che rappresenta un'unione tra rami ha due identificatori di revisione normali nei propri posti genitoriali.
+ 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.