# HG changeset patch
# User gpiancastelli
# Date 1250886584 -7200
# Node ID 7252e7b7f07d8794bb9be84c90187330ac97d241
# Parent 0a49072e8c7fda403cb90b7b2359f63acc2aac35
Final editing for chapters 8-11.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/ch08-branch.xml
--- a/it/ch08-branch.xml Fri Aug 21 21:42:22 2009 +0200
+++ b/it/ch08-branch.xml Fri Aug 21 22:29:44 2009 +0200
@@ -49,7 +49,7 @@
Non c'è alcun limite al numero di etichette che potete avere in un repository, o al numero di etichette che una singola revisione può avere. Nella pratica, non è una grande idea averne troppe (un numero che varierà da progetto a progetto), semplicemente perché le etichette sono pensate per aiutarvi a rintracciare le revisioni: se avete molte etichette, la comodità di usarle per identificare le revisioni diminuisce rapidamente.
- Per esempio, se il vostro progetto definisce nuove milestone con una frequenza di alcuni giorni, è perfettamente ragionevole dotare ognuna di un'etichetta. Ma se avete un sistema di assemblaggio continuo che si assicura di poter assemblare ogni revisione in modo pulito, introdurreste troppo rumore etichettando ogni assemblaggio pulito. Invece, potreste etichettare gli assemblaggi falliti (supponendo che siano rari!) o semplicemente evitare di usare le etichette per tenere traccia degli assemblaggi.
+ Per esempio, se il vostro progetto definisce nuove milestone con una frequenza di alcuni giorni, è perfettamente ragionevole dotare ognuna di un'etichetta. Ma se avete un sistema di assemblaggio continuo che si assicura di poter assemblare ogni revisione senza problemi, introdurreste troppo rumore etichettando ogni assemblaggio pulito. Invece, potreste etichettare gli assemblaggi falliti (supponendo che siano rari!) o semplicemente evitare di usare le etichette per tenere traccia degli assemblaggi.Se volete rimuovere un'etichetta che non volete più, usate hg tag --remove.
@@ -72,7 +72,7 @@
Se state risolvendo un conflitto nel file .hgtags durante un'unione, c'è una particolarità da ricordare quando modificate il file .hgtags: quando Mercurial sta analizzando le etichette in un repository, non legge mai la copia di lavoro del file .hgtags, ma legge la revisione del file registrata più recentemente.
- Una sfortunata conseguenza di questo comportamento è che non potete verificare la correttezza del file .hgtags risultato dall'unione se non dopo aver effettuato il commit di un cambiamento. Quindi, se vi trovate a risolvere un conflitto su .hgtags durante un'unione, assicuratevi di eseguire hg tags dopo aver effettuato il commit. Se il comando trova un errore nel file .hgtags, vi indicherà la posizione dell'errore, che potrete dunque correggere, registrando la correzione nel repository. Dovreste poi eseguire ancora hg tags, giusto per essere sicuri che la vostra correzione sia valida.
+ Una sfortunata conseguenza di questo comportamento è che non potete verificare la correttezza del file .hgtags risultato dall'unione se non dopo aver effettuato il commit di un cambiamento. Quindi, se vi trovate a risolvere un conflitto su .hgtags durante un'unione, assicuratevi di eseguire hg tags dopo aver effettuato il commit. Se il comando trova un errore nel file .hgtags, vi indicherà la posizione dell'errore, che potrete dunque correggere registrando la correzione nel repository. Dovreste poi eseguire ancora hg tags, giusto per essere sicuri che la vostra correzione sia valida.
@@ -115,7 +115,7 @@
&interaction.branch-repo.tag;
- Potete quindi clonare un nuovo repository condiviso mioprogetto-1.0.1 da quella etichetta.
+ Potete quindi clonare un nuovo repository condiviso mioprogetto-1.0.1 a partire da quella etichetta.
&interaction.branch-repo.clone;
diff -r 0a49072e8c7f -r 7252e7b7f07d it/ch09-undo.xml
--- a/it/ch09-undo.xml Fri Aug 21 21:42:22 2009 +0200
+++ b/it/ch09-undo.xml Fri Aug 21 22:29:44 2009 +0200
@@ -42,7 +42,7 @@
È pratica comune usare Mercurial mantenendo in repository differenti i rami di sviluppo separati di un progetto. Il vostro gruppo di sviluppo potrebbe avere un repository condiviso per la release 0.9 del vostro progetto e un altro, contenente cambiamenti differenti, per la release 1.0.
- In questa situazione, potete immaginare che pasticcio accadrebbe se aveste un repository 0.9 locale e vi propagaste accidentalmente i cambiamenti dal repository 1.0 condiviso. Nel caso peggiore, potreste non fare abbastanza attenzione e trasmettere quei cambiamenti nell'albero 0.9 condiviso, confondendo tutti gli altri sviluppatori (ma non preoccupatevi, ritorneremo a questo orribile scenario più avanti). Tuttavia, è più probabile che notiate immediatamente l'errore, perché Mercurial vi mostrerà l'URL da cui sta estraendo i cambiamenti, o perché vedrete Mercurial propagare un numero sospettosamente alto di cambiamenti nel repository.
+ In questa situazione, potete immaginare che pasticcio accadrebbe se aveste un repository 0.9 locale e vi propagaste accidentalmente i cambiamenti dal repository 1.0 condiviso. Nel caso peggiore, potreste non fare abbastanza attenzione e trasmettere quei cambiamenti nell'albero 0.9 condiviso, disorientando tutti gli altri sviluppatori (ma non preoccupatevi, ritorneremo a questo orribile scenario più avanti). Tuttavia, è più probabile che notiate immediatamente l'errore, perché Mercurial vi mostrerà l'URL da cui sta estraendo i cambiamenti, o perché vedrete Mercurial propagare un numero sospettosamente alto di cambiamenti nel repository.Il comando hg rollback cancellerà scrupolosamente tutti i changeset che avete appena estratto. Mercurial raggruppa tutti i cambiamenti provenienti da un'invocazione di hg pull in una singola transazione, quindi un'unica invocazione di hg rollback è tutto quello che vi serve per annullare questo errore.
@@ -64,7 +64,7 @@
&interaction.rollback.twice;
- Una volta che avete abortito una transazione in un repository, non potete effettuare un'altra cancellazione in quel repository fino a quando non avete eseguito un nuovo inserimento o una nuova estrazione.
+ Una volta che avete abortito una transazione in un repository, non potete effettuare un'altra volta questa operazione in quel repository fino a quando non avete eseguito un nuovo inserimento o una nuova estrazione.
@@ -271,7 +271,7 @@
Esegue il commit del risultato come un nuovo changeset che ha backout come genitore.
- Se specificate l'opzione sulla riga di comando, esegue un'unione con orig e inserisce i risultati dell'unione nel repository.
+ Se specificate l'opzione sulla riga di comando, esegue un'unione con orig ma non inserisce i risultati dell'unione nel repository.In alternativa, sarebbe possibile implementare hg backout utilizzando hg export per esportare il changeset da ritirare sotto forma di diff e poi impiegando l'opzione del comando patch per invertire l'effetto del cambiamento senza gingillarsi con la directory di lavoro. Questo procedimento sembra molto più semplice, ma non funzionerebbe affatto altrettanto bene.
@@ -412,9 +412,9 @@
Ora introdurremo un po' di terminologia, giusto per chiarire quali sono le parti del processo di ricerca di cui siete responsabili voi e quali sono quelle di cui è responsabile Mercurial. Un test è qualcosa che voi eseguite quando hg bisect sceglie un changeset. Una sonda è ciò che hg bisect esegue per dirvi se una revisione è buona. Infine, useremo la parola bisezione per intendere la ricerca tramite il comando hg bisect.
- Un modo semplice per automatizzare il processo di ricerca sarebbe quello di collaudare semplicemente ogni changeset. Tuttavia, questo approccio è scarsamente scalabile. Se ci volessero dieci minuti per collaudare un singolo changeset e il vostro repository contenesse 10.000 changeset, l'approccio completo impiegherebbe una media di 35 giorni per trovare il changeset che ha introdotto un bug. Anche se sapeste che il bug è stato introdotto in uno degli ultimi 500 changeset e limitaste la ricerca a quelli, dovrebbero trascorrere più di 40 ore per trovare il changeset che ha introdotto il vostro bug.
-
- Il comando hg bisect invece usa la propria conoscenza della forma della cronologia delle revisioni del vostro progetto per effettuare una ricerca in tempo proporzionale al logaritmo del numero dei changeset da controllare (il tipo di ricerca che esegue viene chiamata ricerca dicotomica). Con questo approccio, la ricerca attraverso 10.000 changeset impiegherà meno di 3 ore, anche a 10 minuti per ogni test (la ricerca richiederà circa 14 test). Limitate la vostra ricerca agli ultimi cento changeset e il tempo impiegato sarà solo circa un'ora (approssimativamente sette test).
+ Un modo semplice per automatizzare il processo di ricerca sarebbe quello di collaudare semplicemente tutti i changeset. Tuttavia, questo approccio è scarsamente scalabile. Se ci volessero dieci minuti per collaudare un singolo changeset e il vostro repository contenesse 10.000 changeset, l'approccio completo impiegherebbe una media di 35 giorni per trovare il changeset che ha introdotto un bug. Anche se sapeste che il bug è stato introdotto in uno degli ultimi 500 changeset e limitaste la ricerca a quelli, dovrebbero trascorrere più di 40 ore per trovare il changeset che ha introdotto il vostro bug.
+
+ Il comando hg bisect invece usa la propria conoscenza della forma della cronologia delle revisioni del vostro progetto per effettuare una ricerca in tempo proporzionale al logaritmo del numero dei changeset da controllare (il tipo di ricerca che esegue viene chiamata ricerca dicotomica). Con questo approccio, la ricerca attraverso 10.000 changeset impiegherà meno di 3 ore, anche a 10 minuti per test (la ricerca richiederà circa 14 test). Limitate la vostra ricerca agli ultimi cento changeset e il tempo impiegato sarà solo circa un'ora (approssimativamente sette test).Il comando hg bisect è consapevole della natura ramificata della cronologia delle revisioni di un progetto Mercurial, quindi non ha problemi a trattare con rami, unioni, o molteplici teste in un repository. Opera in maniera così efficiente perché è in grado di potare interi rami di cronologia con una singola sonda.
@@ -510,7 +510,7 @@
Fornite informazioni consistenti
- Il comando hg bisect vi richiede di indicare correttamente il risultato di ogni test che eseguite. Se gli dite che un test è fallito quando in realtà ha avuto successo, il comando potrebbe essere in grado di scoprire l'inconsistenza. Se riesce a identificare un'incosistenza nei vostri resoconti, vi dirà che un particolare changeset è sia funzionante che guasto. Tuttavia, non è in grado di farlo perfettamente ed è ugualmente probabile che vi restituisca il changeset sbagliato come causa del bug.
+ Il comando hg bisect vi richiede di indicare correttamente il risultato di ogni test che eseguite. Se gli dite che un test è fallito quando in realtà ha avuto successo, il comando potrebbe essere in grado di scoprire l'inconsistenza. Se riesce a identificare un'inconsistenza nei vostri resoconti, vi dirà che un particolare changeset è sia funzionante che guasto. Tuttavia, non è in grado di farlo perfettamente ed è ugualmente probabile che vi restituisca il changeset sbagliato come causa del bug.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/ch10-hook.xml
--- a/it/ch10-hook.xml Fri Aug 21 21:42:22 2009 +0200
+++ b/it/ch10-hook.xml Fri Aug 21 22:29:44 2009 +0200
@@ -4,7 +4,7 @@
Mercurial vi offre un potente meccanismo per effettuare azioni automatiche in risposta agli eventi che accadono in un repository. In alcuni casi, potete persino controllare la risposta di Mercurial a questi eventi.
- Il nome che Mercurial usa per indicare una di queste azioni è hook (letteralmente, gancio). Gli hook vengono chiamati trigger (letteralmente, grilletto) in alcuni sistemi di controllo di revisione, ma i due nomi si riferiscono alla stessa idea.
+ Il nome che Mercurial usa per indicare una di queste azioni è hook (letteralmente, gancio). In alcuni sistemi di controllo di revisione, gli hook vengono chiamati trigger (letteralmente, grilletto), ma i due nomi si riferiscono alla stessa idea.Un'introduzione agli hook di Mercurial
@@ -51,7 +51,7 @@
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, sappiate che Mercurial eseguirà gli hook definiti nel file ~/.hgrc globale per quel sistema.
+ In alcuni casi, potreste essere esposti a hook che non avete installato voi. Se lavorate con Mercurial su un sistema che non vi è familiare, sappiate che 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 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.
@@ -71,7 +71,7 @@
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 un'installazione standard di Mercurial su un file system NFS e usare un file ~/.hgrc globale per definire hook che verranno visti da tutti gli utenti. Tuttavia, come constateremo nella prossima sezione, anche questo approccio ha dei limiti.
+ In una intranet aziendale, questo aspetto è in qualche modo più facile da controllare, dato che per esempio potete fornire un'installazione standard di Mercurial su un file system NFS e usare un file hgrc globale per definire hook che verranno visti da tutti gli utenti. Tuttavia, come constateremo nella prossima sezione, anche questo approccio ha dei limiti.
@@ -79,13 +79,13 @@
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 tenere presente che i vostri utenti sono in grado di disabilitare o sostituire quegli hook.
+ Se fate ricorso a un file hgrc di sistema o globale che definisce alcuni hook, dovreste quindi tenere presente 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.
+ 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 ridefinendo 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 ufficiale ben noto che avete messo in sicurezza e configurato adeguatamente.
@@ -233,12 +233,12 @@
&ch09-check_whitespace.py.lst;
- Questa versione è molto più complessa, ma anche molto più utile. Analizza un diff unificato 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.
+ Questa versione è molto più complessa, ma anche molto più utile. Analizza un diff unificato 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. In più, 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, dopo aver corretto il problema, possiate usare l'opzione del comando hg commit per riutilizzare il messaggio di commit salvato.
&interaction.ch09-hook.ws.better;
Come ultima nota a margine, osservate in questo esempio l'uso della funzione 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+$,,' nomefile
+ perl -pi -e 's,[ \t]+$,,' nomefile
@@ -307,13 +307,11 @@
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, creato da Mario Rossi
- <mario.rossi@example.com> nel repository vattelapesca,
+ 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.example.com/vattelapesca?cmd=changeset;node=aad8b264143a
- Descrizione del changeset: risolto bug 10483 proteggendo il codice da alcuni
- puntatori NULL.
+ http://hg.example.com/vattelapesca?cmd=changeset;node=aad8b264143a
+ 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à.
@@ -326,7 +324,7 @@
Configurare l'hook <literal role="hook">bugzilla</literal>
- Dovreste configurare questo hook nel file ~/.hgrc del vostro server come un hook incoming, per esempio nel modo seguente:
+ 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
@@ -335,7 +333,7 @@
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 precompilato per il vostro sistema, potete scaricarla da .
- Le informazioni di configurazione per questo hook si trovano nella sezione bugzilla del vostro file ~/.hgrc.
+ 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 usato da Bugzilla cambia occasionalmente, quindi questo hook deve sapere esattamente quale schema usare.
@@ -349,7 +347,7 @@
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 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:
+ notify: se volete che Bugzilla spedisca un'email di notifica agli interessati dopo che questo hook ha aggiunto un commento a un bug, è necessario 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 nessuno@example.comIl 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.
@@ -364,7 +362,7 @@
Ogni elemento nella sezione usermap contiene un indirizzo email sulla sinistra e un nome utente Bugzilla sulla destra.[usermap]
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 un repository modificabile dall'utente, per esempio. 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:
+ 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 un repository modificabile dall'utente, per esempio. 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/datiutente/bugzilla-usermap.conf
@@ -377,14 +375,14 @@
Configurare il testo che viene aggiunto a un bug
- 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.
+ 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/test, allora impostando strip a 4 otterrete il percorso parziale app/test. 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'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 permetterà 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.example.com/
@@ -436,11 +434,11 @@
# 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.
+ Le informazioni di configurazione per questo hook si trovano nella sezione notify del file hgrc.
- test: per 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 per 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 iscrizione. 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 iscrizioni e trasmettere i cambiamenti al vostro server.
+ test: per default, questo hook non spedisce alcuna email, ma stampa il messaggio che verrebbe inviato. Impostate questo elemento a false per consentire la spedizione delle email. La ragione per cui la spedizione delle email è disabilitata per 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 sbagliate mentre correggete la vostra configurazione.
+
+ config: il percorso di un file di configurazione che contiene le informazioni di iscrizione. 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 iscrizioni 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 iscriversi al servizio di notifica 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/condivisi/test, impostare strip a 4 farà in modo che notify restringa il percorso da considerare a condivisi/test e associ le iscrizioni a questo percorso.
@@ -465,7 +463,7 @@
Collaudo e risoluzione dei problemi
- Non dimenticate che il comportamento predefinito dell'estensione notify è quello di non spedire alcuna mail fino a quando non lo avete esplicitamente configurato per farlo, impostando test a false. Fino a quel momento, si limiterà a stampare il messaggio che avrebbe inviato.
+ Non dimenticate che il comportamento predefinito dell'estensione notify è quello di non spedire alcuna mail fino a quando non lo avete esplicitamente configurato per farlo, impostando test a false. Fino a quel momento, si limiterà a stampare il messaggio che verrebbe inviato.
@@ -481,7 +479,7 @@
pass
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 node o parentN, conterrà un identificatore esadecimale di changeset. Per rappresentare l'identificatore di changeset nullo, viene usata una stringa vuota invece di una stringa di zeri.Se un parametro si chiama url, conterrà l'URL di un repository remoto, nel caso possa essere determinato.
@@ -503,7 +501,7 @@
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.
+ 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. Per rappresentare l'identificatore di changeset nullo, viene usata una stringa vuota 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.
@@ -744,7 +742,7 @@
<literal role="hook">preupdate</literal>&emdash;prima di eseguire un aggiornamento o un'unione della directory di lavoro
- Questo hook viene eseguito prima di cominciare un aggiornamento o un'unione della 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.
+ Questo hook viene eseguito prima di cominciare un aggiornamento o un'unione della 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'aggiornamento o l'unione non vengono cominciati.I parametri di questo hook sono i seguenti.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/ch11-template.xml
--- a/it/ch11-template.xml Fri Aug 21 21:42:22 2009 +0200
+++ b/it/ch11-template.xml Fri Aug 21 22:29:44 2009 +0200
@@ -17,7 +17,7 @@
&interaction.template.simple.compact;
- Lo stile changelog ci dà un'idea quale sia il potere espressivo del motore di template di Mercurial. Questo stile tenta di seguire le linee guida per la formattazione di un registro dei cambiamenti stabilite dal progetto GNU .
+ Lo stile changelog ci dà un'idea di quale sia il potere espressivo del motore di template di Mercurial. Questo stile tenta di seguire le linee guida per la formattazione di un registro dei cambiamenti stabilite dal progetto GNU .
&interaction.template.simple.changelog;
@@ -40,7 +40,7 @@
Tutti i comandi Mercurial di tipo log vi permettono di usare stili e template: hg incoming, hg log, hg outgoing e hg tip.
- Al momento di scrivere questo manuale, quelli elencati sono i comandi che finora supportano stili e template. Dato che questi sono i comandi più importanti che necessitino di una formattazione personalizzabile, la comunità utenti di Mercurial non ha fatto molta pressione per aggiungere il supporto per stili e template ad altri comandi.
+ Al momento di scrivere questo manuale, quelli elencati sono i comandi che finora supportano stili e template. Dato che questi sono i comandi più importanti per i quali è necessaria una formattazione personalizzabile, la comunità utenti di Mercurial non ha fatto molta pressione per aggiungere il supporto per stili e template ad altri comandi.
@@ -112,7 +112,7 @@
Il motore di template di Mercurial riconosce le sequenze di escape più comunemente usate nelle stringhe. Quando trova un carattere di backslash (\), esamina il carattere successivo e rimpiazza i due caratteri con un unico sostituto, come descritto qui di seguito.
- \:
+ \\:
backslash, \, corrispondente al codice ASCII 134.\n: nuova riga, codice ASCII 12.
@@ -274,7 +274,7 @@
Infine, viene fornita una descrizione di quello che è andato storto.fallimento: stile.errato:1: ___errore di riconoscimento___
- La descrizione del problema non è sempre chiara (come in questo caso), ma anche quando è criptica, è quasi sempre banale trovare la causa dell'errore inspezionando visivamente la riga del file di stile che contiene il problema.
+ La descrizione del problema non è sempre chiara (come in questo caso) ma, anche quando è criptica, è quasi sempre banale trovare la causa dell'errore inspezionando visivamente la riga del file di stile che contiene il problema.
@@ -332,7 +332,7 @@
&interaction.template.svnstyle.style;
- Avremmo potuto includere il testo del file di template direttamente nel file di stile, circondandolo con virgolette e rimpiazzando le nuove righe con sequenze \n, ma questo avrebbe reso il file di stile troppo difficile da leggere. La leggibilità è una buon criterio da cui farsi guidare per decidere se un certo testo appartiene a un file di stile o a un file di template a cui il file di stile fa riferimento. Nel caso il file di stile vi sembri troppo grande o disordinato se inserite un frammento letterale di testo, allora spostate il testo in un template.
+ Avremmo potuto includere il testo del file di template direttamente nel file di stile, circondandolo con virgolette e rimpiazzando le nuove righe con sequenze \n, ma questo avrebbe reso il file di stile troppo difficile da leggere. La leggibilità è un buon criterio da cui farsi guidare per decidere se un certo testo appartiene a un file di stile o a un file di template a cui il file di stile fa riferimento. Nel caso il file di stile vi sembri troppo grande o disordinato se inserite un frammento letterale di testo, allora spostate il testo in un template.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/bisect.search.mytest.it
--- a/it/examples/bisect.search.mytest.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/bisect.search.mytest.it Fri Aug 21 22:29:44 2009 +0200
@@ -2,12 +2,14 @@
$miotest() {$ if grep -q 'ho un gub' *> then
-> risultato=bad
+> contrassegno=bad
+> risultato=guasta> else
-> risultato=good
+> contrassegno=good
+> risultato=funzionante> fi
-> echo il contrassegno di questa revisione è $risultato
-> hg bisect --$risultato
+> echo questa revisione è $risultato
+> hg bisect --$contrassegno>}
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/bisect.search.rest.it
--- a/it/examples/bisect.search.rest.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/bisect.search.rest.it Fri Aug 21 22:29:44 2009 +0200
@@ -1,18 +1,18 @@
$miotest
-il contrassegno di questa revisione è good
+questa revisione è funzionante
Collaudo il changeset 20:bf7ea9a054e6 (3 changeset rimanenti, ~1 test)
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$miotest
-il contrassegno di questa revisione è good
+questa revisione è funzionante
Collaudo il changeset 21:921391dd45c1 (2 changeset rimanenti, ~1 test)
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$miotest
-il contrassegno di questa revisione è good
+questa revisione è funzionante
La prima revisione guasta è:
changeset: 22:b8789808fc48
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Tue May 05 06:55:14 2009 +0000
-summary: Changeset difettoso.
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Tue May 05 06:55:14 2009 +0000
+sommario: Changeset difettoso.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/bisect.search.step1.it
--- a/it/examples/bisect.search.step1.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/bisect.search.step1.it Fri Aug 21 22:29:44 2009 +0200
@@ -5,7 +5,7 @@
>else> risultato=good>fi
-$echo il contrassegno di questa revisione è $risultato
+$echo il contrassegno di questa revisione è: $risultato
il contrassegno di questa revisione è bad
$hg bisect --$risultato
Collaudo il changeset 16:e61fdddff53e (12 changeset rimanenti, ~3 test)
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/bisect.search.step2.it
--- a/it/examples/bisect.search.step2.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/bisect.search.step2.it Fri Aug 21 22:29:44 2009 +0200
@@ -1,6 +1,6 @@
$miotest
-il contrassegno di questa revisione è good
+questa revisione è funzionante
Collaudo il changeset 19:706df39b003b (6 changeset rimanenti, ~2 test)
3 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/branch-named.branches.it
--- a/it/examples/branch-named.branches.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/branch-named.branches.it Fri Aug 21 22:29:44 2009 +0200
@@ -1,10 +1,10 @@
$hg tip
changeset: 0:fc8fb1089cc0
-tag: tip
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:48:56 2009 +0000
-summary: Commit iniziale.
+etichetta: tip
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:48:56 2009 +0000
+sommario: Commit iniziale.
$hg branches
default 0:fc8fb1089cc0
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/branch-named.commit.it
--- a/it/examples/branch-named.commit.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/branch-named.commit.it Fri Aug 21 22:29:44 2009 +0200
@@ -3,11 +3,11 @@
$hg commit -m 'Secondo commit.'$hg tip
changeset: 1:b15761055392
-branch: foo
-tag: tip
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:48:59 2009 +0000
-summary: Secondo commit.
+ramo: foo
+etichetta: tip
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:48:59 2009 +0000
+sommario: Secondo commit.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/branch-named.create.it
--- a/it/examples/branch-named.create.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/branch-named.create.it Fri Aug 21 22:29:44 2009 +0200
@@ -1,6 +1,6 @@
$hg branch foo
-la directory di lavoro è stata segnata come ramo foo
+la directory di lavoro è stata contrassegnata come ramo foo
$hg branch
foo
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/branch-named.foo-commit.it
--- a/it/examples/branch-named.foo-commit.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/branch-named.foo-commit.it Fri Aug 21 22:29:44 2009 +0200
@@ -5,18 +5,18 @@
creata una nuova testa
$hg heads
changeset: 3:859c842ea668
-branch: foo
-tag: tip
-parent: 1:b15761055392
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:49:04 2009 +0000
-summary: NUovo file.
+ramo: foo
+etichetta: tip
+genitore: 1:b15761055392
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:49:04 2009 +0000
+sommario: Nuovo file.
changeset: 2:4dce38140953
-branch: bar
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:49:00 2009 +0000
-summary: Terzo commit.
+ramo: bar
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:49:00 2009 +0000
+sommario: Terzo commit.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/branch-named.merge.it
--- a/it/examples/branch-named.merge.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/branch-named.merge.it Fri Aug 21 22:29:44 2009 +0200
@@ -7,13 +7,13 @@
$hg commit -m 'Unione.'$hg tip
changeset: 4:f50f493d0dc0
-branch: bar
-tag: tip
-parent: 2:4dce38140953
-parent: 3:859c842ea668
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:49:06 2009 +0000
-summary: Unione.
+ramo: bar
+etichetta: tip
+genitore: 2:4dce38140953
+genitore: 3:859c842ea668
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:49:06 2009 +0000
+sommario: Unione.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/branch-named.parents.it
--- a/it/examples/branch-named.parents.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/branch-named.parents.it Fri Aug 21 22:29:44 2009 +0200
@@ -1,11 +1,11 @@
$hg parents
changeset: 2:4dce38140953
-branch: bar
-tag: tip
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:49:00 2009 +0000
-summary: Terzo commit.
+ramo: bar
+etichetta: tip
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:49:00 2009 +0000
+sommario: Terzo commit.
$hg branches
bar 2:4dce38140953
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/branch-named.rebranch.it
--- a/it/examples/branch-named.rebranch.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/branch-named.rebranch.it Fri Aug 21 22:29:44 2009 +0200
@@ -2,17 +2,17 @@
$hg branch
foo
$hg branch bar
-la directory di lavoro è stata segnata come ramo bar
+la directory di lavoro è stata contrassegnata come ramo bar
$echo nuovo file > nuovofile$hg commit -A -m 'Terzo commit.'
aggiungo nuovofile
$hg tip
changeset: 2:4dce38140953
-branch: bar
-tag: tip
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:49:00 2009 +0000
-summary: Terzo commit.
+ramo: bar
+etichetta: tip
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:49:00 2009 +0000
+sommario: Terzo commit.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/branch-named.status.it
--- a/it/examples/branch-named.status.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/branch-named.status.it Fri Aug 21 22:29:44 2009 +0200
@@ -2,10 +2,10 @@
$hg status$hg tip
changeset: 0:fc8fb1089cc0
-tag: tip
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:48:56 2009 +0000
-summary: Commit iniziale
+etichetta: tip
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:48:56 2009 +0000
+sommario: Commit iniziale
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/branch-named.update-switchy.it
--- a/it/examples/branch-named.update-switchy.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/branch-named.update-switchy.it Fri Aug 21 22:29:44 2009 +0200
@@ -3,20 +3,20 @@
0 file aggiornati, 0 file uniti, 1 file rimossi, 0 file irrisolti
$hg parents
changeset: 1:b15761055392
-branch: foo
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:48:59 2009 +0000
-summary: Secondo commit.
+ramo: foo
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:48:59 2009 +0000
+sommario: Secondo commit.
$hg update bar
1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$hg parents
changeset: 2:4dce38140953
-branch: bar
-tag: tip
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:49:00 2009 +0000
-summary: Terzo commit.
+ramo: bar
+etichetta: tip
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:49:00 2009 +0000
+sommario: Terzo commit.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/branch-repo.bugfix.it
--- a/it/examples/branch-repo.bugfix.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/branch-repo.bugfix.it Fri Aug 21 22:29:44 2009 +0200
@@ -1,8 +1,8 @@
-$hg clone mioprogetto-1.0.1 mia-1.0.1-correzione
+$hg clone mioprogetto-1.0.1 mia-correzione-1.0.1
aggiorno la directory di lavoro
2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
-$cd mia-1.0.1-correzione
+$cd mia-correzione-1.0.1$echo 'Ho corretto un bug usando solo echo!' >> miofile$hg commit -m 'Importante correzione per la versione 1.0.1.'$hg push
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/branch-repo.pull.it
--- a/it/examples/branch-repo.pull.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/branch-repo.pull.it Fri Aug 21 22:29:44 2009 +0200
@@ -5,7 +5,7 @@
3 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti
$cd mioprogetto-unione$hg pull ../mioprogetto-1.0.1
-estraggo da ../myproject-1.0.1
+estraggo da ../mioprogetto-1.0.1
cerco i cambiamenti
aggiungo i changeset
aggiungo i manifest
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/ch09-check_whitespace.py.lst.it
--- a/it/examples/ch09-check_whitespace.py.lst.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/ch09-check_whitespace.py.lst.it Fri Aug 21 22:29:44 2009 +0200
@@ -27,7 +27,7 @@
numriga = int(m.group(1))
continue
# corpo - cerca una riga aggiunta con spazio bianco in coda
- m = re.match(r'\+.*\s$', riga)
+ m = re.match(r'\+.*[ \t]$', riga)
if m:
yield nomefile, numriga
if riga and riga[0] in ' +':
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/ch09-hook.ws.better.it
--- a/it/examples/ch09-hook.ws.better.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/ch09-hook.ws.better.it Fri Aug 21 22:29:44 2009 +0200
@@ -4,17 +4,12 @@
pretxncommit.spazio_bianco = .hg/controllo_spazio_bianco.py
$echo 'a ' >> a$hg commit -A -m 'Aggiunge una nuova riga con spazio bianco in coda.'
-a, riga 2: aggiunto spazio bianco in coda
+a, riga 1: aggiunto spazio bianco in coda
messaggio di commit salvato nel file .hg/commit.save
transazione abortita!
ripristino completato
fallimento: l'hook pretxncommit.spazio_bianco è terminato con codice di stato 1
$sed -i 's, *$,,' a$hg commit -A -m 'Rimosso spazio bianco in coda.'
-a, riga 2: aggiunto spazio bianco in coda
-messaggio di commit salvato nel file .hg/commit.save
-transazione abortita!
-ripristino completato
-fallimento: l'hook pretxncommit.spazio_bianco è terminato con codice di stato 1
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/ch10-notify-config-mail.lst.it
--- a/it/examples/ch10-notify-config-mail.lst.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/ch10-notify-config-mail.lst.it Fri Aug 21 22:29:44 2009 +0200
@@ -1,6 +1,6 @@
X-Hg-Repo: test/slave
-Subject: test/slave: Gestisce l'errore nel caso in cui uno slave non ha alcun master.
+Subject: test/slave: Gestisce l'errore nel caso in cui uno slave non ha alcun buffer.
Date: Wed, 2 Aug 2006 15:25:46 -0700 (PDT)
changeset 3cba9bfe74b5 nel repository /home/hg/repos/test/slave
@@ -8,7 +8,7 @@
details:
http://hg.example.com/test/slave?cmd=changeset;node=3cba9bfe74b5
-description: Gestisce l'errore nel caso in cui uno slave non ha alcun master.
+description: Gestisce l'errore nel caso in cui uno slave non ha alcun buffer.
diffs (54 lines):
diff -r 9d95df7cf2ad -r 3cba9bfe74b5 include/test.h
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/hook.simple.init.it
--- a/it/examples/hook.simple.init.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/hook.simple.init.it Fri Aug 21 22:29:44 2009 +0200
@@ -8,7 +8,7 @@
commit = echo inserito $HG_NODE
$echo a > a$hg add a
-$hg commit -m "Collaudo l'hook di commit"
+$hg commit -m "Collaudo l'hook di commit."
inserito 35ce7b98906996dea87740158ba6c3d7bcfa2448
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/rollback.rollback.it
--- a/it/examples/rollback.rollback.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/rollback.rollback.it Fri Aug 21 22:29:44 2009 +0200
@@ -3,10 +3,10 @@
abortisco l'ultima transazione
$hg tip
changeset: 0:ce49f5b59f20
-tag: tip
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:51:13 2009 +0000
-summary: Primo commit.
+etichetta: tip
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:51:13 2009 +0000
+sommario: Primo commit.
$hg status
M a
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/rollback.status.it
--- a/it/examples/rollback.status.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/rollback.status.it Fri Aug 21 22:29:44 2009 +0200
@@ -3,10 +3,10 @@
? b
$hg tip
changeset: 1:249cc777b54f
-tag: tip
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:51:13 2009 +0000
-summary: Aggiunge il file b.
+etichetta: tip
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:51:13 2009 +0000
+sommario: Aggiunge il file b.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/tag.log.it
--- a/it/examples/tag.log.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/tag.log.it Fri Aug 21 22:29:44 2009 +0200
@@ -1,16 +1,16 @@
$hg log
changeset: 1:87dee45bf6ec
-tag: tip
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:51:18 2009 +0000
-summary: Aggiunta l'etichetta v1.0 per il changeset 35aa95ccc713.
+etichetta: tip
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:51:18 2009 +0000
+sommario: Aggiunta l'etichetta v1.0 per il changeset 35aa95ccc713.
changeset: 0:35aa95ccc713
-tag: v1.0
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:51:18 2009 +0000
-summary: Commit iniziale.
+etichetta: v1.0
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:51:18 2009 +0000
+sommario: Commit iniziale.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/tag.log.v1.0.it
--- a/it/examples/tag.log.v1.0.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/tag.log.v1.0.it Fri Aug 21 22:29:44 2009 +0200
@@ -4,10 +4,10 @@
aggiungo miofile2
$hg log -r v1.0
changeset: 0:35aa95ccc713
-tag: v1.0
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:51:18 2009 +0000
-summary: Commit iniziale.
+etichetta: v1.0
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:51:18 2009 +0000
+sommario: Commit iniziale.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/tag.tip.it
--- a/it/examples/tag.tip.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/tag.tip.it Fri Aug 21 22:29:44 2009 +0200
@@ -1,10 +1,10 @@
$hg tip
changeset: 5:9a0bd94354ec
-tag: tip
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:51:22 2009 +0000
-summary: Aggiunta l'etichetta v1.1 per il changeset 35418c351c2b.
+etichetta: tip
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:51:22 2009 +0000
+sommario: Aggiunta l'etichetta v1.1 per il changeset 35418c351c2b.
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/template.simple.changelog.it
--- a/it/examples/template.simple.changelog.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/template.simple.changelog.it Fri Aug 21 22:29:44 2009 +0200
@@ -14,7 +14,7 @@
Aggiunta una riga alla fine del file <<hello>>.
In più, aggiunto un file con il nome indicativo (almeno spero che qualcuno
- possa considerarlo tale) di goodbye.
+ possa considerarlo tale) di goodbye.
[fb5e3583537a] [miaetichetta]
* hello:
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/template.simple.compact.it
--- a/it/examples/template.simple.compact.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/template.simple.compact.it Fri Aug 21 22:29:44 2009 +0200
@@ -6,7 +6,7 @@
2[v0.1] a5ff5617a0be 2009-06-05 15:51 +0000 bos
Aggiunta etichetta miaetichetta per il changeset fb5e3583537a
-1[mytag] fb5e3583537a 2009-06-05 15:51 +0000 bos
+1[miaetichetta] fb5e3583537a 2009-06-05 15:51 +0000 bos
Aggiunta una riga alla fine del file <<hello>>.
0 0afbebcdeafc 2009-06-05 15:51 +0000 bos
diff -r 0a49072e8c7f -r 7252e7b7f07d it/examples/template.simple.normal.it
--- a/it/examples/template.simple.normal.it Fri Aug 21 21:42:22 2009 +0200
+++ b/it/examples/template.simple.normal.it Fri Aug 21 22:29:44 2009 +0200
@@ -1,10 +1,10 @@
$hg log -r1
changeset: 1:fb5e3583537a
-tag: miaetichetta
-user: Bryan O'Sullivan <bos@serpentine.com>
-date: Fri Jun 05 15:51:24 2009 +0000
-summary: Aggiunta una riga alla fine del file <<hello>>.
+etichetta: miaetichetta
+utente: Bryan O'Sullivan <bos@serpentine.com>
+data: Fri Jun 05 15:51:24 2009 +0000
+sommario: Aggiunta una riga alla fine del file <<hello>>.