# HG changeset patch # User Giulio@puck # Date 1250366862 -7200 # Node ID 68e59fe2429e9ceb1e38cf477e61d0ce89c7dbea # Parent bbaa48ea086a036e89d04e1e5e904de2affbe4c9 Minor changes to Ch.1. diff -r bbaa48ea086a -r 68e59fe2429e it/ch01-intro.xml --- a/it/ch01-intro.xml Sat Aug 15 20:53:42 2009 +0200 +++ b/it/ch01-intro.xml Sat Aug 15 22:07:42 2009 +0200 @@ -5,9 +5,9 @@ Perché il controllo di revisione? Perché Mercurial? - Il controllo di revisione è il processo tramite il quale si gestiscono molteplici versioni di una qualsiasi unità di informazione. Nella sua forma più semplice, questo processo viene eseguito a mano da molte persone, ogni volta che modificano un file e lo salvano con un nuovo nome che contiene un numero più alto del numero della versione precedente. - - Tuttavia, gestire più versioni anche solo di un singolo file è un'operazione soggetta a errori, quindi strumenti software che automatizzassero questo processo sono stati disponibili per molto tempo. I primi strumenti automatizzati per il controllo di revisione erano deputati ad assistere un singolo utente nella gestione delle revisioni di un singolo file. Nel corso delle ultime decadi, il campo d'azione degli strumenti di controllo di revisione si è ampiamente esteso, e ora sono in grado di gestire un grande numero di file e di aiutare più persone a lavorare insieme. I migliori strumenti moderni di controllo di revisione non hanno alcun problema a fronteggiare gruppi di migliaia di persone che lavorano insieme su progetti composti da centinaia di migliaia di file. + Il controllo di revisione è il processo tramite il quale si gestiscono molteplici versioni di una qualsiasi unità di informazione. Molte persone eseguono a mano questo processo nella sua forma più semplice, ogni volta che modificano un file e lo salvano con un nuovo nome che contiene un numero più alto del numero della versione precedente. + + Tuttavia, gestire più versioni anche solo di un singolo file è un'operazione soggetta a errori, quindi strumenti software per automatizzare questo processo sono stati disponibili per molto tempo. I primi strumenti automatizzati per il controllo di revisione erano deputati ad assistere un singolo utente nella gestione delle revisioni di un singolo file. Nel corso delle ultime decadi, il campo d'azione degli strumenti di controllo di revisione si è ampiamente esteso, e ora sono in grado di gestire un grande numero di file e di aiutare più persone a lavorare insieme. I migliori strumenti moderni di controllo di revisione non hanno alcun problema a fronteggiare gruppi di migliaia di persone che lavorano insieme su progetti composti da centinaia di migliaia di file. La comparsa del controllo di revisione distribuito è relativamente recente, e finora questo nuovo campo è cresciuto grazie alla propensione umana per l'esplorazione di territori sconosciuti. @@ -20,7 +20,7 @@ Terrà traccia della storia e dell'evoluzione del vostro progetto, così voi non dovete farlo. Per ogni modifica, registrerà informazioni riguardanti chi l'ha fatta, perché l'ha fatta, quando è stata fatta e cosa è stato modificato. - Quando state lavorando con altre persone, il software per il controllo di revisione facilita la collaborazione. Per esempio, quando due persone effettuano cambiamenti incompatibili più o meno simultaneamente, il software vi aiuterà a identificare e risolvere questi conflitti. + Quando state lavorando con altre persone, il software di controllo di revisione facilita la collaborazione. Per esempio, quando due persone effettuano cambiamenti incompatibili più o meno simultaneamente, il software vi aiuterà a identificare e risolvere questi conflitti. Può aiutarvi a rettificare i vostri errori. Se fate una modifica che più tardi si rivela essere un errore, potete ritornare a una versione precedente di uno o più file. In effetti, uno strumento di controllo di revisione davvero buono vi aiuterà a calcolare efficientemente il momento esatto in cui un problema è stato introdotto (si veda la per i dettagli). Vi aiuterà a lavorare simultaneamente su molteplici versioni del vostro progetto e a gestire gli spostamenti tra una versione e l'altra. @@ -33,7 +33,7 @@ D'altra parte, il lavoretto veloce di una singola persona potrebbe sembrare il contesto meno adatto per impiegare uno strumento di controllo di revisione, perché sicuramente il costo di usarne uno deve essere vicino al costo complessivo del progetto. Giusto? - Mercurial supporta in maniera unica entrambe queste dimensioni di sviluppo. Potete impararne le basi in pochi minuti appena, e grazie al suo basso costo di gestione, potete applicare il controllo di revisione al più piccolo dei progetti con facilità. La sua semplicità vi permetterà di concentrarvi su qualsiasi cosa stiate davvero cercando di fare senza farvi distrarre da schiere di concetti astrusi o lunghe sequenze di comandi. Allo stesso tempo, le elevate prestazioni e la natura peer-to-peer di Mercurial vi permetteranno di scalare in maniera indolore per gestire grandi progetti. + Mercurial supporta in maniera unica entrambe queste dimensioni di sviluppo. Potete impararne le basi in pochi minuti appena, e grazie al suo basso costo di gestione potete applicare il controllo di revisione al più piccolo dei progetti con facilità. La sua semplicità vi permetterà di concentrarvi su qualunque cosa stiate davvero cercando di fare senza farvi distrarre da schiere di concetti astrusi o lunghe sequenze di comandi. Allo stesso tempo, le elevate prestazioni e la natura peer-to-peer di Mercurial vi permetteranno di scalare in maniera indolore per gestire grandi progetti. Nessuno strumento di controllo di revisione può salvare un progetto gestito male, ma la scelta degli strumenti adeguati può fare una notevole differenza nella fluidità con cui potete lavorare su un progetto. @@ -44,11 +44,11 @@ Il controllo di revisione è un campo talmente vario che vi si fa spesso riferimento attraverso diversi nomi e acronimi. Ecco alcune delle variazioni più comuni che incontrerete: - controllo di revisione (RCS) - gestione della configurazione del software (SCM), o gestione della configurazione - gestione del codice sorgente - controllo del codice sorgente, o controllo dei sorgenti - controllo di versione (VCS) + controllo di revisione (RCS); + gestione della configurazione del software (SCM), o gestione della configurazione; + gestione del codice sorgente; + controllo del codice sorgente, o controllo dei sorgenti; + controllo di versione (VCS). Alcune persone affermano che questi termini in realtà abbiano significati differenti, ma in pratica essi si sovrappongono così tanto che non c'è alcun modo concordato o persino utile di distinguerli. @@ -60,13 +60,13 @@ Questo libro tratta gli esempi di codice in maniera inusuale. Tutti gli esempi sono vivi&emdash;ognuno di essi è in effetti il risultato di uno script di shell che esegue i comandi Mercurial che vedete. Ogni volta che un'immagine del libro viene costruita dai suoi sorgenti, tutti gli script di esempio vengono automaticamente eseguiti e i loro risultati correnti vengono confrontati con i loro risultati attesi. - Il vantaggio di questo approccio è che gli esempi sono sempre accurati, in quanto descrivono esattamente il comportamento della versione di Mercurial menzionata sulla copertina del libro. Se aggiorno la versione di Mercurial che sto documentando, e il risultato di qualche comando cambia, il processo di costruzione del libro fallisce. + Il vantaggio di questo approccio è che gli esempi sono sempre accurati, in quanto descrivono esattamente il comportamento della versione di Mercurial menzionata sulla copertina del libro. Se aggiorno la versione di Mercurial che sto documentando e il risultato di qualche comando cambia, il processo di assemblaggio del libro fallisce. C'è un piccolo svantaggio in questo approccio, cioè che le date e gli orari che vedete negli esempi tendono a venire compressi insieme in modo anomalo, diversamente da quanto accadrebbe se gli stessi comandi fossero digitati da un essere umano. Laddove un essere umano non può inviare più di un comando ogni pochi secondi, le cui marcature temporali sarebbero analogamente intervallate, i miei script d'esempio automatizzati sono in grado di eseguire molti comandi in un secondo. - Come conseguenza di questo fatto, potrebbe sembrare che molti inserimenti (commit) consecutivi vengano eseguiti durante lo stesso secondo. Potete osservare la presenza di questa anomalia nell'esempio di bisect nella , tanto per farvi un'idea. - - Quindi, mentre leggete gli esempi, non date troppo peso alle date e agli orari che vedete nell'uscita dei comandi, ma potete decisamente fare affidamento sulla consistenza e riproducibilità del comportamento illustrato. + Come conseguenza di questo fatto, potrebbe sembrare che molti inserimenti (in inglese, commit) consecutivi vengano eseguiti durante lo stesso secondo. Potete osservare la presenza di questa anomalia nell'esempio di bisect nella , tanto per farvi un'idea. + + Quindi, mentre leggete gli esempi, non date troppo peso alle date e agli orari che vedete nei risultati dei comandi, ma potete decisamente fare affidamento sulla consistenza e riproducibilità del comportamento illustrato. @@ -75,11 +75,11 @@ Ci sono state alcune inconfondibili tendenze nello sviluppo e nell'utilizzo degli strumenti di controllo di revisione nel corso delle ultime quattro decadi, man mano che le persone acquisivano familiarità con le capacità dei loro strumenti e venivano vincolate dai loro limiti. - La prima generazione ha cominciato col gestire singoli file su singoli computer. Sebbene questi strumenti rappresentassero un enorme progresso rispetto al controllo di revisione manuale effettuato ad hoc, il loro modello di bloccaggio (locking) e la restrizione a un singolo computer limitarono il loro impiego a piccoli gruppi strettamente uniti. - - La seconda generazione ha rilassato questi vincoli spostandosi su architetture di rete e gestendo interi progetti alla volta. Con l'aumentare delle dimensioni dei progetti, gli strumenti incontrarono nuovi problemi. A causa della frequenza elevata con cui i client avevano bisogno di parlare con i server, la scalabilità dei server divenne un problema per progetti di grandi dimensioni. Una connessione di rete inaffidabile poteva impedire agli utenti remoti di essere in grado di parlare al server del tutto. Man mano che i progetti open source cominciarono a rendere l'accesso in sola lettura disponibile a chiunque in forma anonima, persone senza privilegi di commit scoprivano di non poter usare gli strumenti per interagire con un progetto in modo naturale, in quanto non erano in grado di registrare le modifiche da loro effettuate. - - La generazione attuale degli strumenti di controllo di revisione è di natura peer-to-peer. Tutti questi sistemi hanno abbandonato la dipendenza da un singolo server centrale e permettono alle persone di distribuire i propri dati del controllo di revisione laddove sono effettivamente necessari. La collaborazione attraverso Internet non è più vincolata dalla tecnologia, ma è diventata una questione di scelta e consenso. Gli strumenti moderni possono operare offline indefinitamente e autonomamente, utilizzando una connessione di rete solo quando è necessario sincronizzare i cambiamenti con un altro repository. + La prima generazione ha cominciato col gestire singoli file su singoli computer. Sebbene questi strumenti rappresentassero un enorme progresso rispetto al controllo di revisione manuale effettuato ad hoc, il loro modello di bloccaggio (in inglese, locking) e la restrizione a un singolo computer limitarono il loro impiego a piccoli gruppi strettamente uniti. + + La seconda generazione ha rilassato questi vincoli spostandosi su architetture di rete e gestendo interi progetti alla volta. Con l'aumentare delle dimensioni dei progetti, gli strumenti incontrarono nuovi problemi. A causa della frequenza elevata con cui i client avevano bisogno di parlare con i server, la scalabilità dei server divenne un problema per progetti di grandi dimensioni. Una connessione di rete inaffidabile poteva completamente impedire agli utenti remoti di essere in grado di parlare al server. Man mano che i progetti open source cominciarono a rendere l'accesso in sola lettura disponibile a chiunque in forma anonima, persone senza privilegi di inserimento scoprivano di non poter usare gli strumenti per interagire con un progetto in modo naturale, in quanto non erano in grado di registrare le modifiche da loro effettuate. + + La generazione attuale degli strumenti di controllo di revisione è di natura peer-to-peer. Tutti questi sistemi hanno abbandonato la dipendenza da un singolo server centrale e permettono alle persone di distribuire i propri dati di controllo di revisione laddove sono effettivamente necessari. La collaborazione attraverso Internet non è più vincolata dalla tecnologia, ma è diventata una questione di scelta e consenso. Gli strumenti moderni possono operare offline indefinitamente e autonomamente, utilizzando una connessione di rete solo quando è necessario sincronizzare i cambiamenti con un altro repository. @@ -91,7 +91,7 @@ Gli strumenti distribuiti sono indifferenti alle stravaganze dell'infrastruttura dei vostri server, sempre perché replicano i metadati in così tanti luoghi. Se usate un sistema centralizzato e il vostro server si guasta, fareste meglio a sperare che il vostro sistema di backup sia affidabile e che il vostro ultimo backup sia recente ed effettivamente funzionante. Con uno strumento distribuito, avete molti backup disponibili sui computer di ogni singolo collaboratore. - L'affidabilità della vostra rete influenzerà gli strumenti distribuiti in misura molto minore rispetto a quelli centralizzati. Non potete nemmeno usare uno strumento centralizzato senza una connessione di rete, a parte alcuni comandi estremamente vincolati. Con uno strumento distribuito, potreste persino non notare se la vostra connessione di rete cade mentre state lavorando. L'unica cosa che non sarete in grado di fare è comunicare con i repository su altri computer, qualcosa che è relativamente raro rispetto alle operazioni locali. Questo potrebbe essere significativo solo se avete un gruppo di collaboratori sparpagliati in lungo e in largo. + L'affidabilità della vostra rete influenzerà gli strumenti distribuiti in misura molto minore rispetto a quelli centralizzati. Non potete nemmeno usare uno strumento centralizzato senza una connessione di rete, a parte alcuni comandi estremamente limitati. Con uno strumento distribuito, potreste persino non notare se la vostra connessione di rete cade mentre state lavorando. L'unica cosa che non sarete in grado di fare è comunicare con i repository su altri computer, qualcosa che è relativamente raro rispetto alle operazioni locali. Questo potrebbe essere significativo solo se avete un gruppo di collaboratori sparpagliati in lungo e in largo. Vantaggi per i progetti open source @@ -101,15 +101,15 @@ Il falso problema dei fork - È stato suggerito che gli strumenti per il controllo di revisione distribuito espongano i progetti open source a un certo tipo di rischio in quanto rendono estremamente facile biforcare (fork) lo sviluppo di un progetto. Un fork avviene quando le differenze di opinione o di atteggiamento tra sviluppatori di uno stesso gruppo li portano a decidere di non poter lavorare più a lungo insieme. Ogni parte prende una copia più o meno completa del codice sorgente del progetto e prosegue per la propria strada. + È stato suggerito che gli strumenti per il controllo di revisione distribuito espongano i progetti open source a un certo tipo di rischio in quanto rendono estremamente facile biforcare (in inglese, fork) lo sviluppo di un progetto. Un fork avviene quando le differenze di opinione o di atteggiamento tra sviluppatori di uno stesso gruppo li portano a decidere di non poter lavorare più a lungo insieme. Ogni parte prende una copia più o meno completa del codice sorgente del progetto e prosegue per la propria strada. Talvolta le parti di un fork decidono di riconciliare le loro differenze. Con uno strumento centralizzato di controllo di revisione, il processo tecnico di riconciliazione è doloroso e deve essere in gran parte effettuato a mano. Dovete decidere quale cronologia delle revisioni dovrà prevalere e introdurvi in qualche modo i cambiamenti dell'altro gruppo. Di solito, questo risulta nella perdita parziale o completa della cronologia delle revisioni di una delle due parti. - Gli strumenti distribuiti rendono la biforcazione l'unico modo per sviluppare un progetto. Ogni singolo cambiamento apportato è un potenziale punto di biforcazione. La grande forza di questo approccio è che uno strumento per il controllo di revisione distribuito deve essere davvero bravo a unire (merge) due fork, perché i fork sono assolutamente fondamentali: vengono effettuati in ogni momento. + Gli strumenti distribuiti rendono la biforcazione l'unico modo per sviluppare un progetto. Ogni singolo cambiamento apportato è un potenziale punto di biforcazione. La grande forza di questo approccio è che uno strumento per il controllo di revisione distribuito deve essere davvero bravo a unire (in inglese, merge) due fork, perché i fork sono assolutamente fondamentali: vengono effettuati in ogni momento. Se tutte le attività che ogni sviluppatore svolge in ogni momento vengono concepite in termini di biforcazioni e unioni, allora ciò che il mondo open source chiama fork diventa un problema puramente sociale. Gli strumenti distribuiti in realtà non fanno altro che ridurre la probabilità di un vero e proprio fork: - eliminano la distinzione sociale imposta dagli strumenti centralizzati, cioè quella tra le persone all'interno del gruppo con i permessi di commit e le persone all'esterno del gruppo che non hanno questi permessi. + eliminano la distinzione sociale imposta dagli strumenti centralizzati, cioè quella tra le persone all'interno del gruppo con i permessi di inserimento e le persone che si trovano all'esterno del gruppo e non hanno questi permessi; rendono più facile riconciliarsi dopo un fork sociale, perché l'unica operazione che viene coinvolta dal punto di vista del software di controllo di revisione è semplicemente un'altra unione. @@ -120,9 +120,9 @@ Vantaggi per i progetti commerciali - Molti progetti commerciali vengono intrapresi da gruppi i cui membri sono sparpagliati attraverso il globo. I collaboratori lontani da un server centrale soffriranno un maggiore lentezza nell'esecuzione dei comandi e forse una minore affidabilità. I sistemi commerciali di controllo di revisione tentano di mitigare questi problemi tramite componenti aggiuntivi per la replicazione di siti remoti che sono tipicamente costosi da acquistare e intrattabili da amministrare. Un sistema distribuito non soffre di questi problemi in prima istanza. Ancora meglio, potete facilmente configurare molteplici server autoritativi, diciamo uno per ogni sito, in modo che non ci siano comunicazioni ridondanti tra i repository durante i costosi collegamenti di rete a grande distanza. - - I sistemi centralizzati per il controllo di revisione tendono ad avere una scalabilità relativamente bassa. Non è inusuale che un costoso sistema centralizzato cada sotto il carico combinato di una sola dozzina di utenti concorrenti. Ancora una volta, la tipica contromisura tende a essere un dispositivo di replicazione costoso e macchinoso. Dato che con uno strumento distribuito il carico su un server centrale&emdash;sempre che ne abbiate uno&emdash;è molto più basso (perché tutti i dati sono replicati ovunque), un singolo server economico può gestire i bisogni di un gruppo di lavoro molto più grande, e la replicazione per il bilancio del carico diventa una semplice questione di programmazione. + Molti progetti commerciali vengono intrapresi da gruppi i cui membri sono sparpagliati attraverso il globo. I collaboratori lontani da un server centrale soffriranno un maggiore lentezza nell'esecuzione dei comandi e forse una minore affidabilità. I sistemi commerciali di controllo di revisione tentano di mitigare questi problemi tramite componenti aggiuntivi per la replicazione di siti remoti che sono tipicamente costosi da acquistare e complicati da amministrare. Un sistema distribuito non soffre di questi problemi in prima istanza. Ancora meglio, potete facilmente configurare molteplici server autoritativi, diciamo uno per ogni sito, in modo che non ci siano comunicazioni ridondanti tra i repository durante i costosi collegamenti di rete a grande distanza. + + I sistemi centralizzati di controllo di revisione tendono ad avere una scalabilità relativamente bassa. Non è inusuale che un costoso sistema centralizzato cada sotto il carico combinato di una sola dozzina di utenti concorrenti. Ancora una volta, la tipica contromisura tende a essere un dispositivo di replicazione costoso e macchinoso. Dato che con uno strumento distribuito il carico su un server centrale&emdash;sempre che ne abbiate uno&emdash;è molto più basso (perché tutti i dati sono replicati ovunque), un singolo server economico può gestire i bisogni di un gruppo di lavoro molto più grande, e la replicazione per il bilancio del carico diventa una semplice questione di programmazione. I vostri impiegati potranno beneficiare del controllo di versione distribuito anche quando si trovano nella sede di un cliente per risolvere un problema in loco. Gli strumenti permetteranno loro di generare versioni personalizzate del software nel repository, provare soluzioni differenti isolandole l'una dall'altra e cercare in maniera efficiente attraverso la cronologia delle revisioni le sorgenti di bug e regressioni nell'ambiente del cliente, il tutto senza aver bisogno di collegarsi alla rete della vostra azienda. @@ -145,7 +145,7 @@ L'utilità di Mercurial non si limita ai piccoli progetti: è usato da progetti contenenti decine di migliaia di file e centinaia di megabyte di codice sorgente su cui collaborano centinaia di migliaia di sviluppatori. - Se le funzionalità principali di Mercurial non sono sufficienti per voi, è facile aggiungerne di nuove. Mercurial si adatta molto bene alla programmazione delle proprie operazioni, e il codice pulito della sua implementazione in Python facilita l'aggiunta di funzionalità sotto forma di estensioni. Esistono già un certo numero di estensioni utili e popolari, che spaziano dal supporto alla identificazione dei bug fino al miglioramento delle prestazioni. + Se le funzioni principali di Mercurial non sono sufficienti per voi, è facile aggiungerne di nuove. Mercurial è particolarmente adatto alla programmazione delle proprie operazioni, e il codice pulito della sua implementazione in Python facilita l'aggiunta di funzioni sotto forma di estensioni. Esistono già un certo numero di estensioni utili e popolari, che spaziano dal supporto alla identificazione dei bug fino al miglioramento delle prestazioni. @@ -160,10 +160,10 @@ Subversion e Mercurial hanno comandi con nomi simili per effettuare le stesse operazioni, così se avete familiarità con uno dei due è facile imparare a usare l'altro. Entrambi gli strumenti sono portabili su tutti i sistemi operativi più popolari. - Prima della versione 1.5, Subversion non aveva alcun supporto efficace per le unioni. Al momento della scrittura, la sua funzionalità per la gestione delle unioni è nuova e nota per essere Prima della versione 1.5, Subversion non aveva alcun supporto efficace per le unioni. Al momento della scrittura, la sua funzione per la gestione delle unioni è nuova e nota per essere complicata e difettosa. - Mercurial ha un sostanzioso vantaggio in termini di prestazioni rispetto a Subversion per tutte le operazioni di controllo di revisione di cui ho effettuato il benchmark. Il suo vantaggio si misura in un intervallo che va da un fattore di due a un fattore di sei quando lo si confronta con il modulo ra_local di Subversion 1.4.3, che lavora con repository locali ed è quindi il metodo di accesso più veloce disponibile. In situazioni più realistiche che coinvolgono un accesso al repository attraverso la rete, Subversion sconterà uno svantaggio sostanzialmente più consistente. Dato che molti comandi di Subversion devono comunicare con il server e Subversion non è dotato di meccanismi di replicazione efficaci, la capacità del server e la banda di rete diventano colli di bottiglia già per progetti di dimensioni moderate. + Mercurial ha un sostanzioso vantaggio in termini di prestazioni rispetto a Subversion per tutte le operazioni di controllo di revisione di cui ho effettuato il benchmark. Il suo vantaggio si misura in un intervallo che va da un fattore due a un fattore sei quando lo si confronta con il modulo ra_local di Subversion 1.4.3, che lavora con repository locali ed è quindi il metodo di accesso più veloce disponibile. In situazioni più realistiche che coinvolgono un accesso al repository attraverso la rete, Subversion sconterà uno svantaggio sostanzialmente più consistente. Dato che molti comandi di Subversion devono comunicare con il server e Subversion non è dotato di meccanismi di replicazione efficaci, la capacità del server e la banda di rete diventano colli di bottiglia già per progetti di dimensioni moderate. In più, Subversion si espone a un sostanziale utilizzo aggiuntivo di spazio su disco per evitare transazioni di rete durante l'esecuzione di alcune operazioni comuni, come trovare i file modificati (status) e visualizzare le modifiche rispetto alla revisione corrente (diff). Come risultato, la copia di lavoro di un repository Subversion è spesso delle stesse dimensioni, se non più grande, di un intero repository Mercurial più la sua directory di lavoro, anche nel caso in cui il repository Mercurial contenga la cronologia completa del progetto. @@ -171,7 +171,7 @@ Dato che Subversion non memorizza la cronologia di revisione sul client, è molto adatto a gestire progetti che hanno a che fare con numerosi file binari di grandi dimensioni. Se aggiungete cinquanta revisioni di un file incomprimibile di 10MB a un repository, l'utilizzo di spazio sul lato client da parte di Subversion rimarrà costante. Lo spazio usato da qualunque SCM distribuito crescerà rapidamente in proporzione al numero delle revisioni, perché le differenze tra una revisione e l'altra sono grandi. - In più, è spesso difficile, o più tipicamente impossibile, unire differenti versioni di un file binario. L'abilità di Subversion di permettere a un utente di bloccare un file, in modo da ottenere temporaneamente i diritti esclusivi per modificarlo, può essere un vantaggio significativo in progetti dove file binari vengono largamente utilizzati. + In più, è spesso difficile, o più tipicamente impossibile, unire differenti versioni di un file binario. L'abilità di Subversion di permettere a un utente di bloccare un file, in modo da ottenere temporaneamente i diritti esclusivi per modificarlo, può essere un vantaggio significativo in progetti dove i file binari vengono largamente utilizzati. Mercurial può importare la cronologia delle revisioni da un repository Subversion. Può anche esportare la propria cronologia delle revisioni verso un repository Subversion. Questa caratteristica vi permette di sentire l'acqua utilizzando Mercurial e Subverison in parallelo prima di decidere di cambiare. La conversione della cronologia è incrementale, così potete effettuare una conversione iniziale, poi piccole conversioni aggiuntive per introdurre successivamente nuovi cambiamenti. @@ -185,9 +185,9 @@ In termini di prestazioni, Git è estremamente veloce. In molti casi, è più veloce di Mercurial, almeno sotto Linux, mentre Mercurial è più prestante per altre operazioni. Tuttavia, sotto Windows, le prestazioni e il livello generale di supporto offerto da Git sono, al momento della scrittura, molto più indietro rispetto a Mercurial. - Mentre un repository Mercurial non ha bisogno di alcuna manutenzione, un repository Git richiede frequenti reimpacchettamenti manuali dei propri metadati. Senza questi, le prestazioni degradano e l'utilizzo di spazio cresce rapidamente. Le prestazioni di un server che contiene molti repository Git che non vengono rigorosamente e frequentemente reimpacchettati diventeranno pesantemente legate all'utilizzo del disco durante i backup, risultando in istanze di backup giornalieri che hanno impiegato molto più di 24 ore per terminare. Un repository Git appena impacchettato è leggermente più piccolo di un repository Mercurial, ma un repository non impacchettato ha dimensioni maggiori di diversi ordini di grandezza. - - Il cuore di Git è scritto in C. Molti comandi di Git sono implementati come script di shell o in linguaggio Perl la cui qualità è grandemente variabile. Ho incontrato diversi casi in cui gli script proseguivano ciecamente la propria esecuzione in presenza di errori che avrebbero dovuto essere fatali. + Mentre un repository Mercurial non ha bisogno di alcuna manutenzione, un repository Git richiede frequenti reimpacchettamenti manuali dei propri metadati. Senza questi, le prestazioni degradano e l'utilizzo di spazio cresce rapidamente. Le prestazioni di un server che contiene molti repository Git che non vengono rigorosamente e frequentemente reimpacchettati diventeranno pesantemente legate all'utilizzo del disco durante i backup, risultando in istanze di backup giornalieri che impiegano molto più di 24 ore per terminare. Un repository Git appena impacchettato è leggermente più piccolo di un repository Mercurial, ma un repository non impacchettato ha dimensioni maggiori di diversi ordini di grandezza. + + Il cuore di Git è scritto in C. Molti comandi di Git sono implementati come script di shell o in linguaggio Perl la cui qualità è notevolmente variabile. Ho incontrato diversi casi in cui gli script proseguivano ciecamente la propria esecuzione in presenza di errori che avrebbero dovuto essere fatali. Mercurial può importare la cronologia di revisione da un repository Git. @@ -198,11 +198,11 @@ CVS è probabilmente lo strumento di controllo di revisione più usato nel mondo. A causa della sua età e della sporcizia interna, è stato mantenuto solo superficialmente per diversi anni. - Ha un'architettura client/server centralizzata. Non raggruppa cambiamenti di file correlati in commit atomici, esponendo gli utenti al rischio di guastare il software: una persona può effettuare con successo il commit di parte di un cambiamento e poi essere bloccata dalla necessità di un'unione, vincolando altre persone a vedere solo una porzione del lavoro che intendeva fare. Questo influisce anche sul modo di lavorare con la cronologia del progetto. Se volete vedere tutte le modifiche che qualcuno ha effettuato come parte di un'attività, dovrete ispezionare manualmente le descrizioni e le marcature temporali dei cambiamenti fatti a ogni file coinvolto (sempre che sappiate quali fossero quei file). - - CVS ha una nozione confusa di etichette e rami di lavoro che non cercherò nemmeno di descrivere. Non gestisce per bene il cambiamento dei nomi di file o directory, esponendo il repository al rischio di danneggiamenti. Non ha quasi alcuna funzionalità per il controllo della consistenza interna, quindi tipicamente non è nemmeno possibile dire se un repository è danneggiato. Non raccomanderei CVS per alcun progetto, nuovo o esistente. - - Mercurial può importare la cronologia di revisione da CVS. Tuttavia, ci sono alcune avvertenze da considerare; queste sono valide anche per qualsiasi altro strumento di controllo di revisione che importi dati da CVS. A causa della mancanza di cambiamenti atomici in CVS e della mancanza di versioni per la gerarchia dei file, non è possibile ricostruire la cronologia di CVS in maniera completa e accurata; devono essere fatte alcune supposizioni, e le modifiche ai nomi dei file di solito non verranno mostrate. Dato che buona parte dell'amministrazione avanzata di CVS deve essere fatta a mano e quindi è soggetta a errori, i programmi che importano dati da CVS incorrono comunemente in molteplici problemi dovuti a repository danneggiati (marcature temporali completamente fasulle per le revisioni e file che sono rimasti bloccati per più di un decennio sono solo due dei problemi meno interessanti che posso ricordare dalla mia esperienza personale). + Ha un'architettura client/server centralizzata. Non raggruppa cambiamenti di file correlati in inserimenti atomici, esponendo gli utenti al rischio di guastare il software: una persona può inserire con successo parte di un cambiamento e poi essere bloccata dalla necessità di un'unione, vincolando altre persone a vedere solo una porzione del lavoro che intendeva fare. Questo influisce anche sul modo di lavorare con la cronologia del progetto. Se volete vedere tutte le modifiche che qualcuno ha effettuato come parte di un'attività, dovrete ispezionare manualmente le descrizioni e le marcature temporali dei cambiamenti fatti a ogni file coinvolto (sempre che sappiate quali fossero quei file). + + CVS ha una nozione confusa di etichette e rami di lavoro che non cercherò nemmeno di descrivere. Non gestisce per bene il cambiamento dei nomi di file o directory, esponendo il repository al rischio di danneggiamenti. Non ha quasi alcuna funzionalità per il controllo della consistenza interna, quindi tipicamente non è nemmeno possibile dire se un repository è danneggiato. Non raccomanderei CVS per nessun progetto, nuovo o esistente. + + Mercurial può importare la cronologia di revisione da CVS. Tuttavia, ci sono alcune avvertenze da considerare, valide anche per qualsiasi altro strumento di controllo di revisione che importi dati da CVS. A causa della mancanza di inserimenti atomici in CVS e della mancanza di versioni per la gerarchia dei file, non è possibile ricostruire la cronologia di CVS in maniera completa e accurata, bensì devono essere fatte alcune supposizioni, e le modifiche ai nomi dei file di solito non verranno mostrate. Dato che buona parte dell'amministrazione avanzata di CVS deve essere fatta a mano e quindi è soggetta a errori, i programmi che importano dati da CVS incorrono comunemente in molteplici problemi dovuti a repository danneggiati (marcature temporali completamente fasulle per le revisioni e file che sono rimasti bloccati per più di un decennio sono solo due dei problemi meno interessanti che posso ricordare dalla mia esperienza personale). Mercurial può importare la cronologia di revisione da un repository CVS. @@ -222,14 +222,14 @@ Per fare un esempio, Subversion è una buona scelta per chi lavora con file binari frequentemente modificati, a causa della sua natura centralizzata e del supporto per il bloccaggio dei file. - Personalmente trovo che le caratteristiche di Mercurial, come la semplicità, le prestazioni, e un buon supporto per le unioni, siano una combinazione irresistibile che mi ha servito bene per diversi anni. + Personalmente trovo che le caratteristiche di Mercurial, come la semplicità, le prestazioni e un buon supporto per le unioni, siano una combinazione irresistibile che mi ha servito bene per diversi anni. Passare da un altro strumento a Mercurial - Mercurial viene distribuito con una estensione chiamata convert, che può importare incrementalmente la cronologia delle revisioni da diversi altri strumenti per il controllo di revisione. Con incrementale voglio dire che potete convertire tutta la cronologia di un progetto in un'unica seduta, poi rieseguire la conversione più tardi per ottenere i nuovi cambiamenti che sono avvenuti dopo la conversione iniziale. + Mercurial viene distribuito con un'estensione chiamata convert, che può importare incrementalmente la cronologia delle revisioni da diversi altri strumenti di controllo di revisione. Con incrementale voglio dire che potete convertire tutta la cronologia di un progetto in un'unica seduta, poi rieseguire la conversione più tardi per ottenere i nuovi cambiamenti che sono avvenuti dopo la conversione iniziale. Gli strumenti di controllo di revisione supportati da convert sono i seguenti: @@ -246,21 +246,21 @@ Una breve storia del controllo di revisione - Il più noto tra i vecchi strumenti per il controllo di revisione è SCCS (acronimo di Source Code Control System, sistema per il controllo del codice sorgente), che Marc Rochkind scrisse mentre lavorava ai laboratori Bell nei primi anni '70. SCCS operava su singoli file, e obbligava ogni persona che lavorasse su un progetto ad avere accesso a uno spazio di lavoro condiviso su un singolo sistema. Solo una persona alla volta poteva modificare un file; l'arbitraggio per l'accesso ai file era realizzato attraverso i blocchi (lock). Capitava spesso che le persone bloccassero i file e si dimenticassero di sbloccarli più tardi, impedendo a chiunque altro di modificare quei file senza l'aiuto di un amministratore. - - Walter Tichy sviluppò un'alternativa free a SCCS nei primi anni '80, chiamando il suo programma RCS (acronimo di Revision Control System, sistema per il controllo di revisione). Come SCCS, RCS obbligava gli sviluppatori a lavorare in un singolo spazio di lavoro condiviso e a bloccare i file per prevenire cambiamenti simultanei da parte di più persone. - - Più tardi nel corso degli anni '80, Dick Grune usò RCS come componente di base per un insieme di script di shell che chiamò inizialmente cmt, ma che poi ribattezzò CVS (acronimo di Concurrent Versions System, sistema di versioni concorrenti). La grande innovazione di CVS fu che permetteva agli sviluppatori di lavorare simultaneamente e in qualche modo indipendentemente nel loro spazio di lavoro personale. Gli spazi di lavoro personali evitavano agli sviluppatori di pestarsi i piedi tutte le volte, come capitava comunemente con SCCS e RCS. Ogni sviluppatore aveva la copia di ogni file nel progetto e poteva modificare le proprie copie indipendentemente. Era necessario combinare le singole modifiche prima di introdurre i cambiamenti nel repository centrale. - - Brian Berliner prese gli script originali di Grune e li riscrisse in C, rilasciando nel 1989 il codice che fin da allora è stato sviluppato come la moderna versione di CVS. CVS successivamente acquisì l'abilità di operare attraverso una connessione di rete, caratteristica che gli conferì la propria architettura client/server. L'architettura di CVS è centralizzata; solo il server ha la copia della cronologia del progetto. Gli spazi di lavoro sui client contengono solamente una copia delle versioni recenti dei file del progetto e i metadati che servono per conoscere la locazione del server. CVS ha avuto un enorme successo e probabilmente è il sistema di controllo di revisione più diffuso al mondo. - - All'inizio degli anni '90, Sun Microsystems sviluppò un primo sistema per il controllo di revisione distribuito chiamato TeamWare. Uno spazio di lavoro in TeamWare contiene una copia completa della cronologia del progetto. TeamWare non possiede alcuna nozione di un repository centrale. (CVS si basava su RCS per la memorizzazione della cronologia; TeamWare usava SCCS.) + Il più noto tra i vecchi strumenti per il controllo di revisione è SCCS (acronimo di Source Code Control System, sistema per il controllo del codice sorgente), che Marc Rochkind scrisse mentre lavorava ai laboratori Bell nei primi anni '70. SCCS operava su singoli file e obbligava ogni persona che lavorasse su un progetto ad avere accesso a uno spazio di lavoro condiviso su un singolo sistema. Solo una persona alla volta poteva modificare un file e l'arbitraggio per l'accesso ai file era realizzato attraverso i blocchi (in inglese, lock). Capitava spesso che le persone bloccassero i file e si dimenticassero di sbloccarli più tardi, impedendo a chiunque altro di modificare quei file senza l'aiuto di un amministratore. + + Walter Tichy sviluppò un'alternativa libera a SCCS nei primi anni '80, chiamando il suo programma RCS (acronimo di Revision Control System, sistema per il controllo di revisione). Come SCCS, RCS obbligava gli sviluppatori a lavorare in un singolo spazio di lavoro condiviso e a bloccare i file per prevenire cambiamenti simultanei da parte di più persone. + + Più tardi nel corso degli anni '80, Dick Grune usò RCS come componente di base per un insieme di script di shell che chiamò inizialmente cmt, ma che poi ribattezzò CVS (acronimo di Concurrent Versions System, sistema di versioni concorrenti). La grande innovazione di CVS fu che permetteva agli sviluppatori di lavorare simultaneamente e in qualche modo indipendentemente nel loro spazio di lavoro personale. Gli spazi di lavoro personali evitavano agli sviluppatori di pestarsi i piedi tutte le volte, come capitava comunemente con SCCS e RCS. Ogni sviluppatore aveva la copia di ogni file contenuto nel progetto e poteva modificare le proprie copie indipendentemente. Era necessario combinare le singole modifiche prima di introdurre i cambiamenti nel repository centrale. + + Brian Berliner prese gli script originali di Grune e li riscrisse in C, rilasciando nel 1989 il codice che fin da allora è stato sviluppato come la moderna versione di CVS. CVS successivamente acquisì l'abilità di operare attraverso una connessione di rete, caratteristica che gli conferì la propria architettura client/server. L'architettura di CVS è centralizzata: solo il server ha la copia della cronologia del progetto, mentre gli spazi di lavoro sui client contengono solamente una copia delle versioni recenti dei file del progetto e i metadati che servono per conoscere l'ubicazione del server. CVS ha avuto un enorme successo e probabilmente è il sistema di controllo di revisione più diffuso al mondo. + + All'inizio degli anni '90, Sun Microsystems sviluppò un primo sistema per il controllo di revisione distribuito chiamato TeamWare. Uno spazio di lavoro in TeamWare contiene una copia completa della cronologia del progetto. TeamWare non possiede alcuna nozione di un repository centrale. (CVS si basava su RCS per la memorizzazione della cronologia, TeamWare usava SCCS.) Durante gli anni '90 crebbe la consapevolezza dei numerosi problemi di CVS. CVS registra individualmente cambiamenti simultanei a più di un file, invece di raggrupparli insieme come una singola operazione logicamente atomica; non gestisce bene la sua gerarchia di file, ed è facile danneggiare un repository cambiando i nomi di file e directory. Le difficoltà di lettura e manutenzione del suo codice sorgente resero proibitiva la soglia del dolore da oltrepassare per correggere questi problemi architetturali. - Nel 2001, Jim Blandy e Karl Fogel, due sviluppatori che avevano lavorato su CVS, diedero vita a un progetto per sostituirlo con uno strumento che avrebbe avuto una migliore architettura e un codice più pulito. Il risultato, Subversion, non si allontana dal modello client/server centralizzato di CVS, ma aggiunge commit atomici per più file alla volta, una miglior gestione degli spazi di nomi e un certo numero di altre caratteristiche che lo rendono uno strumento generalmente migliore di CVS. Dal suo rilascio iniziale, la sua popolarità è rapidamente cresciuta. - - Più o meno simultaneamente, Graydon Hoare cominciò a lavorare su un ambizioso sistema di controllo di revisione distribuito che chiamò Monotone. Monotone non si limita a risolvere molti dei problemi di progettazione di CVS e a possedere un'architettura peer-to-peer, ma va oltre ai primi (e ai successivi) strumenti di controllo di revisione in un certo numero di modi innovativi, usando hash crittografici come identificatori e adottando una nozione integrale di fiducia (trust) per autenticare il codice che proviene da sorgenti differenti. + Nel 2001, Jim Blandy e Karl Fogel, due sviluppatori che avevano lavorato su CVS, diedero vita a un progetto per sostituirlo con uno strumento che avrebbe avuto un'architettura migliore e un codice più pulito. Il risultato, Subversion, non si allontana dal modello client/server centralizzato di CVS, ma aggiunge inserimenti atomici per più file alla volta, una miglior gestione degli spazi di nomi e un certo numero di altre caratteristiche che lo rendono uno strumento generalmente migliore di CVS. Dal suo rilascio iniziale, la sua popolarità è rapidamente cresciuta. + + Più o meno simultaneamente, Graydon Hoare cominciò a lavorare su un ambizioso sistema distribuito di controllo di revisione che chiamò Monotone. Monotone non si limita a risolvere molti dei problemi di progettazione di CVS e a possedere un'architettura peer-to-peer, ma va oltre ai primi (e ai successivi) strumenti di controllo di revisione in un certo numero di modi innovativi, usando hash crittografici come identificatori e adottando una nozione integrale di fiducia (in inglese, trust) per autenticare il codice che proviene da sorgenti differenti. Mercurial nacque nel 2005. Mentre alcuni aspetti della sua progettazione sono stati influenzati da Monotone, Mercurial si concentra su facilità d'uso, prestazioni elevate e scalabilità verso progetti molto grandi.