# HG changeset patch # User Giulio@puck # Date 1250113628 -7200 # Node ID d4de8d288ba62c83eeaefb72e6de4fd66b424d89 # Parent 5b79834be9a69b4dd76255cf5fd6b12dfe352eec Minor changes and translation of code snippets for Ch.9. diff -r 5b79834be9a6 -r d4de8d288ba6 it/ch09-undo.xml --- a/it/ch09-undo.xml Wed Aug 12 16:44:35 2009 +0200 +++ b/it/ch09-undo.xml Wed Aug 12 23:47:08 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à particolarmente efficaci 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 funzioni particolarmente efficaci che vi aiuteranno a isolare le cause dei problemi e a trattarle in maniera appropriata. Cancellare la cronologia locale @@ -26,13 +26,13 @@ &interaction.rollback.status; - 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. + 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 estrarranno 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 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. + 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 esattamente nello stato 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,25 +40,25 @@ L'estrazione sbagliata - È 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. + È 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. - Il comando hg rollback cancellerà scrupolosamente tutti i changeset che avete appena estratto. Mercurial raggruppa tutti i cambiamenti provenienti da una invocazione di hg pull in una singola transazione, quindi un'unica invocazione di hg rollback è tutto quello che vi serve per annullare questo errore. + 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. - Abortire è inutile se avete già trasmesso le modifiche + Abortire una transazione è 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 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 + 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 transazione 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. @@ -71,7 +71,7 @@ Rimediare alle modifiche sbagliate - 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.) + 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 esamina 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. @@ -79,7 +79,7 @@ Se non vogliamo quella modifica, possiamo semplicemente usare hg revert sul file. - &interaction.daily.revert.unmodify; + &interaction.daily.revert.unmodify; Il comando hg revert ci fornisce un ulteriore grado di protezione salvando il nostro file modificato con un'estensione .orig. @@ -99,13 +99,13 @@ 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, hg revert annullerà lo stato di rimosso del file e ne riprisinterà i contenuti. + Se usate il comando hg remove per cancellare un file, hg revert annullerà lo stato di rimosso del file e ne ripristinerà i contenuti. Errori nella gestione dei 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. + 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. @@ -115,7 +115,7 @@ &interaction.daily.revert.remove; - Questo funziona altrettanto bene per un file che avete cancellato a mano senza dirlo a Mercurial (ricordatevi che, nella terminologia di Mercurial, questo file viene detto mancante). + Questo funziona altrettanto bene con un file che avete cancellato a mano senza dirlo a Mercurial (ricordatevi che, nella terminologia di Mercurial, questo file viene detto mancante). &interaction.daily.revert.missing; @@ -151,7 +151,7 @@ &interaction.backout.simple; - Potete vedere che la seconda riga di myfile non è più presente. Un'occhiata all'elenco generato da hg log ci dà un'idea di quello che il comando hg backout ha fatto. + Potete vedere che la seconda riga di miofile non è più presente. Un'occhiata all'elenco generato da hg log ci dà un'idea di quello che il comando hg backout ha fatto. &interaction.backout.simple.log; @@ -177,11 +177,11 @@ &interaction.backout.non-tip.backout; - Se date un'occhiata al contenuto di myfile dopo che l'operazione di ritiro si è conclusa, vedrete che il primo e il terzo cambiamento sono presenti, ma non il secondo. + Se date un'occhiata al contenuto di miofile dopo che l'operazione di ritiro si è conclusa, vedrete che il primo e il terzo cambiamento sono presenti, ma non il secondo. &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 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. + 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 di cominciare il processo di ritiro, Mercurial 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> @@ -217,7 +217,7 @@ &interaction.backout.manual.log; - 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). + Ancora una volta, è facile vedere quello che è successo osservando 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> @@ -235,7 +235,7 @@ &interaction.backout.manual.heads; - Pensiamo a quello che ora ci aspettiamo di vedere come contenuto di myfile. Il primo cambiamento dovrebbe essere presente, perché non lo abbiamo mai ritirato. Il secondo cambiamento non dovrebbe esserci, dato che quello è il cambiamento che abbiamo ritirato. Visto che il grafo della cronologia mostra il terzo cambiamento come una testa separata, non ci aspettiamo di vedere il terzo cambiamento nel contenuto di myfile. + Pensiamo a quello che ora ci aspettiamo di vedere come contenuto di miofile. Il primo cambiamento dovrebbe essere presente, perché non lo abbiamo mai ritirato. Il secondo cambiamento non dovrebbe esserci, dato che quello è il cambiamento che abbiamo ritirato. Visto che il grafo della cronologia mostra il terzo cambiamento come una testa separata, non ci aspettiamo di vedere il terzo cambiamento nel contenuto di miofile. &interaction.backout.manual.cat; @@ -263,18 +263,18 @@ Memorizza il genitore corrente della directory di lavoro. Chiamiamo orig questo changeset. - Esegue l'equivalente di una invocazione di hg update per sincronizzare la directory di lavoro con il changeset che volete ritirare. Chiamiamo backout questo changeset. + Esegue l'equivalente di un'invocazione di hg update per sincronizzare la directory di lavoro con il changeset che volete ritirare. Chiamiamo backout questo changeset. Trova il genitore di quel changeset. Chiamiamo parent questo changeset. - Per ogni file su cui il changeset backout ha avuto effetto, esegue l'equivalente del comando hg revert -r parent su quel file per ripristinare il contenuto che aveva prima che quel changeset venisse inserito. + Per ogni file su cui il changeset backout ha avuto effetto, esegue l'equivalente del comando hg revert -r parent sul file per ripristinare il contenuto che aveva prima che quel changeset venisse inserito. 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. - 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 sembra molto più semplice, ma non funzionerebbe affatto altrettanto bene. + 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. 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. @@ -291,11 +291,11 @@ 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 . + 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 è ancora stata 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 vi trovate in una situazione come questa e sapete quali sono i repository verso cui 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. @@ -304,7 +304,7 @@ 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. + Di solito, il modo migliore per affrontare la registrazione di un'unione sbagliata è 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 @@ -370,7 +370,7 @@ 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 ), 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. + Configurando alcuni hook su quel repository per convalidare i changeset in entrata (si veda il ), 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 programmato per verificare che un changeset si possa effettivamente compilare è in grado di prevenire involontari guasti al processo di assemblaggio. @@ -386,7 +386,7 @@ 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. + 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 conferirvi un falso senso di sicurezza, peggiorando le cose rispetto a non darvela affatto. @@ -395,9 +395,9 @@ 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. + L'idea alla base del comando hg bisect è che un changeset abbia 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 di esempio 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, il vostro test binario controlla la presenza di quel bug. @@ -412,7 +412,7 @@ 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. + 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). @@ -431,7 +431,7 @@ &interaction.bisect.init; - 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. + 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 ho un gub. &interaction.bisect.commits; @@ -459,7 +459,7 @@ &interaction.bisect.search.init; - 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. + Nel nostro caso, il test binario che usiamo è semplice: controlliamo il repository per vedere se qualche file contiene la stringa ho un 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. @@ -484,7 +484,7 @@ &interaction.bisect.search.mytest; - Ora possiamo eseguire un intero passo di collaudo con il singolo comando mytest. + Ora possiamo eseguire un intero passo di collaudo con il singolo comando miotest. &interaction.bisect.search.step2; @@ -510,7 +510,7 @@ 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. + 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. @@ -526,7 +526,7 @@ fornite sempre informazioni consistenti al comando hg bisect. - 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. + 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 miotest ci permette di riprodurre insieme queste due operazioni, in modo che ogni test sia uniforme e consistente. @@ -534,11 +534,11 @@ 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 è funzionante. - - Un figlio di quel changeset. Il vostro test dovrebbe verificare che quel changeset è guasto. + Il changeset che il comando riporta come la prima revisione guasta. Il vostro test dovrebbe verificare che la revisione sia effettivamente guasta. + + Il genitore di quel changeset (entrambi i genitori, se è un'unione). Il vostro test dovrebbe verificare che quel changeset sia funzionante. + + Un figlio di quel changeset. Il vostro test dovrebbe verificare che quel changeset sia guasto. @@ -559,7 +559,7 @@ 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). + Se avete problemi a ricordare dove trovare un changeset funzionante da fornire al comando hg bisect, non potreste fare di 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. diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/auto-snippets.xml --- a/it/examples/auto-snippets.xml Wed Aug 12 16:44:35 2009 +0200 +++ b/it/examples/auto-snippets.xml Wed Aug 12 23:47:08 2009 +0200 @@ -3,30 +3,30 @@ - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + @@ -126,15 +126,15 @@ - - - - - + + + + + - - + + @@ -189,12 +189,12 @@ - - - - + + + + - + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.init.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg init miorepo +$ cd miorepo +$ echo prima modifica >> miofile +$ hg add miofile +$ hg commit -m 'Prima modifica.' +$ echo seconda modifica >> miofile +$ hg commit -m 'Seconda modifica.' + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.manual.backout.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.backout.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,11 @@ + +$ echo terza modifica >> miofile +$ hg commit -m 'Terza modifica.' +$ hg backout -m 'Ritira la seconda modifica.' 1 +ripristino miofile +creata una nuova testa +il changeset 3:f3e79edd2b05 ritira il changeset 1:51969da8cdc5 +il changeset che ha compiuto il ritiro è una nuova testa - ricordatevi di unire +(usate "backout --merge" se volete unire automaticamente) + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.manual.cat.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.cat.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,5 @@ + +$ cat miofile +prima modifica + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.manual.clone.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.clone.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,13 @@ + +$ cd .. +$ hg clone -r1 miorepo nuovorepo +richiedo tutte le modifiche +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 2 changeset con 2 cambiamenti a 1 file +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd nuovorepo + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.manual.heads.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.heads.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,16 @@ + +$ hg heads +changeset: 3:f3e79edd2b05 +tag: tip +parent: 1:51969da8cdc5 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:48:47 2009 +0000 +summary: Ritira la seconda modifica. + +changeset: 2:629da9559a9e +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:48:46 2009 +0000 +summary: Terza modifica. + + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.manual.log.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.log.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,16 @@ + +$ hg log --style compact +3[tip]:1 f3e79edd2b05 2009-06-05 15:48 +0000 bos + Ritira la seconda modifica. + +2 629da9559a9e 2009-06-05 15:48 +0000 bos + Terza modifica. + +1 51969da8cdc5 2009-06-05 15:48 +0000 bos + Seconda modifica. + +0 efd26e99cc79 2009-06-05 15:48 +0000 bos + Prima modifica. + + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.manual.merge.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.merge.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,8 @@ + +$ hg merge +fallimento: modifiche in sospeso non registrate +$ hg commit -m 'Unisce il changeset che ha compiuto il ritiro con la punta precedente.' +$ cat miofile +prima modifica + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.manual.parents.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.parents.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,9 @@ + +$ hg parents +changeset: 2:629da9559a9e +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:48:46 2009 +0000 +summary: Terza modifica. + + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.non-tip.backout.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.non-tip.backout.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,13 @@ + +$ echo terza modifica >> miofile +$ hg commit -m 'Terza modifica.' +$ hg backout --merge -m 'Ritira la seconda modifica.' 1 +ripristino miofile +creata una nuova testa +il changeset 3:af281715005d ritira il changeset 1:51969da8cdc5 +unisco con il changeset 3:af281715005d +unisco miofile +0 file aggiornati, 1 file uniti, 0 file rimossi, 0 file irrisolti +(unione tra rami, ricordatevi di eseguire il commit) + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.non-tip.cat.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.non-tip.cat.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,6 @@ + +$ cat miofile +prima modifica +terza modifica + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.non-tip.clone.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.non-tip.clone.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,13 @@ + +$ cd .. +$ hg clone -r1 miorepo repo-non-di-punta +richiedo tutte le modifiche +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 2 changeset con 2 cambiamenti a 1 file +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd repo-non-di-punta + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.simple.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.simple.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,8 @@ + +$ hg backout -m 'Ritira la seconda modifica.' tip +ripristino miofile +il changeset 2:a4abdbaa35f1 ritira il changeset 1:51969da8cdc5 +$ cat miofile +prima modifica + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/backout.simple.log.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.simple.log.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,13 @@ + +$ hg log --style compact +2[tip] a4abdbaa35f1 2009-06-05 15:48 +0000 bos + Ritira la seconda modifica. + +1 51969da8cdc5 2009-06-05 15:48 +0000 bos + Seconda modifica. + +0 efd26e99cc79 2009-06-05 15:48 +0000 bos + Prima modifica. + + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/bisect.commits.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.commits.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,13 @@ + +$ cambiamento_difettoso=22 +$ for (( i = 0; i < 35; i++ )); do +> if [[ $i = $cambiamento_difettoso ]]; then +> echo 'ho un gub' > miofile$i +> hg commit -q -A -m 'Changeset difettoso.' +> else +> echo 'niente da vedere, circolate' > miofile$i +> hg commit -q -A -m 'Changeset normale.' +> fi +> done + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/bisect.help.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.help.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,40 @@ + +$ hg help bisect +hg bisect [-gbsr] [-c CMD] [REV] + +ricerca di changeset tramite suddivisioni + + Questo comando vi aiuta a cercare changeset che introducono problemi. + Per usarlo, contrassegnate il changeset più recente che esibisce il + problema come guasto, poi contrassegnate l'ultimo changeset libero dal + problema come funzionante. La bisezione aggiornerà la vostra directory di + lavoro a una revisione di collaudo (a meno che l'opzione --noupdate sia + specificata). Una volta che avete effettuato i test, contrassegnate la + directory di lavoro come guasta o funzionante e bisect la aggiornerà a + un altro changeset candidato o vi comunicherà di aver trovato la revisione + guasta. + + Come scorciatoia, potete anche usare l'argomento revisione per + contrassegnare una revisione come funzionante o guasta senza prima + controllarla. + + Se fornite un comando, verrà usato per operare la bisezione in modo + automatico. Lo stato di uscita del comando verrà usato come indicatore per + contrassegnare una revisione come guasta o funzionante. Nel caso lo stato + di uscita sia 0 la revisione viene contrassegnata come funzionante; 125 - + viene saltata; 127 (comando non trovato) - la bisezione verrà bloccata; + qualsiasi altro stato maggiore di zero contrassegnerà la revisione come + guasta. + +opzioni: + + -r --reset inizializza lo stato della bisezione + -g --good contrassegna un changeset come funzionante + -b --bad contrassegna un changeset come guasto + -s --skip salta il collaudo del changeset + -c --command usa un comando per controllare lo stato del changeset + -U --noupdate non aggiorna alla revisione da collaudare + +usate "hg -v help bisect" per vedere le opzioni globali + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/bisect.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.init.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg init miobug +$ cd miobug + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/bisect.search.bad-init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.bad-init.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg bisect --bad + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/bisect.search.good-init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.good-init.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,6 @@ + +$ hg bisect --good 10 +Collaudo il changeset 22:b8789808fc48 (24 changeset rimanenti, ~4 test) +0 file aggiornati, 0 file uniti, 12 file rimossi, 0 file irrisolti + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/bisect.search.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.init.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg bisect --reset + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/bisect.search.mytest.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.mytest.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,13 @@ + +$ miotest() { +$ if grep -q 'ho un gub' * +> then +> risultato=bad +> else +> risultato=good +> fi +> echo il contrassegno di questa revisione è $risultato +> hg bisect --$risultato +> } + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/bisect.search.reset.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.reset.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg bisect --reset + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/bisect.search.rest.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.rest.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,18 @@ + +$ miotest +il contrassegno di questa revisione è good +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 +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 +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. + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/bisect.search.step1.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.step1.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,14 @@ + +$ if grep -q 'ho un gub' * +> then +> risultato=bad +> else +> risultato=good +> fi +$ 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) +0 file aggiornati, 0 file uniti, 6 file rimossi, 0 file irrisolti + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/bisect.search.step2.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.step2.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,7 @@ + +$ miotest +il contrassegno di questa revisione è good +Collaudo il changeset 19:706df39b003b (6 changeset rimanenti, ~2 test) +3 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/daily.revert.add.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.add.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,10 @@ + +$ echo oops > oops +$ hg add oops +$ hg status oops +A oops +$ hg revert oops +$ hg status +? oops + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/daily.revert.copy.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.copy.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg copy file nuovo-file +$ hg revert nuovo-file +$ hg status +? nuovo-file + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/daily.revert.missing.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.missing.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,9 @@ + +$ rm file +$ hg status +! file +$ hg revert file +$ ls file +file + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/daily.revert.modify.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.modify.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,13 @@ + +$ cat file +contenuto originale +$ echo cambiamento non voluto >> file +$ hg diff file +diff -r d17672b9fe6b file +--- a/file Fri Jun 05 15:50:07 2009 +0000 ++++ b/file Fri Jun 05 15:50:07 2009 +0000 +@@ -1,1 +1,2 @@ + contenuto originale ++cambiamento non voluto + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/daily.revert.remove.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.remove.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg remove file +$ hg status +R file +$ hg revert file +$ hg status +$ ls file +file + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/daily.revert.status.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.status.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,8 @@ + +$ hg status +? file.orig +$ cat file.orig +contenuto originale +cambiamento non voluto + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/daily.revert.unmodify.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.unmodify.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,8 @@ + +$ hg status +M file +$ hg revert file +$ cat file +contenuto originale + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/rollback.add.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rollback.add.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg add b +$ hg commit -m 'Aggiunge il file b, questa volta per davvero.' + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/rollback.commit.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rollback.commit.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg status +M a +$ echo b > b +$ hg commit -m 'Aggiunge il file b.' + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/rollback.rollback.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rollback.rollback.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,15 @@ + +$ hg rollback +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. + +$ hg status +M a +? b + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/rollback.status.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rollback.status.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,12 @@ + +$ hg status +? 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. + + + diff -r 5b79834be9a6 -r d4de8d288ba6 it/examples/rollback.twice.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rollback.twice.it Wed Aug 12 23:47:08 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg rollback +abortisco l'ultima transazione +$ hg rollback +nessuna informazione disponibile per abortire una transazione + +