Trovare e correggere gli errori

# HG changeset patch # User Giulio@puck # Date 1248456209 -7200 # Node ID a1f00af620baf13f958e4c102bae229bae4e8614 # Parent 42ffc394c34ed93ec625f0467313417d22c8b5de Deep revision of Ch.9. diff -r 42ffc394c34e -r a1f00af620ba it/ch09-undo.xml --- a/it/ch09-undo.xml Fri Jul 24 18:08:04 2009 +0200 +++ b/it/ch09-undo.xml Fri Jul 24 19:23:29 2009 +0200 @@ -2,7 +2,7 @@ Trovare e correggere gli errori - Sbagliare potrebbe essere umano, ma per gestire davvero bene le conseguenze degli errori ci vuole un sistema di controllo di revisione di prima qualità. In questo capitolo, discuteremo alcune tecniche che potete usare quando scoprite che un problema si è insinuato nel vostro progetto. Mercurial è dotato di alcune funzionalità ~highly capable~ che vi aiuteranno a isolare le cause dei problemi e a trattarle in maniera appropriata. + Sbagliare potrebbe essere umano, ma per gestire davvero bene le conseguenze degli errori ci vuole un sistema di controllo di revisione di prima qualità. In questo capitolo, discuteremo alcune tecniche che potete usare quando scoprite che un problema si è insinuato nel vostro progetto. Mercurial è dotato di alcune funzionalità particolarmente efficaci che vi aiuteranno a isolare le cause dei problemi e a trattarle in maniera appropriata. Cancellare la cronologia locale @@ -10,7 +10,7 @@ L'inserimento accidentale - 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. + In maniera occasionale ma persistente mi capita di digitare più velocemente di quanto riesca a pensare, cosa che talvolta provoca come conseguenza l'inserimento di un changeset 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. @@ -18,21 +18,21 @@ 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. + Ecco un errore che mi ritrovo spesso a commettere: inserire un changeset in cui ho creato un nuovo file dimenticandomi di aggiungerlo tramite hg add. &interaction.rollback.commit; - Controllare il risultato di hg status dopo l'inserimento conferma immediatamente l'errore. + Un'occhiata al risultato di hg status dopo l'inserimento conferma immediatamente l'errore. &interaction.rollback.status; - Il commit ha catturato le modifiche al file a, ma non il nuovo file b. Se trasmettessi questo changeset a un repository che condivido con i miei colleghi, è molto probabile che qualcosa in a si riferisca a b, che non sarà presente nei loro repository quando estrarranno i miei cambiamenti. Di conseguenza, diventerei oggetto di una certa indignazione. + Il commit ha catturato le modifiche al file a, ma non il nuovo file b. È molto probabile che qualcosa in a si riferisca a b, ma se trasmettessi questo changeset a un repository condiviso, i collaboratori che estraessero i miei cambiamenti non troverebbero b nei loro repository. Di conseguenza, diventerei oggetto di una certa indignazione. Tuttavia, la fortuna è dalla mia parte&emdash;mi sono accorto dell'errore prima di trasmettere il changeset. Ora uso il comando hg rollback e Mercurial farà sparire quell'ultimo changeset. &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 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. + 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 la sua cancellazione 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; @@ -40,7 +40,7 @@ L'estrazione sbagliata - È pratica comune con Mercurial mantenere i rami di sviluppo separati di un progetto in repository differenti. 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. + È pratica comune con Mercurial mantenere 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. @@ -50,30 +50,30 @@ 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.) + 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 una cancellazione 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;le modifiche sono essenzialmente scappate 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 vi si ritorcerà contro.) 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. + 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 quella che la precede, questo non è il comportamento che otterrete. &interaction.rollback.twice; - 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. + 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. Rimediare alle modifiche sbagliate - Se fate un cambiamento a un file e decidete che in realtà non volevate affatto modificare il file, e non avete ancora inserito i vostri cambiamenti nel repository, il comando che vi serve è hg revert. Guarda al changeset che è il genitore della directory di lavoro e ripristina il contenuto di quel file allo stato in cui era in quel changeset. (Questo è un modo prolisso di dire che, nel caso normale, annulla le vostre modifiche.) - - Vediamo come funziona il comando hg revert attraverso ancora un altro piccolo esempio. Cominceremo modificando un file che Mercurial ha già registrato. + Se fate un cambiamento a un file e poi decidete che in realtà non volevate affatto modificare il file, ma non avete ancora inserito i vostri cambiamenti nel repository, il comando che vi serve è hg revert. Questo comando guarda il changeset genitore della directory di lavoro e ripristina il contenuto del file allo stato in cui era in quel changeset. (Questo è un modo prolisso per dire che, nel caso normale, annulla le vostre modifiche.) + + Vediamo come funziona il comando hg revert, ancora con un altro piccolo esempio. Cominceremo modificando un file che Mercurial ha già registrato. &interaction.daily.revert.modify; @@ -81,33 +81,33 @@ &interaction.daily.revert.unmodify; - Il comando hg revert ci fornisce un ulteriore grado di sicurezza salvando il nostro file modificato con una estensione .orig. + Il comando hg revert ci fornisce un ulteriore grado di protezione salvando il nostro file modificato con un'estensione .orig. &interaction.daily.revert.status; Fate attenzione ai file <filename>.orig</filename> - È estremamente improbabile che stiate usando Mercurial per gestire file con estensione .orig o persino che siate interessati al contenuto di quei file. Nel caso, comunque, è utile ricordare che hg revert sovrascriverà incondizionatamente un file con estensione .orig esistente. Per esempio, se avete già un file foo.orig quando ritornate alla versione precedente del file foo, il contenuto di foo.orig verrà ~clobbered~. + È estremamente improbabile che stiate usando Mercurial per gestire file con estensione .orig o persino che siate interessati al contenuto di quei file. Nel caso, comunque, è utile ricordare che hg revert sovrascriverà incondizionatamente un file con estensione .orig esistente. Per esempio, se avete già un file foo.orig quando ritornate alla versione precedente del file foo, il contenuto di foo.orig verrà cestinato. Ecco un riepilogo dei casi che il comando hg revert è in grado di gestire. Li descriveremo in dettaglio nella prossima sezione. - Se modificate un file, lo ripristinerà a suo stato non modificato. + Se modificate un file, il comando lo ripristinerà al suo stato non modificato. - Se usate hg add su un file, annullerà lo stato di aggiunto del file ma lascerà intatti i contenuti del file. + Se usate hg add su un file, hg revert annullerà lo stato di aggiunto del file ma lascerà intatti i contenuti del file. - Se cancellate un file senza dirlo a Mercurial, ripristinerà il file con i suoi contenuti intatti. + Se cancellate un file senza dirlo a Mercurial, il comando ripristinerà i contenuti del file. - Se usate il comando hg remove per cancellare un file, annullerà lo stato di rimosso del file e ne riprisinterà i contenuti intatti. + Se usate il comando hg remove per cancellare un file, hg revert annullerà lo stato di rimosso del file e ne riprisinterà i contenuti. Errori nella gestione dei file - Il comando hg revert è utile non solo per i file modificati. Vi permette di invertire i risultati di tutti i comandi Mercurial di gestione dei file&emdash;hg add, hg remove, e così via. - - Se usate hg add su un file, poi decidete che in effetti non volete che Mercurial ne tenga traccia, usate hg revert per annullare l'operazione di aggiunta. Non preoccupatevi, Mercurial non modificherà il file in alcun modo, ma si limiterà a eliminare il contrassegno per quel file. + Il comando hg revert non è utile solo per i file modificati, ma vi permette di invertire i risultati di tutti i comandi Mercurial di gestione dei file come hg add, hg remove e così via. + + Se usate hg add su un file, poi decidete che in effetti non volete che Mercurial ne tenga traccia, potete usare hg revert per annullare l'operazione di aggiunta. Non preoccupatevi, Mercurial non modificherà il file in alcun modo, ma si limiterà a eliminare il contrassegno per quel file. &interaction.daily.revert.add; @@ -128,9 +128,9 @@ Gestire i cambiamenti inseriti - Considerate il caso in cui avete inserito un cambiamento a e subito dopo un altro cambiamento b basato sul precedente, poi realizzate che il cambiamento a era sbagliato. Mercurial vi consente di ritirare un intero changeset automaticamente e di costruire blocchi che vi permettono di invertire a mano parte di un changeset. - - Prima di leggere questa sezione, c'è una cosa che dovete tenere a mente: il comando hg backout annulla gli effetti di un cambiamento effettuando una aggiunta alla cronologia del vostro repository, non modificandola o eliminandone una parte. È lo strumento giusto da usare se state correggendo un bug, ma non se state cercando di annullare qualche cambiamento che ha conseguenze catastrofiche. Per trattare con questi, leggete la . + Considerate il caso in cui avete inserito un cambiamento a e subito dopo un altro cambiamento b basato sul precedente, poi realizzate che il cambiamento a era sbagliato. Mercurial vi consente di ritirare sia un intero changeset automaticamente, sia certi mattoni da costruzione che vi permettono di invertire a mano parte di un changeset. + + Prima di leggere questa sezione, c'è una cosa che dovete tenere a mente: il comando hg backout annulla gli effetti di un cambiamento effettuando un'aggiunta alla cronologia del vostro repository invece di modificarla o di eliminarne una parte. È lo strumento giusto da usare se state correggendo un bug, ma non se state cercando di annullare qualche cambiamento che potrebbe avere conseguenze catastrofiche. Per trattare con questi ultimi, leggete la . Ritirare un changeset @@ -141,7 +141,7 @@ &interaction.backout.init; - Il comando hg backout prende un singolo identificatore di changeset come argomento; questo è il changeset da annullare. Normalmente, hg backout vi presenterà un editor di testo per farvi scrivere un messaggio di commit, in modo che possiate registrare il motivo per cui state ritirando il cambiamento. In questo esempio, forniremo un messaggio di commit sulla riga di comando usando l'opzione option. + Il comando hg backout prende come argomento un singolo identificatore di changeset che indica il changeset da annullare. Normalmente, hg backout vi presenterà un editor di testo per farvi scrivere un messaggio di commit, in modo che possiate registrare il motivo per cui state ritirando il cambiamento. In questo esempio, forniremo un messaggio di commit sulla riga di comando usando l'opzione . @@ -181,7 +181,7 @@ &interaction.backout.non-tip.cat; - Come illustrato nella rappresentazione grafica della cronologia nella , Mercurial inserisce ancora un cambiamento in questo tipo di situazione (il nodo rettangolare è quello che Mercurial inserisce automaticamente) ma il grafo delle revisioni ora è diverso. Prima che Mercurial cominci il processo di ritiro, mantiene in memoria l'identità del genitore corrente della directory di lavoro. Poi ritira il changeset indicato e inserisce quello come un changeset. Infine, incorpora il genitore precedente della directory di lavoro, ma notate che non esegue il commit dei risultati dell'unione. Il repository ora contiene due teste, e la directory di lavoro è in uno ~stato di merge~. + Come illustrato nella rappresentazione grafica della cronologia nella , Mercurial inserisce ancora un cambiamento in questo tipo di situazione (il nodo rettangolare è quello che Mercurial inserisce automaticamente) ma il grafo delle revisioni ora è diverso. Prima che Mercurial cominci il processo di ritiro, mantiene in memoria l'identità del genitore corrente della directory di lavoro. Poi ritira il changeset indicato e inserisce quel genitore come un changeset. Infine, incorpora il genitore precedente della directory di lavoro, ma notate che non esegue il commit dei risultati dell'unione. Il repository ora contiene due teste e la directory di lavoro contiene i risultati di un'unione.

Ritiro automatico di un changeset diverso dalla punta tramite il comando <command role="hg-cmd">hg backout</command> @@ -191,21 +191,21 @@ - Il risultato è che siete tornati indietro a dove eravate, solo con una parte aggiuntiva di cronologia che annulla gli effetti del changeset che volevate ritirare. - - Potreste chiedervi perché Mercurial non effettua il commit dei risultati dell'unione che ha eseguito. Il motivo è che Mercurial si comporta in maniera conservativa: di solito un'unione ha maggiori probabilità di contenere errori rispetto all'annullamento degli effetti del changeset di punta, quindi il vostro lavoro si troverà più al sicuro se prima ispezionate (e verificherete!) i risultati dell'unione e solo poi li inserite nel repository. + Il risultato è che siete tornati indietro a dove eravate, ma con una parte aggiuntiva di cronologia che annulla gli effetti del changeset che volevate ritirare. + + Potreste chiedervi perché Mercurial non effettua il commit dei risultati dell'unione che ha eseguito. Il motivo è che Mercurial si comporta in maniera conservativa: di solito un'unione ha maggiori probabilità di contenere errori rispetto all'annullamento degli effetti del changeset di punta, quindi il vostro lavoro si troverà più al sicuro se prima ispezionate (e verificate!) i risultati dell'unione e solo poi li inserite nel repository. Usate sempre l'opzione <option role="hg-opt-backout">--merge</option> - In effetti, dato che l'opzione farà la cosa giusta a prescindere dal fatto che il changeset sia quello di punta o meno (i.e. non cercherà di eseguire un'unione se state ritirando la punta, dato che non ce n'è bisogno), dovreste usare sempre questa opzione quando eseguite il comando hg backout. + In effetti, dato che l'opzione farà la cosa giusta a prescindere dal fatto che il changeset sia quello di punta o meno (i.e. non cercherà di eseguire un'unione se state ritirando la punta, dato che non ce n'è bisogno), dovreste usare sempre questa opzione quando invocate il comando hg backout. Controllare meglio il processo di ritiro - Sebbene vi abbia raccomandato di usare sempre l'opzione quando ritirate un cambiamento, il comando hg backout vi permette di decidere come incorporare un changeset ritirato. Avrete raramente bisogno di controllare il processo di ritiro a mano, ma potrebbe essere utile capire quello che il comando hg backout fa per voi automaticamente. Per illustrare questo, cloniamo il nostro primo repository, ma omettiamo il cambiamento ritirato che contiene. + Sebbene vi abbia raccomandato di usare sempre l'opzione quando ritirate un cambiamento, il comando hg backout vi permette di decidere come incorporare un changeset ritirato. Avrete raramente bisogno di controllare il processo di ritiro a mano, ma potrebbe essere utile capire quello che il comando hg backout fa per voi automaticamente. Per illustrare queste operazioni, cloniamo il nostro primo repository, ma omettiamo il cambiamento ritirato che contiene. &interaction.backout.manual.clone; @@ -217,7 +217,7 @@ &interaction.backout.manual.log; - Ancora, è facile vedere quello che è successo guardando al grafo della cronologia delle revisioni, nella . Questo chiarifica che quando usiamo hg backout per ritirare un cambiamento diverso dalla punta, Mercurial aggiunge una nuova testa al repository (il cambiamento che ha inserito ha la forma di un rettangolo). + Ancora una volta, è facile vedere quello che è successo guardando il grafo della cronologia delle revisioni nella . Questo grafo chiarifica che quando usiamo hg backout per ritirare un cambiamento diverso dalla punta, Mercurial aggiunge una nuova testa al repository (il cambiamento inserito ha la forma di un rettangolo).

Ritirare un cambiamento tramite il comando <command role="hg-cmd">hg backout</command> @@ -227,7 +227,7 @@ - Dopo che il comando hg backout ha terminato, lascia il nuovo changeset ritirato come il genitore della directory di lavoro. + Dopo che il comando hg backout ha terminato, lascia il nuovo changeset ritirato come genitore della directory di lavoro. &interaction.backout.manual.parents; @@ -278,33 +278,33 @@ Il comando hg backout esegue un aggiornamento, un inserimento, un'unione e un altro inserimento per dare al meccanismo di unione la possibilità di fare il miglior lavoro possibile nel gestire tutte le modifiche avvenute tra il cambiamento che state ritirando e la revisione di punta corrente. - Se state ritirando un cambiamento che si trova 100 revisioni indietro nella cronologia del vostro progetto, le probabilità che il comando patch sia in grado di applicare un diff invertito in maniera pulita non sono molto alte, perché i cambiamenti intercorsi avranno probabilmente rotto il contesto utilizzato da patch per determinare se può applicare una patch (se questo vi sembra incomprensibile, leggete FIXME per una discussione sul comando patch). In più, il meccanismo di unione di Mercurial riesce gestire i cambiamenti di nome e permessi per file e directory e le modifiche ai file binari, mentre patch non è in grado di farlo. + Se state ritirando un cambiamento che si trova 100 revisioni indietro nella cronologia del vostro progetto, le probabilità che il comando patch sia in grado di applicare un diff invertito in maniera pulita non sono molto alte, perché i cambiamenti intercorsi avranno probabilmente rovinato il contesto utilizzato da patch per determinare se può applicare una patch (se questo vi sembra incomprensibile, leggete FIXME per una discussione sul comando patch). In più, il meccanismo di unione di Mercurial riesce a gestire i cambiamenti di nome e di permessi per file e directory e le modifiche ai file binari, mentre patch non è in grado di farlo. Modifiche che non avrebbero mai dovuto essere fatte - Quasi sempre, il comando hg backout è esattamente quello che vi serve se volete annullare gli effetti di un cambiamento. Lascia una registrazione permanente di quello che avete fatto, sia quando avete inserito il changeset originale che quando avete successivamente rimesso in ordine. - - In rare occasioni, comunque, potreste scoprire di aver inserito un cambiamento che non dovrebbe essere presente nel repository proprio per niente. Per esempio, sarebbe molto inusuale, e di solito considerato un errore, inserire in un repository i file oggetto di un progetto software insieme ai suoi file sorgente. I file oggetto non hanno praticamente alcun valore intrinserco e sono grandi, quindi aumentano la dimensione del repository e il tempo necessario a clonarlo o a estrarne i cambiamenti. - - Prima di illustrare le opzioni che avete se eseguite il commit di un cambiamento da sacchetto di carta marrone (quel tipo di modifiche così cattive che vorreste nascondere la testa in un sacchetto di carta marrone), lasciatemi discutere alcuni approcci che probabilmente non funzioneranno. - - Dato che Mercurial tratta la cronologia in maniera cumulativa&emdash;ogni cambiamento si basa su tutti i cambiamenti che lo precedono&emdash;in genere non potete far semplicemente sparire i cambiamenti disastrosi. L'unica eccezione è quando avete appena inserito una modifica e non è stata ancora propagata verso qualche altro repository. In questo caso, potete tranquillamente usare il comando hg rollback, come descritto nella . - - Dopo che avete trasmesso un cambiamento sbagliato a un altro repository, potreste anocra usare hg rollback per far scomparire la vostra copia locale del cambiamento, ma questa azione non avrà le conseguenze che volete. Il cambiamento sarà ancora presente nel repository remoto, quindi riapparirà nel vostro repository locale la prossima volta che ne estrarrete i cambiamenti. - - Se vi trovate in una situazione come questa e sapete verso quali repository si è propagato il vostro cambiamento sbagliato, potete provare a sbarazzarvi del cambiamento in ognuno di quei repository. Questa, naturalmente, non è una soluzione soddisfacente: se mancate anche un singolo repository quando state ripulendo, il cambiamento sarà ancora là fuori e potrebbe propagarsi ulteriormente. + Quasi sempre, il comando hg backout è esattamente quello che vi serve se volete annullare gli effetti di un cambiamento. Il comando lascia una registrazione permanente di quello che avete fatto, sia quando avete inserito il changeset originale che quando avete successivamente rimesso in ordine. + + In rare occasioni, comunque, potreste scoprire di aver inserito un cambiamento che non dovrebbe essere presente nel repository proprio per niente. Per esempio, sarebbe molto inusuale, e di solito considerato un errore, inserire in un repository i file oggetto di un progetto software insieme ai suoi file sorgente. I file oggetto non hanno praticamente alcun valore intrinseco e sono grandi, quindi aumentano la dimensione del repository e il tempo necessario a clonarlo o a estrarne i cambiamenti. + + Prima di illustrare le opzioni a vostra disposizione se eseguite il commit di un cambiamento da sacchetto di carta marrone (quel tipo di modifiche talmente infelici che vorreste nascondere la testa in un sacchetto di carta marrone), lasciatemi discutere alcuni approcci che probabilmente non funzioneranno. + + Dato che Mercurial tratta la cronologia in maniera cumulativa&emdash;ogni cambiamento si basa su tutti i cambiamenti che lo precedono&emdash;in genere non è possibile far semplicemente sparire i cambiamenti disastrosi. L'unica eccezione capita quando avete appena inserito una modifica che non è stata ancora propagata verso qualche altro repository. In questo caso, potete tranquillamente usare il comando hg rollback, come descritto nella . + + Dopo che avete trasmesso un cambiamento sbagliato a un altro repository, potreste ancora usare hg rollback per far scomparire la vostra copia locale del cambiamento, ma questa azione non avrà le conseguenze che volete. Il cambiamento sarà ancora presente nel repository remoto, quindi riapparirà nel vostro repository locale la prossima volta che effettuerete un'estrazione. + + Se vi trovate in una situazione come questa e sapete verso quali repository si è propagato il vostro cambiamento sbagliato, potete provare a sbarazzarvi del cambiamento in ognuno di quei repository. Questa, naturalmente, non è una soluzione soddisfacente: se tralasciate anche un singolo repository quando state ripulendo, il cambiamento sarà ancora là fuori e potrebbe propagarsi ulteriormente. Se avete inserito uno o più cambiamenti dopo il cambiamento che vorreste veder sparire, le vostre opzioni si riducono ulteriormente. Mercurial non offre alcun modo per fare un buco nella cronologia lasciando gli altri changeset intatti. Ritirare un'unione - Dato che le unioni sono spesso complicate, si sono sentiti casi di unioni gravemente rovinate, ma i cui risultati sono stati erroneamente inseriti in un repository. Mercurial fornisce un'importante protezione contro le unioni sbagliate rifiutandosi di eseguire il commit di file non risolti, ma l'ingenuità umana garantisce che è ancora possibile mettere sottosopra un'unione e inserirla. - - Data un'unione sbagliata che è stata inserita, di solito il miglior modo di affrontarla è semplicemente provare a riparare il danno a mano. Un completo disastro che non può essere corretto a mano dovrebbe essere molto raro, ma il comando hg backout può aiutare a rendere la pulizia più semplice. Offre un'opzione , che vi consente di specificare a quale genitore tornare quando state ritirando un'unione. + Dato che le unioni sono spesso complicate, si sono sentiti casi di unioni gravemente rovinate, ma i cui risultati sono stati erroneamente inseriti in un repository. Mercurial fornisce un'importante protezione contro le unioni sbagliate rifiutandosi di eseguire il commit di file irrisolti, ma l'ingenuità umana garantisce che sia ancora possibile mettere sottosopra un'unione e registrarne i risultati. + + Di solito, il modo migliore per affrontare la registrazione di un'unione è semplicemente quello di provare a riparare il danno a mano. Un completo disastro che non possa venire corretto a mano dovrebbe essere molto raro, ma il comando hg backout può aiutare a rendere la pulizia più semplice attraverso l'opzione , che vi consente di specificare a quale genitore tornare quando state ritirando un'unione.

Un'unione sbagliata @@ -314,13 +314,13 @@ - Supponete di avere un grafo delle revisioni simile a quello della . Quello che vorremmo fare è rifare l'unione tra le revisioni 2 e 3. + Supponete di avere un grafo delle revisioni simile a quello della . Ci piacerebbe rifare l'unione tra le revisioni 2 e 3. Potremmo eseguire questa operazione nel modo seguente. - Invocare hg backout --rev=4 --parent=2. Questo dice al comando hg backout di ritirare la revisione 4, che è l'unione sbagliata, e di scegliere il genitore 2, uno dei genitori dell'unione, nel momento di decidere quale revisione preferire. L'effetto del comando può essere visto nella . + Invocare hg backout --rev=4 --parent=2. Questo dice al comando hg backout di ritirare la revisione 4, che è l'unione sbagliata, e di scegliere il genitore 2, uno dei genitori dell'unione, al momento di decidere quale revisione preferire. L'effetto del comando può essere visto nella .

Ritirare l'unione favorendo un genitore @@ -368,51 +368,51 @@ Proteggervi dai cambiamenti che vi sono <quote>sfuggiti</quote> - Se avete inserito alcuni cambiamenti nel vostro repositor locale e li avete propagati da qualche altra parte, questo non costituisce necessariamente un disastro. Potete proteggervi prevenendo la comparsa di alcuni tipi di changeset sbagliati. Questo è particolarmente facile se il vostro gruppo di lavoro di solito estrae i cambiamenti da un repository centrale. + Se avete inserito alcuni cambiamenti nel vostro repository locale e li avete propagati da qualche altra parte, questo non è necessariamente un disastro. Potete proteggervi prevenendo la comparsa di alcuni tipi di changeset sbagliati. Questo è particolarmente facile se di solito il vostro gruppo di lavoro estrae i cambiamenti da un repository centrale. Configurando alcuni hook su quel repository per validare i changeset in entrata (si veda il FIXME), potete automaticamente evitare che alcuni tipi di changeset sbagliati compaiano nel repository centrale. Con una tale configurazione, alcuni tipi di changeset sbagliati tenderanno naturalmente a estinguersi perché non possono propagarsi verso il repository centrale. Ancora meglio, questo accade senza alcun bisogno di un intervento esplicito. - Per esempio, un hook sui cambiamenti in entrata che verifica che un changeset si riesca effettivamente a compilare può prevenire involontari guasti al processo di assemblaggio. + Per esempio, un hook sui cambiamenti in entrata programmato per verificare che un changeset si possa effettivamente compilare è in grado di prevenire involontari guasti al processo di assemblaggio. Cosa fare con i cambiamenti sensibili che sfuggono - Persino un progetto gestito con attenzione può subire uno sfortunato evento come il commit e l'incontrollata propagazione di un file che contiene password importanti. - - Se qualcosa del genere dovesse accadervi e le informazioni che vengono accidentalmente propagate sono davvero sensibili, il vostro primo passo dovrebbe essere quello di mitigare l'effetto della perdita senza cercare di controllare la perdita stessa. Se non siete sicuri al 100% di sapere esattamente chi può aver visto i cambiamenti, dovreste immediatamente cambiare le password, cancellare le carte di credito, o trovare qualche altro modo per assicurarvi che le informazioni fuoriuscite non siano più utili. In altre parole, assumete che il cambiamento si sia propagato in lungo e in largo e che non ci sia più niente che potete fare. - - Potreste sperare che ci sia qualche meccanismo che potete usare per scoprire chi ha visto un cambiamento o per cancellare il cambiamento permanentemente e ovunque, ma ci sono buone ragioni per cui queste operazioni non sono possibili. - - Mercurial non fornisce una ~audit trail~ di chi ha estratto i cambiamenti da un repository, perché di solito questa informazione è impossibile registrare o è facile da imbrogliare. In un ambiente multi-utente o di rete, dovreste quindi dubitare estremamente di voi stessi se pensate di aver identificato ogni luogo in cui un cambiamento sensibile si è propagato. Non dimenticate che le persone possono spedire pacchetti via email, salvare i propri dati su altri computer tramite il software di backup, trasportare i repository su chiavi USB e trovare altri modi completamente innocenti di confondere i vostri tentativi di ritrovare ogni copia di un cambiamento problematico. - - In più, Mercurial non vi fornisce un modo per far completamente sparire un changeset dalla cronologia perché non c'è alcun modo di imporre la sua sparizione, dato che qualcuno potrebbe facilmente modificare la propria copia di Mercurial per ignorare quelle direttive. E poi, se anche Mercurial fornisse questa funzionalità, qualcuno che semplicemente non abbia estratto il changeset che fa sparire questo file non ne godrebbe gli effetti, né lo farebbero i ~web crawler~ che visitano un repository al momento sbagliato, i backup del disco, o altri meccanismi. In effetti, nessun sistema distribuito di controllo di revisione può far sparire dati in maniera affidabile. Dare l'illusione di un controllo di questo tipo potrebbe facilmente fornirvi un falso senso di sicurezza, peggiorando le cose rispetto a non darvela affatto. + Persino un progetto gestito con attenzione può subire eventi sfortunati come il commit di un file che contiene password importanti e la sua incontrollata propagazione. + + Se qualcosa del genere dovesse accadervi e le informazioni che vengono accidentalmente propagate fossero davvero sensibili, il vostro primo passo dovrebbe essere quello di mitigare l'effetto della perdita senza cercare di controllare la perdita stessa. Se non siete sicuri al 100% di sapere esattamente chi può aver visto i cambiamenti, dovreste immediatamente cambiare le password, cancellare le carte di credito, o trovare qualche altro modo per assicurarvi che le informazioni fuoriuscite non siano più utili. In altre parole, assumete che il cambiamento si sia propagato in lungo e in largo e che non ci sia più niente che potete fare. + + Potreste sperare che ci sia qualche meccanismo da usare per scoprire chi ha visto un cambiamento o per cancellare il cambiamento permanentemente e ovunque, ma ci sono buone ragioni per cui queste operazioni non sono possibili. + + Mercurial non fornisce una traccia registrata di chi ha estratto i cambiamenti da un repository, perché di solito questa informazione è impossibile da raccogliere o è facile da falsificare. In un ambiente multi-utente o di rete, dovreste quindi dubitare fortemente di voi stessi se pensate di aver identificato ogni luogo in cui un cambiamento sensibile si è propagato. Non dimenticate che le persone possono spedire allegati via email, salvare i propri dati su altri computer tramite il software di backup, trasportare i repository su chiavi USB e trovare altri modi completamente innocenti di confondere i vostri tentativi di rintracciare ogni copia di un cambiamento problematico. + + In più, Mercurial non vi fornisce un modo per far completamente sparire un changeset dalla cronologia perché non c'è alcun modo di imporre la sua sparizione, dato che qualcuno potrebbe facilmente modificare la propria copia di Mercurial per ignorare quelle direttive. E poi, se anche Mercurial fornisse questa funzione, qualcuno che semplicemente non abbia estratto il changeset che fa sparire questo file non ne godrebbe gli effetti, né lo farebbero i programmi di indicizzazione web che visitano un repository al momento sbagliato, i backup del disco, o altri meccanismi. In effetti, nessun sistema distribuito di controllo di revisione può far sparire dati in maniera affidabile. Dare l'illusione di un controllo di questo tipo potrebbe facilmente fornirvi un falso senso di sicurezza, peggiorando le cose rispetto a non darvela affatto. Trovare la causa di un bug - Mentre va benissimo essere in grado di ritirare un changeset che ha introdotto un bug, questo richiede che sappiate quale changeset va ritirato. Mercurial offre un inestimabile comando, chiamato hg bisect, che vi aiuta ad automatizzare questo processo e a completarlo in maniera molto efficiente. + Essere in grado di ritirare un changeset che ha introdotto un bug va benissimo, ma richiede che sappiate quale changeset va ritirato. Mercurial offre un inestimabile comando, chiamato hg bisect, che vi aiuta ad automatizzare questo processo e a completarlo in maniera molto efficiente. L'idea dietro al comando hg bisect è che un changeset ha introdotto una modifica di comportamento che potete identificare con un semplice test binario di successo o fallimento. Non sapete quale porzione di codice ha introdotto il cambiamento, ma sapete come verificare la presenza del bug. Il comando hg bisect usa il vostro test per dirigere la propria ricerca del changeset che ha introdotto il codice che ha causato il bug. Ecco alcuni scenari per aiutarvi a capire come potreste applicare questo comando. - La versione più recente del vostro software ha un bug che non ricordate fosse presente alcune settimane prima, ma non sapete quando il bug è stato introdotto. Qui, i vostri test binari controllano la presenza di quel bug. + La versione più recente del vostro software ha un bug che non ricordate fosse presente alcune settimane prima, ma non sapete quando il bug è stato introdotto. Qui, il vostro test binario controlla la presenza di quel bug. Avete corretto un bug in tutta fretta e ora è il momento di chiudere la relativa voce nel database dei bug del vostro gruppo. Il database dei bug richiede un identificatore di changeset quando chiudete una voce, ma non ricordate in quale changeset avete corretto il bug. Ancora una volta, il vostro test binario controlla la presenza del bug. - Il vostro software funziona correttamente, ma più lento del 15% rispetto all'ultima volta che avete compiuto questa misurazione. Volete sapere quale changeset ha introdotto la perdita di prestazioni. In questo caso, il vostro test binario misura le prestazioni del vostro software per vedere se è veloce o lento. + Il vostro software funziona correttamente, ma è più lento del 15% rispetto all'ultima volta che avete compiuto questa misurazione. Volete sapere quale changeset ha introdotto il calo di prestazioni. In questo caso, il vostro test binario misura le prestazioni del vostro software per vedere se è veloce o lento. La dimensione dei componenti del progetto che rilasciate è esplosa di recente e sospettate che qualcosa sia cambiato nel modo in cui assemblate il progetto. Da questi esempi, dovrebbe essere chiaro che il comando hg bisect non è utile solo per trovare le cause dei bug. Potete usarlo per trovare qualsiasi proprietà emergente di un repository (qualsiasi cosa che non potete trovare con una semplice ricerca di testo sui file contenuti nell'albero) per la quale sia possibile scrivere un test binario. - Ora introdurremo un po' di terminologia, giusto per chiarire quali sono le parti del processo di ricerca di cui siete responsabili 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 come nome e bisezionare come verbo 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 scala malamente. Se ci volessero dieci minuti per collaudare un singolo changeset e aveste 10.000 changeset nel vostro repository, 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 passare più di 40 ore di attesa per trovare il changeset che ha introdotto il vostro bug. + 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 aveste 10.000 changeset nel vostro repository, 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). @@ -431,7 +431,7 @@ &interaction.bisect.init; - Simuleremo un progetto che ha un bug in modo molto semplice: creiamo cambiamenti elementari in un ciclo e nomineremo uno specifico cambiamento che conterrà il bug. Questo ciclo crea 35 changeset, ognuno dei quali aggiunge un singolo file al repository. Rappresenteremo il nostro bug con un file che contiene il testo i have a gub. + Simuleremo un progetto con un bug in modo molto semplice: creiamo cambiamenti elementari in un ciclo e designamo uno specifico cambiamento che conterrà il bug. Questo ciclo crea 35 changeset, ognuno dei quali aggiunge un singolo file al repository. Rappresenteremo il nostro bug con un file che contiene il testo i have a gub. &interaction.bisect.commits; @@ -453,19 +453,19 @@ Il comando aggiorna la directory di lavoro a quel changeset e il processo ricomincia da capo. - Il processo termina quando hg bisect identifica un unico cambiamento che contrassegna il punto in cui il vostro test passa dallo stato di successo a quello di fallimento. + Il processo termina quando hg bisect identifica un unico cambiamento che indica il punto in cui il vostro test passa dallo stato di successo a quello di fallimento. Per cominciare la ricerca, dobbiamo eseguire il comando hg bisect --reset. &interaction.bisect.search.init; - Nel nostro caso, il test binario che usiamo è semplice: controlliamo per vedere se qualche file nel repository contiene la stringa i have a gub. Se è così, questo changeset contiene il cambiamento che ha causato il bug. Per convenzione, un changeset che ha la proprietà che stiamo cercando è guasto, mentre uno che non ce l'ha è corretto. - - Quasi sempre, la revisione su cui la directory di lavoro è sincronizzata (di solito, la punta) esibisce già il problema introdotto dal cambiamento malfunzionante, quindi la contrassegneremo come guasta. + Nel nostro caso, il test binario che usiamo è semplice: controlliamo il repository per vedere se qualche file contiene la stringa i have a gub. Se è così, questo changeset contiene il cambiamento che ha causato il bug. Per convenzione, un changeset che ha la proprietà che stiamo cercando è guasto, mentre uno che non ce l'ha è funzionante. + + Quasi sempre, la revisione su cui la directory di lavoro è sincronizzata (di solito, la punta) esibisce già il problema introdotto dal cambiamento malfunzionante, quindi la indicheremo come guasta. &interaction.bisect.search.bad-init; - Il nostro compito successivo consiste nel nominare un changeset che sappiamo non contenere il bug, in modo che il comando hg bisect possa circoscrivere la ricerca tra il primo changeset corretto e il primo changeset guasto. Nel nostro caso, sappiamo che la revisione 10 non conteneva il bug. (Spiegherò meglio come scegliere il primo changeset corretto più avanti.) + Il nostro compito successivo consiste nel nominare un changeset che sappiamo non contenere il bug, in modo che il comando hg bisect possa circoscrivere la ricerca tra il primo changeset funzionante e il primo changeset guasto. Nel nostro caso, sappiamo che la revisione 10 non conteneva il bug. (Spiegherò meglio come scegliere il primo changeset funzionante più avanti.) &interaction.bisect.search.good-init; @@ -476,7 +476,7 @@ Ha aggiornato la directory di lavoro al prossimo changeset da collaudare e ci ha detto quale changeset sta collaudando. - Ora eseguiamo il nostro test nella directory di lavoro, usando il comando grep per vedere se il nostro file guasto è presente. Se c'è, questa revisione è guasta, altrimenti è corretta. + Ora eseguiamo il nostro test nella directory di lavoro, usando il comando grep per vedere se il nostro file guasto è presente. Se c'è, questa revisione è guasta, altrimenti è funzionante. &interaction.bisect.search.step1; @@ -498,7 +498,7 @@ Riordinare dopo la vostra ricerca - Quando avete finito di usare il comando hg bisect in un repository, potete invocare il comando hg bisect --reset per scartare le informazioni che venivano usate per guidare la vostra ricerca. Il comando non usa molto spazio, quindi non importa se vi dimenticate di effettuare questa esecuzione. Tuttavia, hg bisect non vi permetterà di cominciare una nuova ricerca in quel repository fino a quando non avrete eseguito hg bisect --reset. + Quando avete finito di usare il comando hg bisect in un repository, potete invocare il comando hg bisect --reset in modo da scartare le informazioni che venivano usate per guidare la vostra ricerca. Il comando non usa molto spazio, quindi non è un problema se vi dimenticate di effettuare questa invocazione. Tuttavia, hg bisect non vi permetterà di cominciare una nuova ricerca in quel repository fino a quando non avrete eseguito hg bisect --reset. &interaction.bisect.search.reset; @@ -508,15 +508,15 @@ Suggerimenti per trovare efficacemente i bug - Fornire informazioni consistenti - - Il comando hg bisect vi richiede di riportare correttamente il risultato di ogni test che eseguite. Se dite al comando che un test è fallito quando in realtà ha avuto successo, potrebbe essere in grado di scoprire l'inconsistenza. Se può identificare un'incosistenza nei vostri resoconti, vi dirà che un particolare changeset è sia corretto che guasto. Tuttavia, non è in grado di farlo perfettamente ed è ugualmente probabile che vi restituisca il changeset sbagliato come causa del bug. - - - - Automatizzare il più possibile - - Quando ho cominciato a usare il comando hg bisect, ho provato a eseguire alcune volte i miei test a mano sulla riga di comando. Questo è un approccio che almeno a me non si addice. Dopo alcune prove, ho visto che stavo facendo abbastanza errori da dover ricominciare le mie ricerche diverse volte prima di riuscire a ottenere i risultati corretti. + Fornite informazioni consistenti + + Il comando hg bisect vi richiede di riportare 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. + + + + Automatizzate il più possibile + + Quando ho cominciato a usare il comando hg bisect, ho provato a eseguire alcune volte i miei test a mano sulla riga di comando. Questo non è l'approccio adatto, almeno per me. Dopo alcune prove, mi sono accorto che stavo facendo abbastanza errori da dover ricominciare le mie ricerche diverse volte prima di riuscire a ottenere i risultati corretti. I miei problemi iniziali nel guidare a mano il comando hg bisect si sono verificati anche con ricerche semplici su repository di piccole dimensioni, ma se il problema che state cercando è più sottile, o se il numero di test che hg bisect deve eseguire aumenta, la probabilità che un errore umano rovini la ricerca è molto più alta. Una volta che ho cominciato ad automatizzare i miei test, ho ottenuto risultati molto migliori. @@ -526,17 +526,17 @@ fornite sempre informazioni consistenti al comando hg bisect. - Nel mio esempio precedente, il comando grep verifica il sintomo e l'istruzione if prende il risultato di questo controllo e si assicura di fornire la stessa informazione al comando hg bisect. La funzione mytest ci permette di riprodurre insieme queste due operazioni, in modo che ogni test sia uniforme e consistente. - - - - Controllare i vostri risultati - - Dato che il risultato di una ricerca con hg bisect è solo tanto buona quanto le informazioni che passate al comando, non prendete il changeset che vi indica come la verità assoluta. Un modo semplice di effettuare un riscontro sul risultato è quello di eseguire manualmente i vostro test su ognuno dei changeset seguenti. + Nel mio esempio precedente, il comando grep verifica il sintomo e l'istruzione if usa il risultato di questo controllo per assicurarsi di fornire la stessa informazione al comando hg bisect. La funzione mytest ci permette di riprodurre insieme queste due operazioni, in modo che ogni test sia uniforme e consistente. + + + + Controllate i vostri risultati + + Dato che il risultato di una ricerca con hg bisect è solo tanto buono quanto le informazioni che passate al comando, non prendete il changeset che vi indica come la verità assoluta. Un modo semplice di effettuare un riscontro sul risultato è quello di eseguire manualmente il vostro test su ognuno dei changeset seguenti. Il changeset che il comando riporta come la prima revisione guasta. Il vostro test dovrebbe verificare che la revisione è effettivamente guasta. - Il genitore di quel changeset (entrambi i genitori, se è un'unione). Il vostro test dovrebbe verificare che quel changeset è corretto. + Il genitore di quel changeset (entrambi i genitori, se è un'unione). Il vostro test dovrebbe verificare che quel changeset è funzionante. Un figlio di quel changeset. Il vostro test dovrebbe verificare che quel changeset è guasto. @@ -545,21 +545,21 @@ 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 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 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. - - - - Circoscrivete la vostra ricerca in maniera ritardata - - Scegliere il primo changeset corretto e il primo changeset guasto che contrassegneranno i punti estremi della vostra ricerca è spesso facile, ma merita comunque una breve discussione. Dal punto di vista di hg bisect, il changeset più recente è convenzionalmente guasto e il changeset più vecchio è corretto. - - Se avete problemi a ricordare dove si trova un changeset corretto da fornire al comando hg bisect, non potreste fare meglio che collaudare changeset a caso. Ricordatevi di eliminare i contendenti che non possono esibire il bug (magari perché la funzionalità con il bug non era ancora presente) e quelli in cui un altro problema nasconde il bug (come ho discusso in precedenza). + È 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 diverso bug bloccante 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 indicare 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 si blocca, allora sia il vostro bug bloccante che il bug bloccante non correlato che lo maschera sembreranno la stessa cosa e fuorvieranno hg bisect. + + Un'altra situazione utile per 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. + + + + Circoscrivete la vostra ricerca in maniera approssimativa + + Scegliere il primo changeset funzionante e il primo changeset guasto che rappresenteranno i punti estremi della vostra ricerca è spesso facile, ma merita comunque una breve discussione. Dal punto di vista di hg bisect, il changeset più recente è convenzionalmente guasto e il changeset più vecchio è funzionante. + + Se avete problemi a ricordare dove trovare un changeset funzionante da fornire al comando hg bisect, non potreste fare meglio che collaudare changeset a caso. Ricordatevi di eliminare i contendenti che non possono esibire il bug (magari perché la funzione con il bug non era ancora presente) e quelli in cui un altro problema nasconde il bug (come ho discusso in precedenza). Anche se i vostri tentativi si concludono in anticipo di migliaia di changeset o di mesi di cronologia, aggiungerete solo una manciata di test al numero totale che hg bisect deve eseguire, grazie al suo comportamento logaritmico.