# HG changeset patch # User Giulio@puck # Date 1248095962 -7200 # Node ID bd13bb9c9e03747f9a5166aae48b9f31b4745e09 # Parent fb05936ccde9260d1dc3794839fa1e3772e10f1a More minor modifications to Ch.9. diff -r fb05936ccde9 -r bd13bb9c9e03 it/ch09-undo.xml --- a/it/ch09-undo.xml Sun Jul 19 01:14:57 2009 +0200 +++ b/it/ch09-undo.xml Mon Jul 20 15:19:22 2009 +0200 @@ -10,15 +10,15 @@ L'inserimento accidentale - Ho l'occasionale ma persistente problema di digitare più velocemente di quanto riesca a pensare, cosa che talvolta ha come risultato io che inserisco un changeset che è incompleto o completamente sbagliato. Nel mio caso, il classico tipo di changeset incompleto è quello in cui ho creato un nuovo file sorgente ma ho dimenticato di usare hg add per aggiungerlo al repository. Un changeset completamente sbagliato non è così comune, ma non è meno fastidioso. + Ho l'occasionale ma persistente problema di digitare più velocemente di quanto riesca a pensare, cosa che talvolta provoca come conseguenza l'inserimento di un changeset che è incompleto o completamente sbagliato. Nel mio caso, il classico tipo di changeset incompleto è quello in cui ho creato un nuovo file sorgente ma ho dimenticato di usare hg add per aggiungerlo al repository. Un changeset completamente sbagliato non è così comune, ma non è meno fastidioso. - ~Rolling back~ una transazione - - Nella , ho menzionato che Mercurial tratta ogni modifica del repository come una transazione. Ogni volta che inserite un changeset o estraete i cambiamenti da un altro repository, Mercurial ricorda cosa avete fatto. Potete annullare, o ~roll back~, esattamente una di queste azioni usando il comando hg rollback. (Leggete la per un importante avvertimento su come usare questo comando.) - - Ecco un errore che mi ritrovo spesso a commettere: inserire un cambiamento in cui ho creato un nuovo file ma ho dimenticato di aggiungerlo tramite hg add. + Abortire una transazione + + Nella , ho menzionato che Mercurial tratta ogni modifica del repository come una transazione. Ogni volta che inserite un changeset o estraete i cambiamenti da un altro repository, Mercurial ricorda cosa avete fatto. Potete annullare, o abortire, esattamente una di queste azioni usando il comando hg rollback. (Leggete la per un importante avvertimento su come usare questo comando.) + + Ecco un errore che mi ritrovo spesso a commettere: inserire un changeset in cui ho creato un nuovo file ma ho dimenticato di aggiungerlo tramite hg add. &interaction.rollback.commit; @@ -32,7 +32,7 @@ &interaction.rollback.rollback; - Notate che il changeset non è più presente nella cronologia del repository e che la directory di lavoro pensa ancora che il file a sia stato modificato. Il commit e il ~rollback~ hanno lasciato la directory di lavoro nello stato esatto in cui si trovava prima dell'inserimento; il changeset è stato completamente rimosso. Ora posso tranquillamente usare hg add per aggiungere il file b e rieseguire il commit. + Notate che il changeset non è più presente nella cronologia del repository e che la directory di lavoro pensa ancora che il file a sia stato modificato. Il commit e il suo annullamento hanno lasciato la directory di lavoro nello stato esatto in cui si trovava prima dell'inserimento; il changeset è stato completamente rimosso. Ora posso tranquillamente usare hg add per aggiungere il file b e rieseguire il commit. &interaction.rollback.add; @@ -48,23 +48,23 @@ - ~Rolling back~ è inutile se avete già trasmesso le modifiche - - Il valore di hg rollback scende a zero una volta che avete trasmesso le vostre modifiche a un altro repository. ~Rolling back~ un cambiamento lo fa scomparire interamente, ma solo nel repository in cui invocate hg rollback. Dato che un ~rollback~ elimina parte della cronologia, non è possibile che la scomparsa di un cambiamento si propaghi tra i repository. - - Se avete trasmesso un cambiamento a un altro repository&emdash;in particolare se è un repository condiviso&emdash;è essenzialmente scappato dal recinto e dovrete rimediare all'errore in un altro modo. Se trasmettete un changeset da qualche parte, poi ~roll it back~ e poi estraete i cambiamenti dal repository verso cui avete effettuato la trasmissione, il changeset di cui credevate di esservi sbarazzati riapparirà semplicemente nel vostro repository. - - (Se siete assolutamente sicuri che il cambiamento che volete ritirare è quello più recente contenuto nel repository a cui lo avete trasmesso e sapete che nessun altro può averlo estratto da quel repository, potete ritirare il changeset anche là, ma non dovreste aspettarvi che questo funzioni in maniera affidabile. Presto o tardi un cambiamento finirà in un repository su cui non avete un controllo diretto (o vi siete dimenticati di averlo) e tornerà indietro a mordervi.) - - - - Potete ritirare una sola volta - - Mercurial memorizza esattamente una transazione nel suo registro delle transazioni: quella più recente avvenuta nel repository. Questo significa che potete ritirare solo una transazione. Se vi aspettate di poter ritirare una transazione e poi il suo predecessore, questo non il comportamento che otterrete. + Abortire è inutile se avete già trasmesso le modifiche + + Il valore di hg rollback scende a zero una volta che avete trasmesso le vostre modifiche a un altro repository. Abortire un cambiamento lo fa scomparire interamente, ma solo nel repository in cui invocate hg rollback. Dato che un annullamento elimina parte della cronologia, non è possibile che la scomparsa di un cambiamento si propaghi tra i repository. + + Se avete trasmesso un cambiamento a un altro repository&emdash;in particolare se è un repository condiviso&emdash;è essenzialmente scappato dal recinto e dovrete rimediare all'errore in un altro modo. Se trasmettete un changeset da qualche parte, lo abortite e poi estraete i cambiamenti dal repository verso cui avete effettuato la trasmissione, il changeset di cui credevate di esservi sbarazzati riapparirà semplicemente nel vostro repository. + + (Se siete assolutamente sicuri che il cambiamento che volete abortire è quello più recente contenuto nel repository a cui lo avete trasmesso e sapete che nessun altro può averlo estratto da quel repository, potete ritirare il changeset anche là, ma non dovreste aspettarvi che questo funzioni in maniera affidabile. Presto o tardi un cambiamento finirà in un repository su cui non avete un controllo diretto (o vi siete dimenticati di averlo) e tornerà indietro a mordervi.) + + + + Potete abortire una sola volta + + Mercurial memorizza esattamente una transazione nel suo registro delle transazioni: quella più recente avvenuta nel repository. Questo significa che potete abortire solo una transazione. Se vi aspettate di poter abortire una transazione e poi il suo predecessore, questo non il comportamento che otterrete. &interaction.rollback.twice; - Una volta che avete ritirato una transazione in un repository, non potete effettuare un altro ritiro in quel repository fino a quando non avete eseguito un altro inserimento o una nuova estrazione. + Una volta che avete abortito una transazione in un repository, non potete effettuare un altro annullamento in quel repository fino a quando non avete eseguito un altro inserimento o una nuova estrazione. @@ -545,11 +545,11 @@ Fate attenzione alle interferenze tra i bug - È possibile che la vostra ricerca di un bug venga rovinata dalla presenza di un altro bug. Per esempio, diciamo che il vostro software ~crashes~ alla revisione 100 e funziona correttamente alla revisione 50. Senza che voi lo sappiate, qualcun altro ha introdotto un ~crashing~ bug differente alla revisione 60 e lo ha corretto alla revisione 80. Questo potrebbe distorcere i vostri risultati in vari modi. + È possibile che la vostra ricerca di un bug venga rovinata dalla presenza di un altro bug. Per esempio, diciamo che il vostro software si blocca alla revisione 100 e funziona correttamente alla revisione 50. Senza che voi lo sappiate, qualcun altro ha introdotto un bug bloccante differente alla revisione 60 e lo ha corretto alla revisione 80. Questo potrebbe distorcere i vostri risultati in vari modi. È possibile che questo altro bug mascheri completamente il vostro, cioè che sia comparso prima che il vostro bug abbia avuto la possibilità di manifestarsi. Se non potete evitare quell'altro bug (per esempio, impedisce al vostro progetto di venire assemblato) e quindi non potete dire se il vostro bug è presente in un particolare changeset, il comando hg bisect non è in grado di aiutarvi direttamente. Invece, invocando hg bisect --skip potete contrassegnare un changeset come non collaudato. - Potrebbe esserci un problema differente se il vostro test per la presenza di un bug non è abbastanza specifico. Se controllate che il mio programma ~crashes~, allora sia il vostro ~crashing~ bug che il ~crashing~ bug scorrelato che lo maschera sembreranno la stessa cosa e fuorvieranno hg bisect. + Potrebbe esserci un problema differente se il vostro test per la presenza di un bug non è abbastanza specifico. Se controllate che il mio programma si blocca, allora sia il vostro bug bloccante che il bug bloccante scorrelato che lo maschera sembreranno la stessa cosa e fuorvieranno hg bisect. Un'altra situazione utile in cui sfruttare hg bisect --skip è quella in cui non potete collaudare una revisione perché il vostro progetto era guasto e quindi in uno stato non collaudabile in quella revisione, magari perché qualcuno aveva introdotto un cambiamento che impediva al progetto di venire assemblato.