# HG changeset patch # User Giulio@puck # Date 1249402535 -7200 # Node ID 5c9552a4e5529028d6ddb04f2b839becb5c9333b # Parent 8e65bbd54a4f3e6294ae7b0f7d1c6e2928e88e62 Deep revision of Ch.14. diff -r 8e65bbd54a4f -r 5c9552a4e552 it/ch14-hgext.xml --- a/it/ch14-hgext.xml Fri Jul 31 23:44:45 2009 +0200 +++ b/it/ch14-hgext.xml Tue Aug 04 18:15:35 2009 +0200 @@ -2,39 +2,39 @@ Aggiungere funzionalità con le estensioni - Mentre il nucleo di Mercurial è piuttosto completo dal punto di vista delle funzionalità, è deliberatamente spoglio di funzioni esotiche. Questo approccio di preservare la semplicità mantiene il software facile da maneggiare sia per chi lo mantiene sia per chi lo usa. - - Tuttavia, Mercurial non vi chiude in un insieme di comandi immutabile: potete aggiungere nuove funzioni a Mercurial sotto forma di estensioni (talvolta note come plugin). Abbiamo già discusso alcune di queste estensioni nei capitoli precedenti. + Se da una parte il nucleo di Mercurial è piuttosto completo dal punto di vista delle funzionalità, dall'altra è deliberatamente privo di caratteristiche ornamentali. Questo approccio orientato a preservare la semplicità mantiene il software facile da maneggiare sia per chi ne cura la manutenzione sia per chi lo usa. + + Tuttavia, Mercurial non vi ingabbia in un insieme di comandi immutabile: potete aggiungere nuove funzioni a Mercurial sotto forma di estensioni (talvolta note come plugin). Abbiamo già discusso alcune di queste estensioni nei capitoli precedenti. La parla dell'estensione fetch, che combina l'estrazione di nuovi cambiamenti e la loro unione con i cambiamenti locali in un singolo comando, fetch. - Nel , abbiamo parlato di diverse estensioni che sono utili per funzionalità relative agli hook: acl aggiunge le liste di controllo d'accesso; bugzilla aggiunge l'integrazione con il sistema Bugzilla per la gestione dei bug; e notify invia email di notifica in reazione all'inserimento di nuovi cambiamenti. - - L'estensione Mercurial Queues per la gestione delle patch è talmente inestimabile che merita due capitoli e un'appendice a essa dedicati: il copre le nozioni di base, il ne discute gli argomenti avanzati e il entra nei dettagli di ogni comando. + Nel , abbiamo parlato di diverse estensioni le cui funzioni sono utilizzabili sotto forma di hook: acl aggiunge le liste di controllo d'accesso, bugzilla aggiunge l'integrazione con il sistema Bugzilla per la gestione dei bug e notify invia email di notifica in reazione all'inserimento di nuovi cambiamenti. + + L'estensione Mercurial Queues per la gestione delle patch è talmente importante da meritare due capitoli e un'appendice interamente dedicati: il copre le nozioni di base, il ne discute gli argomenti avanzati e l' tratta ogni comando nei dettagli. - In questo capitolo, parleremo di alcune delle altre estensioni che sono disponibili per Mercurial, e toccheremo brevemente alcuni dei meccanismi che avrete bisogno di conoscere se volete scrivere le vostre estensioni. + In questo capitolo, parleremo di alcune delle altre estensioni disponibili per Mercurial e tratteremo brevemente alcuni dei meccanismi che avrete bisogno di conoscere se volete scrivere le vostre estensioni. - Nella , discuteremo la possibilità di enormi miglioramenti delle prestazioni tramite l'uso della estensione inotify. + Nella , discuteremo la possibilità di enormi miglioramenti delle prestazioni tramite l'uso dell'estensione inotify. Migliorare le prestazioni con l'estensione <literal role="hg-ext">inotify</literal> - Siete interessati ad avere alcune delle più comuni operazioni Mercurial che eseguono fino a cento volte più velocemente? Continuate a leggere! - - Mercurial ha prestazioni eccellenti in circostanze normali. Per esempio, quando invocate il comando hg status, Mercurial deve esaminare quasi ogni file e directory nel vostro repository in modo da mostrare lo stato dei file. Molti altri comandi Mercurial devono fare lo stesso lavoro dietro le quinte; per esempio, il comando hg diff usa il meccanismo dello stato per evitare di fare costose operazioni di confronto su file che ovviamente non sono stati modificati. - - Dato che ottenere lo stato di un file è un'operazione cruciale per avere buone prestazioni, gli autori di Mercurial hanno ottimizzato questo codice #to within an inch of its life#. Tuttavia, non è possibile evitare il fatto che quando invocate hg - status, Mercurial dovrà effettuare almeno una costosa chiamata di sistema per ogni file gestito per determinare se è stato modificato dall'ultima volta che Mercurial ha controllato. Per repository di dimensioni sufficientemente grandi, questa operazione può durare molto tempo. - - Per esprimere con un numero la vastità di questo effetto, ho creato un repository contenente 150.000 file registrati. Ho cronometrato hg status per scoprire che impiega dieci secondi a terminare, anche quando nessuno di quei file è stato modificato. - - Molti sistemi operativi moderni contengono utilità per la notifica sui file. Se un programma si registra al servizio appropriato, il sistema operativo lo avvertirà ogni volta che un file di interesse viene creato, modificato, o cancellato. Sui sistemi Linux, il componente del kernel che si occupa di questo si chiama inotify. - - L'estensione inotify di Mercurial interagisce con il componente inotify per ottimizzare le esecuzioni di hg status. Questa estensione ha due componenti. Un demone esegue in background e riceve le notifiche dal sottosistema inotify. In più, accetta connessioni anche dai normali comandi Mercurial. L'estensione modifica il comportamento di Mercurial in modo che, invece di esaminare il file system, interroghi il demone. Dato che il demone possiede informazioni esatte sullo stato del repository, può rispondere istantaneamente con un risultato, evitando il bisogno di esaminare ogni file e directory nel repository. + Siete interessati a ottenere esecuzioni fino a cento volte più veloci per alcune delle più comuni operazioni compiute da Mercurial? Continuate a leggere! + + Le prestazioni di Mercurial sono tipicamente eccellenti. Per esempio, quando invocate il comando hg status, Mercurial deve esaminare quasi ogni file e directory nel vostro repository in modo da mostrare lo stato dei file. Molti altri comandi Mercurial devono fare lo stesso lavoro dietro le quinte; per esempio, il comando hg diff usa il meccanismo dello stato per evitare costose operazioni di confronto su file che ovviamente non sono stati modificati. + + Dato che ottenere lo stato di un file è un'operazione cruciale per raggiungere buone prestazioni, gli autori di Mercurial hanno ottimizzato quasi completamente questo codice. Tuttavia, non è possibile evitare il fatto che, quando invocate hg + status, Mercurial dovrà effettuare almeno una costosa chiamata di sistema per ogni file registrato in modo da determinare se è stato modificato dall'ultima volta che Mercurial ha controllato. Per repository di dimensioni sufficientemente grandi, questa operazione può durare molto tempo. + + Per esprimere numericamente la vastità di questo effetto, ho creato un repository contenente 150.000 file registrati e ho cronometrato hg status per scoprire che impiega dieci secondi a terminare, anche quando nessuno di quei file è stato modificato. + + Molti sistemi operativi moderni contengono utilità di notifica per i file. Se un programma si registra al servizio appropriato, il sistema operativo lo avvertirà ogni volta che un file di interesse viene creato, modificato, o cancellato. Sui sistemi Linux, il componente del kernel che si occupa di questa funzione si chiama inotify. + + L'estensione inotify di Mercurial interagisce con il componente inotify per ottimizzare l'esecuzione di hg status. Questa estensione ha due componenti. Un demone esegue in background e riceve le notifiche dal sottosistema inotify, accettando connessioni anche dai normali comandi Mercurial. L'estensione modifica il comportamento di Mercurial in modo che, invece di esaminare il file system, interroghi il demone. Dato che il demone possiede informazioni esatte sullo stato del repository, può rispondere istantaneamente con un risultato, evitando il bisogno di esaminare tutti i file e le directory nel repository. Ricordate i dieci secondi che ho misurato come il tempo impiegato dal solo Mercurial per eseguire hg status su un repository di 150.000 file? Con l'estensione inotify abilitata, il tempo è sceso a 0.1 secondi, più veloce di un fattore cento. @@ -42,57 +42,58 @@ L'estensione inotify è specifica per Linux. Dato che si interfaccia direttamente con il sottosistema inotify del kernel di Linux, non funziona su altri sistemi operativi. - Dovrebbe funzionare su qualsiasi distribuzione Linux che è stata rilasciata dopo i primi mesi del 2005. È probabile che le distribuzioni più vecchie abbiano un kernel a cui manca inotify, o una versione di glibc senza il necessario supporto di interfacciamento. - - Non tutti i file system sono adatti per essere usati con l'estensione inotify. I file system di rete come NFS sono #non-starter#, per esempio, in particolare se state eseguendo Mercurial su diversi sistemi che montano lo stesso file system di rete. Il sistema inotify del kernel non ha alcun modo di sapere quali cambiamenti sono avvenuti su un altro sistema. + L'estensione dovrebbe funzionare su qualsiasi distribuzione Linux rilasciata dopo i primi mesi del 2005. È probabile che le distribuzioni più vecchie includano un kernel a cui manca inotify, o una versione di glibc senza il necessario supporto di interfacciamento. + + Non tutti i file system sono adatti per essere usati con l'estensione inotify. I file system di rete come NFS sono fuori gioco, per esempio, in particolare se state eseguendo Mercurial su diversi sistemi che montano lo stesso file system di rete. Il sistema inotify del kernel non ha alcun modo di sapere quali cambiamenti sono avvenuti su un altro sistema. La maggior parte dei file system locali (e.g. ext3, XFS, ReiserFS) dovrebbe andare bene. - A maggio 2007, l'estensione inotify non viene ancora distribuita con Mercurial, quindi è un po' più complicata da installare rispetto ad altre estensioni. Ma il miglioramento delle prestazioni ne vale la pena! - - Attualmente, l'estensione è divisa in due parti: un insieme di patch al codice sorgente di Mercurial e una libreria di #bindings# Python al sottosistema inotify. + A maggio 2007, l'estensione inotify non viene ancora distribuita con Mercurial, quindi è un po' più complicata da installare rispetto ad altre estensioni. Ma il miglioramento delle prestazioni ne vale la pena! + + Attualmente, l'estensione è divisa in due parti: un insieme di patch al codice sorgente di Mercurial e una libreria di interfaccia Python al sottosistema inotify. - Esistono due librerie di #bindings# Python per inotify. Una è chiamata pyinotify ed è impacchettata da alcune distribuzioni Linux sotto il nome python-inotify. Questa non è quella di cui avete bisogno, dato che è troppo inefficiente e piena di problemi per essere pratica. + Esistono due librerie di interfaccia Python per inotify. Una è chiamata pyinotify ed è inclusa in alcune distribuzioni Linux sotto il nome python-inotify. Questa non è quella di cui avete bisogno, dato che è troppo inefficiente e piena di problemi per essere pratica. Per cominciare, è meglio avere già installata una copia funzionante di Mercurial. - Se seguite le istruzioni qui sotto, finirete per sostituire e sovrascrivere qualsiasi installazione esistente di Mercurial possiate già avere, usando l'ultimo codice sperimentale di Mercurial. Non dite che non siete stati avvertiti! + Se seguite le istruzioni qui sotto, finirete per sostituire e sovrascrivere qualsiasi installazione esistente di Mercurial possiate già avere, usando l'ultima versione sperimentale di Mercurial. Non dite che non siete stati avvertiti! - Clonate il repository dei #bindings# Python per inotify. Assemblate il software e installatelo. + Clonate il repository della libreria di interfaccia Python per inotify. Assemblate il software e installatelo. hg clone http://hg.kublai.com/python/inotify cd inotify python setup.py build --force sudo python setup.py install --skip-build - Clonate il repository Mercurial crew. Clonate il repository di patch per inotify in modo che Mercurial Queues saranno in grado di applicare le patch alla vostra copia del repository crew. + Clonate il repository Mercurial crew. Clonate il repository di patch per inotify in modo che Mercurial Queues sia in grado di applicare le patch alla vostra copia del repository crew. hg clone http://hg.intevation.org/mercurial/crew hg clone crew inotify hg clone http://hg.kublai.com/mercurial/patches/inotify inotify/.hg/patches - Assicuratevi di avere abilitato l'estensione mq per Mercurial Queues. Se non avete mai usato MQ, leggete la per cominciare velocemente. - - Posizionatevi nel repository inotify e applicate tutte le patch per l'estensione inotify usando l'opzione per il comando qpush. + Assicuratevi di aver abilitato mq, l'estensione Mercurial Queues. Se non avete mai usato MQ, leggete la per una rapida introduzione. + + Posizionatevi nel repository inotify e applicate tutte le patch per l'estensione inotify usando l'opzione del comando qpush. cd inotify hg qpush -a - Se ottenete un messaggio di errore da qpush, non dovreste continuare. Invece, chiedete aiuto. - - Assemblate e installate la versione accomodata di Mercurial. + Se ottenete un messaggio di errore da qpush, dovreste fermarvi e chiedere aiuto. + + Assemblate e installate la versione modificata di Mercurial. python setup.py build --force sudo python setup.py install --skip-build - Una volta che avete assemblato una versione adeguatamente accomodata di Mercurial, tutto ciò che dovete fare per abilitare l'estensione inotify è aggiungere una voce al vostro file ~/.hgrc. - [extensions] inotify = - Quando l'estensione inotify è abilitata, Mercurial avvierà in maniera automatica e trasparente il demone la prima volta che invocherete un comando che ha bisogno dello stato dei file nel repository. Mercurial esegue un demone di stato per repository. - - Il demone di stato viene avviato silenziosamente ed esegue in background. Se guardate la lista dei processi in esecuzione dopo aver abilitato l'estensione inotify ed eseguite alcuni comandi in repository differenti, vedrete alcuni processi hg in attesa di aggiornamenti dal kernel e richieste da Mercurial. - - La prima volta che invocate un comando Mercurial in un repository dopo aver abilitato l'estensione inotify, il comando verrà eseguito con quasi le stesse prestazioni di un normale comando Mercurial. Questo accade perché il demone di stato deve effettuare scansione di stato in modo da avere un rilevamento di base su cui applicare gli aggiornamenti successivi provenienti dal kernel. Tuttavia, ogni comando successivo che effettua qualunque tipo di controllo sullo stato dovrebbe essere visibilmente più veloce persino su repository di dimensioni abbastanza modeste. Ancora meglio, più grande è il vostro repository, più grande sarà il vantaggio sulle performance che vedrete. Il demone inotify rende le operazioni di stato quasi istantanee su repository di tutte le dimensioni! - - Se preferite, potete avviare manualmente un demone di stato usando il comando inserve. Questo vi dà un controllo leggermente più accurato su come il demone dovrebbe eseguire. Naturalmente, questo comando sarà disponibile solo nel caso in cui l'estensione inotify sia abilitata. - - Quando state usando l'estensione inotify, non dovreste notare nessuna differenza nel comportamento di Mercurial, con la sola eccezione dei comandi relativi allo stato che eseguono molto più velocemente di quanto facevano di solito. Dovreste specificatamente aspettarvi che i comandi non stampino output differenti, né dovrebbero dare risultati differenti. Se una di queste situazioni si verifica, vi prego di segnalare il bug. + Una volta che avete assemblato una versione adeguatamente modificata di Mercurial, tutto ciò che dovete fare per abilitare l'estensione inotify è aggiungere una voce al vostro file ~/.hgrc. + [extensions] +inotify = + Quando l'estensione inotify è abilitata, Mercurial avvierà il demone in maniera automatica e trasparente la prima volta che invocherete un comando che ha bisogno di conoscere lo stato dei file nel repository. Mercurial esegue un demone di stato per repository. + + Il demone di stato viene avviato silenziosamente ed esegue in background. Se osservate la lista dei processi in esecuzione e invocate alcuni comandi in repository differenti dopo aver abilitato l'estensione inotify, vedrete alcuni processi hg in attesa di aggiornamenti dal kernel e di richieste da Mercurial. + + La prima volta che invocate un comando Mercurial in un repository dopo aver abilitato l'estensione inotify, il comando verrà eseguito con quasi le stesse prestazioni di un normale comando Mercurial. Questo accade perché il demone di stato deve effettuare una normale scansione di stato in modo da avere un rilevamento di base su cui applicare gli aggiornamenti successivi provenienti dal kernel. Tuttavia, ogni comando successivo che effettua qualunque tipo di controllo sullo stato dovrebbe essere visibilmente più veloce persino su repository di dimensioni abbastanza modeste. Ancora meglio, più grande è il vostro repository, più grande sarà il vantaggio che vedrete sulle prestazioni. Il demone inotify rende le operazioni di stato quasi istantanee su repository di tutte le dimensioni! + + Se preferite, potete avviare manualmente un demone di stato usando il comando inserve, che vi permette di controllare in maniera leggermente più accurata le modalità di esecuzione del demone. Naturalmente, questo comando sarà disponibile solo nel caso in cui l'estensione inotify sia abilitata. + + Quando state usando l'estensione inotify, non dovreste notare nessuna differenza nel comportamento di Mercurial, con la sola eccezione dei comandi relativi allo stato, che vengono eseguiti molto più velocemente di quanto accadeva di solito. Dovreste specificatamente aspettarvi che i comandi non stampino output differenti né restituiscano risultati differenti. Se una di queste situazioni si verifica, vi prego di segnalare il bug. @@ -102,46 +103,46 @@ &interaction.extdiff.diff; - Nel caso desideraste usare uno strumento esterno per visualizzare le modifiche, vorrete usare l'estensione extdiff, che vi permetterà di usare, per esempio, uno strumento di diff grafico. - - L'estensione extdiff è inclusa in Mercurial, quindi è facile da installare. Nella sezione extensions del vostro file ~/.hgrc, aggiungete semplicemente una voce di una riga per abilitare l'estensione. + Nel caso desideraste usare uno strumento esterno per visualizzare le modifiche, vorrete usare l'estensione extdiff, che vi permetterà di impiegare, per esempio, uno strumento di diff grafico. + + L'estensione extdiff è inclusa in Mercurial, quindi è facile da installare. Per abilitare l'estensione, vi basta aggiungere una voce di una riga nella sezione extensions del vostro file ~/.hgrc. [extensions] extdiff = - Questo introduce un comando chiamato extdiff, il cui comportamento predefinito è quello di usare il comando diff del vostro sistema per generare un diff in formato unified allo stesso modo del comando Questa estensione introduce un comando chiamato extdiff, il cui comportamento predefinito è quello di usare il comando diff del vostro sistema per generare un diff in formato unified allo stesso modo del comando hg diff predefinito. &interaction.extdiff.extdiff; - I risultati non saranno esattamente gli stessi delle variazioni del comando predefinito hg diff, perché i risultati del comando diff variano da un sistema all'altro, persino quando gli vengono passate le stesse opzioni. - - Come indica la riga making snapshot stampata qui sopra, il comando extdiff funziona creando due fotografie (in inglese, snapshot) del vostro albero sorgente. La prima fotografia è quella della revisione sorgente; la seconda è quella della revisione destinazione o della directory di lavoro. Il comando extdiff genera queste fotografie in una directory temporanea, passa il nome di ogni directory a un visualizzatore di diff esterno, poi cancella la directory temporanea. Per lavorare in modo più efficiente, fotografa solo le directory e i file che sono stati modificati tra le due revisioni. - - I nomi delle directory di fotografia hanno il nome base uguale a quello del vostro repository. Se il percorso del vostro repository è /quux/bar/foo, allora foo sarà il nome di ognuna delle directory di fotografia. Ogni nome di directory di fotografia ha il proprio identificatore di changeset in coda, nel caso sia appropriato. Se è la fotografia di una revisione a631aca1083f, la directory verrà chiamata foo.a631aca1083f. Una fotografia della directory di lavoro non avrà un identificatore di changeset in coda, quindi sarebbe semplicemente foo in questo esempio. Per vedere come questo appare in pratica, guardate ancora all'esempio di extdiff precedente. Notate che il diff contiene i nomi delle directory di fotografia nella propria intestazione. - - Il comando extdiff accetta due importanti opzioni. L'opzione vi permette di scegliere un programma diverso da diff con cui vedere le differenze. Con l'opzione , potete cambiare le opzioni che extdiff passa al programma (per default, queste opzioni sono -Npru, che hanno senso solo se state invocando diff). Sotto altri aspetti, il comando extdiff agisce in modo simile al comando predefinito hg diff: si usano gli stessi nomi di opzione, la stessa sintassi e gli stessi argomenti per specificare le revisioni che volete, i file che volete, e così via. - - Per esempio, ecco come eseguire il normale comando diff di sistema per fargli generare diff in formato context (usando l'opzione ) invece di diff in formato unified e per fargli mostrare cinque righe di contesto invece delle tre predefinite (passandogli 5 come argomento per l'opzione ). + I risultati non saranno esattamente gli stessi ottenibili con le diverse versioni del comando predefinito hg diff, perché i risultati del comando diff variano da un sistema all'altro, persino quando gli vengono passate le stesse opzioni. + + Il comando extdiff funziona creando due fotografie del vostro albero sorgente. La prima fotografia è quella della revisione sorgente, la seconda è quella della revisione destinazione o della directory di lavoro. Il comando extdiff genera queste fotografie in una directory temporanea, passa il nome di ogni directory di fotografia a un visualizzatore di diff esterno, poi cancella la directory temporanea. Per lavorare in modo più efficiente, il comando fotografa solo le directory e i file che sono stati modificati tra le due revisioni. + + Il nome delle directory di fotografia è uguale al nome base del vostro repository. Se il percorso del vostro repository è /quux/bar/foo, allora foo sarà il nome di ognuna delle directory di fotografia. Nel caso sia appropriato, ogni nome di directory di fotografia termina con il proprio identificatore di changeset. Se la fotografia è quella della revisione a631aca1083f, la directory verrà chiamata foo.a631aca1083f. Una fotografia della directory di lavoro non terminerà con un identificatore di changeset, quindi in questo esempio il suo nome sarebbe semplicemente foo. Per vedere come questo appare in pratica, osservate ancora l'esempio di extdiff precedente. Notate che il diff contiene i nomi delle directory di fotografia nella propria intestazione. + + Il comando extdiff accetta due importanti opzioni. L'opzione vi permette di scegliere un programma diverso da diff con cui visualizzare le differenze. Con l'opzione , potete cambiare le opzioni che extdiff passa al programma (le opzioni predefinite sono -Npru, che hanno senso solo se state invocando diff). Sotto altri aspetti, il comando extdiff agisce in modo simile al comando predefinito hg diff: si usano gli stessi nomi di opzione, la stessa sintassi e gli stessi argomenti per specificare le revisioni che volete, i file che volete, e così via. + + Per esempio, ecco come invocare il normale comando diff di sistema per fargli generare diff in formato context (usando l'opzione ) invece di diff in formato unified e per fargli mostrare cinque righe di contesto invece delle tre predefinite (passandogli 5 come argomento per l'opzione ). &interaction.extdiff.extdiff-ctx; - Lanciare uno strumento di diff visuale è altrettanto facile. Ecco come lanciare il visualizzatorekdiff3. + Lanciare uno strumento di diff visuale è altrettanto facile. Ecco come lanciare il visualizzatore kdiff3. hg extdiff -p kdiff3 -o - Se il comando che usate per visualizzare i diff non gestisce le directory, potete facilmente aggirare questo problema con un minimo di programmazione. Per un esempio di un programma simile in azione con l'estensione mq e il comando interdiff, consultate la . + Se il comando che usate per visualizzare i diff non gestisce le directory, potete facilmente aggirare questo problema con un minimo di programmazione. Consultate la per vedere un esempio di un programma simile in azione con l'estensione mq e il comando interdiff. Definire alias per i comandi - Potrebbe essere scomodo ricordare le opzioni sia per il comando extdiff che per il visualizzatore di diff che volete usare, quindi l'estensione extdiff vi permette di definire nuovi comandi che invocheranno il vostro visualizzatore di diff con esattamente le opzioni giuste. - - Tutto quello che avete bisogno di fare è modificare il vostro file ~/.hgrc aggiungendo una sezione chiamata extdiff dove potete definire molteplici comandi. Ecco come aggiungere un comando kdiff3. Una volta che lo avete definito, potete digitare hg kdiff3 e l'estensione extdiff eseguirà kdiff3 per voi. + Potrebbe essere scomodo ricordare le opzioni sia per il comando extdiff che per il visualizzatore di diff che volete usare, quindi l'estensione extdiff vi permette di definire nuovi comandi che invocheranno il vostro visualizzatore di diff con le opzioni giuste. + + Tutto quello che dovete fare è modificare il vostro file ~/.hgrc aggiungendo una sezione chiamata extdiff dove potete definire molteplici comandi. Ecco come aggiungere un comando kdiff3. Una volta che lo avete definito, potete digitare hg kdiff3 e l'estensione extdiff lancerà kdiff3 per voi. [extdiff] cmd.kdiff3 = Se lasciate vuota la parte destra della definizione, come qui sopra, l'estensione extdiff usa il nome del comando che avete definito come il nome del programma esterno da usare. Ma questi nomi non devono necessariamente essere uguali. Qui di seguito definiamo un comando chiamato hg wibble che invoca kdiff3. [extdiff] cmd.wibble = kdiff3 - Potete anche specificare le opzioni predefinite con cui volete invocare il vostro programma di visualizzazione di diff. Il prefisso da usare è opts., seguito dal nome del comando a cui applicare le opzioni. Questo esempio definisce un comando hg vimdiff che esegue l'estensione DirDiff dell'editorvim. + Potete anche specificare le opzioni predefinite con cui volete invocare il vostro programma di visualizzazione di diff. Il prefisso da usare è opts., seguito dal nome del comando a cui applicare le opzioni. Questo esempio definisce un comando hg vimdiff che esegue l'estensione DirDiff dell'editor vim. [extdiff] cmd.vimdiff = vim opts.vimdiff = -f '+next' '+execute "DirDiff" argv(0) argv(1)' @@ -160,24 +161,24 @@ Inviare cambiamenti via email con l'estensione <literal role="hg-ext">patchbomb</literal> - Molti progetti hanno una cultura di revisione dei cambiamenti nella quale le persone inviano le proprie modifiche a una mailing list in modo che altri possano leggerle e commentarle prima che la loro versione finale venga inserita in un repository condiviso. Alcuni progetti assegnano a qualcuno il ruolo del custode che applica le modifiche di altre persone a un repository a cui quelle altre persone non hanno accesso. - - Mercurial facilita l'invio tramite email di modifiche da rivedere o applicare grazie alla sua estensione patchbomb. L'estensione viene chiamata così perché le modifiche vengono inviate in forma di patch e solitamente viene inviato un singolo changeset per messaggio email. Quindi, inviare una lunga serie di cambiamenti via email è molto simile a bombardare la casella del ricevente, da cui il nome patchbomb. - - Come al solito, la configurazione di base dell'estensione patchbomb prende solo una o due righe del vostro file /.hgrc. + Molti progetti seguono una pratica di revisione dei cambiamenti in cui gli sviluppatori inviano le proprie modifiche a una mailing list in modo che altri possano leggerle e commentarle prima che la loro versione finale venga inserita in un repository condiviso. Alcuni progetti assegnano a qualcuno il ruolo del custode che applica le modifiche di altre persone a un repository a cui quelle persone non hanno accesso. + + Mercurial facilita l'invio di email contenenti modifiche da rivedere o applicare grazie alla sua estensione patchbomb. L'estensione viene chiamata così perché le modifiche vengono inviate in forma di patch e solitamente viene inviato un singolo changeset per ogni messaggio email. Quindi, inviare una lunga serie di cambiamenti via email è molto simile a bombardare la casella del ricevente, da cui il nome patchbomb. + + Come al solito, la configurazione di base dell'estensione patchbomb occupa solo una o due righe del vostro file /.hgrc. [extensions] patchbomb = Una volta che avete abilitato l'estensione, avrete a disposizione un nuovo comando chiamato email. - Il modo migliore e più sicuro di invocare il comando email è quello di eseguirlo sempre una prima volta con l'opzione . Questo vi mostrerà che cosa invierebbe il comando, senza in effetti inviare nulla. Una volta che avete dato una veloce occhiata ai cambiamenti e avete verificato di stare mandando quelli giusti, potete rieseguire lo stesso comando, questa volta senza l'opzione . + Il modo migliore e più sicuro di invocare il comando email è quello di eseguirlo sempre una prima volta con l'opzione . Questo vi mostrerà ciò che il comando invierebbe, senza in effetti inviare nulla. Una volta che avete dato una veloce occhiata ai cambiamenti e avete verificato di stare mandando quelli giusti, potete rieseguire lo stesso comando, questa volta senza l'opzione . Il comando email accetta lo stesso tipo di sintassi di revisione di tutti gli altri comandi Mercurial. Per esempio, questo comando invierà ogni revisione tra 7 e tip comprese. hg email -n 7:tip - Potete anche specificare un repository con cui effettuare i confronti. Se fornite un repository ma nessuna revisione, il comando email invierà tutte le revisioni del repository locale che non sono presenti nel repository remoto. Se in aggiunta specificate revisioni o un nome di ramo (quest'ultimo usando l'opzione ), questo vincolerà le revisioni inviate. - - È perfettamente sicuro invocare il comando email senza i nomi delle persone a cui volete spedire un messaggio: se fate in questo modo, vi verranno chiesti interattivamente. (Se state usando un sistema di tipo Unix o Linux, dovreste avere a disposizione le capacità avanzate di digitazione fornite da readline o simili quando immettete quelle intestazioni, cosa che vi si rivelerà utile.) - - Quando state inviando una sola revisione, il comando email userà la prima riga della descrizione del changeset come l'oggetto predefinito del singolo messaggio email che invia. + Potete anche specificare un repository con cui effettuare i confronti. Se fornite un repository senza indicare alcuna revisione, il comando email invierà tutte le revisioni del repository locale che non sono presenti nel repository remoto. Se in aggiunta specificate revisioni o il nome di un ramo (quest'ultimo usando l'opzione ), questo vincolerà le revisioni inviate. + + È assolutamente sicuro invocare il comando email senza i nomi delle persone a cui volete spedire un messaggio: se fate in questo modo, i destinatari vi verranno chiesti interattivamente. (Se state usando un sistema di tipo Unix o Linux, dovreste avere a disposizione le capacità avanzate di digitazione fornite da readline o librerie simili quando immettete quelle intestazioni, cosa che vi si rivelerà utile.) + + Quando state inviando una sola revisione, il comando email userà la prima riga della descrizione del changeset come l'oggetto predefinito del singolo messaggio email da spedire. Se inviate revisioni multiple, di solito il comando email spedirà un messaggio per ogni changeset. Farà precedere la serie da un messaggio introduttivo in cui dovreste descrivere lo scopo della serie di cambiamenti che state inviando. @@ -186,19 +187,19 @@ Non tutti i progetti hanno esattamente le stesse convenzioni per spedire cambiamenti via email, così l'estensione patchbomb prova a fornire un certo numero di variazioni attraverso le opzioni a riga di comando. - Potete scrivere un oggetto per il messaggio introduttivo sulla riga di comando usando l'opzione . Questa opzione prende un argomento, il testo da usare per l'oggetto. - - Per cambiare l'indirizzo email da cui vengono spediti i messaggi usate l'opzione . Questa opzione prende un argomento, l'indirizzo email da usare. - - Il comportamento predefinito è quello di inviare diff in formato unified (leggete la per una descrizione del formato), uno per messaggio. Potete invece inviare un bundle eseguibile con l'opzione . - - I diff in formato unified sono normalmente preceduti da un'intestazione di metadati. Potete ometterla e inviare diff disadorni con l'opzione . - - I diff vengono normalmente spediti in linea, nella stessa parte del corpo che contiene la descrizione della patch. Questo è il modo più facile per consentire al più ampio numero di lettori di citare e rispondere a parti di un diff, dato che alcuni client email citeranno soltanto la prima parte MIME del corpo di un messaggio. Se preferireste inviare la descrizione e il diff in parti separate del corpo, usate l'opzione . - - Invece di spedire messaggi email, potete scriverli in una cartella email in formato mbox usando l'opzione . Questa opzione prende un argomento, il nome del file su cui scrivere. - - Se preferite aggiungere un riepilogo nel formato del comando diffstat a ogni patch, e uno al messaggio introduttivo, usate l'opzione . Il comando diffstat mostra una tabella contenente il nome di ogni file coinvolto nella patch, il numero di righe modificate e un istogramma che mostra quanto ogni file è stato modificato. Questo dà a chi legge un colpo d'occhio qualitativo sulla complessità di una patch. + Potete scrivere un oggetto per il messaggio introduttivo sulla riga di comando usando l'opzione . Questa opzione accetta un argomento, il testo da usare per l'oggetto. + + Per cambiare l'indirizzo email da cui vengono spediti i messaggi usate l'opzione . Questa opzione accetta un argomento, l'indirizzo email da usare. + + Il comportamento predefinito è quello di inviare diff in formato unified (leggete la per una descrizione del formato), uno per ogni messaggio. Potete invece usare l'opzione per inviare un bundle eseguibile. + + I diff in formato unified sono normalmente preceduti da un'intestazione di metadati. Potete ometterla e inviare diff disadorni con l'opzione . + + I diff vengono normalmente spediti in linea, nella stessa parte del corpo che contiene la descrizione della patch. Questo è il modo più facile per consentire al più ampio numero di lettori di rispondere citando parti di un diff, dato che alcuni client email citeranno soltanto la prima parte MIME del corpo di un messaggio. Se preferite inviare la descrizione e il diff in parti separate del corpo, usate l'opzione . + + Invece di spedire messaggi email, potete salvarli in una cartella email in formato mbox usando l'opzione . Questa opzione accetta un argomento, il nome del file su cui scrivere. + + Se preferite aggiungere un riepilogo nel formato del comando diffstat a ogni patch, e uno al messaggio introduttivo, usate l'opzione . Il comando diffstat mostra una tabella contenente il nome di ogni file coinvolto nella patch, il numero di righe modificate e un istogramma che illustra quante modifiche sono state apportate a ogni file. Questo riepilogo offre a chi legge una visione qualitativa della complessità di una patch.