# HG changeset patch # User Giulio@puck # Date 1249075661 -7200 # Node ID f67a90f6c055e3746fab73ed49c7a01649cc453b # Parent 6569bd1e5dbc5945b4f71a2f931e54a4ac174c6b Deep revision of Ch.10. diff -r 6569bd1e5dbc -r f67a90f6c055 it/ch10-hook.xml --- a/it/ch10-hook.xml Thu Jul 30 13:07:43 2009 +0200 +++ b/it/ch10-hook.xml Fri Jul 31 23:27:41 2009 +0200 @@ -7,16 +7,16 @@ Il nome che Mercurial usa per indicare una di queste azioni è hook. Gli hook vengono chiamati trigger in alcuni sistemi di controllo di revisione, ma i due nomi si riferiscono alla stessa idea. - Un'introduzione agli hook in Mercurial + Un'introduzione agli hook di Mercurial Qui di seguito troverete una breve lista degli hook supportati da Mercurial. Rivisiteremo ognuno di questi hook in maggior dettaglio più avanti, nella . - Ognuno degli hook la cui descrizione comincia con la parola Controlling ha l'abilità di determinare se un'attività può procedere. Se l'hook ha successo, l'attività può procedere; se fallisce, l'attività non viene permessa oppure viene annullata, a seconda dell'hook. + Ognuno degli hook che viene indicato come hook di controllo nella propria descrizione ha l'abilità di determinare se un'attività può procedere. Se l'hook ha successo, l'attività può procedere; se fallisce, l'attività non viene permessa oppure viene annullata, a seconda dell'hook. changegroup: viene eseguito dopo che un gruppo di changeset proveniente da qualche altra parte è stato propagato nel repository. - commit: viene eseguito dopo che un nuovo changeset è stato creato nel repository locale. + commit: viene eseguito dopo la creazione di un nuovo changeset nel repository locale. incoming: viene eseguito una volta per ogni nuovo changeset proveniente da qualche altra parte che è stato propagato nel repository. Notate la differenza con changegroup, che viene eseguito una volta per ogni gruppo di changeset propagato nel repository. @@ -25,19 +25,19 @@ prechangegroup: viene eseguito prima di cominciare a propagare un gruppo di changeset nel repository. precommit: - Controlling. This is run before starting a commit. - - preoutgoing: Controlling. Viene eseguito prima di cominciare a trasmettere un gruppo di changeset da questo repository. - - pretag: Controlling. Viene eseguito prima di creare un'etichetta. - - pretxnchangegroup: Controlling. Viene eseguito dopo che un gruppo di changeset proveniente da un altro repository è stato propagato nel repository locale, ma prima che la transazione che renderebbe permanenti i cambiamenti nel repository sia completata. - - pretxncommit: Controlling. Viene eseguito dopo che un nuovo changeset è stato creato nel repository locale, ma prima che la transazione che lo renderebbe permanente sia completata. - - preupdate: Controlling. Viene eseguito prima di cominciare un aggiornamento o un'unione della directory di lavoro. - - tag: viene eseguito dopo che un'etichetta è stata creata. + hook di controllo. Viene eseguito prima di cominciare un inserimento. + + preoutgoing: hook di controllo. Viene eseguito prima di cominciare a trasmettere un gruppo di changeset da questo repository. + + pretag: hook di controllo. Viene eseguito prima di creare un'etichetta. + + pretxnchangegroup: hook di controllo. Viene eseguito dopo che un gruppo di changeset proveniente da un altro repository è stato propagato nel repository locale, ma prima di completare la transazione che renderebbe permanenti i cambiamenti nel repository. + + pretxncommit: hook di controllo. Viene eseguito dopo la creazione di un nuovo changeset nel repository locale, ma prima di completare la transazione che lo renderebbe permanente. + + preupdate: hook di controllo. Viene eseguito prima di cominciare un aggiornamento o un'unione della directory di lavoro. + + tag: viene eseguito dopo la creazione di un'etichetta. update: viene eseguito dopo che un'operazione di aggiornamento o di unione della directory di lavoro è stata completata. @@ -49,49 +49,49 @@ Gli hook vengono eseguiti con i vostri privilegi - Quando eseguite un comando Mercurial in un repository e quel comando causa l'esecuzione di un hook, quell'hook esegue sul vostro sistema, sotto il vostro account utente, con il vostro livello di privilegio. Dato che gli hook sono frammenti di codice eseguibile, dovreste trattarli con un adeguato livello di sospetto. Non installate un hook a meno che non confidiate di sapere chi lo ha creato e che cosa fa. + Quando invocate un comando Mercurial in un repository e quel comando causa l'esecuzione di un hook, quell'hook viene eseguito sul vostro sistema, con il vostro account utente, al vostro livello di privilegio. Dato che gli hook sono frammenti di codice eseguibile, dovreste trattarli in maniera adeguatamente sospettosa. Non installate un hook a meno che non confidiate di sapere chi lo ha creato e che cosa fa. In alcuni casi, potreste essere esposti a hook che non avete installato voi. Se lavorate con Mercurial su un sistema che non vi è familiare, Mercurial eseguirà gli hook definiti nel file ~/.hgrc globale per quel sistema. - Se state lavorando con un repository posseduto da un altro utente, Mercurial può eseguire gli hook definiti nel repository di quell'utente, ma li eseguirà ancora con la vostra identità. Per esempio, se estraete i cambiamenti da quel repository tramite hg pull, e il suo file .hg/hgrc definisce un hoook outgoing locale, quell'hook verrà eseguito sotto il vostro account utente anche se non possedete quel repository. + Se state lavorando con un repository posseduto da un altro utente, Mercurial può eseguire gli hook definiti nel repository di quell'utente, ma li eseguirà ancora sotto la vostra identità. Per esempio, se estraete i cambiamenti da quel repository tramite hg pull, e il suo file .hg/hgrc definisce un hook outgoing locale, quell'hook verrà eseguito con il vostro account utente anche se non siete il proprietario di quel repository. - Questo si applica se state estraendo cambiamenti da un repository su un file system locale o di rete. Se state eseguendo l'estrazione via HTTP o SSH, qualsiasi hook outgoing eseguirà sotto qualunque account sta eseguendo il processo server, sul server. + Questo si applica se estraete cambiamenti da un repository operando su un file system locale o di rete. Se state effettuando l'estrazione via HTTP o SSH, qualsiasi hook outgoing verrà eseguito sul server con l'account utente che è stato usato per eseguire il processo server. - Per vedere quali hook sono definiti in un repository, usate il comando hg showconfig hooks. Se state lavorando in un repository, ma state comunicando con un repository che non possedete (e.g. usando hg pull o hg incoming), ricordate che sono gli hook dell'altro repository che dovreste controllare, non i vostri. - - - - Gli hooks non si propagano - - In Mercurial, gli hook non sono soggetti a controllo di revisione e non si propagano quando clonate un repository o ne estraete i cambiamenti. La ragione è semplice: un hook è un frammento di codice eseguibile completamente arbitrario. Esegue sotto la vostra identità utente, con il vostro livello di privilegio, sulla vostra macchina. - - Sarebbe estremamente avventato per qualsiasi sistema distribuito di controllo di revisione implementare hook soggetti al controllo di revisione, dato che questo offrirebbe un modo facilmente sfruttabile di sovvertire gli account degli utenti del sistema di controllo di revisione. - - Dato che Mercurial non propaga gli hook, se state collaborando con altre persone su un progetto comune, non dovreste presumere che gli altri stiano usando gli stessi hook Mercurial che state usando voi, o che i loro siano correttamente configurati. Dovreste documentare gli hook che vi aspettate che le persone usino. - - In una intranet aziendale, questo è in qualche modo più facile da controllare, dato che per esempio potete fornire una installazione standard di Mercurial su un file system NFS e usare un file ~/.hgrc #site-wide# per definire hook che tutti gli utenti vedranno. Tuttavia, come vedremo nella prossima sezione, anche questo approccio ha dei limiti. + Per vedere quali hook sono definiti in un repository, usate il comando hg showconfig hooks. Se state lavorando in un repository, ma state comunicando con un repository di cui non siete i proprietari (e.g. usando hg pull o hg incoming), ricordate che sono gli hook dell'altro repository che dovreste controllare, non i vostri. + + + + Gli hook non si propagano + + In Mercurial, gli hook non sono soggetti a controllo di revisione e non si propagano quando clonate un repository o ne estraete i cambiamenti. La ragione è semplice: un hook è un frammento di codice eseguibile completamente arbitrario. Viene eseguito sotto l'identità del vostro utente, al vostro livello di privilegio, sulla vostra macchina. + + Sarebbe estremamente avventato per qualsiasi sistema distribuito di controllo di revisione implementare hook soggetti al controllo di revisione, dato che questo offrirebbe un modo facilmente sfruttabile per alterare gli account degli utenti del sistema di controllo di revisione. + + Dato che Mercurial non propaga gli hook, se state collaborando con altre persone su un progetto comune, non dovreste presumere che gli altri stiano usando gli stessi hook Mercurial che state usando voi, o che i loro siano correttamente configurati. Dovreste documentare quali sono gli hook che vi aspettate siano usati dalle altre persone. + + In una intranet aziendale, questo aspetto è in qualche modo più facile da controllare, dato che per esempio potete fornire una installazione standard di Mercurial su un file system NFS e usare un file ~/.hgrc globale per definire hook che tutti gli utenti vedranno. Tuttavia, come constateremo nella prossima sezione, anche questo approccio ha dei limiti. Gli hook possono essere sostituiti - Mercurial vi consente di sostituire una definizione di hook ridefinendo quell'hook. Potete disabilitarlo impostando il suo valore alla stringa vuota, o cambiare il suo comportamento come desiderate. - - Se fate ricorso a un file ~/.hgrc di sistema o #site-wide# che definisce alcuni hook, dovreste quindi capire che i vostri utenti sono in grado di disabilitare o sostituire quegli hook. - - - - Assicurarvi che gli hook critici vengano eseguiti - - Talvolta potreste voler imporre una politica che non volete che gli altri siano in grado di aggirare. Per esempio, potreste avere un requisito che ogni changeset deve passare una rigorosa serie di test. Definire questo requisito attraverso un hook in un file ~/.hgrc #site-wide# non funzionerà per i computer portatili degli utenti remoti, e naturalmente gli utenti locali potranno sovvertirla a piacimento sostituendo quell'hook. - - Invece, potete impostare le vostre politiche per l'uso di Mercurial in modo da aspettarsi che le persone propaghino i cambiamenti attraverso un server canonico ben noto che avete messo in sicurezza e configurato adeguatamente. - - Un modo di fare questo è attraverso una combinazione di ingegneria sociale e tecnologia. Impostate un account con accesso ristretto; gli utenti possono trasmettere i cambiamenti attraverso la rete ai repository gestiti da questo account, ma non possono usare l'account per entrare sul server ed eseguire i normali comandi di shell. In questo scenario, un utente può effettuare il commit di un changeset che contiene tutta la vecchia spazzatura che vuole. - - Quando qualcuno trasmette un changeset al server da cui tutti estraggono i cambiamenti, il server verificherà il changeset prima di accettarlo come permanente, e lo rifiuterà se non riesce a passare i test. Se le persone si limitano a estrarre i cambiamenti da questo server di filtraggio, questo servirà ad assicurare che tutti i cambiamenti estratti dalle persone siano stati auotamticamente controllati. + Mercurial vi consente di sostituire una definizione di hook attraverso la sua ridefinizione. Potete disabilitare un hook impostando il suo valore alla stringa vuota, o cambiare il suo comportamento come desiderate. + + Se fate ricorso a un file ~/.hgrc di sistema o globale che definisce alcuni hook, dovreste quindi rendervi conto che i vostri utenti sono in grado di disabilitare o sostituire quegli hook. + + + + Assicurarsi che gli hook critici vengano eseguiti + + Talvolta potreste voler imporre il rispetto di una politica in modo che gli altri non siano in grado di aggirarla. Per esempio, potreste richiedere a ogni changeset di passare una rigorosa serie di test. La definizione di questo requisito attraverso un hook in un file ~/.hgrc globale non avrà effetto sui computer portatili degli utenti remoti, e naturalmente gli utenti locali potranno alterarla a piacimento sostituendo quell'hook. + + Invece, potete istituire le vostre politiche sull'uso di Mercurial in modo che le persone siano tenute a propagare i cambiamenti attraverso un server canonico ben noto che avete messo in sicurezza e configurato adeguatamente. + + Questo risultato si può ottenere attraverso una combinazione di ingegneria sociale e tecnologia. Impostate un account con accesso ristretto; gli utenti possono trasmettere i cambiamenti attraverso la rete ai repository gestiti da questo account, ma non possono usare l'account per entrare sul server ed eseguire i normali comandi di shell. In questo scenario, un utente può effettuare il commit di un changeset che contiene tutte le porcherie che desidera. + + Quando qualcuno trasmette un changeset al server da cui tutti estraggono i cambiamenti, il server verificherà il changeset prima di accettarlo come permanente e lo rifiuterà se non riesce a passare i test. Se le persone si limitano a estrarre i cambiamenti da questo server di filtraggio, questo servirà ad assicurare che tutti i cambiamenti estratti dalle persone siano stati automaticamente controllati. @@ -99,41 +99,41 @@ Una breve guida all'uso degli hook - Scrivere un hook Mercurial è facile. Cominciamo con un hook che viene eseguito quando l'invocazione di hg commit termina e che stampa semplicemente l'hash del changeset appena creato. L'hook è chiamato commit. + Scrivere un hook Mercurial è facile. Cominciamo con un hook che viene invocato al termine dell'invocazione di hg commit e che stampa semplicemente l'hash del changeset appena creato. L'hook è chiamato commit. Tutti gli hook seguono lo schema presentato in questo esempio. -&interaction.hook.simple.init; - - Aggiungete una voce alla sezione hooks del vostro file ~/.hgrc. Sulla sinistra si trova il nome dell'evento su cui attivarsi, sulla destra si trova l'azione da intraprendere. Come potete vedere, potete eseguire comandi di shell arbitrari in un hook. Mercurial passa informazioni aggiuntive all'hook usando le variabili d'ambiente (cercate HG_NODE nell'esempio). + &interaction.hook.simple.init; + + Aggiungete una voce alla sezione hooks del vostro file ~/.hgrc. Sulla sinistra si trova il nome dell'evento in risposta al quale attivarsi, sulla destra si trova l'azione da intraprendere. Come vedete, è possibile eseguire comandi di shell arbitrari in un hook. Mercurial passa informazioni aggiuntive all'hook usando le variabili d'ambiente (cercate HG_NODE nell'esempio). Effettuare molteplici azioni per evento - Piuttosto spesso, vorrete definire più di un hook per un particolare tipo di evento, come mostrato qui sotto. + Vi capiterà piuttosto spesso di voler definire più di un hook per un particolare tipo di evento, come mostrato qui sotto. &interaction.hook.simple.ext; - Mercurial vi permette di fare questo aggiungendo una estensione alla fine del nome di un hook. Il nome di un hook si estende dando il nome dell'hook, seguito da un punto (il carattere .), seguito da altro testo di vostra scelta. Per esempio, Mercurial eseguirà sia commit.foo che commit.bar all'occorrenza dell'evento commit. - - Per dare un ordine di esecuzione ben definito quando ci sono molteplici hook definiti per un evento, Mercurial ordina gli hook secondo l'estensione ed esegue i comandi di hook in questo ordine. Nell'esempio precedente, eseguirà commit.bar prima di commit.foo, e commit prima di entrambi. - - È una buona idea usare un'estensione in qualche modo descrittiva quando definite un nuovo hook. Questo vi aiuterà a ricordare lo scopo di quell'hook. Se l'hook fallisce, otterrete un messaggio di errore che contiene il nome dell'hook e l'estensione, quindi l'impiego di una estensione descrittiva potrebbe darvi un suggerimento immediato sul motivo per cui l'hook è fallito (si veda la per un esempio). + Mercurial vi permette di fare questo aggiungendo un'estensione alla fine del nome di un hook. Il nome di un hook si estende scrivendo il nome dell'hook, seguito da un punto (il carattere .), seguito da altro testo di vostra scelta. Per esempio, Mercurial eseguirà sia commit.foo che commit.bar all'occorrenza dell'evento commit. + + Per stabilire un ordine di esecuzione ben definito quando più hook corrispondono allo stesso evento, Mercurial ordina gli hook secondo l'estensione ed esegue i comandi di hook in questo ordine. Nell'esempio precedente, eseguirà commit.bar prima di commit.foo, e commit prima di entrambi. + + Per aiutarvi a ricordare lo scopo di un hook, è buona norma usare un'estensione abbastanza descrittiva quando ne definite uno nuovo. Se l'hook fallisce, otterrete un messaggio di errore che contiene il nome dell'hook e l'estensione, quindi l'impiego di un'estensione descrittiva potrebbe darvi un suggerimento immediato sul motivo per cui l'hook è fallito (si veda la per un esempio). Controllare se un'attività può procedere - Nei nostri primi esempi, abbiamo usato l'hook commit, che viene eseguito dopo che un commit è stato completato. Questo è uno tra i vari hook Mercurial che vengono eseguiti dopo che un'attività si conclude. Questi hook non hanno alcun modo di influenzare l'attività stessa. - - Mercurial definisce un certo numero di eventi che accadono prima che un'attività cominci, o dopo che è cominciata ma prima che termini. Gli hook che vengono attivati da questi eventi hanno l'abilità aggiuntiva di scegliere se l'attività può continuare o se verrà abortita. - - L'hook pretxncommit viene eseguito dopo che un commit è stato completamente eseguito ma non è ancora concluso. In altre parole, i metadati che rappresentano il changeset sono stati scritti su disco, ma la transazione non ha ancora avuto il permesso di completarsi. L'hook pretxncommit ha l'abilità di decidere se la transazione può completarsi oppure se deve essere abortita. + Nei nostri primi esempi, abbiamo usato l'hook commit, che viene invocato al termine di un commit ed è uno dei vari hook Mercurial che vengono eseguiti dopo la conclusione di un'attività. Questi hook non hanno alcun modo di influenzare l'attività stessa. + + Mercurial definisce un certo numero di eventi che accadono prima che un'attività cominci, o dopo che è cominciata ma prima che termini. Gli hook attivati da questi eventi hanno l'ulteriore capacità di determinare se l'attività può continuare o se verrà abortita. + + L'hook pretxncommit viene invocato dopo che un commit è stato completamente eseguito ma non è ancora concluso. In altre parole, i metadati che rappresentano il changeset sono stati scritti su disco, ma la transazione non ha ancora avuto il permesso di completarsi. L'hook pretxncommit ha la capacità di decidere se la transazione può completarsi oppure se deve essere abortita. Se l'hook pretxncommit termina con un codice di stato uguale a zero, la transazione può completare, il commit si conclude e l'hook commit viene eseguito. Se l'hook pretxncommit termina con un codice di stato diverso da zero, la transazione viene abortita, i metadati che rappresentano il changeset vengono cancellati e l'hook commit non viene eseguito. -&interaction.hook.simple.pretxncommit; + &interaction.hook.simple.pretxncommit; L'hook in questo esempio controlla che il messaggio di commit contenga un identificatore di bug. Se lo contiene, il commit può completare, altrimenti il commit viene abortito. @@ -142,18 +142,18 @@ Implementare i vostri hook - Quando state scrivendo un hook, potreste trovare utile eseguire Mercurial con l'opzione oppure con l'elemento di configurazione verbose impostato a true. Quando fate così, Mercurial stamperà un messaggio prima di invocare ogni hook. + Quando state scrivendo un hook, potreste trovare utile eseguire Mercurial con l'opzione oppure con l'elemento di configurazione verbose impostato a vero, in modo che Mercurial stampi un messaggio prima di invocare qualsiasi hook. - Scegliere come il vostro hook dovrebbe eseguire + Scegliere la modalità di esecuzione del vostro hook Potete implementare un hook come un programma normale&emdash;tipicamente uno script di shell&emdash;o come una funzione Python che viene eseguita nell'ambito del processo Mercurial. - Implementare un hook come programma esterno ha il vantaggio di non richiedere alcuna conoscenza del funzionamento interno di Mercurial. Potete invocare i normali comandi Mercurial per ottenere qualsiasi informazione aggiuntiva di cui abbiate bisogno. Il #trade-off# è che gli hook esterni sono più lenti rispetto agli hook #in-process#. - - Un hook Python #in-process# ha accesso completo alla API di Mercurial e non #shell out# a un altro processo, quindi è inerentemente più veloce rispetto a un hook esterno. In più, ottenere la maggior parte delle informazioni richieste da un hook è più facile usando la API di Mercurial che eseguendo i comandi Mercurial. - - Se siete a vostro agio con Python, o richiedete prestazioni elevate, implementarei vostri hook in Python potrebbe essere una buona scelta. Tuttavia, quando avete un hook semplice da scrivere e le prestazioni non vi interessano (probabilmente per la maggior parte degli hook), uno script di shell è perfettamente adeguato. + Implementare un hook come programma esterno ha il vantaggio di non richiedere alcuna conoscenza del funzionamento interno di Mercurial. Potete invocare i normali comandi Mercurial per ottenere tutte le informazioni aggiuntive di cui avete bisogno. Lo svantaggio è che gli hook esterni sono più lenti rispetto agli hook interni. + + Un hook Python interno ha accesso completo alla API di Mercurial e non deve pagare la creazione di un altro processo, quindi è intrinsecamente più veloce rispetto a un hook esterno. Per ottenere la maggior parte delle informazioni richieste da un hook è anche più facile usare la API di Mercurial che eseguire i comandi Mercurial. + + Se siete a vostro agio con Python, o avete bisogno di prestazioni elevate, implementare i vostri hook in Python potrebbe essere una buona scelta. Tuttavia, quando il vostro hook è semplice da scrivere e le prestazioni non vi interessano (cose che probabilmente capitano per la maggior parte degli hook), uno script di shell è perfettamente adeguato. @@ -161,13 +161,13 @@ Mercurial invoca ogni hook con un insieme di parametri ben definito. In Python, un parametro viene passato come un argomento con nome alla vostra funzione di hook. Per un programma esterno, un parametro viene passato come una variabile d'ambiente. - Sia che il vostro hook sia implementato in Python che come uno script di shell, i nomi e i valori dei parametri specifici per quell'hook saranno gli stessi. Un parametro booleano sarà rappresentato come un valore booleano in Python, ma come il numero 1 (per vero) o 0 (per falso) come una variabile d'ambiente per un hook esterno. Se il nome di un parametro di hook è foo, anche l'argomento con nome per un hook Python sarà chiamato foo, mentre la variabile d'ambiente per un hook esterno sarà chiamata HG_FOO. + I nomi e i valori dei parametri specifici di un hook saranno gli stessi sia per gli hook implementati in Python sia per quelli realizzati come script di shell. Un parametro booleano sarà rappresentato come un valore booleano in Python, ma come una variabile d'ambiente con valore numerico 1 (per vero) o 0 (per falso) per un hook esterno. Se il nome di un parametro di hook è foo, anche l'argomento con nome per un hook Python sarà chiamato foo, mentre la variabile d'ambiente per un hook esterno sarà chiamata HG_FOO. I valori di ritorno degli hook e il controllo delle attività - Un hook che viene eseguito con successo deve terminare con uno stato uguale a zero se è esterno, o restituire il valore booleano falso se è #in-process#. Il fallimento viene indicato con uno stato di terminazione diverso da zero per un hook esterno, o dal valore booleano vero per un hook #in-process#. Se un hook #in-process# solleva un'eccezione, l'hook viene considerato come fallito. + Un hook che viene eseguito con successo deve terminare con uno stato uguale a zero se è esterno, o restituire il valore booleano falso se è interno. Il fallimento viene indicato con uno stato di terminazione diverso da zero per un hook esterno, o dal valore booleano vero per un hook interno. Se un hook interno solleva un'eccezione, l'hook si considera fallito. Per un hook che controlla se un'attività può procedere, zero o falso significano concesso, mentre un numero diverso da zero, vero, o un'eccezione significano negato. @@ -175,21 +175,21 @@ Scrivere un hook esterno - Quando definite un hook esterno nel vostro file ~/.hgrc e l'hook viene eseguito, il suo valore viene passato alla vostra shell, che lo interpreta. Questo significa che potete usare i normali costrutti di shell nel corpo dell'hook. + Quando definite un hook esterno nel vostro file ~/.hgrc e l'hook viene invocato, il suo valore viene passato alla vostra shell, che lo interpreta. Questo significa che potete usare i normali costrutti di shell nel corpo dell'hook. Un hook eseguibile viene sempre eseguito con la sua directory corrente impostata alla directory radice del repository. Ogni parametro di hook viene passato come una variabile di ambiente con il nome in maiuscolo preceduto dalla stringa HG_. - Con l'eccezione dei parametri di hook, Mercurial non imposta o modifica alcuna variabile d'ambiente quando esegue un hook. Questo è utile da ricordare se state scrivendo un hook #site-wide# che potrebbe venire eseguito da un certo numero di utenti differenti con differenti variabili d'ambiente impostate. In situazioni multi-utente, non dovreste fare affidamento sul fatto che le variabili di ambiente siano impostate con i valori che avete nel vostro ambiente quando state collaudando l'hook. - - - - Dire a Mercurial di usare un hook #in-process# - - La sintassi del file ~/.hgrc per definire un hook #in-process# è leggermente differente da quella per un hook eseguibile. Il valore dell'hook deve cominciare con il testo python: e proseguire con il nome completamente qualificato dell'oggetto invocabile da usare come il valore dell'hook. - - Il modulo in cui si trova l'hook viene automaticamente importato quando l'hook viene eseguito. Fino a quando il nome del modulo e il valore di PYTHONPATH sono corretti, dovrebbe funzionare e basta. + Con l'eccezione dei parametri di hook, Mercurial non imposta o modifica alcuna variabile d'ambiente quando esegue un hook. Questo è utile da ricordare se state scrivendo un hook globale che potrebbe venire invocato da un certo numero di utenti differenti con differenti variabili d'ambiente impostate. In ambienti multi-utente, non dovreste fare affidamento sul fatto che le variabili d'ambiente abbiano i valori che avete impostato nel vostro ambiente di lavoro durante il collaudo dell'hook. + + + + Dire a Mercurial di usare un hook interno + + La sintassi del file ~/.hgrc per definire un hook interno è leggermente differente da quella per un hook eseguibile. Il valore dell'hook deve cominciare con il testo python: e proseguire con il nome completamente qualificato dell'oggetto invocabile da usare come valore dell'hook. + + Il modulo in cui si trova l'hook viene automaticamente importato quando l'hook viene invocato. Purché il nome del modulo e il valore di PYTHONPATH siano corretti, l'importazione dovrebbe funzionare e basta. Il seguente frammento di un file ~/.hgrc di esempio illustra la sintassi e il significato delle nozioni appena descritte. [hooks] @@ -198,12 +198,12 @@ - Implementare un hook #in-process# - - Il più semplice hook #in-process# non fa nulla, ma illustra la forma base della API degli hook: + Implementare un hook interno + + Il più semplice hook interno non fa nulla, ma illustra la forma base della API degli hook: def myhook(ui, repo, **kwargs): pass - Il primo argomento di un hook Python è sempre un oggetto ui. Il secondo è un oggetto repository, al momento sempre un'istanza di localrepository. Gli altri argomenti con nome seguono questi due argomenti. Quali vengono passati dipende dall'hook che viene invocato, ma un hook può ignorare gli argomenti di cui non ha bisogno depositandoli in un dizionario di argomenti con nome, come succede con **kwargs qui sopra. + Il primo argomento di un hook Python è sempre un oggetto mercurial.ui.ui. Il secondo è un oggetto repository, al momento sempre un'istanza di mercurial.localrepo.localrepository. Gli altri argomenti con nome seguono questi due argomenti. Quali argomenti con nome vengono passati dipende dall'hook che viene invocato, ma un hook può ignorare gli argomenti di cui non ha bisogno depositandoli in un dizionario di argomenti con nome, come succede con **kwargs qui sopra. @@ -221,23 +221,23 @@ Controllare lo spazio bianco in coda - Un uso interessante per un hook relativo ai commit è quello di aiutarvi a scrivere codice più pulito. Un semplice esempio di codice più pulito è l'affermazione che un cambiamento non dovrebbe aggiungere alcuna nuova riga di testo che contiene spazio bianco in coda. Lo spazio bianco in coda è composto da una serie di spazi e caratteri di tabulazione alla fine di una riga di testo. Nella maggior parte dei casi, lo spazio bianco in coda è rumore invisibile e superfluo, ma è occasionalmente problematico, e in genere le persone preferiscono sbarazzarsene. - - Potete usare l'hook precommit o l'hook pretxncommit per scoprire se avete un problema di spazio bianco in coda. Se usate precommit, l'hook non saprà quali file state inserendo, quindi dovrà controllare ogni file modificato nel repository alla ricerca di spazio bianco in coda. Se volete inserire un cambiamento al solo file foo, ma il flie bar contiene spazio bianco in coda, effettuare un controllo tramite l'hook precommit vi impedirà di eseguire il commit di foo a causa dei problemi con bar. Questo non sembra il comportamento corretto. - - Se doveste scegliere l'hook pretxncommit, il controllo non accadrà fino al momento appena precedente il completamento della transizione di commit. Questo vi consentirà di controllare il problema solo sui file esatti che verranno inseriti. Tuttavia, se avete inserito il messaggio di commit interattivamente e l'hook fallisce, la transazione verrà abortita e dovrete riscrivere il messaggio di commit dopo aver corretto lo spazio bianco in coda e invocato ancora hg commit. + Un uso interessante per un hook relativo ai commit è quello di aiutarvi a scrivere codice più pulito. Un semplice esempio di codice più pulito è la regola per cui un cambiamento non dovrebbe aggiungere nessuna nuova riga di testo contenente spazio bianco in coda. Lo spazio bianco in coda è composto da una serie di spazi e caratteri di tabulazione alla fine di una riga di testo. Nella maggior parte dei casi, lo spazio bianco in coda non è altro che rumore invisibile e superfluo, ma si rivela occasionalmente problematico e in genere le persone preferiscono sbarazzarsene. + + Potete usare l'hook precommit o l'hook pretxncommit per scoprire se avete un problema di spazio bianco in coda. Se usate precommit, l'hook non saprà quali file state inserendo, quindi dovrà controllare ogni file modificato nel repository alla ricerca di spazio bianco in coda. Se volete inserire un cambiamento al solo file foo, ma il flie bar contiene spazio bianco in coda, effettuare un controllo tramite l'hook precommit vi impedirà di eseguire il commit di foo a causa dei problemi con bar. Questo comportamento non sembra corretto. + + Se doveste scegliere l'hook pretxncommit, il controllo non avverrà fino al momento appena precedente il completamento della transizione di commit. Questo vi consentirà di controllare il problema solo sui file che verranno registrati. Tuttavia, se avete inserito il messaggio di commit interattivamente e l'hook fallisce, la transazione verrà abortita e dovrete riscrivere il messaggio di commit dopo aver corretto lo spazio bianco in coda e invocato ancora hg commit. &interaction.ch09-hook.ws.simple; - In questo esempio, introduciamo un semplice hook pretxncommit che controlla lo spazio bianco in coda. Questo hook è breve, ma non molto utile. Termina con uno stato di errore se un cambiamento aggiunge una riga con spazio bianco in coda a un file qualsiasi, ma non stampa alcuna informazione che potrebbe aiutarci a individuare il file o la riga che contiene il problema. L'hook ha anche la piacevole proprietà di non fare attenzione alle righe non modificate, in quanto solo le righe che introducono nuovo spazio bianco in coda causano problemi. + In questo esempio, abbiamo introdotto un semplice hook pretxncommit che controlla lo spazio bianco in coda. Questo hook è breve, ma non molto utile: termina con uno stato di errore se un changeset aggiunge una riga con spazio bianco in coda a un file qualsiasi, ma non stampa alcuna informazione che potrebbe aiutarci a individuare il file o la riga che contiene il problema. L'hook ha anche la piacevole proprietà di non prestare attenzione alle righe non modificate, in quanto solo le righe che introducono nuovo spazio bianco in coda causano problemi. &ch09-check_whitespace.py.lst; - Questa versione è molto più complessa, ma anche molto più utile. Analizza un diff in formato unified per vedere se una qualsiasi riga aggiunge spazio bainco in coda e stampa ilnome del file e il numero della riga di ogni occorrenza di questo tipo. Anche meglio, se il cambiamento aggiunge spazio bianco in coda, questo hook salva il messaggio di commit e stampa il nome del file salvato prima di uscire e dire a Mercurial di abortire la transazione, in modo che possiate usare l'opzione del comando hg commit per riutilizzare il messaggio di commit salvato una volta che avete corretto il problema. + Questa versione è molto più complessa, ma anche molto più utile. Analizza un diff in formato unified per vedere se una qualsiasi riga aggiunge spazio bianco in coda e stampa il nome del file e il numero della riga di ogni occorrenza di questo tipo. Anche meglio, se il cambiamento aggiunge spazio bianco in coda, questo hook salva il messaggio di commit e stampa il nome del file salvato prima di uscire e dire a Mercurial di abortire la transazione, in modo che possiate usare l'opzione del comando hg commit per riutilizzare il messaggio di commit salvato una volta che avete corretto il problema. &interaction.ch09-hook.ws.better; - Come digressione finale, notate in questo esempio l'uso della funzionalità di modifica sul posto di sed per eliminare lo spazio bianco in coda da un file. Questo impiego è sufficientemente conciso e utile che lo riprodurrò qui di seguito (usando perl per essere sicuro). + Come ultima nota a margine, osservate in questo esempio l'uso della funzionalità di modifica sul posto di sed per eliminare lo spazio bianco in coda da un file. Questo impiego è sufficientemente conciso e utile che lo riprodurrò qui di seguito (usando perl per sicurezza). perl -pi -e 's,\s+$,,' filename @@ -245,25 +245,25 @@ Hook inclusi - Mercurial viene distribuito con diversi hook inclusi che potete trovare nella directory hgext dell'albero dei sorgenti di Mercurial. Se state usando un pacchetto eseguibile di Mercurial, gli hook si trovano nella directory hgext posizionata dovunque il vostro pacchetto abbia installato Mercurial. + Mercurial viene distribuito con diversi hook inclusi che potete trovare nella directory hgext dell'albero dei sorgenti di Mercurial. Se state usando un pacchetto eseguibile di Mercurial, gli hook si trovano nella directory hgext posizionata ovunque il vostro pacchetto abbia installato Mercurial. <literal role="hg-ext">acl</literal>&emdash;controllo di accesso per parti di un repository - L'estensione acl vi permette di controllare a quali utenti remoti è permesso di trasmettere changeset verso un server attraverso la rete. Potete proteggere qualsiasi porzione di un repository (compreso l'intero repository), in modo che uno specifico utente remoto possa trasmettere cambiamenti che non influenzano le parti protette. - - Questa estensione implementa il controllo di accesso sulla base dell'identità dell'utente che effettua la trasmissione, non di chi ha eseguito il commit dei changeset che vengono trasferiti. Ha senso usare questo hook solo se avete un ambiente server chiuso che autentica gli utenti remoti e volete essere sicuri che solo specifici utenti possano trasmettere cambiamenti a quel server. + L'estensione acl vi permette di controllare quali utenti remoti hanno il permesso di trasmettere changeset verso un server attraverso la rete. Potete proteggere qualsiasi porzione di un repository (compreso l'intero repository) in modo che uno specifico utente remoto possa trasmettere solo cambiamenti che non influenzano le parti protette. + + Questa estensione implementa il controllo di accesso sulla base dell'identità dell'utente che effettua la trasmissione, non di chi ha eseguito il commit dei changeset che vengono trasferiti. Ha senso usare questo hook solo se avete un ambiente server protetto che autentica gli utenti remoti e volete essere sicuri che solo specifici utenti possano trasmettere cambiamenti a quel server. Configurare l'hook <literal role="hook">acl</literal> - Per gestire i cambiamenti in entrata, l'hook acl deve essere usato come un hook pretxnchangegroup. Questo vi permette di vedere quali file vengono modificati da ogni changeset in entrata e di abortire un gruppo di changeset se modificano file proibiti. Ecco un esempio di come attivare l'hook: + Per gestire i cambiamenti in entrata, l'hook acl deve essere usato come un hook pretxnchangegroup. Questo vi permette di vedere quali file vengono modificati da ogni changeset in entrata e di abortire un gruppo di changeset se modifica qualche file proibito. Ecco un esempio di come attivare l'hook: [hooks] pretxnchangegroup.acl = python:hgext.acl.hook L'estensione acl si configura usando tre sezioni. - La sezione acl contiene solo la voce sources, che elenca le fonti di cambiamenti in entrata a cui l'hook deve fare attenzione. Di solito, non avrete bisogno di configurare questa sezione. + La sezione acl contiene solo la voce sources, che elenca le modalità di provenienza dei cambiamenti in entrata a cui l'hook deve fare attenzione. Di solito, non avrete bisogno di configurare questa sezione. serve: controlla i changeset in entrata che arrivano da un repository remoto via HTTP o SSH. Questo è il valore predefinito di sources e di solito è l'unica impostazione di cui avrete bisogno per questo elemento di configurazione. @@ -271,14 +271,14 @@ push: controlla i cambiamenti in entrata che arrivano attraverso una trasmissione da un repository locale. - bundle: controlla i changeset in entrata che arrivano da un altro repository attraverso un #bundle#. + bundle: controlla i changeset in entrata che arrivano da un altro repository attraverso un bundle.FIXME Cos'è un bundle? - La sezione acl.allow controlla gli utenti a cui è permesso aggiungere changeset al repository. Se questa sezione non è presente, il permesso viene concesso a tutti gli utenti a cui non viene esplicitamente negato. Se questa sezione è presente, il permesso viene negato a tutti gli utenti a cui non viene esplicitamente concesso (quindi una sezione vuota significa che il permesso è negato a tutti gli utenti). - - La sezione acl.deny determina a queli utenti viene impedito di aggiungere changeset al repository. Se questa sezione non è presente o è vuota, tutti gli utenti hanno il permesso di aggiungere. - - Le sintassi per le sezioni acl.allow e acl.deny sono identiche. Sulla sinistra di ogni voce si trova un pattern di tipo glob che corrisponde a file e directory relativi alla radice del repository, sulla destra si trova un nome utente. + La sezione acl.allow controlla gli utenti a cui è permesso aggiungere changeset al repository. Se questa sezione non è presente, il permesso viene concesso a tutti gli utenti a cui non viene esplicitamente negato. Se questa sezione è presente, il permesso viene negato a tutti gli utenti a cui non viene esplicitamente concesso (quindi una sezione vuota significa che il permesso viene negato a tutti gli utenti). + + La sezione acl.deny determina a quali utenti viene impedito di aggiungere changeset al repository. Se questa sezione non è presente o è vuota, tutti gli utenti hanno il permesso di aggiungere modifiche. + + La sintassi per le sezioni acl.allow e acl.deny è la stessa. Sulla sinistra di ogni voce si trova un pattern di tipo glob che corrisponde a file e directory relativi alla radice del repository, sulla destra si trova un nome utente. Nell'esempio seguente, l'utente docwriter può trasmettere cambiamenti solo al sottoalbero docs del repository, mentre l'utente intern può trasmettere cambiamenti a qualsiasi file o directory tranne source/sensitive. @@ -291,11 +291,11 @@ Collaudo e risoluzione dei problemi - Se volete collaudare l'hook acl, eseguitelo con le informazioni di debug di Mercurial abilitate. Dato che probabilmente lo eseguirete su un server dove non è conveniente (o talvolta possibile) passare l'opzione , non dimenticatevi che potete abilitare le informazioni di debug nel vostro file ~/.hgrc: + Se volete collaudare l'hook acl, eseguitelo abilitando le informazioni di debug di Mercurial abilitate. Dato che probabilmente lo eseguirete su un server dove non è conveniente (e talvolta nemmeno possibile) passare l'opzione , non dimenticatevi che potete abilitare le informazioni di debug nel vostro file ~/.hgrc: [ui] debug = true - Con questo abilitato, l'hook acl stamperà abbastanza informazioni da permettervi di capire perché sta consentendo o vietando le trasmissioni da specifici utenti. + Con questa opzione abilitata, l'hook acl stamperà abbastanza informazioni da permettervi di capire perché sta consentendo o vietando le trasmissioni da specifici utenti. @@ -307,39 +307,39 @@ L'estensione bugzilla aggiunge un commento a un bug su Bugzilla ogni volta che trova un riferimento all'identificatore di quel bug in un messaggio di commit. Potete installare questo hook su un server condiviso, in modo che l'hook venga eseguito ogni volta che un utente remoto trasmette i cambiamenti a quel server. L'hook aggiunge al bug un commento che somiglia a questo (potete configurare i contenuti del commento, come vedrete fra un attimo): - Changeset aad8b264143a, made by Joe User - <joe.user@domain.com> in the frobnitz repository, refers - to this bug. For complete details, see + Changeset aad8b264143a, creato da Mario Rossi + <mario.rossi@example.com> nel repository vattelapesca, fa riferimento + a questo bug. Per i dettagli completi, si veda http://hg.domain.com/frobnitz?cmd=changeset;node=aad8b264143a - Changeset description: Fix bug 10483 by guarding against some - NULL pointers - Il valore di questo hook è che automatizza il processo di aggiornare un bug ogni volta che un changeset vi fa riferimento. Se configurate l'hook in maniera adeguata, faciliterà la navigazione diretta da un bug su Bugzilla a un changeset che si riferisce a quel bug. - - Potete usare il codice di questo hook come un punto di partenza per ricette di integrazione con Bugzilla più esotiche. Ecco alcune possibilità. - - Richiedere che ogni changeset trasmesso al server abbia un identificatore di bug valido nel suo messaggio di commit. In questo caso, vorrete configurare l'hook come un hook pretxncommit. Questo permetterebbe all'hook di rifiutare cambiamenti che non contengono identificatori di bug. - - Permettere ai changeset in entrata di modificare automaticamente lo stato di un bug, come pure di aggiungere semplicemente un commento. Per esempio, l'hook potrebbe riconoscere la stringa fixed bug 31337 come indicatore che dovrebbe aggiornare lo stato del bug 31337 a richiede un collaudo. + Descrizione del changeset: risolto bug 10483 proteggendo il codice da alcuni + puntatori NULL. + Il valore di questo hook è che automatizza il processo di aggiornamento di un bug ogni volta che un changeset vi fa riferimento. Se lo configurate in maniera adeguata, l'hook faciliterà la navigazione diretta da un bug su Bugzilla a un changeset che si riferisce a quel bug. + + Potete usare il codice di questo hook come un punto di partenza per ricette più esotiche di integrazione con Bugzilla. Ecco alcune possibilità. + + Richiedere che ogni changeset trasmesso al server abbia un identificatore di bug valido nel proprio messaggio di commit. In questo caso, vorrete configurare l'hook come un hook pretxncommit per consentirgli di rifiutare i cambiamenti che non contengono identificatori di bug. + + Permettere ai changeset in entrata di modificare automaticamente lo stato di un bug, come pure di aggiungere semplicemente un commento. Per esempio, l'hook potrebbe riconoscere la stringa risolto bug 31337 come il segnale che indica la necessità di aggiornare lo stato del bug 31337 a richiede un collaudo. Configurare l'hook <literal role="hook">bugzilla</literal> - Dovreste configurare questo hook nel file ~/.hgrc del vostro server come un hook incoming, per esempio come segue: + Dovreste configurare questo hook nel file ~/.hgrc del vostro server come un hook incoming, per esempio nel modo seguente: [hooks] incoming.bugzilla = python:hgext.bugzilla.hook - A causa della natura specializzata di questo hook e dato che Bugzilla non è stato implementato con questo tipo di integrazioni in mente, configurare questo hook è un processo in qualche modo complicato. - - Prima di cominciare, dovete installare i #binding# Python per MySQL sulla macchina (o le macchine) dove intendete eseguire l'hook. Se non sono disponibili sotto forma di pacchetto eseguibile per il vostro sistema, potete scaricarli da web:mysql-python. + A causa della natura specializzata dell'hook e dato che Bugzilla non è stato implementato con questo tipo di integrazioni in mente, configurare questo hook è un processo piuttosto complicato. + + Prima di cominciare, dovete installare la libreria di interfaccia Python per MySQL sulla macchina (o le macchine) dove intendete eseguire l'hook. Se non è disponibile sotto forma di pacchetto eseguibile per il vostro sistema, potete scaricarla da web:mysql-python. Le informazioni di configurazione per questo hook si trovano nella sezione bugzilla del vostro file ~/.hgrc. - version: la versione di Bugzilla installata sul server. Lo schema di database che Bugzilla usa cambia occasionalmente, quindi questo hook deve sapere esattamenre quale schema usare. - - host: il nome della macchina del server MySQL che memorizza i vostri dati di Bugzilla. Il database deve essere configurato per consentire le connessioni da qualunque macchina stia eseguendo l'hook bugzilla. + version: la versione di Bugzilla installata sul server. Lo schema di database usato da Bugzilla cambia occasionalmente, quindi questo hook deve sapere esattamente quale schema usare. + + host: il nome della macchina del server MySQL che memorizza i vostri dati per Bugzilla. Il database deve essere configurato per consentire le connessioni da qualunque macchina stia eseguendo l'hook bugzilla. user: il nome utente con il quale connettersi al server MySQL. Il database deve essere configurato per consentire a questo utente di connettersi da qualunque macchina stia eseguendo l'hook bugzilla. Questo utente deve essere in grado di modificare le tabelle di Bugzilla. Il valore predefinito di questo elemento è bugs, che è il nome standard dell'utente Bugzilla in un database MySQL. @@ -348,9 +348,9 @@ db: il nome del database Bugzilla sul server MySQL. Il valore predefinito di questo elemento è bugs, che è il nome standard del database MySQL dove Bugzilla memorizza i propri dati. - notify: se volete che Bugzilla invii una email di notifica agli interessati dopo che questo hook ha aggiunto un commento a un bug, avrete bisogno che questo hook esegua un comando ogni volta che aggiorna il database. Il comando da eseguire dipende da dove avete installato Bugzilla, ma tipicamente somiglierà al seguente, se avete installato Bugzilla in /var/www/html/bugzilla: + notify: se volete che Bugzilla spedisca un'email di notifica agli interessati dopo che questo hook ha aggiunto un commento a un bug, avrete bisogno che questo hook esegua un comando ogni volta che aggiorna il database. Il comando da eseguire dipende da dove avete installato Bugzilla, ma tipicamente somiglierà al seguente, se avete installato Bugzilla in /var/www/html/bugzilla: cd /var/www/html/bugzilla && - ./processmail %s nobody@nowhere.com + ./processmail %s nessuno@example.com Il programma processmail di Bugzilla si aspetta che gli vengano passati un identificatore di bug (l'hook sostituisce %s con l'identificatore di bug) e un indirizzo email. Si aspetta anche di essere in grado di scrivere su alcuni file nella directory in cui viene eseguito. Se Bugzilla e questo hook non sono installati sulla stessa macchina, dovrete trovare un modo per eseguire processmail sul server dove Bugzilla è installato. @@ -361,29 +361,30 @@ Di default, l'hook bugzilla prova a utilizzare l'indirizzo email di chi ha eseguito il commit del changeset come il nome utente Bugzilla con cui aggiornare un bug. Se questa impostazione non vi soddisfa, potete correlare gli indirizzi email degli utenti Mercurial ai nomi utente Bugzilla tramite una sezione usermap. - Ogni elemento nella sezione usermap contiene un indirizzo emial sulla sinistra e un nome utente Bugzilla sulla destra. + Ogni elemento nella sezione usermap contiene un indirizzo email sulla sinistra e un nome utente Bugzilla sulla destra. [usermap] -jane.user@example.com = jane - Potete tenere i dati della sezione usermap in un normale file ~/.hgrc, oppure dire all'hook bugzilla di leggere le informazioni da un file usermap esterno. In quest'ultimo caso, potete memorizzare i dati del file usermap da soli in (per esempio) un repository modificabile dall'utente. Questo rende possibile permettere ai vostri utenti di mantenere le proprie voci della sezione usermap. Il file ~/.hgrc principale potrebbe somigliare a questo: +maria.bianchi@example.com = maria + Potete tenere i dati della sezione usermap in un normale file ~/.hgrc, oppure dire all'hook bugzilla di leggere le informazioni da un file usermap esterno. In quest'ultimo caso, potete memorizzare i dati del file usermap separatamente in (per esempio) un repository modificabile dall'utente. Questo vi permette di dare ai vostri utenti la possibilità di mantenere le proprie voci nella sezione usermap. Il file ~/.hgrc principale potrebbe somigliare a questo: # il normale file hgrc fa riferimento a un file di correlazioni esterno [bugzilla] usermap = /home/hg/repos/userdata/bugzilla-usermap.conf Mentre il file usermap a cui fa riferimento potrebbe somigliare a questo: # bugzilla-usermap.conf - all'interno di un repository Mercurial -[usermap] stephanie@example.com = steph +[usermap] +stefania@example.com = stef Configurare il testo che viene aggiunto a un bug - Potete configurare il testo che questo hook aggiunge come commento specificandolo sotto forma di un template Mercurial. Diverse voci del file ~/.hgrc (sempre nella sezione bugzilla) controllano questo comportamento. + Potete configurare il testo che questo hook aggiunge come commento specificandolo sotto forma di template Mercurial. Diverse voci del file ~/.hgrc (sempre nella sezione bugzilla) controllano questo comportamento. strip: il numero di parti iniziali da eliminare dal percorso di un repository per costruire un percorso parziale da usare in un URL. Per esempio, se i repository sul vostro server si trovano nella directory /home/hg/repos, e voi avete un repository il cui percorso è /home/hg/repos/app/tests, allora impostando strip a 4 otterrete il percorso parziale app/tests. L'hook renderà disponibile questo percorso parziale con il nome webroot durante l'espansione di un template. - template: il testo del template da usare. In aggiunta alle solite variabili relative ai changeset, questo template può usare hgweb (il valore dell'elemento di configurazione hgweb menzionato in precedenza) e webroot (il percorso costruito usando l'elemeno strip appena descritto). + template: il testo del template da usare. In aggiunta alle solite variabili relative ai changeset, questo template può usare hgweb (il valore dell'elemento di configurazione hgweb menzionato in precedenza) e webroot (il percorso costruito usando l'elemento strip appena descritto). - In più, potete aggiungere un elemento baseurl alla sezione web del vostro file ~/.hgrc. L'hook bugzilla lo renderà disponibile durante l'espansione di un template, come la stringa di base da usare nel costruire un URL che consentirà agli utenti di navigare da un commento Bugzilla verso un changeset correlato. Ecco un esempio di come usare questo elemento: + In più, potete aggiungere un elemento baseurl alla sezione web del vostro file ~/.hgrc. L'hook bugzilla lo renderà disponibile durante l'espansione di un template, come la stringa di base da usare nel costruire un URL che permetterà agli utenti di navigare da un commento Bugzilla verso un changeset correlato. Ecco un esempio di come usare questo elemento: [web] baseurl = http://hg.domain.com/ @@ -397,21 +398,21 @@ I problemi più comuni con la configurazione dell'hook bugzilla sono relativi all'esecuzione dello script processmail di Bugzilla e alla correlazione tra nomi utente Mercurial e nomi utente Bugzilla. - Se ricordate quanto detto nella , l'utente che esegue il processo Mercurial sul server è anche quello che eseguirà lo script processmail. Questo script talvolta chiederà a Bugzilla di scrivere sui file nella sua directory di configurazione, e di solito i file di configurazione di Bugzilla sono proprietà dell'utente che esegue il processo del vostro server web. + Se ricordate quanto detto nella , l'utente che esegue il processo Mercurial sul server è anche quello che eseguirà lo script processmail. Questo script talvolta chiederà a Bugzilla di modificare i file nella sua directory di configurazione, e di solito i file di configurazione di Bugzilla sono proprietà dell'utente che esegue il processo del vostro server web. Potete far eseguire processmail con un'identità utente appropriata tramite il comando sudo. Ecco una voce di esempio da un file sudoers. hg_user = (httpd_user) NOPASSWD: /var/www/html/bugzilla/processmail-wrapper %s Questo consente all'utente hg_user di eseguire il programma processmail-wrapper sotto l'identità dell'utente httpd_user. - Questa indirezione attraverso uno script che funge da involucro è necessaria, perché processmail si aspetta di venire eseguito con la propria directory corrente impostata al percorso di installazione di Bugzilla, ma non è possibile specificare questo vincolo in un file sudoers. Il contenuto dello script involucro è semplice: + Questa invocazione indiretta attraverso uno script che funge da involucro è necessaria, perché processmail si aspetta di venire eseguito con la propria directory corrente impostata al percorso di installazione di Bugzilla, ma non è possibile specificare questo vincolo in un file sudoers. Il contenuto dello script involucro è semplice: #!/bin/sh -cd `dirname $0` && ./processmail "$1" nobody@example.com +cd `dirname $0` && ./processmail "$1" nessuno@example.com Non sembra che l'indirizzo email passato a processmail abbia importanza. - Se la vostra usermap non è impostata correttamente, gli utenti vedranno un messaggio di errore stampato dall'hook bugzilla quando trasmetotno i cambiamenti al server. Il messaggio di errore somiglierà al seguente: - cannot find bugzilla user id for john.q.public@example.com - Questo significa che l'indirizzo email dell'utente Mercurial, john.q.public@example.com, non è un nome utente Bugizlla valido, né possiede una voce nella vostra usermap che lo metta in relazione con un nome utente Bugzilla valido. + Se la vostra sezione usermap non è impostata correttamente, gli utenti vedranno un messaggio di errore stampato dall'hook bugzilla al momento di trasmettere i cambiamenti al server. Il messaggio di errore somiglierà al seguente: + cannot find bugzilla user id for mario.rossi@example.com + Questo significa che l'indirizzo email dell'utente Mercurial, mario.rossi@example.com, non è un nome utente Bugzilla valido, né possiede una voce nella vostra sezione usermap che lo metta in relazione con un nome utente Bugzilla valido. @@ -419,35 +420,35 @@ <literal role="hg-ext">notify</literal>&emdash;inviare notifiche via email - Sebbene il server web predefinito di Mercurial fornisca i feed RSS dei cambiamenti per ogni repository, molte persone preferiscono ricevere notifiche dei cambiamenti via email. L'hook notify vi permette di inviare notifiche a un insieme di indirizzi email ogni volta che arrivano changeset a cui quelle persone sono interessate. + Sebbene il server web predefinito di Mercurial fornisca i feed RSS dei cambiamenti per ogni repository, molte persone preferiscono ricevere le notifiche dei cambiamenti via email. L'hook notify vi permette di inviare notifiche a un insieme di indirizzi email ogni volta che arrivano changeset a cui quelle persone sono interessate. Come l'hook bugzilla, anche l'hook notify è guidato da un template, in modo che possiate personalizzare i contenuti dei messaggi di notifica inviati. - Di default, l'hook notify include un diff di ogni changeset che spedisce; potete limitare le dimensioni del diff, oppure disattivare interamente questa funzionalità. È utile per consentire agli interessati di revisionare i cambiamenti immediatamente, piuttosto che obbligarli a cliccare per seguire un URL. + Di default, l'hook notify include un diff di ogni changeset che spedisce. Questa funzione vi permette di limitare le dimensioni del diff, oppure di disattivarle interamente, ma è utile per consentire agli interessati di revisionare i cambiamenti immediatamente piuttosto che obbligarli a cliccare per seguire un URL. Configurare l'hook <literal role="hg-ext">notify</literal> - Potete impostare l'hook notify per spedire un messaggio email per changeset in entrata, o uno per gruppo di changeset in entrata (tutti quelli che sono arrivati in una singola estrazione o trasmissione). + Potete impostare l'hook notify in modo che spedisca un messaggio email per ogni changeset in entrata, o uno per ogni gruppo di changeset in entrata (tutti quelli che sono arrivati in una singola estrazione o trasmissione). [hooks] -# spedisci una email per gruppo di cambiamenti +# spedisci un'email per gruppo di cambiamenti changegroup.notify = python:hgext.notify.hook -# spedisci una email per cambiamento +# spedisci un'email per cambiamento incoming.notify = python:hgext.notify.hook Le informazioni di configurazione per questo hook si trovano nella sezione notify del file ~/.hgrc. - test: di default, questo hook non spedisce alcuna email, ma stampa il messaggio che avrebbe inviato. Impostate questo elemento a false per consentire alle email di venire spedite. La ragione per cui la spedizione delle email è disabilitata di default è che ci vogliono diverse prove per configurare questa estensione esattamente come vorreste, e non starebbe bene #spam# gli interessati con un certo numero di notifiche guaste mentre correggete la vostra configurazione. + test: di default, questo hook non spedisce alcuna email, ma stampa il messaggio che avrebbe inviato. Impostate questo elemento a false per consentire la spedizione delle email. La ragione per cui la spedizione delle email è disabilitata di default è che ci vogliono diverse prove per configurare questa estensione esattamente come vorreste, e non starebbe bene infastidire gli interessati con un certo numero di notifiche guaste mentre correggete la vostra configurazione. config: il percorso di un file di configurazione che contiene le informazioni di sottoscrizione. Questo viene tenuto separato dal file ~/.hgrc principale in modo che possiate mantenerlo in un proprio repository. Le persone possono poi clonare quel repository, aggiornare le proprie sottoscrizioni e trasmettere i cambiamenti al vostro server. - strip: il numero di parti iniziali da eliminare dal percorso di un repository quando state decidendo se è possibile sottoscriversi alle notifiche di un repository. Per esempio, se i repository sul vostro server si trovano in /home/hg/repos, e notify sta considerando un repository chiamato /home/hg/repos/shared/test, impostare strip a 4 farà in modo che notify restringa il percorso da considerare a shared/test e cerchi le sottoscrizioni corrispondenti a esso. - - template: il testo del template da usare quando i messaggi vengono iniviati. Questo specifica i contenuti sia delle intestazioni che del corpo del messaggio. - - maxdiff: il massimo numero di righe di dati di diff da aggiungere alla fine di un messaggio. Se un diff è più lungo di questo limite, viene troncato. Di default, questo è impostato a 300. Impostate questo a 0 per omettere i diff dalle email di notifica. - - sources: una lista di fonti di changeset da considerare. Questo vi permette di limitare notify in modo che spedisca email riguardanti solo particolari utenti remoti che hanno trasmesso modifiche a questo repository attraverso un particolare sevrer, per esempio. Leggete la per sapere quali fonti potete specificare qui. + strip: il numero di parti iniziali da eliminare dal percorso di un repository quando state decidendo se è possibile sottoscriversi alle notifiche per un repository. Per esempio, se i repository sul vostro server si trovano in /home/hg/repos, e notify sta considerando un repository chiamato /home/hg/repos/shared/test, impostare strip a 4 farà in modo che notify restringa il percorso da considerare a shared/test e associ le sottoscrizioni a questo percorso. + + template: il testo del template da usare per inviare i messaggi. Questo specifica i contenuti sia delle intestazioni che del corpo del messaggio. + + maxdiff: il massimo numero di righe di dati di diff da aggiungere alla fine di un messaggio. Se un diff è più lungo di questo limite, viene troncato. Di default, questo valore è impostato a 300. Impostate questo valore a 0 per omettere i diff dalle email di notifica. + + sources: una lista di modalità di provenienza dei changeset da considerare. Questo vi permette di limitare notify in modo che spedisca email riguardanti solo utenti remoti che hanno trasmesso modifiche a questo repository attraverso un server, per esempio. Leggete la per sapere quali modalità potete specificare qui. Se impostate l'elemento baseurl nella sezione web, potete usarlo in un template, dove sarà disponibile con il nome webroot. @@ -473,64 +474,64 @@ Informazioni per gli implementatori di hook - Esecuzione degli hook #in-process# - - Un hook #in-process# viene invocato con argomenti della forma seguente: + Esecuzione degli hook interni + + Un hook interno viene invocato con argomenti della forma seguente: def myhook(ui, repo, **kwargs): pass - Il parametro ui è un oggetto di tipo ui. Il parametro repo è un oggetto di tipo localrepository. I nomi e i valori dei parametri **kwargs dipendono dall'hook coinvolto, ma hanno le seguenti caratteristiche comuni: - - Se un parametro si chiama node o parentN, conterrà un identificatore esadecimale di changeset. La stringa vuota viene usata per rappresentare l'identificatore di changeset nullo invece di una stringa di zero. + Il parametro ui è un oggetto di tipo mercurial.ui.ui. Il parametro repo è un oggetto di tipo mercurial.localrepo.localrepository. I nomi e i valori dei parametri **kwargs dipendono dall'hook coinvolto, ma hanno le seguenti caratteristiche comuni: + + Se un parametro si chiama node o parentN, conterrà un identificatore esadecimale di changeset. La stringa vuota viene usata per rappresentare l'identificatore di changeset nullo invece di una stringa di zeri. Se un parametro si chiama url, conterrà l'URL di un repository remoto, nel caso possa essere determinato. I parametri con valore booleano vengono rappresentati come oggetti Python di tipo bool. - Un hook #in-process# viene invocato senza cambiare la directory di lavoro del processo (a differenza degli hook esterni, che vengono eseguiti nella radice del repository) L'hook non deve mai cambiare questa directory, altrimenti causerà il fallimento di tutte le proprie invocazioni alla API di Mercurial. + Un hook interno viene invocato senza cambiare la directory di lavoro del processo (a differenza degli hook esterni, che vengono eseguiti nella radice del repository). L'hook non deve mai cambiare questa directory, altrimenti causerà il fallimento di tutte le proprie invocazioni alla API di Mercurial. Se un hook restituisce il valore booleano falso, si considera terminato con successo. Se restituisce il valore booleano vero oppure solleva un'eccezione, si considera fallito. Un modo utile di pensare a questa convenzione di esecuzione è dimmi se hai fallito. - Notate che gli identificatori di changeset sono passati agli hook Python sotto forma di stringhe esadecimali, non degli hash binari che la API Mercurial usa normalmente. Per convertire un hash da esadecimale a binario, usate la funzione bin. + Notate che gli identificatori di changeset vengono passati agli hook Python sotto forma di stringhe esadecimali, non degli hash binari che la API Mercurial usa normalmente. Per convertire un hash da esadecimale a binario, usate la funzione bin. Esecuzione degli hook esterni - Un hook esterno viene passato alla shell dell'utente che sta eseguendo Mercurial. Le funzionalità di quella shell, come la sostituzione delle variabili e la redirezione dei comandi, sono disponibili. L'hook viene eseguito nella directory radice del repository (a differenza degli hook #in-process#, che vengono eseguiti nella stessa directory in cui è stato eseguito Mercurial). - - I parametri di hook sono passati all'hook sotto forma di variabili d'ambiente. Il nome di ogni variabile d'ambiente viene convertito in maiuscolo e preceduto dalla stringa HG_. Per esempio, se ilnome di un parametro è node, il nome della variabile d'ambiente che rappresenta quel parametro sarà HG_NODE. - - Un parametro booleano è rappresentato come la stringa 1 se è vero, o 0 se è falso. Se una variabile d'ambiente è chiamata HG_NODE, HG_PARENT1, o HG_PARENT2, conterrà un identificatore di changeset rappresentato come stringa esadecimale. La stringa vuota viene usate per rappresentare l'identificatore di changeset nullo invece di una stringa di zeri. Se una variabile d'ambiente è chiamata HG_URL, conterrà l'URL di un repository remoto, nel caso possa essere determinato. - - Se un hook termina con uno stato uguale a zero, si considera terminato con successo. Se terina con uno stato diverso da zero, si condiera fallito. + Un hook esterno viene passato alla shell dell'utente che sta eseguendo Mercurial e può disporre delle funzionalità di quella shell, come la sostituzione delle variabili e la redirezione dei comandi. L'hook viene eseguito nella directory radice del repository (a differenza degli hook interni, che vengono eseguiti nella stessa directory in cui è stato eseguito Mercurial). + + I parametri di hook sono passati all'hook sotto forma di variabili d'ambiente. Il nome di ogni variabile d'ambiente viene convertito in maiuscolo e fatto precedere dalla stringa HG_. Per esempio, se il nome di un parametro è node, il nome della variabile d'ambiente che rappresenta quel parametro sarà HG_NODE. + + Un parametro booleano è rappresentato come la stringa 1 se è vero o 0 se è falso. Se una variabile d'ambiente è chiamata HG_NODE, HG_PARENT1, o HG_PARENT2, conterrà un identificatore di changeset rappresentato come una stringa esadecimale. La stringa vuota viene usata per rappresentare l'identificatore di changeset nullo invece di una stringa di zeri. Se una variabile d'ambiente è chiamata HG_URL, conterrà l'URL di un repository remoto, nel caso possa essere determinato. + + Se un hook termina con uno stato uguale a zero, si considera terminato con successo. Se termina con uno stato diverso da zero, si considera fallito. Scoprire da dove vengono i changeset - Un hook che coinvolge il trasferimento di changeset tra un repository locale e un altro potrebbe essere in grado di trovare informazioni sul lato opposto. Mercurial sa come i cambiamenti vengono trasferiti e in molti casi da o a dove vengono trasferiti. + Un hook che coinvolge il trasferimento di changeset tra un repository locale e un altro potrebbe essere in grado di trovare informazioni sul lato opposto. Mercurial conosce il modo in cui i cambiamenti vengono trasferiti e in molti casi conosce anche l'ubicazione del luogo da cui o verso cui vengono trasferiti. Le fonti dei changeset - Mercurial dirà a un hook quali mezzi vengono o sono stati usati per trasferire i changeset tra repository. Questa informazione viene fornita da Mercurial in un parametro Python chiamato source o in una variabile d'ambiente chiamata HG_SOURCE. + Mercurial dirà a un hook quali sono, o sono stati, i mezzi usati per trasferire i changeset tra repository, fornendo questa informazione in un parametro Python chiamato source o in una variabile d'ambiente chiamata HG_SOURCE. - serve: i changeset sono trasferiti da o a un repository remoto via HTTP o SSH. + serve: i changeset sono trasferiti da o verso un repository remoto via HTTP o SSH. pull: i changeset sono trasferiti attraverso un'estrazione da un repository a un altro. push: i changeset sono trasferiti attraverso una trasmissione da un repository a un altro. - bundle: i changeset sono trasferiti da o verso un #bundle#. + bundle: i changeset sono trasferiti da o verso un bundle. La destinazione dei cambiamenti&emdash;gli URL dei repository remoti - Quando è possibile, Mercurial dirà a un hook l'ubicazione del lato opposto di un'attività che trasferisce i dati dei changeset tra repository. Questa informazione viene fornita da Mercurial in un parametro Python chiamato url o in una variabile d'ambiente chiamata HG_URL. + Quando è possibile, Mercurial dirà a un hook l'ubicazione del lato opposto di un'attività che trasferisce i dati dei changeset tra repository, fornendo questa informazione in un parametro Python chiamato url o in una variabile d'ambiente chiamata HG_URL. Questa informazione non è sempre nota. Se un hook viene invocato in un repository condiviso via HTTP o SSH, Mercurial non è in grado di dire dove si trova il repository, ma potrebbe sapere da dove si sta connettendo il client. In questi casi, l'URL prenderà una delle seguenti forme: @@ -538,7 +539,7 @@ remote:http:1.2.3.4&emdash;client HTTP remoto, all'indirizzo IP 1.2.3.4. Se il client sta usando SSL, questo URL sarà nella forma remote:https:1.2.3.4. - Empty&emdash;Mercurial non è riuscito a scoprire nessuna informazione sul client remoto. + Vuoto&emdash;Mercurial non è riuscito a scoprire nessuna informazione sul client remoto. @@ -549,9 +550,9 @@ <literal role="hook">changegroup</literal>&emdash;dopo l'aggiunta di changeset remoti - Questo hook viene eseguito dopo che un gruppo di changeset preesistenti è stato aggiunto al repository, per esempio tramite hg pull o hg unbundle. Questo hook viene eseguito una volta per ogni operazione che aggiunge uno o più changeset, a differenza dell'hook incoming, che viene eseguito una volta per changeset a prescindere dal fatto che il changeset sia arrivato in un gruppo. - - Alcuni possibili usi di questo hook includono far partire un assemblaggio o un collaudo automatico dei changeset aggiunti, l'aggiornamento di un database di bug, o la notifica che un repository contiene nuovi cambiamenti. + Questo hook viene eseguito dopo che un gruppo di changeset preesistenti è stato aggiunto al repository, per esempio tramite hg pull o hg unbundle. Questo hook viene eseguito una volta per ogni operazione che aggiunge uno o più changeset, a differenza dell'hook incoming, che viene eseguito una volta per ogni changeset a prescindere dal fatto che il changeset sia arrivato in un gruppo. + + Alcuni possibili usi di questo hook includono l'avvio di un assemblaggio o di un collaudo automatico dei changeset aggiunti, l'aggiornamento di un database di bug, o la notifica che un repository contiene nuovi cambiamenti. I parametri di questo hook sono i seguenti. @@ -562,7 +563,7 @@ url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per maggiori informazioni. - Si vedano anche gli hook: incoming (), prechangegroup (), pretxnchangegroup () + Si vedano anche gli hook incoming (), prechangegroup () e pretxnchangegroup (). @@ -579,7 +580,7 @@ parent2: un identificatore di changeset. L'identificatore di changeset del secondo genitore del changeset appena inserito. - Si vedano anche gli hook: precommit (), pretxncommit () + Si vedano anche gli hook precommit () e pretxncommit (). @@ -587,7 +588,7 @@ Questo hook viene eseguito dopo che un changeset preesistente è stato aggiunto al repository, per esempio attraverso l'invocazione di hg push. Se un gruppo di changeset è stato aggiunto in una singola operazione, questo hook viene eseguito una volta per ogni changeset aggiunto. - Potete usare questo hook per gli stessi scopi dell'hook changegroup hook (); talvolta è semplicemente più conveniente eseguire un hook per ogni gruppo di changeset, mentre altre volte è più comodo eseguirlo per ogni changeset. + Potete usare questo hook per gli stessi scopi dell'hook changegroup (). A volte è semplicemente più comodo eseguire un hook per ogni gruppo di changeset, mentre altre volte è più conveniente eseguirlo per ogni changeset. I parametri di questo hook sono i seguenti. @@ -598,7 +599,7 @@ url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per maggiori informazioni. - Si vedano anche gli hook: changegroup (), prechangegroup (), pretxnchangegroup () + Si vedano anche gli hook changegroup (), prechangegroup () e pretxnchangegroup (). @@ -606,18 +607,18 @@ Questo hook viene eseguito dopo che un gruppo di changeset è stato propagato al di fuori di questo repository, per esempio attraverso l'invocazione dei comandi hg push o hg bundle. - Questo hook può essere impiegato per notificare gli amministratori che alcuni cambiamenti sono stati estratti. + Un possibile impiego di questo hook è quello di notificare gli amministratori di un repository che alcuni cambiamenti sono stati estratti. I parametri di questo hook sono i seguenti. - node: un identificatore di changeset. L'identificatore del primo changeset del gruppo che è stato mandato. + node: un identificatore di changeset. L'identificatore del primo changeset del gruppo che è stato propagato. source: una stringa. La fonte dell'operazione (si veda la ). Se un client remoto ha estratto i cambiamenti da questo repository, il valore di source sarà serve. Se il client che ha ottenuto i cambiamenti di questo repository era locale, il valore di source sarà bundle, pull, o push, a seconda dell'operazione effettuata dal client. url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per maggiori informazioni. - Si vedano anche gli hook: preoutgoing () + Si veda anche l'hook preoutgoing (). @@ -627,7 +628,7 @@ Questo hook non possiede alcuna informazione sui changeset che verranno aggiunti, perché viene eseguito prima che la trasmissione di quei changeset possa cominciare. Se questo hook fallisce, i changeset non verranno trasmessi. - Questo hook si può utilizzare per evitare che i cambiamenti vengano aggiunti a un repository. Per esempio, potreste usarlo per congelare temporaneamente o permanentemente un ramo ospitato su un server in modo che gli utenti non possano trasmettervi alcuna modifica, consentendo comunque a un amministratore locale di modificare il repository. + Un possibile impiego di questo hook è quello di evitare che i cambiamenti vengano aggiunti a un repository. Per esempio, potreste usarlo per congelare temporaneamente o permanentemente un ramo ospitato su un server in modo che gli utenti non possano trasmettervi alcuna modifica, consentendo comunque a un amministratore locale di modificare il repository. I parametri di questo hook sono i seguenti. @@ -636,15 +637,15 @@ url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per maggiori informazioni. - Si vedano anche gli hook: changegroup (), incoming (), pretxnchangegroup () + Si vedano anche gli hook changegroup (), incoming () e pretxnchangegroup (). <literal role="hook">precommit</literal>&emdash;prima di cominciare l'inserimento di un changeset - Questo hook viene eseguito prima che Mercurial cominci l'inserimento di un nuovo changeset. Viene eseguito prima che Mercurial conosca i metadati dell'inserimento, come i file da inserire, il messaggio e la data di commit. - - Questo hook può essere usato per disabilitare la possibilità di inserire nuovi changeset, pur permettendo la trasmissione di changeset in entrata. Un'altra possibilità è quella di eseguire l'assemblaggio o il collaudo e permettere all'inserimento di cominciare solo se l'assemblaggio o il collaudo hanno successo. + Questo hook viene eseguito prima che Mercurial cominci l'inserimento di un nuovo changeset, quindi prima che Mercurial conosca i metadati dell'inserimento come i file da inserire, il messaggio e la data di commit. + + Questo hook può essere usato per disabilitare la possibilità di inserire nuovi changeset, pur permettendo la trasmissione di changeset in entrata. Un'altra possibilità è quella di eseguire l'assemblaggio o il collaudo e consentire l'avvio dell'inserimento solo se l'assemblaggio o il collaudo hanno successo. I parametri di questo hook sono i seguenti. @@ -654,7 +655,7 @@ Se l'inserimento procede, i genitori della directory di lavoro diventeranno i genitori del nuovo changeset. - Si vedano anche gli hook: commit (), pretxncommit () + Si vedano anche gli hook commit () e pretxncommit (). @@ -662,22 +663,22 @@ Questo hook viene invocato prima che Mercurial conosca le identità dei changeset da trasmettere. - Questo hook può essere usato per evitare che i changeset vengano trasmessi a un altro repository. + Un possibile impiego di questo hook è quello di evitare che i changeset vengano trasmessi a un altro repository. I parametri di questo hook sono i seguenti. - source: una stringa. La fonte dell'operazione che sta tentando di ottenere i cambiamenti da questo repository (si veda la ). Leggete la documentazione del parametro source per l'hook outgoing nella per i possibili valori di questo parametro. + source: una stringa. La fonte dell'operazione che sta tentando di ottenere i cambiamenti da questo repository (si veda la ). Leggete la documentazione del parametro source dell'hook outgoing nella per conoscere i possibili valori di questo parametro. url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per maggiori informazioni. - Si vedano anche gli hook: outgoing () + Si veda anche l'hook outgoing (). <literal role="hook">pretag</literal>&emdash;prima di etichettare un changeset - Questo hook di controllo viene eseguito prima della creazione di un etichetta. Se l'hook ha successo, la creazione dell'etichetta procede. Se l'hook fallisce, l'etichetta non viene creata. + Questo hook di controllo viene eseguito prima della creazione di un'etichetta. Se l'hook ha successo, la creazione dell'etichetta procede. Se l'hook fallisce, l'etichetta non viene creata. I parametri di questo hook sono i seguenti. @@ -688,9 +689,9 @@ tag: una stringa. Il nome dell'etichetta da creare. - Se l'etichetta da creare è soggetta a controllo di revisione, anche gli hook precommit e pretxncommit ( e ) verranno eseguiti. - - Si vedano anche gli hook: tag () + Se l'etichetta da creare è soggetta a controllo di revisione, verranno eseguiti anche gli hook precommit e pretxncommit ( e ). + + Si veda anche l'hook tag (). @@ -699,11 +700,11 @@ Questo hook di controllo viene eseguito prima di completare la transazione che gestisce l'aggiunta di un gruppo di nuovi changeset provenienti dall'esterno del repository. Se l'hook ha successo, la transazione viene completata e tutti i changeset diventano permanenti all'interno di questo repository. Se l'hook fallisce, la transazione viene abortita e i dati relativi ai changeset vengono cancellati. - Questo hook può accedere ai metadati associati con i changeset quasi aggiunti, ma dovrebbe evitare di modificarli in maniera permanente. L'hook deve anche evitare di modificare la directory di lavoro. - - Mentre questo hook è in esecuzione, se altri processi Mercurial accedono a questo repository, saranno in grado di vedere i changeset quasi aggiunti come se fossero permanenti. Questo potrebbe provocare delle condizioni di corsa critica se non eseguite i passi necessari per evitarle. - - Quesro hook può essere usato per esaminare automaticamente un gruppo di changeset. Se l'hook fallisce, tutti i changeset vengono respinti quando la transazione viene abortita. + Questo hook può accedere ai metadati associati ai changeset in procinto di essere aggiunti, ma dovrebbe evitare di modificarli in maniera permanente. L'hook deve anche evitare di modificare la directory di lavoro. + + Se altri processi Mercurial accedono a questo repository mentre questo hook è in esecuzione, saranno in grado di vedere i changeset quasi aggiunti come se fossero permanenti. Questo potrebbe portare a condizioni di corsa critica se non eseguite i passi necessari per evitarle. + + Questo hook può essere usato per esaminare automaticamente un gruppo di changeset. Se l'hook fallisce, tutti i changeset vengono respinti quando la transazione viene abortita. I parametri di questo hook sono i seguenti. @@ -711,10 +712,10 @@ source: una stringa. La fonte di questi cambiamenti. Si veda la per i dettagli. - url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per magggiori informazioni. - - - Si vedano anche gli hook: changegroup (), incoming (), prechangegroup () + url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per maggiori informazioni. + + + Si vedano anche gli hook changegroup (), incoming () e prechangegroup (). @@ -722,27 +723,27 @@ Questo hook di controllo viene eseguito prima di completare la transazione che gestisce un nuovo inserimento. Se l'hook ha successo, la transazione viene completata e il changeset diventa permanente all'interno di questo repository. Se l'hook fallisce, la transazione viene abortita e i dati dell'inserimento vengono cancellati. - Questo hook può accedere ai metadati associati con il changeset quasi inserito, ma dovrebbe evitare di modificarli in maniera permanente. L'hook deve anche evitare di modificare la directory di lavoro. - - Mentre questo hook è in esecuzione, se altri processi Mercurial accedono a questo repository, saranno in grado di vedere i changeset quasi aggiunti come se fossero permanenti. Questo potrebbe provocare delle condizioni di corsa critica se non eseguite i passi necessari per evitarle. + Questo hook può accedere ai metadati associati al changeset in procinto di essere inserito, ma dovrebbe evitare di modificarli in maniera permanente. L'hook deve anche evitare di modificare la directory di lavoro. + + Se altri processi Mercurial accedono a questo repository mentre questo hook è in esecuzione, saranno in grado di vedere i changeset quasi aggiunti come se fossero permanenti. Questo potrebbe portare a condizioni di corsa critica se non eseguite i passi necessari per evitarle. I parametri di questo hook sono i seguenti. - node: un identificatore di changeset. L'identificatore del changeset appena inserito. - - parent1: un identificatore di changeset. L'identificatore di changeset del primo genitore del changeset appena inserito. - - parent2: un identificatore di changeset. L'identificatore di changeset del secondo genitore del changeset appena inserito. - - - Si vedano anche gli hook: precommit () + node: un identificatore di changeset. L'identificatore del changeset sul punto di essere inserito. + + parent1: un identificatore di changeset. L'identificatore di changeset del primo genitore del changeset sul punto di essere inserito. + + parent2: un identificatore di changeset. L'identificatore di changeset del secondo genitore del changeset sul punto di essere inserito. + + + Si veda anche l'hook precommit (). <literal role="hook">preupdate</literal>&emdash;prima di eseguire un aggiornamento o un'unione nella directory di lavoro - Questo hook viene eseguito prima di cominciare un aggiornamento o un'unione nella directory di lavoro. Viene eseguito solo se i normali controlli effettuati da Mercurial prima di un aggiornamento determinano che l'aggiornamento o l'unione possono procedere. Se l'hook ha successo, l'aggiornamento o l'unione possono procedere; se fallisce, l'aggiornameno o l'unione non vengono cominciati. + Questo hook viene eseguito prima di cominciare un aggiornamento o un'unione nella directory di lavoro. Viene eseguito solo se i normali controlli effettuati da Mercurial prima di un aggiornamento determinano che l'aggiornamento o l'unione possono procedere. Se l'hook ha successo, l'aggiornamento o l'unione possono procedere, ma se fallisce, l'aggiornameno o l'unione non vengono cominciati. I parametri di questo hook sono i seguenti. @@ -751,7 +752,7 @@ parent2: un identificatore di changeset. Il suo valore viene impostato solo se si sta eseguendo un'unione. Contiene l'identificatore della revisione con cui la directory di lavoro viene unita. - Si vedano anche gli hook: update () + Si veda anche l'hook update (). @@ -770,14 +771,15 @@ Se l'etichetta creata è soggetta a controllo di revisione, l'hook commit () verrà eseguito prima di questo hook. - Si vedano anche gli hook: pretag () + Si veda anche l'hook pretag (). <literal role="hook">update</literal>&emdash;dopo aver eseguito un aggiornamento o un'unione nella directory di lavoro - Questo hook viene eseguito dopo il completamento di un aggiornamento o di un'unione nella directory di lavoro. Dato che un'unione può fallire (se il comando esterno hgmerge non è in grado di risolvere i conflitti in un file), questo hook comunica se l'aggiornamento o l'unione sono stati completati in maniera pulita. - + Questo hook viene eseguito dopo il completamento di un aggiornamento o di un'unione nella directory di lavoro. Dato che un'unione può fallire (nel caso il comando esterno hgmerge non sia in grado di risolvere i conflitti in un file), questo hook comunica se l'aggiornamento o l'unione sono stati completati in maniera pulita. + + I parametri di questo hook sono i seguenti. error: un booleano. Indica se l'aggiornamento o l'unione sono stati completati con successo. @@ -786,7 +788,7 @@ parent2: un identificatore di changeset. Il suo valore viene impostato solo se è stata eseguita un'unione. Contiene l'identificatore della revisione con cui la directory di lavoro è stata unita. - Si vedano anche gli hook: preupdate () + Si veda anche l'hook preupdate ().