Una panoramica di Mercurial: unire il lavoro

# HG changeset patch # User Giulio@puck # Date 1246433060 -7200 # Node ID 79e43e425111ad0fd7b7863fcef14e332560fa15 # Parent 263a6c849b6caa3137244329a5c9ca85b6b31a48 Deep revision of Ch.3. diff -r 263a6c849b6c -r 79e43e425111 it/ch03-tour-merge.xml --- a/it/ch03-tour-merge.xml Wed Jul 01 08:37:21 2009 +0200 +++ b/it/ch03-tour-merge.xml Wed Jul 01 09:24:20 2009 +0200 @@ -1,52 +1,52 @@ - - Una panoramica di Mercurial: unire il lavoro - - Abbiamo ora coperto il clonare un repository, effettuare cambiamenti in un repository, e estrarre o trasmettere cambiamenti da un repository a un altro. Il nostro prossimo passo sarà unire i cambiamenti da repository separati. + + Una panoramica di Mercurial: le unioni + + Finora abbiamo parlato di come clonare un repository, effettuare cambiamenti in un repository ed estrarre o trasmettere cambiamenti da un repository all'altro. Il nostro prossimo passo sarà quello di unire i cambiamenti da repository separati. Unire flussi di lavoro - Le unioni sono una parte fondamentale del lavoro con uno strumento per il controllo di revisione distribuito. Ecco alcuni casi in cui il bisogno di unire il lavoro si solleva. + Le unioni giocano un ruolo fondamentale quando si lavora con uno strumento per il controllo di revisione distribuito. Ecco alcuni casi in cui può presentarsi il bisogno di unire tra loro due o più flussi di lavoro. - Alice e Bruno hanno ognuno una copia personale di un repository per un progetto su cui stanno collaborando. Mentre Alice corregge un bug nel suo repository, Bruno aggiunge una nuova caratteristica nel proprio. Entrambi vogliono che il repository condiviso contenga sia la correzione del bug sia la nuova caratteristica. + Alice e Bruno hanno ognuno una copia personale di un repository per un progetto su cui stanno collaborando. Mentre Alice corregge un bug nel suo repository, Bruno aggiunge una nuova funzionalità nel proprio. Entrambi vogliono che il repository condiviso contenga sia la correzione del bug sia la nuova funzionalità. - Cinzia lavora frequentemente su numerose attività differenti alla volta per un singolo progretto, ognuna isolata al sicuro nel proprio repository. Lavorando in questo modo, Cinzia ha spesso bisogno di unire un fremmento del proprio lavoro con un altro. + Cinzia lavora frequentemente su più attività differenti alla volta per un singolo progretto, ognuna isolata al sicuro nel proprio repository. Lavorando in questo modo, Cinzia ha spesso bisogno di unire una parte del proprio lavoro con un'altra. - Dato che abbiamo bisogno di effettuare spesso delle unioni, Mercurial facilita il processo. Camminiamo attraverso una unione. Cominceremo clonando ancora un altro repository (vedete quanto spesso spuntano fuori?) e effettuando un cambiamento in esso. + Dato che abbiamo spesso bisogno di effettuare delle unioni, Mercurial ci viene in aiuto agevolando questo processo. Per capire come funzionano le unioni, seguiamone una passo per passo. Cominceremo creando ancora un altro clone del nostro repository (vedete quante volte spuntano fuori?) apportandovi poi alcune modifiche. &interaction.tour.merge.clone; - Ora dovremmo avere due copie di hello.c con contenuti differenti. Le cronologie dei due repository ora divergono l'una dall'altra, come illustrato nella . Ecco la copia del nostro file da un repository. + Ora abbiamo due copie di hello.c con contenuti differenti e le cronologie dei due repository divergono l'una dall'altra, come illustrato nella . Ecco la copia del nostro file presente nel primo repository. &interaction.tour.merge.cat1; - Ed ecco la nostra versione leggermente differente dall'altro. + Ed ecco la nuova versione, leggermente differente, contenuta nell'altro repository. &interaction.tour.merge.cat2;

- Le recenti cronologie divergenti dei repository <filename class="directory">my-hello</filename> e <filename class="directory">my-new-hello</filename> + Le cronologie divergenti dei repository <filename class="directory">my-hello</filename> e <filename class="directory">my-new-hello</filename> XXX add text - Sappiamo già che estrarre i cambiamenti dal nostro repository my-hello non avrà alcun effetto sulla directory di lavoro. + Sappiamo già che l'estrazione dei cambiamenti dal nostro repository my-hello non avrà alcun effetto sulla directory di lavoro. &interaction.tour.merge.pull; - Tuttavia, il comando hg pull dice qualcosa a proposito di teste. - - - I changeset di testa - - Ricordate che Mercurial registra qual è il genitore di ogni cambiamento. Se un cambiamento ha un genitore, chiamiamo quel cambiamento un figlio o discendente del genitore. Una testa è un cambiamento che non ha figli. La revisione di punta è quindi una testa, perché la revisione più recente in un repository non ha alcun figlio. Ci sono occasioni in cui un repository può contenere più di una testa. + Tuttavia, il comando hg pull dice qualcosa a proposito di teste (in inglese, heads). + + + Le teste di un repository + + Come ricorderete, Mercurial memorizza l'identità del genitore di ogni changeset. Se un cambiamento possiede un genitore, lo chiamiamo figlio o discendente del genitore. Una testa è un changeset che non ha figli. Quindi, la revisione di punta è una testa, perché la revisione più recente in un repository non possiede alcun figlio. Ci sono occasioni in cui un repository può contenere più di una testa.

I contenuti del repository dopo aver propagato i cambiamenti da <filename class="directory">my-hello</filename> a <filename class="directory">my-new-hello</filename> @@ -58,7 +58,7 @@ - Dalla figura , potete vedere l'effetto della propagazione dei cambiamenti dal repository my-hello al repository my-new-hello. La cronologia che era già presente in my-new-hello non viene toccata, ma una nuova revisione è stata aggiunta. Riferendoci alla , possiamo vedere che l'identificatore di changeset rimane lo stesso nel nuovo repository, ma che il numero di revisione è cambiato. (Questo, incidentalmente, è un buon esempio del perché non è sicuro usare i numeri di revisione per discutere i changeset.) Possiamo vedere le teste di un repository utilizzando il comando hg heads. + Dalla , potete vedere l'effetto della propagazione dei cambiamenti dal repository my-hello al repository my-new-hello. La cronologia già presente in my-new-hello non viene toccata, ma al repository è stata aggiunta una nuova revisione. Riferendoci alla , possiamo vedere che nel nuovo repository l'identificatore di changeset rimane lo stesso, ma il numero di revisione è cambiato. (Questo, incidentalmente, è un buon esempio del perché sia inopportuno usare i numeri di revisione per discutere i changeset.) Possiamo vedere le teste di un repository utilizzando il comando hg heads. &interaction.tour.merge.heads; @@ -66,33 +66,33 @@ Effettuare l'unione - Cosa succede se proviamo a usare il normale comando hg update per aggiornare alla nuova punta? + Cosa succede se proviamo a usare normalmente il comando hg update per aggiornare la directory di lavoro alla nuova punta? &interaction.tour.merge.update; - Mercurial ci sta dicendo che il comando hg update non farà una unione; non aggiornerà la directory di lavoro quando pensa che potremmo voler fare una unione, a meno che non lo forziamo a farlo. (Incidentalmente, forzare l'aggiornamento con hg update -C would revert any uncommitted changes in the working directory.) - - Per cominciare una unione tra le due teste, usiamo il comando hg merge. + Mercurial ci sta dicendo che il comando hg update non è in grado di effettuare un'unione e, se pensa che potremmo volerne fare una, non aggiornerà la directory di lavoro a meno che non gli chiediamo esplicitamente di farlo. (Incidentalmente, forzare l'aggiornamento tramite hg update -C provocherebbe la perdita di tutte le modifiche contenute nella directory di lavoro e non ancora inserite nel repository.) + + Per avviare un'unione tra le due teste, usiamo il comando hg merge. &interaction.tour.merge.merge; - We resolve il contenuto del file hello.c. Questo aggiorna la directory di lavoro in modo che contenga i cambiamenti da entrambe le teste, cosa che si riflette sia nel risultato del comando hg parents sia nei contenuti del file hello.c. + Il contenuto del file hello.c viene sistemato. L'operazione aggiorna la directory di lavoro in modo che contenga le modifiche provenienti da entrambe le teste, cosa che si riflette sia nell'elenco visualizzato dal comando hg parents sia nei contenuti del file hello.c. &interaction.tour.merge.parents; - Inserire i risultati dell'unione - - Ogni volta che eseguiamo un'unione, il comando hg parents mostrerà due genitori fino a quando non invocheremo hg commit per inserire nel repository i risultati dell'unione. + Inserire i risultati dell'unione nel repository + + Ogni volta che eseguiamo un'unione, il comando hg parents mostrerà due genitori fino a quando non invocheremo hg commit per inserire i risultati dell'unione nel repository. &interaction.tour.merge.commit; - Ora abbiamo una nuova revisione di punta; notate che ha entrambe le nostre vecchie teste come suoi genitori. Queste sono le stesse revisioni che erano state precedentemente mostrate da hg parents. + Ora abbiamo una nuova revisione di punta che, come potete notare, possiede entrambe le nostre vecchie teste come genitori. Queste sono le stesse revisioni che erano state precedentemente mostrate da hg parents. &interaction.tour.merge.tip; - Nella , potete vedere una rappresentazione di quanto accade alla directory di lavoro durante l'unione, e di come questo abbia effetto sul repository quando avviene l'inserimento. Durante l'unione, la directory di lavoro ha due changeset genitori e questi diventano i genitori del nuovo changeset. + Nella , potete vedere una rappresentazione di quanto accade alla directory di lavoro durante l'unione e di come questo abbia effetto sul repository quando avviene l'inserimento. Durante l'unione, la directory di lavoro possiede due changeset genitori che poi diventano i genitori del nuovo changeset.

Lo stato della directory di lavoro e del repository durante l'unione e dopo l'inserimento @@ -104,46 +104,46 @@ - Talvolta si dice che un'unione è composta da due parti: la parte sinistra è il primo genitore nell'uscita di hg parents, e la parte destra è il secondo. Se per esempio la directory di lavoro si trovava alla revisione 5 prima che cominciassimo l'unione, quella revisione diventerà la parte sinistra dell'unione. + Talvolta si dice che un'unione è composta da due parti: la parte sinistra è costituita dal primo genitore elencato da hg parents e la parte destra dal secondo. Se per esempio la directory di lavoro si fosse trovata alla revisione 5 prima che cominciassimo l'unione, quella revisione sarebbe diventata la parte sinistra dell'unione. - Unire cambiamenti conflittuali - - La maggior parte delle unioni sono faccende semplici, ma talvolta vi troverete a unire cambiamenti dove ognuna delle due parti modifica le stesse porzioni degli stessi file. A meno che entrambe le modifiche siano identiche, questo risulterà in un conflitto, dove voi dovete decidere come riconciliare i diversi cambiamenti in un risultato coerente. + Risolvere i conflitti tra cambiamenti + + La maggior parte delle unioni è semplice, ma talvolta vi troverete a unire cambiamenti dove ognuna delle due parti modifica le stesse porzioni degli stessi file. A meno che entrambe le modifiche siano identiche, questo risulterà in un conflitto che dovrete cercare di riconciliare decidendo come combinare i diversi cambiamenti in un risultato coerente.

- Cambiamenti in conflitto a un documento + Modifiche in conflitto a un documento XXX add text - La illustra un esempio di due cambiamenti in conflitto a un documento. Abbiamo cominciato con una singola versione del file; poi abbiamo fatto alcuni cambiamenti; mentre qualcun altro ha fatto cambiamenti differenti allo stesso testo. Il nostro compito nella risoluzione del conflitto tra i cambiamenti è quello di decidere che cosa dovrebbe contenere il file. - - Mercurial non è dotato di uno strumento predefinito per gestire i conflitti. Invece, esegue un programma esterno, di solito uno che mostra un qualche tipo di interfaccia grafica per la risoluzione dei conflitti. Di default, Mercurial prova a trovare uno tra i vari strumenti di unione differenti che è probabile siano installati sul vostro sistema. Prima prova a cercare alcuni strumenti di unione completamente automatici; se non riesce a trovarli (perché il processo di risoluzione richiede una guida umana) o non sono presenti, prova vari altri strumenti grafici per le unioni. - - È anche possibile far eseguire a Mercurial uno specifico programma, impostando la variable di ambiente HGMERGE al nome del vostro programma preferito. + La illustra un esempio di due diversi cambiamenti a uno stesso documento che sono in conflitto tra loro. Siamo partiti da una singola versione del file, a cui poi abbiamo apportato alcune modifiche mentre qualcun altro eseguiva modifiche differenti allo stesso testo. Nella risoluzione del conflitto tra i cambiamenti, il nostro compito è quello di decidere che cosa dovrebbe contenere il file. + + Mercurial non è dotato di alcuna funzionalità predefinita per gestire i conflitti. Invece, richiama un programma esterno, di solito uno che mostra un qualche tipo di interfaccia grafica per la risoluzione dei conflitti, trovato tra i tanti strumenti di unione differenti che è probabile siano installati sul vostro sistema. Come prima cosa, Mercurial prova a cercare alcuni strumenti di unione completamente automatici; poi, se non riesce a trovarli (perché il processo di risoluzione richiede una guida umana) o se non sono presenti, prova vari altri strumenti grafici per le unioni. + + È anche possibile far eseguire a Mercurial uno specifico programma, impostando il valore della variable di ambiente HGMERGE al nome del vostro programma preferito. Usare uno strumento grafico per le unioni - Il mio strumento grafico per le unioni preferito è kdiff3, che userà per descrivere le caratteristiche che sono comuni agli strumenti grafici per l'unione di file. Potete vedere uno screenshot di kdiff3 in azione nella . Il tipo di unione che sta eseguendo si chiama unione a tre vie, perché ci sono tre differenti versioni di un file che ci interessano. Lo strumento dunque divide la porzione superiore della finestra in tre pannelli: + Il mio strumento grafico preferito per gestire le unioni è kdiff3, che userò per descrivere le caratteristiche comuni a queste applicazioni. Potete vedere kdiff3 in azione nella . Il tipo di unione che sta eseguendo si chiama unione a tre vie, perché ci sono tre differenti versioni di un file che ci interessano. La porzione superiore della finestra è divisa in tre pannelli: - A sinistra si trova la versione base del file, i.e. la versione più recente da cui le due versioni che stiamo cercando di unire discendono. + a sinistra troviamo la versione base del file, i.e. la versione più recente da cui discendono le due versioni che stiamo cercando di unire; - Nel mezzo si trova la nostra versione del file, con i contenuti che abbiamo modificato. + nel mezzo troviamo la nostra versione del file, con i contenuti che abbiamo modificato; - A destra troviamo la loro versione del file, quella che proviene dal changeset che stiamo cercando di incorporare. + a destra troviamo la loro versione del file, quella che proviene dal changeset che stiamo cercando di incorporare. - Nel pannello sotto a questi si trova il risultato corrente dell'unione. Il nostro compito è quello di sostituire tutto il testo in rosso, che indica conflitti irrisolti, con una qualche unione ragionevole della nostra e della loro versione del file. - - Tutti e quattro questi pannelli sono collegati tra loro; se scrolliamo in verticale o in orizzontale in ognuo di essi, gli altri vengono aggiornati per mostrare le sezioni corrispondenti dei rispettivi file. + Il pannello sottostante contiene il risultato corrente dell'unione. Il nostro compito è quello di sostituire tutto il testo in rosso, che indica conflitti irrisolti, con una qualche combinazione ragionevole della nostra e della loro versione del file. + + Tutti e quattro questi pannelli sono collegati tra loro: se ci spostiamo in verticale o in orizzontale in un pannello qualsiasi, gli altri vengono aggiornati per mostrare le sezioni corrispondenti dei rispettivi file.

- Usare <command>kdiff3</command> per unire versioni di un file + Usare <command>kdiff3</command> per unire diverse versioni di un file @@ -153,15 +153,15 @@ - Per ogni porzione conflittuale del file, possiamo scegliere di risolvere il conflitto usando una qualche combinazione di testo dalla versione base, dalla nostra, o dalla loro. Possiamo anche modificare manualmente il file unito in ogni momento, nel caso abbiamo bisogno di effettuare cambiamenti ulteriori. - - Esistono molti strumenti per l'unione di file, davvero troppi per elencarli qui. Essi variano a seconda della piattaforma per la quale sono disponibili, e nelle loro particolari forze e debolezze. La maggior parte è tuned per unire file contenenti testo semplice, mentre alcuni sono indirizzati a particolari formati di file (generalmente XML). - - - - Un esempio lavorato - - In questo esempio, riprodurremo le cronologia delle modifiche ai file della precedente. Per cominciare, creiamo un repository con una versione base del nostro documento. + Per ogni porzione conflittuale del file, possiamo scegliere di risolvere il conflitto usando una qualche combinazione di testo dalla versione base, dalla nostra, o dalla loro. Possiamo anche modificare manualmente il file risultante in ogni momento, nel caso avessimo bisogno di effettuare ulteriori cambiamenti. + + Esistono molti strumenti per l'unione di file, davvero troppi per elencarli qui. Si differenziano a seconda della piattaforma per cui sono disponibili e delle loro particolari forze e debolezze. La maggior parte è calibrata per unire file contenenti testo semplice, mentre alcuni sono orientati a particolari formati di file (generalmente XML). + + + + Un esempio risolto + + In questo esempio, riprodurremo la cronologia delle modifiche ai file della vista in precedenza. Per cominciare, creiamo un repository con una versione base del nostro documento. &interaction.tour-merge-conflict.wife; @@ -169,30 +169,30 @@ &interaction.tour-merge-conflict.cousin; - E ora aggiungiamo un altro clone, per simulare qualcun altro che effettui un cambiamento al file. (Questo suggerisce l'idea che non è affatto inusuale unire con sé stessi quando isolate le vostre attività in repository separati, e in effetti trovate e risolvete conflitti mentre fate così.) + E ora aggiungiamo un altro clone, per simulare qualcun altro che effettui un cambiamento al file. (Questo suggerisce l'idea che non è affatto inusuale ritrovarsi a unire tra loro i propri repository che contengono attività isolate, risolvendo i conflitti incontrati nel corso di questo processo.) &interaction.tour-merge-conflict.son; - Avendo creato due versioni differenti del file, impostiamo un ambiente adeguato a eseguire la nostra unione. + Avendo creato due versioni differenti del file, predisponiamo un ambiente adeguato a eseguire la nostra unione. &interaction.tour-merge-conflict.pull; - In questo esempio, imposterò la variabile d'ambiente HGMERGE per dire a Mercurial di usare il comando non interattivo merge. Questo comando è incluso in molti sistemi Unix-like. (Se state seguento questo esempio sul vostro computer, non preoccupatevi di impostare HGMERGE. Verrete depositati in uno strumento grafico per l'unione dei file, che è di molto preferibile.) + In questo esempio, imposterò la variabile d'ambiente HGMERGE per dire a Mercurial di usare il comando non interattivo merge. Questo comando è incluso in molti sistemi di tipo Unix. (Se state seguento questo esempio sul vostro computer, non preoccupatevi di impostare HGMERGE. Vi verrà presentata un'applicazione grafica da utilizzare per unire i file, che è un'alternativa di gran lunga preferibile.) &interaction.tour-merge-conflict.merge; - Dato che merge non riesce a risolvere il conflitto tra i cambiamenti, lascia marcatori di unione dentro al file che ha i conflitti, indicando quali righe sono in conflitto e se vengono dalla nostra versione del file o dalla loro. - - Mercurial può dire dal modo in cui merge esce che non è stato in grado di unire con successo, quindi ci dice quali comandi abbiamo bisogno di eseguire se vogliamo rifare l'operazione di unione. Questo potrebbe essere utile se, per esempio, stessimo eseguendo uno strumento di unione grafico e uscissimo perché siamo confusi o realizziamo di aver fatto un errore. - - Se l'unione automatica o manuale fallisce, non c'è nulla che ci impedisce di correggere i file interessati per conto nostro, per inserire poi nel repository i risultati della nostra unione: + Dato che merge non riesce a risolvere il conflitto tra i cambiamenti, inserisce alcuni marcatori di unione all'interno del file che esibisce i conflitti, per indicare quali righe sono in conflitto e se quelle righe provengono dalla nostra versione del file o dalla loro. + + Dal modo in cui merge termina, Mercurial riconosce che non è stato in grado di operare con successo, quindi ci dice quali comandi abbiamo bisogno di eseguire se vogliamo rifare l'operazione di unione. Questo potrebbe essere utile se, per esempio, stessimo lavorando con un'applicazione grafica per la gestione delle unioni e la chiudessimo perché siamo confusi o realizziamo di aver commesso un errore. + + Nel caso in cui l'unione automatica o manuale fallisca, nulla ci impedisce di correggere i file interessati per conto nostro, per poi inserire i risultati della nostra unione nel repository: &interaction.tour-merge-conflict.commit; Dov'è il comando <command>hg resolve</command>? - Il comando hg resolve è stato introdotto nella verisone 1.1 di Mercurial, che è stata rilasciata nel dicembre 2008. Se state usando una versione più vecchia (eseguite hg version per controllare) questo comando non sarà presente. Se la vostra versione di Mercurial è più vecchia della 1.1, vi consiglio vivamente di installare una versione più nuova prima di affrontare unioni complicate. + Il comando hg resolve è stato introdotto nella verisone 1.1 di Mercurial rilasciata nel dicembre 2008. Se state usando una versione più vecchia (eseguite hg version per controllare) questo comando non sarà presente. Nel caso la vostra versione di Mercurial sia precedente alla 1.1, vi consiglio vivamente di installare una versione più recente prima di affrontare unioni complicate. @@ -200,34 +200,34 @@ Semplificare la sequenza di estrazione-unione-inserimento - Il processo di unione dei cambiamenti come delineato in precedenza è molto semplice, ma richiede di eseguire tre comandi in sequenza. + Il processo di unione dei cambiamenti appena delineato è molto semplice, ma richiede di eseguire tre comandi in sequenza. hg pull -u hg merge hg commit -m 'Incorporati i cambiamenti remoti' - Nel caso dell'inserimento conclusivo, avete anche bisogno di inserire un messaggio di commit, che sarà quasi sempre un frammento di testo boilerplate non interessante. - - Sarebbe carino ridurre il numero di passi necessari, se questo fosse possibile. In effetti, Mercurial viene distribuito con una estensione chiamata fetch che fa proprio questo. - - Mercurial fornisce un meccanismo flessibile di estensione che permette alle persone di estendere le sue funzionalità mantenendo il cuore di Mercurial piccolo e facile da trattare. Alcune estensioni aggiungono nuovi comandi che potete usare dalla linea di comando, mentre altri lavorano dietro le quinte, per esempio aggiungendo funzionalità alla modalità server predefinita di Mercurial. - - L'estensione fetch aggiunge un nuovo comando chiamato, ovviamente, hg fetch. Questa estensione agisce come una combinazione di hg pull -u, hg merge e hg commit. Comincia propagando i cambiamenti da un altro repository verso il repository corrente. Se trova che i cambiamenti aggiungono una nuova testa al repository, lo aggiorna alla nuova testa, comincia una unione, poi (se l'unione ha successo) inserisce il risultato dell'unione nel repository con un messaggio di commit generato automaticamente. Se non sono state aggiunte nuove teste, il comando aggiorna la directory di lavoro alla nuova revisione di punta. - - Abilitare l'estensione fetch è facile. Aprite il file .hgrc nella vostra directory personale e andate alla sezione extensions oppure create una sezione extensions se non esiste già. Poi aggiungete una riga che contenga semplicemente fetch=. + Nel caso dell'inserimento finale, avete anche bisogno di includere un messaggio di commit, che sarà quasi sempre composto da testo standard non particolarmente interessante. + + Se fosse possibile, sarebbe carino ridurre il numero di passi necessari. In effetti, Mercurial viene distribuito con un'estensione chiamata fetch pensata proprio per questo scopo. + + Mercurial fornisce un meccanismo flessibile per consentire ad altre persone di estendere le sue funzionalità, preservando le dimensioni ridotte e la manutenibilità del proprio nucleo. Alcune estensioni aggiungono nuovi comandi che potete usare dalla linea di comando, mentre altri lavorano dietro le quinte, per esempio accrescendo le funzionalità della modalità server predefinita di Mercurial. + + L'estensione fetch aggiunge un nuovo comando chiamato, naturalmente, hg fetch. Questa estensione agisce come una combinazione di hg pull -u, hg merge e hg commit. Comincia propagando verso il repository corrente i cambiamenti estratti da un altro repository. Se si accorge che i cambiamenti hanno aggiunto una nuova testa al repository aggiorna la directory di lavoro alla nuova testa, poi avvia il processo di unione e infine, se l'unione ha successo, ne inserisce il risultato nel repository con un messaggio di commit generato automaticamente. Se non sono state aggiunte nuove teste, il comando si limita ad aggiornare la directory di lavoro alla nuova revisione di punta. + + Abilitare l'estensione fetch è facile. Aprite il file .hgrc che si trova nella vostra directory personale e andate alla sezione extensions (oppure createla se non esiste già). Poi aggiungete una riga che contenga semplicemente fetch=. [extensions] fetch = - (Normalmente, il lato destro del simbolo = indicherebbe dove trovare l'estensione, ma dato che l'estensione fetch è nella distribuzione standard, Mercurial sa già dove andarla a cercare.) + (Normalmente, il lato destro del simbolo = indicherebbe dove trovare l'estensione, ma dato che l'estensione fetch è compresa nella distribuzione standard, Mercurial sa già dove andarla a cercare.) Rinominare, copiare e unire - Durante la vita di un progetto, vorremo spesso cambiare la disposizione dei suoi file e delle sue directory. Questo può essere tanto semplice quanto rinominare un singolo file, o tanto complesso quanto ristrutturare l'intera gerarchia dei file nell'ambito del progetto. - - Mercurial supporta questi tipi di cambiamenti complessi in maniera fluida, a patto che gli diciamo quello stiamo facendo. Se vogliamo rinominare un file, dovremmo usare il comando hg rename + Durante la vita di un progetto, vorremo spesso cambiare la disposizione dei suoi file e delle sue directory. Queste modifiche possono essere tanto semplici quanto rinominare un singolo file, o tanto complesse quanto ristrutturare l'intera gerarchia dei file nell'ambito del progetto. + + Mercurial supporta questi tipi di cambiamenti in maniera fluida, a patto che gli diciamo quello che stiamo facendo. Se vogliamo rinominare un file, dovremmo usare il comando hg rename Se siete utenti Unix, sarete contenti di sapere che il comando hg rename si può abbreviare in hg mv. - per cambiarne il nome, in modo che Mercurial possa fare la cosa giusta più tardi quando effettueremo un'unione. + per cambiarne il nome, in modo che Mercurial possa comportarsi in maniera appropriata nel caso più tardi effettuassimo un'unione. Tratteremo l'uso di questi comandi in maniera più estesa nel FIXME.