hgbook
changeset 853:eed01b9ad3e6
Typography.
| author | gpiancastelli |
|---|---|
| date | Sat Aug 22 21:55:05 2009 +0200 (2009-08-22) |
| parents | 63fe2cfe3d4c |
| children | 18b67e30ba27 |
| files | it/appA-svn.xml it/appB-mq-ref.xml it/appC-srcinstall.xml it/appD-license.xml it/book-shortcuts.xml it/ch00-preface.xml it/ch01-intro.xml it/ch02-tour-basic.xml it/ch03-tour-merge.xml it/ch04-concepts.xml it/ch05-daily.xml it/ch06-collab.xml it/ch07-filenames.xml it/ch08-branch.xml it/ch09-undo.xml it/ch10-hook.xml it/ch11-template.xml it/ch12-mq.xml it/ch13-mq-collab.xml it/ch14-hgext.xml it/web/index-home.html.in |
line diff
1.1 --- a/it/appA-svn.xml Sat Aug 22 21:01:56 2009 +0200 1.2 +++ b/it/appA-svn.xml Sat Aug 22 21:55:05 2009 +0200 1.3 @@ -9,7 +9,7 @@ 1.4 <sect1> 1.5 <title>Importare la cronologia da un altro sistema</title> 1.6 1.7 - <para id="x_6e3">Mercurial include un'estensione chiamata <literal>convert</literal> che può importare la cronologia di un progetto dalla maggior parte dei sistemi di controllo di revisione più popolari. Al momento in cui il libro è stato scritto, l'estensione può importare la cronologia dai seguenti sistemi:</para> 1.8 + <para id="x_6e3">Mercurial include un’estensione chiamata <literal>convert</literal> che può importare la cronologia di un progetto dalla maggior parte dei sistemi di controllo di revisione più popolari. Al momento in cui il libro è stato scritto, l’estensione può importare la cronologia dai seguenti sistemi:</para> 1.9 <itemizedlist> 1.10 <listitem> 1.11 <para id="x_6e4">Subversion</para> 1.12 @@ -39,25 +39,25 @@ 1.13 1.14 <para id="x_6ec">(Per verificare perché lo stesso Mercurial sia supportato come sorgente da cui importare la cronologia, si veda la <xref linkend="svn.filemap"/>.)</para> 1.15 1.16 - <para id="x_6ed">Potete attivare l'estensione nel solito modo, modificando il vostro file <filename>~/.hgrc</filename>.</para> 1.17 + <para id="x_6ed">Potete attivare l’estensione nel solito modo, modificando il vostro file <filename>~/.hgrc</filename>.</para> 1.18 1.19 <programlisting>[extensions] 1.20 convert =</programlisting> 1.21 1.22 - <para id="x_6ee">Questo renderà disponibile il comando <command>hg convert</command>. Il comando è facile da usare. Per esempio, l'invocazione seguente importerà in Mercurial la cronologia di Subversion per Nose, un framework per il collaudo di unità.</para> 1.23 + <para id="x_6ee">Questo renderà disponibile il comando <command>hg convert</command>. Il comando è facile da usare. Per esempio, l’invocazione seguente importerà in Mercurial la cronologia di Subversion per Nose, un framework per il collaudo di unità.</para> 1.24 1.25 <screen><prompt>$</prompt> <userinput>hg convert http://python-nose.googlecode.com/svn/trunk</userinput></screen> 1.26 1.27 - <para id="x_6ef">L'estensione <literal>convert</literal> opera in maniera incrementale. In altre parole, dopo che avete invocato <command>hg convert</command> una prima volta, invocandolo nuovamente importerete tutte le nuove revisioni che sono state inserite dopo la vostra prima esecuzione del comando. La conversione incrementale funzionerà solo se invocate <command>hg convert</command> nello stesso repository Mercurial che avete usato in origine, perché l'estensione <literal>convert</literal> salva alcuni metadati privati all'interno del repository in un file chiamato <filename>.hg/shamap</filename> non soggetto al controllo di revisione.</para> 1.28 - 1.29 - <para id="x_707">Quando volete cominciare a effettuare modifiche usando Mercurial, è preferibile clonare l'albero in cui state facendo le vostre conversioni e tenere da parte l'albero originale per dedicarlo a future conversioni incrementali. Questo è il modo più sicuro per estrarre i futuri commit dal sistema di controllo di revisione sorgente e incorporarli nel progetto Mercurial che avete appena creato.</para> 1.30 + <para id="x_6ef">L’estensione <literal>convert</literal> opera in maniera incrementale. In altre parole, dopo che avete invocato <command>hg convert</command> una prima volta, invocandolo nuovamente importerete tutte le nuove revisioni che sono state inserite dopo la vostra prima esecuzione del comando. La conversione incrementale funzionerà solo se invocate <command>hg convert</command> nello stesso repository Mercurial che avete usato in origine, perché l’estensione <literal>convert</literal> salva alcuni metadati privati all’interno del repository in un file chiamato <filename>.hg/shamap</filename> non soggetto al controllo di revisione.</para> 1.31 + 1.32 + <para id="x_707">Quando volete cominciare a effettuare modifiche usando Mercurial, è preferibile clonare l’albero in cui state facendo le vostre conversioni e tenere da parte l’albero originale per dedicarlo a future conversioni incrementali. Questo è il modo più sicuro per estrarre i futuri commit dal sistema di controllo di revisione sorgente e incorporarli nel progetto Mercurial che avete appena creato.</para> 1.33 1.34 <sect2> 1.35 <title>Convertire molti rami</title> 1.36 1.37 - <para id="x_708">Il comando <command>hg convert</command> eseguito in precedenza converte solo la cronologia del <literal>trunk</literal> del repository Subversion. Se invece usiamo l'URL <literal>http://python-nose.googlecode.com/svn</literal>, Mercurial individuerà automaticamente le directory <literal>trunk</literal>, <literal>tags</literal> e <literal>branches</literal> che compongono la struttura usata di solito dai progetti Subversion e le importerà come rami separati.</para> 1.38 - 1.39 - <para id="x_709">Per default, a ogni ramo Subversion importato in Mercurial viene assegnato un nome. Dopo che la conversione si è conclusa, potete ottenere una lista dei nomi dei rami attivi nel repository Mercurial usando <command>hg branches -a</command>. Se preferite importare i rami Subversion senza nomi, passate l'opzione <option>--config convert.hg.usebranchnames=false</option> al comando <command>hg convert</command>.</para> 1.40 + <para id="x_708">Il comando <command>hg convert</command> eseguito in precedenza converte solo la cronologia del <literal>trunk</literal> del repository Subversion. Se invece usiamo l’URL <literal>http://python-nose.googlecode.com/svn</literal>, Mercurial individuerà automaticamente le directory <literal>trunk</literal>, <literal>tags</literal> e <literal>branches</literal> che compongono la struttura usata di solito dai progetti Subversion e le importerà come rami separati.</para> 1.41 + 1.42 + <para id="x_709">Per default, a ogni ramo Subversion importato in Mercurial viene assegnato un nome. Dopo che la conversione si è conclusa, potete ottenere una lista dei nomi dei rami attivi nel repository Mercurial usando <command>hg branches -a</command>. Se preferite importare i rami Subversion senza nomi, passate l’opzione <option>--config convert.hg.usebranchnames=false</option> al comando <command>hg convert</command>.</para> 1.43 1.44 <para id="x_70a">Una volta che avete convertito il vostro albero, se volete seguire la consuetudine tipica per Mercurial di lavorare in un albero che contiene un singolo ramo, potete clonare quel singolo ramo usando <command>hg clone -r nomedelramo</command>.</para> 1.45 </sect2> 1.46 @@ -65,9 +65,9 @@ 1.47 <sect2> 1.48 <title>Correlare i nomi utente</title> 1.49 1.50 - <para id="x_6f0">Alcuni strumenti di controllo di revisione salvano con ogni inserimento solo nomi utenti brevi che possono essere difficili da interpretare. Con Mercurial, la norma è quella di salvare il nome e l'indirizzo email di chi effettua il commit, due informazioni molto più utili se in seguito volessimo contattare quella persona.</para> 1.51 - 1.52 - <para id="x_6f1">Se state convertendo un albero da un sistema di controllo di revisione che usa nomi brevi, potete correlare quei nomi a equivalenti più lunghi passando l'opzione <option>--authors</option> al comando <command>hg convert</command>. Questa opzione accetta un nome di file che dovrebbe contenere voci nel seguente formato.</para> 1.53 + <para id="x_6f0">Alcuni strumenti di controllo di revisione salvano con ogni inserimento solo nomi utenti brevi che possono essere difficili da interpretare. Con Mercurial, la norma è quella di salvare il nome e l’indirizzo email di chi effettua il commit, due informazioni molto più utili se in seguito volessimo contattare quella persona.</para> 1.54 + 1.55 + <para id="x_6f1">Se state convertendo un albero da un sistema di controllo di revisione che usa nomi brevi, potete correlare quei nomi a equivalenti più lunghi passando l’opzione <option>--authors</option> al comando <command>hg convert</command>. Questa opzione accetta un nome di file che dovrebbe contenere voci nel seguente formato.</para> 1.56 1.57 <programlisting>arist = Aristotele <aristotele@filo.example.gr> 1.58 soc = Socrate <socrate@filo.example.gr></programlisting> 1.59 @@ -76,13 +76,13 @@ 1.60 </sect2> 1.61 1.62 <sect2 id="svn.filemap"> 1.63 - <title>Riordinare l'albero</title> 1.64 - 1.65 - <para id="x_6f3">Non tutti i progetti hanno una cronologia pulita. Potrebbe esserci una directory che non avrebbe mai dovuto essere inserita, un file che è troppo grande, o un'intera gerarchia che ha bisogno di essere riorganizzata.</para> 1.66 - 1.67 - <para id="x_6f4">L'estensione <literal>convert</literal> supporta l'idea di una <quote>mappa di file</quote> che può essere impiegata per riorganizzare i file e le directory di un progetto nel momento in cui se ne importa la cronologia. Questo è utile non solo quando si importa la cronologia da altri sistemi di controllo di revisione, ma anche per potare o riorganizzare un albero Mercurial.</para> 1.68 - 1.69 - <para id="x_6f5">Per specificare una mappa di file, usate l'opzione <option>--filemap</option> e fornitele un nome di file. Una mappa di file contiene righe nei seguenti formati.</para> 1.70 + <title>Riordinare l’albero</title> 1.71 + 1.72 + <para id="x_6f3">Non tutti i progetti hanno una cronologia pulita. Potrebbe esserci una directory che non avrebbe mai dovuto essere inserita, un file che è troppo grande, o un’intera gerarchia che ha bisogno di essere riorganizzata.</para> 1.73 + 1.74 + <para id="x_6f4">L’estensione <literal>convert</literal> supporta l’idea di una <quote>mappa di file</quote> che può essere impiegata per riorganizzare i file e le directory di un progetto nel momento in cui se ne importa la cronologia. Questo è utile non solo quando si importa la cronologia da altri sistemi di controllo di revisione, ma anche per potare o riorganizzare un albero Mercurial.</para> 1.75 + 1.76 + <para id="x_6f5">Per specificare una mappa di file, usate l’opzione <option>--filemap</option> e fornitele un nome di file. Una mappa di file contiene righe nei seguenti formati.</para> 1.77 1.78 <programlisting># Questo è un commento 1.79 # Le righe vuote vengono ignorate 1.80 @@ -94,9 +94,9 @@ 1.81 rename da/qualche/percorso a/qualche/altra/posizione 1.82 </programlisting> 1.83 1.84 - <para id="x_6f6">La direttiva <literal>include</literal> provoca l'inclusione di un file, o di tutti i file contenuti in una directory, nel repository destinazione. Questa direttiva provoca anche l'esclusione di tutti gli altri file o directory che non sono state esplicitamente incluse. La direttiva <literal>exclude</literal> provoca l'esclusione dei file e delle directory indicate e di tutti quegli altri percorsi che non sono stati esplicitamente menzionati per essere inclusi.</para> 1.85 - 1.86 - <para id="x_6f7">Per spostare un file o una directory da una posizione a un'altra, usate la direttiva <literal>rename</literal>. Se dovete spostare un file o una directory da una sottodirectory alla radice del repository, usate <literal>.</literal> come secondo argomento della direttiva <literal>rename</literal>.</para> 1.87 + <para id="x_6f6">La direttiva <literal>include</literal> provoca l’inclusione di un file, o di tutti i file contenuti in una directory, nel repository destinazione. Questa direttiva provoca anche l’esclusione di tutti gli altri file o directory che non sono state esplicitamente incluse. La direttiva <literal>exclude</literal> provoca l’esclusione dei file e delle directory indicate e di tutti quegli altri percorsi che non sono stati esplicitamente menzionati per essere inclusi.</para> 1.88 + 1.89 + <para id="x_6f7">Per spostare un file o una directory da una posizione a un’altra, usate la direttiva <literal>rename</literal>. Se dovete spostare un file o una directory da una sottodirectory alla radice del repository, usate <literal>.</literal> come secondo argomento della direttiva <literal>rename</literal>.</para> 1.90 </sect2> 1.91 1.92 <sect2> 1.93 @@ -104,7 +104,7 @@ 1.94 1.95 <para id="x_70b">Avrete spesso bisogno di fare diversi tentativi prima di trovare la combinazione perfetta tra mappa di utenti, mappa di file e altri parametri di conversione. La conversione di un repository Subversion attraverso un protocollo di accesso come ssh o HTTP può procedere migliaia di volte più lentamente di quanto Mercurial sia capace di operare in realtà, a causa della latenza di rete. Questo può rendere molto complicata la messa a punto di quella ricetta per la conversione perfetta.</para> 1.96 1.97 - <para id="x_70c">Il comando <ulink url="http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt"><command>svnsync</command></ulink> può velocizzare notevolmente la conversione di un repository Subversion. Serve per creare un mirror di sola lettura di un repository Subversion. L'idea è quella di creare un mirror locale del vostro albero Subversion per poi convertire il mirror in un repository Mercurial.</para> 1.98 + <para id="x_70c">Il comando <ulink url="http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt"><command>svnsync</command></ulink> può velocizzare notevolmente la conversione di un repository Subversion. Serve per creare un mirror di sola lettura di un repository Subversion. L’idea è quella di creare un mirror locale del vostro albero Subversion per poi convertire il mirror in un repository Mercurial.</para> 1.99 1.100 <para id="x_70d">Immaginiamo di voler convertire il repository Subversion che contiene il popolare progetto Memcached in un albero Mercurial. Per prima cosa, creiamo un repository Subversion locale.</para> 1.101 1.102 @@ -120,7 +120,7 @@ 1.103 <screen><prompt>$</prompt> <userinput>svnsync --init file://`pwd`/memcached-mirror \ 1.104 http://code.sixapart.com/svn/memcached</userinput></screen> 1.105 1.106 - <para id="x_710">Il passo successivo consiste nell'avviare il processo di creazione del mirror con il comando <command>svnsync</command>.</para> 1.107 + <para id="x_710">Il passo successivo consiste nell’avviare il processo di creazione del mirror con il comando <command>svnsync</command>.</para> 1.108 1.109 <screen><prompt>$</prompt> <userinput>svnsync sync file://`pwd`/memcached-mirror</userinput></screen> 1.110 1.111 @@ -130,7 +130,7 @@ 1.112 1.113 <para id="x_712">Se il repository Subversion è ancora attivo, possiamo usare questo processo in maniera incrementale. Invochiamo <command>svnsync</command> per propagare i nuovi cambiamenti verso il nostro mirror e poi invochiamo <command>hg convert</command> per importarli nel nostro albero Mercurial.</para> 1.114 1.115 - <para id="x_713">Un'importazione in due stadi realizzata con <command>svnsync</command> ha due vantaggi. Il primo è che <command>svnsync</command> usa una sincronizzazione di rete con Subversion più efficiente rispetto al comando <command>hg convert</command>, quindi trasferisce meno dati attraverso la rete. Il secondo è che l'importazione da un albero Subversion locale è così veloce che potete aggiustare ripetutamente le vostre impostazioni di conversione senza aspettare ogni volta la terminazione di un processo di conversione basato su rete e dolorosamente lento.</para> 1.116 + <para id="x_713">Un’importazione in due stadi realizzata con <command>svnsync</command> ha due vantaggi. Il primo è che <command>svnsync</command> usa una sincronizzazione di rete con Subversion più efficiente rispetto al comando <command>hg convert</command>, quindi trasferisce meno dati attraverso la rete. Il secondo è che l’importazione da un albero Subversion locale è così veloce che potete aggiustare ripetutamente le vostre impostazioni di conversione senza aspettare ogni volta la terminazione di un processo di conversione basato su rete e dolorosamente lento.</para> 1.117 </sect2> 1.118 </sect1> 1.119 1.120 @@ -142,16 +142,16 @@ 1.121 <sect2> 1.122 <title>Differenze filosofiche</title> 1.123 1.124 - <para id="x_6f9">Naturalmente, la differenza fondamentale tra Subversion e Mercurial è che Subversion è centralizzato mentre Mercurial è distribuito. Dato che Mercurial memorizza tutta la cronologia di un progetto sul vostro disco locale, ha bisogno di accedere alla rete solo quando volete esplicitamente comunicare con un altro repository. Al contrario, Subversion memorizza localmente un'esigua quantità di informazioni, perciò il client deve contattare il proprio server per molte operazioni comuni.</para> 1.125 - 1.126 - <para id="x_6fa">Subversion riesce più o meno a cavarsela senza una nozione di ramo ben definita: qualificare come ramo una porzione dello spazio di nomi sul server è una questione di convenzioni, e il software non impone alcuna costrizione. Mercurial tratta un repository come l'unità della gestione dei rami.</para> 1.127 + <para id="x_6f9">Naturalmente, la differenza fondamentale tra Subversion e Mercurial è che Subversion è centralizzato mentre Mercurial è distribuito. Dato che Mercurial memorizza tutta la cronologia di un progetto sul vostro disco locale, ha bisogno di accedere alla rete solo quando volete esplicitamente comunicare con un altro repository. Al contrario, Subversion memorizza localmente un’esigua quantità di informazioni, perciò il client deve contattare il proprio server per molte operazioni comuni.</para> 1.128 + 1.129 + <para id="x_6fa">Subversion riesce più o meno a cavarsela senza una nozione di ramo ben definita: qualificare come ramo una porzione dello spazio di nomi sul server è una questione di convenzioni, e il software non impone alcuna costrizione. Mercurial tratta un repository come l’unità della gestione dei rami.</para> 1.130 1.131 <sect3> 1.132 - <title>L'ambito dei comandi</title> 1.133 - 1.134 - <para id="x_6fb">Dato che Subversion non sa quali parti del suo spazio di nomi siano realmente rami, tratta la maggior parte dei comandi come se richiedesse di operare al livello della directory in cui vi trovate e ai livelli sottostanti. Per esempio, se eseguite <command>svn log</command>, otterrete la cronologia di qualunque parte dell'albero stiate osservando, non dell'intero albero.</para> 1.135 - 1.136 - <para id="x_6fc">Il comportamento predefinito di Mercurial è differente perché i suoi comandi operano sull'intero repository. Eseguite <command>hg log</command> e vi mostrerà la cronologia dell'intero albero, a prescindere da quale parte della directory di lavoro stiate visitando in quel momento. Se volete solo la cronologia di un file o di una directory particolare, vi basta fornire un nome al comando, e.g. <command>hg log sorgenti</command>.</para> 1.137 + <title>L’ambito dei comandi</title> 1.138 + 1.139 + <para id="x_6fb">Dato che Subversion non sa quali parti del suo spazio di nomi siano realmente rami, tratta la maggior parte dei comandi come se richiedesse di operare al livello della directory in cui vi trovate e ai livelli sottostanti. Per esempio, se eseguite <command>svn log</command>, otterrete la cronologia di qualunque parte dell’albero stiate osservando, non dell’intero albero.</para> 1.140 + 1.141 + <para id="x_6fc">Il comportamento predefinito di Mercurial è differente perché i suoi comandi operano sull’intero repository. Eseguite <command>hg log</command> e vi mostrerà la cronologia dell’intero albero, a prescindere da quale parte della directory di lavoro stiate visitando in quel momento. Se volete solo la cronologia di un file o di una directory particolare, vi basta fornire un nome al comando, e.g. <command>hg log sorgenti</command>.</para> 1.142 1.143 <para id="x_6fd">Secondo la mia esperienza, questa differenza nel comportamento predefinito dei comandi è probabilmente la cosa che può confondervi di più se dovete spostarvi frequentemente avanti e indietro tra i due strumenti.</para> 1.144 </sect3> 1.145 @@ -161,7 +161,7 @@ 1.146 1.147 <para id="x_6fe">Con Subversion, è normale (anche se blandamente deprecato) che più persone collaborino su un singolo ramo. Se Alice e Bruno stanno lavorando insieme e Alice inserisce alcune modifiche nel ramo condiviso, Bruno deve aggiornare la vista del ramo del suo client prima di poter effettuare un commit. Dato che in quel momento non esiste alcuna registrazione permanente dei cambiamenti fatti da Bruno, le sue modifiche potrebbero rovinarsi o andare perdute durante e dopo questo aggiornamento.</para> 1.148 1.149 - <para id="x_6ff">Mercurial, invece, incoraggia un modello di inserimento-e-unione. Bruno inserisce le sue modifiche nella sua copia locale del repository prima di estrarre o trasmettere i cambiamenti da o verso il server che condivide con Alice. Se Alice trasmette i suoi cambiamenti prima che Bruno provi a trasmettere i propri, Bruno non sarà in grado di trasmettere i suoi cambiamenti prima di aver estratto quelli di Alice, averli incorporati e aver effettuato il commit dei risultati dell'unione. Se Bruno commette un errore durante l'unione, può sempre ritornare al commit con il quale aveva registrato i suoi cambiamenti.</para> 1.150 + <para id="x_6ff">Mercurial, invece, incoraggia un modello di inserimento-e-unione. Bruno inserisce le sue modifiche nella sua copia locale del repository prima di estrarre o trasmettere i cambiamenti da o verso il server che condivide con Alice. Se Alice trasmette i suoi cambiamenti prima che Bruno provi a trasmettere i propri, Bruno non sarà in grado di trasmettere i suoi cambiamenti prima di aver estratto quelli di Alice, averli incorporati e aver effettuato il commit dei risultati dell’unione. Se Bruno commette un errore durante l’unione, può sempre ritornare al commit con il quale aveva registrato i suoi cambiamenti.</para> 1.151 1.152 <para id="x_700">Vale la pena sottolineare che questi sono i modi più comuni di lavorare con questi strumenti. Subversion supporta un modello più sicuro per consentirvi di lavorare nel vostro ramo personale, che però in pratica si rivela abbastanza scomodo da non essere particolarmente diffuso. Mercurial può supportare un modello meno sicuro che permette di estrarre e unire i cambiamenti nonostante la presenza di modifiche non ancora registrate, ma questo è considerato estremamente inusuale.</para> 1.153 </sect3> 1.154 @@ -173,9 +173,9 @@ 1.155 1.156 <para id="x_702">Con Mercurial, i commit sono sempre locali e devono essere pubblicati successivamente tramite il comando <command>hg push</command>.</para> 1.157 1.158 - <para id="x_703">Ogni approccio ha i propri vantaggi e svantaggi. Il modello di Subversion prevede che i cambiamenti siano pubblicati, e quindi revisionabili e utilizzabili, immediatamente. D'altra parte, questo significa che un utente deve avere accesso in scrittura a un repository per utilizzare normalmente lo strumento, ma la maggior parte dei progetti open source non concede i permessi di scrittura alla leggera.</para> 1.159 - 1.160 - <para id="x_704">L'approccio di Mercurial consente a chiunque possa clonare un repository di inserirvi modifiche senza il bisogno del permesso di qualcun altro e di pubblicare i propri cambiamenti e continuare a partecipare nel modo che preferisce. A causa della distinzione tra le operazioni di inserimento e trasmissione dei cambiamenti, può capitare che qualcuno effettui il commit di alcune modifiche sul proprio computer e si allontani per qualche giorno dimenticandosi di trasmetterli, cosa che in rari casi potrebbe bloccare temporaneamente le attività dei collaboratori.</para> 1.161 + <para id="x_703">Ogni approccio ha i propri vantaggi e svantaggi. Il modello di Subversion prevede che i cambiamenti siano pubblicati, e quindi revisionabili e utilizzabili, immediatamente. D’altra parte, questo significa che un utente deve avere accesso in scrittura a un repository per utilizzare normalmente lo strumento, ma la maggior parte dei progetti open source non concede i permessi di scrittura alla leggera.</para> 1.162 + 1.163 + <para id="x_704">L’approccio di Mercurial consente a chiunque possa clonare un repository di inserirvi modifiche senza il bisogno del permesso di qualcun altro e di pubblicare i propri cambiamenti e continuare a partecipare nel modo che preferisce. A causa della distinzione tra le operazioni di inserimento e trasmissione dei cambiamenti, può capitare che qualcuno effettui il commit di alcune modifiche sul proprio computer e si allontani per qualche giorno dimenticandosi di trasmetterli, cosa che in rari casi potrebbe bloccare temporaneamente le attività dei collaboratori.</para> 1.164 </sect3> 1.165 </sect2> 1.166 1.167 @@ -270,7 +270,7 @@ 1.168 <entry><command>svn info</command></entry> 1.169 <entry><command>hg showconfig 1.170 paths.parent</command></entry> 1.171 - <entry>Mostra da quale URL è avvenuta l'estrazione</entry> 1.172 + <entry>Mostra da quale URL è avvenuta l’estrazione</entry> 1.173 </row> 1.174 <row> 1.175 <entry><command>svn list</command></entry> 1.176 @@ -327,9 +327,9 @@ 1.177 <sect1> 1.178 <title>Suggerimenti utili per i principianti</title> 1.179 1.180 - <para id="x_705">In alcuni sistemi di controllo di revisione, può diventare complicato stampare le differenze per una singola revisione registrata nel repository. Per esempio, con Subversion, per vedere cos'è cambiato nella revisione 104654 dovete digitare <command>svn diff -r104653:104654</command>. Mercurial elimina la necessità di digitare due volte l'identificatore di revisione in questo caso comune. Per ottenere solo le differenze, digitate <command>hg export 104654</command>. Per ottenere un messaggio dal registro della cronologia seguito dalle differenze, digitate <command>hg log -r104654 -p</command>.</para> 1.181 - 1.182 - <para id="x_706">Quando eseguite <command>hg status</command> senza argomenti, vi viene mostrato lo stato dell'intero albero, con i percorsi relativi alla radice del repository. Questo rende complicato copiare un nome di file dal risultato di <command>hg status</command> alla riga di comando. Se eseguite <command>hg status</command> passandogli il nome di un file o di una directory, il comando stamperà i percorsi relativi alla vostra posizione corrente. Quindi, per ottenere da <command>hg status</command> lo stato di tutto l'albero, con i percorsi relativi alla vostra directory corrente invece che alla radice del repository, passate il risultato di <command>hg root</command> al comando <command>hg status</command>. Su un sistema di tipo Unix, potete farlo facilmente nel modo che segue:</para> 1.183 + <para id="x_705">In alcuni sistemi di controllo di revisione, può diventare complicato stampare le differenze per una singola revisione registrata nel repository. Per esempio, con Subversion, per vedere cos’è cambiato nella revisione 104654 dovete digitare <command>svn diff -r104653:104654</command>. Mercurial elimina la necessità di digitare due volte l’identificatore di revisione in questo caso comune. Per ottenere solo le differenze, digitate <command>hg export 104654</command>. Per ottenere un messaggio dal registro della cronologia seguito dalle differenze, digitate <command>hg log -r104654 -p</command>.</para> 1.184 + 1.185 + <para id="x_706">Quando eseguite <command>hg status</command> senza argomenti, vi viene mostrato lo stato dell’intero albero, con i percorsi relativi alla radice del repository. Questo rende complicato copiare un nome di file dal risultato di <command>hg status</command> alla riga di comando. Se eseguite <command>hg status</command> passandogli il nome di un file o di una directory, il comando stamperà i percorsi relativi alla vostra posizione corrente. Quindi, per ottenere da <command>hg status</command> lo stato di tutto l’albero, con i percorsi relativi alla vostra directory corrente invece che alla radice del repository, passate il risultato di <command>hg root</command> al comando <command>hg status</command>. Su un sistema di tipo Unix, potete farlo facilmente nel modo che segue:</para> 1.186 1.187 <screen><prompt>$</prompt> <userinput>hg status `hg root`</userinput></screen> 1.188 </sect1>
2.1 --- a/it/appB-mq-ref.xml Sat Aug 22 21:01:56 2009 +0200 2.2 +++ b/it/appB-mq-ref.xml Sat Aug 22 21:55:05 2009 +0200 2.3 @@ -5,12 +5,12 @@ 2.4 <sect1 id="sec:mqref:cmdref"> 2.5 <title>Guida di riferimento ai comandi MQ</title> 2.6 2.7 - <para id="x_5e8">Per un'introduzione ai comandi forniti da MQ, usate il comando <command role="hg-cmd">hg help mq</command>.</para> 2.8 + <para id="x_5e8">Per un’introduzione ai comandi forniti da MQ, usate il comando <command role="hg-cmd">hg help mq</command>.</para> 2.9 2.10 <sect2> 2.11 <title><command role="hg-ext-mq">qapplied</command>&emdash;stampa le patch applicate</title> 2.12 2.13 - <para id="x_5e9">Il comando <command role="hg-ext-mq">qapplied</command> stampa la pila corrente delle patch applicate. Le patch vengono stampate in ordine dalla più vecchia alla più recente, così l'ultima patch nella lista è quella <quote>in cima</quote> alla pila.</para> 2.14 + <para id="x_5e9">Il comando <command role="hg-ext-mq">qapplied</command> stampa la pila corrente delle patch applicate. Le patch vengono stampate in ordine dalla più vecchia alla più recente, così l’ultima patch nella lista è quella <quote>in cima</quote> alla pila.</para> 2.15 2.16 </sect2> 2.17 <sect2> 2.18 @@ -18,12 +18,12 @@ 2.19 2.20 <para id="x_5ea">Il comando <command role="hg-ext-mq">qcommit</command> registra qualsiasi cambiamento in sospeso nel repository <filename role="special" class="directory">.hg/patches</filename>. Questo comando funziona solo se la directory <filename role="special" class="directory">.hg/patches</filename> è un repository, cioè se avete creato la directory usando <command role="hg-cmd">hg qinit <option role="hg-ext-mq-cmd-qinit-opt">-c</option></command> o avete invocato <command role="hg-cmd">hg init</command> nella directory dopo aver eseguito <command role="hg-ext-mq">qinit</command>.</para> 2.21 2.22 - <para id="x_5eb">Questo comando è un'abbreviazione di <command role="hg-cmd">hg commit --cwd .hg/patches</command>.</para> 2.23 + <para id="x_5eb">Questo comando è un’abbreviazione di <command role="hg-cmd">hg commit --cwd .hg/patches</command>.</para> 2.24 </sect2> 2.25 <sect2> 2.26 <title><command role="hg-ext-mq">qdelete</command>&emdash;elimina una patch dal file <filename role="special">series</filename></title> 2.27 2.28 - <para id="x_5ec">Il comando <command role="hg-ext-mq">qdelete</command> rimuove la voce relativa a una patch dal file <filename role="special">series</filename> nella directory <filename role="special" class="directory">.hg/patches</filename>. Non estrae la patch se la patch è già applicata. Per default, non cancella il file della patch, perciò dovrete usare l'opzione <option role="hg-ext-mq-cmd-qdel-opt">-f</option> se volete fare questo.</para> 2.29 + <para id="x_5ec">Il comando <command role="hg-ext-mq">qdelete</command> rimuove la voce relativa a una patch dal file <filename role="special">series</filename> nella directory <filename role="special" class="directory">.hg/patches</filename>. Non estrae la patch se la patch è già applicata. Per default, non cancella il file della patch, perciò dovrete usare l’opzione <option role="hg-ext-mq-cmd-qdel-opt">-f</option> se volete fare questo.</para> 2.30 2.31 <para id="x_5ed">Opzioni:</para> 2.32 <itemizedlist> 2.33 @@ -33,9 +33,9 @@ 2.34 2.35 </sect2> 2.36 <sect2> 2.37 - <title><command role="hg-ext-mq">qdiff</command>&emdash;stampa un diff dell'ultima patch applicata</title> 2.38 - 2.39 - <para id="x_5ef">Il comando <command role="hg-ext-mq">qdiff</command> stampa un diff dell'ultima patch applicata. È equivalente al comando <command role="hg-cmd">hg diff -r-2:-1</command>.</para> 2.40 + <title><command role="hg-ext-mq">qdiff</command>&emdash;stampa un diff dell’ultima patch applicata</title> 2.41 + 2.42 + <para id="x_5ef">Il comando <command role="hg-ext-mq">qdiff</command> stampa un diff dell’ultima patch applicata. È equivalente al comando <command role="hg-cmd">hg diff -r-2:-1</command>.</para> 2.43 2.44 </sect2> 2.45 <sect2> 2.46 @@ -47,11 +47,11 @@ 2.47 <sect2> 2.48 <title><command role="hg-ext-mq">qfold</command>&emdash;unisce (<quote>include</quote>) diverse patch in una</title> 2.49 2.50 - <para id="x_5f0">Il comando <command role="hg-ext-mq">qfold</command> unisce più patch all'ultima patch applicata, in modo che l'ultima patch applicata rappresenti l'unione di tutti i cambiamenti delle patch in questione.</para> 2.51 - 2.52 - <para id="x_5f1">Le patch da includere non devono essere applicate, altrimenti <command role="hg-ext-mq">qfold</command> terminerà segnalando un errore. L'ordine in cui le patch vengono incluse è significativo: <command role="hg-cmd">hg qfold a b</command> significa <quote>applica la patch più recente, seguita da <literal>a</literal>, seguita da <literal>b</literal></quote>.</para> 2.53 - 2.54 - <para id="x_5f2">I commenti delle patch incluse vengono aggiunti alla fine dei commenti della patch di destinazione, separando ogni blocco di commenti con tre caratteri di asterisco (<quote><literal>*</literal></quote>). Usate l'opzione <option role="hg-ext-mq-cmd-qfold-opt">-e</option> per modificare il messaggio di commit della patch/changeset combinata dopo che l'inclusione è stata completata.</para> 2.55 + <para id="x_5f0">Il comando <command role="hg-ext-mq">qfold</command> unisce più patch all’ultima patch applicata, in modo che l’ultima patch applicata rappresenti l’unione di tutti i cambiamenti delle patch in questione.</para> 2.56 + 2.57 + <para id="x_5f1">Le patch da includere non devono essere applicate, altrimenti <command role="hg-ext-mq">qfold</command> terminerà segnalando un errore. L’ordine in cui le patch vengono incluse è significativo: <command role="hg-cmd">hg qfold a b</command> significa <quote>applica la patch più recente, seguita da <literal>a</literal>, seguita da <literal>b</literal></quote>.</para> 2.58 + 2.59 + <para id="x_5f2">I commenti delle patch incluse vengono aggiunti alla fine dei commenti della patch di destinazione, separando ogni blocco di commenti con tre caratteri di asterisco (<quote><literal>*</literal></quote>). Usate l’opzione <option role="hg-ext-mq-cmd-qfold-opt">-e</option> per modificare il messaggio di commit della patch/changeset combinata dopo che l’inclusione è stata completata.</para> 2.60 2.61 <para id="x_5f3">Opzioni:</para> 2.62 <itemizedlist> 2.63 @@ -65,15 +65,15 @@ 2.64 2.65 </sect2> 2.66 <sect2> 2.67 - <title><command role="hg-ext-mq">qheader</command>&emdash;mostra l'intestazione/descrizione di una patch</title> 2.68 - 2.69 - <para id="x_5f7">Il comando <command role="hg-ext-mq">qheader</command> stampa l'intestazione, o descrizione, di una patch. Per default, stampa l'intestazione dell'ultima patch applicata. Dato un argomento, stampa l'intestazione della patch indicata.</para> 2.70 + <title><command role="hg-ext-mq">qheader</command>&emdash;mostra l’intestazione/descrizione di una patch</title> 2.71 + 2.72 + <para id="x_5f7">Il comando <command role="hg-ext-mq">qheader</command> stampa l’intestazione, o descrizione, di una patch. Per default, stampa l’intestazione dell’ultima patch applicata. Dato un argomento, stampa l’intestazione della patch indicata.</para> 2.73 2.74 </sect2> 2.75 <sect2> 2.76 <title><command role="hg-ext-mq">qimport</command>&emdash;importa una patch di terze parti nella coda</title> 2.77 2.78 - <para id="x_5f8">Il comando <command role="hg-ext-mq">qimport</command> aggiunge una voce per una patch esterna al file <filename role="special">series</filename> e copia la patch nella directory <filename role="special" class="directory">.hg/patches</filename>. Aggiunge la voce immediatamente dopo l'ultima patch applicata, ma non inserisce la patch.</para> 2.79 + <para id="x_5f8">Il comando <command role="hg-ext-mq">qimport</command> aggiunge una voce per una patch esterna al file <filename role="special">series</filename> e copia la patch nella directory <filename role="special" class="directory">.hg/patches</filename>. Aggiunge la voce immediatamente dopo l’ultima patch applicata, ma non inserisce la patch.</para> 2.80 2.81 <para id="x_5f9">Se la directory <filename role="special" class="directory">.hg/patches</filename> è un repository, <command role="hg-ext-mq">qimport</command> usa <command role="hg-cmd">hg add</command> per aggiungere automaticamente la patch importata.</para> 2.82 2.83 @@ -95,15 +95,15 @@ 2.84 <sect2> 2.85 <title><command role="hg-ext-mq">qnew</command>&emdash;crea una nuova patch</title> 2.86 2.87 - <para id="x_5fe">Il comando <command role="hg-ext-mq">qnew</command> crea una nuova patch. Prende come argomento obbligatorio il nome da usare per il file di patch. La nuova patch viene creata vuota per default, viene aggiunta al file <filename role="special">series</filename> dopo l'ultima patch applicata e viene immediatamente inserita sopra quella patch.</para> 2.88 - 2.89 - <para id="x_5ff">Se <command role="hg-ext-mq">qnew</command> trova qualche file modificato nella directory di lavoro, si rifiuterà di creare una nuova patch a meno che non usiate l'opzione <option role="hg-ext-mq-cmd-qnew-opt">-f</option> (vedete più avanti). Questo comportamento vi permette di aggiornare l'ultima patch applicata tramite <command role="hg-ext-mq">qrefresh</command> prima di applicare una nuova patch.</para> 2.90 + <para id="x_5fe">Il comando <command role="hg-ext-mq">qnew</command> crea una nuova patch. Prende come argomento obbligatorio il nome da usare per il file di patch. La nuova patch viene creata vuota per default, viene aggiunta al file <filename role="special">series</filename> dopo l’ultima patch applicata e viene immediatamente inserita sopra quella patch.</para> 2.91 + 2.92 + <para id="x_5ff">Se <command role="hg-ext-mq">qnew</command> trova qualche file modificato nella directory di lavoro, si rifiuterà di creare una nuova patch a meno che non usiate l’opzione <option role="hg-ext-mq-cmd-qnew-opt">-f</option> (vedete più avanti). Questo comportamento vi permette di aggiornare l’ultima patch applicata tramite <command role="hg-ext-mq">qrefresh</command> prima di applicare una nuova patch.</para> 2.93 2.94 <para id="x_600">Opzioni:</para> 2.95 <itemizedlist> 2.96 - <listitem><para id="x_601"><option role="hg-ext-mq-cmd-qnew-opt">-f</option>: crea una nuova patch se il contenuto della directory di lavoro è stato modificato. Ogni cambiamento in sospeso viene aggiunto alla patch appena creata, pertanto al termine dell'esecuzione del comando la directory di lavoro non risulterà più modificata.</para> 2.97 - </listitem> 2.98 - <listitem><para id="x_602"><option role="hg-ext-mq-cmd-qnew-opt">-m</option>: usa il testo dato come messaggio di commit. Il testo verrà memorizzato all'inizio del file di patch, prima dei dati di patch.</para> 2.99 + <listitem><para id="x_601"><option role="hg-ext-mq-cmd-qnew-opt">-f</option>: crea una nuova patch se il contenuto della directory di lavoro è stato modificato. Ogni cambiamento in sospeso viene aggiunto alla patch appena creata, pertanto al termine dell’esecuzione del comando la directory di lavoro non risulterà più modificata.</para> 2.100 + </listitem> 2.101 + <listitem><para id="x_602"><option role="hg-ext-mq-cmd-qnew-opt">-m</option>: usa il testo dato come messaggio di commit. Il testo verrà memorizzato all’inizio del file di patch, prima dei dati di patch.</para> 2.102 </listitem> 2.103 </itemizedlist> 2.104 2.105 @@ -111,7 +111,7 @@ 2.106 <sect2> 2.107 <title><command role="hg-ext-mq">qnext</command>&emdash;stampa il nome della patch successiva</title> 2.108 2.109 - <para id="x_603">Il comando <command role="hg-ext-mq">qnext</command> stampa il nome della patch nel file <filename role="special">series</filename> che segue la patch applicata più recentemente. Questa patch diventerà l'ultima patch applicata se invocate <command role="hg-ext-mq">qpush</command>.</para> 2.110 + <para id="x_603">Il comando <command role="hg-ext-mq">qnext</command> stampa il nome della patch nel file <filename role="special">series</filename> che segue la patch applicata più recentemente. Questa patch diventerà l’ultima patch applicata se invocate <command role="hg-ext-mq">qpush</command>.</para> 2.111 2.112 </sect2> 2.113 <sect2> 2.114 @@ -121,17 +121,17 @@ 2.115 2.116 <para id="x_605">Questo comando rimuove dal repository i changeset che rappresentano le patch estratte e aggiorna la directory di lavoro per annullare gli effetti delle patch.</para> 2.117 2.118 - <para id="x_606">Questo comando accetta un argomento opzionale che viene usato per indicare il nome o l'indice numerico della patch da estrarre. Se viene passato un nome, il comando continuerà a estrarre patch fino a quando la patch nominata sarà in cima alla pila delle patch applicate. Se viene passato un numero, <command role="hg-ext-mq">qpop</command> tratterà il numero come un indice d'accesso alle voci presenti nel file della serie, partendo da zero (le righe vuote e le righe contenenti solo commenti non vengono contate). Il comando continuerà a estrarre patch fino a quando la patch identificata dall'indice dato sarà in cima alla pila delle patch applicate.</para> 2.119 - 2.120 - <para id="x_607">Il comando <command role="hg-ext-mq">qpop</command> non legge e non modifica né le patch né il file <filename role="special">series</filename>. Perciò, potete tranquillamente usare <command role="hg-ext-mq">qpop</command> su una patch che avete rimosso dal file <filename role="special">series</filename>, oppure su una patch che avete rinominato o completamente cancellato. Negli ultimi due casi, usate il nome che la patch aveva quando l'avete applicata.</para> 2.121 - 2.122 - <para id="x_608">Per default, il comando <command role="hg-ext-mq">qpop</command> non estrarrà alcuna patch se la directory di lavoro è stata modificata. Potete cambiare questo comportamento usando l'opzione <option role="hg-ext-mq-cmd-qpop-opt">-f</option>, che annulla tutte le modifiche nella directory di lavoro.</para> 2.123 + <para id="x_606">Questo comando accetta un argomento opzionale che viene usato per indicare il nome o l’indice numerico della patch da estrarre. Se viene passato un nome, il comando continuerà a estrarre patch fino a quando la patch nominata sarà in cima alla pila delle patch applicate. Se viene passato un numero, <command role="hg-ext-mq">qpop</command> tratterà il numero come un indice d’accesso alle voci presenti nel file della serie, partendo da zero (le righe vuote e le righe contenenti solo commenti non vengono contate). Il comando continuerà a estrarre patch fino a quando la patch identificata dall’indice dato sarà in cima alla pila delle patch applicate.</para> 2.124 + 2.125 + <para id="x_607">Il comando <command role="hg-ext-mq">qpop</command> non legge e non modifica né le patch né il file <filename role="special">series</filename>. Perciò, potete tranquillamente usare <command role="hg-ext-mq">qpop</command> su una patch che avete rimosso dal file <filename role="special">series</filename>, oppure su una patch che avete rinominato o completamente cancellato. Negli ultimi due casi, usate il nome che la patch aveva quando l’avete applicata.</para> 2.126 + 2.127 + <para id="x_608">Per default, il comando <command role="hg-ext-mq">qpop</command> non estrarrà alcuna patch se la directory di lavoro è stata modificata. Potete cambiare questo comportamento usando l’opzione <option role="hg-ext-mq-cmd-qpop-opt">-f</option>, che annulla tutte le modifiche nella directory di lavoro.</para> 2.128 2.129 <para id="x_609">Opzioni:</para> 2.130 <itemizedlist> 2.131 <listitem><para id="x_60a"><option role="hg-ext-mq-cmd-qpop-opt">-a</option>: estrae tutte le patch applicate, riportando il repository allo stato in cui era prima che applicaste qualunque patch.</para> 2.132 </listitem> 2.133 - <listitem><para id="x_60b"><option role="hg-ext-mq-cmd-qpop-opt">-f</option>: annulla forzatamente qualsiasi modifica alla directory di lavoro al momento dell'estrazione.</para> 2.134 + <listitem><para id="x_60b"><option role="hg-ext-mq-cmd-qpop-opt">-f</option>: annulla forzatamente qualsiasi modifica alla directory di lavoro al momento dell’estrazione.</para> 2.135 </listitem> 2.136 <listitem><para id="x_60c"><option role="hg-ext-mq-cmd-qpop-opt">-n</option>: estrae una patch dalla coda nominata.</para> 2.137 </listitem> 2.138 @@ -143,7 +143,7 @@ 2.139 <sect2> 2.140 <title><command role="hg-ext-mq">qprev</command>&emdash;stampa il nome della patch precedente</title> 2.141 2.142 - <para id="x_60e">Il comando <command role="hg-ext-mq">qprev</command> stampa il nome della patch nel file <filename role="special">series</filename> che precede la patch applicata più recentemente. Questa patch diventerà l'ultima patch applicata se invocate <command role="hg-ext-mq">qpop</command>.</para> 2.143 + <para id="x_60e">Il comando <command role="hg-ext-mq">qprev</command> stampa il nome della patch nel file <filename role="special">series</filename> che precede la patch applicata più recentemente. Questa patch diventerà l’ultima patch applicata se invocate <command role="hg-ext-mq">qpop</command>.</para> 2.144 2.145 </sect2> 2.146 <sect2 id="sec:mqref:cmd:qpush"> 2.147 @@ -155,14 +155,14 @@ 2.148 2.149 <para id="x_611">I dati predefiniti usati per creare un changeset sono i seguenti.</para> 2.150 <itemizedlist> 2.151 - <listitem><para id="x_612">La data e il fuso orario del commit sono la data e il fuso orario corrente. Dato che questi dati vengono usati per computare l'identità di un changeset, questo significa che se invocate <command role="hg-ext-mq">qpop</command> su una patch e poi invocate <command role="hg-ext-mq">qpush</command> sulla stessa patch, il changeset che inserite avrà un'identità diversa dal changeset che avete estratto.</para> 2.152 - </listitem> 2.153 - <listitem><para id="x_613">L'autore è quello predefinito usato dal comando <command role="hg-cmd">hg commit</command>.</para> 2.154 + <listitem><para id="x_612">La data e il fuso orario del commit sono la data e il fuso orario corrente. Dato che questi dati vengono usati per computare l’identità di un changeset, questo significa che se invocate <command role="hg-ext-mq">qpop</command> su una patch e poi invocate <command role="hg-ext-mq">qpush</command> sulla stessa patch, il changeset che inserite avrà un’identità diversa dal changeset che avete estratto.</para> 2.155 + </listitem> 2.156 + <listitem><para id="x_613">L’autore è quello predefinito usato dal comando <command role="hg-cmd">hg commit</command>.</para> 2.157 </listitem> 2.158 <listitem><para id="x_614">Il messaggio di commit è il testo proveniente dal file di patch che precede la prima intestazione del diff. Se questo testo non è presente, viene usato un messaggio di commit predefinito che identifica il nome della patch.</para> 2.159 </listitem> 2.160 </itemizedlist> 2.161 - <para id="x_615">Se una patch contiene un'intestazione di patch Mercurial, i dati nell'intestazione di patch sostituiscono quelli predefiniti.</para> 2.162 + <para id="x_615">Se una patch contiene un’intestazione di patch Mercurial, i dati nell’intestazione di patch sostituiscono quelli predefiniti.</para> 2.163 2.164 <para id="x_616">Opzioni:</para> 2.165 <itemizedlist> 2.166 @@ -170,9 +170,9 @@ 2.167 </listitem> 2.168 <listitem><para id="x_618"><option role="hg-ext-mq-cmd-qpush-opt">-l</option>: aggiunge il nome della patch alla fine del messaggio di commit.</para> 2.169 </listitem> 2.170 - <listitem><para id="x_619"><option role="hg-ext-mq-cmd-qpush-opt">-m</option>: se l'applicazione di una patch fallisce, usa la voce relativa alla patch contenuta in un'altra coda salvata per computare i parametri di un'unione a tre vie, effettuando poi l'unione a tre vie attraverso il normale meccanismo di unione di Mercurial. Usa il risultato dell'unione come nuovo contenuto della patch.</para> 2.171 - </listitem> 2.172 - <listitem><para id="x_61a"><option role="hg-ext-mq-cmd-qpush-opt">-n</option>: usa la coda nominata se effettua un'unione durante l'inserimento.</para> 2.173 + <listitem><para id="x_619"><option role="hg-ext-mq-cmd-qpush-opt">-m</option>: se l’applicazione di una patch fallisce, usa la voce relativa alla patch contenuta in un’altra coda salvata per computare i parametri di un’unione a tre vie, effettuando poi l’unione a tre vie attraverso il normale meccanismo di unione di Mercurial. Usa il risultato dell’unione come nuovo contenuto della patch.</para> 2.174 + </listitem> 2.175 + <listitem><para id="x_61a"><option role="hg-ext-mq-cmd-qpush-opt">-n</option>: usa la coda nominata se effettua un’unione durante l’inserimento.</para> 2.176 </listitem> 2.177 </itemizedlist> 2.178 2.179 @@ -181,9 +181,9 @@ 2.180 </sect2> 2.181 <sect2> 2.182 <title><command 2.183 - role="hg-ext-mq">qrefresh</command>&emdash;aggiorna l'ultima patch applicata</title> 2.184 - 2.185 - <para id="x_61c">Il comando <command role="hg-ext-mq">qrefresh</command> aggiorna l'ultima patch applicata. Modifica la patch, rimuove il vecchio changeset che rappresentava la patch e crea un nuovo changeset per rappresentare la patch modificata.</para> 2.186 + role="hg-ext-mq">qrefresh</command>&emdash;aggiorna l’ultima patch applicata</title> 2.187 + 2.188 + <para id="x_61c">Il comando <command role="hg-ext-mq">qrefresh</command> aggiorna l’ultima patch applicata. Modifica la patch, rimuove il vecchio changeset che rappresentava la patch e crea un nuovo changeset per rappresentare la patch modificata.</para> 2.189 2.190 <para id="x_61d">Il comando <command role="hg-ext-mq">qrefresh</command> si occupa delle seguenti modifiche.</para> 2.191 <itemizedlist> 2.192 @@ -195,11 +195,11 @@ 2.193 </listitem> 2.194 </itemizedlist> 2.195 2.196 - <para id="x_621">Anche se <command role="hg-ext-mq">qrefresh</command> non trova alcun cambiamento, ricrea comunque il changeset che rappresenta la patch. Questo produce una differenza tra l'identità del nuovo changeset e quella del precedente changeset che identificava la patch.</para> 2.197 + <para id="x_621">Anche se <command role="hg-ext-mq">qrefresh</command> non trova alcun cambiamento, ricrea comunque il changeset che rappresenta la patch. Questo produce una differenza tra l’identità del nuovo changeset e quella del precedente changeset che identificava la patch.</para> 2.198 2.199 <para id="x_622">Opzioni:</para> 2.200 <itemizedlist> 2.201 - <listitem><para id="x_623"><option role="hg-ext-mq-cmd-qrefresh-opt">-e</option>: modifica il messaggio di commit e la descrizione della patch, usando l'editor di testo preferito.</para> 2.202 + <listitem><para id="x_623"><option role="hg-ext-mq-cmd-qrefresh-opt">-e</option>: modifica il messaggio di commit e la descrizione della patch, usando l’editor di testo preferito.</para> 2.203 </listitem> 2.204 <listitem><para id="x_624"><option role="hg-ext-mq-cmd-qrefresh-opt">-m</option>: modifica il messaggio di commit e la descrizione della patch, usando il testo dato.</para> 2.205 </listitem> 2.206 @@ -213,13 +213,13 @@ 2.207 2.208 <para id="x_626">Il comando <command role="hg-ext-mq">qrename</command> rinomina una patch e modifica la voce relativa alla patch nel file <filename role="special">series</filename>.</para> 2.209 2.210 - <para id="x_627">Con un singolo argomento, <command role="hg-ext-mq">qrename</command> rinomina l'ultima patch applicata. Con due argomenti, cambia il nome del primo argomento al secondo argomento.</para> 2.211 - 2.212 - </sect2> 2.213 - <sect2> 2.214 - <title><command role="hg-ext-mq">qseries</command>&emdash;stampa l'intera serie di patch</title> 2.215 - 2.216 - <para id="x_62a">Il comando <command role="hg-ext-mq">qseries</command> stampa l'intera serie di patch contenuta nel file <filename role="special">series</filename>. Stampa solo i nomi delle patch, saltando le righe vuote e i commenti. Stampa le patch in ordine dalla prima patch da applicare all'ultima.</para> 2.217 + <para id="x_627">Con un singolo argomento, <command role="hg-ext-mq">qrename</command> rinomina l’ultima patch applicata. Con due argomenti, cambia il nome del primo argomento al secondo argomento.</para> 2.218 + 2.219 + </sect2> 2.220 + <sect2> 2.221 + <title><command role="hg-ext-mq">qseries</command>&emdash;stampa l’intera serie di patch</title> 2.222 + 2.223 + <para id="x_62a">Il comando <command role="hg-ext-mq">qseries</command> stampa l’intera serie di patch contenuta nel file <filename role="special">series</filename>. Stampa solo i nomi delle patch, saltando le righe vuote e i commenti. Stampa le patch in ordine dalla prima patch da applicare all’ultima.</para> 2.224 2.225 </sect2> 2.226 <sect2> 2.227 @@ -232,7 +232,7 @@ 2.228 <title><command 2.229 role="hg-ext-mq">qunapplied</command>&emdash;stampa le patch non ancora applicate</title> 2.230 2.231 - <para id="x_62c">Il comando <command role="hg-ext-mq">qunapplied</command> stampa i nomi delle patch non ancora applicate contenute nel file <filename role="special">series</filename>, nell'ordine in cui le patch verrebbero inserite.</para> 2.232 + <para id="x_62c">Il comando <command role="hg-ext-mq">qunapplied</command> stampa i nomi delle patch non ancora applicate contenute nel file <filename role="special">series</filename>, nell’ordine in cui le patch verrebbero inserite.</para> 2.233 2.234 </sect2> 2.235 <sect2> 2.236 @@ -259,13 +259,13 @@ 2.237 <sect2> 2.238 <title>Il file <filename role="special">series</filename></title> 2.239 2.240 - <para id="x_633">Il file <filename role="special">series</filename> contiene una lista dei nomi di tutte le patch che MQ può applicare. Viene rappresentato come una lista di nomi, con un nome salvato per riga. Lo spazio bianco all'inizio e alla fine di ogni riga viene ignorato.</para> 2.241 + <para id="x_633">Il file <filename role="special">series</filename> contiene una lista dei nomi di tutte le patch che MQ può applicare. Viene rappresentato come una lista di nomi, con un nome salvato per riga. Lo spazio bianco all’inizio e alla fine di ogni riga viene ignorato.</para> 2.242 2.243 <para id="x_634">Le righe possono contenere commenti. Un commento comincia con il carattere <quote><literal>#</literal></quote> e si estende fino alla fine della riga. Le righe vuote e le righe che contengono solo commenti vengono ignorate.</para> 2.244 2.245 - <para id="x_635">Avrete spesso bisogno di modificare il file <filename role="special">series</filename> a mano, da cui il supporto per i commenti e le righe vuote appena descritto. Per esempio, potete commentare temporaneamente una patch in modo che <command role="hg-ext-mq">qpush</command> la salti quando applica le patch. Potete anche cambiare l'ordine in cui le patch vengono applicate riordinando le loro voci nel file <filename role="special">series</filename>.</para> 2.246 - 2.247 - <para id="x_636">Viene anche supportata la possibilità di mettere il file <filename role="special">series</filename> sotto controllo di revisione. È una buona idea mettere sotto controllo di revisione anche tutte le patch a cui il file si riferisce. Se create una directory di patch usando l'opzione <option role="hg-ext-mq-cmd-qinit-opt">-c</option> del comando <command role="hg-ext-mq">qinit</command>, questo verrà fatto per voi automaticamente.</para> 2.248 + <para id="x_635">Avrete spesso bisogno di modificare il file <filename role="special">series</filename> a mano, da cui il supporto per i commenti e le righe vuote appena descritto. Per esempio, potete commentare temporaneamente una patch in modo che <command role="hg-ext-mq">qpush</command> la salti quando applica le patch. Potete anche cambiare l’ordine in cui le patch vengono applicate riordinando le loro voci nel file <filename role="special">series</filename>.</para> 2.249 + 2.250 + <para id="x_636">Viene anche supportata la possibilità di mettere il file <filename role="special">series</filename> sotto controllo di revisione. È una buona idea mettere sotto controllo di revisione anche tutte le patch a cui il file si riferisce. Se create una directory di patch usando l’opzione <option role="hg-ext-mq-cmd-qinit-opt">-c</option> del comando <command role="hg-ext-mq">qinit</command>, questo verrà fatto per voi automaticamente.</para> 2.251 2.252 </sect2> 2.253 <sect2>
3.1 --- a/it/appC-srcinstall.xml Sat Aug 22 21:01:56 2009 +0200 3.2 +++ b/it/appC-srcinstall.xml Sat Aug 22 21:55:05 2009 +0200 3.3 @@ -9,7 +9,7 @@ 3.4 <orderedlist> 3.5 <listitem><para id="x_5e1">Scaricate un archivio dei sorgenti recente da <ulink url="http://www.selenic.com/mercurial/download">http://www.selenic.com/mercurial/download</ulink>.</para> 3.6 </listitem> 3.7 - <listitem><para id="x_5e2">Estraete i contenuti dell'archivio:</para> 3.8 + <listitem><para id="x_5e2">Estraete i contenuti dell’archivio:</para> 3.9 <programlisting>gzip -dc mercurial-VERSIONE.tar.gz | tar xf -</programlisting> 3.10 </listitem> 3.11 <listitem><para id="x_5e3">Posizionatevi nella directory dei sorgenti ed eseguite lo script di installazione che assemblerà Mercurial e lo installerà nella vostra directory personale.</para> 3.12 @@ -17,9 +17,9 @@ 3.13 python setup.py install --force --home=$HOME</programlisting> 3.14 </listitem> 3.15 </orderedlist> 3.16 - <para id="x_5e4">Una volta che l'installazione è terminata, Mercurial si troverà nella sottodirectory <literal>bin</literal> della vostra directory personale. Non dimenticate di assicurarvi che questa directory sia presente nel percorso di ricerca della vostra shell.</para> 3.17 + <para id="x_5e4">Una volta che l’installazione è terminata, Mercurial si troverà nella sottodirectory <literal>bin</literal> della vostra directory personale. Non dimenticate di assicurarvi che questa directory sia presente nel percorso di ricerca della vostra shell.</para> 3.18 3.19 - <para id="x_5e5">Probabilmente avrete bisogno di impostare la variabile d'ambiente <envar>PYTHONPATH</envar> in modo che l'eseguibile di Mercurial possa trovare il resto dei pacchetti di Mercurial. Per esempio, sul mio portatile, ho impostato il valore di quella variabile a <literal>/home/bos/lib/python</literal>. Il percorso esatto dipende da come Python è stato installato sul vostro sistema, ma dovrebbe essere facile da scoprire. Se non siete sicuri, date un'occhiata alle informazioni precedentemente stampate dallo script di installazione e cercate il luogo in cui i contenuti della directory <literal>mercurial</literal> sono stati installati.</para> 3.20 + <para id="x_5e5">Probabilmente avrete bisogno di impostare la variabile d’ambiente <envar>PYTHONPATH</envar> in modo che l’eseguibile di Mercurial possa trovare il resto dei pacchetti di Mercurial. Per esempio, sul mio portatile, ho impostato il valore di quella variabile a <literal>/home/bos/lib/python</literal>. Il percorso esatto dipende da come Python è stato installato sul vostro sistema, ma dovrebbe essere facile da scoprire. Se non siete sicuri, date un’occhiata alle informazioni precedentemente stampate dallo script di installazione e cercate il luogo in cui i contenuti della directory <literal>mercurial</literal> sono stati installati.</para> 3.21 3.22 </sect1> 3.23 <sect1> 3.24 @@ -27,7 +27,7 @@ 3.25 3.26 <para id="x_5e6">Assemblare e installare Mercurial sotto Windows richiede una varietà di strumenti, una certa quantità di conoscenze tecniche e una considerevole dose di pazienza. Vi suggerisco vivamente di <emphasis>non</emphasis> seguire questa strada se siete un <quote>utente occasionale</quote>. A meno che non intendiate lavorare su Mercurial, vi raccomando invece di usare un pacchetto di installazione eseguibile.</para> 3.27 3.28 - <para id="x_5e7">Se avete intenzione di assemblare Mercurial dai sorgenti su Windows, seguite le direttive <quote>pratiche</quote> sul wiki di Mercurial all'indirizzo <ulink url="http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall">http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall</ulink> e aspettatevi che il processo comporti lo svolgimento di numerose operazioni complicate.</para> 3.29 + <para id="x_5e7">Se avete intenzione di assemblare Mercurial dai sorgenti su Windows, seguite le direttive <quote>pratiche</quote> sul wiki di Mercurial all’indirizzo <ulink url="http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall">http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall</ulink> e aspettatevi che il processo comporti lo svolgimento di numerose operazioni complicate.</para> 3.30 3.31 </sect1> 3.32 </appendix>
4.1 --- a/it/appD-license.xml Sat Aug 22 21:01:56 2009 +0200 4.2 +++ b/it/appD-license.xml Sat Aug 22 21:55:05 2009 +0200 4.3 @@ -12,14 +12,14 @@ 4.4 <para id="x_63a">Proper form for an incorporation by reference is as follows:</para> 4.5 4.6 <blockquote> 4.7 - <para id="x_63b">Copyright (c) <emphasis>year</emphasis> by <emphasis>author's name or designee</emphasis>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v<emphasis>x.y</emphasis> or later (the latest version is presently available at <ulink url="http://www.opencontent.org/openpub/">http://www.opencontent.org/openpub/</ulink>).</para> 4.8 + <para id="x_63b">Copyright (c) <emphasis>year</emphasis> by <emphasis>author’s name or designee</emphasis>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v<emphasis>x.y</emphasis> or later (the latest version is presently available at <ulink url="http://www.opencontent.org/openpub/">http://www.opencontent.org/openpub/</ulink>).</para> 4.9 </blockquote> 4.10 4.11 <para id="x_63c">The reference must be immediately followed with any options elected by the author(s) and/or publisher of the document (see <xref linkend="sec:opl:options"/>).</para> 4.12 4.13 <para id="x_63d">Commercial redistribution of Open Publication-licensed material is permitted.</para> 4.14 4.15 - <para id="x_63e">Any publication in standard (paper) book form shall require the citation of the original publisher and author. The publisher and author's names shall appear on all outer surfaces of the book. On all outer surfaces of the book the original publisher's name shall be as large as the title of the work and cited as possessive with respect to the title.</para> 4.16 + <para id="x_63e">Any publication in standard (paper) book form shall require the citation of the original publisher and author. The publisher and author’s names shall appear on all outer surfaces of the book. On all outer surfaces of the book the original publisher’s name shall be as large as the title of the work and cited as possessive with respect to the title.</para> 4.17 4.18 </sect1> 4.19 <sect1> 4.20 @@ -54,7 +54,7 @@ 4.21 </listitem> 4.22 <listitem><para id="x_648">The location of the original unmodified document must be identified.</para> 4.23 </listitem> 4.24 - <listitem><para id="x_649">The original author's (or authors') name(s) may not be used to assert or imply endorsement of the resulting document without the original author's (or authors') permission.</para> 4.25 + <listitem><para id="x_649">The original author’s (or authors’) name(s) may not be used to assert or imply endorsement of the resulting document without the original author’s (or authors’) permission.</para> 4.26 </listitem></orderedlist> 4.27 4.28 </sect1>
5.1 --- a/it/book-shortcuts.xml Sat Aug 22 21:01:56 2009 +0200 5.2 +++ b/it/book-shortcuts.xml Sat Aug 22 21:55:05 2009 +0200 5.3 @@ -1,5 +1,6 @@ 5.4 <!-- Please keep the contents of this file sorted. --> 5.5 5.6 <!ENTITY Agrave "À"> 5.7 +<!ENTITY rsquo "’"> 5.8 <!ENTITY Egrave "È"> 5.9 <!ENTITY emdash "—">
6.1 --- a/it/ch00-preface.xml Sat Aug 22 21:01:56 2009 +0200 6.2 +++ b/it/ch00-preface.xml Sat Aug 22 21:55:05 2009 +0200 6.3 @@ -7,30 +7,30 @@ 6.4 6.5 <para id="x_72e">Alcuni anni fa, quando cominciai a sentire il desiderio di spiegare perché credevo che il controllo di revisione distribuito fosse importante, questo campo era talmente nuovo che la letteratura pubblicata da offrire come riferimento alle persone interessate era quasi inesistente.</para> 6.6 6.7 - <para id="x_72f">Sebbene a quel tempo fossi abbastanza impegnato a lavorare sui meccanismi interni di Mercurial, mi misi a scrivere questo libro perché sembrava il modo più efficace di aiutare il software a raggiungere il grande pubblico, accompagnandolo con l'idea che il controllo di revisione dovesse essere distribuito per natura. Rendo il libro disponibile online secondo i termini di una licenza liberale per la stessa ragione: per diffondere il messaggio.</para> 6.8 + <para id="x_72f">Sebbene a quel tempo fossi abbastanza impegnato a lavorare sui meccanismi interni di Mercurial, mi misi a scrivere questo libro perché sembrava il modo più efficace di aiutare il software a raggiungere il grande pubblico, accompagnandolo con l’idea che il controllo di revisione dovesse essere distribuito per natura. Rendo il libro disponibile online secondo i termini di una licenza liberale per la stessa ragione: per diffondere il messaggio.</para> 6.9 6.10 - <para id="x_730">Un buon libro di software possiede un ritmo familiare che assomiglia da vicino al racconto di una storia: che cos'è questa cosa? Perché è importante? Come mi aiuterà? Come si usa? In questo libro, provo a rispondere a queste domande per il controllo di revisione distribuito in generale e per Mercurial in particolare.</para> 6.11 + <para id="x_730">Un buon libro di software possiede un ritmo familiare che assomiglia da vicino al racconto di una storia: che cos’è questa cosa? Perché è importante? Come mi aiuterà? Come si usa? In questo libro, provo a rispondere a queste domande per il controllo di revisione distribuito in generale e per Mercurial in particolare.</para> 6.12 </sect1> 6.13 6.14 <sect1> 6.15 <title>Grazie per il vostro sostegno a Mercurial</title> 6.16 6.17 - <para id="x_731">Acquistando una copia di questo libro state sostenendo il continuo sviluppo e la libertà ininterrotta di Mercurial in particolare e del software libero e open source in generale. O'Reilly Media e io stiamo donando le mie royalty sulle vendite di questo libro alla Software Freedom Conservancy (<ulink 6.18 + <para id="x_731">Acquistando una copia di questo libro state sostenendo il continuo sviluppo e la libertà ininterrotta di Mercurial in particolare e del software libero e open source in generale. O’Reilly Media e io stiamo donando le mie royalty sulle vendite di questo libro alla Software Freedom Conservancy (<ulink 6.19 url="http://www.softwarefreedom.org/">http://www.softwarefreedom.org/</ulink>) che fornisce supporto in termini di personale e di assistenza legale a Mercurial e a un certo numero di altri progetti software open source importanti e meritevoli.</para> 6.20 </sect1> 6.21 6.22 <sect1> 6.23 <title>Ringraziamenti</title> 6.24 6.25 - <para id="x_732">Questo libro non esisterebbe se non fosse per gli sforzi di Matt Mackall, l'autore e capo progetto di Mercurial. Lo assistono abilmente centinaia di collaboratori volontari sparsi in tutto il mondo.</para> 6.26 + <para id="x_732">Questo libro non esisterebbe se non fosse per gli sforzi di Matt Mackall, l’autore e capo progetto di Mercurial. Lo assistono abilmente centinaia di collaboratori volontari sparsi in tutto il mondo.</para> 6.27 6.28 <para id="x_733">I miei figli, Cian e Ruairi, si sono sempre fatti trovare pronti per aiutarmi a rilassarmi con meravigliosi e spericolati giochi da bambini. Vorrei anche ringraziare la mia ex moglie, Shannon, per il suo supporto.</para> 6.29 6.30 <para id="x_734">I miei colleghi e amici hanno fornito aiuto e sostegno in innumerevoli modi. Questa lista di persone non può che essere decisamente incompleta: Stephen Hahn, Karyn Ritter, Bonnie Corwin, James Vasile, Matt Norwood, Eben Moglen, Bradley Kuhn, Robert Walsh, Jeremy Fitzhardinge, Rachel Chalmers.</para> 6.31 6.32 - <para id="x_735">Ho sviluppato questo libro pubblicamente, mettendo sul sito web del libro le bozze dei capitoli mano a mano che li completavo. I lettori mi hanno poi mandato le loro opinioni usando un'applicazione web da me creata. Al momento in cui ho terminato il libro, più di 100 persone avevano inviato il proprio parere, un numero impressionante considerando che il sistema di commenti è stato attivo solo per circa due mesi verso la fine del processo di scrittura.</para> 6.33 + <para id="x_735">Ho sviluppato questo libro pubblicamente, mettendo sul sito web del libro le bozze dei capitoli mano a mano che li completavo. I lettori mi hanno poi mandato le loro opinioni usando un’applicazione web da me creata. Al momento in cui ho terminato il libro, più di 100 persone avevano inviato il proprio parere, un numero impressionante considerando che il sistema di commenti è stato attivo solo per circa due mesi verso la fine del processo di scrittura.</para> 6.34 6.35 - <para id="x_736">In particolare, vorrei esprimere la mia riconoscenza alle seguenti persone, che tra loro hanno contribuito più di un terzo del numero totale di commenti. Vorrei ringraziarli per la cura e l'impegno che hanno messo nel fornire un giudizio talmente tanto dettagliato.</para> 6.36 + <para id="x_736">In particolare, vorrei esprimere la mia riconoscenza alle seguenti persone, che tra loro hanno contribuito più di un terzo del numero totale di commenti. Vorrei ringraziarli per la cura e l’impegno che hanno messo nel fornire un giudizio talmente tanto dettagliato.</para> 6.37 6.38 <para id="x_737">Martin Geisler, Damien Cassou, Alexey Bakhirkin, Till Plewe, Dan Himes, Paul Sargent, Gokberk Hamurcu, Matthijs van der Vleuten, Michael Chermside, John Mulligan, Jordi Fita, Jon Parise.</para> 6.39 6.40 @@ -57,7 +57,7 @@ 6.41 <term><literal>Spaziatura fissa</literal></term> 6.42 6.43 <listitem> 6.44 - <para id="x_73c">Usato per i listati dei programmi e all'interno di paragrafi che fanno riferimento a elementi di programmazione come variabili o nomi di funzione, database, tipi di dato, variabili d'ambiente, istruzioni e parole chiave.</para> 6.45 + <para id="x_73c">Usato per i listati dei programmi e all’interno di paragrafi che fanno riferimento a elementi di programmazione come variabili o nomi di funzione, database, tipi di dato, variabili d’ambiente, istruzioni e parole chiave.</para> 6.46 </listitem> 6.47 </varlistentry> 6.48 6.49 @@ -65,7 +65,7 @@ 6.50 <term><userinput>Spaziatura fissa in grassetto</userinput></term> 6.51 6.52 <listitem> 6.53 - <para id="x_73d">Mostra comandi o altro testo che dovrebbe essere digitato letteralmente dall'utente.</para> 6.54 + <para id="x_73d">Mostra comandi o altro testo che dovrebbe essere digitato letteralmente dall’utente.</para> 6.55 </listitem> 6.56 </varlistentry> 6.57 6.58 @@ -73,7 +73,7 @@ 6.59 <term><replaceable>Spaziatura fissa in corsivo</replaceable></term> 6.60 6.61 <listitem> 6.62 - <para id="x_73e">Mostra testo che dovrebbe essere sostituito da valori forniti dall'utente oppure determinati dal contesto.</para> 6.63 + <para id="x_73e">Mostra testo che dovrebbe essere sostituito da valori forniti dall’utente oppure determinati dal contesto.</para> 6.64 </listitem> 6.65 </varlistentry> 6.66 </variablelist> 6.67 @@ -90,28 +90,28 @@ 6.68 <sect1> 6.69 <title>Usare gli esempi di codice</title> 6.70 6.71 - <para id="x_741">Questo libro ha il compito di aiutarvi a svolgere il vostro lavoro. In generale, potete usare il codice che trovate in questo libro nei vostri programmi e nella vostra documentazione. Non è necessario che ci contattiate per chiedere il permesso, a meno che non stiate riproducendo una porzione significativa del codice. Per esempio, non avete bisogno di un permesso per scrivere un programma che usa diversi frammenti di codice estratti da questo libro, ma dovete richiedere un permesso se desiderate vendere o distribuire un CD-ROM di esempi tratti dai libri pubblicati da O'Reilly. Non ci vuole alcun permesso per rispondere a una domanda citando questo libro e riproducendo codice di esempio, ma dovete richiedere un permesso per incorporare nella documentazione di un vostro prodotto una quantità significativa di codice proveniente da questo libro.</para> 6.72 + <para id="x_741">Questo libro ha il compito di aiutarvi a svolgere il vostro lavoro. In generale, potete usare il codice che trovate in questo libro nei vostri programmi e nella vostra documentazione. Non è necessario che ci contattiate per chiedere il permesso, a meno che non stiate riproducendo una porzione significativa del codice. Per esempio, non avete bisogno di un permesso per scrivere un programma che usa diversi frammenti di codice estratti da questo libro, ma dovete richiedere un permesso se desiderate vendere o distribuire un CD-ROM di esempi tratti dai libri pubblicati da O’Reilly. Non ci vuole alcun permesso per rispondere a una domanda citando questo libro e riproducendo codice di esempio, ma dovete richiedere un permesso per incorporare nella documentazione di un vostro prodotto una quantità significativa di codice proveniente da questo libro.</para> 6.73 6.74 - <para id="x_742">Apprezziamo, ma non richiediamo, l'attribuzione del materiale utilizzato. Un'attribuzione di solito include il titolo, l'autore, l'editore e il codice ISBN. Per esempio: “<emphasis>Titolo del libro</emphasis> di Qualche Autore. Copyright 2008 O’Reilly Media, Inc., 978-0-596-xxxx-x.”</para> 6.75 + <para id="x_742">Apprezziamo, ma non richiediamo, l’attribuzione del materiale utilizzato. Un’attribuzione di solito include il titolo, l’autore, l’editore e il codice ISBN. Per esempio: “<emphasis>Titolo del libro</emphasis> di Qualche Autore. Copyright 2008 O’Reilly Media, Inc., 978-0-596-xxxx-x.”</para> 6.76 6.77 - <para id="x_743">Se credete che il vostro utilizzo del codice di esempio ricada fuori dai confini della correttezza o dei permessi illustrati sopra, sentitevi liberi di contattarci all'indirizzo email <email>permissions@oreilly.com</email>.</para> 6.78 + <para id="x_743">Se credete che il vostro utilizzo del codice di esempio ricada fuori dai confini della correttezza o dei permessi illustrati sopra, sentitevi liberi di contattarci all’indirizzo email <email>permissions@oreilly.com</email>.</para> 6.79 </sect1> 6.80 6.81 <sect1> 6.82 <title>Safari® Books Online</title> 6.83 6.84 <note role="safarienabled"> 6.85 - <para id="x_744">Quando vedete un'icona Safari® Books Online sulla copertina del vostro libro tecnico preferito, questo significa che quel libro è disponibile attraverso la libreria Safari di O'Reilly Network.</para> 6.86 + <para id="x_744">Quando vedete un’icona Safari® Books Online sulla copertina del vostro libro tecnico preferito, questo significa che quel libro è disponibile attraverso la libreria Safari di O’Reilly Network.</para> 6.87 </note> 6.88 6.89 - <para id="x_745">Safari offre una soluzione più vantaggiosa rispetto agli e-book. È una libreria virtuale che vi permette di effettuare facilmente ricerche su migliaia di libri tecnici, copiare e incollare gli esempi di codice, scaricare capitoli e trovare risposte veloci quando avete bisogno delle informazioni più accurate e recenti. Provatelo gratis all'indirizzo <ulink role="orm:hideurl:ital" 6.90 + <para id="x_745">Safari offre una soluzione più vantaggiosa rispetto agli e-book. È una libreria virtuale che vi permette di effettuare facilmente ricerche su migliaia di libri tecnici, copiare e incollare gli esempi di codice, scaricare capitoli e trovare risposte veloci quando avete bisogno delle informazioni più accurate e recenti. Provatelo gratis all’indirizzo <ulink role="orm:hideurl:ital" 6.91 url="http://my.safaribooksonline.com/?portal=oreilly">http://my.safaribooksonline.com</ulink>.</para> 6.92 </sect1> 6.93 6.94 <sect1> 6.95 <title>Come contattarci</title> 6.96 6.97 - <para id="x_746">Per favore spedite commenti e domande riguardanti questo libro all'editore:</para> 6.98 + <para id="x_746">Per favore spedite commenti e domande riguardanti questo libro all’editore:</para> 6.99 6.100 <simplelist type="vert"> 6.101 <member>O’Reilly Media, Inc.</member> 6.102 @@ -127,19 +127,19 @@ 6.103 <member>707 829-0104 (fax)</member> 6.104 </simplelist> 6.105 6.106 - <para id="x_747">Abbiamo predisposto una pagina web dedicata a questo libro, dove elenchiamo errata, esempi e qualsivoglia informazione aggiuntiva. Potete accedere a questa pagina (relativa alla versione inglese del libro) all'indirizzo:</para> 6.107 + <para id="x_747">Abbiamo predisposto una pagina web dedicata a questo libro, dove elenchiamo errata, esempi e qualsivoglia informazione aggiuntiva. Potete accedere a questa pagina (relativa alla versione inglese del libro) all’indirizzo:</para> 6.108 6.109 <simplelist type="vert"> 6.110 <member><ulink url="http://www.oreilly.com/catalog/9780596800673"></ulink></member> 6.111 </simplelist> 6.112 6.113 - <para id="x_748">Per inviare un commento o porre domande tecniche su questo libro, spedite un'email a:</para> 6.114 + <para id="x_748">Per inviare un commento o porre domande tecniche su questo libro, spedite un’email a:</para> 6.115 6.116 <simplelist type="vert"> 6.117 <member><email>bookquestions@oreilly.com</email></member> 6.118 </simplelist> 6.119 6.120 - <para id="x_749">Per maggiori informazioni sui nostri libri, sulle conferenze, sui Centri di Risorse, e su O'Reilly Network, visitate il nostro sito web all'indirizzo:</para> 6.121 + <para id="x_749">Per maggiori informazioni sui nostri libri, sulle conferenze, sui Centri di Risorse, e su O’Reilly Network, visitate il nostro sito web all’indirizzo:</para> 6.122 6.123 <simplelist type="vert"> 6.124 <member><ulink url="http://www.oreilly.com"></ulink></member>
7.1 --- a/it/ch01-intro.xml Sat Aug 22 21:01:56 2009 +0200 7.2 +++ b/it/ch01-intro.xml Sat Aug 22 21:55:05 2009 +0200 7.3 @@ -7,9 +7,9 @@ 7.4 7.5 <para id="x_6d">Il controllo di revisione è il processo tramite il quale si gestiscono molteplici versioni di una qualsiasi unità di informazione. Molte persone eseguono a mano questo processo nella sua forma più semplice, ogni volta che modificano un file e lo salvano con un nuovo nome che contiene un numero più alto del numero della versione precedente.</para> 7.6 7.7 - <para id="x_6e">Tuttavia, gestire più versioni anche solo di un singolo file è un'operazione soggetta a errori, quindi gli strumenti software per automatizzare questo processo sono stati disponibili per molto tempo. I primi strumenti automatizzati per il controllo di revisione erano deputati ad assistere un singolo utente nella gestione delle revisioni di un singolo file. Nel corso delle ultime decadi, il campo d'azione degli strumenti di controllo di revisione si è ampiamente esteso, e ora sono in grado di gestire un grande numero di file e di aiutare più persone a lavorare insieme. I migliori strumenti moderni di controllo di revisione non hanno alcun problema a fronteggiare gruppi di migliaia di persone che lavorano insieme su progetti composti da centinaia di migliaia di file.</para> 7.8 - 7.9 - <para id="x_6f">La comparsa del controllo di revisione distribuito è relativamente recente, e finora questo nuovo campo si è sviluppato grazie alla propensione umana per l'esplorazione di territori sconosciuti.</para> 7.10 + <para id="x_6e">Tuttavia, gestire più versioni anche solo di un singolo file è un’operazione soggetta a errori, quindi gli strumenti software per automatizzare questo processo sono stati disponibili per molto tempo. I primi strumenti automatizzati per il controllo di revisione erano deputati ad assistere un singolo utente nella gestione delle revisioni di un singolo file. Nel corso delle ultime decadi, il campo d’azione degli strumenti di controllo di revisione si è ampiamente esteso, e ora sono in grado di gestire un grande numero di file e di aiutare più persone a lavorare insieme. I migliori strumenti moderni di controllo di revisione non hanno alcun problema a fronteggiare gruppi di migliaia di persone che lavorano insieme su progetti composti da centinaia di migliaia di file.</para> 7.11 + 7.12 + <para id="x_6f">La comparsa del controllo di revisione distribuito è relativamente recente, e finora questo nuovo campo si è sviluppato grazie alla propensione umana per l’esplorazione di territori sconosciuti.</para> 7.13 7.14 <para id="x_70">Sto scrivendo un libro sul controllo di revisione distribuito perché credo che sia una materia importante che merita una guida sul campo. Ho scelto di trattare Mercurial perché è lo strumento più facile con cui saggiare il terreno, e tuttavia è in grado di scalare fino a soddisfare le richieste di ambienti reali e impegnativi dove molti altri strumenti di controllo di revisione si sono dovuti arrendere.</para> 7.15 7.16 @@ -19,10 +19,10 @@ 7.17 <para id="x_71">Esiste un certo numero di ragioni per le quali voi o il vostro gruppo potreste voler usare uno strumento automatico per il controllo di revisione su un progetto.</para> 7.18 7.19 <itemizedlist> 7.20 - <listitem><para id="x_72">Lo strumento terrà traccia della storia e dell'evoluzione del vostro progetto, così voi non dovete farlo. Per ogni modifica, registrerà informazioni riguardanti <emphasis>chi</emphasis> l'ha fatta, <emphasis>perché</emphasis> l'ha fatta, <emphasis>quando</emphasis> è stata fatta e <emphasis>cosa</emphasis> è stato modificato.</para></listitem> 7.21 + <listitem><para id="x_72">Lo strumento terrà traccia della storia e dell’evoluzione del vostro progetto, così voi non dovete farlo. Per ogni modifica, registrerà informazioni riguardanti <emphasis>chi</emphasis> l’ha fatta, <emphasis>perché</emphasis> l’ha fatta, <emphasis>quando</emphasis> è stata fatta e <emphasis>cosa</emphasis> è stato modificato.</para></listitem> 7.22 <listitem><para id="x_73">Quando state lavorando con altre persone, il software di controllo di revisione facilita la collaborazione. Per esempio, quando due persone effettuano cambiamenti incompatibili più o meno simultaneamente, il software vi aiuterà a identificare e risolvere questi conflitti.</para></listitem> 7.23 <listitem><para id="x_74">Lo strumento può aiutarvi a rettificare i vostri errori. Se fate una modifica che più tardi si rivela essere un errore, potete ritornare a una versione precedente di uno o più file. In effetti, uno strumento di controllo di revisione <emphasis>davvero</emphasis> buono vi aiuterà a calcolare efficientemente il momento esatto in cui un problema è stato introdotto (si veda la <xref linkend="sec:undo:bisect"/> per i dettagli).</para></listitem> 7.24 - <listitem><para id="x_75">Il software vi aiuterà a lavorare simultaneamente su molteplici versioni del vostro progetto e a gestire gli spostamenti tra una versione e l'altra.</para></listitem> 7.25 + <listitem><para id="x_75">Il software vi aiuterà a lavorare simultaneamente su molteplici versioni del vostro progetto e a gestire gli spostamenti tra una versione e l’altra.</para></listitem> 7.26 </itemizedlist> 7.27 7.28 <para id="x_76">La maggior parte di queste ragioni sono altrettanto valide&emdash;almeno in teoria&emdash;sia che lavoriate su un progetto da soli sia che collaboriate insieme a un centianio di altre persone.</para> 7.29 @@ -31,7 +31,7 @@ 7.30 7.31 <para id="x_78">È probabile che un progetto di cinquecento persone collassi quasi immediatamente sotto il proprio peso senza un processo e uno strumento di controllo di revisione. In questo caso, il costo di usare il controllo di revisione potrebbe sembrare difficilmente meritevole di considerazione, dato che <emphasis>senza</emphasis> di esso il fallimento del progetto è quasi garantito.</para> 7.32 7.33 - <para id="x_79">D'altra parte, il <quote>lavoretto veloce</quote> di una singola persona potrebbe sembrare il contesto meno adatto per impiegare uno strumento di controllo di revisione, perché sicuramente il costo di usarne uno deve essere vicino al costo complessivo del progetto. Giusto?</para> 7.34 + <para id="x_79">D’altra parte, il <quote>lavoretto veloce</quote> di una singola persona potrebbe sembrare il contesto meno adatto per impiegare uno strumento di controllo di revisione, perché sicuramente il costo di usarne uno deve essere vicino al costo complessivo del progetto. Giusto?</para> 7.35 7.36 <para id="x_7a">Mercurial supporta in maniera unica <emphasis>entrambe</emphasis> queste dimensioni di sviluppo. Potete impararne le basi in pochi minuti appena, e grazie al suo basso costo di gestione potete applicare il controllo di revisione al più piccolo dei progetti con facilità. La sua semplicità vi permetterà di concentrarvi su qualunque cosa stiate <emphasis>davvero</emphasis> cercando di fare senza distrarvi con schiere di concetti astrusi o lunghe sequenze di comandi. Allo stesso tempo, le elevate prestazioni e la natura peer-to-peer di Mercurial vi permetteranno di scalare in maniera indolore per gestire grandi progetti.</para> 7.37 7.38 @@ -50,7 +50,7 @@ 7.39 <listitem><para id="x_80">controllo del codice sorgente, o controllo dei sorgenti;</para></listitem> 7.40 <listitem><para id="x_81">controllo di versione (VCS).</para></listitem> 7.41 </itemizedlist> 7.42 - <para id="x_82">Alcune persone affermano che questi termini in realtà abbiano significati differenti, ma in pratica essi si sovrappongono così tanto che non c'è alcun modo concordato o persino utile di distinguerli.</para> 7.43 + <para id="x_82">Alcune persone affermano che questi termini in realtà abbiano significati differenti, ma in pratica essi si sovrappongono così tanto che non c’è alcun modo concordato o persino utile di distinguerli.</para> 7.44 7.45 </sect2> 7.46 </sect1> 7.47 @@ -58,13 +58,13 @@ 7.48 <sect1> 7.49 <title>A proposito degli esempi in questo libro</title> 7.50 7.51 - <para id="x_84">Questo libro tratta gli esempi di codice in maniera inusuale. Tutti gli esempi sono <quote>vivi</quote>&emdash;ognuno di essi è in effetti il risultato di uno script di shell che esegue i comandi Mercurial che vedete. Ogni volta che un'immagine del libro viene assemblata dai suoi sorgenti, tutti gli script di esempio vengono automaticamente eseguiti e i loro risultati correnti vengono confrontati con i loro risultati attesi.</para> 7.52 + <para id="x_84">Questo libro tratta gli esempi di codice in maniera inusuale. Tutti gli esempi sono <quote>vivi</quote>&emdash;ognuno di essi è in effetti il risultato di uno script di shell che esegue i comandi Mercurial che vedete. Ogni volta che un’immagine del libro viene assemblata dai suoi sorgenti, tutti gli script di esempio vengono automaticamente eseguiti e i loro risultati correnti vengono confrontati con i loro risultati attesi.</para> 7.53 7.54 <para id="x_85">Il vantaggio di questo approccio è che gli esempi sono sempre accurati, in quanto descrivono <emphasis>esattamente</emphasis> il comportamento della versione di Mercurial menzionata sulla copertina del libro. Se aggiorno la versione di Mercurial che sto documentando e il risultato di qualche comando cambia, il processo di assemblaggio del libro fallisce.</para> 7.55 7.56 - <para id="x_86">C'è un piccolo svantaggio in questo approccio: le date e gli orari che vedete negli esempi tendono a venire <quote>compressi</quote> insieme in modo anomalo, diversamente da quanto accadrebbe se gli stessi comandi fossero digitati da un essere umano. Laddove un essere umano non può inviare più di un comando ogni pochi secondi, le cui marcature temporali sarebbero analogamente intervallate, i miei script d'esempio automatizzati sono in grado di eseguire molti comandi in un secondo.</para> 7.57 - 7.58 - <para id="x_87">Come conseguenza di questo fatto, potrebbe sembrare che molti inserimenti (in inglese, commit) consecutivi vengano eseguiti durante lo stesso secondo. Potete osservare la presenza di questa anomalia nell'esempio di <literal role="hg-ext">bisect</literal> nella <xref linkend="sec:undo:bisect"/>, tanto per farvi un'idea.</para> 7.59 + <para id="x_86">C’è un piccolo svantaggio in questo approccio: le date e gli orari che vedete negli esempi tendono a venire <quote>compressi</quote> insieme in modo anomalo, diversamente da quanto accadrebbe se gli stessi comandi fossero digitati da un essere umano. Laddove un essere umano non può inviare più di un comando ogni pochi secondi, le cui marcature temporali sarebbero analogamente intervallate, i miei script d’esempio automatizzati sono in grado di eseguire molti comandi in un secondo.</para> 7.60 + 7.61 + <para id="x_87">Come conseguenza di questo fatto, potrebbe sembrare che molti inserimenti (in inglese, commit) consecutivi vengano eseguiti durante lo stesso secondo. Potete osservare la presenza di questa anomalia nell’esempio di <literal role="hg-ext">bisect</literal> nella <xref linkend="sec:undo:bisect"/>, tanto per farvi un’idea.</para> 7.62 7.63 <para id="x_88">Quindi, mentre leggete gli esempi, non date troppo peso alle date e agli orari che vedete nei risultati dei comandi, ma fate <emphasis>decisamente</emphasis> affidamento sulla consistenza e riproducibilità del comportamento illustrato.</para> 7.64 7.65 @@ -73,11 +73,11 @@ 7.66 <sect1> 7.67 <title>Le tendenze nel campo</title> 7.68 7.69 - <para id="x_89">Ci sono state alcune inconfondibili tendenze nello sviluppo e nell'utilizzo degli strumenti di controllo di revisione nel corso delle ultime quattro decadi, man mano che le persone acquisivano familiarità con le capacità dei loro strumenti e venivano vincolate dai loro limiti.</para> 7.70 + <para id="x_89">Ci sono state alcune inconfondibili tendenze nello sviluppo e nell’utilizzo degli strumenti di controllo di revisione nel corso delle ultime quattro decadi, man mano che le persone acquisivano familiarità con le capacità dei loro strumenti e venivano vincolate dai loro limiti.</para> 7.71 7.72 <para id="x_8a">La prima generazione ha cominciato col gestire singoli file su singoli computer. Sebbene questi strumenti rappresentassero un enorme progresso rispetto al controllo di revisione manuale effettuato ad hoc, il loro modello di bloccaggio (in inglese, locking) e la restrizione a un singolo computer limitarono il loro impiego a piccoli gruppi strettamente uniti.</para> 7.73 7.74 - <para id="x_8b">La seconda generazione ha rilassato questi vincoli spostandosi su architetture di rete e gestendo interi progetti alla volta. Con l'aumentare delle dimensioni dei progetti, gli strumenti incontrarono nuovi problemi. A causa della frequenza elevata con cui i client avevano bisogno di parlare con i server, la scalabilità dei server divenne un problema per progetti di grandi dimensioni. Una connessione di rete inaffidabile poteva completamente impedire agli utenti remoti di parlare con il server. Man mano che i progetti open source cominciarono a rendere l'accesso in sola lettura disponibile a chiunque in forma anonima, persone senza privilegi di inserimento scoprivano di non poter usare gli strumenti per interagire con un progetto in modo naturale, in quanto non erano in grado di registrare le modifiche da loro effettuate.</para> 7.75 + <para id="x_8b">La seconda generazione ha rilassato questi vincoli spostandosi su architetture di rete e gestendo interi progetti alla volta. Con l’aumentare delle dimensioni dei progetti, gli strumenti incontrarono nuovi problemi. A causa della frequenza elevata con cui i client avevano bisogno di parlare con i server, la scalabilità dei server divenne un problema per progetti di grandi dimensioni. Una connessione di rete inaffidabile poteva completamente impedire agli utenti remoti di parlare con il server. Man mano che i progetti open source cominciarono a rendere l’accesso in sola lettura disponibile a chiunque in forma anonima, persone senza privilegi di inserimento scoprivano di non poter usare gli strumenti per interagire con un progetto in modo naturale, in quanto non erano in grado di registrare le modifiche da loro effettuate.</para> 7.76 7.77 <para id="x_8c">La generazione attuale degli strumenti di controllo di revisione è di natura peer-to-peer. Tutti questi sistemi hanno abbandonato la dipendenza da un singolo server centrale e permettono alle persone di distribuire i propri dati di controllo di revisione laddove sono effettivamente necessari. La collaborazione attraverso Internet non è più vincolata dalla tecnologia, ma è diventata una questione di scelta e consenso. Gli strumenti moderni possono operare offline indefinitamente e autonomamente, utilizzando una connessione di rete solo quando è necessario sincronizzare i cambiamenti con un altro repository.</para> 7.78 7.79 @@ -87,11 +87,11 @@ 7.80 7.81 <para id="x_8d">Sebbene per diversi anni gli stumenti per il controllo di revisione distribuito si siano mantenuti robusti e usabili tanto quanto le loro controparti delle generazioni precedenti, questo non vuol dire che le persone che utilizzavano strumenti più vecchi si siano necessariamente accorte dei loro vantaggi. Ci sono diversi modi in cui gli strumenti distribuiti brillano rispetto a quelli centralizzati.</para> 7.82 7.83 - <para id="x_8e">Per un singolo sviluppatore, gli strumenti distribuiti sono quasi sempre più veloci di quelli centralizzati. Questo avviene per una semplice ragione: uno strumento centralizzato ha bisogno di utilizzare la rete per molte operazioni comuni, perché la maggior parte dei metadati sono memorizzati in una singola copia sul server centrale. Uno strumento distribuito memorizza tutti i suoi metadati localmente. A parità di altre condizioni, utilizzare la rete aggiunge un costo supplementare a uno strumento centralizzato. Non sottovalutate l'importanza di uno strumento veloce e reattivo: vi troverete a passare molto tempo interagendo con il vostro software di controllo di revisione.</para> 7.84 - 7.85 - <para id="x_8f">Gli strumenti distribuiti sono indifferenti alle stravaganze dell'infrastruttura dei vostri server, sempre perché replicano i metadati in così tanti luoghi. Se usate un sistema centralizzato e il vostro server si guasta, fareste meglio a sperare che il vostro sistema di backup sia affidabile e che il vostro ultimo backup sia recente ed effettivamente funzionante. Con uno strumento distribuito, avete molti backup disponibili sui computer di ogni singolo collaboratore.</para> 7.86 - 7.87 - <para id="x_90">L'affidabilità della vostra rete influenzerà gli strumenti distribuiti in misura molto minore rispetto a quelli centralizzati. Non potete nemmeno usare uno strumento centralizzato senza una connessione di rete, a parte alcuni comandi estremamente limitati. Con uno strumento distribuito, potreste persino non notare se la vostra connessione di rete cade mentre state lavorando. L'unica cosa che non sarete in grado di fare è comunicare con i repository su altri computer, qualcosa che è relativamente raro rispetto alle operazioni locali. Questo potrebbe essere significativo solo se avete un gruppo di collaboratori sparpagliati in giro per il mondo.</para> 7.88 + <para id="x_8e">Per un singolo sviluppatore, gli strumenti distribuiti sono quasi sempre più veloci di quelli centralizzati. Questo avviene per una semplice ragione: uno strumento centralizzato ha bisogno di utilizzare la rete per molte operazioni comuni, perché la maggior parte dei metadati sono memorizzati in una singola copia sul server centrale. Uno strumento distribuito memorizza tutti i suoi metadati localmente. A parità di altre condizioni, utilizzare la rete aggiunge un costo supplementare a uno strumento centralizzato. Non sottovalutate l’importanza di uno strumento veloce e reattivo: vi troverete a passare molto tempo interagendo con il vostro software di controllo di revisione.</para> 7.89 + 7.90 + <para id="x_8f">Gli strumenti distribuiti sono indifferenti alle stravaganze dell’infrastruttura dei vostri server, sempre perché replicano i metadati in così tanti luoghi. Se usate un sistema centralizzato e il vostro server si guasta, fareste meglio a sperare che il vostro sistema di backup sia affidabile e che il vostro ultimo backup sia recente ed effettivamente funzionante. Con uno strumento distribuito, avete molti backup disponibili sui computer di ogni singolo collaboratore.</para> 7.91 + 7.92 + <para id="x_90">L’affidabilità della vostra rete influenzerà gli strumenti distribuiti in misura molto minore rispetto a quelli centralizzati. Non potete nemmeno usare uno strumento centralizzato senza una connessione di rete, a parte alcuni comandi estremamente limitati. Con uno strumento distribuito, potreste persino non notare se la vostra connessione di rete cade mentre state lavorando. L’unica cosa che non sarete in grado di fare è comunicare con i repository su altri computer, qualcosa che è relativamente raro rispetto alle operazioni locali. Questo potrebbe essere significativo solo se avete un gruppo di collaboratori sparpagliati in giro per il mondo.</para> 7.93 7.94 <sect2> 7.95 <title>Vantaggi per i progetti open source</title> 7.96 @@ -103,28 +103,28 @@ 7.97 7.98 <para id="x_92">È stato suggerito che gli strumenti per il controllo di revisione distribuito espongano i progetti open source a un certo tipo di rischio in quanto rendono estremamente facile <quote>biforcare</quote> (in inglese, fork) lo sviluppo di un progetto. Un fork avviene quando le differenze di opinione o di atteggiamento tra sviluppatori di uno stesso gruppo li portano a decidere di non poter lavorare più a lungo insieme. Ogni parte prende una copia più o meno completa del codice sorgente del progetto e prosegue per la propria strada.</para> 7.99 7.100 - <para id="x_93">Talvolta le parti di un fork decidono di riconciliare le loro differenze. Con uno strumento centralizzato di controllo di revisione, il processo <emphasis>tecnico</emphasis> di riconciliazione è doloroso e deve essere in gran parte effettuato a mano. Dovete decidere quale cronologia delle revisioni dovrà <quote>prevalere</quote> e introdurvi in qualche modo i cambiamenti dell'altro gruppo. Di solito, questo risulta nella perdita parziale o completa della cronologia delle revisioni di una delle due parti.</para> 7.101 - 7.102 - <para id="x_94">Gli strumenti distribuiti rendono la biforcazione <emphasis>l'unico</emphasis> modo per sviluppare un progetto. Ogni singolo cambiamento apportato è un potenziale punto di biforcazione. La grande forza di questo approccio è che uno strumento per il controllo di revisione distribuito deve essere davvero bravo a <emphasis>unire</emphasis> (in inglese, merge) due fork, perché i fork sono assolutamente fondamentali: vengono effettuati in ogni momento.</para> 7.103 + <para id="x_93">Talvolta le parti di un fork decidono di riconciliare le loro differenze. Con uno strumento centralizzato di controllo di revisione, il processo <emphasis>tecnico</emphasis> di riconciliazione è doloroso e deve essere in gran parte effettuato a mano. Dovete decidere quale cronologia delle revisioni dovrà <quote>prevalere</quote> e introdurvi in qualche modo i cambiamenti dell’altro gruppo. Di solito, questo risulta nella perdita parziale o completa della cronologia delle revisioni di una delle due parti.</para> 7.104 + 7.105 + <para id="x_94">Gli strumenti distribuiti rendono la biforcazione <emphasis>l’unico</emphasis> modo per sviluppare un progetto. Ogni singolo cambiamento apportato è un potenziale punto di biforcazione. La grande forza di questo approccio è che uno strumento per il controllo di revisione distribuito deve essere davvero bravo a <emphasis>unire</emphasis> (in inglese, merge) due fork, perché i fork sono assolutamente fondamentali: vengono effettuati in ogni momento.</para> 7.106 7.107 <para id="x_95">Se tutte le attività che ogni sviluppatore svolge in ogni momento vengono concepite in termini di biforcazioni e unioni, allora ciò che il mondo open source chiama <quote>fork</quote> diventa un problema <emphasis>puramente</emphasis> sociale. Gli strumenti distribuiti in realtà non fanno altro che <emphasis>ridurre</emphasis> la probabilità di un vero e proprio fork:</para> 7.108 <itemizedlist> 7.109 - <listitem><para id="x_96">eliminano la distinzione sociale imposta dagli strumenti centralizzati, cioè quella tra le persone all'interno del gruppo con i permessi di inserimento e le persone che si trovano all'esterno del gruppo e non hanno questi permessi;</para></listitem> 7.110 - <listitem><para id="x_97">rendono più facile riconciliarsi dopo un fork sociale, perché l'unica operazione che viene coinvolta dal punto di vista del software di controllo di revisione è semplicemente un'altra unione.</para></listitem> 7.111 + <listitem><para id="x_96">eliminano la distinzione sociale imposta dagli strumenti centralizzati, cioè quella tra le persone all’interno del gruppo con i permessi di inserimento e le persone che si trovano all’esterno del gruppo e non hanno questi permessi;</para></listitem> 7.112 + <listitem><para id="x_97">rendono più facile riconciliarsi dopo un fork sociale, perché l’unica operazione che viene coinvolta dal punto di vista del software di controllo di revisione è semplicemente un’altra unione.</para></listitem> 7.113 </itemizedlist> 7.114 7.115 - <para id="x_98">Alcune persone oppongono resistenza agli strumenti distribuiti perché vogliono mantenere uno stretto controllo sui propri progetti e credono che gli strumenti centralizzati diano loro questo controllo. Tuttavia, se siete tra quelli che hanno questa convinzione, e il vostro repository CVS o Subversion è disponibile pubblicamente, sappiate che esistono numerosi strumenti in grado di estrarre l'intera cronologia del vostro progetto (anche se lentamente) e ricrearla da qualche altra parte al di là del vostro controllo. Quindi non solo il vostro controllo in questo caso è illusorio, ma state anche rinunciando alla possibilità di collaborare facilmente con chiunque si senta in dovere di duplicare la cronologia del vostro progetto.</para> 7.116 + <para id="x_98">Alcune persone oppongono resistenza agli strumenti distribuiti perché vogliono mantenere uno stretto controllo sui propri progetti e credono che gli strumenti centralizzati diano loro questo controllo. Tuttavia, se siete tra quelli che hanno questa convinzione, e il vostro repository CVS o Subversion è disponibile pubblicamente, sappiate che esistono numerosi strumenti in grado di estrarre l’intera cronologia del vostro progetto (anche se lentamente) e ricrearla da qualche altra parte al di là del vostro controllo. Quindi non solo il vostro controllo in questo caso è illusorio, ma state anche rinunciando alla possibilità di collaborare facilmente con chiunque si senta in dovere di duplicare la cronologia del vostro progetto.</para> 7.117 7.118 </sect3> 7.119 </sect2> 7.120 <sect2> 7.121 <title>Vantaggi per i progetti commerciali</title> 7.122 7.123 - <para id="x_99">Molti progetti commerciali vengono intrapresi da gruppi i cui membri sono sparpagliati attraverso il globo. I collaboratori lontani da un server centrale soffriranno un maggiore lentezza nell'esecuzione dei comandi e forse una minore affidabilità. I sistemi commerciali di controllo di revisione tentano di mitigare questi problemi tramite componenti aggiuntivi per la replicazione di siti remoti che sono tipicamente costosi da acquistare e complicati da amministrare. Un sistema distribuito non soffre di questi problemi in prima istanza. Ancora meglio, potete facilmente configurare molteplici server autoritativi, diciamo uno per ogni sito, in modo che non ci siano comunicazioni ridondanti tra i repository durante i costosi collegamenti di rete a grande distanza.</para> 7.124 + <para id="x_99">Molti progetti commerciali vengono intrapresi da gruppi i cui membri sono sparpagliati attraverso il globo. I collaboratori lontani da un server centrale soffriranno un maggiore lentezza nell’esecuzione dei comandi e forse una minore affidabilità. I sistemi commerciali di controllo di revisione tentano di mitigare questi problemi tramite componenti aggiuntivi per la replicazione di siti remoti che sono tipicamente costosi da acquistare e complicati da amministrare. Un sistema distribuito non soffre di questi problemi in prima istanza. Ancora meglio, potete facilmente configurare molteplici server autoritativi, diciamo uno per ogni sito, in modo che non ci siano comunicazioni ridondanti tra i repository durante i costosi collegamenti di rete a grande distanza.</para> 7.125 7.126 <para id="x_9a">I sistemi centralizzati di controllo di revisione tendono ad avere una scalabilità relativamente bassa. Non è inusuale che un costoso sistema centralizzato cada sotto il carico combinato di una sola dozzina di utenti concorrenti. Ancora una volta, la tipica contromisura tende a essere un dispositivo di replicazione costoso e macchinoso. Dato che con uno strumento distribuito il carico su un server centrale&emdash;sempre che ne abbiate uno&emdash;è molto più basso (perché tutti i dati sono replicati ovunque), un singolo server economico può gestire i bisogni di un gruppo di lavoro molto più grande, e la replicazione per il bilancio del carico diventa una semplice questione di programmazione.</para> 7.127 7.128 - <para id="x_9b">I vostri impiegati potranno beneficiare del controllo di versione distribuito anche quando si trovano nella sede di un cliente per risolvere un problema in loco. Gli strumenti permetteranno loro di generare versioni personalizzate del software nel repository, provare soluzioni differenti isolandole l'una dall'altra e cercare in maniera efficiente attraverso la cronologia delle revisioni le sorgenti di bug e regressioni nell'ambiente del cliente, il tutto senza aver bisogno di collegarsi alla rete della vostra azienda.</para> 7.129 + <para id="x_9b">I vostri impiegati potranno beneficiare del controllo di versione distribuito anche quando si trovano nella sede di un cliente per risolvere un problema in loco. Gli strumenti permetteranno loro di generare versioni personalizzate del software nel repository, provare soluzioni differenti isolandole l’una dall’altra e cercare in maniera efficiente attraverso la cronologia delle revisioni le sorgenti di bug e regressioni nell’ambiente del cliente, il tutto senza aver bisogno di collegarsi alla rete della vostra azienda.</para> 7.130 7.131 </sect2> 7.132 </sect1> 7.133 @@ -139,13 +139,13 @@ 7.134 <listitem><para id="x_a0">È facile da personalizzare.</para></listitem> 7.135 </itemizedlist> 7.136 7.137 - <para id="x_a1">Se avete una vaga familiarità con i sistemi di controllo di revisione, dovreste essere in grado di cominciare a usare Mercurial in meno di cinque minuti. Anche se non è così, non vi ci vorrà più di qualche altro minuto. L'insieme di comandi e caratteristiche di Mercurial è generalmente uniforme e consistente, così potete tenere a mente poche regole generali piuttosto che una nutrita schiera di eccezioni.</para> 7.138 + <para id="x_a1">Se avete una vaga familiarità con i sistemi di controllo di revisione, dovreste essere in grado di cominciare a usare Mercurial in meno di cinque minuti. Anche se non è così, non vi ci vorrà più di qualche altro minuto. L’insieme di comandi e caratteristiche di Mercurial è generalmente uniforme e consistente, così potete tenere a mente poche regole generali piuttosto che una nutrita schiera di eccezioni.</para> 7.139 7.140 <para id="x_a2">Potete cominciare a lavorare con Mercurial su un piccolo progetto in pochi minuti, creando nuove modifiche e rami di sviluppo, trasferendo cambiamenti sia localmente che attraverso la rete, sfruttando la velocità di tutte le operazioni di stato e cronologia. Mercurial cerca di essere agile e di non starvi tra i piedi combinando un basso costo cognitivo con operazioni estremamente veloci.</para> 7.141 7.142 - <para id="x_a3">L'utilità di Mercurial non si limita ai piccoli progetti: è usato da progetti contenenti decine di migliaia di file e centinaia di megabyte di codice sorgente su cui collaborano centinaia di migliaia di sviluppatori.</para> 7.143 - 7.144 - <para id="x_a4">Se le funzioni principali di Mercurial non sono sufficienti per voi, è facile aggiungerne di nuove. Mercurial è particolarmente adatto alla programmazione delle proprie operazioni, e il codice pulito della sua implementazione in Python facilita l'aggiunta di funzioni sotto forma di estensioni. Esistono già un certo numero di estensioni utili e popolari, che spaziano dal supporto all'identificazione dei bug fino al miglioramento delle prestazioni.</para> 7.145 + <para id="x_a3">L’utilità di Mercurial non si limita ai piccoli progetti: è usato da progetti contenenti decine di migliaia di file e centinaia di megabyte di codice sorgente su cui collaborano centinaia di migliaia di sviluppatori.</para> 7.146 + 7.147 + <para id="x_a4">Se le funzioni principali di Mercurial non sono sufficienti per voi, è facile aggiungerne di nuove. Mercurial è particolarmente adatto alla programmazione delle proprie operazioni, e il codice pulito della sua implementazione in Python facilita l’aggiunta di funzioni sotto forma di estensioni. Esistono già un certo numero di estensioni utili e popolari, che spaziano dal supporto all’identificazione dei bug fino al miglioramento delle prestazioni.</para> 7.148 7.149 </sect1> 7.150 <sect1> 7.151 @@ -156,36 +156,36 @@ 7.152 <sect2> 7.153 <title>Subversion</title> 7.154 7.155 - <para id="x_a6">Subversion è un sistema di controllo di revisione piuttosto popolare, sviluppato per sostituire CVS. Ha un'architettura client/server centralizzata.</para> 7.156 - 7.157 - <para id="x_a7">Subversion e Mercurial hanno comandi con nomi simili per effettuare le stesse operazioni, così se avete familiarità con uno dei due è facile imparare a usare l'altro. Entrambi gli strumenti sono portabili su tutti i sistemi operativi più popolari.</para> 7.158 + <para id="x_a6">Subversion è un sistema di controllo di revisione piuttosto popolare, sviluppato per sostituire CVS. Ha un’architettura client/server centralizzata.</para> 7.159 + 7.160 + <para id="x_a7">Subversion e Mercurial hanno comandi con nomi simili per effettuare le stesse operazioni, così se avete familiarità con uno dei due è facile imparare a usare l’altro. Entrambi gli strumenti sono portabili su tutti i sistemi operativi più popolari.</para> 7.161 7.162 <para id="x_a8">Prima della versione 1.5, Subversion non aveva alcun supporto efficace per le unioni. Al momento della scrittura, la sua funzione per la gestione delle unioni è nuova e nota per essere <ulink 7.163 url="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword">complicata e difettosa</ulink>.</para> 7.164 7.165 <para id="x_a9">Mercurial ha un sostanzioso vantaggio in termini di prestazioni rispetto a Subversion per tutte le operazioni di controllo di revisione di cui ho effettuato il benchmark. Il suo vantaggio si misura in un intervallo che va da un fattore due a un fattore sei quando lo si confronta con il modulo <emphasis>ra_local</emphasis> di Subversion 1.4.3, che lavora con repository locali ed è quindi il metodo di accesso più veloce disponibile. In situazioni più realistiche che coinvolgono un accesso al repository attraverso la rete, Subversion sconterà uno svantaggio sostanzialmente più consistente. Dato che molti comandi di Subversion devono comunicare con il server e Subversion non è dotato di meccanismi di replicazione efficaci, la capacità del server e la banda di rete diventano colli di bottiglia già per progetti di dimensioni moderate.</para> 7.166 7.167 - <para id="x_aa">In più, Subversion si espone a un sostanziale utilizzo aggiuntivo di spazio su disco per evitare transazioni di rete durante l'esecuzione di alcune operazioni comuni, come trovare i file modificati (<literal>status</literal>) e visualizzare le modifiche rispetto alla revisione corrente (<literal>diff</literal>). Come risultato, la copia di lavoro di un repository Subversion è spesso delle stesse dimensioni, se non più grande, di un intero repository Mercurial più la sua directory di lavoro, anche nel caso in cui il repository Mercurial contenga la cronologia completa del progetto.</para> 7.168 - 7.169 - <para id="x_ab">Subversion è ampiamente supportato da strumenti di terze parti. Mercurial è considerevolmente indietro in quest'area. Il divario si sta assottigliando, tuttavia, e in effetti alcuni degli strumenti di interfaccia grafica di Mercurial attualmente offuscano i loro equivalenti per Subversion. Come Mercurial, Subversion è dotato di un eccellente manuale d'uso.</para> 7.170 - 7.171 - <para id="x_ac">Dato che Subversion non memorizza la cronologia di revisione sul client, è molto adatto a gestire progetti che hanno a che fare con numerosi file binari di grandi dimensioni. Se aggiungete cinquanta revisioni di un file incomprimibile di 10MB a un repository, l'utilizzo di spazio sul lato client da parte di Subversion rimarrà costante. Lo spazio usato da qualunque SCM distribuito crescerà rapidamente in proporzione al numero delle revisioni, perché le differenze tra una revisione e l'altra sono grandi.</para> 7.172 - 7.173 - <para id="x_ad">In più, è spesso difficile, o più tipicamente impossibile, unire differenti versioni di un file binario. L'abilità di Subversion di permettere a un utente di bloccare un file, in modo da ottenere temporaneamente i diritti esclusivi per modificarlo, può essere un vantaggio significativo in progetti dove i file binari vengono largamente utilizzati.</para> 7.174 - 7.175 - <para id="x_ae">Mercurial può importare la cronologia delle revisioni da un repository Subversion. Può anche esportare la propria cronologia delle revisioni verso un repository Subversion. Questa caratteristica vi permette di <quote>sentire l'acqua</quote> utilizzando Mercurial e Subverison in parallelo prima di decidere di cambiare. La conversione della cronologia è incrementale, così potete effettuare una conversione iniziale, poi piccole conversioni aggiuntive per introdurre successivamente nuovi cambiamenti.</para> 7.176 + <para id="x_aa">In più, Subversion si espone a un sostanziale utilizzo aggiuntivo di spazio su disco per evitare transazioni di rete durante l’esecuzione di alcune operazioni comuni, come trovare i file modificati (<literal>status</literal>) e visualizzare le modifiche rispetto alla revisione corrente (<literal>diff</literal>). Come risultato, la copia di lavoro di un repository Subversion è spesso delle stesse dimensioni, se non più grande, di un intero repository Mercurial più la sua directory di lavoro, anche nel caso in cui il repository Mercurial contenga la cronologia completa del progetto.</para> 7.177 + 7.178 + <para id="x_ab">Subversion è ampiamente supportato da strumenti di terze parti. Mercurial è considerevolmente indietro in quest’area. Il divario si sta assottigliando, tuttavia, e in effetti alcuni degli strumenti di interfaccia grafica di Mercurial attualmente offuscano i loro equivalenti per Subversion. Come Mercurial, Subversion è dotato di un eccellente manuale d’uso.</para> 7.179 + 7.180 + <para id="x_ac">Dato che Subversion non memorizza la cronologia di revisione sul client, è molto adatto a gestire progetti che hanno a che fare con numerosi file binari di grandi dimensioni. Se aggiungete cinquanta revisioni di un file incomprimibile di 10MB a un repository, l’utilizzo di spazio sul lato client da parte di Subversion rimarrà costante. Lo spazio usato da qualunque SCM distribuito crescerà rapidamente in proporzione al numero delle revisioni, perché le differenze tra una revisione e l’altra sono grandi.</para> 7.181 + 7.182 + <para id="x_ad">In più, è spesso difficile, o più tipicamente impossibile, unire differenti versioni di un file binario. L’abilità di Subversion di permettere a un utente di bloccare un file, in modo da ottenere temporaneamente i diritti esclusivi per modificarlo, può essere un vantaggio significativo in progetti dove i file binari vengono largamente utilizzati.</para> 7.183 + 7.184 + <para id="x_ae">Mercurial può importare la cronologia delle revisioni da un repository Subversion. Può anche esportare la propria cronologia delle revisioni verso un repository Subversion. Questa caratteristica vi permette di <quote>sentire l’acqua</quote> utilizzando Mercurial e Subverison in parallelo prima di decidere di cambiare. La conversione della cronologia è incrementale, così potete effettuare una conversione iniziale, poi piccole conversioni aggiuntive per introdurre successivamente nuovi cambiamenti.</para> 7.185 7.186 </sect2> 7.187 <sect2> 7.188 <title>Git</title> 7.189 7.190 - <para id="x_af">Git è uno strumento per il controllo di revisione distribuito che è stato sviluppato per gestire l'albero dei sorgenti del kernel di Linux. Come Mercurial, il suo design iniziale è stato in qualche modo influenzato da Monotone.</para> 7.191 + <para id="x_af">Git è uno strumento per il controllo di revisione distribuito che è stato sviluppato per gestire l’albero dei sorgenti del kernel di Linux. Come Mercurial, il suo design iniziale è stato in qualche modo influenzato da Monotone.</para> 7.192 7.193 <para id="x_b0">Git possiede un insieme di comandi piuttosto ampio, con la versione 1.5.0 che fornisce 139 singoli comandi. Si è fatto una certa reputazione di essere difficile da imparare. Rispetto a Git, Mercurial pone una maggiore attenzione alla semplicità.</para> 7.194 7.195 <para id="x_b1">In termini di prestazioni, Git è estremamente veloce. In molti casi, è più veloce di Mercurial, almeno sotto Linux, mentre Mercurial è più prestante per altre operazioni. Tuttavia, sotto Windows, le prestazioni e il livello generale di supporto offerto da Git sono, al momento della scrittura, molto più indietro rispetto a Mercurial.</para> 7.196 7.197 - <para id="x_b2">Mentre un repository Mercurial non ha bisogno di alcuna manutenzione, un repository Git richiede frequenti <quote>reimpacchettamenti</quote> manuali dei propri metadati. Senza questi, le prestazioni degradano e l'utilizzo di spazio cresce rapidamente. Le prestazioni di un server che contiene molti repository Git che non vengono rigorosamente e frequentemente reimpacchettati diventeranno pesantemente legate all'utilizzo del disco durante i backup, risultando in istanze di backup giornalieri che impiegano molto più di 24 ore per terminare. Un repository Git appena impacchettato è leggermente più piccolo di un repository Mercurial, ma un repository non impacchettato ha dimensioni maggiori di diversi ordini di grandezza.</para> 7.198 + <para id="x_b2">Mentre un repository Mercurial non ha bisogno di alcuna manutenzione, un repository Git richiede frequenti <quote>reimpacchettamenti</quote> manuali dei propri metadati. Senza questi, le prestazioni degradano e l’utilizzo di spazio cresce rapidamente. Le prestazioni di un server che contiene molti repository Git che non vengono rigorosamente e frequentemente reimpacchettati diventeranno pesantemente legate all’utilizzo del disco durante i backup, risultando in istanze di backup giornalieri che impiegano molto più di 24 ore per terminare. Un repository Git appena impacchettato è leggermente più piccolo di un repository Mercurial, ma un repository non impacchettato ha dimensioni maggiori di diversi ordini di grandezza.</para> 7.199 7.200 <para id="x_b3">Il cuore di Git è scritto in C. Molti comandi di Git sono implementati come script di shell o in linguaggio Perl la cui qualità è notevolmente variabile. Ho incontrato diversi casi in cui gli script proseguivano ciecamente la propria esecuzione in presenza di errori che avrebbero dovuto essere fatali.</para> 7.201 7.202 @@ -198,11 +198,11 @@ 7.203 7.204 <para id="x_b5">CVS è probabilmente lo strumento di controllo di revisione più usato nel mondo. A causa della sua età e della sporcizia interna, è stato mantenuto solo superficialmente per diversi anni.</para> 7.205 7.206 - <para id="x_b6">Ha un'architettura client/server centralizzata. Non raggruppa cambiamenti di file correlati in inserimenti atomici, esponendo gli utenti al rischio di <quote>guastare il software</quote>: una persona può inserire con successo parte di un cambiamento e poi essere bloccata dalla necessità di un'unione, vincolando altre persone a vedere solo una porzione del lavoro che intendeva fare. Questo influisce anche sul modo di lavorare con la cronologia del progetto. Se volete vedere tutte le modifiche che qualcuno ha effettuato come parte di un'attività, dovrete ispezionare manualmente le descrizioni e le marcature temporali dei cambiamenti fatti a ogni file coinvolto (sempre che sappiate quali fossero quei file).</para> 7.207 + <para id="x_b6">Ha un’architettura client/server centralizzata. Non raggruppa cambiamenti di file correlati in inserimenti atomici, esponendo gli utenti al rischio di <quote>guastare il software</quote>: una persona può inserire con successo parte di un cambiamento e poi essere bloccata dalla necessità di un’unione, vincolando altre persone a vedere solo una porzione del lavoro che intendeva fare. Questo influisce anche sul modo di lavorare con la cronologia del progetto. Se volete vedere tutte le modifiche che qualcuno ha effettuato come parte di un’attività, dovrete ispezionare manualmente le descrizioni e le marcature temporali dei cambiamenti fatti a ogni file coinvolto (sempre che sappiate quali fossero quei file).</para> 7.208 7.209 <para id="x_b7">CVS ha una nozione confusa di etichette e rami di lavoro che non cercherò nemmeno di descrivere. Non gestisce per bene il cambiamento dei nomi di file o directory, esponendo il repository al rischio di danneggiamenti. Non ha quasi alcuna funzionalità per il controllo della consistenza interna, quindi tipicamente non è nemmeno possibile dire se un repository è danneggiato. Non raccomanderei CVS per nessun progetto, nuovo o esistente.</para> 7.210 7.211 - <para id="x_b8">Mercurial può importare la cronologia di revisione da un repository CVS. Tuttavia, ci sono alcune avvertenze da considerare, valide anche per qualsiasi altro strumento di controllo di revisione che importi dati da CVS. A causa della mancanza di inserimenti atomici in CVS e della mancanza di versioni per la gerarchia dei file, non è possibile ricostruire la cronologia di CVS in maniera completa e accurata, bensì devono essere fatte alcune supposizioni, e le modifiche ai nomi dei file di solito non verranno mostrate. Dato che buona parte dell'amministrazione avanzata di CVS deve essere fatta a mano e quindi è soggetta a errori, i programmi che importano dati da CVS incorrono comunemente in molteplici problemi dovuti a repository danneggiati (marcature temporali completamente fasulle per le revisioni e file che sono rimasti bloccati per più di un decennio sono solo due dei problemi meno interessanti che posso ricordare dalla mia esperienza personale).</para> 7.212 + <para id="x_b8">Mercurial può importare la cronologia di revisione da un repository CVS. Tuttavia, ci sono alcune avvertenze da considerare, valide anche per qualsiasi altro strumento di controllo di revisione che importi dati da CVS. A causa della mancanza di inserimenti atomici in CVS e della mancanza di versioni per la gerarchia dei file, non è possibile ricostruire la cronologia di CVS in maniera completa e accurata, bensì devono essere fatte alcune supposizioni, e le modifiche ai nomi dei file di solito non verranno mostrate. Dato che buona parte dell’amministrazione avanzata di CVS deve essere fatta a mano e quindi è soggetta a errori, i programmi che importano dati da CVS incorrono comunemente in molteplici problemi dovuti a repository danneggiati (marcature temporali completamente fasulle per le revisioni e file che sono rimasti bloccati per più di un decennio sono solo due dei problemi meno interessanti che posso ricordare dalla mia esperienza personale).</para> 7.213 <!-- 7.214 <para id="x_b9">Mercurial può importare la cronologia di revisione da un repository CVS.</para> 7.215 --> 7.216 @@ -210,15 +210,15 @@ 7.217 <sect2> 7.218 <title>Strumenti commerciali</title> 7.219 7.220 - <para id="x_ba">Perforce ha un'architettura client/server centralizzata in cui nessun dato viene memorizzato sul lato client. A differenza degli strumenti di controllo di revisione moderni, Perforce richiede che l'utente esegua un comando per comunicare al server di voler modificare un qualsiasi file.</para> 7.221 - 7.222 - <para id="x_bb">Le prestazioni di Perforce sono piuttosto buone per piccoli gruppi di lavoro, ma decadono rapidamente man mano che il numero di utenti cresce oltre le poche dozzine. Installazioni di Perforce di modeste dimensioni richiedono l'utilizzo di proxy per fronteggiare il carico generato dai propri utenti.</para> 7.223 + <para id="x_ba">Perforce ha un’architettura client/server centralizzata in cui nessun dato viene memorizzato sul lato client. A differenza degli strumenti di controllo di revisione moderni, Perforce richiede che l’utente esegua un comando per comunicare al server di voler modificare un qualsiasi file.</para> 7.224 + 7.225 + <para id="x_bb">Le prestazioni di Perforce sono piuttosto buone per piccoli gruppi di lavoro, ma decadono rapidamente man mano che il numero di utenti cresce oltre le poche dozzine. Installazioni di Perforce di modeste dimensioni richiedono l’utilizzo di proxy per fronteggiare il carico generato dai propri utenti.</para> 7.226 7.227 </sect2> 7.228 <sect2> 7.229 <title>Scegliere uno strumento di controllo di revisione</title> 7.230 7.231 - <para id="x_bc">Con l'eccezione di CVS, tutti gli strumenti appena elencati hanno qualità uniche che li rendono adatti a particolari stili di lavoro. Non esiste un singolo strumento di controllo di revisione che sia il migliore in tutte le situazioni.</para> 7.232 + <para id="x_bc">Con l’eccezione di CVS, tutti gli strumenti appena elencati hanno qualità uniche che li rendono adatti a particolari stili di lavoro. Non esiste un singolo strumento di controllo di revisione che sia il migliore in tutte le situazioni.</para> 7.233 7.234 <para id="x_bd">Per fare un esempio, Subversion è una buona scelta per chi lavora con file binari frequentemente modificati, a causa della sua natura centralizzata e del supporto per il bloccaggio dei file.</para> 7.235 7.236 @@ -229,7 +229,7 @@ 7.237 <sect1> 7.238 <title>Passare da un altro strumento a Mercurial</title> 7.239 7.240 - <para id="x_bf">Mercurial viene distribuito con un'estensione chiamata <literal role="hg-ext">convert</literal> che può importare in maniera incrementale la cronologia delle revisioni da diversi altri strumenti di controllo di revisione. Con <quote>incrementale</quote> voglio dire che potete convertire tutta la cronologia di un progetto in un'unica seduta, poi rieseguire la conversione più tardi per ottenere i nuovi cambiamenti che sono avvenuti dopo la conversione iniziale.</para> 7.241 + <para id="x_bf">Mercurial viene distribuito con un’estensione chiamata <literal role="hg-ext">convert</literal> che può importare in maniera incrementale la cronologia delle revisioni da diversi altri strumenti di controllo di revisione. Con <quote>incrementale</quote> voglio dire che potete convertire tutta la cronologia di un progetto in un’unica seduta, poi rieseguire la conversione più tardi per ottenere i nuovi cambiamenti che sono avvenuti dopo la conversione iniziale.</para> 7.242 7.243 <para id="x_c0">Gli strumenti di controllo di revisione supportati da <literal role="hg-ext">convert</literal> sono i seguenti:</para> 7.244 <itemizedlist> 7.245 @@ -238,30 +238,30 @@ 7.246 <listitem><para id="x_c3">Git</para></listitem> 7.247 <listitem><para id="x_c4">Darcs</para></listitem></itemizedlist> 7.248 7.249 - <para id="x_c5">In più, <literal role="hg-ext">convert</literal> può esportare i cambiamenti da Mercurial a Subversion. Questo rende possibile provare Subversion e Mercurial in parallelo senza rischiare di perdere il proprio lavoro prima di impegnarsi nel definitivo passaggio dall'uno all'altro.</para> 7.250 - 7.251 - <para id="x_c6">Il comando <command role="hg-ext-convert">convert</command> è facile da usare. Vi basta puntarlo al percorso o all'URL di un repository sorgente, dandogli opzionalmente il nome di un repository destinazione, e comincerà a lavorare. Dopo la conversione iniziale, sarà sufficiente eseguire ancora lo stesso comando per importare i nuovi cambiamenti.</para> 7.252 + <para id="x_c5">In più, <literal role="hg-ext">convert</literal> può esportare i cambiamenti da Mercurial a Subversion. Questo rende possibile provare Subversion e Mercurial in parallelo senza rischiare di perdere il proprio lavoro prima di impegnarsi nel definitivo passaggio dall’uno all’altro.</para> 7.253 + 7.254 + <para id="x_c6">Il comando <command role="hg-ext-convert">convert</command> è facile da usare. Vi basta puntarlo al percorso o all’URL di un repository sorgente, dandogli opzionalmente il nome di un repository destinazione, e comincerà a lavorare. Dopo la conversione iniziale, sarà sufficiente eseguire ancora lo stesso comando per importare i nuovi cambiamenti.</para> 7.255 </sect1> 7.256 7.257 <sect1> 7.258 <title>Una breve storia del controllo di revisione</title> 7.259 7.260 - <para id="x_c7">Il più noto tra i vecchi strumenti per il controllo di revisione è SCCS (acronimo di Source Code Control System, sistema per il controllo del codice sorgente), che Marc Rochkind scrisse mentre lavorava ai laboratori Bell nei primi anni '70. SCCS operava su singoli file e obbligava ogni persona che lavorasse su un progetto ad avere accesso a uno spazio di lavoro condiviso su un singolo sistema. Solo una persona alla volta poteva modificare un file e l'arbitraggio per l'accesso ai file era realizzato attraverso i blocchi (in inglese, lock). Capitava spesso che le persone bloccassero i file e si dimenticassero di sbloccarli più tardi, impedendo a chiunque altro di modificare quei file senza l'aiuto di un amministratore.</para> 7.261 - 7.262 - <para id="x_c8">Walter Tichy sviluppò un'alternativa libera a SCCS nei primi anni '80, chiamando il suo programma RCS (acronimo di Revision Control System, sistema per il controllo di revisione). Come SCCS, RCS obbligava gli sviluppatori a lavorare in un singolo spazio di lavoro condiviso e a bloccare i file per prevenire cambiamenti simultanei da parte di più persone.</para> 7.263 - 7.264 - <para id="x_c9">Più tardi nel corso degli anni '80, Dick Grune usò RCS come componente di base per un insieme di script di shell che chiamò inizialmente cmt, ma che poi ribattezzò CVS (acronimo di Concurrent Versions System, sistema di versioni concorrenti). La grande innovazione di CVS fu che permetteva agli sviluppatori di lavorare simultaneamente e in qualche modo indipendentemente nel loro spazio di lavoro personale. Gli spazi di lavoro personali evitavano agli sviluppatori di pestarsi i piedi tutte le volte, come capitava comunemente con SCCS e RCS. Ogni sviluppatore aveva la copia di ogni file contenuto nel progetto e poteva modificare le proprie copie indipendentemente. Era necessario combinare le singole modifiche prima di introdurre i cambiamenti nel repository centrale.</para> 7.265 - 7.266 - <para id="x_ca">Brian Berliner prese gli script originali di Grune e li riscrisse in C, rilasciando nel 1989 il codice che fin da allora è stato sviluppato come la moderna versione di CVS. CVS successivamente acquisì l'abilità di operare attraverso una connessione di rete, caratteristica che gli conferì la propria architettura client/server. L'architettura di CVS è centralizzata: solo il server ha la copia della cronologia del progetto, mentre gli spazi di lavoro sui client contengono solamente una copia delle versioni recenti dei file del progetto e i metadati che servono per conoscere l'ubicazione del server. CVS ha avuto un enorme successo e probabilmente è il sistema di controllo di revisione più diffuso al mondo.</para> 7.267 - 7.268 - <para id="x_cb">All'inizio degli anni '90, Sun Microsystems sviluppò un primo sistema per il controllo di revisione distribuito chiamato TeamWare. Uno spazio di lavoro in TeamWare contiene una copia completa della cronologia del progetto. TeamWare non possiede alcuna nozione di un repository centrale. (CVS si basava su RCS per la memorizzazione della cronologia, TeamWare usava SCCS.)</para> 7.269 - 7.270 - <para id="x_cc">Durante gli anni '90 crebbe la consapevolezza dei numerosi problemi di CVS. CVS registra individualmente cambiamenti simultanei a più di un file, invece di raggrupparli insieme come una singola operazione logicamente atomica, inoltre non gestisce bene la propria gerarchia di file, ed è facile danneggiare un repository cambiando i nomi di file e directory. Le difficoltà di lettura e manutenzione del suo codice sorgente resero proibitiva la <quote>soglia del dolore</quote> da oltrepassare per correggere questi problemi architetturali.</para> 7.271 - 7.272 - <para id="x_cd">Nel 2001, Jim Blandy e Karl Fogel, due sviluppatori che avevano lavorato su CVS, diedero vita a un progetto per sostituirlo con uno strumento che avrebbe avuto un'architettura migliore e un codice più pulito. Il risultato, Subversion, non si allontana dal modello client/server centralizzato di CVS, ma aggiunge inserimenti atomici per più file alla volta, una miglior gestione degli spazi di nomi e un certo numero di altre caratteristiche che lo rendono uno strumento generalmente migliore di CVS. Dal suo rilascio iniziale, la sua popolarità è rapidamente cresciuta.</para> 7.273 - 7.274 - <para id="x_ce">Più o meno simultaneamente, Graydon Hoare cominciò a lavorare su un ambizioso sistema distribuito di controllo di revisione che chiamò Monotone. Monotone non si limita a risolvere molti dei problemi di progettazione di CVS e a possedere un'architettura peer-to-peer, ma va oltre i primi (e i successivi) strumenti di controllo di revisione in un certo numero di modi innovativi, usando hash crittografici come identificatori e adottando una nozione integrale di <quote>fiducia</quote> per autenticare il codice che proviene da sorgenti differenti.</para> 7.275 - 7.276 - <para id="x_cf">Mercurial nacque nel 2005. Mentre alcuni aspetti della sua progettazione sono stati influenzati da Monotone, Mercurial si concentra su facilità d'uso, prestazioni elevate e scalabilità verso progetti molto grandi.</para> 7.277 + <para id="x_c7">Il più noto tra i vecchi strumenti per il controllo di revisione è SCCS (acronimo di Source Code Control System, sistema per il controllo del codice sorgente), che Marc Rochkind scrisse mentre lavorava ai laboratori Bell nei primi anni ’70. SCCS operava su singoli file e obbligava ogni persona che lavorasse su un progetto ad avere accesso a uno spazio di lavoro condiviso su un singolo sistema. Solo una persona alla volta poteva modificare un file e l’arbitraggio per l’accesso ai file era realizzato attraverso i blocchi (in inglese, lock). Capitava spesso che le persone bloccassero i file e si dimenticassero di sbloccarli più tardi, impedendo a chiunque altro di modificare quei file senza l’aiuto di un amministratore.</para> 7.278 + 7.279 + <para id="x_c8">Walter Tichy sviluppò un’alternativa libera a SCCS nei primi anni ’80, chiamando il suo programma RCS (acronimo di Revision Control System, sistema per il controllo di revisione). Come SCCS, RCS obbligava gli sviluppatori a lavorare in un singolo spazio di lavoro condiviso e a bloccare i file per prevenire cambiamenti simultanei da parte di più persone.</para> 7.280 + 7.281 + <para id="x_c9">Più tardi nel corso degli anni ’80, Dick Grune usò RCS come componente di base per un insieme di script di shell che chiamò inizialmente cmt, ma che poi ribattezzò CVS (acronimo di Concurrent Versions System, sistema di versioni concorrenti). La grande innovazione di CVS fu che permetteva agli sviluppatori di lavorare simultaneamente e in qualche modo indipendentemente nel loro spazio di lavoro personale. Gli spazi di lavoro personali evitavano agli sviluppatori di pestarsi i piedi tutte le volte, come capitava comunemente con SCCS e RCS. Ogni sviluppatore aveva la copia di ogni file contenuto nel progetto e poteva modificare le proprie copie indipendentemente. Era necessario combinare le singole modifiche prima di introdurre i cambiamenti nel repository centrale.</para> 7.282 + 7.283 + <para id="x_ca">Brian Berliner prese gli script originali di Grune e li riscrisse in C, rilasciando nel 1989 il codice che fin da allora è stato sviluppato come la moderna versione di CVS. CVS successivamente acquisì l’abilità di operare attraverso una connessione di rete, caratteristica che gli conferì la propria architettura client/server. L’architettura di CVS è centralizzata: solo il server ha la copia della cronologia del progetto, mentre gli spazi di lavoro sui client contengono solamente una copia delle versioni recenti dei file del progetto e i metadati che servono per conoscere l’ubicazione del server. CVS ha avuto un enorme successo e probabilmente è il sistema di controllo di revisione più diffuso al mondo.</para> 7.284 + 7.285 + <para id="x_cb">All’inizio degli anni ’90, Sun Microsystems sviluppò un primo sistema per il controllo di revisione distribuito chiamato TeamWare. Uno spazio di lavoro in TeamWare contiene una copia completa della cronologia del progetto. TeamWare non possiede alcuna nozione di un repository centrale. (CVS si basava su RCS per la memorizzazione della cronologia, TeamWare usava SCCS.)</para> 7.286 + 7.287 + <para id="x_cc">Durante gli anni ’90 crebbe la consapevolezza dei numerosi problemi di CVS. CVS registra individualmente cambiamenti simultanei a più di un file, invece di raggrupparli insieme come una singola operazione logicamente atomica, inoltre non gestisce bene la propria gerarchia di file, ed è facile danneggiare un repository cambiando i nomi di file e directory. Le difficoltà di lettura e manutenzione del suo codice sorgente resero proibitiva la <quote>soglia del dolore</quote> da oltrepassare per correggere questi problemi architetturali.</para> 7.288 + 7.289 + <para id="x_cd">Nel 2001, Jim Blandy e Karl Fogel, due sviluppatori che avevano lavorato su CVS, diedero vita a un progetto per sostituirlo con uno strumento che avrebbe avuto un’architettura migliore e un codice più pulito. Il risultato, Subversion, non si allontana dal modello client/server centralizzato di CVS, ma aggiunge inserimenti atomici per più file alla volta, una miglior gestione degli spazi di nomi e un certo numero di altre caratteristiche che lo rendono uno strumento generalmente migliore di CVS. Dal suo rilascio iniziale, la sua popolarità è rapidamente cresciuta.</para> 7.290 + 7.291 + <para id="x_ce">Più o meno simultaneamente, Graydon Hoare cominciò a lavorare su un ambizioso sistema distribuito di controllo di revisione che chiamò Monotone. Monotone non si limita a risolvere molti dei problemi di progettazione di CVS e a possedere un’architettura peer-to-peer, ma va oltre i primi (e i successivi) strumenti di controllo di revisione in un certo numero di modi innovativi, usando hash crittografici come identificatori e adottando una nozione integrale di <quote>fiducia</quote> per autenticare il codice che proviene da sorgenti differenti.</para> 7.292 + 7.293 + <para id="x_cf">Mercurial nacque nel 2005. Mentre alcuni aspetti della sua progettazione sono stati influenzati da Monotone, Mercurial si concentra su facilità d’uso, prestazioni elevate e scalabilità verso progetti molto grandi.</para> 7.294 </sect1> 7.295 </chapter>
8.1 --- a/it/ch02-tour-basic.xml Sat Aug 22 21:01:56 2009 +0200 8.2 +++ b/it/ch02-tour-basic.xml Sat Aug 22 21:55:05 2009 +0200 8.3 @@ -10,14 +10,14 @@ 8.4 <sect2> 8.5 <title>Windows</title> 8.6 8.7 - <para id="x_c">La miglior versione di Mercurial per Windows è TortoiseHg, che può essere trovata all'indirizzo <ulink url="http://bitbucket.org/tortoisehg/stable/wiki/Home">http://bitbucket.org/tortoisehg/stable/wiki/Home</ulink>. Questo pacchetto non ha dipendenze esterne ed è pronto a funzionare non appena viene installato. Fornisce sia un'interfaccia a linea di comando sia un'interfaccia grafica.</para> 8.8 + <para id="x_c">La miglior versione di Mercurial per Windows è TortoiseHg, che può essere trovata all’indirizzo <ulink url="http://bitbucket.org/tortoisehg/stable/wiki/Home">http://bitbucket.org/tortoisehg/stable/wiki/Home</ulink>. Questo pacchetto non ha dipendenze esterne ed è pronto a funzionare non appena viene installato. Fornisce sia un’interfaccia a linea di comando sia un’interfaccia grafica.</para> 8.9 8.10 </sect2> 8.11 8.12 <sect2> 8.13 <title>Mac OS X</title> 8.14 8.15 - <para id="x_a">Lee Cantey fornisce un pacchetto di installazione di Mercurial per Mac OS X all'indirizzo <ulink url="http://mercurial.berkwood.com">http://mercurial.berkwood.com</ulink>.</para> 8.16 + <para id="x_a">Lee Cantey fornisce un pacchetto di installazione di Mercurial per Mac OS X all’indirizzo <ulink url="http://mercurial.berkwood.com">http://mercurial.berkwood.com</ulink>.</para> 8.17 </sect2> 8.18 8.19 <sect2> 8.20 @@ -25,7 +25,7 @@ 8.21 8.22 <para id="x_2">Dato che ogni distribuzione Linux ha i propri stumenti di impacchettamento, le proprie politiche e il proprio ritmo di sviluppo, è difficile dare un insieme completo di istruzioni su come installare i pacchetti eseguibili di Mercurial. La versione di Mercurial che finirete per ottenere può variare a seconda di quanto sia attiva la persona che mantiene il pacchetto di installazione per la vostra distribuzione.</para> 8.23 8.24 - <para id="x_3">Per semplificare le cose, mi concentrerò sull'installazione di Mercurial dalla linea di comando sulle distribuzioni Linux più popolari. La maggior parte di queste distribuzioni fornisce un gestore grafico per i pacchetti di installazione che vi permetterà di installare Mercurial con un singolo click sulla voce relativa al pacchetto chiamato <literal>mercurial</literal>.</para> 8.25 + <para id="x_3">Per semplificare le cose, mi concentrerò sull’installazione di Mercurial dalla linea di comando sulle distribuzioni Linux più popolari. La maggior parte di queste distribuzioni fornisce un gestore grafico per i pacchetti di installazione che vi permetterà di installare Mercurial con un singolo click sulla voce relativa al pacchetto chiamato <literal>mercurial</literal>.</para> 8.26 8.27 <itemizedlist> 8.28 <listitem><para id="x_4">Ubuntu e Debian:</para> 8.29 @@ -42,7 +42,7 @@ 8.30 <sect2> 8.31 <title>Solaris</title> 8.32 8.33 - <para id="x_9">SunFreeWare, all'indirizzo <ulink url="http://www.sunfreeware.com">http://www.sunfreeware.com</ulink>, allestisce pacchetti precompilati di Mercurial.</para> 8.34 + <para id="x_9">SunFreeWare, all’indirizzo <ulink url="http://www.sunfreeware.com">http://www.sunfreeware.com</ulink>, allestisce pacchetti precompilati di Mercurial.</para> 8.35 8.36 </sect2> 8.37 8.38 @@ -51,32 +51,32 @@ 8.39 <sect1> 8.40 <title>Per cominciare</title> 8.41 8.42 - <para id="x_e">Come prima cosa, useremo il comando <command role="hg-cmd">hg version</command> per verificare che Mercurial sia correttamente installato. L'effettiva informazione sulla versione stampata dal comando non è così importante, in quanto ci interessa semplicemente che il comando venga eseguito e che stampi qualche cosa.</para> 8.43 + <para id="x_e">Come prima cosa, useremo il comando <command role="hg-cmd">hg version</command> per verificare che Mercurial sia correttamente installato. L’effettiva informazione sulla versione stampata dal comando non è così importante, in quanto ci interessa semplicemente che il comando venga eseguito e che stampi qualche cosa.</para> 8.44 8.45 &interaction.tour.version; 8.46 8.47 <sect2> 8.48 <title>Aiuto predefinito</title> 8.49 8.50 - <para id="x_f">Mercurial include un sistema di aiuto predefinito che si rivela inestimabile quando vi trovate bloccati cercando di ricordare come si esegue un comando. Se siete completamente bloccati, provate a invocare <command role="hg-cmd">hg help</command> per visualizzare una breve lista di comandi insieme a una descrizione delle funzionalità di ognuno. Se chiedete aiuto per un comando specifico (come nell'esempio seguente), verranno stampate informazioni più dettagliate.</para> 8.51 + <para id="x_f">Mercurial include un sistema di aiuto predefinito che si rivela inestimabile quando vi trovate bloccati cercando di ricordare come si esegue un comando. Se siete completamente bloccati, provate a invocare <command role="hg-cmd">hg help</command> per visualizzare una breve lista di comandi insieme a una descrizione delle funzionalità di ognuno. Se chiedete aiuto per un comando specifico (come nell’esempio seguente), verranno stampate informazioni più dettagliate.</para> 8.52 8.53 &interaction.tour.help; 8.54 8.55 - <para id="x_10">Per ottenere un livello di dettaglio ancora maggiore (che di solito non vi servirà) eseguite <command role="hg-cmd">hg help <option role="hg-opt-global">-v</option></command>. L'opzione <option role="hg-opt-global">-v</option> è l'abbreviazione di <option role="hg-opt-global">--verbose</option> e dice a Mercurial di stampare più informazioni di quanto farebbe di solito.</para> 8.56 + <para id="x_10">Per ottenere un livello di dettaglio ancora maggiore (che di solito non vi servirà) eseguite <command role="hg-cmd">hg help <option role="hg-opt-global">-v</option></command>. L’opzione <option role="hg-opt-global">-v</option> è l’abbreviazione di <option role="hg-opt-global">--verbose</option> e dice a Mercurial di stampare più informazioni di quanto farebbe di solito.</para> 8.57 8.58 </sect2> 8.59 </sect1> 8.60 <sect1> 8.61 <title>Lavorare con un repository</title> 8.62 8.63 - <para id="x_11">In Mercurial, tutto accade all'interno di un <emphasis>repository</emphasis>. Il repository di un progetto contiene tutti i file che <quote>appartengono</quote> a quel progetto insieme a una registrazione cronologica delle loro modifiche.</para> 8.64 - 8.65 - <para id="x_12">Non c'è niente di particolarmente magico in un repository: è semplicemente un albero di directory nel vostro file system che Mercurial tratta in modo speciale. Potete cancellare un repository o modificarne il nome in ogni momento, usando sia la riga di comando sia il vostro programma preferito di gestione dei file.</para> 8.66 + <para id="x_11">In Mercurial, tutto accade all’interno di un <emphasis>repository</emphasis>. Il repository di un progetto contiene tutti i file che <quote>appartengono</quote> a quel progetto insieme a una registrazione cronologica delle loro modifiche.</para> 8.67 + 8.68 + <para id="x_12">Non c’è niente di particolarmente magico in un repository: è semplicemente un albero di directory nel vostro file system che Mercurial tratta in modo speciale. Potete cancellare un repository o modificarne il nome in ogni momento, usando sia la riga di comando sia il vostro programma preferito di gestione dei file.</para> 8.69 8.70 <sect2> 8.71 <title>Fare una copia locale di un repository</title> 8.72 8.73 - <para id="x_13"><emphasis>Copiare</emphasis> un repository è in realtà un'operazione un po' speciale. Pur potendo usare un normale comando di copia dei file per copiare un repository, il modo migliore per farlo è quello di usare un comando predefinito fornito da Mercurial. Questo comando si chiama <command role="hg-cmd">hg clone</command>, perché crea una copia identica di un repository esistente.</para> 8.74 + <para id="x_13"><emphasis>Copiare</emphasis> un repository è in realtà un’operazione un po’ speciale. Pur potendo usare un normale comando di copia dei file per copiare un repository, il modo migliore per farlo è quello di usare un comando predefinito fornito da Mercurial. Questo comando si chiama <command role="hg-cmd">hg clone</command>, perché crea una copia identica di un repository esistente.</para> 8.75 8.76 &interaction.tour.clone; 8.77 8.78 @@ -88,7 +88,7 @@ 8.79 8.80 <para id="x_15">Il contenuto e la cronologia di questi file nel nostro repository sono gli stessi di quelli presenti nel repository che abbiamo clonato.</para> 8.81 8.82 - <para id="x_16">Ogni repository Mercurial contiene la propria copia privata dei file e della cronologia di un progetto ed è sempre completo, auto-contenuto e indipendente. Come abbiamo appena detto, il clone di un repository ricorda l'ubicazione del repository da cui è stato clonato, ma Mercurial non comunicherà con quel repository, o con qualsiasi altro repository, a meno che non siamo noi a chiederlo.</para> 8.83 + <para id="x_16">Ogni repository Mercurial contiene la propria copia privata dei file e della cronologia di un progetto ed è sempre completo, auto-contenuto e indipendente. Come abbiamo appena detto, il clone di un repository ricorda l’ubicazione del repository da cui è stato clonato, ma Mercurial non comunicherà con quel repository, o con qualsiasi altro repository, a meno che non siamo noi a chiederlo.</para> 8.84 8.85 <para id="x_17">Per ora, questo significa che siamo liberi di effettuare esperimenti con il nostro repository, sapendo con sicurezza che è un <quote>ambiente di prova</quote> privato le cui variazioni non avranno effetto su nessun altro.</para> 8.86 8.87 @@ -96,13 +96,13 @@ 8.88 <sect2> 8.89 <title>Che cosa contiene un repository?</title> 8.90 8.91 - <para id="x_18">Se diamo un'occhiata più dettagliata all'interno di un repository, possiamo vedere che contiene una directory chiamata <filename class="directory">.hg</filename>. Questo è il luogo dove Mercurial tiene tutti i propri metadati sul repository.</para> 8.92 + <para id="x_18">Se diamo un’occhiata più dettagliata all’interno di un repository, possiamo vedere che contiene una directory chiamata <filename class="directory">.hg</filename>. Questo è il luogo dove Mercurial tiene tutti i propri metadati sul repository.</para> 8.93 8.94 &interaction.tour.ls-a; 8.95 8.96 <para id="x_19">Il contenuto della directory <filename class="directory">.hg</filename> e delle sue sottodirectory è riservato a Mercurial. Tutti gli altri file e directory nel repository sono vostri e potete farne ciò che volete.</para> 8.97 8.98 - <para id="x_1a">Per introdurre un po' di terminologia, diciamo che la directory <filename class="directory">.hg</filename> è il repository <quote>reale</quote> e che tutti gli altri file e directory che coesistono con esso si trovano nella <emphasis>directory di lavoro</emphasis>. Potete ricordare facilmente questa distinzione se considerate che il <emphasis>repository</emphasis> contiene la <emphasis>cronologia</emphasis> del progetto, mentre la <emphasis>directory di lavoro</emphasis> contiene una <emphasis>fotografia</emphasis> del vostro progetto in un punto particolare della cronologia.</para> 8.99 + <para id="x_1a">Per introdurre un po’ di terminologia, diciamo che la directory <filename class="directory">.hg</filename> è il repository <quote>reale</quote> e che tutti gli altri file e directory che coesistono con esso si trovano nella <emphasis>directory di lavoro</emphasis>. Potete ricordare facilmente questa distinzione se considerate che il <emphasis>repository</emphasis> contiene la <emphasis>cronologia</emphasis> del progetto, mentre la <emphasis>directory di lavoro</emphasis> contiene una <emphasis>fotografia</emphasis> del vostro progetto in un punto particolare della cronologia.</para> 8.100 8.101 </sect2> 8.102 </sect1> 8.103 @@ -120,17 +120,17 @@ 8.104 <itemizedlist> 8.105 <listitem><para id="x_1e"><literal>changeset</literal>: questo campo ha il formato di un numero, seguito dal carattere di due punti, seguito da una stringa esadecimale. Questi sono gli <emphasis>identificatori</emphasis> del changeset. La stringa esadecimale è un identificatore unico: la stessa stringa esadecimale si riferirà sempre allo stesso changeset in ogni copia di questo repository. Il numero è più corto e facile da digitare rispetto alla stringa esadecimale, ma non è unico: lo stesso numero potrebbe identificare changeset differenti in due cloni differenti di uno stesso repository.</para> 8.106 </listitem> 8.107 - <listitem><para id="x_1f"><literal>utente</literal> (in inglese, <literal>user</literal>): l'identità della persona che ha creato il changeset. Questo è un campo di testo libero, ma il più delle volte contiene il nome e l'indirizzo email di una persona.</para></listitem> 8.108 - <listitem><para id="x_20"><literal>data</literal> (in inglese, <literal>date</literal>): la data, l'orario e il fuso orario in cui il changeset è stato creato. (La data e l'orario sono locali per quel fuso orario e mostrano il giorno e l'ora per la persona che ha creato il changeset.)</para></listitem> 8.109 + <listitem><para id="x_1f"><literal>utente</literal> (in inglese, <literal>user</literal>): l’identità della persona che ha creato il changeset. Questo è un campo di testo libero, ma il più delle volte contiene il nome e l’indirizzo email di una persona.</para></listitem> 8.110 + <listitem><para id="x_20"><literal>data</literal> (in inglese, <literal>date</literal>): la data, l’orario e il fuso orario in cui il changeset è stato creato. (La data e l’orario sono locali per quel fuso orario e mostrano il giorno e l’ora per la persona che ha creato il changeset.)</para></listitem> 8.111 <listitem><para id="x_21"><literal>sommario</literal> (in inglese, <literal>summary</literal>): la prima riga del messaggio di testo che il creatore del changeset ha utilizzato per descrivere il changeset.</para></listitem> 8.112 <listitem> 8.113 - <para id="x_67d">Alcuni changeset, come il primo della lista mostrata qui sopra, sono contrassegnati da un'etichetta contenuta in un campo <literal>etichetta</literal> (in inglese, <literal>tag</literal>). Un'etichetta è un altro modo di identificare un changeset, dandogli un nome facile da ricordare. (L'etichetta chiamata <literal>tip</literal> è speciale: si riferisce sempre alla modifica più recente nel repository.)</para> 8.114 + <para id="x_67d">Alcuni changeset, come il primo della lista mostrata qui sopra, sono contrassegnati da un’etichetta contenuta in un campo <literal>etichetta</literal> (in inglese, <literal>tag</literal>). Un’etichetta è un altro modo di identificare un changeset, dandogli un nome facile da ricordare. (L’etichetta chiamata <literal>tip</literal> è speciale: si riferisce sempre alla modifica più recente nel repository.)</para> 8.115 </listitem> 8.116 </itemizedlist> 8.117 8.118 - <para id="x_22">Il testo stampato dall'esecuzione predefinita del comando <command role="hg-cmd">hg log</command> è un semplice riepilogo e in quanto tale non contiene molti dettagli.</para> 8.119 - 8.120 - <para id="x_23">La <xref linkend="fig:tour-basic:history"/> mostra una rappresentazione grafica della cronologia del repository <filename class="directory">hello</filename>, in modo che sia un po' più facile vedere qual è la direzione in cui la cronologia si sta <quote>sviluppando</quote>. Ritorneremo a questa figura diverse volte in questo capitolo e nei capitoli che seguono.</para> 8.121 + <para id="x_22">Il testo stampato dall’esecuzione predefinita del comando <command role="hg-cmd">hg log</command> è un semplice riepilogo e in quanto tale non contiene molti dettagli.</para> 8.122 + 8.123 + <para id="x_23">La <xref linkend="fig:tour-basic:history"/> mostra una rappresentazione grafica della cronologia del repository <filename class="directory">hello</filename>, in modo che sia un po’ più facile vedere qual è la direzione in cui la cronologia si sta <quote>sviluppando</quote>. Ritorneremo a questa figura diverse volte in questo capitolo e nei capitoli che seguono.</para> 8.124 8.125 <figure id="fig:tour-basic:history"> 8.126 <title>Rappresentazione grafica della cronologia per il repository <filename class="directory">hello</filename></title> 8.127 @@ -143,45 +143,45 @@ 8.128 <sect2> 8.129 <title>Parlare di changeset o revisioni con altre persone</title> 8.130 8.131 - <para id="x_25">Dato che l'inglese è una lingua notoriamente trasandata e che l'informatica ha una storia consacrata alla confusione terminologica (perché usare un solo termine quando se ne possono usare quattro?), il controllo di revisione impiega una varietà di termini ed espressioni per indicare la stessa cosa. Se parlate della cronologia di Mercurial con altre persone, scoprirete che il termine <quote>changeset</quote> è spesso abbreviato in <quote>change</quote> (in italiano, cambiamento) o in <quote>cset</quote> (nella sua forma scritta) e che talvolta ci si riferisce a un changeset chiamandolo <quote>revisione</quote> oppure <quote>rev</quote>.</para> 8.132 - 8.133 - <para id="x_26">Mentre non ha importanza quale <emphasis>parola</emphasis> voi usiate per riferirvi al concetto di <quote>un changeset</quote>, l'<emphasis>identificatore</emphasis> che usate per riferirvi a <quote>uno <emphasis>specifico</emphasis> changeset</quote> è di grande importanza. Ricordatevi che il campo <literal>changeset</literal> nel riepilogo mostrato da <command role="hg-cmd">hg log</command> identifica un changeset utilizzando sia un numero che una stringa esadecimale.</para> 8.134 + <para id="x_25">Dato che l’inglese è una lingua notoriamente trasandata e che l’informatica ha una storia consacrata alla confusione terminologica (perché usare un solo termine quando se ne possono usare quattro?), il controllo di revisione impiega una varietà di termini ed espressioni per indicare la stessa cosa. Se parlate della cronologia di Mercurial con altre persone, scoprirete che il termine <quote>changeset</quote> è spesso abbreviato in <quote>change</quote> (in italiano, cambiamento) o in <quote>cset</quote> (nella sua forma scritta) e che talvolta ci si riferisce a un changeset chiamandolo <quote>revisione</quote> oppure <quote>rev</quote>.</para> 8.135 + 8.136 + <para id="x_26">Mentre non ha importanza quale <emphasis>parola</emphasis> voi usiate per riferirvi al concetto di <quote>un changeset</quote>, l’<emphasis>identificatore</emphasis> che usate per riferirvi a <quote>uno <emphasis>specifico</emphasis> changeset</quote> è di grande importanza. Ricordatevi che il campo <literal>changeset</literal> nel riepilogo mostrato da <command role="hg-cmd">hg log</command> identifica un changeset utilizzando sia un numero che una stringa esadecimale.</para> 8.137 <itemizedlist> 8.138 <listitem><para id="x_27">Il numero di revisione è una notazione comoda che è <emphasis>valida solo in quel repository</emphasis>.</para></listitem> 8.139 - <listitem><para id="x_28">La stringa esadecimale è l'<emphasis>identificatore permanente e non modificabile</emphasis> che individuerà sempre quell'esatto changeset in <emphasis>qualsiasi</emphasis> copia del repository.</para></listitem> 8.140 + <listitem><para id="x_28">La stringa esadecimale è l’<emphasis>identificatore permanente e non modificabile</emphasis> che individuerà sempre quell’esatto changeset in <emphasis>qualsiasi</emphasis> copia del repository.</para></listitem> 8.141 </itemizedlist> 8.142 8.143 - <para id="x_29">Questa distinzione è importante. Se spedite un'email a qualcuno parlando della <quote>revisione 33</quote>, c'è un'alta probabilità che la sua revisione 33 <emphasis>non sia la stessa</emphasis> della vostra, perché un numero di revisione dipende dall'ordine in cui i cambiamenti sono stati introdotti in un repository e non c'è alcuna garanzia che gli stessi cambiamenti siano avvenuti nello stesso ordine in repository differenti. Tre cambiamenti <literal>a,b,c</literal> possono facilmente comparire in un repository come <literal>0,1,2</literal> e in un altro repository come <literal>0,2,1</literal>.</para> 8.144 - 8.145 - <para id="x_2a">Mercurial usa i numeri di revisione soltanto come un'abbreviazione di convenienza. Se avete bisogno di discutere un changeset con qualcuno o di indicare un changeset per qualche altra ragione (per esempio, nella segnalazione di un bug), usate l'identificatore esadecimale.</para> 8.146 + <para id="x_29">Questa distinzione è importante. Se spedite un’email a qualcuno parlando della <quote>revisione 33</quote>, c’è un’alta probabilità che la sua revisione 33 <emphasis>non sia la stessa</emphasis> della vostra, perché un numero di revisione dipende dall’ordine in cui i cambiamenti sono stati introdotti in un repository e non c’è alcuna garanzia che gli stessi cambiamenti siano avvenuti nello stesso ordine in repository differenti. Tre cambiamenti <literal>a,b,c</literal> possono facilmente comparire in un repository come <literal>0,1,2</literal> e in un altro repository come <literal>0,2,1</literal>.</para> 8.147 + 8.148 + <para id="x_2a">Mercurial usa i numeri di revisione soltanto come un’abbreviazione di convenienza. Se avete bisogno di discutere un changeset con qualcuno o di indicare un changeset per qualche altra ragione (per esempio, nella segnalazione di un bug), usate l’identificatore esadecimale.</para> 8.149 8.150 </sect2> 8.151 <sect2> 8.152 <title>Vedere revisioni specifiche</title> 8.153 8.154 - <para id="x_2b">Per ridurre l'elenco stampato dal comando <command role="hg-cmd">hg log</command> a una singola revisione, usate l'opzione <option role="hg-opt-log">-r</option> (o <option role="hg-opt-log">--rev</option>). Potete usare sia un numero di revisione che un identificatore esadecimale e potete fornire al comando tutte le revisioni che volete.</para> 8.155 + <para id="x_2b">Per ridurre l’elenco stampato dal comando <command role="hg-cmd">hg log</command> a una singola revisione, usate l’opzione <option role="hg-opt-log">-r</option> (o <option role="hg-opt-log">--rev</option>). Potete usare sia un numero di revisione che un identificatore esadecimale e potete fornire al comando tutte le revisioni che volete.</para> 8.156 8.157 &interaction.tour.log-r; 8.158 8.159 - <para id="x_2c">Se volete vedere la cronologia di diverse revisioni senza doverle elencare tutte potete usare la <emphasis>notazione di intervallo</emphasis>, che vi permette di esprimere l'idea di operare su <quote>tutte le revisioni tra <literal>abc</literal> e <literal>def</literal> comprese</quote>.</para> 8.160 + <para id="x_2c">Se volete vedere la cronologia di diverse revisioni senza doverle elencare tutte potete usare la <emphasis>notazione di intervallo</emphasis>, che vi permette di esprimere l’idea di operare su <quote>tutte le revisioni tra <literal>abc</literal> e <literal>def</literal> comprese</quote>.</para> 8.161 8.162 &interaction.tour.log.range; 8.163 8.164 - <para id="x_2d">Mercurial rispetta anche l'ordine in cui specificate le revisioni, quindi il comando <command role="hg-cmd">hg log -r 2:4</command> stamperà le revisioni 2, 3 e 4, mentre il comando <command role="hg-cmd">hg log -r 4:2</command> stamperà le revisioni 4, 3 e 2.</para> 8.165 + <para id="x_2d">Mercurial rispetta anche l’ordine in cui specificate le revisioni, quindi il comando <command role="hg-cmd">hg log -r 2:4</command> stamperà le revisioni 2, 3 e 4, mentre il comando <command role="hg-cmd">hg log -r 4:2</command> stamperà le revisioni 4, 3 e 2.</para> 8.166 8.167 </sect2> 8.168 <sect2> 8.169 <title>Informazioni più dettagliate</title> 8.170 8.171 - <para id="x_2e">Mentre le informazioni di riepilogo stampate da <command role="hg-cmd">hg log</command> sono utili se sapete già cosa state cercando, potreste aver bisogno di vedere una descrizione completa del cambiamento, o una lista dei file modificati, nel caso stiate tentando di capire se il changeset è quello che volevate. L'opzione <option role="hg-opt-global">-v</option> (o <option role="hg-opt-global">--verbose</option>) del comando <command role="hg-cmd">hg log</command> vi fornisce questi dettagli aggiuntivi.</para> 8.172 + <para id="x_2e">Mentre le informazioni di riepilogo stampate da <command role="hg-cmd">hg log</command> sono utili se sapete già cosa state cercando, potreste aver bisogno di vedere una descrizione completa del cambiamento, o una lista dei file modificati, nel caso stiate tentando di capire se il changeset è quello che volevate. L’opzione <option role="hg-opt-global">-v</option> (o <option role="hg-opt-global">--verbose</option>) del comando <command role="hg-cmd">hg log</command> vi fornisce questi dettagli aggiuntivi.</para> 8.173 8.174 &interaction.tour.log-v; 8.175 8.176 - <para id="x_2f">Se volete vedere sia la descrizione che il contenuto di un cambiamento, aggiungete l'opzione <option role="hg-opt-log">-p</option> (o <option role="hg-opt-log">--patch</option>). In questo modo il contenuto del cambiamento verrà stampato come un <emphasis>diff unificato</emphasis> (se non avete mai visto un diff unificato prima d'ora, date un'occhiata alla <xref linkend="sec:mq:patch"/> per un'introduzione).</para> 8.177 + <para id="x_2f">Se volete vedere sia la descrizione che il contenuto di un cambiamento, aggiungete l’opzione <option role="hg-opt-log">-p</option> (o <option role="hg-opt-log">--patch</option>). In questo modo il contenuto del cambiamento verrà stampato come un <emphasis>diff unificato</emphasis> (se non avete mai visto un diff unificato prima d’ora, date un’occhiata alla <xref linkend="sec:mq:patch"/> per un’introduzione).</para> 8.178 8.179 &interaction.tour.log-vp; 8.180 8.181 - <para id="x_67e">L'opzione <option role="hg-opt-log">-p</option> è tremendamente utile, quindi merita di essere ricordata.</para> 8.182 + <para id="x_67e">L’opzione <option role="hg-opt-log">-p</option> è tremendamente utile, quindi merita di essere ricordata.</para> 8.183 8.184 </sect2> 8.185 </sect1> 8.186 @@ -191,11 +191,11 @@ 8.187 8.188 <para id="x_30">Facciamo una piccola pausa nella nostra esplorazione dei comandi di Mercurial per discutere lo schema secondo cui quei comandi lavorano, perché potreste trovarlo utile da tenere a mente nel seguito di questa panoramica.</para> 8.189 8.190 - <para id="x_31">Mercurial adotta un approccio semplice e consistente per gestire le opzioni che potete passare ai comandi. Segue l'insieme di convenzioni per le opzioni comunemente usato nei moderni sistemi Linux e Unix.</para> 8.191 + <para id="x_31">Mercurial adotta un approccio semplice e consistente per gestire le opzioni che potete passare ai comandi. Segue l’insieme di convenzioni per le opzioni comunemente usato nei moderni sistemi Linux e Unix.</para> 8.192 8.193 <itemizedlist> 8.194 <listitem> 8.195 - <para id="x_32">Ogni opzione ha un nome lungo. Per esempio, come avete già visto, il comando <command role="hg-cmd">hg log</command> accetta un'opzione <option role="hg-opt-log">--rev</option>.</para> 8.196 + <para id="x_32">Ogni opzione ha un nome lungo. Per esempio, come avete già visto, il comando <command role="hg-cmd">hg log</command> accetta un’opzione <option role="hg-opt-log">--rev</option>.</para> 8.197 </listitem> 8.198 <listitem> 8.199 <para id="x_33">La maggior parte delle opzioni ha anche un nome breve. Invece di <option role="hg-opt-log">--rev</option>, possiamo usare <option role="hg-opt-log">-r</option>. (Alcune opzioni non hanno un nome breve perché vengono usate raramente.)</para> 8.200 @@ -213,19 +213,19 @@ 8.201 8.202 <para id="x_36">Negli esempi contenuti in questo libro, di solito uso le opzioni brevi invece di quelle lunghe. Questo riflette semplicemente la mia preferenza, quindi non leggetevi nulla di particolarmente significativo.</para> 8.203 8.204 - <para id="x_37">La maggior parte dei comandi che stampano un testo di qualche tipo stamperanno più testo quando gli verrà passata l'opzione <option role="hg-opt-global">-v</option> (o <option role="hg-opt-global">--verbose</option>) e meno testo quando gli verrà passata l'opzione <option role="hg-opt-global">-q</option> (o <option role="hg-opt-global">--quiet</option>).</para> 8.205 + <para id="x_37">La maggior parte dei comandi che stampano un testo di qualche tipo stamperanno più testo quando gli verrà passata l’opzione <option role="hg-opt-global">-v</option> (o <option role="hg-opt-global">--verbose</option>) e meno testo quando gli verrà passata l’opzione <option role="hg-opt-global">-q</option> (o <option role="hg-opt-global">--quiet</option>).</para> 8.206 8.207 <note> 8.208 <title>La consistenza nella denominazione delle opzioni</title> 8.209 8.210 - <para id="x_680">Quasi sempre, le opzioni dei comandi Mercurial usano nomi consistenti per fare riferimento agli stessi concetti. Per esempio, se un comando ha a che fare con i changeset, questi verranno sempre identificati tramite l'opzione <option role="hg-opt-log">--rev</option> o <option role="hg-opt-log">-r</option>. L'uso consistente dei nomi delle opzioni rende più facile ricordarsi quali opzioni sono accettate da un particolare comando.</para> 8.211 + <para id="x_680">Quasi sempre, le opzioni dei comandi Mercurial usano nomi consistenti per fare riferimento agli stessi concetti. Per esempio, se un comando ha a che fare con i changeset, questi verranno sempre identificati tramite l’opzione <option role="hg-opt-log">--rev</option> o <option role="hg-opt-log">-r</option>. L’uso consistente dei nomi delle opzioni rende più facile ricordarsi quali opzioni sono accettate da un particolare comando.</para> 8.212 </note> 8.213 8.214 </sect1> 8.215 <sect1> 8.216 <title>Come effettuare e rivedere i cambiamenti</title> 8.217 8.218 - <para id="x_38">Ora che sappiamo come ispezionare la cronologia in Mercurial, diamo un'occhiata al modo in cui si apportano e si esaminano i cambiamenti.</para> 8.219 + <para id="x_38">Ora che sappiamo come ispezionare la cronologia in Mercurial, diamo un’occhiata al modo in cui si apportano e si esaminano i cambiamenti.</para> 8.220 8.221 <para id="x_39">Per cominciare, isoleremo il nostro esperimento in un apposito repository. Usiamo il comando <command role="hg-cmd">hg clone</command>, ma senza clonare il repository remoto, perché sarà sufficiente clonarne la copia locale che già possediamo. Una clonazione locale è molto più veloce rispetto a una clonazione attraverso la rete e, nella maggior parte dei casi, il clone di un repository locale utilizza anche una quantità inferiore di spazio su disco<footnote> 8.222 <para id="x_681">Il risparmio di spazio si ottiene quando i repository sorgente e destinazione sono sullo stesso file system, nel qual caso Mercurial userà collegamenti fisici per effettuare una condivisione copy-on-write dei suoi metadati interni. Se questa spiegazione non significa nulla per voi, non preoccupatevi: ogni cosa avviene in maniera trasparente e automatica, e non avete bisogno di capirla.</para> 8.223 @@ -233,7 +233,7 @@ 8.224 8.225 &interaction.tour.reclone; 8.226 8.227 - <para id="x_3a">Come nota a margine, è buona pratica tenere da parte una copia <quote>intatta</quote> di un repository remoto, che potete usare per creare cloni temporanei o ambienti di prova per ogni attività che volete svolgere. Questo vi permette di lavorare su molteplici attività in parallelo, ognuna isolata dalle altre fino a quando non è completa e non siete pronti per reintegrarla. Dato che i cloni locali sono così economici, non c'è quasi alcuno spreco nel clonare e cancellare repository ogni volta che volete.</para> 8.228 + <para id="x_3a">Come nota a margine, è buona pratica tenere da parte una copia <quote>intatta</quote> di un repository remoto, che potete usare per creare cloni temporanei o ambienti di prova per ogni attività che volete svolgere. Questo vi permette di lavorare su molteplici attività in parallelo, ognuna isolata dalle altre fino a quando non è completa e non siete pronti per reintegrarla. Dato che i cloni locali sono così economici, non c’è quasi alcuno spreco nel clonare e cancellare repository ogni volta che volete.</para> 8.229 8.230 <para id="x_3b">Nel nostro repository <filename class="directory">mio-hello</filename> abbiamo un file <filename>hello.c</filename> che contiene il classico programma <quote>ciao, mondo</quote>.</para> 8.231 8.232 @@ -258,7 +258,7 @@ 8.233 <tip> 8.234 <title>Capire le patch</title> 8.235 8.236 - <para id="x_683">Ricordate di dare un'occhiata alla <xref linkend="sec:mq:patch"/> se non sapete come interpretare il risultato del comando appena eseguito.</para> 8.237 + <para id="x_683">Ricordate di dare un’occhiata alla <xref linkend="sec:mq:patch"/> se non sapete come interpretare il risultato del comando appena eseguito.</para> 8.238 </tip> 8.239 </sect1> 8.240 <sect1> 8.241 @@ -272,16 +272,16 @@ 8.242 <sect2> 8.243 <title>Impostare un nome utente</title> 8.244 8.245 - <para id="x_42">Quando provate a eseguire <command role="hg-cmd">hg commit</command> per la prima volta, non c'è alcuna garanzia che il comando abbia successo. Mercurial registra il vostro nome e indirizzo con ogni cambiamento che inserite, in modo che più tardi voi e gli altri siate in grado di dire chi lo ha effettuato. Mercurial prova a costruire automaticamente un nome utente ragionevole da usare per l'inserimento. Proverà ognuno dei seguenti metodi, in questo ordine.</para> 8.246 + <para id="x_42">Quando provate a eseguire <command role="hg-cmd">hg commit</command> per la prima volta, non c’è alcuna garanzia che il comando abbia successo. Mercurial registra il vostro nome e indirizzo con ogni cambiamento che inserite, in modo che più tardi voi e gli altri siate in grado di dire chi lo ha effettuato. Mercurial prova a costruire automaticamente un nome utente ragionevole da usare per l’inserimento. Proverà ognuno dei seguenti metodi, in questo ordine.</para> 8.247 <orderedlist> 8.248 - <listitem><para id="x_43">La precedenza più alta verrà data al nome utente che segue l'opzione <option role="hg-opt-commit">-u</option> del comando <command role="hg-cmd">hg commit</command>.</para></listitem> 8.249 - <listitem><para id="x_44">Successivamente, verrà controllato il valore della variabile d'ambiente <envar>HGUSER</envar>.</para></listitem> 8.250 - <listitem><para id="x_45">Quindi, verrà usato l'elemento <envar role="rc-item-ui">username</envar> contenuto in un file chiamato <filename role="special">.hgrc</filename> che potreste aver creato nella vostra directory personale. Per vedere come dovrebbero apparire i contenuti di questo file, fate riferimento alla <xref linkend="sec:tour-basic:username"/> più avanti.</para></listitem> 8.251 - <listitem><para id="x_46">Successivamente, verrà controllato il valore della variabile d'ambiente <envar>EMAIL</envar>.</para></listitem> 8.252 + <listitem><para id="x_43">La precedenza più alta verrà data al nome utente che segue l’opzione <option role="hg-opt-commit">-u</option> del comando <command role="hg-cmd">hg commit</command>.</para></listitem> 8.253 + <listitem><para id="x_44">Successivamente, verrà controllato il valore della variabile d’ambiente <envar>HGUSER</envar>.</para></listitem> 8.254 + <listitem><para id="x_45">Quindi, verrà usato l’elemento <envar role="rc-item-ui">username</envar> contenuto in un file chiamato <filename role="special">.hgrc</filename> che potreste aver creato nella vostra directory personale. Per vedere come dovrebbero apparire i contenuti di questo file, fate riferimento alla <xref linkend="sec:tour-basic:username"/> più avanti.</para></listitem> 8.255 + <listitem><para id="x_46">Successivamente, verrà controllato il valore della variabile d’ambiente <envar>EMAIL</envar>.</para></listitem> 8.256 <listitem><para id="x_47">Infine, Mercurial interrogherà il vostro sistema per trovare il vostro nome utente locale e il nome della vostra macchina, utilizzandoli poi per costruire un nome utente. Dato che questo processo risulta spesso in un nome utente che non è molto utile, Mercurial stamperà un messaggio di avvertimento nel caso sia costretto a ricorrere a questa alternativa.</para></listitem> 8.257 </orderedlist> 8.258 <para id="x_48">Se tutti questi meccanismi falliscono, Mercurial si fermerà stampando un messaggio di errore. In questo caso, non vi permetterà di eseguire il commit fino a quando non avrete impostato il vostro nome utente.</para> 8.259 - <para id="x_49">Dovreste considerare la variabile d'ambiente <envar>HGUSER</envar> e l'opzione <option role="hg-opt-commit">-u</option> del comando <command role="hg-cmd">hg commit</command> come modi per rimpiazzare la selezione predefinita del nome utente da parte di Mercurial. Normalmente, il modo più semplice e robusto per impostare il vostro nome utente è quello di creare un file <filename role="special">.hgrc</filename>.</para> 8.260 + <para id="x_49">Dovreste considerare la variabile d’ambiente <envar>HGUSER</envar> e l’opzione <option role="hg-opt-commit">-u</option> del comando <command role="hg-cmd">hg commit</command> come modi per rimpiazzare la selezione predefinita del nome utente da parte di Mercurial. Normalmente, il modo più semplice e robusto per impostare il vostro nome utente è quello di creare un file <filename role="special">.hgrc</filename>.</para> 8.261 <sect3 id="sec:tour-basic:username"> 8.262 <title>Creare un file di configurazione per Mercurial</title> 8.263 8.264 @@ -290,7 +290,7 @@ 8.265 <tip> 8.266 <title>La <quote>directory personale</quote> sotto Windows</title> 8.267 8.268 - <para id="x_716">In una installazione italiana di Windows, la vostra directory personale di solito corrisponde a una cartella chiamata con il vostro nome utente che si trova in <filename>C:\Documents and Settings</filename>. Potete scoprire l'esatto nome della vostra directory personale aprendo una finestra del prompt dei comandi e invocando il comando seguente.</para> 8.269 + <para id="x_716">In una installazione italiana di Windows, la vostra directory personale di solito corrisponde a una cartella chiamata con il vostro nome utente che si trova in <filename>C:\Documents and Settings</filename>. Potete scoprire l’esatto nome della vostra directory personale aprendo una finestra del prompt dei comandi e invocando il comando seguente.</para> 8.270 8.271 <screen><prompt>C:\></prompt> <userinput>echo %UserProfile%</userinput></screen> 8.272 </tip> 8.273 @@ -299,13 +299,13 @@ 8.274 [ui] 8.275 username = Nome Cognome <indirizzo.email@example.org></programlisting> 8.276 8.277 - <para id="x_4b">La riga <quote><literal>[ui]</literal></quote> comincia una <emphasis>sezione</emphasis> del file di configurazione, così potete leggere la riga <quote><literal>username = ...</literal></quote> con il significato di <quote>imposta il valore dell'elemento <literal>username</literal> nella sezione <literal>ui</literal></quote>. Una sezione continua fino a quando ne comincia una nuova o fino alla fine del file. Mercurial ignora le righe vuote e tratta il testo di ogni riga che comincia con il carattere <quote><literal>#</literal></quote> come un commento.</para> 8.278 + <para id="x_4b">La riga <quote><literal>[ui]</literal></quote> comincia una <emphasis>sezione</emphasis> del file di configurazione, così potete leggere la riga <quote><literal>username = ...</literal></quote> con il significato di <quote>imposta il valore dell’elemento <literal>username</literal> nella sezione <literal>ui</literal></quote>. Una sezione continua fino a quando ne comincia una nuova o fino alla fine del file. Mercurial ignora le righe vuote e tratta il testo di ogni riga che comincia con il carattere <quote><literal>#</literal></quote> come un commento.</para> 8.279 </sect3> 8.280 8.281 <sect3> 8.282 <title>Scegliere un nome utente</title> 8.283 8.284 - <para id="x_4c">Potete usare il testo che preferite come valore dell'elemento di configurazione <literal>username</literal>, dato che questa informazione serve per essere letta da altre persone e non verrà interpretata da Mercurial. La convenzione seguita dalla maggior parte delle persone è quella di usare il proprio nome e indirizzo email, come nell'esempio precedente.</para> 8.285 + <para id="x_4c">Potete usare il testo che preferite come valore dell’elemento di configurazione <literal>username</literal>, dato che questa informazione serve per essere letta da altre persone e non verrà interpretata da Mercurial. La convenzione seguita dalla maggior parte delle persone è quella di usare il proprio nome e indirizzo email, come nell’esempio precedente.</para> 8.286 <note> 8.287 <para id="x_4d">Il server web predefinito di Mercurial offusca gli indirizzi email, per rendere la vita difficile agli strumenti che gli spammer usano per raccogliere nuovi indirizzi. Questo riduce la possibilità che cominciate a ricevere una maggior quantità di spazzatura nella vostra casella email se pubblicate un repository Mercurial sul web.</para></note> 8.288 </sect3> 8.289 @@ -313,11 +313,11 @@ 8.290 <sect2> 8.291 <title>Scrivere un messaggio di commit</title> 8.292 8.293 - <para id="x_4e">Quando inseriamo un cambiamento, Mercurial apre un editor di testo per farci scrivere un <emphasis>messaggio di commit</emphasis> allo scopo di descrivere le modifiche che abbiamo effettuato in questo changeset. Il messaggio verrà registrato per i lettori interessati a sapere quello che abbiamo fatto e perché, e verrà stampato dalle invocazioni di <command role="hg-cmd">hg log</command> successive alla terminazione dell'inserimento.</para> 8.294 + <para id="x_4e">Quando inseriamo un cambiamento, Mercurial apre un editor di testo per farci scrivere un <emphasis>messaggio di commit</emphasis> allo scopo di descrivere le modifiche che abbiamo effettuato in questo changeset. Il messaggio verrà registrato per i lettori interessati a sapere quello che abbiamo fatto e perché, e verrà stampato dalle invocazioni di <command role="hg-cmd">hg log</command> successive alla terminazione dell’inserimento.</para> 8.295 8.296 &interaction.tour.commit; 8.297 8.298 - <para id="x_4f">L'editor aperto dal comando <command role="hg-cmd">hg commit</command> conterrà una o due righe vuote, seguite da un certo numero di righe che cominciano con <quote><literal>HG:</literal></quote>.</para> 8.299 + <para id="x_4f">L’editor aperto dal comando <command role="hg-cmd">hg commit</command> conterrà una o due righe vuote, seguite da un certo numero di righe che cominciano con <quote><literal>HG:</literal></quote>.</para> 8.300 8.301 <programlisting> 8.302 Potete digitare qui il vostro messaggio di commit. 8.303 @@ -355,19 +355,19 @@ 8.304 <sect2> 8.305 <title>Abortire un commit</title> 8.306 8.307 - <para id="x_54">Se decidete di non voler eseguire l'inserimento mentre state scrivendo il messaggio di commit, vi basta uscire dal vostro editor senza salvare il file che contiene il messaggio. Questo eviterà che il repository e la directory di lavoro vengano alterati in alcun modo.</para> 8.308 + <para id="x_54">Se decidete di non voler eseguire l’inserimento mentre state scrivendo il messaggio di commit, vi basta uscire dal vostro editor senza salvare il file che contiene il messaggio. Questo eviterà che il repository e la directory di lavoro vengano alterati in alcun modo.</para> 8.309 </sect2> 8.310 8.311 <sect2> 8.312 <title>Ammirare la nostra nuova opera</title> 8.313 8.314 - <para id="x_56">Una volta che abbiamo terminato l'inserimento, possiamo usare il comando <command role="hg-cmd">hg tip</command> per visualizzare il changeset che abbiamo appena creato. Questo comando produce una stampa identica a quella del comando <command role="hg-cmd">hg log</command>, ma mostra solamente la revisione più recente nel repository.</para> 8.315 + <para id="x_56">Una volta che abbiamo terminato l’inserimento, possiamo usare il comando <command role="hg-cmd">hg tip</command> per visualizzare il changeset che abbiamo appena creato. Questo comando produce una stampa identica a quella del comando <command role="hg-cmd">hg log</command>, ma mostra solamente la revisione più recente nel repository.</para> 8.316 8.317 &interaction.tour.tip; 8.318 8.319 <para id="x_57">Ci riferiremo alla revisione più recente nel repository come alla <emphasis>revisione di punta</emphasis>, o semplicemente la <emphasis>punta</emphasis>.</para> 8.320 8.321 - <para id="x_684">Notate che il comando <command role="hg-cmd">hg tip</command> accetta molte delle stesse opzioni viste per <command role="hg-cmd">hg log</command>, quindi l'opzione <option role="hg-opt-global">-v</option> nell'esempio precedente chiede al comando di <quote>essere verboso</quote> e l'opzione <option role="hg-opt-tip">-p</option> specifica di <quote>stampare una patch</quote>. L'uso di <option role="hg-opt-tip">-p</option> per stampare le patch è un altro esempio della denominazione consistente che avevamo menzionato in precedenza.</para> 8.322 + <para id="x_684">Notate che il comando <command role="hg-cmd">hg tip</command> accetta molte delle stesse opzioni viste per <command role="hg-cmd">hg log</command>, quindi l’opzione <option role="hg-opt-global">-v</option> nell’esempio precedente chiede al comando di <quote>essere verboso</quote> e l’opzione <option role="hg-opt-tip">-p</option> specifica di <quote>stampare una patch</quote>. L’uso di <option role="hg-opt-tip">-p</option> per stampare le patch è un altro esempio della denominazione consistente che avevamo menzionato in precedenza.</para> 8.323 </sect2> 8.324 </sect1> 8.325 8.326 @@ -383,37 +383,37 @@ 8.327 8.328 &interaction.tour.clone-pull; 8.329 8.330 - <para id="x_5a">Useremo il comando <command role="hg-cmd">hg pull</command> per propagare i cambiamenti dal repository <filename class="directory">mio-hello</filename> al repository <filename class="directory">hello-estrazione</filename>. Tuttavia, estrarre alla cieca cambiamenti sconosciuti da un repository è una prospettiva che può incutere qualche timore. Mercurial fornisce il comando <command role="hg-cmd">hg incoming</command> proprio allo scopo di elencare quali cambiamenti <emphasis>verrebbero</emphasis> estratti dal repository senza effettivamente procedere con l'operazione.</para> 8.331 + <para id="x_5a">Useremo il comando <command role="hg-cmd">hg pull</command> per propagare i cambiamenti dal repository <filename class="directory">mio-hello</filename> al repository <filename class="directory">hello-estrazione</filename>. Tuttavia, estrarre alla cieca cambiamenti sconosciuti da un repository è una prospettiva che può incutere qualche timore. Mercurial fornisce il comando <command role="hg-cmd">hg incoming</command> proprio allo scopo di elencare quali cambiamenti <emphasis>verrebbero</emphasis> estratti dal repository senza effettivamente procedere con l’operazione.</para> 8.332 8.333 &interaction.tour.incoming; 8.334 8.335 - <para id="x_5c">Propagare i cambiamenti in un repository è semplicemente questione di eseguire il comando <command role="hg-cmd">hg pull</command>, dicendogli opzionalmente da quale repository compiere l'estrazione.</para> 8.336 + <para id="x_5c">Propagare i cambiamenti in un repository è semplicemente questione di eseguire il comando <command role="hg-cmd">hg pull</command>, dicendogli opzionalmente da quale repository compiere l’estrazione.</para> 8.337 8.338 &interaction.tour.pull; 8.339 8.340 - <para id="x_5d">Come potete vedere se confrontate il risultato di <command role="hg-cmd">hg tip</command> prima e dopo, abbiamo propagato con successo i cambiamenti nel nostro repository. Tuttavia, Mercurial separa l'operazione di estrazione dei cambiamenti da quella di aggiornamento della directory di lavoro. Rimane ancora un passo da fare prima di poter vedere i cambiamenti appena estratti comparire nella directory di lavoro.</para> 8.341 + <para id="x_5d">Come potete vedere se confrontate il risultato di <command role="hg-cmd">hg tip</command> prima e dopo, abbiamo propagato con successo i cambiamenti nel nostro repository. Tuttavia, Mercurial separa l’operazione di estrazione dei cambiamenti da quella di aggiornamento della directory di lavoro. Rimane ancora un passo da fare prima di poter vedere i cambiamenti appena estratti comparire nella directory di lavoro.</para> 8.342 8.343 <tip> 8.344 <title>Estrarre cambiamenti specifici</title> 8.345 8.346 - <para id="x_5b">È possibile che, a causa del ritardo tra l'esecuzione di <command role="hg-cmd">hg incoming</command> e <command role="hg-cmd">hg pull</command>, non riusciate vedere tutti i changeset che verranno prelevati dall'altro repository. Supponete di voler estrarre cambiamenti da un repository che si trovi in rete da qualche parte. Mentre state osservando il risultato di <command role="hg-cmd">hg incoming</command>, ma prima che riusciate a estrarre quei cambiamenti, qualcuno potrebbe aver inserito qualcosa nel repository remoto. Questo significa che è possibile estrarre più cambiamenti di quelil esaminati tramite <command role="hg-cmd">hg incoming</command>.</para> 8.347 - 8.348 - <para id="x_718">Se volete estrarre solamente quei particolari cambiamenti che sono stati elencati da <command role="hg-cmd">hg incoming</command>, o avete qualche altra ragione per estrarre un sottoinsieme dei cambiamenti, è sufficiente utilizzare l'identificatore di changeset del cambiamento che volete estrarre, e.g. <command>hg pull -r7e95bb</command>.</para> 8.349 + <para id="x_5b">È possibile che, a causa del ritardo tra l’esecuzione di <command role="hg-cmd">hg incoming</command> e <command role="hg-cmd">hg pull</command>, non riusciate vedere tutti i changeset che verranno prelevati dall’altro repository. Supponete di voler estrarre cambiamenti da un repository che si trovi in rete da qualche parte. Mentre state osservando il risultato di <command role="hg-cmd">hg incoming</command>, ma prima che riusciate a estrarre quei cambiamenti, qualcuno potrebbe aver inserito qualcosa nel repository remoto. Questo significa che è possibile estrarre più cambiamenti di quelil esaminati tramite <command role="hg-cmd">hg incoming</command>.</para> 8.350 + 8.351 + <para id="x_718">Se volete estrarre solamente quei particolari cambiamenti che sono stati elencati da <command role="hg-cmd">hg incoming</command>, o avete qualche altra ragione per estrarre un sottoinsieme dei cambiamenti, è sufficiente utilizzare l’identificatore di changeset del cambiamento che volete estrarre, e.g. <command>hg pull -r7e95bb</command>.</para> 8.352 </tip> 8.353 </sect2> 8.354 8.355 <sect2> 8.356 <title>Aggiornare la directory di lavoro</title> 8.357 8.358 - <para id="x_5e">Finora abbiamo glissato sulla relazione tra il repository e la sua directory di lavoro. Il comando <command role="hg-cmd">hg pull</command> che abbiamo eseguito nella <xref linkend="sec:tour:pull"/> ha propagato i cambiamenti nel repository ma, se controlliamo, non c'è alcuna traccia di quei cambiamenti nella directory di lavoro. Questo accade perché il comportamento predefinito di <command role="hg-cmd">hg pull</command> prevede di non modificare la directory di lavoro. Per fare questo, dobbiamo invece usare il comando <command role="hg-cmd">hg update</command>.</para> 8.359 + <para id="x_5e">Finora abbiamo glissato sulla relazione tra il repository e la sua directory di lavoro. Il comando <command role="hg-cmd">hg pull</command> che abbiamo eseguito nella <xref linkend="sec:tour:pull"/> ha propagato i cambiamenti nel repository ma, se controlliamo, non c’è alcuna traccia di quei cambiamenti nella directory di lavoro. Questo accade perché il comportamento predefinito di <command role="hg-cmd">hg pull</command> prevede di non modificare la directory di lavoro. Per fare questo, dobbiamo invece usare il comando <command role="hg-cmd">hg update</command>.</para> 8.360 8.361 &interaction.tour.update; 8.362 8.363 - <para id="x_5f">Potrebbe sembrare un po' strano che <command role="hg-cmd">hg pull</command> non aggiorni automaticamente la directory di lavoro, ma c'è una buona ragione per questo: <command role="hg-cmd">hg update</command> è in grado di aggiornare la directory di lavoro allo stato in cui era in <emphasis>qualsiasi revisione</emphasis> contenuta nella cronologia del repository. Se la vostra directory di lavoro fosse stata aggiornata a una vecchia revisione&emdash;per cercare l'origine di un bug, diciamo&emdash;potreste non essere terribilmente contenti di vedere il comando <command role="hg-cmd">hg pull</command> da voi eseguito aggiornare automaticamente la directory di lavoro a una nuova revisione.</para> 8.364 - 8.365 - <para id="x_60">Dato che la sequenza di estrazione e aggiornamento è così comune, Mercurial vi permette di combinare le due operazioni passando l'opzione <option role="hg-opt-pull">-u</option> al comando <command role="hg-cmd">hg pull</command>.</para> 8.366 - 8.367 - <para id="x_61">Se tornate indietro alla <xref linkend="sec:tour:pull"/> e osservate il testo visualizzato dal comando <command role="hg-cmd">hg pull</command> eseguito senza l'opzione <option role="hg-opt-pull">-u</option>, potete vedere che contiene un promemoria utile a ricordarci che dobbiamo effettuare un passo esplicito per aggiornare la directory di lavoro.</para> 8.368 + <para id="x_5f">Potrebbe sembrare un po’ strano che <command role="hg-cmd">hg pull</command> non aggiorni automaticamente la directory di lavoro, ma c’è una buona ragione per questo: <command role="hg-cmd">hg update</command> è in grado di aggiornare la directory di lavoro allo stato in cui era in <emphasis>qualsiasi revisione</emphasis> contenuta nella cronologia del repository. Se la vostra directory di lavoro fosse stata aggiornata a una vecchia revisione&emdash;per cercare l’origine di un bug, diciamo&emdash;potreste non essere terribilmente contenti di vedere il comando <command role="hg-cmd">hg pull</command> da voi eseguito aggiornare automaticamente la directory di lavoro a una nuova revisione.</para> 8.369 + 8.370 + <para id="x_60">Dato che la sequenza di estrazione e aggiornamento è così comune, Mercurial vi permette di combinare le due operazioni passando l’opzione <option role="hg-opt-pull">-u</option> al comando <command role="hg-cmd">hg pull</command>.</para> 8.371 + 8.372 + <para id="x_61">Se tornate indietro alla <xref linkend="sec:tour:pull"/> e osservate il testo visualizzato dal comando <command role="hg-cmd">hg pull</command> eseguito senza l’opzione <option role="hg-opt-pull">-u</option>, potete vedere che contiene un promemoria utile a ricordarci che dobbiamo effettuare un passo esplicito per aggiornare la directory di lavoro.</para> 8.373 8.374 <para id="x_62">Per scoprire a quale revisione è aggiornata la directory di lavoro, usate il comando <command role="hg-cmd">hg parents</command>.</para> 8.375 8.376 @@ -426,13 +426,13 @@ 8.377 8.378 &interaction.tour.older; 8.379 8.380 - <para id="x_65">Se omettete una revisione esplicita, <command role="hg-cmd">hg update</command> effettuerà l'aggiornamento alla revisione più recente (la revisione di punta), come mostrato nella seconda invocazione di <command role="hg-cmd">hg update</command> nell'esempio precedente.</para> 8.381 + <para id="x_65">Se omettete una revisione esplicita, <command role="hg-cmd">hg update</command> effettuerà l’aggiornamento alla revisione più recente (la revisione di punta), come mostrato nella seconda invocazione di <command role="hg-cmd">hg update</command> nell’esempio precedente.</para> 8.382 </sect2> 8.383 8.384 <sect2> 8.385 <title>Pubblicare i cambiamenti in un altro repository</title> 8.386 8.387 - <para id="x_66">Mercurial ci permette di trasmettere i nostri cambiamenti dal repository in cui ci troviamo verso un altro repository. Come per l'esempio del comando <command role="hg-cmd">hg pull</command> appena illustrato, creeremo un repository temporaneo a cui trasmettere i nostri cambiamenti.</para> 8.388 + <para id="x_66">Mercurial ci permette di trasmettere i nostri cambiamenti dal repository in cui ci troviamo verso un altro repository. Come per l’esempio del comando <command role="hg-cmd">hg pull</command> appena illustrato, creeremo un repository temporaneo a cui trasmettere i nostri cambiamenti.</para> 8.389 8.390 &interaction.tour.clone-push; 8.391 8.392 @@ -440,11 +440,11 @@ 8.393 8.394 &interaction.tour.outgoing; 8.395 8.396 - <para id="x_68">E il comando <command role="hg-cmd">hg push</command> esegue l'effettiva trasmissione.</para> 8.397 + <para id="x_68">E il comando <command role="hg-cmd">hg push</command> esegue l’effettiva trasmissione.</para> 8.398 8.399 &interaction.tour.push; 8.400 8.401 - <para id="x_69">Allo stesso modo di <command role="hg-cmd">hg pull</command>, il comando <command role="hg-cmd">hg push</command> non aggiorna la directory di lavoro nel repository verso il quale sta trasmettendo i cambiamenti. Diversamente da <command role="hg-cmd">hg pull</command>, <command role="hg-cmd">hg push</command> non fornisce un'opzione <literal>-u</literal> che aggiorni la directory di lavoro dell'altro repository. Questa asimmetria è voluta: il repository verso il quale stiamo trasmettendo potrebbe essere su un server remoto e condiviso da molte persone. Se dovessimo aggiornare la sua directory di lavoro mentre altre persone ci stanno lavorando, il loro lavoro sarebbe rovinato.</para> 8.402 + <para id="x_69">Allo stesso modo di <command role="hg-cmd">hg pull</command>, il comando <command role="hg-cmd">hg push</command> non aggiorna la directory di lavoro nel repository verso il quale sta trasmettendo i cambiamenti. Diversamente da <command role="hg-cmd">hg pull</command>, <command role="hg-cmd">hg push</command> non fornisce un’opzione <literal>-u</literal> che aggiorni la directory di lavoro dell’altro repository. Questa asimmetria è voluta: il repository verso il quale stiamo trasmettendo potrebbe essere su un server remoto e condiviso da molte persone. Se dovessimo aggiornare la sua directory di lavoro mentre altre persone ci stanno lavorando, il loro lavoro sarebbe rovinato.</para> 8.403 8.404 <para id="x_6a">Cosa succede se proviamo a estrarre o trasmettere cambiamenti che il repository contiene già? Nulla di particolarmente eccitante.</para> 8.405 8.406 @@ -454,7 +454,7 @@ 8.407 <sect2> 8.408 <title>Ubicazioni predefinite</title> 8.409 8.410 - <para id="x_719">Quando cloniamo un repository, Mercurial registra l'ubicazione del repository che abbiamo clonato nel file <filename>.hg/hgrc</filename> del nuovo repository. I comandi <command>hg pull</command> e <command>hg push</command> useranno quella ubicazione come impostazione predefinita quando vengono invocati senza fornire esplicitamente un percorso. Anche i comandi <command>hg incoming</command> e <command>hg outgoing</command> si comporteranno allo stesso modo.</para> 8.411 + <para id="x_719">Quando cloniamo un repository, Mercurial registra l’ubicazione del repository che abbiamo clonato nel file <filename>.hg/hgrc</filename> del nuovo repository. I comandi <command>hg pull</command> e <command>hg push</command> useranno quella ubicazione come impostazione predefinita quando vengono invocati senza fornire esplicitamente un percorso. Anche i comandi <command>hg incoming</command> e <command>hg outgoing</command> si comporteranno allo stesso modo.</para> 8.412 8.413 <para id="x_71a">Se aprite il file <filename>.hg/hgrc</filename> di un repository con un editor di testo, vedrete contenuti simili ai seguenti.</para> 8.414
9.1 --- a/it/ch03-tour-merge.xml Sat Aug 22 21:01:56 2009 +0200 9.2 +++ b/it/ch03-tour-merge.xml Sat Aug 22 21:55:05 2009 +0200 9.3 @@ -2,7 +2,7 @@ 9.4 <?dbhtml filename="una-panoramica-di-mercurial-le-unioni.html"?> 9.5 <title>Una panoramica di Mercurial: le unioni</title> 9.6 9.7 - <para id="x_338">Finora abbiamo parlato di come clonare un repository, effettuare modifiche in un repository ed estrarre o trasmettere cambiamenti da un repository all'altro. Il nostro prossimo passo sarà quello di <emphasis>unire</emphasis> le modifiche provenienti da repository separati.</para> 9.8 + <para id="x_338">Finora abbiamo parlato di come clonare un repository, effettuare modifiche in un repository ed estrarre o trasmettere cambiamenti da un repository all’altro. Il nostro prossimo passo sarà quello di <emphasis>unire</emphasis> le modifiche provenienti da repository separati.</para> 9.9 9.10 <sect1> 9.11 <title>Unire flussi di lavoro</title> 9.12 @@ -13,7 +13,7 @@ 9.13 <para id="x_33a">Alice e Bruno hanno entrambi 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 funzione nel proprio. Entrambi vogliono che il repository condiviso contenga sia la correzione del bug sia la nuova funzione.</para> 9.14 </listitem> 9.15 <listitem> 9.16 - <para id="x_33b">Cinzia lavora frequentemente su più attività differenti alla volta per un singolo progetto, 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.</para> 9.17 + <para id="x_33b">Cinzia lavora frequentemente su più attività differenti alla volta per un singolo progetto, 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.</para> 9.18 </listitem> 9.19 </itemizedlist> 9.20 9.21 @@ -21,11 +21,11 @@ 9.22 9.23 &interaction.tour.merge.clone; 9.24 9.25 - <para id="x_33d">Ora abbiamo due copie di <filename>hello.c</filename> con contenuti differenti e le cronologie dei due repository divergono l'una dall'altra, come illustrato nella <xref linkend="fig:tour-merge:sep-repos"/>. Ecco la copia del nostro file presente nel primo repository.</para> 9.26 + <para id="x_33d">Ora abbiamo due copie di <filename>hello.c</filename> con contenuti differenti e le cronologie dei due repository divergono l’una dall’altra, come illustrato nella <xref linkend="fig:tour-merge:sep-repos"/>. Ecco la copia del nostro file presente nel primo repository.</para> 9.27 9.28 &interaction.tour.merge.cat1; 9.29 9.30 - <para id="x_722">Ed ecco la versione leggermente differente contenuta nell'altro repository.</para> 9.31 + <para id="x_722">Ed ecco la versione leggermente differente contenuta nell’altro repository.</para> 9.32 9.33 &interaction.tour.merge.cat2; 9.34 9.35 @@ -37,7 +37,7 @@ 9.36 </mediaobject> 9.37 </figure> 9.38 9.39 - <para id="x_33f">Sappiamo già che l'estrazione dei cambiamenti dal nostro repository <filename class="directory">mio-hello</filename> non avrà alcun effetto sulla directory di lavoro.</para> 9.40 + <para id="x_33f">Sappiamo già che l’estrazione dei cambiamenti dal nostro repository <filename class="directory">mio-hello</filename> non avrà alcun effetto sulla directory di lavoro.</para> 9.41 9.42 &interaction.tour.merge.pull; 9.43 9.44 @@ -46,7 +46,7 @@ 9.45 <sect2> 9.46 <title>Le teste di un repository</title> 9.47 9.48 - <para id="x_341">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.</para> 9.49 + <para id="x_341">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.</para> 9.50 9.51 <figure id="fig:tour-merge:pull"> 9.52 <title>I contenuti del repository dopo aver propagato i cambiamenti da <filename class="directory">mio-hello</filename> a <filename class="directory">mio-nuovo-hello</filename></title> 9.53 @@ -58,33 +58,33 @@ 9.54 </mediaobject> 9.55 </figure> 9.56 9.57 - <para id="x_343">Dalla <xref linkend="fig:tour-merge:pull"/>, potete vedere l'effetto della propagazione dei cambiamenti dal repository <filename class="directory">mio-hello</filename> al repository <filename class="directory">mio-nuovo-hello</filename>. La cronologia già presente in <filename class="directory">mio-nuovo-hello</filename> non viene toccata, ma al repository è stata aggiunta una nuova revisione. Riferendoci alla <xref linkend="fig:tour-merge:sep-repos"/>, possiamo vedere che nel nuovo repository l'<emphasis>identificatore di changeset</emphasis> rimane lo stesso, ma il <emphasis>numero di revisione</emphasis> è 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 <command role="hg-cmd">hg heads</command>.</para> 9.58 + <para id="x_343">Dalla <xref linkend="fig:tour-merge:pull"/>, potete vedere l’effetto della propagazione dei cambiamenti dal repository <filename class="directory">mio-hello</filename> al repository <filename class="directory">mio-nuovo-hello</filename>. La cronologia già presente in <filename class="directory">mio-nuovo-hello</filename> non viene toccata, ma al repository è stata aggiunta una nuova revisione. Riferendoci alla <xref linkend="fig:tour-merge:sep-repos"/>, possiamo vedere che nel nuovo repository l’<emphasis>identificatore di changeset</emphasis> rimane lo stesso, ma il <emphasis>numero di revisione</emphasis> è 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 <command role="hg-cmd">hg heads</command>.</para> 9.59 9.60 &interaction.tour.merge.heads; 9.61 </sect2> 9.62 9.63 <sect2> 9.64 - <title>Effettuare l'unione</title> 9.65 + <title>Effettuare l’unione</title> 9.66 9.67 <para id="x_344">Cosa succede se proviamo a usare normalmente il comando <command role="hg-cmd">hg update</command> per aggiornare la directory di lavoro alla nuova punta?</para> 9.68 9.69 &interaction.tour.merge.update; 9.70 9.71 - <para id="x_345">Mercurial ci sta dicendo che <command role="hg-cmd">hg update</command> non è in grado di effettuare un'unione. Il comando non aggiornerà la directory di lavoro se pensa che potremmo voler eseguire un'unione, a meno che non gli chiediamo esplicitamente di farlo. (Incidentalmente, forzare l'aggiornamento tramite <command>hg update -C</command> provocherebbe la perdita di tutte le modifiche contenute nella directory di lavoro e non ancora inserite nel repository.)</para> 9.72 - 9.73 - <para id="x_723">Per avviare un'unione tra le due teste, usiamo il comando <command role="hg-cmd">hg merge</command>.</para> 9.74 + <para id="x_345">Mercurial ci sta dicendo che <command role="hg-cmd">hg update</command> non è in grado di effettuare un’unione. Il comando non aggiornerà la directory di lavoro se pensa che potremmo voler eseguire un’unione, a meno che non gli chiediamo esplicitamente di farlo. (Incidentalmente, forzare l’aggiornamento tramite <command>hg update -C</command> provocherebbe la perdita di tutte le modifiche contenute nella directory di lavoro e non ancora inserite nel repository.)</para> 9.75 + 9.76 + <para id="x_723">Per avviare un’unione tra le due teste, usiamo il comando <command role="hg-cmd">hg merge</command>.</para> 9.77 9.78 &interaction.tour.merge.merge; 9.79 9.80 - <para id="x_347">Il contenuto del file <filename>hello.c</filename> viene sistemato. L'operazione aggiorna la directory di lavoro in modo che contenga le modifiche provenienti da <emphasis>entrambe</emphasis> le teste, cosa che si riflette sia nell'elenco visualizzato dal comando <command role="hg-cmd">hg parents</command> sia nei contenuti del file <filename>hello.c</filename>.</para> 9.81 + <para id="x_347">Il contenuto del file <filename>hello.c</filename> viene sistemato. L’operazione aggiorna la directory di lavoro in modo che contenga le modifiche provenienti da <emphasis>entrambe</emphasis> le teste, cosa che si riflette sia nell’elenco visualizzato dal comando <command role="hg-cmd">hg parents</command> sia nei contenuti del file <filename>hello.c</filename>.</para> 9.82 9.83 &interaction.tour.merge.parents; 9.84 </sect2> 9.85 9.86 <sect2> 9.87 - <title>Inserire i risultati dell'unione nel repository</title> 9.88 - 9.89 - <para id="x_348">Ogni volta che eseguiamo un'unione, il comando <command role="hg-cmd">hg parents</command> mostrerà due genitori fino a quando non invocheremo <command role="hg-cmd">hg commit</command> per inserire i risultati dell'unione nel repository.</para> 9.90 + <title>Inserire i risultati dell’unione nel repository</title> 9.91 + 9.92 + <para id="x_348">Ogni volta che eseguiamo un’unione, il comando <command role="hg-cmd">hg parents</command> mostrerà due genitori fino a quando non invocheremo <command role="hg-cmd">hg commit</command> per inserire i risultati dell’unione nel repository.</para> 9.93 9.94 &interaction.tour.merge.commit; 9.95 9.96 @@ -92,10 +92,10 @@ 9.97 9.98 &interaction.tour.merge.tip; 9.99 9.100 - <para id="x_34a">Nella <xref linkend="fig:tour-merge:merge"/>, 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.</para> 9.101 + <para id="x_34a">Nella <xref linkend="fig:tour-merge:merge"/>, 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.</para> 9.102 9.103 <figure id="fig:tour-merge:merge"> 9.104 - <title>Lo stato della directory di lavoro e del repository durante l'unione e dopo l'inserimento</title> 9.105 + <title>Lo stato della directory di lavoro e del repository durante l’unione e dopo l’inserimento</title> 9.106 <mediaobject> 9.107 <imageobject> 9.108 <imagedata fileref="figs/tour-merge-merge.png"/> 9.109 @@ -104,7 +104,7 @@ 9.110 </mediaobject> 9.111 </figure> 9.112 9.113 - <para id="x_69c">Talvolta si dice che un'unione è composta da due <emphasis>parti</emphasis>: la parte sinistra è costituita dal primo genitore elencato da <command role="hg-cmd">hg parents</command> 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.</para> 9.114 + <para id="x_69c">Talvolta si dice che un’unione è composta da due <emphasis>parti</emphasis>: la parte sinistra è costituita dal primo genitore elencato da <command role="hg-cmd">hg parents</command> 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.</para> 9.115 </sect2> 9.116 </sect1> 9.117 9.118 @@ -125,7 +125,7 @@ 9.119 9.120 <para id="x_34e">Mercurial non è dotato di alcuna funzione 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 a richiamare diversi strumenti grafici di unione.</para> 9.121 9.122 - <para id="x_34f">È anche possibile far eseguire a Mercurial uno specifico programma, impostando il valore della variable d'ambiente <envar>HGMERGE</envar> al nome del vostro programma preferito.</para> 9.123 + <para id="x_34f">È anche possibile far eseguire a Mercurial uno specifico programma, impostando il valore della variable d’ambiente <envar>HGMERGE</envar> al nome del vostro programma preferito.</para> 9.124 9.125 <sect2> 9.126 <title>Usare uno strumento grafico di unione</title> 9.127 @@ -138,7 +138,7 @@ 9.128 </listitem> 9.129 <listitem><para id="x_353">a destra troviamo la <quote>loro</quote> versione del file, quella che proviene dal changeset che stiamo cercando di incorporare.</para> 9.130 </listitem></itemizedlist> 9.131 - <para id="x_354">Il pannello sottostante contiene il <emphasis>risultato</emphasis> corrente dell'unione. Il nostro compito è quello di sostituire tutto il testo in rosso, che indica conflitti irrisolti, con una qualche combinazione ragionevole della <quote>nostra</quote> e della <quote>loro</quote> versione del file.</para> 9.132 + <para id="x_354">Il pannello sottostante contiene il <emphasis>risultato</emphasis> corrente dell’unione. Il nostro compito è quello di sostituire tutto il testo in rosso, che indica conflitti irrisolti, con una qualche combinazione ragionevole della <quote>nostra</quote> e della <quote>loro</quote> versione del file.</para> 9.133 9.134 <para id="x_355">Tutti e quattro questi pannelli sono <emphasis>collegati tra loro</emphasis>: se ci spostiamo in verticale o in orizzontale in un pannello qualsiasi, gli altri vengono aggiornati per mostrare le sezioni corrispondenti dei rispettivi file.</para> 9.135 9.136 @@ -155,7 +155,7 @@ 9.137 9.138 <para id="x_357">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.</para> 9.139 9.140 - <para id="x_358">Esistono <emphasis>molti</emphasis> strumenti per gestire 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).</para> 9.141 + <para id="x_358">Esistono <emphasis>molti</emphasis> strumenti per gestire 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).</para> 9.142 </sect2> 9.143 9.144 <sect2> 9.145 @@ -169,7 +169,7 @@ 9.146 9.147 &interaction.tour-merge-conflict.cousin; 9.148 9.149 - <para id="x_35b">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 contenenti attività isolate, risolvendo i conflitti incontrati nel corso di questo processo.)</para> 9.150 + <para id="x_35b">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 contenenti attività isolate, risolvendo i conflitti incontrati nel corso di questo processo.)</para> 9.151 9.152 &interaction.tour-merge-conflict.son; 9.153 9.154 @@ -177,20 +177,20 @@ 9.155 9.156 &interaction.tour-merge-conflict.pull; 9.157 9.158 - <para id="x_35d">In questo esempio, imposterò la variabile d'ambiente <envar>HGMERGE</envar> per dire a Mercurial di usare il comando non interattivo <command>merge</command>. Questo comando è incluso in molti sistemi di tipo Unix. (Se state seguendo questo esempio sul vostro computer, non preoccupatevi di impostare <envar>HGMERGE</envar>. Vi verrà presentata un'applicazione grafica da utilizzare per unire i file, che è un'alternativa di gran lunga preferibile.)</para> 9.159 + <para id="x_35d">In questo esempio, imposterò la variabile d’ambiente <envar>HGMERGE</envar> per dire a Mercurial di usare il comando non interattivo <command>merge</command>. Questo comando è incluso in molti sistemi di tipo Unix. (Se state seguendo questo esempio sul vostro computer, non preoccupatevi di impostare <envar>HGMERGE</envar>. Vi verrà presentata un’applicazione grafica da utilizzare per unire i file, che è un’alternativa di gran lunga preferibile.)</para> 9.160 9.161 &interaction.tour-merge-conflict.merge; 9.162 9.163 - <para id="x_35f">Dato che <command>merge</command> non riesce a risolvere il conflitto tra i cambiamenti, inserisce alcuni <emphasis>marcatori di unione</emphasis> 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.</para> 9.164 - 9.165 - <para id="x_360">Dal modo in cui <command>merge</command> 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.</para> 9.166 - 9.167 - <para id="x_361">Nel caso in cui l'unione automatica o manuale fallisca, nulla ci impedisce di <quote>correggere</quote> i file interessati per conto nostro, per poi inserire i risultati della nostra unione nel repository:</para> 9.168 + <para id="x_35f">Dato che <command>merge</command> non riesce a risolvere il conflitto tra i cambiamenti, inserisce alcuni <emphasis>marcatori di unione</emphasis> 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.</para> 9.169 + 9.170 + <para id="x_360">Dal modo in cui <command>merge</command> 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.</para> 9.171 + 9.172 + <para id="x_361">Nel caso in cui l’unione automatica o manuale fallisca, nulla ci impedisce di <quote>correggere</quote> i file interessati per conto nostro, per poi inserire i risultati della nostra unione nel repository:</para> 9.173 9.174 &interaction.tour-merge-conflict.commit; 9.175 9.176 <note> 9.177 - <title>Dov'è il comando <command>hg resolve</command>?</title> 9.178 + <title>Dov’è il comando <command>hg resolve</command>?</title> 9.179 9.180 <para id="x_724">Il comando <command>hg resolve</command> è stato introdotto nella verisone 1.1 di Mercurial rilasciata nel dicembre 2008. Se state usando una versione più vecchia (eseguite <command>hg version</command> 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.</para> 9.181 </note> 9.182 @@ -204,31 +204,31 @@ 9.183 <programlisting>hg pull -u 9.184 hg merge 9.185 hg commit -m 'Incorporati i cambiamenti remoti'</programlisting> 9.186 - <para id="x_363">Nel caso dell'inserimento finale, avete anche bisogno di includere un messaggio di commit, che sarà quasi sempre composto da testo <quote>standard</quote> non particolarmente interessante.</para> 9.187 - 9.188 - <para id="x_364">Se fosse possibile, sarebbe comodo ridurre il numero di passi necessari. In effetti, Mercurial viene distribuito con un'estensione chiamata <literal role="hg-ext">fetch</literal> pensata proprio per questo scopo.</para> 9.189 + <para id="x_363">Nel caso dell’inserimento finale, avete anche bisogno di includere un messaggio di commit, che sarà quasi sempre composto da testo <quote>standard</quote> non particolarmente interessante.</para> 9.190 + 9.191 + <para id="x_364">Se fosse possibile, sarebbe comodo ridurre il numero di passi necessari. In effetti, Mercurial viene distribuito con un’estensione chiamata <literal role="hg-ext">fetch</literal> pensata proprio per questo scopo.</para> 9.192 9.193 <para id="x_365">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 riga di comando, mentre altre lavorano <quote>dietro le quinte</quote>, per esempio accrescendo la funzionalità della modalità server predefinita di Mercurial.</para> 9.194 9.195 - <para id="x_366">L'estensione <literal role="hg-ext">fetch</literal> aggiunge un nuovo comando chiamato, naturalmente, <command role="hg-cmd">hg fetch</command>. Questa estensione agisce come una combinazione di <command role="hg-cmd">hg pull -u</command>, <command role="hg-cmd">hg merge</command> e <command role="hg-cmd">hg commit</command>. 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.</para> 9.196 - 9.197 - <para id="x_367">Abilitare l'estensione <literal role="hg-ext">fetch</literal> è facile. Aprite il file <filename role="special">.hgrc</filename> che si trova nella vostra directory personale e andate alla sezione <literal role="rc-extensions">extensions</literal> (oppure createla se non esiste già). Poi aggiungete una riga che contenga semplicemente <quote><literal>fetch=</literal></quote>.</para> 9.198 + <para id="x_366">L’estensione <literal role="hg-ext">fetch</literal> aggiunge un nuovo comando chiamato, naturalmente, <command role="hg-cmd">hg fetch</command>. Questa estensione agisce come una combinazione di <command role="hg-cmd">hg pull -u</command>, <command role="hg-cmd">hg merge</command> e <command role="hg-cmd">hg commit</command>. 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.</para> 9.199 + 9.200 + <para id="x_367">Abilitare l’estensione <literal role="hg-ext">fetch</literal> è facile. Aprite il file <filename role="special">.hgrc</filename> che si trova nella vostra directory personale e andate alla sezione <literal role="rc-extensions">extensions</literal> (oppure createla se non esiste già). Poi aggiungete una riga che contenga semplicemente <quote><literal>fetch=</literal></quote>.</para> 9.201 9.202 <programlisting>[extensions] 9.203 fetch =</programlisting> 9.204 9.205 - <para id="x_368">(Normalmente, la parte a destra del simbolo <quote><literal>=</literal></quote> indicherebbe dove trovare l'estensione, ma dato che l'estensione <literal role="hg-ext">fetch</literal> è compresa nella distribuzione standard, Mercurial sa già dove andarla a cercare.)</para> 9.206 + <para id="x_368">(Normalmente, la parte a destra del simbolo <quote><literal>=</literal></quote> indicherebbe dove trovare l’estensione, ma dato che l’estensione <literal role="hg-ext">fetch</literal> è compresa nella distribuzione standard, Mercurial sa già dove andarla a cercare.)</para> 9.207 </sect1> 9.208 9.209 <sect1> 9.210 <title>Rinominare, copiare e unire</title> 9.211 9.212 - <para id="x_729">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.</para> 9.213 + <para id="x_729">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.</para> 9.214 9.215 <para id="x_72a">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 <command>hg rename</command><footnote> 9.216 <para id="x_72b">Se siete utenti Unix, sarete felici di sapere che il comando <command>hg rename</command> si può abbreviare in <command>hg mv</command>.</para> 9.217 - </footnote> per cambiare il nome del file, in modo che Mercurial possa comportarsi in maniera appropriata nel caso più tardi effettuassimo un'unione.</para> 9.218 - 9.219 - <para id="x_72c">Tratteremo l'uso di questi comandi in maniera più estesa nella <xref linkend="chap:daily.copy"/>.</para> 9.220 + </footnote> per cambiare il nome del file, in modo che Mercurial possa comportarsi in maniera appropriata nel caso più tardi effettuassimo un’unione.</para> 9.221 + 9.222 + <para id="x_72c">Tratteremo l’uso di questi comandi in maniera più estesa nella <xref linkend="chap:daily.copy"/>.</para> 9.223 </sect1> 9.224 </chapter>
10.1 --- a/it/ch04-concepts.xml Sat Aug 22 21:01:56 2009 +0200 10.2 +++ b/it/ch04-concepts.xml Sat Aug 22 21:55:05 2009 +0200 10.3 @@ -4,7 +4,7 @@ 10.4 10.5 <para id="x_2e8">Diversamente da molti sistemi di controllo di revisione, Mercurial è costruito sulla base di concetti abbastanza semplici da facilitare la comprensione del modo in cui il software funziona realmente. Conoscere questi dettagli non è certamente necessario, per cui potete tranquillamente saltare questo capitolo. Tuttavia, penso che otterrete di più dal software conoscendo il <quote>modello concettuale</quote> del suo funzionamento.</para> 10.6 10.7 - <para id="x_2e9">Essere in grado di capire quello che accade dietro le quinte mi dà una certa garanzia che Mercurial sia stato attentamente progettato per essere sia <emphasis>sicuro</emphasis> che <emphasis>efficiente</emphasis>. Analogamente, è importante che per me sia facile avere un'idea corretta di quello che il software sta facendo mentre svolgo un'attività di controllo di revisione, in modo da abbassare la probabilità di venire sorpreso dal suo comportamento.</para> 10.8 + <para id="x_2e9">Essere in grado di capire quello che accade dietro le quinte mi dà una certa garanzia che Mercurial sia stato attentamente progettato per essere sia <emphasis>sicuro</emphasis> che <emphasis>efficiente</emphasis>. Analogamente, è importante che per me sia facile avere un’idea corretta di quello che il software sta facendo mentre svolgo un’attività di controllo di revisione, in modo da abbassare la probabilità di venire sorpreso dal suo comportamento.</para> 10.9 10.10 <para id="x_2ea">Inizieremo questo capitolo parlando dei concetti chiave alla base della progettazione di Mercurial, poi proseguiremo discutendo alcuni dei dettagli più interessanti della sua implementazione.</para> 10.11 10.12 @@ -16,7 +16,7 @@ 10.13 10.14 <para id="x_2eb">Quando Mercurial tiene traccia delle modifiche a un file, memorizza la cronologia di quel file in un oggetto di metadati chiamato <emphasis>filelog</emphasis> (letteralmente, registro del file). Ogni voce in un filelog contiene informazioni sufficienti a ricostruire una revisione del file di cui tiene traccia. I filelog sono memorizzati come file nella directory <filename role="special" class="directory">.hg/store/data</filename>. Un filelog contiene due tipi di informazione: dati di revisione, più un indice per aiutare Mercurial a trovare una revisione in maniera efficiente.</para> 10.15 10.16 - <para id="x_2ec">Il filelog di un file di grandi dimensioni o che abbia una lunga cronologia viene memorizzato in due file separati per i dati (con un suffisso <quote><literal>.d</literal></quote>) e l'indice (con un suffisso <quote><literal>.i</literal></quote>). Per file di piccole dimensioni con una cronologia ridotta, i dati di revisione e l'indice vengono combinati in un singolo file <quote><literal>.i</literal></quote>. La corrispondenza tra un file nella directory di lavoro e il filelog che tiene traccia della sua cronologia nel repository è illustrata nella <xref 10.17 + <para id="x_2ec">Il filelog di un file di grandi dimensioni o che abbia una lunga cronologia viene memorizzato in due file separati per i dati (con un suffisso <quote><literal>.d</literal></quote>) e l’indice (con un suffisso <quote><literal>.i</literal></quote>). Per file di piccole dimensioni con una cronologia ridotta, i dati di revisione e l’indice vengono combinati in un singolo file <quote><literal>.i</literal></quote>. La corrispondenza tra un file nella directory di lavoro e il filelog che tiene traccia della sua cronologia nel repository è illustrata nella <xref 10.18 linkend="fig:concepts:filelog"/>.</para> 10.19 10.20 <figure id="fig:concepts:filelog"> 10.21 @@ -43,7 +43,7 @@ 10.22 <sect2> 10.23 <title>Relazioni tra le revisioni</title> 10.24 10.25 - <para id="x_2f0">Nell'ambito di un changelog, di un manifest, o di un filelog, ogni revisione mantiene un puntatore al suo genitore diretto (o ai suoi due genitori, se è una revisione di unione). Come ho già detto, esistono anche relazioni tra revisioni <emphasis>attraverso</emphasis> queste strutture, e tali relazioni sono di natura gerarchica.</para> 10.26 + <para id="x_2f0">Nell’ambito di un changelog, di un manifest, o di un filelog, ogni revisione mantiene un puntatore al suo genitore diretto (o ai suoi due genitori, se è una revisione di unione). Come ho già detto, esistono anche relazioni tra revisioni <emphasis>attraverso</emphasis> queste strutture, e tali relazioni sono di natura gerarchica.</para> 10.27 10.28 <para id="x_2f1">Per ogni changeset nel repository, esiste esattamente una revisione memorizzata nel changelog. Ogni revisione del changelog contiene un puntatore a una singola revisione del manifest. Una revisione del manifest include un puntatore a una singola revisione di ogni filelog registrato quando il changeset è stato creato. Queste relazioni sono illustrate nella <xref linkend="fig:concepts:metadata"/>.</para> 10.29 10.30 @@ -55,7 +55,7 @@ 10.31 </mediaobject> 10.32 </figure> 10.33 10.34 - <para id="x_2f3">Come mostrato in figura, <emphasis>non</emphasis> c'è una relazione <quote>uno a uno</quote> tra le revisioni nel changelog, nel manifest, o nel filelog. Se un file registrato da Mercurial non è cambiato tra due changeset, la voce per quel file nelle due revisioni del manifest punterà alla stessa revisione nel suo filelog<footnote> 10.35 + <para id="x_2f3">Come mostrato in figura, <emphasis>non</emphasis> c’è una relazione <quote>uno a uno</quote> tra le revisioni nel changelog, nel manifest, o nel filelog. Se un file registrato da Mercurial non è cambiato tra due changeset, la voce per quel file nelle due revisioni del manifest punterà alla stessa revisione nel suo filelog<footnote> 10.36 <para id="x_725">È possibile (anche se inusuale) che il manifest rimanga lo stesso tra due changeset, nel qual caso le voci del changelog per quei changeset punteranno alla stessa revisione del manifest.</para> 10.37 </footnote>.</para> 10.38 10.39 @@ -69,7 +69,7 @@ 10.40 <sect2> 10.41 <title>Memorizzazione efficiente</title> 10.42 10.43 - <para id="x_2f5">Il revlog permette di memorizzare le revisioni in maniera efficiente usando un meccanismo basato su differenze chiamate <emphasis>delta</emphasis>. Invece di registrare una copia completa di un file per ogni revisione, il revlog memorizza i cambiamenti necessari a trasformare una revisione più vecchia nella nuova revisione. Per molti tipi di file, queste delta sono tipicamente una frazione percentuale della dimensione di un'intera copia di un file.</para> 10.44 + <para id="x_2f5">Il revlog permette di memorizzare le revisioni in maniera efficiente usando un meccanismo basato su differenze chiamate <emphasis>delta</emphasis>. Invece di registrare una copia completa di un file per ogni revisione, il revlog memorizza i cambiamenti necessari a trasformare una revisione più vecchia nella nuova revisione. Per molti tipi di file, queste delta sono tipicamente una frazione percentuale della dimensione di un’intera copia di un file.</para> 10.45 10.46 <para id="x_2f6">Alcuni sistemi di controllo di revisione obsoleti possono lavorare solo con le delta di file di testo e sono costretti a memorizzare i file binari come copie complete o a codificarli in una rappresentazione testuale, entrambi approcci dispendiosi. Mercurial è in grado di gestire in maniera efficiente le delta di file con contenuti binari arbitrari, per cui non ha bisogno di trattare il testo in maniera speciale.</para> 10.47 10.48 @@ -79,7 +79,7 @@ 10.49 10.50 <para id="x_2f7">Mercurial si limita ad <emphasis>aggiungere</emphasis> dati alla fine di un file di revlog invece di modificarne una sezione dopo averlo memorizzato. Questo approccio è più robusto ed efficiente rispetto a sistemi che hanno bisogno di modificare o riscrivere i dati.</para> 10.51 10.52 - <para id="x_2f8">In più, Mercurial tratta ogni scrittura come parte di una <emphasis>transazione</emphasis> che può coinvolgere un qualsiasi numero di file. Una transazione è <emphasis>atomica</emphasis>: o l'intera transazione ha successo e i suoi effetti sono visibili in lettura in un unico passo, oppure l'operazione viene completamente annullata. Questa garanzia di atomicità significa che se state eseguendo due copie di Mercurial, una che sta leggendo dati e l'altra che sta scrivendo, la copia che agisce in lettura non vedrà mai un risultato parzialmente scritto che potrebbe confonderla.</para> 10.53 + <para id="x_2f8">In più, Mercurial tratta ogni scrittura come parte di una <emphasis>transazione</emphasis> che può coinvolgere un qualsiasi numero di file. Una transazione è <emphasis>atomica</emphasis>: o l’intera transazione ha successo e i suoi effetti sono visibili in lettura in un unico passo, oppure l’operazione viene completamente annullata. Questa garanzia di atomicità significa che se state eseguendo due copie di Mercurial, una che sta leggendo dati e l’altra che sta scrivendo, la copia che agisce in lettura non vedrà mai un risultato parzialmente scritto che potrebbe confonderla.</para> 10.54 10.55 <para id="x_2f9">Il fatto che Mercurial operi solo aggiungendo dati alla fine dei file rende più facile fornire questa garanzia transazionale. Più è facile fare cose come queste, più dovreste avere fiducia nel fatto che vengano eseguite correttamente.</para> 10.56 10.57 @@ -87,7 +87,7 @@ 10.58 <sect2> 10.59 <title>Reperimento veloce</title> 10.60 10.61 - <para id="x_2fa">Mercurial evita astutamente un'insidia comune a tutti i primi sistemi di controllo di revisione: il problema del <emphasis>reperimento inefficiente</emphasis>. La maggior parte dei sistemi di controllo di revisione memorizza i contenuti di una revisione come una serie incrementale di modifiche rispetto a una <quote>fotografia</quote>. (Alcuni basano la fotografia sulla revisione più vecchia, altri su quella più recente.) Per ricostruire una revisione specifica, dovete leggere prima la fotografia e poi ognuna delle revisioni tra la fotografia e la revisione che volete. Più cronologia accumula un file, più revisioni dovete leggere, quindi più tempo viene impiegato per ricostruire una particolare revisione.</para> 10.62 + <para id="x_2fa">Mercurial evita astutamente un’insidia comune a tutti i primi sistemi di controllo di revisione: il problema del <emphasis>reperimento inefficiente</emphasis>. La maggior parte dei sistemi di controllo di revisione memorizza i contenuti di una revisione come una serie incrementale di modifiche rispetto a una <quote>fotografia</quote>. (Alcuni basano la fotografia sulla revisione più vecchia, altri su quella più recente.) Per ricostruire una revisione specifica, dovete leggere prima la fotografia e poi ognuna delle revisioni tra la fotografia e la revisione che volete. Più cronologia accumula un file, più revisioni dovete leggere, quindi più tempo viene impiegato per ricostruire una particolare revisione.</para> 10.63 10.64 <figure id="fig:concepts:snapshot"> 10.65 <title>Fotografia di un revlog, con delta incrementali</title> 10.66 @@ -97,12 +97,12 @@ 10.67 </mediaobject> 10.68 </figure> 10.69 10.70 - <para id="x_2fc">Il modo innovativo in cui Mercurial risolve questo problema è semplice ma efficace. Una volta che la quantità totale di informazioni di delta memorizzate dall'ultima fotografia supera una soglia fissata, Mercurial memorizza una nuova fotografia (compressa, naturalmente) invece di un'altra delta. Questo approccio consente di ricostruire velocemente <emphasis>qualsiasi</emphasis> revisione di un file e funziona così bene che in seguito è stato copiato da molti altri sistemi di controllo di revisione.</para> 10.71 - 10.72 - <para id="x_2fd">La <xref linkend="fig:concepts:snapshot"/> illustra l'idea. In una voce contenuta nel file indice di un revlog, Mercurial memorizza l'intervallo di voci che deve leggere dal file di dati per ricostruire una particolare revisione.</para> 10.73 + <para id="x_2fc">Il modo innovativo in cui Mercurial risolve questo problema è semplice ma efficace. Una volta che la quantità totale di informazioni di delta memorizzate dall’ultima fotografia supera una soglia fissata, Mercurial memorizza una nuova fotografia (compressa, naturalmente) invece di un’altra delta. Questo approccio consente di ricostruire velocemente <emphasis>qualsiasi</emphasis> revisione di un file e funziona così bene che in seguito è stato copiato da molti altri sistemi di controllo di revisione.</para> 10.74 + 10.75 + <para id="x_2fd">La <xref linkend="fig:concepts:snapshot"/> illustra l’idea. In una voce contenuta nel file indice di un revlog, Mercurial memorizza l’intervallo di voci che deve leggere dal file di dati per ricostruire una particolare revisione.</para> 10.76 10.77 <sect3> 10.78 - <title>Digressione: l'influenza della compressione video</title> 10.79 + <title>Digressione: l’influenza della compressione video</title> 10.80 10.81 <para id="x_2fe">Se avete familiarità con la compressione video o avete mai esaminato un segnale televisivo trasmesso attraverso un cavo digitale o un servizio satellitare, potreste sapere che la maggior parte degli schemi per la compressione video memorizzano ogni frame del video come una delta rispetto al frame precedente.</para> 10.82 10.83 @@ -117,20 +117,20 @@ 10.84 10.85 <para id="x_301">Gli hash forniscono più di un semplice controllo contro la corruzione dei dati, infatti vengono usati come identificatori per le revisioni. Gli hash di identificazione dei changeset che avete visto come utenti finali provengono dalle revisioni del changelog. Sebbene anche i filelog e il manifest facciano uso di hash, in questo caso Mercurial li impiega solo dietro le quinte.</para> 10.86 10.87 - <para id="x_302">Mercurial verifica che gli hash siano corretti nel momento in cui reperisce le revisioni dei file o estrae i cambiamenti da un altro repository. Se incontra un problema di integrità, lo segnalerà e bloccherà l'operazione che stava eseguendo.</para> 10.88 - 10.89 - <para id="x_303">In aggiunta all'effetto che ha sull'efficienza del reperimento, l'uso di fotografie periodiche da parte di Mercurial rende i repository più robusti nei confronti della corruzione parziale dei dati. Se un revlog viene parzialmente rovinato da un errore hardware o da un bug di sistema, spesso rimane possibile ricostruire alcune o la maggior parte delle revisioni a partire dalle sezioni illese del revlog che si trovano prima e dopo la sezione rovinata. Questo non sarebbe possibile con un modello di memorizzazione basato unicamente sulle delta.</para> 10.90 + <para id="x_302">Mercurial verifica che gli hash siano corretti nel momento in cui reperisce le revisioni dei file o estrae i cambiamenti da un altro repository. Se incontra un problema di integrità, lo segnalerà e bloccherà l’operazione che stava eseguendo.</para> 10.91 + 10.92 + <para id="x_303">In aggiunta all’effetto che ha sull’efficienza del reperimento, l’uso di fotografie periodiche da parte di Mercurial rende i repository più robusti nei confronti della corruzione parziale dei dati. Se un revlog viene parzialmente rovinato da un errore hardware o da un bug di sistema, spesso rimane possibile ricostruire alcune o la maggior parte delle revisioni a partire dalle sezioni illese del revlog che si trovano prima e dopo la sezione rovinata. Questo non sarebbe possibile con un modello di memorizzazione basato unicamente sulle delta.</para> 10.93 </sect2> 10.94 </sect1> 10.95 10.96 <sect1> 10.97 <title>Cronologia delle revisioni, ramificazioni e unioni</title> 10.98 10.99 - <para id="x_304">Ogni voce in un revlog di Mercurial conosce l'identità della propria revisione progenitrice diretta, di solito chiamata <emphasis>genitore</emphasis>. In effetti, una revisione contiene spazio non solo per un genitore, ma per due. Mercurial usa un hash speciale, chiamato <quote>identificatore nullo</quote>, per rappresentare l'idea che <quote>non c'è alcun genitore qui</quote>. Questo hash è semplicemente una stringa di zeri.</para> 10.100 + <para id="x_304">Ogni voce in un revlog di Mercurial conosce l’identità della propria revisione progenitrice diretta, di solito chiamata <emphasis>genitore</emphasis>. In effetti, una revisione contiene spazio non solo per un genitore, ma per due. Mercurial usa un hash speciale, chiamato <quote>identificatore nullo</quote>, per rappresentare l’idea che <quote>non c’è alcun genitore qui</quote>. Questo hash è semplicemente una stringa di zeri.</para> 10.101 10.102 <para id="x_305">Nella <xref linkend="fig:concepts:revlog"/>, potete vedere un esempio della struttura concettuale di un revlog. I filelog, i manifest e i changelog hanno tutti questa identica struttura e differiscono solo per il tipo di dati memorizzati in ogni delta e fotografia.</para> 10.103 10.104 - <para id="x_306">La prima revisione in un revlog (nella parte inferiore dell'immagine) presenta un identificatore nullo in entrambi gli spazi riservati ai genitori. Per una revisione <quote>normale</quote>, lo spazio del primo genitore contiene l'identificatore della revisione genitore e lo spazio del secondo contiene l'identificatore nullo, indicando che la revisione possiede un solo vero genitore. Due revisioni qualsiasi che possiedano lo stesso genitore si chiamano <emphasis>rami</emphasis>. Una revisione che rappresenta un'unione tra rami ha due identificatori di revisione normali negli spazi dedicati ai propri genitori.</para> 10.105 + <para id="x_306">La prima revisione in un revlog (nella parte inferiore dell’immagine) presenta un identificatore nullo in entrambi gli spazi riservati ai genitori. Per una revisione <quote>normale</quote>, lo spazio del primo genitore contiene l’identificatore della revisione genitore e lo spazio del secondo contiene l’identificatore nullo, indicando che la revisione possiede un solo vero genitore. Due revisioni qualsiasi che possiedano lo stesso genitore si chiamano <emphasis>rami</emphasis>. Una revisione che rappresenta un’unione tra rami ha due identificatori di revisione normali negli spazi dedicati ai propri genitori.</para> 10.106 10.107 <figure id="fig:concepts:revlog"> 10.108 <title>La struttura concettuale di un revlog</title> 10.109 @@ -148,9 +148,9 @@ 10.110 10.111 <para id="x_308">La directory di lavoro <quote>sa</quote> quale changeset contiene. Quando aggiornate la directory di lavoro per contenere un particolare changeset, Mercurial cerca la revisione appropriata del manifest per trovare quali file aveva registrato nel momento in cui quel changeset è stato inserito e qual era la revisione corrente di ogni file in quel momento. Poi, ricrea una copia di tutti quei file con gli stessi contenuti che avevano quando il changeset è stato inserito.</para> 10.112 10.113 - <para id="x_309">Il <emphasis>dirstate</emphasis> (letteralmente, stato della directory) è una struttura speciale che contiene le informazioni possedute da Mercurial sulla directory di lavoro. Viene mantenuto sotto forma di un file chiamato <filename>.hg/dirstate</filename> all'interno di un repository. Il dirstate contiene i dettagli del changeset a cui la directory di lavoro è aggiornata e di tutti i file che Mercurial sta monitorando nella directory di lavoro. Il dirstate permette a Mercurial anche di notare velocemente i file modificati, registrando le loro date e dimensioni al momento dell'aggiornamento.</para> 10.114 - 10.115 - <para id="x_30a">Il dirstate riserva spazio per due genitori, esattamente come una revisione di un revlog, in modo da poter rappresentare sia una normale revisione (con un genitore) che un'unione di due revisioni precedenti. Quando usate il comando <command role="hg-cmd">hg update</command>, il changeset a cui aggiornate la directory di lavoro viene memorizzato nello spazio del <quote>primo genitore</quote> e l'identificatore nullo nello spazio del secondo. Quando incorporate un altro changeset tramite <command role="hg-cmd">hg merge</command>, il primo genitore rimane lo stesso e il secondo genitore diventa il changeset che state incorporando. Il comando <command role="hg-cmd">hg parents</command> vi dice quali sono i genitori del dirstate.</para> 10.116 + <para id="x_309">Il <emphasis>dirstate</emphasis> (letteralmente, stato della directory) è una struttura speciale che contiene le informazioni possedute da Mercurial sulla directory di lavoro. Viene mantenuto sotto forma di un file chiamato <filename>.hg/dirstate</filename> all’interno di un repository. Il dirstate contiene i dettagli del changeset a cui la directory di lavoro è aggiornata e di tutti i file che Mercurial sta monitorando nella directory di lavoro. Il dirstate permette a Mercurial anche di notare velocemente i file modificati, registrando le loro date e dimensioni al momento dell’aggiornamento.</para> 10.117 + 10.118 + <para id="x_30a">Il dirstate riserva spazio per due genitori, esattamente come una revisione di un revlog, in modo da poter rappresentare sia una normale revisione (con un genitore) che un’unione di due revisioni precedenti. Quando usate il comando <command role="hg-cmd">hg update</command>, il changeset a cui aggiornate la directory di lavoro viene memorizzato nello spazio del <quote>primo genitore</quote> e l’identificatore nullo nello spazio del secondo. Quando incorporate un altro changeset tramite <command role="hg-cmd">hg merge</command>, il primo genitore rimane lo stesso e il secondo genitore diventa il changeset che state incorporando. Il comando <command role="hg-cmd">hg parents</command> vi dice quali sono i genitori del dirstate.</para> 10.119 10.120 <sect2> 10.121 <title>Cosa succede quando eseguite un commit</title> 10.122 @@ -177,7 +177,7 @@ 10.123 10.124 <para id="x_30f">È utile pensare alla directory di lavoro come al <quote>changeset che state per inserire</quote>. Le azioni compiute su qualsiasi file che abbiate detto a Mercurial di aver aggiunto, rimosso, rinominato, o copiato verranno riflesse in quel changeset, così come le modifiche a qualsiasi file che Mercurial aveva già registrato. Il nuovo changeset acquisirà come propri genitori quelli della directory di lavoro.</para> 10.125 10.126 - <para id="x_310">Dopo un commit, Mercurial aggiornerà i genitori della directory di lavoro in modo che il primo genitore sia l'identificatore del nuovo changeset e il secondo sia l'identificatore nullo, come mostrato nella <xref linkend="fig:concepts:wdir-after-commit"/>. Mercurial non tocca alcun file nella directory di lavoro quando eseguite un commit, ma si limita a modificare il dirstate per annotare i nuovi genitori della directory.</para> 10.127 + <para id="x_310">Dopo un commit, Mercurial aggiornerà i genitori della directory di lavoro in modo che il primo genitore sia l’identificatore del nuovo changeset e il secondo sia l’identificatore nullo, come mostrato nella <xref linkend="fig:concepts:wdir-after-commit"/>. Mercurial non tocca alcun file nella directory di lavoro quando eseguite un commit, ma si limita a modificare il dirstate per annotare i nuovi genitori della directory.</para> 10.128 10.129 </sect2> 10.130 <sect2> 10.131 @@ -225,32 +225,32 @@ 10.132 </mediaobject> 10.133 </figure> 10.134 10.135 - <para id="x_319">Mercurial deve anche modificare la directory di lavoro per unire i file gestiti dai due changeset. Semplificandolo un po', il processo di unione funziona nel modo seguente, per ogni file contenuto nei manifest di entrambi i changeset.</para> 10.136 + <para id="x_319">Mercurial deve anche modificare la directory di lavoro per unire i file gestiti dai due changeset. Semplificandolo un po’, il processo di unione funziona nel modo seguente, per ogni file contenuto nei manifest di entrambi i changeset.</para> 10.137 <itemizedlist> 10.138 <listitem><para id="x_31a">Se nessuno dei changeset ha modificato il file, non fare nulla con quel file.</para> 10.139 </listitem> 10.140 - <listitem><para id="x_31b">Se un changeset ha modificato il file e l'altro non lo ha modificato, crea la copia modificata del file nella directory di lavoro.</para> 10.141 - </listitem> 10.142 - <listitem><para id="x_31c">Se un changeset ha rimosso un file e l'altro no (o se anche l'altro lo ha cancellato), cancella il file dalla directory di lavoro.</para> 10.143 - </listitem> 10.144 - <listitem><para id="x_31d">Se un changeset ha cancellato un file ma l'altro lo ha modificato, chiedi all'utente cosa vuole fare: tenere il file modificato oppure rimuoverlo?</para> 10.145 - </listitem> 10.146 - <listitem><para id="x_31e">Se entrambi i changeset hanno modificato un file, richiama un programma di unione esterno per scegliere i contenuti del file da unire. Questa operazione potrebbe richiedere un'interazione con l'utente.</para> 10.147 - </listitem> 10.148 - <listitem><para id="x_31f">Se un changeset ha modificato un file e l'altro lo ha rinominato o copiato, assicurati che i cambiamenti seguano il nuovo nome del file.</para> 10.149 + <listitem><para id="x_31b">Se un changeset ha modificato il file e l’altro non lo ha modificato, crea la copia modificata del file nella directory di lavoro.</para> 10.150 + </listitem> 10.151 + <listitem><para id="x_31c">Se un changeset ha rimosso un file e l’altro no (o se anche l’altro lo ha cancellato), cancella il file dalla directory di lavoro.</para> 10.152 + </listitem> 10.153 + <listitem><para id="x_31d">Se un changeset ha cancellato un file ma l’altro lo ha modificato, chiedi all’utente cosa vuole fare: tenere il file modificato oppure rimuoverlo?</para> 10.154 + </listitem> 10.155 + <listitem><para id="x_31e">Se entrambi i changeset hanno modificato un file, richiama un programma di unione esterno per scegliere i contenuti del file da unire. Questa operazione potrebbe richiedere un’interazione con l’utente.</para> 10.156 + </listitem> 10.157 + <listitem><para id="x_31f">Se un changeset ha modificato un file e l’altro lo ha rinominato o copiato, assicurati che i cambiamenti seguano il nuovo nome del file.</para> 10.158 </listitem></itemizedlist> 10.159 <para id="x_320">Ci sono molti altri dettagli&emdash;le unioni sono piene di casi particolari&emdash;ma queste sono le scelte più comuni coinvolte nel processo di unione. Come potete vedere, la maggior parte dei casi è completamente automatizzata e in effetti la maggior parte delle unioni termina automaticamente senza richiedere il vostro intervento per risolvere alcun conflitto.</para> 10.160 10.161 - <para id="x_321">Se considerate quello che succede quando effettuate un commit dopo un'unione, ancora una volta la directory di lavoro è <quote>il changeset che state per inserire</quote>. Dopo che il comando <command role="hg-cmd">hg merge</command> ha terminato, la directory di lavoro possiede due genitori, che poi diventeranno i genitori del nuovo changeset.</para> 10.162 - 10.163 - <para id="x_322">Mercurial vi permette di effettuare molteplici unioni, ma dovete inserire i risultati di ogni singola unione man mano che procedete, perché Mercurial tiene traccia solamente di due genitori sia per le revisioni che per la directory di lavoro. Anche se unire molteplici changeset alla volta sarebbe tecnicamente possibile, Mercurial evita di farlo per semplicità. Con unioni a più vie, il rischio di disorientare l'utente, di incappare in conflitti sgradevoli da risolvere e di fare una terribile confusione durante il processo di unione diventerebbe intollerabile.</para> 10.164 + <para id="x_321">Se considerate quello che succede quando effettuate un commit dopo un’unione, ancora una volta la directory di lavoro è <quote>il changeset che state per inserire</quote>. Dopo che il comando <command role="hg-cmd">hg merge</command> ha terminato, la directory di lavoro possiede due genitori, che poi diventeranno i genitori del nuovo changeset.</para> 10.165 + 10.166 + <para id="x_322">Mercurial vi permette di effettuare molteplici unioni, ma dovete inserire i risultati di ogni singola unione man mano che procedete, perché Mercurial tiene traccia solamente di due genitori sia per le revisioni che per la directory di lavoro. Anche se unire molteplici changeset alla volta sarebbe tecnicamente possibile, Mercurial evita di farlo per semplicità. Con unioni a più vie, il rischio di disorientare l’utente, di incappare in conflitti sgradevoli da risolvere e di fare una terribile confusione durante il processo di unione diventerebbe intollerabile.</para> 10.167 10.168 </sect2> 10.169 10.170 <sect2> 10.171 <title>Le unioni e i cambiamenti di nome</title> 10.172 10.173 - <para id="x_69a">Un numero sorprendente di sistemi di controllo di revisione dedica poca o addirittura nessuna attenzione ai cambiamenti del <emphasis>nome</emphasis> di un file. Per esempio, era pratica comune scartare silenziosamente le modifiche a un file contenute in una delle due parti di un'unione se quel file fosse stato rinominato nell'altra parte.</para> 10.174 + <para id="x_69a">Un numero sorprendente di sistemi di controllo di revisione dedica poca o addirittura nessuna attenzione ai cambiamenti del <emphasis>nome</emphasis> di un file. Per esempio, era pratica comune scartare silenziosamente le modifiche a un file contenute in una delle due parti di un’unione se quel file fosse stato rinominato nell’altra parte.</para> 10.175 10.176 <para id="x_69b">Mercurial registra alcuni metadati quando gli dite di effettuare una cambiamento di nome o una copia e li usa durante le unioni per comportarsi in maniera appropriata. Per esempio, se io cambio il nome di un file che voi modificate senza rinominare, quando uniamo i nostri cambiamenti il file verrà rinominato e gli verranno applicate le vostre modifiche.</para> 10.177 </sect2> 10.178 @@ -259,23 +259,23 @@ 10.179 <sect1> 10.180 <title>Altre caratteristiche di progettazione interessanti</title> 10.181 10.182 - <para id="x_323">Nelle sezioni precedenti, ho provato a evidenziare alcuni degli aspetti più importanti nella progettazione di Mercurial, per illustrare come sia stata dedicata la dovuta attenzione a prestazioni e affidabilità. Tuttavia, l'attenzione ai dettagli non finisce qui. Ci sono un certo numero di altri aspetti nella costruzione di Mercurial che trovo personalmente interessanti. Ne descriverò alcuni in questa sezione, separatamente dagli elementi <quote>di primo piano</quote> analizzati finora, in modo che se siete interessati potete farvi un'idea più precisa di quanti ragionamenti ci sono dietro a un sistema ben progettato.</para> 10.183 + <para id="x_323">Nelle sezioni precedenti, ho provato a evidenziare alcuni degli aspetti più importanti nella progettazione di Mercurial, per illustrare come sia stata dedicata la dovuta attenzione a prestazioni e affidabilità. Tuttavia, l’attenzione ai dettagli non finisce qui. Ci sono un certo numero di altri aspetti nella costruzione di Mercurial che trovo personalmente interessanti. Ne descriverò alcuni in questa sezione, separatamente dagli elementi <quote>di primo piano</quote> analizzati finora, in modo che se siete interessati potete farvi un’idea più precisa di quanti ragionamenti ci sono dietro a un sistema ben progettato.</para> 10.184 10.185 <sect2> 10.186 <title>Compressione intelligente</title> 10.187 10.188 <para id="x_324">Quando è appropriato, Mercurial memorizzerà sia la fotografia che le delta in forma compressa, <emphasis>cercando</emphasis> sempre di comprimere una fotografia o una delta, ma memorizzando la versione compressa solo se è più piccola della versione originale.</para> 10.189 10.190 - <para id="x_325">Questo significa che Mercurial fa <quote>la cosa giusta</quote> quando memorizza un file il cui formato sia già compresso, come un archivio <literal>zip</literal> o un'immagine JPEG. Quando questi tipi di file vengono compressi una seconda volta, il file risultante è tipicamente più grande di quello originale, così Mercurial memorizzerà la versione iniziale del file <literal>zip</literal> o JPEG.</para> 10.191 + <para id="x_325">Questo significa che Mercurial fa <quote>la cosa giusta</quote> quando memorizza un file il cui formato sia già compresso, come un archivio <literal>zip</literal> o un’immagine JPEG. Quando questi tipi di file vengono compressi una seconda volta, il file risultante è tipicamente più grande di quello originale, così Mercurial memorizzerà la versione iniziale del file <literal>zip</literal> o JPEG.</para> 10.192 10.193 <para id="x_326">Di solito, le delta tra le revisioni di un file compresso sono più grandi delle fotografie del file, ma anche in questi casi Mercurial fa <quote>la cosa giusta</quote> ancora una volta. Scopre che quella delta supera la soglia oltre la quale Mercurial dovrebbe registrare una fotografia completa del file e quindi memorizza la fotografia, risparmiando ancora spazio nei confronti di un approccio ingenuo basato solo sulle delta.</para> 10.194 10.195 <sect3> 10.196 <title>Ricompressione di rete</title> 10.197 10.198 - <para id="x_327">Nel memorizzare le revisioni su disco, Mercurial usa l'algoritmo di compressione <quote>deflate</quote> (lo stesso usato dal popolare formato <literal>zip</literal>), che concilia una buona velocità con un rispettabile rapporto di compressione. Tuttavia, quando trasmette i dati di una revisione attraverso una connessione di rete, Mercurial decomprime i dati di revisione compressi.</para> 10.199 - 10.200 - <para id="x_328">Se la connessione avviene via HTTP, Mercurial ricomprime l'intero flusso di dati usando un algoritmo che ha un rapporto di compressione migliore (l'algoritmo Burrows-Wheeler del rinomato pacchetto di compressione <literal>bzip2</literal>). Questa combinazione di algoritmo e compressione dell'intero flusso (invece di una revisione alla volta) riduce notevolmente il numero di byte da trasferire, producendo prestazioni di trasmissione migliori sulla maggior parte delle reti.</para> 10.201 + <para id="x_327">Nel memorizzare le revisioni su disco, Mercurial usa l’algoritmo di compressione <quote>deflate</quote> (lo stesso usato dal popolare formato <literal>zip</literal>), che concilia una buona velocità con un rispettabile rapporto di compressione. Tuttavia, quando trasmette i dati di una revisione attraverso una connessione di rete, Mercurial decomprime i dati di revisione compressi.</para> 10.202 + 10.203 + <para id="x_328">Se la connessione avviene via HTTP, Mercurial ricomprime l’intero flusso di dati usando un algoritmo che ha un rapporto di compressione migliore (l’algoritmo Burrows-Wheeler del rinomato pacchetto di compressione <literal>bzip2</literal>). Questa combinazione di algoritmo e compressione dell’intero flusso (invece di una revisione alla volta) riduce notevolmente il numero di byte da trasferire, producendo prestazioni di trasmissione migliori sulla maggior parte delle reti.</para> 10.204 10.205 <para id="x_329">Se la connessione avviene via <command>ssh</command>, Mercurial <emphasis>non</emphasis> ricomprime il flusso, perché <command>ssh</command> è già in grado di farlo da sé. Potete dire a Mercurial di usare sempre la funzione di compressione di <command>ssh</command> modificando il file <filename>.hgrc</filename> che si trova nella vostra directory personale nel modo seguente.</para> 10.206 10.207 @@ -289,7 +289,7 @@ 10.208 10.209 <para id="x_32a">Quando si cerca di garantire che una lettura non veda scritture parziali, non è sufficiente limitarsi ad aggiungere in coda ai file le nuove informazioni. Se ricordate la <xref linkend="fig:concepts:metadata"/>, le revisioni in un changelog puntano alle revisioni nel manifest e le revisioni nel manifest puntano alle revisioni nei filelog. Questa gerarchia è intenzionale.</para> 10.210 10.211 - <para id="x_32b">Un'operazione di scrittura avvia una transazione modificando i dati nei filelog e nel manifest, senza modificare alcun dato contenuto nel changelog prima che di aver terminato con quelli. Un'operazione di lettura comincia leggendo i dati nel changelog, poi i dati nel manifest seguiti dai dati nei filelog.</para> 10.212 + <para id="x_32b">Un’operazione di scrittura avvia una transazione modificando i dati nei filelog e nel manifest, senza modificare alcun dato contenuto nel changelog prima che di aver terminato con quelli. Un’operazione di lettura comincia leggendo i dati nel changelog, poi i dati nel manifest seguiti dai dati nei filelog.</para> 10.213 10.214 <para id="x_32c">Dato che la scrittura ha sempre terminato di modificare i dati nei filelog e nel manifest prima di modificare il changelog, una lettura non vedrà mai il changelog puntare verso una revisione parzialmente modificata del manifest e non vedrà mai il manifest puntare verso una revisione parzialmente modificata di un filelog.</para> 10.215 10.216 @@ -297,11 +297,11 @@ 10.217 <sect2> 10.218 <title>Accesso concorrente</title> 10.219 10.220 - <para id="x_32d">Le garanzie sull'ordinamento e sull'atomicità delle operazioni di lettura significano che Mercurial non avrà mai bisogno di <emphasis>bloccare</emphasis> un repository da cui sta leggendo i dati, anche se il repository viene modificato mentre la lettura è in corso. Questo ha un importante effetto sulla scalabilità: potete avere un numero arbitrario di processi Mercurial che leggono contemporaneamente in sicurezza i dati da un repository, senza preoccuparvi che qualcun altro lo stia modificando oppure no.</para> 10.221 + <para id="x_32d">Le garanzie sull’ordinamento e sull’atomicità delle operazioni di lettura significano che Mercurial non avrà mai bisogno di <emphasis>bloccare</emphasis> un repository da cui sta leggendo i dati, anche se il repository viene modificato mentre la lettura è in corso. Questo ha un importante effetto sulla scalabilità: potete avere un numero arbitrario di processi Mercurial che leggono contemporaneamente in sicurezza i dati da un repository, senza preoccuparvi che qualcun altro lo stia modificando oppure no.</para> 10.222 10.223 <para id="x_32e">La mancanza di un blocco durante la lettura significa che, se state condividendo un repository su un sistema multi-utente, non avete bisogno di concedere ad altri utenti locali i permessi di <emphasis>scrittura</emphasis> al vostro repository per consentire loro di clonarlo o estrarne i cambiamenti, ma saranno sufficienti i permessi di <emphasis>lettura</emphasis>. (Questa <emphasis>non</emphasis> è una caratteristica comune tra i sistemi di controllo di revisione, quindi non datela per scontata! La maggior parte dei sistemi richiede che i lettori siano in grado di bloccare un repository per accederlo in sicurezza, cosa che naturalmente provoca ogni tipo di sgradevoli e fastidiosi problemi di sicurezza e amministrazione.)</para> 10.224 10.225 - <para id="x_32f">Mercurial usa i blocchi per assicurarsi che un solo processo alla volta possa effettuare modifiche a un repository (il meccanismo di bloccaggio è sicuro persino su file system che sono notoriamente avversi al bloccaggio, come NFS). Se un repository è bloccato, un'operazione di scrittura aspetterà per qualche tempo prima di ricontrollare se il repository si è sbloccato, ma se il repository rimane bloccato troppo a lungo, dopo un po' il processo che sta tentando di scrivere andrà in timeout. Questo significa, per esempio, che i vostri script automatici non rimarranno bloccati per sempre accumulandosi l'uno sull'altro se un sistema dovesse inavvertitamente cadere. (Sì, il valore del timeout è configurabile, da zero a infinito.)</para> 10.226 + <para id="x_32f">Mercurial usa i blocchi per assicurarsi che un solo processo alla volta possa effettuare modifiche a un repository (il meccanismo di bloccaggio è sicuro persino su file system che sono notoriamente avversi al bloccaggio, come NFS). Se un repository è bloccato, un’operazione di scrittura aspetterà per qualche tempo prima di ricontrollare se il repository si è sbloccato, ma se il repository rimane bloccato troppo a lungo, dopo un po’ il processo che sta tentando di scrivere andrà in timeout. Questo significa, per esempio, che i vostri script automatici non rimarranno bloccati per sempre accumulandosi l’uno sull’altro se un sistema dovesse inavvertitamente cadere. (Sì, il valore del timeout è configurabile, da zero a infinito.)</para> 10.227 10.228 <sect3> 10.229 <title>Accesso sicuro al dirstate</title> 10.230 @@ -313,19 +313,19 @@ 10.231 <sect2> 10.232 <title>Evitare le operazioni di seek</title> 10.233 10.234 - <para id="x_331">Un aspetto critico delle prestazioni di Mercurial è quello di evitare le operazioni di seek della testina del disco, dato che ognuna di queste operazioni è molto più dispendiosa persino di un'operazione di lettura relativamente grande.</para> 10.235 - 10.236 - <para id="x_332">Questa è la ragione per cui, per esempio, il dirstate è memorizzato in un singolo file. Se ci fosse un file di dirstate per ogni directory registrata da Mercurial, il disco effettuerebbe un'operazione di seek per ciascuna directory. Invece, Mercurial legge l'intero file di dirstate in un singolo passo.</para> 10.237 + <para id="x_331">Un aspetto critico delle prestazioni di Mercurial è quello di evitare le operazioni di seek della testina del disco, dato che ognuna di queste operazioni è molto più dispendiosa persino di un’operazione di lettura relativamente grande.</para> 10.238 + 10.239 + <para id="x_332">Questa è la ragione per cui, per esempio, il dirstate è memorizzato in un singolo file. Se ci fosse un file di dirstate per ogni directory registrata da Mercurial, il disco effettuerebbe un’operazione di seek per ciascuna directory. Invece, Mercurial legge l’intero file di dirstate in un singolo passo.</para> 10.240 10.241 <para id="x_333">Mercurial adotta anche una strategia <quote>copy-on-write</quote> per clonare un repository su disco locale. Invece di copiare ogni file di revlog dal vecchio repository al nuovo, utilizza <quote>collegamenti fisici</quote> per indicare che <quote>due nomi puntano allo stesso file</quote>. Quando Mercurial sta per modificare uno dei file di un revlog, controlla per vedere se il numero di nomi che puntano al file è più grande di uno. Se è così, questo significa che più di un repository sta usando il file, quindi Mercurial ne crea una nuova copia riservata a questo repository.</para> 10.242 10.243 - <para id="x_334">Alcuni sviluppatori di sistemi per il controllo di revisione hanno fatto notare che la creazione di una copia privata completa di un file non sfrutta lo spazio su disco in maniera molto efficiente. Sebbene questo sia vero, lo spazio su disco è piuttosto economico, e questo metodo consente di avere le prestazioni migliori rinviando la maggior parte della contabilità al sistema operativo. Molto probabilmente, una strategia alternativa ridurrebbe le prestazioni e aumenterebbe la complessità del software, ma velocità e semplicità sono aspetti chiave per la <quote>facilità</quote> nell'uso quotidiano.</para> 10.244 + <para id="x_334">Alcuni sviluppatori di sistemi per il controllo di revisione hanno fatto notare che la creazione di una copia privata completa di un file non sfrutta lo spazio su disco in maniera molto efficiente. Sebbene questo sia vero, lo spazio su disco è piuttosto economico, e questo metodo consente di avere le prestazioni migliori rinviando la maggior parte della contabilità al sistema operativo. Molto probabilmente, una strategia alternativa ridurrebbe le prestazioni e aumenterebbe la complessità del software, ma velocità e semplicità sono aspetti chiave per la <quote>facilità</quote> nell’uso quotidiano.</para> 10.245 10.246 </sect2> 10.247 <sect2> 10.248 <title>Altre informazioni contenute nel dirstate</title> 10.249 10.250 - <para id="x_335">Dato che Mercurial non vi obbliga a dirgli quando state modificando un file, usa il dirstate per memorizzare alcune informazioni aggiuntive in modo da poter determinare in maniera efficiente se avete modificato un file. Per ogni file nella directory di lavoro, Mercurial memorizza la data in cui ha registrato una modifica al file per l'ultima volta e la dimensione che il file aveva in quel momento.</para> 10.251 + <para id="x_335">Dato che Mercurial non vi obbliga a dirgli quando state modificando un file, usa il dirstate per memorizzare alcune informazioni aggiuntive in modo da poter determinare in maniera efficiente se avete modificato un file. Per ogni file nella directory di lavoro, Mercurial memorizza la data in cui ha registrato una modifica al file per l’ultima volta e la dimensione che il file aveva in quel momento.</para> 10.252 10.253 <para id="x_336">Quando utilizzate esplicitamente <command role="hg-cmd">hg add</command>, <command role="hg-cmd">hg remove</command>, <command role="hg-cmd">hg rename</command>, o <command role="hg-cmd">hg copy</command> su un file, Mercurial aggiorna il dirstate in modo che sappia cosa fare con quel file quando effettuate un commit.</para> 10.254 10.255 @@ -333,7 +333,7 @@ 10.256 10.257 <itemizedlist> 10.258 <listitem> 10.259 - <para id="x_726">Quando Mercurial controlla lo stato di un file nella directory di lavoro, per prima cosa confronta la data dell'ultima modifica del file con la data memorizzata nel dirstate che indica l'ultima volta in cui Mercurial ha registrato una modifica per quel file. Se le due date sono le stesse, il file non deve essere stato modificato, quindi Mercurial non ha bisogno di fare ulteriori controlli.</para> 10.260 + <para id="x_726">Quando Mercurial controlla lo stato di un file nella directory di lavoro, per prima cosa confronta la data dell’ultima modifica del file con la data memorizzata nel dirstate che indica l’ultima volta in cui Mercurial ha registrato una modifica per quel file. Se le due date sono le stesse, il file non deve essere stato modificato, quindi Mercurial non ha bisogno di fare ulteriori controlli.</para> 10.261 </listitem> 10.262 <listitem> 10.263 <para id="x_727">Se la dimensione del file è cambiata, il file deve essere stato modificato. Solo nel caso in cui la data di modifica sia cambiata, ma non la dimensione, Mercurial ha effettivamente bisogno di leggere i contenuti del file per vedere se è stato modificato.</para>
11.1 --- a/it/ch05-daily.xml Sat Aug 22 21:01:56 2009 +0200 11.2 +++ b/it/ch05-daily.xml Sat Aug 22 21:55:05 2009 +0200 11.3 @@ -1,17 +1,17 @@ 11.4 <chapter id="chap:daily"> 11.5 <?dbhtml filename="uso-quotidiano-di-mercurial.html"?> 11.6 - <title>L'uso quotidiano di Mercurial</title> 11.7 + <title>L’uso quotidiano di Mercurial</title> 11.8 11.9 <sect1> 11.10 <title>Aggiungere file a un repository Mercurial</title> 11.11 11.12 <para id="x_1a3">Mercurial lavora solo con i file che gli dite di amministrare nel vostro repository. Il comando <command role="hg-cmd">hg status</command> vi dirà quali sono i file che Mercurial non conosce, usando un <quote><literal>?</literal></quote> per mostrare questi file.</para> 11.13 11.14 - <para id="x_1a4">Per dire a Mercurial di tenere traccia di un file, usate il comando <command role="hg-cmd">hg add</command>. Una volta che avete aggiunto un file, la voce per quel file nell'elenco visualizzato da <command role="hg-cmd">hg status</command> cambia da <quote><literal>?</literal></quote> ad <quote><literal>A</literal></quote>.</para> 11.15 + <para id="x_1a4">Per dire a Mercurial di tenere traccia di un file, usate il comando <command role="hg-cmd">hg add</command>. Una volta che avete aggiunto un file, la voce per quel file nell’elenco visualizzato da <command role="hg-cmd">hg status</command> cambia da <quote><literal>?</literal></quote> ad <quote><literal>A</literal></quote>.</para> 11.16 11.17 &interaction.daily.files.add; 11.18 11.19 - <para id="x_1a5">Dopo aver eseguito <command role="hg-cmd">hg commit</command>, i file che avete aggiunto prima dell'inserimento non verranno più elencati dal comando <command role="hg-cmd">hg status</command>, perché il comportamento predefinito di <command role="hg-cmd">hg status</command> è quello di segnalarvi solo i file <quote>interessanti</quote> come (per esempio) quelli che avete modificato, rimosso, o rinominato. Se avete un repository che contiene migliaia di file, vorrete raramente sapere qualcosa dei file che Mercurial ha già registrato ma che non sono cambiati. (Potete comunque ottenere questa informazione, come vedremo più avanti.)</para> 11.20 + <para id="x_1a5">Dopo aver eseguito <command role="hg-cmd">hg commit</command>, i file che avete aggiunto prima dell’inserimento non verranno più elencati dal comando <command role="hg-cmd">hg status</command>, perché il comportamento predefinito di <command role="hg-cmd">hg status</command> è quello di segnalarvi solo i file <quote>interessanti</quote> come (per esempio) quelli che avete modificato, rimosso, o rinominato. Se avete un repository che contiene migliaia di file, vorrete raramente sapere qualcosa dei file che Mercurial ha già registrato ma che non sono cambiati. (Potete comunque ottenere questa informazione, come vedremo più avanti.)</para> 11.21 11.22 <para id="x_1a6">Mercurial non agisce immediatamente su un file che avete appena aggiunto, ma scatterà una fotografia dello stato del file la prossima volta che eseguirete un commit. Poi continuerà a tenere traccia dei cambiamenti che apportate al file ogni volta che eseguite un commit, fino a quando non rimuoverete il file.</para> 11.23 11.24 @@ -22,7 +22,7 @@ 11.25 11.26 &interaction.daily.files.add-dir; 11.27 11.28 - <para id="x_1a8">Notate che, in questo esempio, Mercurial ha stampato i nomi dei file che ha aggiunto, mentre non lo ha fatto quando abbiamo aggiunto il file <filename>miofile.txt</filename> nell'esempio precedente.</para> 11.29 + <para id="x_1a8">Notate che, in questo esempio, Mercurial ha stampato i nomi dei file che ha aggiunto, mentre non lo ha fatto quando abbiamo aggiunto il file <filename>miofile.txt</filename> nell’esempio precedente.</para> 11.30 11.31 <para id="x_1a9">Questo accade perché, nel primo esempio, abbiamo esplicitamente nominato il file da aggiungere sulla riga di comando. In questi casi, Mercurial assume che sappiamo ciò che stiamo facendo, per cui non stampa alcuna informazione.</para> 11.32 11.33 @@ -47,7 +47,7 @@ 11.34 <sect1> 11.35 <title>Come rimuovere un file dal repository</title> 11.36 11.37 - <para id="x_1af">Una volta che avete deciso che un file non appartiene più al vostro repository, usate il comando <command role="hg-cmd">hg remove</command>. Questo comando cancella il file e dice a Mercurial di non tenerne più traccia (cosa che avverrà nel prossimo commit). Un file rimosso viene rappresentato con una <quote><literal>R</literal></quote> nell'elenco prodotto da <command role="hg-cmd">hg status</command>.</para> 11.38 + <para id="x_1af">Una volta che avete deciso che un file non appartiene più al vostro repository, usate il comando <command role="hg-cmd">hg remove</command>. Questo comando cancella il file e dice a Mercurial di non tenerne più traccia (cosa che avverrà nel prossimo commit). Un file rimosso viene rappresentato con una <quote><literal>R</literal></quote> nell’elenco prodotto da <command role="hg-cmd">hg status</command>.</para> 11.39 11.40 &interaction.daily.files.remove; 11.41 11.42 @@ -70,7 +70,7 @@ 11.43 <sect2> 11.44 <title>File mancanti</title> 11.45 11.46 - <para id="x_1b6">Mercurial considera <emphasis>mancante</emphasis> un file che avete cancellato senza usare <command role="hg-cmd">hg remove</command>. Un file mancante viene rappresentato con <quote><literal>!</literal></quote> nell'elenco mostrato da <command role="hg-cmd">hg status</command>. Di solito, i comandi Mercurial non agiscono mai sui file mancanti.</para> 11.47 + <para id="x_1b6">Mercurial considera <emphasis>mancante</emphasis> un file che avete cancellato senza usare <command role="hg-cmd">hg remove</command>. Un file mancante viene rappresentato con <quote><literal>!</literal></quote> nell’elenco mostrato da <command role="hg-cmd">hg status</command>. Di solito, i comandi Mercurial non agiscono mai sui file mancanti.</para> 11.48 11.49 &interaction.daily.files.missing; 11.50 11.51 @@ -78,7 +78,7 @@ 11.52 11.53 &interaction.daily.files.remove-after; 11.54 11.55 - <para id="x_1b8">D'altra parte, se avete cancellato il file mancante per errore, passate al comando <command role="hg-cmd">hg revert</command> il nome del file da recuperare e il file riapparirà senza alcun cambiamento.</para> 11.56 + <para id="x_1b8">D’altra parte, se avete cancellato il file mancante per errore, passate al comando <command role="hg-cmd">hg revert</command> il nome del file da recuperare e il file riapparirà senza alcun cambiamento.</para> 11.57 11.58 &interaction.daily.files.recover-missing; 11.59 </sect2> 11.60 @@ -86,7 +86,7 @@ 11.61 <sect2> 11.62 <title>Digressione: perché dire esplicitamente a Mercurial di rimuovere un file?</title> 11.63 11.64 - <para id="x_1b9">Potreste chiedervi perché Mercurial vi costringe a dirgli esplicitamente che state cancellando un file. Nelle prime fasi di sviluppo, Mercurial vi permetteva di cancellare un file nel modo che preferivate: avrebbe notato automaticamente l'assenza del file durante la successiva esecuzione di <command role="hg-cmd">hg commit</command> e avrebbe smesso di monitorarlo. In pratica, questo modo di operare rendeva troppo facile rimuovere accidentalmente un file senza accorgersene.</para> 11.65 + <para id="x_1b9">Potreste chiedervi perché Mercurial vi costringe a dirgli esplicitamente che state cancellando un file. Nelle prime fasi di sviluppo, Mercurial vi permetteva di cancellare un file nel modo che preferivate: avrebbe notato automaticamente l’assenza del file durante la successiva esecuzione di <command role="hg-cmd">hg commit</command> e avrebbe smesso di monitorarlo. In pratica, questo modo di operare rendeva troppo facile rimuovere accidentalmente un file senza accorgersene.</para> 11.66 </sect2> 11.67 11.68 <sect2> 11.69 @@ -96,7 +96,7 @@ 11.70 11.71 &interaction.daily.files.addremove; 11.72 11.73 - <para id="x_1bb">Il comando <command role="hg-cmd">hg commit</command> offre anche un'opzione <option role="hg-opt-commit">-A</option> che effettua la stessa operazione di aggiunta-e-rimozione, immediatamente seguita da un commit.</para> 11.74 + <para id="x_1bb">Il comando <command role="hg-cmd">hg commit</command> offre anche un’opzione <option role="hg-opt-commit">-A</option> che effettua la stessa operazione di aggiunta-e-rimozione, immediatamente seguita da un commit.</para> 11.75 11.76 &interaction.daily.files.commit-addremove; 11.77 </sect2> 11.78 @@ -108,9 +108,9 @@ 11.79 <para id="x_1bc">Mercurial fornisce un comando <command role="hg-cmd">hg copy</command> che vi permette di creare una nuova copia di un file. Quando copiate un file usando questo comando, Mercurial registra il fatto che il nuovo file è una copia del file originale e tratta i file copiati in maniera speciale quando unite il vostro lavoro con quello di qualcun altro.</para> 11.80 11.81 <sect2> 11.82 - <title>I risultati di una copia durante un'unione</title> 11.83 - 11.84 - <para id="x_1bd">Quello che succede durante un'unione è che i cambiamenti <quote>seguono</quote> la copia. Per illustrare al meglio cosa questo significa, creiamo un esempio. Cominceremo con il solito piccolo repository che contiene un singolo file.</para> 11.85 + <title>I risultati di una copia durante un’unione</title> 11.86 + 11.87 + <para id="x_1bd">Quello che succede durante un’unione è che i cambiamenti <quote>seguono</quote> la copia. Per illustrare al meglio cosa questo significa, creiamo un esempio. Cominceremo con il solito piccolo repository che contiene un singolo file.</para> 11.88 11.89 &interaction.daily.copy.init; 11.90 11.91 @@ -126,7 +126,7 @@ 11.92 11.93 &interaction.daily.copy.status; 11.94 11.95 - <para id="x_1c1">Ma se passiamo l'opzione <option role="hg-opt-status">-C</option> al comando <command role="hg-cmd">hg status</command>, otterremo un'altra riga nell'elenco stampato: questo è il file <emphasis>da cui</emphasis> il nostro file appena aggiunto è stato copiato.</para> 11.96 + <para id="x_1c1">Ma se passiamo l’opzione <option role="hg-opt-status">-C</option> al comando <command role="hg-cmd">hg status</command>, otterremo un’altra riga nell’elenco stampato: questo è il file <emphasis>da cui</emphasis> il nostro file appena aggiunto è stato copiato.</para> 11.97 11.98 &interaction.daily.copy.status-copy; 11.99 11.100 @@ -144,7 +144,7 @@ 11.101 11.102 <para id="x_1c4">Questo comportamento&emdash;dei cambiamenti a un file che si propagano alle copie del file&emdash;potrebbe sembrare esoterico, ma nella maggior parte dei casi è altamente desiderabile.</para> 11.103 11.104 - <para id="x_1c5">Prima di tutto, ricordatevi che questa propagazione avviene <emphasis>solamente</emphasis> durante un'unione. Quindi se usate <command role="hg-cmd">hg copy</command> su un file e in seguito modificate il file originale nel normale corso del vostro lavoro, non accadrà nulla.</para> 11.105 + <para id="x_1c5">Prima di tutto, ricordatevi che questa propagazione avviene <emphasis>solamente</emphasis> durante un’unione. Quindi se usate <command role="hg-cmd">hg copy</command> su un file e in seguito modificate il file originale nel normale corso del vostro lavoro, non accadrà nulla.</para> 11.106 11.107 <para id="x_1c6">La seconda cosa da sapere è che le modifiche si propagheranno alla copia solo se il changeset da cui state incorporando le modifiche <emphasis>non ha ancora visto</emphasis> la copia.</para> 11.108 11.109 @@ -152,9 +152,9 @@ 11.110 11.111 <para id="x_1c8">Se dopo aver estratto e incorporato le mie modifiche Mercurial <emphasis>non</emphasis> avesse propagato i cambiamenti attraverso le copie, il vostro nuovo file sorgente ora conterrebbe il bug e, a meno che voi non sapeste come propagare la correzione a mano, il bug <emphasis>rimarrebbe</emphasis> nella vostra copia del file.</para> 11.112 11.113 - <para id="x_1c9">Propagando automaticamente le modifiche che hanno corretto il bug dal file originale alla copia, Mercurial previene questo tipo di problemi. A quanto ne so, Mercurial è <emphasis>l'unico</emphasis> sistema di controllo di revisione che propaga i cambiamenti verso le copie in questo modo.</para> 11.114 - 11.115 - <para id="x_1ca">Una volta che la vostra cronologia dei cambiamenti contiene la registrazione che la copia e la successiva unione sono avvenute, di solito non c'è più bisogno di propagare cambiamenti dal file originale al file copiato. Questo è il motivo per cui Mercurial propaga i cambiamenti verso le copie solo durante la prima unione ma non successivamente.</para> 11.116 + <para id="x_1c9">Propagando automaticamente le modifiche che hanno corretto il bug dal file originale alla copia, Mercurial previene questo tipo di problemi. A quanto ne so, Mercurial è <emphasis>l’unico</emphasis> sistema di controllo di revisione che propaga i cambiamenti verso le copie in questo modo.</para> 11.117 + 11.118 + <para id="x_1ca">Una volta che la vostra cronologia dei cambiamenti contiene la registrazione che la copia e la successiva unione sono avvenute, di solito non c’è più bisogno di propagare cambiamenti dal file originale al file copiato. Questo è il motivo per cui Mercurial propaga i cambiamenti verso le copie solo durante la prima unione ma non successivamente.</para> 11.119 </sect2> 11.120 11.121 <sect2> 11.122 @@ -168,7 +168,7 @@ 11.123 11.124 <para id="x_1cc">Quando usate il comando <command role="hg-cmd">hg copy</command>, Mercurial esegue la copia dei file originali contenuti nella directory di lavoro nello stato in cui si trovano in quel momento. Questo significa che, se fate alcune modifiche a un file e poi lo copiate tramite <command role="hg-cmd">hg copy</command> senza prima aver inserito quelle modifiche nel repository, anche la nuova copia conterrà le modifiche che avete apportato fino a quel momento. (Trovo che questo comportamento sia leggermente controintuitivo ed è per questo che lo menziono qui.)</para> 11.125 11.126 - <para id="x_1cd">Il comando <command role="hg-cmd">hg copy</command> agisce in maniera simile al comando Unix <command>cp</command> (potete usare l'alias <command role="hg-cmd">hg cp</command> se preferite). Dobbiamo fornirgli due o più argomenti, di cui l'ultimo viene trattato come <emphasis>destinazione</emphasis> e tutti gli altri vengono trattati come <emphasis>sorgenti</emphasis>.</para> 11.127 + <para id="x_1cd">Il comando <command role="hg-cmd">hg copy</command> agisce in maniera simile al comando Unix <command>cp</command> (potete usare l’alias <command role="hg-cmd">hg cp</command> se preferite). Dobbiamo fornirgli due o più argomenti, di cui l’ultimo viene trattato come <emphasis>destinazione</emphasis> e tutti gli altri vengono trattati come <emphasis>sorgenti</emphasis>.</para> 11.128 11.129 <para id="x_685">Se invocate <command role="hg-cmd">hg copy</command> con un singolo file come sorgente e la destinazione non esiste, il comando crea un nuovo file con quel nome.</para> 11.130 11.131 @@ -178,15 +178,15 @@ 11.132 11.133 &interaction.daily.copy.dir-dest; 11.134 11.135 - <para id="x_1cf">Copiare una directory è un'operazione ricorsiva e preserva la struttura delle directory della sorgente.</para> 11.136 + <para id="x_1cf">Copiare una directory è un’operazione ricorsiva e preserva la struttura delle directory della sorgente.</para> 11.137 11.138 &interaction.daily.copy.dir-src; 11.139 11.140 - <para id="x_1d0">Se la sorgente e la destinazione sono entrambe directory, l'albero della sorgente viene ricreato nella directory di destinazione.</para> 11.141 + <para id="x_1d0">Se la sorgente e la destinazione sono entrambe directory, l’albero della sorgente viene ricreato nella directory di destinazione.</para> 11.142 11.143 &interaction.daily.copy.dir-src-dest; 11.144 11.145 - <para id="x_1d1">Come con il comando <command role="hg-cmd">hg remove</command>, se copiate un file manualmente e poi volete informare Mercurial di aver copiato il file, usate semplicemente l'opzione <option role="hg-opt-copy">--after</option> di <command role="hg-cmd">hg copy</command>.</para> 11.146 + <para id="x_1d1">Come con il comando <command role="hg-cmd">hg remove</command>, se copiate un file manualmente e poi volete informare Mercurial di aver copiato il file, usate semplicemente l’opzione <option role="hg-opt-copy">--after</option> di <command role="hg-cmd">hg copy</command>.</para> 11.147 11.148 &interaction.daily.copy.after; 11.149 </sect2> 11.150 @@ -205,18 +205,18 @@ 11.151 11.152 &interaction.daily.rename.status; 11.153 11.154 - <para id="x_1d5">Come accade per i risultati del comando <command role="hg-cmd">hg copy</command>, dobbiamo usare l'opzione <option role="hg-opt-status">-C</option> del comando <command role="hg-cmd">hg status</command> per vedere che Mercurial considera il file aggiunto come una copia del file originale ora rimosso.</para> 11.155 + <para id="x_1d5">Come accade per i risultati del comando <command role="hg-cmd">hg copy</command>, dobbiamo usare l’opzione <option role="hg-opt-status">-C</option> del comando <command role="hg-cmd">hg status</command> per vedere che Mercurial considera il file aggiunto come una copia del file originale ora rimosso.</para> 11.156 11.157 &interaction.daily.rename.status-copy; 11.158 11.159 - <para id="x_1d6">Come con <command role="hg-cmd">hg remove</command> e <command role="hg-cmd">hg copy</command>, potete usare l'opzione <option role="hg-opt-rename">--after</option> per informare Mercurial del cambiamento di nome dopo che il fatto è avvenuto. Nella maggior parte degli altri aspetti, il comportamento del comando <command role="hg-cmd">hg rename</command> e le opzioni che accetta sono simili a quelli del comando <command role="hg-cmd">hg copy</command>.</para> 11.160 + <para id="x_1d6">Come con <command role="hg-cmd">hg remove</command> e <command role="hg-cmd">hg copy</command>, potete usare l’opzione <option role="hg-opt-rename">--after</option> per informare Mercurial del cambiamento di nome dopo che il fatto è avvenuto. Nella maggior parte degli altri aspetti, il comportamento del comando <command role="hg-cmd">hg rename</command> e le opzioni che accetta sono simili a quelli del comando <command role="hg-cmd">hg copy</command>.</para> 11.161 11.162 <para id="x_686">Se avete familiarità con la riga di comando Unix, sarete felici di sapere che il comando <command role="hg-cmd">hg rename</command> può essere invocato come <command role="hg-cmd">hg mv</command>.</para> 11.163 11.164 <sect2> 11.165 <title>Rinominare i file e unire i cambiamenti</title> 11.166 11.167 - <para id="x_1d7">Dato che Mercurial rinomina i file tramite un'operazione di copia-e-rimozione, i cambiamenti vengono propagati nello stesso modo quando effettuate un'unione sia dopo aver copiato un file che dopo averlo rinominato.</para> 11.168 + <para id="x_1d7">Dato che Mercurial rinomina i file tramite un’operazione di copia-e-rimozione, i cambiamenti vengono propagati nello stesso modo quando effettuate un’unione sia dopo aver copiato un file che dopo averlo rinominato.</para> 11.169 11.170 <para id="x_1d8">Se io modifico un file e voi lo rinominate e poi uniamo i nostri rispettivi cambiamenti, le mie modifiche al file con il suo nome originale verranno propagate al file con il suo nuovo nome. (Vi potreste aspettare che questo <quote>funzioni e basta</quote> ma in realtà non tutti i sistemi di controllo di revisione lo fanno.)</para> 11.171 11.172 @@ -240,23 +240,23 @@ 11.173 11.174 <para id="x_1dd">Mi piace pensare a questo come a un conflitto perché entrambi gli sviluppatori hanno espresso intenzioni differenti a proposito di come il file dovrebbe essere chiamato.</para> 11.175 11.176 - <para id="x_1de">Cosa pensate che dovrebbe accadere quando Anna e Bruno uniscono il loro lavoro? L'effettivo comportamento di Mercurial è quello di preservare sempre <emphasis>entrambi</emphasis> i nomi quando unisce changeset che contengono cambiamenti di nome divergenti.</para> 11.177 + <para id="x_1de">Cosa pensate che dovrebbe accadere quando Anna e Bruno uniscono il loro lavoro? L’effettivo comportamento di Mercurial è quello di preservare sempre <emphasis>entrambi</emphasis> i nomi quando unisce changeset che contengono cambiamenti di nome divergenti.</para> 11.178 11.179 &interaction.rename.divergent.merge; 11.180 11.181 - <para id="x_1df">Notate che, sebbene Mercurial vi avverta del cambiamento di nome divergente, lascia che siate voi a riconciliare la divergenza dopo l'unione.</para> 11.182 + <para id="x_1df">Notate che, sebbene Mercurial vi avverta del cambiamento di nome divergente, lascia che siate voi a riconciliare la divergenza dopo l’unione.</para> 11.183 </sect2> 11.184 11.185 <sect2> 11.186 <title>Cambiamenti di nome convergenti e unioni</title> 11.187 11.188 - <para id="x_1e0">Un altro tipo di conflitto tra i cambiamenti di nome avviene quando due persone rinominano differenti file <emphasis>sorgente</emphasis> alla stessa <emphasis>destinazione</emphasis>. In questo caso, Mercurial esegue l'unione normalmente e lascia che siate voi a guidarlo verso una risoluzione ragionevole.</para> 11.189 + <para id="x_1e0">Un altro tipo di conflitto tra i cambiamenti di nome avviene quando due persone rinominano differenti file <emphasis>sorgente</emphasis> alla stessa <emphasis>destinazione</emphasis>. In questo caso, Mercurial esegue l’unione normalmente e lascia che siate voi a guidarlo verso una risoluzione ragionevole.</para> 11.190 </sect2> 11.191 11.192 <sect2> 11.193 <title>Altri casi particolari legati ai nomi</title> 11.194 11.195 - <para id="x_1e1">Mercurial soffre di un bug noto da tempo che gli impedisce di portare a termine un'unione in cui una parte contiene un file con un certo nome mentre l'altra contiene una directory con lo stesso nome. Questo è documentato come <ulink role="hg-bug" url="http://www.selenic.com/mercurial/bts/issue29">problema 29</ulink>.</para> 11.196 + <para id="x_1e1">Mercurial soffre di un bug noto da tempo che gli impedisce di portare a termine un’unione in cui una parte contiene un file con un certo nome mentre l’altra contiene una directory con lo stesso nome. Questo è documentato come <ulink role="hg-bug" url="http://www.selenic.com/mercurial/bts/issue29">problema 29</ulink>.</para> 11.197 11.198 &interaction.issue29.go; 11.199 11.200 @@ -278,7 +278,7 @@ 11.201 <sect1> 11.202 <title>Affrontare unioni complesse</title> 11.203 11.204 - <para id="x_687">In un progetto grande o complicato, può capitare che l'unione tra due changeset provochi qualche mal di testa. Supponete che ci sia un file sorgente di grandi dimensioni che è stato ampiamente modificato da entrambe le parti di un'unione: quasi inevitabilmente, questo risulterà in conflitti, alcuni dei quali potrebbero avere bisogno di più di un tentativo per venire risolti.</para> 11.205 + <para id="x_687">In un progetto grande o complicato, può capitare che l’unione tra due changeset provochi qualche mal di testa. Supponete che ci sia un file sorgente di grandi dimensioni che è stato ampiamente modificato da entrambe le parti di un’unione: quasi inevitabilmente, questo risulterà in conflitti, alcuni dei quali potrebbero avere bisogno di più di un tentativo per venire risolti.</para> 11.206 11.207 <para id="x_688">Costruiamoci un semplice esempio di questa eventualità e vediamo come affrontarlo. Cominceremo con un repository contenente un file e lo cloneremo due volte.</para> 11.208 11.209 @@ -288,7 +288,7 @@ 11.210 11.211 &interaction.ch04-resolve.left; 11.212 11.213 - <para id="x_68a">Nell'altro, modificheremo il file in modo differente.</para> 11.214 + <para id="x_68a">Nell’altro, modificheremo il file in modo differente.</para> 11.215 11.216 &interaction.ch04-resolve.right; 11.217 11.218 @@ -300,17 +300,17 @@ 11.219 11.220 &interaction.ch04-resolve.heads; 11.221 11.222 - <para id="x_68d">Normalmente, se eseguissimo il comando <command role="hg-cmd">hg merge</command> a questo punto, ci verrebbe presentata un'applicazione grafica tramite la quale riconciliare manualmente le modifiche in conflitto su <filename>miofile.txt</filename>. Tuttavia, per semplificare le cose ai fini della presentazione, vorremmo invece che l'unione fallisse immediatamente. Ecco un modo in cui possiamo farlo.</para> 11.223 + <para id="x_68d">Normalmente, se eseguissimo il comando <command role="hg-cmd">hg merge</command> a questo punto, ci verrebbe presentata un’applicazione grafica tramite la quale riconciliare manualmente le modifiche in conflitto su <filename>miofile.txt</filename>. Tuttavia, per semplificare le cose ai fini della presentazione, vorremmo invece che l’unione fallisse immediatamente. Ecco un modo in cui possiamo farlo.</para> 11.224 11.225 &interaction.ch04-resolve.export; 11.226 11.227 - <para id="x_68e">Abbiamo chiesto al meccanismo di unione di Mercurial di eseguire il comando <command>false</command> (che, come desideriamo, fallisce immediatamente) se si accorge di non riuscire a risolvere un'unione automaticamente.</para> 11.228 + <para id="x_68e">Abbiamo chiesto al meccanismo di unione di Mercurial di eseguire il comando <command>false</command> (che, come desideriamo, fallisce immediatamente) se si accorge di non riuscire a risolvere un’unione automaticamente.</para> 11.229 11.230 <para id="x_68f">Se ora lanciamo <command role="hg-cmd">hg merge</command>, il comando dovrebbe fermarsi e riportare un fallimento.</para> 11.231 11.232 &interaction.ch04-resolve.merge; 11.233 11.234 - <para id="x_690">Se anche non avessimo notato che l'unione è fallita, Mercurial eviterà di farci accidentalmente inserire nel repository i risultati di un'unione fallita.</para> 11.235 + <para id="x_690">Se anche non avessimo notato che l’unione è fallita, Mercurial eviterà di farci accidentalmente inserire nel repository i risultati di un’unione fallita.</para> 11.236 11.237 &interaction.ch04-resolve.cifail; 11.238 11.239 @@ -319,7 +319,7 @@ 11.240 <sect2> 11.241 <title>Gli stati di risoluzione di un file</title> 11.242 11.243 - <para id="x_692">Quando avviene un'unione, di solito la maggior parte dei file rimarrà tale e quale. Mercurial terrà traccia dello stato di ogni file su cui deve operare.</para> 11.244 + <para id="x_692">Quando avviene un’unione, di solito la maggior parte dei file rimarrà tale e quale. Mercurial terrà traccia dello stato di ogni file su cui deve operare.</para> 11.245 11.246 <itemizedlist> 11.247 <listitem> 11.248 @@ -330,34 +330,34 @@ 11.249 </listitem> 11.250 </itemizedlist> 11.251 11.252 - <para id="x_695">Se Mercurial vede un <emphasis>qualsiasi</emphasis> file nello stato irrisolto dopo un'unione, considera fallita l'unione. Fortunatamente, non abbiamo bisogno di ricominciare l'intera unione da zero.</para> 11.253 - 11.254 - <para id="x_696">L'opzione <option role="hg-opt-resolve">--list</option> o <option role="hg-opt-resolve">-l</option> del comando <command role="hg-cmd">hg resolve</command> mostra lo stato di ogni file coinvolto in un'unione.</para> 11.255 + <para id="x_695">Se Mercurial vede un <emphasis>qualsiasi</emphasis> file nello stato irrisolto dopo un’unione, considera fallita l’unione. Fortunatamente, non abbiamo bisogno di ricominciare l’intera unione da zero.</para> 11.256 + 11.257 + <para id="x_696">L’opzione <option role="hg-opt-resolve">--list</option> o <option role="hg-opt-resolve">-l</option> del comando <command role="hg-cmd">hg resolve</command> mostra lo stato di ogni file coinvolto in un’unione.</para> 11.258 11.259 &interaction.ch04-resolve.list; 11.260 11.261 - <para id="x_697">Nell'elenco stampato da <command role="hg-cmd">hg resolve</command>, un file risolto è contrassegnato con una <literal>R</literal> mentre un file irrisolto è contrassegnato con una <literal>U</literal>. Se un file qualsiasi viene elencato con una <literal>U</literal>, sappiamo che un tentativo di inserire i risultati dell'unione nel repository andrà incontro al fallimento.</para> 11.262 - </sect2> 11.263 - 11.264 - <sect2> 11.265 - <title>Risolvere un'unione di file</title> 11.266 - 11.267 - <para id="x_698">Abbiamo diverse opzioni per far passare un file dallo stato irrisolto a quello risolto. Quella di gran lunga più comune consiste nell'eseguire nuovamente <command role="hg-cmd">hg resolve</command>. Se passiamo i nomi di singoli file o directory, il comando riproverà a unire i file irrisolti presenti in quelle ubicazioni. Possiamo anche passare l'opzione <option role="hg-opt-resolve">--all</option> o <option role="hg-opt-resolve">-a</option> per riprovare a unire <emphasis>tutti</emphasis> i file irrisolti.</para> 11.268 - 11.269 - <para id="x_699">Mercurial ci permette anche di modificare direttamente lo stato di risoluzione di un file. Possiamo contrassegnare manualmente un file come risolto usando l'opzione <option role="hg-opt-resolve">--mark</option> o come irrisolto usando l'opzione <option role="hg-opt-resolve">--unmark</option>. Questo ci consente di ripulire a mano un'unione particolarmente disordinata e di tenere traccia dei nostri progressi con ogni file man mano che procediamo.</para> 11.270 + <para id="x_697">Nell’elenco stampato da <command role="hg-cmd">hg resolve</command>, un file risolto è contrassegnato con una <literal>R</literal> mentre un file irrisolto è contrassegnato con una <literal>U</literal>. Se un file qualsiasi viene elencato con una <literal>U</literal>, sappiamo che un tentativo di inserire i risultati dell’unione nel repository andrà incontro al fallimento.</para> 11.271 + </sect2> 11.272 + 11.273 + <sect2> 11.274 + <title>Risolvere un’unione di file</title> 11.275 + 11.276 + <para id="x_698">Abbiamo diverse opzioni per far passare un file dallo stato irrisolto a quello risolto. Quella di gran lunga più comune consiste nell’eseguire nuovamente <command role="hg-cmd">hg resolve</command>. Se passiamo i nomi di singoli file o directory, il comando riproverà a unire i file irrisolti presenti in quelle ubicazioni. Possiamo anche passare l’opzione <option role="hg-opt-resolve">--all</option> o <option role="hg-opt-resolve">-a</option> per riprovare a unire <emphasis>tutti</emphasis> i file irrisolti.</para> 11.277 + 11.278 + <para id="x_699">Mercurial ci permette anche di modificare direttamente lo stato di risoluzione di un file. Possiamo contrassegnare manualmente un file come risolto usando l’opzione <option role="hg-opt-resolve">--mark</option> o come irrisolto usando l’opzione <option role="hg-opt-resolve">--unmark</option>. Questo ci consente di ripulire a mano un’unione particolarmente disordinata e di tenere traccia dei nostri progressi con ogni file man mano che procediamo.</para> 11.279 </sect2> 11.280 </sect1> 11.281 11.282 <sect1> 11.283 <title>Formati di diff più utili</title> 11.284 11.285 - <para id="x_6c7">Il formato predefinito del testo stampato dal comando <command role="hg-cmd">hg diff</command> è compatibile all'indietro con il normale comando <command>diff</command>, ma questo presenta alcuni svantaggi.</para> 11.286 + <para id="x_6c7">Il formato predefinito del testo stampato dal comando <command role="hg-cmd">hg diff</command> è compatibile all’indietro con il normale comando <command>diff</command>, ma questo presenta alcuni svantaggi.</para> 11.287 11.288 <para id="x_6c8">Considerate il caso in cui si utilizzi <command role="hg-cmd">hg rename</command> per rinominare un file.</para> 11.289 11.290 &interaction.ch04-diff.rename.basic; 11.291 11.292 - <para id="x_6c9">Il risultato di <command role="hg-cmd">hg diff</command> mostrato qui sopra offusca il fatto che abbiamo semplicemente rinominato un file. Il comando <command role="hg-cmd">hg diff</command> accetta l'opzione <option>--git</option> o <option>-g</option> per usare un formato di diff più nuovo che presenta queste informazioni in una forma più leggibile.</para> 11.293 + <para id="x_6c9">Il risultato di <command role="hg-cmd">hg diff</command> mostrato qui sopra offusca il fatto che abbiamo semplicemente rinominato un file. Il comando <command role="hg-cmd">hg diff</command> accetta l’opzione <option>--git</option> o <option>-g</option> per usare un formato di diff più nuovo che presenta queste informazioni in una forma più leggibile.</para> 11.294 11.295 &interaction.ch04-diff.rename.git; 11.296 11.297 @@ -365,7 +365,7 @@ 11.298 11.299 &interaction.ch04-diff.chmod; 11.300 11.301 - <para id="x_6cb">Il normale comando <command>diff</command> non considera i permessi dei file, perciò la semplice invocazione di <command role="hg-cmd">hg diff</command> non stampa nulla. Se però utilizziamo l'opzione <option>-g</option>, il comando ci dice che cos'è realmente accaduto.</para> 11.302 + <para id="x_6cb">Il normale comando <command>diff</command> non considera i permessi dei file, perciò la semplice invocazione di <command role="hg-cmd">hg diff</command> non stampa nulla. Se però utilizziamo l’opzione <option>-g</option>, il comando ci dice che cos’è realmente accaduto.</para> 11.303 11.304 &interaction.ch04-diff.chmod.git; 11.305 </sect1> 11.306 @@ -373,7 +373,7 @@ 11.307 <sect1> 11.308 <title>Quali file gestire e quali file evitare</title> 11.309 11.310 - <para id="x_6cc">Generalmente, i sistemi di controllo di revisione danno il meglio nella gestione dei file di testo scritti da esseri umani, come il codice sorgente, i cui file non cambiano molto da una revisione all'altra. Alcuni sistemi centralizzati di controllo di revisione possono anche destreggiarsi abbastanza bene con i file binari, come le immagini bitmap.</para> 11.311 + <para id="x_6cc">Generalmente, i sistemi di controllo di revisione danno il meglio nella gestione dei file di testo scritti da esseri umani, come il codice sorgente, i cui file non cambiano molto da una revisione all’altra. Alcuni sistemi centralizzati di controllo di revisione possono anche destreggiarsi abbastanza bene con i file binari, come le immagini bitmap.</para> 11.312 11.313 <para id="x_6cd">Per esempio, gli sviluppatori di un gioco dovranno tipicamente gestire sia il proprio codice sorgente sia le proprie risorse binarie (e.g. dati geometrici, texture, schemi di mappe) attraverso un sistema di controllo di revisione.</para> 11.314 11.315 @@ -385,9 +385,9 @@ 11.316 11.317 <para id="x_6d1">Quando Mercurial memorizza le modifiche a un file, di solito salva solo le differenze tra la versione corrente del file e quella precedente. Per la maggior parte dei file di testo questo approccio si rivela estremamente efficiente. Tuttavia, alcuni file (in particolare i file binari) sono fatti in modo tale che persino una piccola modifica al contenuto logico del file risulta nel cambiamento di molti o della maggior parte dei byte contenuti nel file. Per esempio, i file compressi sono particolarmente sensibili a questo effetto. Se le differenze tra ogni versione di un file e la successiva sono sempre grandi, Mercurial non riuscirà a memorizzare la cronologia del file in maniera molto efficiente. Questo potrebbe avere effetti sia sul bisogno di spazio di memorizzazione locale sia sulla quantità di tempo che viene impiegata per clonare un repository.</para> 11.318 11.319 - <para id="x_6d2">Per avere un'idea di come questo problema potrebbe riguardarvi nella pratica, supponete di voler usare Mercurial per gestire un documento OpenOffice. OpenOffice memorizza i documenti su disco sotto forma di file ZIP compressi. Modificate anche solo una lettera nel vostro documento in OpenOffice e quasi ogni byte nell'intero file cambierà quando lo salverete. Ora supponete che le dimensioni di quel file siano pari a 2MB. Dato che la maggior parte del file cambia ogni volta che lo salvate, Mercurial dovrà memorizzare tutti i 2MB del file ogni volta che eseguite un commit, anche se dal vostro punto di vista forse solo poche parole vengono cambiate ogni volta. Un singolo file modificato frequentemente che non rispetti le assunzioni dei meccanismi di memorizzazione di Mercurial può facilmente avere un effetto fuori misura sulle dimensioni del repository.</para> 11.320 - 11.321 - <para id="x_6d3">Di male in peggio, se due di voi modificano il documento OpenOffice su cui state lavorando, non c'è alcun modo utile di effettuare un'unione tra le diverse versioni. In effetti, non c'è nemmeno un buon modo di capire quali sono le differenze tra i vostri rispettivi cambiamenti.</para> 11.322 + <para id="x_6d2">Per avere un’idea di come questo problema potrebbe riguardarvi nella pratica, supponete di voler usare Mercurial per gestire un documento OpenOffice. OpenOffice memorizza i documenti su disco sotto forma di file ZIP compressi. Modificate anche solo una lettera nel vostro documento in OpenOffice e quasi ogni byte nell’intero file cambierà quando lo salverete. Ora supponete che le dimensioni di quel file siano pari a 2MB. Dato che la maggior parte del file cambia ogni volta che lo salvate, Mercurial dovrà memorizzare tutti i 2MB del file ogni volta che eseguite un commit, anche se dal vostro punto di vista forse solo poche parole vengono cambiate ogni volta. Un singolo file modificato frequentemente che non rispetti le assunzioni dei meccanismi di memorizzazione di Mercurial può facilmente avere un effetto fuori misura sulle dimensioni del repository.</para> 11.323 + 11.324 + <para id="x_6d3">Di male in peggio, se due di voi modificano il documento OpenOffice su cui state lavorando, non c’è alcun modo utile di effettuare un’unione tra le diverse versioni. In effetti, non c’è nemmeno un buon modo di capire quali sono le differenze tra i vostri rispettivi cambiamenti.</para> 11.325 11.326 <para id="x_6d4">Quindi, ci sono alcune chiare raccomandazioni da fare sui tipi di file ai quali dovete stare molto attenti.</para> 11.327 11.328 @@ -404,12 +404,12 @@ 11.329 <sect1> 11.330 <title>Realizzare backup e mirror</title> 11.331 11.332 - <para id="x_6d7">Dato che Mercurial mantiene una copia completa della cronologia in ogni clone, chiunque usi Mercurial per collaborare su un progetto può potenzialmente agire come una sorgente di backup nell'eventualità di una catastrofe. Se un repository centrale diventa inaccessibile, potete costruire un rimpiazzo semplicemente clonando una copia del repository da un collaboratore ed estraendo dai repository di altre persone qualsiasi cambiamento che quella copia potrebbe non avere visto.</para> 11.333 - 11.334 - <para id="x_6d8">Usare Mercurial per effettuare backup separati e mirror remoti è piuttosto semplice. Impostate un'attività periodica (e.g. tramite il comando <command>cron</command>) su un server remoto per estrarre i cambiamenti dai vostri repository principali ogni ora. Questa operazione diventerà complicata solo nell'improbabile caso in cui il numero dei repository principali che mantenete cambi frequentemente, eventualità che potrete affrontare utilizzando uno script per programmare l'aggiornamento della lista dei repository di cui fare il backup.</para> 11.335 - 11.336 - <para id="x_6d9">Se effettuate un backup tradizionale dei vostri repository principali su nastro o su disco e volete fare il backup di un repository chiamato <filename>miorepo</filename>, usate il comando <command>hg clone -U miorepo miorepo.bak</command> per creare un clone di <filename>miorepo</filename> prima di cominciare a registrare i vostri backup. L'opzione <option>-U</option> evita di popolare la directory di lavoro dopo che la clonazione si è conclusa, dato che sarebbe superfluo e renderebbe più lungo il backup.</para> 11.337 - 11.338 - <para id="x_6da">Se poi effettuate il backup di <filename>miorepo.bak</filename> invece di <filename>miorepo</filename>, avrete la garanzia di possedere una fotografia consistente del vostro repository a cui nessuno sviluppatore insonne trasmetterà i propri cambiamenti nel bel mezzo di un'operazione di backup.</para> 11.339 + <para id="x_6d7">Dato che Mercurial mantiene una copia completa della cronologia in ogni clone, chiunque usi Mercurial per collaborare su un progetto può potenzialmente agire come una sorgente di backup nell’eventualità di una catastrofe. Se un repository centrale diventa inaccessibile, potete costruire un rimpiazzo semplicemente clonando una copia del repository da un collaboratore ed estraendo dai repository di altre persone qualsiasi cambiamento che quella copia potrebbe non avere visto.</para> 11.340 + 11.341 + <para id="x_6d8">Usare Mercurial per effettuare backup separati e mirror remoti è piuttosto semplice. Impostate un’attività periodica (e.g. tramite il comando <command>cron</command>) su un server remoto per estrarre i cambiamenti dai vostri repository principali ogni ora. Questa operazione diventerà complicata solo nell’improbabile caso in cui il numero dei repository principali che mantenete cambi frequentemente, eventualità che potrete affrontare utilizzando uno script per programmare l’aggiornamento della lista dei repository di cui fare il backup.</para> 11.342 + 11.343 + <para id="x_6d9">Se effettuate un backup tradizionale dei vostri repository principali su nastro o su disco e volete fare il backup di un repository chiamato <filename>miorepo</filename>, usate il comando <command>hg clone -U miorepo miorepo.bak</command> per creare un clone di <filename>miorepo</filename> prima di cominciare a registrare i vostri backup. L’opzione <option>-U</option> evita di popolare la directory di lavoro dopo che la clonazione si è conclusa, dato che sarebbe superfluo e renderebbe più lungo il backup.</para> 11.344 + 11.345 + <para id="x_6da">Se poi effettuate il backup di <filename>miorepo.bak</filename> invece di <filename>miorepo</filename>, avrete la garanzia di possedere una fotografia consistente del vostro repository a cui nessuno sviluppatore insonne trasmetterà i propri cambiamenti nel bel mezzo di un’operazione di backup.</para> 11.346 </sect1> 11.347 </chapter>
12.1 --- a/it/ch06-collab.xml Sat Aug 22 21:01:56 2009 +0200 12.2 +++ b/it/ch06-collab.xml Sat Aug 22 21:55:05 2009 +0200 12.3 @@ -5,23 +5,23 @@ 12.4 <para id="x_44a">Essendo uno strumento completamente decentralizzato, Mercurial non impone alcuna politica su come le persone dovrebbero lavorare insieme. Tuttavia, se per voi il controllo di revisione distribuito è una novità, conoscere alcuni strumenti ed esempi può aiutarvi a ragionare sui possibili modelli di workflow (letteralmente, flusso di lavoro) da adottare.</para> 12.5 12.6 <sect1> 12.7 - <title>L'interfaccia web di Mercurial</title> 12.8 + <title>L’interfaccia web di Mercurial</title> 12.9 12.10 <para id="x_44b">Mercurial è dotato di una potente interfaccia web che possiede diverse caratteristiche utili.</para> 12.11 12.12 - <para id="x_44c">L'interfaccia web vi permette di navigare interattivamente un singolo repository o una collezione di repository. Potete vedere la cronologia di un repository, esaminare qualsiasi cambiamento (con i commenti e le differenze) e vedere il contenuto di qualsiasi file o directory. Potete persino ottenere una vista della cronologia che vi fornisce una rappresentazione grafica delle relazioni tra le unioni e i singoli cambiamenti.</para> 12.13 - 12.14 - <para id="x_44d">L'interfaccia web offre ai visitatori anche i feed RSS e Atom dei cambiamenti in un repository. Questo vi permette di <quote>abbonarvi</quote> a un repository usando il vostro lettore di feed preferito e di venire automaticamente informati sulle attività in quel repository non appena vengono compiute. Trovo questa possibilità molto più conveniente rispetto al modello di iscrizione a una mailing list a cui sono spedite le notifiche, in quanto non richiede alcuna configurazione aggiuntiva da parte di chiunque stia condividendo il repository.</para> 12.15 - 12.16 - <para id="x_44e">L'interfaccia web consente agli utenti remoti anche di clonare un repository, estrarne i cambiamenti e (quando il server è configurato per permetterlo) trasmettervi le proprie modifiche. Mercurial comprime aggressivamente i dati incapsulando il protocollo HTTP in modo da lavorare con grande efficienza persino attraverso connessioni di rete a banda ridotta.</para> 12.17 - 12.18 - <para id="x_44f">Il modo più facile di cominciare a usare l'interfaccia web è quello di aprire il vostro browser per visitare un repository esistente, come il repository principale di Mercurial all'indirizzo <ulink url="http://www.selenic.com/repo/hg">http://www.selenic.com/repo/hg</ulink>.</para> 12.19 - 12.20 - <para id="x_450">Se siete interessati a fornire un'interfaccia web ai vostri repository, esistono diversi buoni modi per farlo.</para> 12.21 + <para id="x_44c">L’interfaccia web vi permette di navigare interattivamente un singolo repository o una collezione di repository. Potete vedere la cronologia di un repository, esaminare qualsiasi cambiamento (con i commenti e le differenze) e vedere il contenuto di qualsiasi file o directory. Potete persino ottenere una vista della cronologia che vi fornisce una rappresentazione grafica delle relazioni tra le unioni e i singoli cambiamenti.</para> 12.22 + 12.23 + <para id="x_44d">L’interfaccia web offre ai visitatori anche i feed RSS e Atom dei cambiamenti in un repository. Questo vi permette di <quote>abbonarvi</quote> a un repository usando il vostro lettore di feed preferito e di venire automaticamente informati sulle attività in quel repository non appena vengono compiute. Trovo questa possibilità molto più conveniente rispetto al modello di iscrizione a una mailing list a cui sono spedite le notifiche, in quanto non richiede alcuna configurazione aggiuntiva da parte di chiunque stia condividendo il repository.</para> 12.24 + 12.25 + <para id="x_44e">L’interfaccia web consente agli utenti remoti anche di clonare un repository, estrarne i cambiamenti e (quando il server è configurato per permetterlo) trasmettervi le proprie modifiche. Mercurial comprime aggressivamente i dati incapsulando il protocollo HTTP in modo da lavorare con grande efficienza persino attraverso connessioni di rete a banda ridotta.</para> 12.26 + 12.27 + <para id="x_44f">Il modo più facile di cominciare a usare l’interfaccia web è quello di aprire il vostro browser per visitare un repository esistente, come il repository principale di Mercurial all’indirizzo <ulink url="http://www.selenic.com/repo/hg">http://www.selenic.com/repo/hg</ulink>.</para> 12.28 + 12.29 + <para id="x_450">Se siete interessati a fornire un’interfaccia web ai vostri repository, esistono diversi buoni modi per farlo.</para> 12.30 12.31 <para id="x_69d">In un ambiente informale, il modo più facile e veloce di cominciare è quello di usare il comando <command role="hg-cmd">hg serve</command>, che è particolarmente adatto per offrire un servizio <quote>leggero</quote> a breve termine. Leggete la <xref linkend="sec:collab:serve"/> più avanti per i dettagli su come usare questo comando.</para> 12.32 12.33 - <para id="x_69e">Per repository destinati a progetti di lunga durata che vorreste mantenere disponibili permanentemente, potete rivolgervi ai diversi servizi di hosting pubblici esistenti. Alcuni ospitano gratuitamente i progetti open source, mentre altri offrono un hosting commerciale a pagamento. Una lista aggiornata di questi servizi è disponibile all'indirizzo <ulink url="http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting">http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting</ulink>.</para> 12.34 + <para id="x_69e">Per repository destinati a progetti di lunga durata che vorreste mantenere disponibili permanentemente, potete rivolgervi ai diversi servizi di hosting pubblici esistenti. Alcuni ospitano gratuitamente i progetti open source, mentre altri offrono un hosting commerciale a pagamento. Una lista aggiornata di questi servizi è disponibile all’indirizzo <ulink url="http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting">http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting</ulink>.</para> 12.35 12.36 <para id="x_6a0">Se invece preferite tenere i repository sui vostri server, Mercurial è dotato di un supporto predefinito per diverse tecnologie di hosting popolari, in particolar modo CGI (acronimo di Common Gateway Interface, interfaccia di gateway comune) e WSGI (acronimo di Web Server Gateway Interface, interfaccia di gateway per server web). Leggete la <xref linkend="sec:collab:cgi"/> per i dettagli sulle configurazioni di CGI e WSGI.</para> 12.37 </sect1> 12.38 @@ -34,11 +34,11 @@ 12.39 <sect2> 12.40 <title>Fattori da considerare</title> 12.41 12.42 - <para id="x_452">L'aspetto più importante che dovete tenere presente per qualsiasi modello è il grado di conformità ai bisogni e alle capacità delle persone che lo useranno. Questo potrebbe sembrare ovvio, ma in ogni caso non potete comunque permettervi di dimenticarvelo nemmeno per un momento.</para> 12.43 + <para id="x_452">L’aspetto più importante che dovete tenere presente per qualsiasi modello è il grado di conformità ai bisogni e alle capacità delle persone che lo useranno. Questo potrebbe sembrare ovvio, ma in ogni caso non potete comunque permettervi di dimenticarvelo nemmeno per un momento.</para> 12.44 12.45 <para id="x_453">Una volta mi capitò di comporre un modello di workflow che a me sembrava perfettamente sensato, ma che provocò una notevole quantità di litigi e parecchia costernazione tra i membri del mio gruppo di sviluppo. Nonostante i miei tentativi di spiegare perché avessimo bisogno di un insieme complesso di ramificazioni e come i cambiamenti dovessero circolare tra i rami, alcuni membri del gruppo si ribellarono. Sebbene fossero persone intelligenti, non volevano fare attenzione ai vincoli sotto i quali stavamo operando, né affrontare le conseguenze di quei vincoli sui dettagli del modello che stavo difendendo.</para> 12.46 12.47 - <para id="x_454">Evitate di nascondere sotto il tappeto i prevedibili problemi di tipo tecnico o sociale. Qualunque schema adottiate, dovreste avere un piano per affrontare errori e scenari problematici. Prendete in considerazione l'idea di aggiungere meccanismi automatici per prevenire o risolvere velocemente i problemi che siete in grado di anticipare. Per esempio, se intendete avere un ramo con cambiamenti che non desiderate rilasciare al pubblico, fareste meglio a pensare fin dall'inizio alla possibilità che qualcuno possa accidentalmente incorporare quei cambiamenti in un ramo di release. Potete evitare questo particolare problema implementando un hook che prevenga l'unione di cambiamenti da rami non appropriati.</para> 12.48 + <para id="x_454">Evitate di nascondere sotto il tappeto i prevedibili problemi di tipo tecnico o sociale. Qualunque schema adottiate, dovreste avere un piano per affrontare errori e scenari problematici. Prendete in considerazione l’idea di aggiungere meccanismi automatici per prevenire o risolvere velocemente i problemi che siete in grado di anticipare. Per esempio, se intendete avere un ramo con cambiamenti che non desiderate rilasciare al pubblico, fareste meglio a pensare fin dall’inizio alla possibilità che qualcuno possa accidentalmente incorporare quei cambiamenti in un ramo di release. Potete evitare questo particolare problema implementando un hook che prevenga l’unione di cambiamenti da rami non appropriati.</para> 12.49 </sect2> 12.50 12.51 <sect2> 12.52 @@ -46,11 +46,11 @@ 12.53 12.54 <para id="x_455">Non vorrei suggerire che un approccio in cui <quote>tutto è permesso</quote> sia qualcosa di sostenibile, ma è un modello che è facile da capire e funziona perfettamente in alcune situazioni inusuali.</para> 12.55 12.56 - <para id="x_456">Per esempio, molti progetti hanno un gruppo sparpagliato di collaboratori che si incontrano fisicamente solo di rado. Alcuni gruppi preferiscono superare l'isolamento del lavoro a distanza organizzando <quote>maratone</quote> occasionali in cui un certo numero di persone si ritrova insieme in un'unico luogo (la stanza delle riunioni di un'azienda, la sala delle conferenze in un hotel, posti di questo tipo) e passa diversi giorni più o meno chiuso lì, a lavorare intensamente su una manciata di progetti.</para> 12.57 - 12.58 - <para id="x_457">Una maratona o una sessione di programmazione in un locale sono le occasioni perfette per usare il comando <command role="hg-cmd">hg serve</command>, dato che <command role="hg-cmd">hg serve</command> non richiede alcuna infrastruttura server elaborata. Potete cominciare a usare <command role="hg-cmd">hg serve</command> in pochi minuti, leggendo la <xref linkend="sec:collab:serve"/> più avanti. Poi vi basta comunicare ai vostri vicini l'esistenza di un server in esecuzione, fargli sapere l'URL a cui devono collegarsi, e avrete un modo rapido da predisporre per lavorare insieme. Gli altri potranno digitare il vostro URL nel proprio browser e revisionare velocemente i vostri cambiamenti, o estrarre la correzione di un bug dal vostro repository e verificarla, o clonare un ramo contenente una nuova funzione e provarla.</para> 12.59 - 12.60 - <para id="x_458">Il fascino, e allo stesso tempo il problema, di fare le cose ad hoc in questo modo è che solo le persone che sanno dell'esistenza dei vostri cambiamenti e sanno dove trovarli possono vederli. Un approccio informale di questo tipo non riesce proprio a scalare oltre una manciata di persone, perché ogni individuo ha bisogno di conoscere <emphasis>n</emphasis> diversi repository da cui estrarre modifiche.</para> 12.61 + <para id="x_456">Per esempio, molti progetti hanno un gruppo sparpagliato di collaboratori che si incontrano fisicamente solo di rado. Alcuni gruppi preferiscono superare l’isolamento del lavoro a distanza organizzando <quote>maratone</quote> occasionali in cui un certo numero di persone si ritrova insieme in un’unico luogo (la stanza delle riunioni di un’azienda, la sala delle conferenze in un hotel, posti di questo tipo) e passa diversi giorni più o meno chiuso lì, a lavorare intensamente su una manciata di progetti.</para> 12.62 + 12.63 + <para id="x_457">Una maratona o una sessione di programmazione in un locale sono le occasioni perfette per usare il comando <command role="hg-cmd">hg serve</command>, dato che <command role="hg-cmd">hg serve</command> non richiede alcuna infrastruttura server elaborata. Potete cominciare a usare <command role="hg-cmd">hg serve</command> in pochi minuti, leggendo la <xref linkend="sec:collab:serve"/> più avanti. Poi vi basta comunicare ai vostri vicini l’esistenza di un server in esecuzione, fargli sapere l’URL a cui devono collegarsi, e avrete un modo rapido da predisporre per lavorare insieme. Gli altri potranno digitare il vostro URL nel proprio browser e revisionare velocemente i vostri cambiamenti, o estrarre la correzione di un bug dal vostro repository e verificarla, o clonare un ramo contenente una nuova funzione e provarla.</para> 12.64 + 12.65 + <para id="x_458">Il fascino, e allo stesso tempo il problema, di fare le cose ad hoc in questo modo è che solo le persone che sanno dell’esistenza dei vostri cambiamenti e sanno dove trovarli possono vederli. Un approccio informale di questo tipo non riesce proprio a scalare oltre una manciata di persone, perché ogni individuo ha bisogno di conoscere <emphasis>n</emphasis> diversi repository da cui estrarre modifiche.</para> 12.66 </sect2> 12.67 12.68 <sect2> 12.69 @@ -68,7 +68,7 @@ 12.70 <sect2> 12.71 <title>Un repository centrale su un servizio di hosting</title> 12.72 12.73 - <para id="x_6a1">Una caratteristica meravigliosa dei servizi di hosting come <ulink url="http://bitbucket.org/">Bitbucket</ulink> è che non solo si occupano di gestire i dettagli della configurazione del server, come gli account utente, l'autenticazione e i protocolli sicuri di rete, ma offrono anche un'infrastruttura aggiuntiva per far funzionare al meglio questo modello.</para> 12.74 + <para id="x_6a1">Una caratteristica meravigliosa dei servizi di hosting come <ulink url="http://bitbucket.org/">Bitbucket</ulink> è che non solo si occupano di gestire i dettagli della configurazione del server, come gli account utente, l’autenticazione e i protocolli sicuri di rete, ma offrono anche un’infrastruttura aggiuntiva per far funzionare al meglio questo modello.</para> 12.75 12.76 <para id="x_6a2">Per esempio, un servizio di hosting ben ingegnerizzato consentirà agli sviluppatori di clonare le proprie copie di un repository con un singolo clic, in modo da farli lavorare in spazi separati e lasciarli condividere i propri cambiamenti quando sono pronti.</para> 12.77 12.78 @@ -78,9 +78,9 @@ 12.79 <sect2> 12.80 <title>Lavorare con più rami</title> 12.81 12.82 - <para id="x_45d">Qualsiasi progetto di dimensioni significative tende a fare progressi su più fronti contemporaneamente. Nel caso del software, un progetto passa comunemente attraverso una serie di release ufficiali periodiche. Una release potrebbe andare in fase di <quote>manutenzione</quote> per un po' dopo la sua prima pubblicazione, finendo per contenere solo correzioni di bug, senza che vengano aggiunte nuove funzioni. Una o più release future potrebbero trovarsi in lavorazione in parallelo a queste revisioni di manutenzione. Normalmente le persone usano il termine <quote>ramo</quote> (in inglese, branch) per indicare una di queste direzioni leggermente differenti in cui lo sviluppo sta procedendo.</para> 12.83 - 12.84 - <para id="x_45e">Mercurial è particolarmente adatto a gestire un certo numero di rami paralleli ma non identici. Ogni <quote>direzione di sviluppo</quote> può vivere nel proprio repository centrale e voi potete unire cambiamenti dall'uno all'altro repository quando ne avete bisogno. Dato che i repository sono tra loro indipendenti, i cambiamenti instabili in un ramo di sviluppo non avranno mai effetto su un ramo stabile a meno che qualcuno incorpori esplicitamente quei cambiamenti nel ramo stabile.</para> 12.85 + <para id="x_45d">Qualsiasi progetto di dimensioni significative tende a fare progressi su più fronti contemporaneamente. Nel caso del software, un progetto passa comunemente attraverso una serie di release ufficiali periodiche. Una release potrebbe andare in fase di <quote>manutenzione</quote> per un po’ dopo la sua prima pubblicazione, finendo per contenere solo correzioni di bug, senza che vengano aggiunte nuove funzioni. Una o più release future potrebbero trovarsi in lavorazione in parallelo a queste revisioni di manutenzione. Normalmente le persone usano il termine <quote>ramo</quote> (in inglese, branch) per indicare una di queste direzioni leggermente differenti in cui lo sviluppo sta procedendo.</para> 12.86 + 12.87 + <para id="x_45e">Mercurial è particolarmente adatto a gestire un certo numero di rami paralleli ma non identici. Ogni <quote>direzione di sviluppo</quote> può vivere nel proprio repository centrale e voi potete unire cambiamenti dall’uno all’altro repository quando ne avete bisogno. Dato che i repository sono tra loro indipendenti, i cambiamenti instabili in un ramo di sviluppo non avranno mai effetto su un ramo stabile a meno che qualcuno incorpori esplicitamente quei cambiamenti nel ramo stabile.</para> 12.88 12.89 <para id="x_45f">Ecco un esempio di come questo processo può funzionare in pratica. Diciamo che avete un <quote>ramo principale</quote> su un server centrale.</para> 12.90 12.91 @@ -96,7 +96,7 @@ 12.92 12.93 &interaction.branching.main; 12.94 12.95 - <para id="x_463">Grazie all'etichetta registrata sulla milestone, chi clonerà quel repository in futuro potrà usare <command role="hg-cmd">hg update</command> per ottenere una copia della directory di lavoro nello stato esatto in cui si trovava quando quella revisione etichettata è stata inserita.</para> 12.96 + <para id="x_463">Grazie all’etichetta registrata sulla milestone, chi clonerà quel repository in futuro potrà usare <command role="hg-cmd">hg update</command> per ottenere una copia della directory di lavoro nello stato esatto in cui si trovava quando quella revisione etichettata è stata inserita.</para> 12.97 12.98 &interaction.branching.update; 12.99 12.100 @@ -114,13 +114,13 @@ 12.101 12.102 &interaction.branching.merge; 12.103 12.104 - <para id="x_468">Il ramo principale conterrà ancora cambiamenti che non sono presenti nel ramo stabile, ma conterrà anche tutte le correzioni di bug provenienti dal ramo stabile. Il ramo stabile non viene toccato da quei cambiamenti, dato che le modifiche stanno passando solo dal ramo stabile a quello principale e non nell'altra direzione.</para> 12.105 + <para id="x_468">Il ramo principale conterrà ancora cambiamenti che non sono presenti nel ramo stabile, ma conterrà anche tutte le correzioni di bug provenienti dal ramo stabile. Il ramo stabile non viene toccato da quei cambiamenti, dato che le modifiche stanno passando solo dal ramo stabile a quello principale e non nell’altra direzione.</para> 12.106 </sect2> 12.107 12.108 <sect2> 12.109 <title>Rami di funzione</title> 12.110 12.111 - <para id="x_469">Per progetti di dimensioni più grandi, un modo efficace per gestire i cambiamenti è quello di dividere un gruppo in piccoli sottogruppi. Ogni sottogruppo gestisce un proprio ramo condiviso, clonato da un singolo ramo <quote>principale</quote> usato dall'intero progetto. Le persone che lavorano su un singolo ramo sono tipicamente piuttosto isolate dagli sviluppi che avvengono negli altri rami.</para> 12.112 + <para id="x_469">Per progetti di dimensioni più grandi, un modo efficace per gestire i cambiamenti è quello di dividere un gruppo in piccoli sottogruppi. Ogni sottogruppo gestisce un proprio ramo condiviso, clonato da un singolo ramo <quote>principale</quote> usato dall’intero progetto. Le persone che lavorano su un singolo ramo sono tipicamente piuttosto isolate dagli sviluppi che avvengono negli altri rami.</para> 12.113 12.114 <figure id="fig:collab:feature-branches"> 12.115 <title>Rami di funzione</title> 12.116 @@ -136,27 +136,27 @@ 12.117 <sect2> 12.118 <title>Il treno delle release</title> 12.119 12.120 - <para id="x_46c">L'organizzazione di alcuni progetti può ricordare quella di un <quote>treno</quote>: le release sono fissate a intervalli di alcuni mesi e includono tutte le funzioni che sono pronte quando il <quote>treno</quote> è pronto a partire.</para> 12.121 - 12.122 - <para id="x_46d">Questo modello assomiglia all'impiego dei rami di funzione, tranne per il fatto che quando un ramo di funzione perde un treno, qualche membro del gruppo di quella funzione estrae i cambiamenti che sono partiti con il treno della release e li unisce al ramo della funzione. Così, il gruppo continua a lavorare partendo da quella release, in modo che la funzione di cui è responsabile possa essere inclusa nella release successiva.</para> 12.123 + <para id="x_46c">L’organizzazione di alcuni progetti può ricordare quella di un <quote>treno</quote>: le release sono fissate a intervalli di alcuni mesi e includono tutte le funzioni che sono pronte quando il <quote>treno</quote> è pronto a partire.</para> 12.124 + 12.125 + <para id="x_46d">Questo modello assomiglia all’impiego dei rami di funzione, tranne per il fatto che quando un ramo di funzione perde un treno, qualche membro del gruppo di quella funzione estrae i cambiamenti che sono partiti con il treno della release e li unisce al ramo della funzione. Così, il gruppo continua a lavorare partendo da quella release, in modo che la funzione di cui è responsabile possa essere inclusa nella release successiva.</para> 12.126 </sect2> 12.127 12.128 <sect2> 12.129 <title>Il modello del kernel di Linux</title> 12.130 12.131 - <para id="x_46e">Il modello di sviluppo del kernel di Linux è caratterizzato da una struttura gerarchica poco profonda circondata da una nuvola di caos apparente. Dato che la maggior parte degli sviluppatori Linux usa <command>git</command>, uno strumento distribuito di controllo di revisione con caratteristiche simili a Mercurial, è utile descrivere come si lavora in quell'ambiente in modo che, se le idee vi piacciono, possiate tradurre il metodo da uno strumento all'altro.</para> 12.132 - 12.133 - <para id="x_46f">Al centro della comunità siede Linus Torvalds, il creatore di Linux. Linus pubblica un singolo repository di sorgenti che è considerato il ramo <quote>autoritativo</quote> corrente dall'intera comunità di sviluppo. Chiunque può clonare l'albero di Linus, ma Linus è piuttosto selettivo per quanto riguarda gli alberi da cui estrae le modifiche.</para> 12.134 - 12.135 - <para id="x_470">Linus ha un certo numero di <quote>luogotenenti di fiducia</quote>. Come regola generale, estrae qualunque cambiamento gli trasmettano, nella maggior parte dei casi senza nemmeno revisionare quelle modifiche. Alcuni di quei luogotenenti hanno accettato il ruolo di <quote>manutentori</quote> responsabili di specifici sottosistemi del kernel. Se un programmatore qualsiasi vuole che la propria modifica a un sottosistema del kernel finisca nell'albero di Linus, deve trovare il manutentore di quel sottosistema e chiedergli di accettarla. Se il manutentore revisiona le modifiche e accetta di prenderle, le passerà a Linus al momento giusto.</para> 12.136 + <para id="x_46e">Il modello di sviluppo del kernel di Linux è caratterizzato da una struttura gerarchica poco profonda circondata da una nuvola di caos apparente. Dato che la maggior parte degli sviluppatori Linux usa <command>git</command>, uno strumento distribuito di controllo di revisione con caratteristiche simili a Mercurial, è utile descrivere come si lavora in quell’ambiente in modo che, se le idee vi piacciono, possiate tradurre il metodo da uno strumento all’altro.</para> 12.137 + 12.138 + <para id="x_46f">Al centro della comunità siede Linus Torvalds, il creatore di Linux. Linus pubblica un singolo repository di sorgenti che è considerato il ramo <quote>autoritativo</quote> corrente dall’intera comunità di sviluppo. Chiunque può clonare l’albero di Linus, ma Linus è piuttosto selettivo per quanto riguarda gli alberi da cui estrae le modifiche.</para> 12.139 + 12.140 + <para id="x_470">Linus ha un certo numero di <quote>luogotenenti di fiducia</quote>. Come regola generale, estrae qualunque cambiamento gli trasmettano, nella maggior parte dei casi senza nemmeno revisionare quelle modifiche. Alcuni di quei luogotenenti hanno accettato il ruolo di <quote>manutentori</quote> responsabili di specifici sottosistemi del kernel. Se un programmatore qualsiasi vuole che la propria modifica a un sottosistema del kernel finisca nell’albero di Linus, deve trovare il manutentore di quel sottosistema e chiedergli di accettarla. Se il manutentore revisiona le modifiche e accetta di prenderle, le passerà a Linus al momento giusto.</para> 12.141 12.142 <para id="x_471">Ogni singolo luogotenente segue il proprio metodo per revisionare, accettare e pubblicare le modifiche, e per decidere quando passarle a Linus. In più, esistono diversi rami ben noti che vengono usati per scopi differenti. Per esempio, alcune persone mantengono repository <quote>stabili</quote> di vecchie versioni del kernel alle quali applicano correzioni critiche quando è necessario. Alcuni manutentori pubblicano molteplici alberi: uno per modifiche sperimentali, uno per cambiamenti che stanno per passare in alto, e così via. Altri pubblicano semplicemente un singolo albero.</para> 12.143 12.144 - <para id="x_472">Questo modello ha due caratteristiche importanti. La prima è quella di essere <quote>a sola estrazione</quote>. Dovete chiedere, convincere, o implorare un altro sviluppatore di prendere una modifica da voi, perché non c'è quasi nessun albero a cui più di una persona possa trasmettere e non c'è modo di trasmettere cambiamenti a un albero controllato da qualcun altro.</para> 12.145 + <para id="x_472">Questo modello ha due caratteristiche importanti. La prima è quella di essere <quote>a sola estrazione</quote>. Dovete chiedere, convincere, o implorare un altro sviluppatore di prendere una modifica da voi, perché non c’è quasi nessun albero a cui più di una persona possa trasmettere e non c’è modo di trasmettere cambiamenti a un albero controllato da qualcun altro.</para> 12.146 12.147 <para id="x_473">La seconda è quella di essere basato su reputazione e approvazione. Se siete sconosciuti, Linus probabilmente ignorerà le vostre modifiche senza nemmeno rispondervi. Ma il manutentore di un sottosistema probabilmente le revisionerà e sarà disposto ad accettarle se rispettano i suoi criteri di conformità. Più modifiche <quote>buone</quote> presentate a un manutentore, più è probabile che si fidi del vostro giudizio e accetti i vostri cambiamenti. Se siete ben conosciuti e mantenete un ramo di lunga data per qualcosa che Linus non ha ancora accettato, le persone con interessi simili potranno incorporare regolarmente i vostri cambiamenti per rimanere aggiornati sul vostro lavoro.</para> 12.148 12.149 - <para id="x_474">Reputazione e approvazione non oltrepassano necessariamente i confini tecnici e sociali di un sottosistema. Se siete un programmatore rispettato ma specializzato nell'ambito della memorizzazione dei dati e provate a correggere un bug relativo all'infrastruttura di rete, un manutentore del sottosistema esaminerà minuziosamente quel cambiamento come se fosse stato realizzato da un completo sconosciuto.</para> 12.150 + <para id="x_474">Reputazione e approvazione non oltrepassano necessariamente i confini tecnici e sociali di un sottosistema. Se siete un programmatore rispettato ma specializzato nell’ambito della memorizzazione dei dati e provate a correggere un bug relativo all’infrastruttura di rete, un manutentore del sottosistema esaminerà minuziosamente quel cambiamento come se fosse stato realizzato da un completo sconosciuto.</para> 12.151 12.152 <para id="x_475">Alle persone che provengono da esperienze con progetti più ordinari, il processo di sviluppo relativamente caotico del kernel di Linux sembra spesso completamente folle: subisce i capricci dei singoli, le persone apportano radicali cambiamenti ogni volta che lo ritengono opportuno e la velocità di sviluppo è sorprendente. Nonostante questo, Linux è un software molto apprezzato e di grande successo.</para> 12.153 </sect2> 12.154 @@ -166,7 +166,7 @@ 12.155 12.156 <para id="x_476">Nella comunità open source si tenta continuamente di stabilire, attraverso accese discussioni, se un modello di sviluppo in cui le persone non fanno altro che estrarre cambiamenti le une dalle altre sia <quote>meglio</quote> di un modello in cui più persone possono trasmettere modifiche a un repository condiviso.</para> 12.157 12.158 - <para id="x_477">Tipicamente, i sostenitori del modello a scrittura condivisa usano strumenti che impongono attivamente questo approccio. Se state usando uno strumento centralizzato di controllo di revisione come Subversion, non c'è alcun modo di scegliere il modello che userete: lo strumento vi fornisce un modello a scrittura condivisa e se volete fare qualcos'altro dovete strutturare il vostro metodo al di sopra di quel modello (per esempio, applicando una patch a mano).</para> 12.159 + <para id="x_477">Tipicamente, i sostenitori del modello a scrittura condivisa usano strumenti che impongono attivamente questo approccio. Se state usando uno strumento centralizzato di controllo di revisione come Subversion, non c’è alcun modo di scegliere il modello che userete: lo strumento vi fornisce un modello a scrittura condivisa e se volete fare qualcos’altro dovete strutturare il vostro metodo al di sopra di quel modello (per esempio, applicando una patch a mano).</para> 12.160 12.161 <para id="x_478">Un buon sistema distribuito di controllo di revisione supporterà entrambi i modelli. Voi e i vostri collaboratori potrete quindi organizzare il modo di lavorare insieme sulla base dei vostri bisogni e delle vostre preferenze, non delle acrobazie a cui vi costringono gli strumenti.</para> 12.162 </sect2> 12.163 @@ -186,9 +186,9 @@ 12.164 <sect1 id="sec:collab:serve"> 12.165 <title>Condivisione informale con <command role="hg-cmd">hg serve</command></title> 12.166 12.167 - <para id="x_47b">Il comando <command role="hg-cmd">hg serve</command> di Mercurial è meravigliosamente adatto per situazioni in cui i gruppi di sviluppo sono piccoli, localizzati e veloci. Rappresenta anche un modo fantastico per familiarizzare con l'uso dei comandi Mercurial attraverso la rete.</para> 12.168 - 12.169 - <para id="x_47c">Invocate <command role="hg-cmd">hg serve</command> all'interno di un repository e in meno di un secondo verrà avviato un server HTTP specializzato che accetterà connessioni da qualunque client e servirà i dati di quel repository fino a quando non lo spegnerete. Chiunque conosca l'URL del server che avete appena avviato e sia in grado di accedere al vostro computer attraverso la rete potrà usare un browser web o lo stesso Mercurial per leggere i dati da quel repository. Un URL corrispondente a un'istanza di <command role="hg-cmd">hg serve</command> in esecuzione su un computer portatile somiglierà probabilmente a qualcosa come <literal>http://mio-portatile.local:8000/</literal>.</para> 12.170 + <para id="x_47b">Il comando <command role="hg-cmd">hg serve</command> di Mercurial è meravigliosamente adatto per situazioni in cui i gruppi di sviluppo sono piccoli, localizzati e veloci. Rappresenta anche un modo fantastico per familiarizzare con l’uso dei comandi Mercurial attraverso la rete.</para> 12.171 + 12.172 + <para id="x_47c">Invocate <command role="hg-cmd">hg serve</command> all’interno di un repository e in meno di un secondo verrà avviato un server HTTP specializzato che accetterà connessioni da qualunque client e servirà i dati di quel repository fino a quando non lo spegnerete. Chiunque conosca l’URL del server che avete appena avviato e sia in grado di accedere al vostro computer attraverso la rete potrà usare un browser web o lo stesso Mercurial per leggere i dati da quel repository. Un URL corrispondente a un’istanza di <command role="hg-cmd">hg serve</command> in esecuzione su un computer portatile somiglierà probabilmente a qualcosa come <literal>http://mio-portatile.local:8000/</literal>.</para> 12.173 12.174 <para id="x_47d">Il comando <command role="hg-cmd">hg serve</command> non è un server web di uso generale, ma può fare solo due cose:</para> 12.175 <itemizedlist> 12.176 @@ -198,18 +198,18 @@ 12.177 </listitem></itemizedlist> 12.178 <para id="x_480">In particolare, <command role="hg-cmd">hg serve</command> non permetterà agli utenti di <emphasis>modificare</emphasis> il vostro repository, perché è stato pensato per un uso in sola lettura.</para> 12.179 12.180 - <para id="x_481">Se avete appena cominciato a lavorare con Mercurial, non c'è nulla che vi impedisca di usare <command role="hg-cmd">hg serve</command> per servire i dati di un repository sul vostro computer, poi usare comandi come <command role="hg-cmd">hg clone</command>, <command role="hg-cmd">hg incoming</command>, e così via per comunicare con quel server come se il repository fosse situato su una macchina remota. Questo può aiutarvi a familiarizzare velocemente con l'utilizzo dei comandi su repository ospitati in rete.</para> 12.181 + <para id="x_481">Se avete appena cominciato a lavorare con Mercurial, non c’è nulla che vi impedisca di usare <command role="hg-cmd">hg serve</command> per servire i dati di un repository sul vostro computer, poi usare comandi come <command role="hg-cmd">hg clone</command>, <command role="hg-cmd">hg incoming</command>, e così via per comunicare con quel server come se il repository fosse situato su una macchina remota. Questo può aiutarvi a familiarizzare velocemente con l’utilizzo dei comandi su repository ospitati in rete.</para> 12.182 12.183 <sect2> 12.184 <title>Alcune cose da tenere a mente</title> 12.185 12.186 <para id="x_482">Dato che <command role="hg-cmd">hg serve</command> fornisce un accesso non autenticato in lettura a tutti i client, dovreste usarlo solo in un ambiente in cui non vi interessa, o potete interamente controllare, chi può accedere alla vostra rete ed estrarre dati dal vostro repository.</para> 12.187 12.188 - <para id="x_483">Il comando <command role="hg-cmd">hg serve</command> non sa nulla del firewall che potreste avere installato a protezione del vostro sistema o della vostra rete: non è in grado di scoprire se avete un firewall né di controllarlo. Se altre persone non riescono ad accedere a un'istanza di <command role="hg-cmd">hg serve</command> in esecuzione, la seconda cosa che dovreste fare (<emphasis>dopo</emphasis> aver verificato che stiano usando l'URL corretto) è controllare la configurazione del vostro firewall.</para> 12.189 - 12.190 - <para id="x_484">Per default, <command role="hg-cmd">hg serve</command> accetta connessioni in entrata sulla porta 8000. Se un altro processo sta già occupando la porta che volete usare, potete specificare una porta differente tramite l'opzione <option role="hg-opt-serve">-p</option>.</para> 12.191 - 12.192 - <para id="x_485">Normalmente, quando <command role="hg-cmd">hg serve</command> parte, non stampa alcuna informazione, cosa che potrebbe intimidirvi. Se volete avere una conferma che il comando stia eseguendo correttamente, e volete scoprire l'esatto URL che dovreste inviare ai vostri collaboratori, lanciate <command role="hg-cmd">hg serve</command> con l'opzione <option role="hg-opt-global">-v</option>.</para> 12.193 + <para id="x_483">Il comando <command role="hg-cmd">hg serve</command> non sa nulla del firewall che potreste avere installato a protezione del vostro sistema o della vostra rete: non è in grado di scoprire se avete un firewall né di controllarlo. Se altre persone non riescono ad accedere a un’istanza di <command role="hg-cmd">hg serve</command> in esecuzione, la seconda cosa che dovreste fare (<emphasis>dopo</emphasis> aver verificato che stiano usando l’URL corretto) è controllare la configurazione del vostro firewall.</para> 12.194 + 12.195 + <para id="x_484">Per default, <command role="hg-cmd">hg serve</command> accetta connessioni in entrata sulla porta 8000. Se un altro processo sta già occupando la porta che volete usare, potete specificare una porta differente tramite l’opzione <option role="hg-opt-serve">-p</option>.</para> 12.196 + 12.197 + <para id="x_485">Normalmente, quando <command role="hg-cmd">hg serve</command> parte, non stampa alcuna informazione, cosa che potrebbe intimidirvi. Se volete avere una conferma che il comando stia eseguendo correttamente, e volete scoprire l’esatto URL che dovreste inviare ai vostri collaboratori, lanciate <command role="hg-cmd">hg serve</command> con l’opzione <option role="hg-opt-global">-v</option>.</para> 12.198 </sect2> 12.199 </sect1> 12.200 12.201 @@ -236,12 +236,12 @@ 12.202 </listitem> 12.203 <listitem><para id="x_48d"><quote>:22</quote> idenifica il numero di porta del server a cui connettersi. La porta predefinita è la 22, quindi dovete utilizzare il carattere di due punti e il numero di porta solo se <emphasis>non</emphasis> state usando la porta 22.</para> 12.204 </listitem> 12.205 - <listitem><para id="x_48e">Il resto dell'URL è il percorso locale del repository sul server.</para> 12.206 + <listitem><para id="x_48e">Il resto dell’URL è il percorso locale del repository sul server.</para> 12.207 </listitem></orderedlist> 12.208 12.209 <para id="x_48f">Si rischia facilmente di fare confusione con il percorso locale contenuto negli URL ssh, dato che gli strumenti non hanno un modo standard per interpretarlo. Alcuni programmi si comportano in modo diverso rispetto ad altri quando operano su questi percorsi. Questa non è una situazione ideale, ma è difficile che possa cambiare, quindi leggete il paragrafo seguente con la dovuta attenzione.</para> 12.210 12.211 - <para id="x_490">Mercurial tratta il percorso di un repository sul server come se fosse relativo alla directory personale dell'utente remoto. Per esempio, se l'utente <literal>foo</literal> possiede una directory personale <filename class="directory">/home/foo</filename> sul server, allora un URL ssh che contiene un percorso <filename class="directory">bar</filename> si riferisce <emphasis>in realtà</emphasis> alla directory <filename class="directory">/home/foo/bar</filename>.</para> 12.212 + <para id="x_490">Mercurial tratta il percorso di un repository sul server come se fosse relativo alla directory personale dell’utente remoto. Per esempio, se l’utente <literal>foo</literal> possiede una directory personale <filename class="directory">/home/foo</filename> sul server, allora un URL ssh che contiene un percorso <filename class="directory">bar</filename> si riferisce <emphasis>in realtà</emphasis> alla directory <filename class="directory">/home/foo/bar</filename>.</para> 12.213 12.214 <para id="x_491">Se volete specificare un percorso relativo alla directory personale di un altro utente, potete usare un percorso che comincia con un carattere di tilde seguito dal nome utente (chiamiamolo <literal>altroutente</literal>) in questo modo.</para> 12.215 <programlisting>ssh://server/~altroutente/hg/repo</programlisting> 12.216 @@ -253,9 +253,9 @@ 12.217 <sect2> 12.218 <title>Trovare un client ssh per il vostro sistema</title> 12.219 12.220 - <para id="x_493">Quasi tutti i sistemi di tipo Unix includono un'installazione di OpenSSH. Se state usando uno di questi sistemi, eseguite <literal>which ssh</literal> per scoprire se il comando <command>ssh</command> è installato (di solito si trova nella directory <filename class="directory">/usr/bin</filename>). Nell'improbabile eventualità in cui non sia presente, date un'occhiata alla documentazione del vostro sistema per capire come installarlo.</para> 12.221 - 12.222 - <para id="x_494">Su Windows, il pacchetto TortoiseHg comprende una versione dell'eccellente comando <command>plink</command>, realizzato da Simon Tatham, che non dovrebbe avere bisogno di ulteriori configurazioni.</para> 12.223 + <para id="x_493">Quasi tutti i sistemi di tipo Unix includono un’installazione di OpenSSH. Se state usando uno di questi sistemi, eseguite <literal>which ssh</literal> per scoprire se il comando <command>ssh</command> è installato (di solito si trova nella directory <filename class="directory">/usr/bin</filename>). Nell’improbabile eventualità in cui non sia presente, date un’occhiata alla documentazione del vostro sistema per capire come installarlo.</para> 12.224 + 12.225 + <para id="x_494">Su Windows, il pacchetto TortoiseHg comprende una versione dell’eccellente comando <command>plink</command>, realizzato da Simon Tatham, che non dovrebbe avere bisogno di ulteriori configurazioni.</para> 12.226 </sect2> 12.227 12.228 <sect2> 12.229 @@ -278,25 +278,25 @@ 12.230 </listitem> 12.231 </itemizedlist> 12.232 12.233 - <para id="x_49a">Quando generate una coppia di chiavi, di solito è <emphasis>altamente</emphasis> raccomandabile proteggerla con una frase di accesso chiamata passphrase. (L'unico caso in cui potreste non volerlo fare è quando state usando il protocollo ssh per attività automatiche su una rete sicura.)</para> 12.234 - 12.235 - <para id="x_49b">In ogni caso, generare semplicemente la coppia di chiavi non basta, ma dovrete aggiungere la chiave pubblica all'insieme di chiavi autorizzate che appartiene a qualsiasi utente vogliate utilizzare per accedere al server remoto. Per i server che usano OpenSSH (la grande maggioranza), questo significa aggiungere la chiave pubblica a una lista contenuta in un file chiamato <filename role="special">authorized_keys</filename> nella directory <filename role="special" class="directory">.ssh</filename> dell'utente.</para> 12.236 + <para id="x_49a">Quando generate una coppia di chiavi, di solito è <emphasis>altamente</emphasis> raccomandabile proteggerla con una frase di accesso chiamata passphrase. (L’unico caso in cui potreste non volerlo fare è quando state usando il protocollo ssh per attività automatiche su una rete sicura.)</para> 12.237 + 12.238 + <para id="x_49b">In ogni caso, generare semplicemente la coppia di chiavi non basta, ma dovrete aggiungere la chiave pubblica all’insieme di chiavi autorizzate che appartiene a qualsiasi utente vogliate utilizzare per accedere al server remoto. Per i server che usano OpenSSH (la grande maggioranza), questo significa aggiungere la chiave pubblica a una lista contenuta in un file chiamato <filename role="special">authorized_keys</filename> nella directory <filename role="special" class="directory">.ssh</filename> dell’utente.</para> 12.239 12.240 <para id="x_49c">Su un sistema di tipo Unix, la vostra chiave pubblica avrà una estensione <filename>.pub</filename>. Se state usando <command>puttygen</command> su Windows, potete salvare la chiave pubblica in un file di vostra scelta, o copiarla dalla finestra in cui è visualizzata e incollarla direttamente nel file <filename role="special">authorized_keys</filename>.</para> 12.241 </sect2> 12.242 <sect2> 12.243 <title>Usare un agente di autenticazione</title> 12.244 12.245 - <para id="x_49d">Un agente di autenticazione è un demone che tiene le passphrase in memoria (quindi le dimenticherà se uscite dal sistema e poi rientrate). Un client ssh noterà se un agente è in esecuzione e gli richiederà una passphrase. Se non c'è alcun agente di autenticazione attivo, o se l'agente non ha memorizzato la passphrase necessaria, dovrete digitare la vostra passphrase ogni volta che Mercurial prova a comunicare con il server per vostro conto (per esempio, ogni volta che estraete o trasmettete cambiamenti).</para> 12.246 + <para id="x_49d">Un agente di autenticazione è un demone che tiene le passphrase in memoria (quindi le dimenticherà se uscite dal sistema e poi rientrate). Un client ssh noterà se un agente è in esecuzione e gli richiederà una passphrase. Se non c’è alcun agente di autenticazione attivo, o se l’agente non ha memorizzato la passphrase necessaria, dovrete digitare la vostra passphrase ogni volta che Mercurial prova a comunicare con il server per vostro conto (per esempio, ogni volta che estraete o trasmettete cambiamenti).</para> 12.247 12.248 <para id="x_49e">Lo svantaggio di memorizzare le passphrase in un agente è che un aggressore ben preparato sarebbe in grado di recuperare il testo in chiaro delle vostre passphrase, a volte anche se il vostro sistema è stato riavviato. Dovreste giudicare da voi se questo è un rischio che potete correre. Di certo, un agente vi permette di risparmiare tempo evitandovi di digitare ripetutamente sempre lo stesso testo.</para> 12.249 12.250 <itemizedlist> 12.251 <listitem> 12.252 - <para id="x_49f">Su sistemi di tipo Unix, l'agente è chiamato <command>ssh-agent</command> e spesso viene eseguito automaticamente quando entrate nel sistema. Dovrete usare il comando <command>ssh-add</command> per aggiungere una nuova passphrase alla memoria dell'agente.</para> 12.253 + <para id="x_49f">Su sistemi di tipo Unix, l’agente è chiamato <command>ssh-agent</command> e spesso viene eseguito automaticamente quando entrate nel sistema. Dovrete usare il comando <command>ssh-add</command> per aggiungere una nuova passphrase alla memoria dell’agente.</para> 12.254 </listitem> 12.255 <listitem> 12.256 - <para id="x_6a7">Su Windows, se state usando TortoiseHg, il comando <command>pageant</command> funziona come un agente. Come con <command>puttygen</command>, avrete bisogno di <ulink url="http://www.chiark.greenend.org.uk/%7Esgtatham/putty/download.html">scaricare <command>pageant</command></ulink> dal sito web di PuTTY e di leggere <ulink url="http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter9.html#pageant">la sua documentazione</ulink>. Il comando <command>pageant</command> aggiunge alla vostra area di notifica un'icona che vi permetterà di gestire le passphrase memorizzate.</para> 12.257 + <para id="x_6a7">Su Windows, se state usando TortoiseHg, il comando <command>pageant</command> funziona come un agente. Come con <command>puttygen</command>, avrete bisogno di <ulink url="http://www.chiark.greenend.org.uk/%7Esgtatham/putty/download.html">scaricare <command>pageant</command></ulink> dal sito web di PuTTY e di leggere <ulink url="http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter9.html#pageant">la sua documentazione</ulink>. Il comando <command>pageant</command> aggiunge alla vostra area di notifica un’icona che vi permetterà di gestire le passphrase memorizzate.</para> 12.258 </listitem> 12.259 </itemizedlist> 12.260 </sect2> 12.261 @@ -308,13 +308,13 @@ 12.262 12.263 <para id="x_4a1">Prima di provare a usare Mercurial per comunicare con un server ssh, è preferibile che vi assicuriate di poter usare i normali comandi <command>ssh</command> o <command>putty</command> per contattare il server. Se incontrate problemi usando direttamente questi comandi, Mercurial sicuramente non funzionerà e in più nasconderà il problema sottostante. Ogni volta che avete un problema relativo a ssh con Mercurial, per cominciare dovreste accertarvi nuovamente che i semplici comandi ssh lato client funzionino <emphasis>prima</emphasis> di preoccuparvi di eventuali problemi con Mercurial.</para> 12.264 12.265 - <para id="x_4a2">La prima cosa di cui accertarsi sul lato server è che siate in grado di entrare nel sistema da un'altra macchina. Se non potete usare <command>ssh</command> o <command>putty</command> per entrare, il messaggio di errore che vi viene mostrato potrebbe darvi alcuni suggerimenti per capire che cosa non va. I problemi più comuni sono i seguenti.</para> 12.266 + <para id="x_4a2">La prima cosa di cui accertarsi sul lato server è che siate in grado di entrare nel sistema da un’altra macchina. Se non potete usare <command>ssh</command> o <command>putty</command> per entrare, il messaggio di errore che vi viene mostrato potrebbe darvi alcuni suggerimenti per capire che cosa non va. I problemi più comuni sono i seguenti.</para> 12.267 <itemizedlist> 12.268 - <listitem><para id="x_4a3">Se l'errore è di tipo <quote>connection refused</quote> (connessione rifiutata), questo significa che non c'è alcun demone ssh in esecuzione sul server, o che il server è inaccessibile a causa della configurazione del firewall.</para> 12.269 - </listitem> 12.270 - <listitem><para id="x_4a4">Se l'errore è di tipo <quote>no route to host</quote> (macchina remota non raggiungibile), questo significa che avete un indirizzo sbagliato per il server o un firewall con impostazioni talmente restrittive da impedirgli di vedere il server.</para> 12.271 - </listitem> 12.272 - <listitem><para id="x_4a5">Se l'errore è di tipo <quote>permission denied</quote> (permesso negato), potreste aver digitato in maniera inesatta il nome utente sul server, o la passphrase della vostra chiave, o la password dell'utente remoto.</para> 12.273 + <listitem><para id="x_4a3">Se l’errore è di tipo <quote>connection refused</quote> (connessione rifiutata), questo significa che non c’è alcun demone ssh in esecuzione sul server, o che il server è inaccessibile a causa della configurazione del firewall.</para> 12.274 + </listitem> 12.275 + <listitem><para id="x_4a4">Se l’errore è di tipo <quote>no route to host</quote> (macchina remota non raggiungibile), questo significa che avete un indirizzo sbagliato per il server o un firewall con impostazioni talmente restrittive da impedirgli di vedere il server.</para> 12.276 + </listitem> 12.277 + <listitem><para id="x_4a5">Se l’errore è di tipo <quote>permission denied</quote> (permesso negato), potreste aver digitato in maniera inesatta il nome utente sul server, o la passphrase della vostra chiave, o la password dell’utente remoto.</para> 12.278 </listitem></itemizedlist> 12.279 <para id="x_4a6">Riepilogando, se avete problemi di comunicazione con il demone ssh del server, per prima cosa assicuratevi che ne esista uno in esecuzione. Su molti sistemi sarà installato ma disabilitato per default. Una volta che avete compiuto questo passo, dovreste controllare che il firewall del server sia configurato per consentire connessioni in entrata verso la porta su cui il demone ssh si trova in ascolto (di solito, la 22). Non preoccupatevi di altri errori di configurazione più esotici fino a quando non avete controllato questi due.</para> 12.280 12.281 @@ -324,17 +324,17 @@ 12.282 </listitem> 12.283 <listitem><para id="x_4a9">Potreste aver memorizzato la passphrase per la chiave sbagliata.</para> 12.284 </listitem></itemizedlist> 12.285 - <para id="x_4aa">Se vi viene richiesta la password per l'utente remoto, ecco altri possibili cause.</para> 12.286 + <para id="x_4aa">Se vi viene richiesta la password per l’utente remoto, ecco altri possibili cause.</para> 12.287 <itemizedlist> 12.288 - <listitem><para id="x_4ab">La directory personale dell'utente o la sua directory <filename role="special" class="directory">.ssh</filename> potrebbero avere permessi eccessivamente liberali. Come risultato, il demone ssh non si fiderà dei contenuti del file <filename role="special">authorized_keys</filename> e quindi non lo leggerà. Per esempio, una directory personale o una directory <filename role="special" class="directory">.ssh</filename> con il permesso di scrittura di gruppo abilitato causerà spesso questo effetto.</para> 12.289 - </listitem> 12.290 - <listitem><para id="x_4ac">Il file <filename role="special">authorized_keys</filename> dell'utente potrebbe avere un problema. Se l'utente non è l'unico proprietario del file o qualcun altro può scrivere sul file, il demone ssh non si fiderà dei suoi contenuti e quindi non lo leggerà.</para> 12.291 + <listitem><para id="x_4ab">La directory personale dell’utente o la sua directory <filename role="special" class="directory">.ssh</filename> potrebbero avere permessi eccessivamente liberali. Come risultato, il demone ssh non si fiderà dei contenuti del file <filename role="special">authorized_keys</filename> e quindi non lo leggerà. Per esempio, una directory personale o una directory <filename role="special" class="directory">.ssh</filename> con il permesso di scrittura di gruppo abilitato causerà spesso questo effetto.</para> 12.292 + </listitem> 12.293 + <listitem><para id="x_4ac">Il file <filename role="special">authorized_keys</filename> dell’utente potrebbe avere un problema. Se l’utente non è l’unico proprietario del file o qualcun altro può scrivere sul file, il demone ssh non si fiderà dei suoi contenuti e quindi non lo leggerà.</para> 12.294 </listitem></itemizedlist> 12.295 12.296 - <para id="x_4ad">In un mondo ideale, dovreste essere in grado di eseguire il comando seguente con successo e ottenere come risultato la stampa di una riga contenente la data e l'ora correnti.</para> 12.297 + <para id="x_4ad">In un mondo ideale, dovreste essere in grado di eseguire il comando seguente con successo e ottenere come risultato la stampa di una riga contenente la data e l’ora correnti.</para> 12.298 <programlisting>ssh mioserver date</programlisting> 12.299 12.300 - <para id="x_4ae">Se gli script di accesso sul vostro server stampano messaggi informativi o altri tipi di testo anche quando eseguite comandi non interattivi come questo, dovreste correggerli prima di continuare, in modo che stampino solo se vengono eseguiti interattivamente. Altrimenti, questi messaggi come minimo confonderanno le stampe di Mercurial e nel caso peggiore potrebbero causare problemi durante l'esecuzione remota dei comandi Mercurial. Mercurial prova a individuare e ignorare questi messaggi durante le sessioni <command>ssh</command> non interattive, ma non è infallibile. (Se state modificando i vostri script di accesso sul vostro server, potete vedere se uno script di accesso viene eseguito in una shell interattiva controllando il codice restituito dal comando <literal>tty -s</literal>.)</para> 12.301 + <para id="x_4ae">Se gli script di accesso sul vostro server stampano messaggi informativi o altri tipi di testo anche quando eseguite comandi non interattivi come questo, dovreste correggerli prima di continuare, in modo che stampino solo se vengono eseguiti interattivamente. Altrimenti, questi messaggi come minimo confonderanno le stampe di Mercurial e nel caso peggiore potrebbero causare problemi durante l’esecuzione remota dei comandi Mercurial. Mercurial prova a individuare e ignorare questi messaggi durante le sessioni <command>ssh</command> non interattive, ma non è infallibile. (Se state modificando i vostri script di accesso sul vostro server, potete vedere se uno script di accesso viene eseguito in una shell interattiva controllando il codice restituito dal comando <literal>tty -s</literal>.)</para> 12.302 12.303 <para id="x_4af">Dopo aver verificato che il buon vecchio ssh stia funzionando con il vostro server, il passo successivo è quello di assicurarsi che Mercurial sia in esecuzione sul server. Il comando seguente dovrebbe terminare con successo:</para> 12.304 12.305 @@ -344,23 +344,23 @@ 12.306 <itemizedlist> 12.307 <listitem><para id="x_4b1">Mercurial è veramente installato sul server? So che sembra una cosa ovvia, ma vale la pena di controllare!</para> 12.308 </listitem> 12.309 - <listitem><para id="x_4b2">Forse il percorso di ricerca della vostra shell (solitamente impostato attraverso la variabile d'ambiente <envar>PATH</envar>) è semplicemente configurato male.</para> 12.310 - </listitem> 12.311 - <listitem><para id="x_4b3">Forse la vostra variabile d'ambiente <envar>PATH</envar> è impostata per puntare all'ubicazione dell'eseguibile <command>hg</command> solo se l'accesso avviene tramite una sessione interattiva. Questo può capitare se state impostando il percorso nello script di accesso sbagliato. Leggete la documentazione della vostra shell per i dettagli.</para> 12.312 - </listitem> 12.313 - <listitem><para id="x_4b4">La variabile d'ambiente <envar>PYTHONPATH</envar> potrebbe aver bisogno di contenere il percorso ai moduli Python di Mercurial. Potrebbe non essere per niente impostata, potrebbe essere sbagliata, o potrebbe venire impostata solo se l'accesso è interattivo.</para> 12.314 + <listitem><para id="x_4b2">Forse il percorso di ricerca della vostra shell (solitamente impostato attraverso la variabile d’ambiente <envar>PATH</envar>) è semplicemente configurato male.</para> 12.315 + </listitem> 12.316 + <listitem><para id="x_4b3">Forse la vostra variabile d’ambiente <envar>PATH</envar> è impostata per puntare all’ubicazione dell’eseguibile <command>hg</command> solo se l’accesso avviene tramite una sessione interattiva. Questo può capitare se state impostando il percorso nello script di accesso sbagliato. Leggete la documentazione della vostra shell per i dettagli.</para> 12.317 + </listitem> 12.318 + <listitem><para id="x_4b4">La variabile d’ambiente <envar>PYTHONPATH</envar> potrebbe aver bisogno di contenere il percorso ai moduli Python di Mercurial. Potrebbe non essere per niente impostata, potrebbe essere sbagliata, o potrebbe venire impostata solo se l’accesso è interattivo.</para> 12.319 </listitem></itemizedlist> 12.320 12.321 - <para id="x_4b5">Se riuscite a eseguire <command role="hg-cmd">hg version</command> attraverso una connessione ssh, ben fatto! Siete riusciti a configurare il client e il server. Ora dovreste essere in grado di usare Mercurial per accedere ai repository ospitati da quel nome utente su quel server. Se a questo punto incontrate qualche problema con Mercurial e ssh, provate a usare l'opzione <option role="hg-opt-global">--debug</option> per avere un'immagine più chiara di quello che sta succedendo.</para> 12.322 + <para id="x_4b5">Se riuscite a eseguire <command role="hg-cmd">hg version</command> attraverso una connessione ssh, ben fatto! Siete riusciti a configurare il client e il server. Ora dovreste essere in grado di usare Mercurial per accedere ai repository ospitati da quel nome utente su quel server. Se a questo punto incontrate qualche problema con Mercurial e ssh, provate a usare l’opzione <option role="hg-opt-global">--debug</option> per avere un’immagine più chiara di quello che sta succedendo.</para> 12.323 </sect2> 12.324 <sect2> 12.325 <title>Usare la compressione con ssh</title> 12.326 12.327 <para id="x_4b6">Mercurial non comprime i dati quando usa il protocollo ssh, perché il protocollo ssh può comprimere i dati in maniera trasparente. Tuttavia, il comportamento predefinito dei client ssh è quello di <emphasis>non</emphasis> richiedere la compressione.</para> 12.328 12.329 - <para id="x_4b7">Su qualsiasi rete diversa da una LAN veloce (persino una rete wireless), è probabile che l'uso della compressione velocizzi significativamente le operazioni di rete di Mercurial. Per esempio, qualcuno ha misurato che la compressione riduce il tempo necessario per creare un repository particolarmente grande attraverso una WAN da 51 minuti a 17 minuti.</para> 12.330 - 12.331 - <para id="x_4b8">Sia <command>ssh</command> che <command>plink</command> richiedono l'opzione <option role="cmd-opt-ssh">-C</option> per attivare la compressione. Potete facilmente modificare il vostro file <filename role="special">~/.hgrc</filename> in modo da abilitare la compressione per tutti gli utilizzi del protocollo ssh da parte di Mercurial. Per esempio, ecco come fare per l'ordinario comando <command>ssh</command> sui sistemi di tipo Unix.</para> 12.332 + <para id="x_4b7">Su qualsiasi rete diversa da una LAN veloce (persino una rete wireless), è probabile che l’uso della compressione velocizzi significativamente le operazioni di rete di Mercurial. Per esempio, qualcuno ha misurato che la compressione riduce il tempo necessario per creare un repository particolarmente grande attraverso una WAN da 51 minuti a 17 minuti.</para> 12.333 + 12.334 + <para id="x_4b8">Sia <command>ssh</command> che <command>plink</command> richiedono l’opzione <option role="cmd-opt-ssh">-C</option> per attivare la compressione. Potete facilmente modificare il vostro file <filename role="special">~/.hgrc</filename> in modo da abilitare la compressione per tutti gli utilizzi del protocollo ssh da parte di Mercurial. Per esempio, ecco come fare per l’ordinario comando <command>ssh</command> sui sistemi di tipo Unix.</para> 12.335 <programlisting>[ui] 12.336 ssh = ssh -C</programlisting> 12.337 12.338 @@ -370,7 +370,7 @@ 12.339 Compression yes 12.340 HostName hg.example.com</programlisting> 12.341 12.342 - <para id="x_4ba">Questo definisce l'alias <literal>hg</literal> per il nome della macchina. Quando usate l'alias sulla riga di comando <command>ssh</command> o in un URL ssh di Mercurial, <command>ssh</command> si connetterà a <literal>hg.example.com</literal> e userà la compressione. In questo modo, potete ottenere sia un nome più corto da digitare sia la compressione, che dal canto loro sono entrambe buone cose.</para> 12.343 + <para id="x_4ba">Questo definisce l’alias <literal>hg</literal> per il nome della macchina. Quando usate l’alias sulla riga di comando <command>ssh</command> o in un URL ssh di Mercurial, <command>ssh</command> si connetterà a <literal>hg.example.com</literal> e userà la compressione. In questo modo, potete ottenere sia un nome più corto da digitare sia la compressione, che dal canto loro sono entrambe buone cose.</para> 12.344 </sect2> 12.345 </sect1> 12.346 12.347 @@ -379,14 +379,14 @@ 12.348 12.349 <para id="x_6a8">Il modo più semplice per condividere uno o più repository in modo permanente è quello di usare un server web e il supporto CGI di Mercurial.</para> 12.350 12.351 - <para id="x_4bb">A seconda di quanto siete ambiziosi, configurare l'interfaccia CGI di Mercurial può portarvi via da pochi minuti a diverse ore.</para> 12.352 + <para id="x_4bb">A seconda di quanto siete ambiziosi, configurare l’interfaccia CGI di Mercurial può portarvi via da pochi minuti a diverse ore.</para> 12.353 12.354 <para id="x_4bc">Cominceremo con il più semplice degli esempi per poi farci strada verso una configurazione più complessa. Persino nel caso più semplice, quasi certamente finirete per avere bisogno di leggere e modificare la configurazione del vostro server web.</para> 12.355 12.356 <note> 12.357 <title>Si richiede alta sopportazione del dolore</title> 12.358 12.359 - <para id="x_4bd">Configurare un server web è un'attività complessa, intricata e altamente dipendente dal sistema. Non mi sarebbe possibile darvi istruzioni che coprano tutti i casi che incontrerete. Quindi, usate il vostro discernimento e il vostro giudizio nel leggere le sezioni che seguono. Siate preparati a commettere molti errori e a passare molto tempo a leggere il registro degli errori del vostro server.</para> 12.360 + <para id="x_4bd">Configurare un server web è un’attività complessa, intricata e altamente dipendente dal sistema. Non mi sarebbe possibile darvi istruzioni che coprano tutti i casi che incontrerete. Quindi, usate il vostro discernimento e il vostro giudizio nel leggere le sezioni che seguono. Siate preparati a commettere molti errori e a passare molto tempo a leggere il registro degli errori del vostro server.</para> 12.361 12.362 <para id="x_6a9">Se non avete uno stomaco abbastanza forte da aggiustare continuamente le configurazioni, o un bisogno impellente di gestire i vostri servizi, potreste voler provare uno dei servizi di hosting pubblici che ho menzionato in precedenza.</para> 12.363 </note> 12.364 @@ -404,7 +404,7 @@ 12.365 <listitem><para id="x_4c1">Il vostro server è configurato per consentirvi di eseguire programmi CGI nella directory dove pianificate di farlo? La maggior parte delle impostazioni di partenza dei server disabilitano esplicitamente la possibilità di eseguire programmi CGI.</para> 12.366 </listitem></orderedlist> 12.367 12.368 - <para id="x_4c2">Se non avete un server web installato e non avete una considerevole esperienza nel configurare Apache, dovreste considerare l'uso del server web <literal>lighttpd</literal> invece di Apache. Le configurazioni di Apache hanno la reputazione ben meritata di essere complicate e di confondere gli utenti. Sebbene Apache sia dotato di un numero maggiore di funzioni rispetto a <literal>lighttpd</literal>, buona parte di queste funzioni non è rilevante per servire repository Mercurial. E <literal>lighttpd</literal> è innegabilmente <emphasis>molto</emphasis> più facile da affrontare di Apache.</para> 12.369 + <para id="x_4c2">Se non avete un server web installato e non avete una considerevole esperienza nel configurare Apache, dovreste considerare l’uso del server web <literal>lighttpd</literal> invece di Apache. Le configurazioni di Apache hanno la reputazione ben meritata di essere complicate e di confondere gli utenti. Sebbene Apache sia dotato di un numero maggiore di funzioni rispetto a <literal>lighttpd</literal>, buona parte di queste funzioni non è rilevante per servire repository Mercurial. E <literal>lighttpd</literal> è innegabilmente <emphasis>molto</emphasis> più facile da affrontare di Apache.</para> 12.370 </sect2> 12.371 12.372 <sect2> 12.373 @@ -412,18 +412,18 @@ 12.374 12.375 <para id="x_4c3">Su sistemi di tipo Unix, di solito gli utenti hanno una sottodirectory con un nome simile a <filename class="directory">public_html</filename> nella propria directory personale da cui possono servire pagine web. Un file chiamato <filename>foo</filename> in questa directory sarà accessibile tramite un URL della forma <literal>http://www.example.com/~nomeutente/foo</literal>.</para> 12.376 12.377 - <para id="x_4c4">Per cominciare, prendete lo script <filename role="special">hgweb.cgi</filename> che dovrebbe essere presente nella vostra installazione di Mercurial. Se non riuscite a trovarne velocemente una copia sul vostro sistema, scaricatela da uno dei principali repository di Mercurial all'indirizzo <ulink url="http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi">http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi</ulink>.</para> 12.378 + <para id="x_4c4">Per cominciare, prendete lo script <filename role="special">hgweb.cgi</filename> che dovrebbe essere presente nella vostra installazione di Mercurial. Se non riuscite a trovarne velocemente una copia sul vostro sistema, scaricatela da uno dei principali repository di Mercurial all’indirizzo <ulink url="http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi">http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi</ulink>.</para> 12.379 12.380 <para id="x_4c5">Dovrete copiare questo script nella vostra directory <filename class="directory">public_html</filename> e assicurarvi che sia eseguibile.</para> 12.381 <programlisting>cp .../hgweb.cgi ~/public_html 12.382 chmod 755 ~/public_html/hgweb.cgi</programlisting> 12.383 - <para id="x_4c6">L'argomento <literal>755</literal> passato a <command>chmod</command> ha un effetto un po' più generale rispetto a quello di rendere lo script eseguibile: garantisce che lo script sia eseguibile da chiunque e che i permessi di scrittura per il <quote>gruppo</quote> e gli <quote>altri</quote> <emphasis>non</emphasis> siano concessi. Se lasciaste abilitati quei permessi, probabilmente il sottosistema <literal>suexec</literal> di Apache si rifiuterebbe di eseguire lo script. In effetti, <literal>suexec</literal> insiste sul fatto che anche la <emphasis>directory</emphasis> in cui risiede lo script non sia modificabile da altri.</para> 12.384 + <para id="x_4c6">L’argomento <literal>755</literal> passato a <command>chmod</command> ha un effetto un po’ più generale rispetto a quello di rendere lo script eseguibile: garantisce che lo script sia eseguibile da chiunque e che i permessi di scrittura per il <quote>gruppo</quote> e gli <quote>altri</quote> <emphasis>non</emphasis> siano concessi. Se lasciaste abilitati quei permessi, probabilmente il sottosistema <literal>suexec</literal> di Apache si rifiuterebbe di eseguire lo script. In effetti, <literal>suexec</literal> insiste sul fatto che anche la <emphasis>directory</emphasis> in cui risiede lo script non sia modificabile da altri.</para> 12.385 <programlisting>chmod 755 ~/public_html</programlisting> 12.386 12.387 <sect3 id="sec:collab:wtf"> 12.388 <title>Che cosa <emphasis>potrebbe</emphasis> andare storto?</title> 12.389 12.390 - <para id="x_4c7">Una volta che avete copiato lo script CGI al suo posto, aprite un browser web e provate a visitare l'URL <literal>http://nomemacchina/~nomeutente/hgweb.cgi</literal>, <emphasis>ma</emphasis> raccogliete le forze per affrontare un fallimento immediato. C'è un'alta probabilità che la visita a questo URL fallisca e ci sono molte possibili ragioni per questo. In effetti, probabilmente vi imbatterete in quasi tutti i possibili errori descritti più avanti, quindi leggete attentamente. Quelli che seguono sono tutti i problemi che ho incontrato sul sistema operativo Fedora 7, con un'installazione vergine di Apache e un account utente creato espressamente per effettuare questo esercizio.</para> 12.391 + <para id="x_4c7">Una volta che avete copiato lo script CGI al suo posto, aprite un browser web e provate a visitare l’URL <literal>http://nomemacchina/~nomeutente/hgweb.cgi</literal>, <emphasis>ma</emphasis> raccogliete le forze per affrontare un fallimento immediato. C’è un’alta probabilità che la visita a questo URL fallisca e ci sono molte possibili ragioni per questo. In effetti, probabilmente vi imbatterete in quasi tutti i possibili errori descritti più avanti, quindi leggete attentamente. Quelli che seguono sono tutti i problemi che ho incontrato sul sistema operativo Fedora 7, con un’installazione vergine di Apache e un account utente creato espressamente per effettuare questo esercizio.</para> 12.392 12.393 <para id="x_4c8">Il vostro server web potrebbe aver disabilitato le directory di pubblicazione per utente. Se state usando Apache, cercate la direttiva <literal>UserDir</literal> nel vostro file di configurazione. Se non è presente, o se è presente ma il suo valore è <literal>disabled</literal>, allora le directory per utente sono disabilitate. Altrimenti, la stringa che segue <literal>UserDir</literal> è il nome della sottodirectory della vostra directory personale che verrà letta da Apache, per esempio <filename class="directory">public_html</filename>.</para> 12.394 12.395 @@ -432,9 +432,9 @@ 12.396 find ~/public_html -type d -print0 | xargs -0r chmod 755 12.397 find ~/public_html -type f -print0 | xargs -0r chmod 644</programlisting> 12.398 12.399 - <para id="x_4ca">L'altra possibilità di errore con i permessi è che potreste ottenere una finestra completamente vuota quando provate a caricare lo script. In questo caso, è probabile che i vostri permessi di accesso siano <emphasis>troppo permissivi</emphasis>. Per esempio, il sottosistema <literal>suexec</literal> di Apache non eseguirà uno script che può essere modificato dal gruppo o dagli altri.</para> 12.400 - 12.401 - <para id="x_4cb">Il vostro server web potrebbe essere configurato per disabilitare l'esecuzione di programmi CGI nella vostra directory di pubblicazione per utente. Ecco la configurazione per utente predefinita di Apache sul mio sistema Fedora.</para> 12.402 + <para id="x_4ca">L’altra possibilità di errore con i permessi è che potreste ottenere una finestra completamente vuota quando provate a caricare lo script. In questo caso, è probabile che i vostri permessi di accesso siano <emphasis>troppo permissivi</emphasis>. Per esempio, il sottosistema <literal>suexec</literal> di Apache non eseguirà uno script che può essere modificato dal gruppo o dagli altri.</para> 12.403 + 12.404 + <para id="x_4cb">Il vostro server web potrebbe essere configurato per disabilitare l’esecuzione di programmi CGI nella vostra directory di pubblicazione per utente. Ecco la configurazione per utente predefinita di Apache sul mio sistema Fedora.</para> 12.405 12.406 &ch06-apache-config.lst; 12.407 12.408 @@ -443,9 +443,9 @@ 12.409 <para id="x_4cd">Se vedete che Apache vi restituisce il testo dello script CGI invece di eseguirlo, potreste dover attivare (se è già presente) o aggiungere una direttiva come questa.</para> 12.410 <programlisting>AddHandler cgi-script .cgi</programlisting> 12.411 12.412 - <para id="x_4ce">Può anche capitare che vi venga restituita una traccia colorata dello stack di esecuzione di Python dove l'interprete afferma di non poter importare un modulo relativo a <literal>mercurial</literal>. Questo è un concreto passo in avanti! Il server ora è in grado di eseguire il vostro script CGI. Questo errore può accadere soltanto se state eseguendo un'installazione privata di Mercurial invece di un'installazione di sistema. Ricordate che il server web esegue il programma CGI senza alcuna variabile d'ambiente che date per scontata in una sessione interattiva. Se vi capita questo errore, aprite la vostra copia di <filename role="special">hgweb.cgi</filename> e seguite le indicazioni che trovate per impostare correttamente la vostra variabile d'ambiente <envar>PYTHONPATH</envar>.</para> 12.413 - 12.414 - <para id="x_4cf">Infine, otterrete <emphasis>sicuramente</emphasis> un'altra traccia colorata dello stack di esecuzione di Python: questa volta l'interprete si lamenterà di non poter trovare <filename class="directory">/path/to/repository</filename>. Modificate il vostro script <filename role="special">hgweb.cgi</filename> per sostituire la stringa <filename class="directory">/path/to/repository</filename> con il percorso completo del repository che volete condividere.</para> 12.415 + <para id="x_4ce">Può anche capitare che vi venga restituita una traccia colorata dello stack di esecuzione di Python dove l’interprete afferma di non poter importare un modulo relativo a <literal>mercurial</literal>. Questo è un concreto passo in avanti! Il server ora è in grado di eseguire il vostro script CGI. Questo errore può accadere soltanto se state eseguendo un’installazione privata di Mercurial invece di un’installazione di sistema. Ricordate che il server web esegue il programma CGI senza alcuna variabile d’ambiente che date per scontata in una sessione interattiva. Se vi capita questo errore, aprite la vostra copia di <filename role="special">hgweb.cgi</filename> e seguite le indicazioni che trovate per impostare correttamente la vostra variabile d’ambiente <envar>PYTHONPATH</envar>.</para> 12.416 + 12.417 + <para id="x_4cf">Infine, otterrete <emphasis>sicuramente</emphasis> un’altra traccia colorata dello stack di esecuzione di Python: questa volta l’interprete si lamenterà di non poter trovare <filename class="directory">/path/to/repository</filename>. Modificate il vostro script <filename role="special">hgweb.cgi</filename> per sostituire la stringa <filename class="directory">/path/to/repository</filename> con il percorso completo del repository che volete condividere.</para> 12.418 12.419 <para id="x_4d0">A questo punto, quando provate a ricaricare la pagina, vi si dovrebbe presentare una gradevole vista HTML della cronologia del vostro repository. Whew!</para> 12.420 </sect3> 12.421 @@ -467,7 +467,7 @@ 12.422 12.423 <para id="x_4d4">Lo script <filename role="special">hgweb.cgi</filename> ha una fastidiosa restrizione che vi permette solo di pubblicare un singolo repository. Se volete pubblicarne più di uno senza complicarvi la vita con molteplici copie dello stesso script, ognuna con un nome diverso, la scelta migliore è quella di usare lo script <filename role="special">hgwebdir.cgi</filename>.</para> 12.424 12.425 - <para id="x_4d5">La procedura per configurare <filename role="special">hgwebdir.cgi</filename> è solo leggermente più complicata di quella per <filename role="special">hgweb.cgi</filename>. Per prima cosa, dovete ottenere una copia dello script. Se non ne avete una sottomano, potete scaricala dal repository principale di Mercurial all'indirizzo <ulink url="http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi">http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi</ulink>.</para> 12.426 + <para id="x_4d5">La procedura per configurare <filename role="special">hgwebdir.cgi</filename> è solo leggermente più complicata di quella per <filename role="special">hgweb.cgi</filename>. Per prima cosa, dovete ottenere una copia dello script. Se non ne avete una sottomano, potete scaricala dal repository principale di Mercurial all’indirizzo <ulink url="http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi">http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi</ulink>.</para> 12.427 12.428 <para id="x_4d6">Dovrete copiare questo script nella vostra directory <filename class="directory">public_html</filename> e assicurarvi che sia eseguibile.</para> 12.429 12.430 @@ -481,9 +481,9 @@ 12.431 <para id="x_4d9">Il modo più facile di configurare <filename role="special">hgwebdir.cgi</filename> è tramite una sezione chiamata <literal>collections</literal> che vi consentirà di pubblicare automaticamente <emphasis>tutti</emphasis> i repository contenuti nelle directory che nominate. La sezione dovrebbe somigliare a questa:</para> 12.432 <programlisting>[collections] 12.433 /mia/radice = /mia/radice</programlisting> 12.434 - <para id="x_4da">Mercurial la interpreta guardando al nome della directory sul lato <emphasis>destro</emphasis> del segno <quote><literal>=</literal></quote>, individuando i repository nella gerarchia contenuta in quella directory e usando il testo sul lato <emphasis>sinistro</emphasis> per eliminare il testo corrispondente dai nomi che elencherà effettivamente nell'interfaccia web. I componenti del percorso che rimangono dopo questa eliminazione formano un <quote>percorso virtuale</quote>.</para> 12.435 - 12.436 - <para id="x_4db">Dato l'esempio precedente, se abbiamo un repository il cui percorso locale è <filename class="directory">/mia/radice/questo/repository</filename>, lo script CGI eliminerà la parte <filename class="directory">/mia/radice</filename> iniziale dal nome e pubblicherà il repository con il percorso virtuale <filename class="directory">questo/repository</filename>. Se l'URL per il nostro script CGI è <literal>http://nomemacchina/~nomeutente/hgwebdir.cgi</literal>, l'URL completo per quel repository sarà <literal>http://nomemacchina/~nomeutente/hgwebdir.cgi/questo/repository</literal>.</para> 12.437 + <para id="x_4da">Mercurial la interpreta guardando al nome della directory sul lato <emphasis>destro</emphasis> del segno <quote><literal>=</literal></quote>, individuando i repository nella gerarchia contenuta in quella directory e usando il testo sul lato <emphasis>sinistro</emphasis> per eliminare il testo corrispondente dai nomi che elencherà effettivamente nell’interfaccia web. I componenti del percorso che rimangono dopo questa eliminazione formano un <quote>percorso virtuale</quote>.</para> 12.438 + 12.439 + <para id="x_4db">Dato l’esempio precedente, se abbiamo un repository il cui percorso locale è <filename class="directory">/mia/radice/questo/repository</filename>, lo script CGI eliminerà la parte <filename class="directory">/mia/radice</filename> iniziale dal nome e pubblicherà il repository con il percorso virtuale <filename class="directory">questo/repository</filename>. Se l’URL per il nostro script CGI è <literal>http://nomemacchina/~nomeutente/hgwebdir.cgi</literal>, l’URL completo per quel repository sarà <literal>http://nomemacchina/~nomeutente/hgwebdir.cgi/questo/repository</literal>.</para> 12.440 12.441 <para id="x_4dc">Se sostituiamo <filename class="directory">/mia/radice</filename> sul lato sinstro di questo esempio con <filename class="directory">/mia</filename>, allora <filename role="special">hgwebdir.cgi</filename> eliminerà solo <filename class="directory">/mia</filename> dal nome del repository e ci darà il percorso virtuale <filename class="directory">radice/questo/repository</filename> invece di <filename class="directory">questo/repository</filename>.</para> 12.442 12.443 @@ -498,7 +498,7 @@ 12.444 <programlisting>[paths] 12.445 repo1 = /mio/percorso/vero/qualche/repository 12.446 repo2 = /qualche/percorso/verso/un/altro</programlisting> 12.447 - <para id="x_4e0">In questo caso, il percorso virtuale (il componente che apparirà in un URL) è sul lato sinistro di ogni definizione, mentre il percorso del repository è sulla destra. Notate che non c'è bisogno che esista alcuna relazione tra il percorso virtuale che scegliete e l'ubicazione di un repository sul vostro file system.</para> 12.448 + <para id="x_4e0">In questo caso, il percorso virtuale (il componente che apparirà in un URL) è sul lato sinistro di ogni definizione, mentre il percorso del repository è sulla destra. Notate che non c’è bisogno che esista alcuna relazione tra il percorso virtuale che scegliete e l’ubicazione di un repository sul vostro file system.</para> 12.449 12.450 <para id="x_4e1">Se lo desiderate, potete usare entrambe le sezioni <literal>collections</literal> e <literal>paths</literal> contemporaneamente in un unico file di configurazione.</para> 12.451 12.452 @@ -513,7 +513,7 @@ 12.453 <sect2> 12.454 <title>Scaricare gli archivi dei sorgenti</title> 12.455 12.456 - <para id="x_4e3">L'interfaccia web di Mercurial permette agli utenti di scaricare un archivio di qualsiasi revisione. Questo archivio conterrà la fotografia della directory di lavoro scattata su quella revisione, ma non conterrà una copia dei dati del repository.</para> 12.457 + <para id="x_4e3">L’interfaccia web di Mercurial permette agli utenti di scaricare un archivio di qualsiasi revisione. Questo archivio conterrà la fotografia della directory di lavoro scattata su quella revisione, ma non conterrà una copia dei dati del repository.</para> 12.458 12.459 <para id="x_4e4">Per default, questa funzione è disabilitata. Per abilitarla, dovrete aggiungere un elemento <envar role="rc-item-web">allow_archive</envar> alla sezione <literal role="rc-web">web</literal> del vostro file <filename role="special">~/.hgrc</filename> come spiegato in dettaglio nella prossima sezione.</para> 12.460 </sect2> 12.461 @@ -522,7 +522,7 @@ 12.462 12.463 <para id="x_4e5">Le interfacce web di Mercurial (il comando <command role="hg-cmd">hg serve</command> e gli script <filename role="special">hgweb.cgi</filename> e <filename role="special">hgwebdir.cgi</filename>) hanno un certo numero di opzioni di configurazione che potete impostare. Queste opzioni appartengono a una sezione chiamata <literal role="rc-web">web</literal>.</para> 12.464 <itemizedlist> 12.465 - <listitem><para id="x_4e6"><envar role="rc-item-web">allow_archive</envar>: Determina qual è (e se c'è) il meccanismo di scaricamento che viene supportato da Mercurial. Se abilitate questa funzione, gli utenti dell'interfaccia web saranno in grado di scaricare un archivio di qualsiasi revisione stiano visitando nel repository. Per abilitare la funzione di archivio, questo elemento deve prendere la forma di una sequenza di parole scelte dalla lista seguente.</para> 12.466 + <listitem><para id="x_4e6"><envar role="rc-item-web">allow_archive</envar>: Determina qual è (e se c’è) il meccanismo di scaricamento che viene supportato da Mercurial. Se abilitate questa funzione, gli utenti dell’interfaccia web saranno in grado di scaricare un archivio di qualsiasi revisione stiano visitando nel repository. Per abilitare la funzione di archivio, questo elemento deve prendere la forma di una sequenza di parole scelte dalla lista seguente.</para> 12.467 <itemizedlist> 12.468 <listitem><para id="x_4e7"><literal>bz2</literal>: un archivio <command>tar</command>, compresso usando la compressione <literal>bzip2</literal>. Questo formato ha il miglior rapporto di compressione, ma usa più tempo di CPU sul server.</para> 12.469 </listitem> 12.470 @@ -535,23 +535,23 @@ 12.471 <programlisting>[web] 12.472 allow_archive = bz2 gz zip</programlisting> 12.473 </listitem> 12.474 - <listitem><para id="x_4eb"><envar role="rc-item-web">allowpull</envar>: booleano. Determina se l'interfaccia web permette agli utenti remoti di usare i comandi <command role="hg-cmd">hg pull</command> e <command role="hg-cmd">hg clone</command> su questo repository via HTTP. Se impostato a <literal>no</literal> o a <literal>false</literal>, solo la parte <quote>orientata agli umani</quote> dell'interfaccia web sarà disponibile.</para> 12.475 - </listitem> 12.476 - <listitem><para id="x_4ec"><envar role="rc-item-web">contact</envar>: stringa. Una stringa di testo libero (ma preferibilmente breve) che identifica la persona o il gruppo responsabile del repository. Questa stringa contiene spesso il nome e l'indirizzo email di una persona o di una mailing list. Spesso ha senso inserire questa voce nel file <filename role="special">.hg/hgrc</filename> del singolo repository, ma può anche avere senso utilizzarla in un file <filename role="special">~/.hgrc</filename> globale se tutti i repository hanno un singolo manutentore.</para> 12.477 + <listitem><para id="x_4eb"><envar role="rc-item-web">allowpull</envar>: booleano. Determina se l’interfaccia web permette agli utenti remoti di usare i comandi <command role="hg-cmd">hg pull</command> e <command role="hg-cmd">hg clone</command> su questo repository via HTTP. Se impostato a <literal>no</literal> o a <literal>false</literal>, solo la parte <quote>orientata agli umani</quote> dell’interfaccia web sarà disponibile.</para> 12.478 + </listitem> 12.479 + <listitem><para id="x_4ec"><envar role="rc-item-web">contact</envar>: stringa. Una stringa di testo libero (ma preferibilmente breve) che identifica la persona o il gruppo responsabile del repository. Questa stringa contiene spesso il nome e l’indirizzo email di una persona o di una mailing list. Spesso ha senso inserire questa voce nel file <filename role="special">.hg/hgrc</filename> del singolo repository, ma può anche avere senso utilizzarla in un file <filename role="special">~/.hgrc</filename> globale se tutti i repository hanno un singolo manutentore.</para> 12.480 </listitem> 12.481 <listitem><para id="x_4ed"><envar role="rc-item-web">maxchanges</envar>: intero. Il numero massimo predefinito di changeset da visualizzare in una singola pagina web.</para> 12.482 </listitem> 12.483 <listitem><para id="x_4ee"><envar role="rc-item-web">maxfiles</envar>: intero. Il numero massimo predefinito di file modificati da visualizzare in una singola pagina web.</para> 12.484 </listitem> 12.485 - <listitem><para id="x_4ef"><envar role="rc-item-web">stripes</envar>: intero. Se l'interfaccia web mostra strisce a colori alternati per rendere più facile l'allineamento visuale delle righe quando state guardando una tabella, questo numero controlla il numero di righe in ogni striscia.</para> 12.486 - </listitem> 12.487 - <listitem><para id="x_4f0"><envar role="rc-item-web">style</envar>: controlla il template usato da Mercurial per visualizzare l'interfaccia web. Mercurial include diversi template web.</para> 12.488 + <listitem><para id="x_4ef"><envar role="rc-item-web">stripes</envar>: intero. Se l’interfaccia web mostra strisce a colori alternati per rendere più facile l’allineamento visuale delle righe quando state guardando una tabella, questo numero controlla il numero di righe in ogni striscia.</para> 12.489 + </listitem> 12.490 + <listitem><para id="x_4f0"><envar role="rc-item-web">style</envar>: controlla il template usato da Mercurial per visualizzare l’interfaccia web. Mercurial include diversi template web.</para> 12.491 <itemizedlist> 12.492 <listitem> 12.493 <para id="x_6aa"><literal>coal</literal> è monocromatico.</para> 12.494 </listitem> 12.495 <listitem> 12.496 - <para id="x_6ab"><literal>gitweb</literal> emula lo stile visivo dell'interfaccia web di git.</para> 12.497 + <para id="x_6ab"><literal>gitweb</literal> emula lo stile visivo dell’interfaccia web di git.</para> 12.498 </listitem> 12.499 <listitem> 12.500 <para id="x_6ac"><literal>monoblue</literal> usa blu e grigi uniformi.</para> 12.501 @@ -578,7 +578,7 @@ 12.502 <itemizedlist> 12.503 <listitem><para id="x_4f4"><envar role="rc-item-web">description</envar>: stringa. Una stringa di testo libero (ma preferibilmente breve) che descrive i contenuti o lo scopo del repository.</para> 12.504 </listitem> 12.505 - <listitem><para id="x_4f5"><envar role="rc-item-web">name</envar>: stringa. Il nome da usare per il repository nell'interfaccia web. Questo rimpiazza il nome predefinito, che è l'ultimo componente del percorso di un repository.</para> 12.506 + <listitem><para id="x_4f5"><envar role="rc-item-web">name</envar>: stringa. Il nome da usare per il repository nell’interfaccia web. Questo rimpiazza il nome predefinito, che è l’ultimo componente del percorso di un repository.</para> 12.507 </listitem></itemizedlist> 12.508 </sect3> 12.509 12.510 @@ -589,7 +589,7 @@ 12.511 <itemizedlist> 12.512 <listitem><para id="x_4f7"><envar role="rc-item-web">accesslog</envar>: percorso. Il nome di un file in cui tenere un registro degli accessi. Normalmente, il comando <command role="hg-cmd">hg serve</command> scrive queste informazioni sul canale di uscita predefinito, non su un file. Le voci del registro vengono scritte nel formato <quote>combinato</quote> che è uno standard usato da quasi tutti i server web.</para> 12.513 </listitem> 12.514 - <listitem><para id="x_4f8"><envar role="rc-item-web">address</envar>: stringa. L'indirizzo locale su cui il server dovrebbe essere in ascolto per le connessioni in entrata. Per default, il server è in ascolto su tutti gli indirizzi.</para> 12.515 + <listitem><para id="x_4f8"><envar role="rc-item-web">address</envar>: stringa. L’indirizzo locale su cui il server dovrebbe essere in ascolto per le connessioni in entrata. Per default, il server è in ascolto su tutti gli indirizzi.</para> 12.516 </listitem> 12.517 <listitem><para id="x_4f9"><envar role="rc-item-web">errorlog</envar>: percorso. Il nome di un file in cui tenere un registro degli errori. Normalmente, il comando <command role="hg-cmd">hg serve</command> scrive queste informazioni sul canale di uscita predefinito, non su un file.</para> 12.518 </listitem> 12.519 @@ -602,9 +602,9 @@ 12.520 <sect3> 12.521 <title>Scegliere il giusto file <filename role="special">~/.hgrc</filename> a cui aggiungere elementi della sezione <literal role="rc-web">web</literal></title> 12.522 12.523 - <para id="x_4fc">È importante ricordare che un server web come Apache o <literal>lighttpd</literal> sarà in esecuzione sotto l'identità di un utente diverso dal vostro. Anche gli script CGI eseguiti dal vostro server, come <filename role="special">hgweb.cgi</filename>, verranno solitamente eseguiti sotto quell'identità.</para> 12.524 - 12.525 - <para id="x_4fd">Se aggiungete elementi della sezione <literal role="rc-web">web</literal> al vostro file <filename role="special">~/.hgrc</filename> personale, gli script CGI non potranno leggere quel file <filename role="special">~/.hgrc</filename>. Quelle impostazioni quindi avranno effetto solo sul comportamento del comando <command role="hg-cmd">hg serve</command> quando sarete voi a eseguirlo. Per fare in modo che gli script CGI vedano le vostre impostazioni, create un file <filename role="special">~/.hgrc</filename> nella directory personale dell'utente la cui identità viene usata per eseguire il vostro server web, oppure aggiungete quelle impostazioni a un file <filename role="special">hgrc</filename> di sistema.</para> 12.526 + <para id="x_4fc">È importante ricordare che un server web come Apache o <literal>lighttpd</literal> sarà in esecuzione sotto l’identità di un utente diverso dal vostro. Anche gli script CGI eseguiti dal vostro server, come <filename role="special">hgweb.cgi</filename>, verranno solitamente eseguiti sotto quell’identità.</para> 12.527 + 12.528 + <para id="x_4fd">Se aggiungete elementi della sezione <literal role="rc-web">web</literal> al vostro file <filename role="special">~/.hgrc</filename> personale, gli script CGI non potranno leggere quel file <filename role="special">~/.hgrc</filename>. Quelle impostazioni quindi avranno effetto solo sul comportamento del comando <command role="hg-cmd">hg serve</command> quando sarete voi a eseguirlo. Per fare in modo che gli script CGI vedano le vostre impostazioni, create un file <filename role="special">~/.hgrc</filename> nella directory personale dell’utente la cui identità viene usata per eseguire il vostro server web, oppure aggiungete quelle impostazioni a un file <filename role="special">hgrc</filename> di sistema.</para> 12.529 </sect3> 12.530 </sect2> 12.531 </sect1> 12.532 @@ -612,16 +612,16 @@ 12.533 <sect1> 12.534 <title>Configurazione di sistema</title> 12.535 12.536 - <para id="x_6b0">Sui sistemi di tipo Unix condivisi da molteplici utenti (come un server su cui le persone pubblicano i propri cambiamenti) ha spesso senso impostare alcuni comportamenti globali predefiniti, come il tema grafico da usare nell'interfaccia web.</para> 12.537 - 12.538 - <para id="x_6b1">Se il file <filename>/etc/mercurial/hgrc</filename> esiste, Mercurial lo leggerà all'avvio e applicherà ogni impostazione di configurazione trovata in quel file. Cercherà anche i file il cui nome termina con l'estensione <literal>.rc</literal> in una directory chiamata <filename>/etc/mercurial/hgrc.d</filename> e applicherà le impostazioni di configurazione trovate in ognuno di quei file.</para> 12.539 + <para id="x_6b0">Sui sistemi di tipo Unix condivisi da molteplici utenti (come un server su cui le persone pubblicano i propri cambiamenti) ha spesso senso impostare alcuni comportamenti globali predefiniti, come il tema grafico da usare nell’interfaccia web.</para> 12.540 + 12.541 + <para id="x_6b1">Se il file <filename>/etc/mercurial/hgrc</filename> esiste, Mercurial lo leggerà all’avvio e applicherà ogni impostazione di configurazione trovata in quel file. Cercherà anche i file il cui nome termina con l’estensione <literal>.rc</literal> in una directory chiamata <filename>/etc/mercurial/hgrc.d</filename> e applicherà le impostazioni di configurazione trovate in ognuno di quei file.</para> 12.542 12.543 <sect2> 12.544 <title>Rendere Mercurial meno prevenuto</title> 12.545 12.546 - <para id="x_6b2">Un file <filename>hgrc</filename> globale può essere utile nella situazione in cui gli utenti stanno estraendo cambiamenti posseduti da altri utenti. Per default, Mercurial non si fida della maggior parte degli elementi di configurazione contenuti nel file <filename>.hg/hgrc</filename> all'interno di un repository che è posseduto da un utente differente. Se cloniamo o estraiamo i cambiamenti da un repository di questo tipo, Mercurial stamperà un avvertimento dicendo che non si fida dei dati nel file <filename>.hg/hgrc</filename> di quel repository.</para> 12.547 - 12.548 - <para id="x_6b3">Se tutti i membri di uno specifico gruppo Unix fanno parte dello stesso gruppo di sviluppo e <emphasis>dovrebbero</emphasis> fidarsi l'uno delle impostazioni di configurazione dell'altro, o se vogliamo fidarci di alcuni utenti particolari, possiamo rimpiazzare il comportamento guardingo predefinito di Mercurial creando un file <filename>hgrc</filename> di sistema come il seguente:</para> 12.549 + <para id="x_6b2">Un file <filename>hgrc</filename> globale può essere utile nella situazione in cui gli utenti stanno estraendo cambiamenti posseduti da altri utenti. Per default, Mercurial non si fida della maggior parte degli elementi di configurazione contenuti nel file <filename>.hg/hgrc</filename> all’interno di un repository che è posseduto da un utente differente. Se cloniamo o estraiamo i cambiamenti da un repository di questo tipo, Mercurial stamperà un avvertimento dicendo che non si fida dei dati nel file <filename>.hg/hgrc</filename> di quel repository.</para> 12.550 + 12.551 + <para id="x_6b3">Se tutti i membri di uno specifico gruppo Unix fanno parte dello stesso gruppo di sviluppo e <emphasis>dovrebbero</emphasis> fidarsi l’uno delle impostazioni di configurazione dell’altro, o se vogliamo fidarci di alcuni utenti particolari, possiamo rimpiazzare il comportamento guardingo predefinito di Mercurial creando un file <filename>hgrc</filename> di sistema come il seguente:</para> 12.552 12.553 <programlisting># Salva questo file con un nome tipo /etc/mercurial/hgrc.d/trust.rc 12.554 [trusted]
13.1 --- a/it/ch07-filenames.xml Sat Aug 22 21:01:56 2009 +0200 13.2 +++ b/it/ch07-filenames.xml Sat Aug 22 21:55:05 2009 +0200 13.3 @@ -13,7 +13,7 @@ 13.4 13.5 &interaction.filenames.files; 13.6 13.7 - <para id="x_546">Quando fornite un nome di directory, Mercurial interpreterà questa azione come la volontà di <quote>operare su tutti i file in questa directory e nelle sue sottodirectory</quote>. Mercurial considera i file e le sottodirectory in una directory secondo l'ordine alfabetico. Quando incontra una sottodirectory, attraverserà quella sottodirectory prima di continuare con la directory corrente.</para> 13.8 + <para id="x_546">Quando fornite un nome di directory, Mercurial interpreterà questa azione come la volontà di <quote>operare su tutti i file in questa directory e nelle sue sottodirectory</quote>. Mercurial considera i file e le sottodirectory in una directory secondo l’ordine alfabetico. Quando incontra una sottodirectory, attraverserà quella sottodirectory prima di continuare con la directory corrente.</para> 13.9 13.10 &interaction.filenames.dirs; 13.11 </sect1> 13.12 @@ -23,16 +23,16 @@ 13.13 13.14 <para id="x_547">I comandi Mercurial che lavorano con i nomi di file assumono un utile comportamento predefinito quando li invocate senza passare alcun nome di file o pattern. Il comportamento che dovreste aspettarvi dipende dalla funzione del comando. Ecco alcune regole pratiche che potete usare per predire quello che un comando probabilmente farà se non gli date alcun nome con cui lavorare.</para> 13.15 <itemizedlist> 13.16 - <listitem><para id="x_548">La maggior parte dei comandi opererà sull'intera directory di lavoro. Per esempio, questo è quello che fa il comando <command role="hg-cmd">hg add</command>.</para> 13.17 - </listitem> 13.18 - <listitem><para id="x_549">Se gli effetti di un comando sono difficili o impossibili da invertire, sarete obbligati a fornirgli esplicitamente almeno un nome o un pattern (si veda più avanti). Questo vi protegge, per esempio, dalla cancellazione accidentale dei file causata da un'esecuzione di <command role="hg-cmd">hg remove</command> senza argomenti.</para> 13.19 + <listitem><para id="x_548">La maggior parte dei comandi opererà sull’intera directory di lavoro. Per esempio, questo è quello che fa il comando <command role="hg-cmd">hg add</command>.</para> 13.20 + </listitem> 13.21 + <listitem><para id="x_549">Se gli effetti di un comando sono difficili o impossibili da invertire, sarete obbligati a fornirgli esplicitamente almeno un nome o un pattern (si veda più avanti). Questo vi protegge, per esempio, dalla cancellazione accidentale dei file causata da un’esecuzione di <command role="hg-cmd">hg remove</command> senza argomenti.</para> 13.22 </listitem></itemizedlist> 13.23 13.24 - <para id="x_54a">Se questi comportamenti predefiniti non vi soddisfano, è facile aggirarli. Se normalmente un comando opera sull'intera directory di lavoro, potete passargli il nome <quote><filename class="directory">.</filename></quote> per invocarlo solo sulla directory corrente e sulle sue sottodirectory.</para> 13.25 + <para id="x_54a">Se questi comportamenti predefiniti non vi soddisfano, è facile aggirarli. Se normalmente un comando opera sull’intera directory di lavoro, potete passargli il nome <quote><filename class="directory">.</filename></quote> per invocarlo solo sulla directory corrente e sulle sue sottodirectory.</para> 13.26 13.27 &interaction.filenames.wdir-subdir; 13.28 13.29 - <para id="x_54b">Sulla stessa falsariga, alcuni comandi normalmente stampano nomi di file relativi alla radice del repository anche quando li invocate da una sottodirectory. Questi comandi stamperanno nomi di file relativi alla vostra sottodirectory se passate loro nomi espliciti. Qui di seguito eseguiremo <command role="hg-cmd">hg status</command> da una sottodirectory e lo faremo agire sull'intera directory di lavoro pur stampando nomi di file relativi alla nostra sottodirectory, passandogli il risultato del comando <command role="hg-cmd">hg root</command>.</para> 13.30 + <para id="x_54b">Sulla stessa falsariga, alcuni comandi normalmente stampano nomi di file relativi alla radice del repository anche quando li invocate da una sottodirectory. Questi comandi stamperanno nomi di file relativi alla vostra sottodirectory se passate loro nomi espliciti. Qui di seguito eseguiremo <command role="hg-cmd">hg status</command> da una sottodirectory e lo faremo agire sull’intera directory di lavoro pur stampando nomi di file relativi alla nostra sottodirectory, passandogli il risultato del comando <command role="hg-cmd">hg root</command>.</para> 13.31 13.32 &interaction.filenames.wdir-relname; 13.33 </sect1> 13.34 @@ -40,11 +40,11 @@ 13.35 <sect1> 13.36 <title>Mercurial vi dice cosa sta succedendo</title> 13.37 13.38 - <para id="x_54c">L'esempio di <command role="hg-cmd">hg add</command> nella sezione precedente illustra qualcos'altro che è utile sapere sui comandi Mercurial. Se un comando opera su un file che non avete nominato esplicitamente sulla riga di comando, di solito stamperà il nome del file in modo che non veniate sorpresi da quello che sta succedendo.</para> 13.39 + <para id="x_54c">L’esempio di <command role="hg-cmd">hg add</command> nella sezione precedente illustra qualcos’altro che è utile sapere sui comandi Mercurial. Se un comando opera su un file che non avete nominato esplicitamente sulla riga di comando, di solito stamperà il nome del file in modo che non veniate sorpresi da quello che sta succedendo.</para> 13.40 13.41 <para id="x_54d">In questo caso, Mercurial segue il principio della <emphasis>minima sorpresa</emphasis>. Se avete fornito il nome esatto di un file sulla riga di comando, non ha senso ripetervelo. Se Mercurial sta agendo <emphasis>implicitamente</emphasis> su un file, per esempio perché non avete fornito alcun nome, o su una directory, o su un pattern (si veda più avanti), ritiene sia più sicuro farvi sapere su quali file sta lavorando.</para> 13.42 13.43 - <para id="x_54e">Potete ridurre al silenzio i comandi che si comportano in questo modo usando l'opzione <option role="hg-opt-global">-q</option>. Potete anche dire loro di stampare il nome di tutti i file, anche quelli che avete nominato esplicitamente, usando l'opzione <option role="hg-opt-global">-v</option>.</para> 13.44 + <para id="x_54e">Potete ridurre al silenzio i comandi che si comportano in questo modo usando l’opzione <option role="hg-opt-global">-q</option>. Potete anche dire loro di stampare il nome di tutti i file, anche quelli che avete nominato esplicitamente, usando l’opzione <option role="hg-opt-global">-v</option>.</para> 13.45 </sect1> 13.46 13.47 <sect1> 13.48 @@ -56,7 +56,7 @@ 13.49 13.50 <para id="x_551">Per fornire un pattern al posto di un nome ordinario sulla riga di comando, il meccanismo è semplice:</para> 13.51 <programlisting>sintassi:corpodelpattern</programlisting> 13.52 - <para id="x_552">Quindi, un pattern viene identificato da una breve stringa di testo che indica il tipo del pattern, seguita dai due punti, seguiti dall'effettivo pattern.</para> 13.53 + <para id="x_552">Quindi, un pattern viene identificato da una breve stringa di testo che indica il tipo del pattern, seguita dai due punti, seguiti dall’effettivo pattern.</para> 13.54 13.55 <para id="x_553">Mercurial supporta due tipi di sintassi per i pattern. Quello usato più spesso è chiamato <literal>glob</literal>: è lo stesso tipo di pattern usato dalla shell Unix e dovrebbe essere familiare anche agli utenti del prompt dei comandi di Windows.</para> 13.56 13.57 @@ -69,9 +69,9 @@ 13.58 <sect2> 13.59 <title>I pattern <literal>glob</literal> sullo stile della shell</title> 13.60 13.61 - <para id="x_557">Questa è un'introduzione ai tipi di pattern che potete usare quando state cercando una corrispondenza con un pattern di tipo glob.</para> 13.62 - 13.63 - <para id="x_558">Il carattere <quote><literal>*</literal></quote> corrisponde a qualsiasi stringa all'interno di una singola directory.</para> 13.64 + <para id="x_557">Questa è un’introduzione ai tipi di pattern che potete usare quando state cercando una corrispondenza con un pattern di tipo glob.</para> 13.65 + 13.66 + <para id="x_558">Il carattere <quote><literal>*</literal></quote> corrisponde a qualsiasi stringa all’interno di una singola directory.</para> 13.67 13.68 &interaction.filenames.glob.star; 13.69 13.70 @@ -87,7 +87,7 @@ 13.71 13.72 &interaction.filenames.glob.range; 13.73 13.74 - <para id="x_55c">Se il primo carattere dopo <quote><literal>[</literal></quote> in una classe di caratteri è <quote><literal>!</literal></quote>, si ottiene l'effetto di <emphasis>negare</emphasis> la classe, facendola corrispondere a qualsiasi carattere non compreso nella classe.</para> 13.75 + <para id="x_55c">Se il primo carattere dopo <quote><literal>[</literal></quote> in una classe di caratteri è <quote><literal>!</literal></quote>, si ottiene l’effetto di <emphasis>negare</emphasis> la classe, facendola corrispondere a qualsiasi carattere non compreso nella classe.</para> 13.76 13.77 <para id="x_55d">Un carattere <quote><literal>{</literal></quote> comincia un gruppo di sottopattern, che trova una corrispondenza se un qualsiasi sottopattern nel gruppo trova una corrispondenza. Il carattere <quote><literal>,</literal></quote> separa i sottopattern e il carattere <quote><literal>}</literal></quote> termina il gruppo.</para> 13.78 13.79 @@ -109,9 +109,9 @@ 13.80 13.81 <para id="x_560">Non discuterò alcun dettaglio del dialetto di regexp di Mercurial in questo libro, dato che le espressioni regolari non vengono usate molto spesso. Le regexp in stile Perl sono comunque già documentate in maniera esauriente su una moltitudine di siti web e in numerosi libri. Invece, qui mi concentrerò su alcune cose che dovreste sapere se vi trovate ad aver bisogno di usare le espressioni regolari con Mercurial.</para> 13.82 13.83 - <para id="x_561">Un'espressione regolare cerca una corrispondenza con un intero nome di file, relativo alla radice del repository. In altre parole, anche se siete già nella sottodirectory <filename class="directory">foo</filename>, se volete una corrispondenza con i file in questa directory il vostro pattern dovrà cominciare con <quote><literal>foo/</literal></quote>.</para> 13.84 - 13.85 - <para id="x_562">Una cosa da notare, se avete familiarità con le regexp in stile Perl, è che le espressioni regolari di Mercurial sono <emphasis>vincolate</emphasis>, nel senso che un'espressione regolare cerca una corrispondenza partendo sempre dall'inizio di una stringa e non da altre posizioni all'interno della stringa. Per cercare una corrispondenza in qualsiasi punto della stringa, il vostro pattern deve cominciare con <quote><literal>.*</literal></quote>.</para> 13.86 + <para id="x_561">Un’espressione regolare cerca una corrispondenza con un intero nome di file, relativo alla radice del repository. In altre parole, anche se siete già nella sottodirectory <filename class="directory">foo</filename>, se volete una corrispondenza con i file in questa directory il vostro pattern dovrà cominciare con <quote><literal>foo/</literal></quote>.</para> 13.87 + 13.88 + <para id="x_562">Una cosa da notare, se avete familiarità con le regexp in stile Perl, è che le espressioni regolari di Mercurial sono <emphasis>vincolate</emphasis>, nel senso che un’espressione regolare cerca una corrispondenza partendo sempre dall’inizio di una stringa e non da altre posizioni all’interno della stringa. Per cercare una corrispondenza in qualsiasi punto della stringa, il vostro pattern deve cominciare con <quote><literal>.*</literal></quote>.</para> 13.89 </sect2> 13.90 </sect1> 13.91 13.92 @@ -120,9 +120,9 @@ 13.93 13.94 <para id="x_563">Mercurial non vi fornisce solo una varietà di modi per specificare i file, ma vi permette di vagliare ulteriormente quei file usando i <emphasis>filtri</emphasis>. I comandi che lavorano con i nomi dei file accettano due opzioni di filtraggio.</para> 13.95 <itemizedlist> 13.96 - <listitem><para id="x_564">L'opzione <option role="hg-opt-global">-I</option>, o <option role="hg-opt-global">--include</option>, vi permette di specificare un pattern a cui i nomi dei file devono corrispondere per poter essere elaborati.</para> 13.97 - </listitem> 13.98 - <listitem><para id="x_565">L'opzione <option role="hg-opt-global">-X</option>, o <option role="hg-opt-global">--exclude</option>, vi fornisce un modo per <emphasis>evitare</emphasis> di elaborare i file che corrispondono a questo pattern.</para> 13.99 + <listitem><para id="x_564">L’opzione <option role="hg-opt-global">-I</option>, o <option role="hg-opt-global">--include</option>, vi permette di specificare un pattern a cui i nomi dei file devono corrispondere per poter essere elaborati.</para> 13.100 + </listitem> 13.101 + <listitem><para id="x_565">L’opzione <option role="hg-opt-global">-X</option>, o <option role="hg-opt-global">--exclude</option>, vi fornisce un modo per <emphasis>evitare</emphasis> di elaborare i file che corrispondono a questo pattern.</para> 13.102 </listitem></itemizedlist> 13.103 <para id="x_566">Potete passare più opzioni <option role="hg-opt-global">-I</option> e <option role="hg-opt-global">-X</option> sulla riga di comando e alternarle come preferite. Mercurial interpreta i pattern che riceve usando la sintassi glob per default (ma potete usare le espressioni regolari se ne avete bisogno).</para> 13.104 13.105 @@ -130,7 +130,7 @@ 13.106 13.107 &interaction.filenames.filter.include; 13.108 13.109 - <para id="x_568">L'interpretazione migliore del filtro <option role="hg-opt-global">-X</option> è quella di una richiesta di <quote>elaborare solo i file che non corrispondono a questo pattern</quote>.</para> 13.110 + <para id="x_568">L’interpretazione migliore del filtro <option role="hg-opt-global">-X</option> è quella di una richiesta di <quote>elaborare solo i file che non corrispondono a questo pattern</quote>.</para> 13.111 13.112 &interaction.filenames.filter.exclude; 13.113 </sect1> 13.114 @@ -138,7 +138,7 @@ 13.115 <sect1> 13.116 <title>Ignorare permanentemente file e directory indesiderate</title> 13.117 13.118 - <para id="x_569">Quando create un nuovo repository, è possibile che nel tempo cresca fino a contenere file che <emphasis>non</emphasis> dovrebbero essere gestiti da Mercurial, ma che non vorreste vedere elencati ogni volta che invocate <command>hg status</command>. Per esempio, i <quote>prodotti di assemblaggio</quote> sono file che vengono creati come parte dell'assemblaggio di un progetto ma che non dovrebbero essere gestiti da un sistema di controllo di revisione. I prodotti di assemblaggio più comuni sono i file di elaborazione generati da strumenti software come i compilatori. Un altro esempio sono i file di bloccaggio, i file di lavoro temporanei e i file di backup che gli editor di testo disseminano per le directory e che non ha alcun senso gestire.</para> 13.119 + <para id="x_569">Quando create un nuovo repository, è possibile che nel tempo cresca fino a contenere file che <emphasis>non</emphasis> dovrebbero essere gestiti da Mercurial, ma che non vorreste vedere elencati ogni volta che invocate <command>hg status</command>. Per esempio, i <quote>prodotti di assemblaggio</quote> sono file che vengono creati come parte dell’assemblaggio di un progetto ma che non dovrebbero essere gestiti da un sistema di controllo di revisione. I prodotti di assemblaggio più comuni sono i file di elaborazione generati da strumenti software come i compilatori. Un altro esempio sono i file di bloccaggio, i file di lavoro temporanei e i file di backup che gli editor di testo disseminano per le directory e che non ha alcun senso gestire.</para> 13.120 13.121 <para id="x_6b4">Per fare in modo che Mercurial ignori permanentemente quei file, create un file chiamato <filename>.hgignore</filename> alla radice del vostro repository. <emphasis>Dovreste</emphasis> registrare questo file tramite <command>hg add</command> in modo che Mercurial ne tenga traccia insieme al resto dei contenuti del vostro repository, dato che anche i vostri collaboratori potrebbero trovarlo utile.</para> 13.122 13.123 @@ -197,9 +197,9 @@ 13.124 13.125 <para id="x_571">Quando opera sulla directory di lavoro, Mercurial segue la politica di denominazione del file system su cui la directory di lavoro si trova. Se il file system conserva le maiuscole ma è insensibile a esse, Mercurial tratterà i nomi che differiscono solo per le maiuscole come se fossero uguali.</para> 13.126 13.127 - <para id="x_572">È importante ricordare che questo approccio permette di eseguire su un file system sensibile alle maiuscole (tipicamente Linux o Unix) il commit di un changeset che creerà problemi per gli utenti di file system insensibili alle maiuscole (di solito Windows e MacOS). Se un utente Linux inserisce nel repository le modifiche a due file, uno chiamato <filename>miofile.c</filename> e l'altro chiamato <filename>MioFile.c</filename>, questi file verranno memorizzati correttamente. E gli stessi file verranno correttamente rappresentati come due file separati nella directory di lavoro di altri utenti Linux.</para> 13.128 - 13.129 - <para id="x_573">Se un utente Windows o Mac estrae questo changeset, inizialmente non avrà alcun problema, perché il meccanismo di memorizzazione di un repository Mercurial è sicuro per le maiuscole. Tuttavia, appena tenta di aggiornare la directory di lavoro a quel changeset tramite <command role="hg-cmd">hg update</command>, o di unire il proprio lavoro con quel changeset tramite <command role="hg-cmd">hg merge</command>, Mercurial individuerà il conflitto tra i due nomi di file che il file system tratterebbe come lo stesso nome e impedirà all'aggiornamento o all'unione di avvenire.</para> 13.130 + <para id="x_572">È importante ricordare che questo approccio permette di eseguire su un file system sensibile alle maiuscole (tipicamente Linux o Unix) il commit di un changeset che creerà problemi per gli utenti di file system insensibili alle maiuscole (di solito Windows e MacOS). Se un utente Linux inserisce nel repository le modifiche a due file, uno chiamato <filename>miofile.c</filename> e l’altro chiamato <filename>MioFile.c</filename>, questi file verranno memorizzati correttamente. E gli stessi file verranno correttamente rappresentati come due file separati nella directory di lavoro di altri utenti Linux.</para> 13.131 + 13.132 + <para id="x_573">Se un utente Windows o Mac estrae questo changeset, inizialmente non avrà alcun problema, perché il meccanismo di memorizzazione di un repository Mercurial è sicuro per le maiuscole. Tuttavia, appena tenta di aggiornare la directory di lavoro a quel changeset tramite <command role="hg-cmd">hg update</command>, o di unire il proprio lavoro con quel changeset tramite <command role="hg-cmd">hg merge</command>, Mercurial individuerà il conflitto tra i due nomi di file che il file system tratterebbe come lo stesso nome e impedirà all’aggiornamento o all’unione di avvenire.</para> 13.133 </sect2> 13.134 13.135 <sect2>
14.1 --- a/it/ch08-branch.xml Sat Aug 22 21:01:56 2009 +0200 14.2 +++ b/it/ch08-branch.xml Sat Aug 22 21:55:05 2009 +0200 14.3 @@ -11,7 +11,7 @@ 14.4 <sect1> 14.5 <title>Dare un nome persistente a una revisione</title> 14.6 14.7 - <para id="x_36c">Una volta che avete deciso che vi piacerebbe chiamare <quote>release</quote> una particolare revisione, è una buona idea registrare l'identità di quella revisione. Questo vi permetterà di riprodurre quella release in un momento successivo, qualsiasi sia lo scopo che avete bisogno di raggiungere in quel momento (riprodurre un bug, convertirla verso una nuova piattaforma, etc).</para> 14.8 + <para id="x_36c">Una volta che avete deciso che vi piacerebbe chiamare <quote>release</quote> una particolare revisione, è una buona idea registrare l’identità di quella revisione. Questo vi permetterà di riprodurre quella release in un momento successivo, qualsiasi sia lo scopo che avete bisogno di raggiungere in quel momento (riprodurre un bug, convertirla verso una nuova piattaforma, etc).</para> 14.9 14.10 &interaction.tag.init; 14.11 14.12 @@ -19,7 +19,7 @@ 14.13 14.14 &interaction.tag.tag; 14.15 14.16 - <para id="x_36e">Un'etichetta non è altro che un <quote>nome simbolico</quote> per una revisione. Le etichette esistono puramente per la vostra convenienza: vi offrono un modo comodo e permanente per fare riferimento a una revisione. Mercurial non interpreta in alcun modo i nomi delle etichette che usate, né impone alcuna restrizione sul nome di un'etichetta a parte le poche che sono necessarie affinché l'etichetta possa essere riconosciuta senza ambiguità. Un nome di etichetta non può contenere i seguenti caratteri:</para> 14.17 + <para id="x_36e">Un’etichetta non è altro che un <quote>nome simbolico</quote> per una revisione. Le etichette esistono puramente per la vostra convenienza: vi offrono un modo comodo e permanente per fare riferimento a una revisione. Mercurial non interpreta in alcun modo i nomi delle etichette che usate, né impone alcuna restrizione sul nome di un’etichetta a parte le poche che sono necessarie affinché l’etichetta possa essere riconosciuta senza ambiguità. Un nome di etichetta non può contenere i seguenti caratteri:</para> 14.18 <itemizedlist> 14.19 <listitem><para id="x_36f">due punti (codice ASCII 58, 14.20 <quote><literal>:</literal></quote>)</para> 14.21 @@ -31,11 +31,11 @@ 14.22 <quote><literal>\n</literal></quote>)</para> 14.23 </listitem></itemizedlist> 14.24 14.25 - <para id="x_372">Potete usare il comando <command role="hg-cmd">hg tags</command> per visualizzare le etichette presenti nel vostro repository. Nel risultato del comando, ogni revisione etichettata è identificata prima dal proprio nome, poi dal numero di revisione e infine dall'hash unico della revisione.</para> 14.26 + <para id="x_372">Potete usare il comando <command role="hg-cmd">hg tags</command> per visualizzare le etichette presenti nel vostro repository. Nel risultato del comando, ogni revisione etichettata è identificata prima dal proprio nome, poi dal numero di revisione e infine dall’hash unico della revisione.</para> 14.27 14.28 &interaction.tag.tags; 14.29 14.30 - <para id="x_373">Notate che <literal>tip</literal> viene inclusa nell'elenco mostrato da <command role="hg-cmd">hg tags</command>. L'etichetta <literal>tip</literal> è una speciale etichetta <quote>mobile</quote> che identifica sempre la revisione più recente contenuta in un repository.</para> 14.31 + <para id="x_373">Notate che <literal>tip</literal> viene inclusa nell’elenco mostrato da <command role="hg-cmd">hg tags</command>. L’etichetta <literal>tip</literal> è una speciale etichetta <quote>mobile</quote> che identifica sempre la revisione più recente contenuta in un repository.</para> 14.32 14.33 <para id="x_374">Il comando <command role="hg-cmd">hg tags</command> elenca le etichette in ordine inverso secondo il numero di revisione. Di solito questo significa che le etichette recenti vengono elencate prima delle etichette più vecchie. Significa anche che <literal>tip</literal> è sempre la prima etichetta elencata nel risultato di <command role="hg-cmd">hg tags</command>.</para> 14.34 14.35 @@ -43,75 +43,75 @@ 14.36 14.37 &interaction.tag.log; 14.38 14.39 - <para id="x_376">I comandi Mercurial a cui dovete passare un identificatore di revisione accetteranno il nome di un'etichetta al suo posto. Internamente, Mercurial tradurrà il nome della vostra etichetta nel corrispondente identificatore di revisione e poi userà quest'ultimo per operare.</para> 14.40 + <para id="x_376">I comandi Mercurial a cui dovete passare un identificatore di revisione accetteranno il nome di un’etichetta al suo posto. Internamente, Mercurial tradurrà il nome della vostra etichetta nel corrispondente identificatore di revisione e poi userà quest’ultimo per operare.</para> 14.41 14.42 &interaction.tag.log.v1.0; 14.43 14.44 - <para id="x_377">Non c'è alcun limite al numero di etichette che potete avere in un repository, o al numero di etichette che una singola revisione può avere. Nella pratica, non è una grande idea averne <quote>troppe</quote> (un numero che varierà da progetto a progetto), semplicemente perché le etichette sono pensate per aiutarvi a rintracciare le revisioni: se avete molte etichette, la comodità di usarle per identificare le revisioni diminuisce rapidamente.</para> 14.45 - 14.46 - <para id="x_378">Per esempio, se il vostro progetto definisce nuove milestone con una frequenza di alcuni giorni, è perfettamente ragionevole dotare ognuna di un'etichetta. Ma se avete un sistema di assemblaggio continuo che si assicura di poter assemblare ogni revisione senza problemi, introdurreste troppo rumore etichettando ogni assemblaggio pulito. Invece, potreste etichettare gli assemblaggi falliti (supponendo che siano rari!) o semplicemente evitare di usare le etichette per tenere traccia degli assemblaggi.</para> 14.47 - 14.48 - <para id="x_379">Se volete rimuovere un'etichetta che non volete più, usate <command role="hg-cmd">hg tag --remove</command>.</para> 14.49 + <para id="x_377">Non c’è alcun limite al numero di etichette che potete avere in un repository, o al numero di etichette che una singola revisione può avere. Nella pratica, non è una grande idea averne <quote>troppe</quote> (un numero che varierà da progetto a progetto), semplicemente perché le etichette sono pensate per aiutarvi a rintracciare le revisioni: se avete molte etichette, la comodità di usarle per identificare le revisioni diminuisce rapidamente.</para> 14.50 + 14.51 + <para id="x_378">Per esempio, se il vostro progetto definisce nuove milestone con una frequenza di alcuni giorni, è perfettamente ragionevole dotare ognuna di un’etichetta. Ma se avete un sistema di assemblaggio continuo che si assicura di poter assemblare ogni revisione senza problemi, introdurreste troppo rumore etichettando ogni assemblaggio pulito. Invece, potreste etichettare gli assemblaggi falliti (supponendo che siano rari!) o semplicemente evitare di usare le etichette per tenere traccia degli assemblaggi.</para> 14.52 + 14.53 + <para id="x_379">Se volete rimuovere un’etichetta che non volete più, usate <command role="hg-cmd">hg tag --remove</command>.</para> 14.54 14.55 &interaction.tag.remove; 14.56 14.57 - <para id="x_37a">Potete anche modificare un'etichetta in qualsiasi momento, in modo che identifichi una revisione differente, semplicemente invocando di nuovo il comando <command role="hg-cmd">hg tag</command>. Dovrete usare l'opzione <option role="hg-opt-tag">-f</option> per dire a Mercurial che volete <emphasis>davvero</emphasis> aggiornare l'etichetta.</para> 14.58 + <para id="x_37a">Potete anche modificare un’etichetta in qualsiasi momento, in modo che identifichi una revisione differente, semplicemente invocando di nuovo il comando <command role="hg-cmd">hg tag</command>. Dovrete usare l’opzione <option role="hg-opt-tag">-f</option> per dire a Mercurial che volete <emphasis>davvero</emphasis> aggiornare l’etichetta.</para> 14.59 14.60 &interaction.tag.replace; 14.61 14.62 - <para id="x_37b">La precedente identità dell'etichetta rimarrà permanentemente registrata, ma Mercurial non la userà più. Quindi non c'è alcuna penalità da pagare se etichettate la revisione sbagliata, ma tutto quello che dovete fare dopo aver scoperto il vostro errore è tornare sui vostri passi ed etichettare la revisione corretta.</para> 14.63 - 14.64 - <para id="x_37c">Mercurial memorizza le etichette nel vostro repository in un normale file soggetto al controllo di revisione. Troverete le etichette che avete creato in un file chiamato <filename role="special">.hgtags</filename> alla radice del vostro repository. Quando eseguite il comando <command role="hg-cmd">hg tag</command>, Mercurial modifica questo file, poi ne effettua automaticamente il commit registrandone i cambiamenti. Questo significa che ad ogni esecuzione di <command role="hg-cmd">hg tag</command> corrisponderà un changeset nell'elenco mostrato da <command role="hg-cmd">hg log</command>.</para> 14.65 + <para id="x_37b">La precedente identità dell’etichetta rimarrà permanentemente registrata, ma Mercurial non la userà più. Quindi non c’è alcuna penalità da pagare se etichettate la revisione sbagliata, ma tutto quello che dovete fare dopo aver scoperto il vostro errore è tornare sui vostri passi ed etichettare la revisione corretta.</para> 14.66 + 14.67 + <para id="x_37c">Mercurial memorizza le etichette nel vostro repository in un normale file soggetto al controllo di revisione. Troverete le etichette che avete creato in un file chiamato <filename role="special">.hgtags</filename> alla radice del vostro repository. Quando eseguite il comando <command role="hg-cmd">hg tag</command>, Mercurial modifica questo file, poi ne effettua automaticamente il commit registrandone i cambiamenti. Questo significa che ad ogni esecuzione di <command role="hg-cmd">hg tag</command> corrisponderà un changeset nell’elenco mostrato da <command role="hg-cmd">hg log</command>.</para> 14.68 14.69 &interaction.tag.tip; 14.70 14.71 <sect2> 14.72 - <title>Gestire i conflitti di etichette durante un'unione</title> 14.73 - 14.74 - <para id="x_37d">Avrete raramente bisogno di preoccuparvi del file <filename role="special">.hgtags</filename>, ma talvolta la sua presenza si farà sentire durante un'unione. Il formato del file è semplice: consiste di una serie di righe, ognuna delle quali comincia con un hash di changeset, seguito da uno spazio, seguito dal nome di un'etichetta.</para> 14.75 - 14.76 - <para id="x_37e">Se state risolvendo un conflitto nel file <filename role="special">.hgtags</filename> durante un'unione, c'è una particolarità da ricordare quando modificate il file <filename role="special">.hgtags</filename>: quando Mercurial sta analizzando le etichette in un repository, non legge <emphasis>mai</emphasis> la copia di lavoro del file <filename role="special">.hgtags</filename>, ma legge la revisione del file <emphasis>registrata più recentemente</emphasis>.</para> 14.77 - 14.78 - <para id="x_37f">Una sfortunata conseguenza di questo comportamento è che non potete verificare la correttezza del file <filename role="special">.hgtags</filename> risultato dall'unione se non <emphasis>dopo</emphasis> aver effettuato il commit di un cambiamento. Quindi, se vi trovate a risolvere un conflitto su <filename role="special">.hgtags</filename> durante un'unione, assicuratevi di eseguire <command role="hg-cmd">hg tags</command> dopo aver effettuato il commit. Se il comando trova un errore nel file <filename role="special">.hgtags</filename>, vi indicherà la posizione dell'errore, che potrete dunque correggere registrando la correzione nel repository. Dovreste poi eseguire ancora <command role="hg-cmd">hg tags</command>, giusto per essere sicuri che la vostra correzione sia valida.</para> 14.79 + <title>Gestire i conflitti di etichette durante un’unione</title> 14.80 + 14.81 + <para id="x_37d">Avrete raramente bisogno di preoccuparvi del file <filename role="special">.hgtags</filename>, ma talvolta la sua presenza si farà sentire durante un’unione. Il formato del file è semplice: consiste di una serie di righe, ognuna delle quali comincia con un hash di changeset, seguito da uno spazio, seguito dal nome di un’etichetta.</para> 14.82 + 14.83 + <para id="x_37e">Se state risolvendo un conflitto nel file <filename role="special">.hgtags</filename> durante un’unione, c’è una particolarità da ricordare quando modificate il file <filename role="special">.hgtags</filename>: quando Mercurial sta analizzando le etichette in un repository, non legge <emphasis>mai</emphasis> la copia di lavoro del file <filename role="special">.hgtags</filename>, ma legge la revisione del file <emphasis>registrata più recentemente</emphasis>.</para> 14.84 + 14.85 + <para id="x_37f">Una sfortunata conseguenza di questo comportamento è che non potete verificare la correttezza del file <filename role="special">.hgtags</filename> risultato dall’unione se non <emphasis>dopo</emphasis> aver effettuato il commit di un cambiamento. Quindi, se vi trovate a risolvere un conflitto su <filename role="special">.hgtags</filename> durante un’unione, assicuratevi di eseguire <command role="hg-cmd">hg tags</command> dopo aver effettuato il commit. Se il comando trova un errore nel file <filename role="special">.hgtags</filename>, vi indicherà la posizione dell’errore, che potrete dunque correggere registrando la correzione nel repository. Dovreste poi eseguire ancora <command role="hg-cmd">hg tags</command>, giusto per essere sicuri che la vostra correzione sia valida.</para> 14.86 </sect2> 14.87 14.88 <sect2> 14.89 <title>Etichette e cloni</title> 14.90 14.91 - <para id="x_380">Potreste aver notato che il comando <command role="hg-cmd">hg clone</command> offre un'opzione <option role="hg-opt-clone">-r</option> per lasciarvi clonare la copia esatta di una particolare revisione di un repository. Il nuovo clone non conterrà alcuna cronologia del progetto registrata dopo la revisione che avete specificato. Questa operazione interagisce con le etichette in un modo che potrebbe sorprendere i più distratti.</para> 14.92 - 14.93 - <para id="x_381">Se ricordate, un'etichetta viene memorizzata come una revisione del file <filename role="special">.hgtags</filename>. Quando create un'etichetta, il changeset in cui viene registrata si riferisce a un changeset precedente. Quando eseguite <command role="hg-cmd">hg clone -r foo</command> per clonare un repository all'etichetta <literal>foo</literal>, il nuovo clone <emphasis>non conterrà alcuna revisione più recente di quella a cui si riferisce l'etichetta, compresa la revisione in cui l'etichetta è stata creata</emphasis>. Come risultato, otterrete esattamente il sottoinsieme corretto della cronologia del progetto nel nuovo repository, ma <emphasis>non</emphasis> l'etichetta che vi sareste potuti aspettare.</para> 14.94 + <para id="x_380">Potreste aver notato che il comando <command role="hg-cmd">hg clone</command> offre un’opzione <option role="hg-opt-clone">-r</option> per lasciarvi clonare la copia esatta di una particolare revisione di un repository. Il nuovo clone non conterrà alcuna cronologia del progetto registrata dopo la revisione che avete specificato. Questa operazione interagisce con le etichette in un modo che potrebbe sorprendere i più distratti.</para> 14.95 + 14.96 + <para id="x_381">Se ricordate, un’etichetta viene memorizzata come una revisione del file <filename role="special">.hgtags</filename>. Quando create un’etichetta, il changeset in cui viene registrata si riferisce a un changeset precedente. Quando eseguite <command role="hg-cmd">hg clone -r foo</command> per clonare un repository all’etichetta <literal>foo</literal>, il nuovo clone <emphasis>non conterrà alcuna revisione più recente di quella a cui si riferisce l’etichetta, compresa la revisione in cui l’etichetta è stata creata</emphasis>. Come risultato, otterrete esattamente il sottoinsieme corretto della cronologia del progetto nel nuovo repository, ma <emphasis>non</emphasis> l’etichetta che vi sareste potuti aspettare.</para> 14.97 </sect2> 14.98 14.99 <sect2> 14.100 <title>Quando le etichette permanenti sono eccessive</title> 14.101 14.102 - <para id="x_382">Dato che le etichette di Mercurial sono soggette a controllo di revisione e fanno parte della cronologia del progetto, chiunque lavori con voi vedrà le etichette che avete creato. Ma i nomi delle revisioni possono essere usati in modi che vanno oltre la semplice annotazione che la revisione <literal>4237e45506ee</literal> è in realtà la <literal>v2.0.2</literal>. Se state provando a rintracciare un bug intricato, poteste volere un'etichetta per ricordarvi di qualcosa come <quote>Anna ha visto gli effetti del bug in questa revisione</quote>.</para> 14.103 - 14.104 - <para id="x_383">In casi come questo, quello che potreste voler usare sono le etichette <emphasis>locali</emphasis>. Un'etichetta locale viene creata tramite l'opzione <option role="hg-opt-tag">-l</option> del comando <command role="hg-cmd">hg tag</command> e viene memorizzata in un file chiamato <filename role="special">.hg/localtags</filename>. Diversamente da <filename role="special">.hgtags</filename>, <filename 14.105 - role="special">.hg/localtags</filename> non è soggetto a controllo di revisione, quindi qualsiasi etichetta creiate usando l'opzione <option role="hg-opt-tag">-l</option> rimarrà strettamente locale al repository in cui state attualmente lavorando.</para> 14.106 + <para id="x_382">Dato che le etichette di Mercurial sono soggette a controllo di revisione e fanno parte della cronologia del progetto, chiunque lavori con voi vedrà le etichette che avete creato. Ma i nomi delle revisioni possono essere usati in modi che vanno oltre la semplice annotazione che la revisione <literal>4237e45506ee</literal> è in realtà la <literal>v2.0.2</literal>. Se state provando a rintracciare un bug intricato, poteste volere un’etichetta per ricordarvi di qualcosa come <quote>Anna ha visto gli effetti del bug in questa revisione</quote>.</para> 14.107 + 14.108 + <para id="x_383">In casi come questo, quello che potreste voler usare sono le etichette <emphasis>locali</emphasis>. Un’etichetta locale viene creata tramite l’opzione <option role="hg-opt-tag">-l</option> del comando <command role="hg-cmd">hg tag</command> e viene memorizzata in un file chiamato <filename role="special">.hg/localtags</filename>. Diversamente da <filename role="special">.hgtags</filename>, <filename 14.109 + role="special">.hg/localtags</filename> non è soggetto a controllo di revisione, quindi qualsiasi etichetta creiate usando l’opzione <option role="hg-opt-tag">-l</option> rimarrà strettamente locale al repository in cui state attualmente lavorando.</para> 14.110 </sect2> 14.111 </sect1> 14.112 14.113 <sect1> 14.114 - <title>Il flusso dei cambiamenti&emdash;la visione d'insieme e la visione di dettaglio</title> 14.115 - 14.116 - <para id="x_384">Per ritornare allo schema abbozzato all'inizio del capitolo, consideriamo un progetto che contiene molteplici attività di sviluppo parallele in lavorazione contemporaneamente.</para> 14.117 - 14.118 - <para id="x_385">Potrebbero esserci attività dedicate a una nuova release principale, a una nuova release <quote>minore</quote> che corregge alcuni bug trovati nell'ultima release principale e a un'inattesa <quote>correzione a caldo</quote> di una vecchia release che ora si trova in fase di manutenzione.</para> 14.119 + <title>Il flusso dei cambiamenti&emdash;la visione d’insieme e la visione di dettaglio</title> 14.120 + 14.121 + <para id="x_384">Per ritornare allo schema abbozzato all’inizio del capitolo, consideriamo un progetto che contiene molteplici attività di sviluppo parallele in lavorazione contemporaneamente.</para> 14.122 + 14.123 + <para id="x_385">Potrebbero esserci attività dedicate a una nuova release principale, a una nuova release <quote>minore</quote> che corregge alcuni bug trovati nell’ultima release principale e a un’inattesa <quote>correzione a caldo</quote> di una vecchia release che ora si trova in fase di manutenzione.</para> 14.124 14.125 <para id="x_386">Di solito, ognuna di queste direzioni di sviluppo parallele viene chiamata <quote>ramo</quote> (in inglese, branch). Tuttavia, abbiamo già visto più volte che Mercurial tratta <emphasis>tutta la cronologia</emphasis> come una serie di rami e unioni. In realtà, quello che abbiamo qui sono due idee marginalmente correlate che condividono casualmente lo stesso nome.</para> 14.126 <itemizedlist> 14.127 - <listitem><para id="x_387">Nella <quote>visione d'insieme</quote> i rami rappresentano il flusso dell'evoluzione di un progetto. Ognuno di questi rami ha il proprio nome ed è oggetto di conversazione tra gli sviluppatori.</para> 14.128 + <listitem><para id="x_387">Nella <quote>visione d’insieme</quote> i rami rappresentano il flusso dell’evoluzione di un progetto. Ognuno di questi rami ha il proprio nome ed è oggetto di conversazione tra gli sviluppatori.</para> 14.129 </listitem> 14.130 - <listitem><para id="x_388">Nella <quote>visione di dettaglio</quote> i rami sono artefatti costruiti durante l'attività quotidiana di sviluppo e unione dei cambiamenti. Questi rami narrano la storia di come il codice è stato sviluppato.</para> 14.131 + <listitem><para id="x_388">Nella <quote>visione di dettaglio</quote> i rami sono artefatti costruiti durante l’attività quotidiana di sviluppo e unione dei cambiamenti. Questi rami narrano la storia di come il codice è stato sviluppato.</para> 14.132 </listitem></itemizedlist> 14.133 </sect1> 14.134 14.135 <sect1> 14.136 - <title>Gestire i rami nella visione d'insieme</title> 14.137 - 14.138 - <para id="x_389">Nella <quote>visione d'insieme</quote>, il modo più facile per isolare un ramo in Mercurial è quello di utilizzare un repository dedicato. Se avete un repository condiviso esistente&emdash;chiamiamolo <literal>mioprogetto</literal>&emdash;che raggiunge una milestone <quote>1.0</quote>, potete cominciare a preparare le future release di manutenzione basate sulla versione 1.0 etichettando la revisione dalla quale avete preparato la release 1.0.</para> 14.139 + <title>Gestire i rami nella visione d’insieme</title> 14.140 + 14.141 + <para id="x_389">Nella <quote>visione d’insieme</quote>, il modo più facile per isolare un ramo in Mercurial è quello di utilizzare un repository dedicato. Se avete un repository condiviso esistente&emdash;chiamiamolo <literal>mioprogetto</literal>&emdash;che raggiunge una milestone <quote>1.0</quote>, potete cominciare a preparare le future release di manutenzione basate sulla versione 1.0 etichettando la revisione dalla quale avete preparato la release 1.0.</para> 14.142 14.143 &interaction.branch-repo.tag; 14.144 14.145 @@ -131,7 +131,7 @@ 14.146 <sect1> 14.147 <title>Non ripetetevi: le unioni tra rami</title> 14.148 14.149 - <para id="x_38d">In molti casi, se avete un bug da correggere su un ramo di manutenzione, è probabile che il bug sia presente anche sul ramo principale del progetto (e magari anche su altri rami di manutenzione). È raro che uno sviluppatore voglia correggere lo stesso bug più volte, quindi diamo un'occhiata ad alcuni modi in cui Mercurial può aiutarvi a gestire queste correzioni senza duplicare il vostro lavoro.</para> 14.150 + <para id="x_38d">In molti casi, se avete un bug da correggere su un ramo di manutenzione, è probabile che il bug sia presente anche sul ramo principale del progetto (e magari anche su altri rami di manutenzione). È raro che uno sviluppatore voglia correggere lo stesso bug più volte, quindi diamo un’occhiata ad alcuni modi in cui Mercurial può aiutarvi a gestire queste correzioni senza duplicare il vostro lavoro.</para> 14.151 14.152 <para id="x_38e">Nel caso più semplice, tutto quello che dovete fare è propagare i cambiamenti dal vostro ramo di manutenzione al vostro clone locale del ramo di destinazione.</para> 14.153 14.154 @@ -145,11 +145,11 @@ 14.155 <sect1> 14.156 <title>Denominare i rami in un repository</title> 14.157 14.158 - <para id="x_390">Nella maggior parte dei casi, isolare ogni ramo in un proprio repository è l'approccio giusto, perché la sua semplicità lo rende facile da capire e quindi è difficile commettere errori. Esiste una relazione uno-a-uno tra i rami in cui state lavorando e le directory sul vostro sistema che vi consente di usare strumenti ordinari (ignari dell'esistenza di Mercurial) per lavorare sui file all'interno di un ramo/repository.</para> 14.159 - 14.160 - <para id="x_391">Se invece appartenete alla categoria degli <quote>utenti avanzati</quote> (<emphasis>e</emphasis> vi appartengono anche i vostri collaboratori), potete considerare un modo alternativo di gestire i rami. Ho già menzionato la distinzione con cui gli sviluppatori percepiscono i rami nella <quote>visione di dettaglio</quote> e nella <quote>visione d'insieme</quote>. Se Mercurial lavora con molteplici rami <quote>di dettaglio</quote> alla volta in un repository (per esempio dopo che avete propagato i cambiamenti, ma prima di incorporarli), può <emphasis>anche</emphasis> lavorare con molteplici rami <quote>d'insieme</quote>.</para> 14.161 - 14.162 - <para id="x_392">La chiave per lavorare in questo modo è che Mercurial vi permette di assegnare un <emphasis>nome</emphasis> persistente a un ramo. In ogni repository c'è sempre un ramo chiamato <literal>default</literal>. Anche prima che cominciate a creare voi stessi nuovi rami con il proprio nome, potete trovare tracce del ramo <literal>default</literal> se le cercate.</para> 14.163 + <para id="x_390">Nella maggior parte dei casi, isolare ogni ramo in un proprio repository è l’approccio giusto, perché la sua semplicità lo rende facile da capire e quindi è difficile commettere errori. Esiste una relazione uno-a-uno tra i rami in cui state lavorando e le directory sul vostro sistema che vi consente di usare strumenti ordinari (ignari dell’esistenza di Mercurial) per lavorare sui file all’interno di un ramo/repository.</para> 14.164 + 14.165 + <para id="x_391">Se invece appartenete alla categoria degli <quote>utenti avanzati</quote> (<emphasis>e</emphasis> vi appartengono anche i vostri collaboratori), potete considerare un modo alternativo di gestire i rami. Ho già menzionato la distinzione con cui gli sviluppatori percepiscono i rami nella <quote>visione di dettaglio</quote> e nella <quote>visione d’insieme</quote>. Se Mercurial lavora con molteplici rami <quote>di dettaglio</quote> alla volta in un repository (per esempio dopo che avete propagato i cambiamenti, ma prima di incorporarli), può <emphasis>anche</emphasis> lavorare con molteplici rami <quote>d’insieme</quote>.</para> 14.166 + 14.167 + <para id="x_392">La chiave per lavorare in questo modo è che Mercurial vi permette di assegnare un <emphasis>nome</emphasis> persistente a un ramo. In ogni repository c’è sempre un ramo chiamato <literal>default</literal>. Anche prima che cominciate a creare voi stessi nuovi rami con il proprio nome, potete trovare tracce del ramo <literal>default</literal> se le cercate.</para> 14.168 14.169 <para id="x_393">Per esempio, quando eseguite il comando <command role="hg-cmd">hg commit</command> e vi viene presentato un editor in modo che possiate inserire un messaggio di commit, cercate una riga che contiene il testo <quote><literal>HG: ramo default</literal></quote> verso il fondo. Questo comando vi informa che il vostro commit avverrà sul ramo chiamato <literal>default</literal>.</para> 14.170 14.171 @@ -157,7 +157,7 @@ 14.172 14.173 &interaction.branch-named.branches; 14.174 14.175 - <para id="x_395">Dato che non avete ancora creato alcun ramo con nome, l'unico ramo esistente è <literal>default</literal>.</para> 14.176 + <para id="x_395">Dato che non avete ancora creato alcun ramo con nome, l’unico ramo esistente è <literal>default</literal>.</para> 14.177 14.178 <para id="x_396">Per trovare qual è il ramo <quote>attuale</quote>, eseguite il comando <command role="hg-cmd">hg branch</command> senza passargli alcun argomento. Otterrete il nome del ramo in cui trova il genitore del changeset corrente.</para> 14.179 14.180 @@ -167,7 +167,7 @@ 14.181 14.182 &interaction.branch-named.create; 14.183 14.184 - <para id="x_398">Dopo che avete creato un ramo, potreste chiedervi qual è stato l'effetto del comando <command role="hg-cmd">hg branch</command>. Che cosa ci dicono i comandi <command role="hg-cmd">hg status</command> e <command role="hg-cmd">hg tip</command>?</para> 14.185 + <para id="x_398">Dopo che avete creato un ramo, potreste chiedervi qual è stato l’effetto del comando <command role="hg-cmd">hg branch</command>. Che cosa ci dicono i comandi <command role="hg-cmd">hg status</command> e <command role="hg-cmd">hg tip</command>?</para> 14.186 14.187 &interaction.branch-named.status; 14.188 14.189 @@ -183,13 +183,13 @@ 14.190 14.191 &interaction.branch-named.rebranch; 14.192 14.193 - <para id="x_39d">In pratica, questa non è una cosa che farete molto spesso, dato che i nomi di ramo tendono ad avere un tempo di vita piuttosto lungo. (Questa non è una regola, ma solo un'osservazione.)</para> 14.194 + <para id="x_39d">In pratica, questa non è una cosa che farete molto spesso, dato che i nomi di ramo tendono ad avere un tempo di vita piuttosto lungo. (Questa non è una regola, ma solo un’osservazione.)</para> 14.195 </sect1> 14.196 14.197 <sect1> 14.198 <title>Gestire molti rami con nome in un repository</title> 14.199 14.200 - <para id="x_39e">Se un repository contiene più di un ramo con nome, Mercurial ricorderà il ramo su cui si trova la vostra directory di lavoro quando eseguite un comando come <command role="hg-cmd">hg update</command> o <command role="hg-cmd">hg pull -u</command> e aggiornerà la directory di lavoro alla revisione di punta di quel ramo, a prescindere da quale sia la punta dell'intero repository. Per aggiornare la directory di lavoro a una revisione che si trova su un ramo con un nome diverso, potreste dover usare l'opzione <option role="hg-opt-update">-C</option> del comando <command role="hg-cmd">hg update</command>.</para> 14.201 + <para id="x_39e">Se un repository contiene più di un ramo con nome, Mercurial ricorderà il ramo su cui si trova la vostra directory di lavoro quando eseguite un comando come <command role="hg-cmd">hg update</command> o <command role="hg-cmd">hg pull -u</command> e aggiornerà la directory di lavoro alla revisione di punta di quel ramo, a prescindere da quale sia la punta dell’intero repository. Per aggiornare la directory di lavoro a una revisione che si trova su un ramo con un nome diverso, potreste dover usare l’opzione <option role="hg-opt-update">-C</option> del comando <command role="hg-cmd">hg update</command>.</para> 14.202 14.203 <para id="x_39f">Questo comportamento è leggermente complicato, quindi vediamolo in azione. Per prima cosa, controlliamo su quale ramo ci troviamo al momento e quali sono i rami contenuti nel nostro repository.</para> 14.204 14.205 @@ -197,7 +197,7 @@ 14.206 14.207 <para id="x_3a0">Ci troviamo sul ramo <literal>bar</literal>, ma esiste anche un ramo più vecchio chiamato <literal>foo</literal>.</para> 14.208 14.209 - <para id="x_3a1">Possiamo utilizzare <command role="hg-cmd">hg update</command> per spostarci avanti e indietro tra le revisioni di punta dei rami <literal>foo</literal> e <literal>bar</literal> senza aver bisogno di impiegare l'opzione <option role="hg-opt-update">-C</option>, perché questi spostamenti avvengono linearmente attraverso la nostra cronologia dei cambiamenti.</para> 14.210 + <para id="x_3a1">Possiamo utilizzare <command role="hg-cmd">hg update</command> per spostarci avanti e indietro tra le revisioni di punta dei rami <literal>foo</literal> e <literal>bar</literal> senza aver bisogno di impiegare l’opzione <option role="hg-opt-update">-C</option>, perché questi spostamenti avvengono linearmente attraverso la nostra cronologia dei cambiamenti.</para> 14.211 14.212 &interaction.branch-named.update-switchy; 14.213 14.214 @@ -213,11 +213,11 @@ 14.215 <sect1> 14.216 <title>I nomi di ramo e le unioni</title> 14.217 14.218 - <para id="x_3a4">Come avete probabilmente notato, le unioni in Mercurial non sono simmetriche. Diciamo che il nostro repository possiede due teste, 17 e 23. Se uso <command role="hg-cmd">hg update</command> per aggiornare alla 17 e poi eseguo <command role="hg-cmd">hg merge</command> per incorporare la 23, Mercurial registra la 17 come primo genitore dell'unione e la 23 come secondo. Ma se uso <command role="hg-cmd">hg update</command> per aggiornare alla 23 e poi eseguo <command role="hg-cmd">hg merge</command> per incorporare la 17, Mercurial registra la 23 come primo genitore e la 17 come secondo.</para> 14.219 - 14.220 - <para id="x_3a5">Questo comportamento influenza la scelta del nome di ramo compiuta da Mercurial quando effettuate un'unione. Dopo un'unione, Mercurial manterrà il nome del ramo del primo genitore quando registrate i risultati dell'unione. Se il nome del ramo del primo genitore è <literal>foo</literal> e unite quel ramo con <literal>bar</literal>, dopo l'unione il nome del ramo in cui vi troverete sarà ancora <literal>foo</literal>.</para> 14.221 - 14.222 - <para id="x_3a6">Capita spesso che un repository contenga più teste, ognuna con lo stesso nome di ramo. Diciamo che io sto lavorando sul ramo <literal>foo</literal> e così fate anche voi. Eseguiamo il commit di cambiamenti differenti, dopodiché io estraggo i vostri cambiamenti e mi ritrovo con due teste, ognuna che dichiara di appartenere al ramo <literal>foo</literal>. Sperabilmente, il risultato di un'unione sarà una singola testa sul ramo <literal>foo</literal>.</para> 14.223 + <para id="x_3a4">Come avete probabilmente notato, le unioni in Mercurial non sono simmetriche. Diciamo che il nostro repository possiede due teste, 17 e 23. Se uso <command role="hg-cmd">hg update</command> per aggiornare alla 17 e poi eseguo <command role="hg-cmd">hg merge</command> per incorporare la 23, Mercurial registra la 17 come primo genitore dell’unione e la 23 come secondo. Ma se uso <command role="hg-cmd">hg update</command> per aggiornare alla 23 e poi eseguo <command role="hg-cmd">hg merge</command> per incorporare la 17, Mercurial registra la 23 come primo genitore e la 17 come secondo.</para> 14.224 + 14.225 + <para id="x_3a5">Questo comportamento influenza la scelta del nome di ramo compiuta da Mercurial quando effettuate un’unione. Dopo un’unione, Mercurial manterrà il nome del ramo del primo genitore quando registrate i risultati dell’unione. Se il nome del ramo del primo genitore è <literal>foo</literal> e unite quel ramo con <literal>bar</literal>, dopo l’unione il nome del ramo in cui vi troverete sarà ancora <literal>foo</literal>.</para> 14.226 + 14.227 + <para id="x_3a6">Capita spesso che un repository contenga più teste, ognuna con lo stesso nome di ramo. Diciamo che io sto lavorando sul ramo <literal>foo</literal> e così fate anche voi. Eseguiamo il commit di cambiamenti differenti, dopodiché io estraggo i vostri cambiamenti e mi ritrovo con due teste, ognuna che dichiara di appartenere al ramo <literal>foo</literal>. Sperabilmente, il risultato di un’unione sarà una singola testa sul ramo <literal>foo</literal>.</para> 14.228 14.229 <para id="x_3a7">Ma se io sto lavorando sul ramo <literal>bar</literal> e incorporo il lavoro dal ramo <literal>foo</literal>, il risultato rimarrà sul ramo <literal>bar</literal>.</para> 14.230 14.231 @@ -231,9 +231,9 @@ 14.232 14.233 <para id="x_3a9">Non dovreste pensare che i rami con nome si possano utilizzare solo in situazioni dove avete molteplici rami di lunga data che coabitano in un singolo repository. Sono molto utili anche nel caso in cui utilizziate un singolo ramo per repository.</para> 14.234 14.235 - <para id="x_3aa">Nel caso più semplice, dare un nome a ogni ramo vi offre una registrazione permanente dell'identità del ramo da cui un changeset ha avuto origine. Questo vi fornisce un contesto più ampio quando state cercando di seguire la cronologia di un progetto ramificato di lunga data.</para> 14.236 - 14.237 - <para id="x_3ab">Se state lavorando con repository condivisi, potete impostare un hook <literal role="hook">pretxnchangegroup</literal> su ogni repository in modo da bloccare i cambiamenti in entrata che appartengono al nome di ramo <quote>sbagliato</quote>. Questo accorgimento vi offre una difesa semplice ma efficace nei confronti di chi trasmette accidentalmente i cambiamenti da un ramo <quote>sperimentale</quote> a un ramo <quote>stabile</quote>. Un hook di questo tipo potrebbe somigliare al seguente, contenuto all'interno del file <filename role="special">/.hgrc</filename> del repository condiviso.</para> 14.238 + <para id="x_3aa">Nel caso più semplice, dare un nome a ogni ramo vi offre una registrazione permanente dell’identità del ramo da cui un changeset ha avuto origine. Questo vi fornisce un contesto più ampio quando state cercando di seguire la cronologia di un progetto ramificato di lunga data.</para> 14.239 + 14.240 + <para id="x_3ab">Se state lavorando con repository condivisi, potete impostare un hook <literal role="hook">pretxnchangegroup</literal> su ogni repository in modo da bloccare i cambiamenti in entrata che appartengono al nome di ramo <quote>sbagliato</quote>. Questo accorgimento vi offre una difesa semplice ma efficace nei confronti di chi trasmette accidentalmente i cambiamenti da un ramo <quote>sperimentale</quote> a un ramo <quote>stabile</quote>. Un hook di questo tipo potrebbe somigliare al seguente, contenuto all’interno del file <filename role="special">/.hgrc</filename> del repository condiviso.</para> 14.241 <programlisting>[hooks] 14.242 pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mioramo</programlisting> 14.243 </sect1>
15.1 --- a/it/ch09-undo.xml Sat Aug 22 21:01:56 2009 +0200 15.2 +++ b/it/ch09-undo.xml Sat Aug 22 21:55:05 2009 +0200 15.3 @@ -8,9 +8,9 @@ 15.4 <title>Cancellare la cronologia locale</title> 15.5 15.6 <sect2> 15.7 - <title>L'inserimento accidentale</title> 15.8 - 15.9 - <para id="x_d3">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 <command role="hg-cmd">hg add</command> per aggiungerlo al repository. Un changeset <quote>completamente sbagliato</quote> non è così comune, ma non è meno fastidioso.</para> 15.10 + <title>L’inserimento accidentale</title> 15.11 + 15.12 + <para id="x_d3">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 <command role="hg-cmd">hg add</command> per aggiungerlo al repository. Un changeset <quote>completamente sbagliato</quote> non è così comune, ma non è meno fastidioso.</para> 15.13 15.14 </sect2> 15.15 <sect2 id="sec:undo:rollback"> 15.16 @@ -22,29 +22,29 @@ 15.17 15.18 &interaction.rollback.commit; 15.19 15.20 - <para id="x_d6">Un'occhiata al risultato di <command role="hg-cmd">hg status</command> dopo l'inserimento conferma immediatamente l'errore.</para> 15.21 + <para id="x_d6">Un’occhiata al risultato di <command role="hg-cmd">hg status</command> dopo l’inserimento conferma immediatamente l’errore.</para> 15.22 15.23 &interaction.rollback.status; 15.24 15.25 <para id="x_d7">Il commit ha catturato le modifiche al file <filename>a</filename>, ma non il nuovo file <filename>b</filename>. È molto probabile che qualcosa in <filename>a</filename> si riferisca a <filename>b</filename>, ma se trasmettessi questo changeset a un repository condiviso, i collaboratori che estrarranno i miei cambiamenti non troverebbero <filename>b</filename> nei loro repository. Di conseguenza, diventerei oggetto di una certa indignazione.</para> 15.26 15.27 - <para id="x_d8">Tuttavia, la fortuna è dalla mia parte&emdash;mi sono accorto dell'errore prima di trasmettere il changeset. Ora uso il comando <command role="hg-cmd">hg rollback</command> e Mercurial farà sparire quell'ultimo changeset.</para> 15.28 + <para id="x_d8">Tuttavia, la fortuna è dalla mia parte&emdash;mi sono accorto dell’errore prima di trasmettere il changeset. Ora uso il comando <command role="hg-cmd">hg rollback</command> e Mercurial farà sparire quell’ultimo changeset.</para> 15.29 15.30 &interaction.rollback.rollback; 15.31 15.32 - <para id="x_d9">Notate che il changeset non è più presente nella cronologia del repository e che la directory di lavoro pensa ancora che il file <filename>a</filename> 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 <command role="hg-cmd">hg add</command> per aggiungere il file <filename>b</filename> e rieseguire il commit.</para> 15.33 + <para id="x_d9">Notate che il changeset non è più presente nella cronologia del repository e che la directory di lavoro pensa ancora che il file <filename>a</filename> 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 <command role="hg-cmd">hg add</command> per aggiungere il file <filename>b</filename> e rieseguire il commit.</para> 15.34 15.35 &interaction.rollback.add; 15.36 15.37 </sect2> 15.38 <sect2> 15.39 - <title>L'estrazione sbagliata</title> 15.40 + <title>L’estrazione sbagliata</title> 15.41 15.42 <para id="x_da">È 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 <quote>0.9</quote> del vostro progetto e un altro, contenente cambiamenti differenti, per la release <quote>1.0</quote>.</para> 15.43 15.44 - <para id="x_db">In questa situazione, potete immaginare che pasticcio accadrebbe se aveste un repository <quote>0.9</quote> locale e vi propagaste accidentalmente i cambiamenti dal repository <quote>1.0</quote> condiviso. Nel caso peggiore, potreste non fare abbastanza attenzione e trasmettere quei cambiamenti nell'albero <quote>0.9</quote> condiviso, disorientando tutti gli altri sviluppatori (ma non preoccupatevi, ritorneremo a questo orribile scenario più avanti). Tuttavia, è più probabile che notiate immediatamente l'errore, perché Mercurial vi mostrerà l'URL da cui sta estraendo i cambiamenti, o perché vedrete Mercurial propagare un numero sospettosamente alto di cambiamenti nel repository.</para> 15.45 - 15.46 - <para id="x_dc">Il comando <command role="hg-cmd">hg rollback</command> cancellerà scrupolosamente tutti i changeset che avete appena estratto. Mercurial raggruppa tutti i cambiamenti provenienti da un'invocazione di <command role="hg-cmd">hg pull</command> in una singola transazione, quindi un'unica invocazione di <command role="hg-cmd">hg rollback</command> è tutto quello che vi serve per annullare questo errore.</para> 15.47 + <para id="x_db">In questa situazione, potete immaginare che pasticcio accadrebbe se aveste un repository <quote>0.9</quote> locale e vi propagaste accidentalmente i cambiamenti dal repository <quote>1.0</quote> condiviso. Nel caso peggiore, potreste non fare abbastanza attenzione e trasmettere quei cambiamenti nell’albero <quote>0.9</quote> condiviso, disorientando tutti gli altri sviluppatori (ma non preoccupatevi, ritorneremo a questo orribile scenario più avanti). Tuttavia, è più probabile che notiate immediatamente l’errore, perché Mercurial vi mostrerà l’URL da cui sta estraendo i cambiamenti, o perché vedrete Mercurial propagare un numero sospettosamente alto di cambiamenti nel repository.</para> 15.48 + 15.49 + <para id="x_dc">Il comando <command role="hg-cmd">hg rollback</command> cancellerà scrupolosamente tutti i changeset che avete appena estratto. Mercurial raggruppa tutti i cambiamenti provenienti da un’invocazione di <command role="hg-cmd">hg pull</command> in una singola transazione, quindi un’unica invocazione di <command role="hg-cmd">hg rollback</command> è tutto quello che vi serve per annullare questo errore.</para> 15.50 15.51 </sect2> 15.52 <sect2 id="sec:undo:rollback-after-push"> 15.53 @@ -52,7 +52,7 @@ 15.54 15.55 <para id="x_dd">Il valore di <command role="hg-cmd">hg rollback</command> scende a zero una volta che avete trasmesso le vostre modifiche a un altro repository. Abortire un cambiamento lo fa scomparire interamente, ma <emphasis>solo</emphasis> nel repository in cui invocate <command role="hg-cmd">hg rollback</command>. Dato che una cancellazione elimina parte della cronologia, non è possibile che la scomparsa di un cambiamento si propaghi tra i repository.</para> 15.56 15.57 - <para id="x_de">Se avete trasmesso un cambiamento a un altro repository&emdash;in particolare se è un repository condiviso&emdash;le modifiche sono essenzialmente <quote>scappate dal recinto</quote> 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.</para> 15.58 + <para id="x_de">Se avete trasmesso un cambiamento a un altro repository&emdash;in particolare se è un repository condiviso&emdash;le modifiche sono essenzialmente <quote>scappate dal recinto</quote> 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.</para> 15.59 15.60 <para id="x_df">Se siete assolutamente sicuri che il cambiamento che volete abortire è quello più recente contenuto nel repository a cui lo avete trasmesso <emphasis>e</emphasis> 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.</para> 15.61 15.62 @@ -64,7 +64,7 @@ 15.63 15.64 &interaction.rollback.twice; 15.65 15.66 - <para id="x_e1">Una volta che avete abortito una transazione in un repository, non potete effettuare un'altra volta questa operazione in quel repository fino a quando non avete eseguito un nuovo inserimento o una nuova estrazione.</para> 15.67 + <para id="x_e1">Una volta che avete abortito una transazione in un repository, non potete effettuare un’altra volta questa operazione in quel repository fino a quando non avete eseguito un nuovo inserimento o una nuova estrazione.</para> 15.68 15.69 </sect2> 15.70 </sect1> 15.71 @@ -81,7 +81,7 @@ 15.72 15.73 &interaction.daily.revert.unmodify; 15.74 15.75 - <para id="x_e5">Il comando <command role="hg-cmd">hg revert</command> ci fornisce un ulteriore grado di protezione salvando il nostro file modificato con un'estensione <filename>.orig</filename>.</para> 15.76 + <para id="x_e5">Il comando <command role="hg-cmd">hg revert</command> ci fornisce un ulteriore grado di protezione salvando il nostro file modificato con un’estensione <filename>.orig</filename>.</para> 15.77 15.78 &interaction.daily.revert.status; 15.79 15.80 @@ -107,7 +107,7 @@ 15.81 15.82 <para id="x_eb">Il comando <command role="hg-cmd">hg revert</command> non è utile solo per i file modificati, ma vi permette di invertire i risultati di tutti i comandi Mercurial di gestione dei file come <command role="hg-cmd">hg add</command>, <command role="hg-cmd">hg remove</command>, e così via.</para> 15.83 15.84 - <para id="x_ec">Se usate <command role="hg-cmd">hg add</command> su un file, poi decidete che in effetti non volete che Mercurial ne tenga traccia, potete usare <command role="hg-cmd">hg revert</command> per annullare l'operazione di aggiunta. Non preoccupatevi, Mercurial non modificherà il file in alcun modo, ma si limiterà a eliminare il <quote>contrassegno</quote> per quel file.</para> 15.85 + <para id="x_ec">Se usate <command role="hg-cmd">hg add</command> su un file, poi decidete che in effetti non volete che Mercurial ne tenga traccia, potete usare <command role="hg-cmd">hg revert</command> per annullare l’operazione di aggiunta. Non preoccupatevi, Mercurial non modificherà il file in alcun modo, ma si limiterà a eliminare il <quote>contrassegno</quote> per quel file.</para> 15.86 15.87 &interaction.daily.revert.add; 15.88 15.89 @@ -119,7 +119,7 @@ 15.90 15.91 &interaction.daily.revert.missing; 15.92 15.93 - <para id="x_ee">Se invertite l'azione del comando <command role="hg-cmd">hg copy</command>, il file copiato rimane nella vostra directory di lavoro senza che Mercurial ne tenga traccia. Dato che l'operazione di copia non ha effetti sul file originale, Mercurial non agisce in alcun modo su quel file.</para> 15.94 + <para id="x_ee">Se invertite l’azione del comando <command role="hg-cmd">hg copy</command>, il file copiato rimane nella vostra directory di lavoro senza che Mercurial ne tenga traccia. Dato che l’operazione di copia non ha effetti sul file originale, Mercurial non agisce in alcun modo su quel file.</para> 15.95 15.96 &interaction.daily.revert.copy; 15.97 </sect2> 15.98 @@ -130,28 +130,28 @@ 15.99 15.100 <para id="x_f5">Considerate il caso in cui avete inserito un cambiamento <emphasis>a</emphasis> e subito dopo un altro cambiamento <emphasis>b</emphasis> basato sul precedente, poi realizzate che il cambiamento <emphasis>a</emphasis> era sbagliato. Mercurial vi consente di <quote>ritirare</quote> sia un intero changeset automaticamente, sia certi <quote>mattoni da costruzione</quote> che vi permettono di invertire a mano parte di un changeset.</para> 15.101 15.102 - <para id="x_f6">Prima di leggere questa sezione, c'è una cosa che dovete tenere a mente: il comando <command role="hg-cmd">hg backout</command> annulla gli effetti di un cambiamento effettuando un'<emphasis>aggiunta</emphasis> 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 <xref linkend="sec:undo:aaaiiieee"/>.</para> 15.103 + <para id="x_f6">Prima di leggere questa sezione, c’è una cosa che dovete tenere a mente: il comando <command role="hg-cmd">hg backout</command> annulla gli effetti di un cambiamento effettuando un’<emphasis>aggiunta</emphasis> 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 <xref linkend="sec:undo:aaaiiieee"/>.</para> 15.104 15.105 <sect2> 15.106 <title>Ritirare un changeset</title> 15.107 15.108 - <para id="x_f7">Il comando <command role="hg-cmd">hg backout</command> vi consente di <quote>annullare</quote> gli effetti di un intero changeset in modo automatico. Dato che la cronologia di Mercurial è immutabile, questo comando <emphasis>non</emphasis> si sbarazza del changeset che volete annullare, ma crea un nuovo changeset che <emphasis>inverte</emphasis> l'effetto del changeset da annullare.</para> 15.109 - 15.110 - <para id="x_f8">Le operazioni del comando <command role="hg-cmd">hg backout</command> sono un po' intricate, quindi le illustreremo con alcuni esempi. Per prima cosa, creiamo un repository con alcuni semplici cambiamenti.</para> 15.111 + <para id="x_f7">Il comando <command role="hg-cmd">hg backout</command> vi consente di <quote>annullare</quote> gli effetti di un intero changeset in modo automatico. Dato che la cronologia di Mercurial è immutabile, questo comando <emphasis>non</emphasis> si sbarazza del changeset che volete annullare, ma crea un nuovo changeset che <emphasis>inverte</emphasis> l’effetto del changeset da annullare.</para> 15.112 + 15.113 + <para id="x_f8">Le operazioni del comando <command role="hg-cmd">hg backout</command> sono un po’ intricate, quindi le illustreremo con alcuni esempi. Per prima cosa, creiamo un repository con alcuni semplici cambiamenti.</para> 15.114 15.115 &interaction.backout.init; 15.116 15.117 - <para id="x_f9">Il comando <command role="hg-cmd">hg backout</command> prende come argomento un singolo identificatore di changeset che indica il changeset da annullare. Normalmente, <command role="hg-cmd">hg backout</command> 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 role="hg-opt-backout">-m</option>.</para> 15.118 + <para id="x_f9">Il comando <command role="hg-cmd">hg backout</command> prende come argomento un singolo identificatore di changeset che indica il changeset da annullare. Normalmente, <command role="hg-cmd">hg backout</command> 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 role="hg-opt-backout">-m</option>.</para> 15.119 15.120 </sect2> 15.121 <sect2> 15.122 <title>Ritirare il changeset di punta </title> 15.123 15.124 - <para id="x_fa">Cominceremo ritirando l'ultimo changeset che abbiamo inserito.</para> 15.125 + <para id="x_fa">Cominceremo ritirando l’ultimo changeset che abbiamo inserito.</para> 15.126 15.127 &interaction.backout.simple; 15.128 15.129 - <para id="x_fb">Potete vedere che la seconda riga di <filename>miofile</filename> non è più presente. Un'occhiata all'elenco generato da <command role="hg-cmd">hg log</command> ci dà un'idea di quello che il comando <command role="hg-cmd">hg backout</command> ha fatto.</para> 15.130 + <para id="x_fb">Potete vedere che la seconda riga di <filename>miofile</filename> non è più presente. Un’occhiata all’elenco generato da <command role="hg-cmd">hg log</command> ci dà un’idea di quello che il comando <command role="hg-cmd">hg backout</command> ha fatto.</para> 15.131 15.132 &interaction.backout.simple.log; 15.133 15.134 @@ -169,7 +169,7 @@ 15.135 <sect2> 15.136 <title>Ritirare un changeset diverso dalla punta</title> 15.137 15.138 - <para id="x_fd">Se volete ritirare un cambiamento diverso dall'ultimo che avete inserito, passate l'opzione <option role="hg-opt-backout">--merge</option> al comando <command role="hg-cmd">hg backout</command>.</para> 15.139 + <para id="x_fd">Se volete ritirare un cambiamento diverso dall’ultimo che avete inserito, passate l’opzione <option role="hg-opt-backout">--merge</option> al comando <command role="hg-cmd">hg backout</command>.</para> 15.140 15.141 &interaction.backout.non-tip.clone; 15.142 15.143 @@ -177,11 +177,11 @@ 15.144 15.145 &interaction.backout.non-tip.backout; 15.146 15.147 - <para id="x_ff">Se date un'occhiata al contenuto di <filename>miofile</filename> dopo che l'operazione di ritiro si è conclusa, vedrete che il primo e il terzo cambiamento sono presenti, ma non il secondo.</para> 15.148 + <para id="x_ff">Se date un’occhiata al contenuto di <filename>miofile</filename> dopo che l’operazione di ritiro si è conclusa, vedrete che il primo e il terzo cambiamento sono presenti, ma non il secondo.</para> 15.149 15.150 &interaction.backout.non-tip.cat; 15.151 15.152 - <para id="x_100">Come illustrato nella rappresentazione grafica della cronologia nella <xref linkend="fig:undo:backout-non-tip"/>, 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 <emphasis>non esegue il commit</emphasis> dei risultati dell'unione. Il repository ora contiene due teste e la directory di lavoro contiene i risultati di un'unione.</para> 15.153 + <para id="x_100">Come illustrato nella rappresentazione grafica della cronologia nella <xref linkend="fig:undo:backout-non-tip"/>, 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 <emphasis>non esegue il commit</emphasis> dei risultati dell’unione. Il repository ora contiene due teste e la directory di lavoro contiene i risultati di un’unione.</para> 15.154 15.155 <figure id="fig:undo:backout-non-tip"> 15.156 <title>Ritiro automatico di un changeset diverso dalla punta tramite il comando <command role="hg-cmd">hg backout</command></title> 15.157 @@ -193,19 +193,19 @@ 15.158 15.159 <para id="x_103">Il risultato è che siete tornati <quote>indietro a dove eravate</quote>, ma con una parte aggiuntiva di cronologia che annulla gli effetti del changeset che volevate ritirare.</para> 15.160 15.161 - <para id="x_6b9">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 <emphasis>poi</emphasis> li inserite nel repository.</para> 15.162 + <para id="x_6b9">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 <emphasis>poi</emphasis> li inserite nel repository.</para> 15.163 15.164 <sect3> 15.165 - <title>Usate sempre l'opzione <option role="hg-opt-backout">--merge</option></title> 15.166 - 15.167 - <para id="x_104">In effetti, dato che l'opzione <option role="hg-opt-backout">--merge</option> farà la <quote>cosa giusta</quote> a prescindere dal fatto che il changeset sia quello di punta o meno (cioè non cercherà di eseguire un'unione se state ritirando la punta, dato che non ce n'è bisogno), dovreste usare <emphasis>sempre</emphasis> questa opzione quando invocate il comando <command role="hg-cmd">hg backout</command>.</para> 15.168 + <title>Usate sempre l’opzione <option role="hg-opt-backout">--merge</option></title> 15.169 + 15.170 + <para id="x_104">In effetti, dato che l’opzione <option role="hg-opt-backout">--merge</option> farà la <quote>cosa giusta</quote> a prescindere dal fatto che il changeset sia quello di punta o meno (cioè non cercherà di eseguire un’unione se state ritirando la punta, dato che non ce n’è bisogno), dovreste usare <emphasis>sempre</emphasis> questa opzione quando invocate il comando <command role="hg-cmd">hg backout</command>.</para> 15.171 15.172 </sect3> 15.173 </sect2> 15.174 <sect2> 15.175 <title>Controllare meglio il processo di ritiro</title> 15.176 15.177 - <para id="x_105">Sebbene vi abbia raccomandato di usare sempre l'opzione <option role="hg-opt-backout">--merge</option> quando ritirate un cambiamento, il comando <command role="hg-cmd">hg backout</command> 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 <command role="hg-cmd">hg backout</command> fa per voi automaticamente. Per illustrare queste operazioni, cloniamo il nostro primo repository, ma omettiamo il cambiamento ritirato che contiene.</para> 15.178 + <para id="x_105">Sebbene vi abbia raccomandato di usare sempre l’opzione <option role="hg-opt-backout">--merge</option> quando ritirate un cambiamento, il comando <command role="hg-cmd">hg backout</command> 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 <command role="hg-cmd">hg backout</command> fa per voi automaticamente. Per illustrare queste operazioni, cloniamo il nostro primo repository, ma omettiamo il cambiamento ritirato che contiene.</para> 15.179 15.180 &interaction.backout.manual.clone; 15.181 15.182 @@ -265,24 +265,24 @@ 15.183 15.184 <para id="x_110">Ecco una breve descrizione del funzionamento del comando <command role="hg-cmd">hg backout</command>.</para> 15.185 <orderedlist> 15.186 - <listitem><para id="x_111">Si assicura che la directory di lavoro sia <quote>pulita</quote>, cioè che l'elenco generato da <command role="hg-cmd">hg status</command> sia vuoto.</para> 15.187 + <listitem><para id="x_111">Si assicura che la directory di lavoro sia <quote>pulita</quote>, cioè che l’elenco generato da <command role="hg-cmd">hg status</command> sia vuoto.</para> 15.188 </listitem> 15.189 <listitem><para id="x_112">Memorizza il genitore corrente della directory di lavoro. Chiamiamo <literal>orig</literal> questo changeset.</para> 15.190 </listitem> 15.191 - <listitem><para id="x_113">Esegue l'equivalente di un'invocazione di <command role="hg-cmd">hg update</command> per sincronizzare la directory di lavoro con il changeset che volete ritirare. Chiamiamo <literal>backout</literal> questo changeset.</para> 15.192 + <listitem><para id="x_113">Esegue l’equivalente di un’invocazione di <command role="hg-cmd">hg update</command> per sincronizzare la directory di lavoro con il changeset che volete ritirare. Chiamiamo <literal>backout</literal> questo changeset.</para> 15.193 </listitem> 15.194 <listitem><para id="x_114">Trova il genitore di quel changeset. Chiamiamo <literal>parent</literal> questo changeset.</para> 15.195 </listitem> 15.196 - <listitem><para id="x_115">Per ogni file su cui il changeset <literal>backout</literal> ha avuto effetto, esegue l'equivalente del comando <command role="hg-cmd">hg revert -r parent</command> sul file per ripristinare il contenuto che aveva prima che quel changeset venisse inserito.</para> 15.197 + <listitem><para id="x_115">Per ogni file su cui il changeset <literal>backout</literal> ha avuto effetto, esegue l’equivalente del comando <command role="hg-cmd">hg revert -r parent</command> sul file per ripristinare il contenuto che aveva prima che quel changeset venisse inserito.</para> 15.198 </listitem> 15.199 <listitem><para id="x_116">Esegue il commit del risultato come un nuovo changeset che ha <literal>backout</literal> come genitore.</para> 15.200 </listitem> 15.201 - <listitem><para id="x_117">Se specificate l'opzione <option role="hg-opt-backout">--merge</option> sulla riga di comando, esegue un'unione con <literal>orig</literal> ma non inserisce i risultati dell'unione nel repository.</para> 15.202 + <listitem><para id="x_117">Se specificate l’opzione <option role="hg-opt-backout">--merge</option> sulla riga di comando, esegue un’unione con <literal>orig</literal> ma non inserisce i risultati dell’unione nel repository.</para> 15.203 </listitem></orderedlist> 15.204 15.205 - <para id="x_118">In alternativa, sarebbe possibile implementare <command role="hg-cmd">hg backout</command> utilizzando <command role="hg-cmd">hg export</command> per esportare il changeset da ritirare sotto forma di diff e poi impiegando l'opzione <option role="cmd-opt-patch">--reverse</option> del comando <command>patch</command> 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.</para> 15.206 - 15.207 - <para id="x_119">Il comando <command role="hg-cmd">hg backout</command> 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 <emphasis>tra</emphasis> il cambiamento che state ritirando e la revisione di punta corrente.</para> 15.208 + <para id="x_118">In alternativa, sarebbe possibile implementare <command role="hg-cmd">hg backout</command> utilizzando <command role="hg-cmd">hg export</command> per esportare il changeset da ritirare sotto forma di diff e poi impiegando l’opzione <option role="cmd-opt-patch">--reverse</option> del comando <command>patch</command> 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.</para> 15.209 + 15.210 + <para id="x_119">Il comando <command role="hg-cmd">hg backout</command> 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 <emphasis>tra</emphasis> il cambiamento che state ritirando e la revisione di punta corrente.</para> 15.211 15.212 <para id="x_11a">Se state ritirando un cambiamento che si trova 100 revisioni indietro nella cronologia del vostro progetto, le probabilità che il comando <command>patch</command> sia in grado di applicare un diff invertito in maniera pulita non sono molto alte, perché i cambiamenti intercorsi avranno probabilmente <quote>rovinato il contesto</quote> utilizzato da <command>patch</command> per determinare se può applicare una patch (se questo vi sembra incomprensibile, leggete la <xref linkend="sec:mq:patch"/> per una discussione sul comando <command>patch</command>). 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 <command>patch</command> non è in grado di farlo.</para> 15.213 15.214 @@ -297,38 +297,38 @@ 15.215 15.216 <para id="x_11d">Prima di illustrare le opzioni a vostra disposizione se eseguite il commit di un cambiamento <quote>da sacchetto di carta marrone</quote> (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.</para> 15.217 15.218 - <para id="x_11e">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 <command role="hg-cmd">hg rollback</command>, come descritto nella <xref linkend="sec:undo:rollback"/>.</para> 15.219 - 15.220 - <para id="x_11f">Dopo che avete trasmesso un cambiamento sbagliato a un altro repository, <emphasis>potreste</emphasis> ancora usare <command role="hg-cmd">hg rollback</command> 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.</para> 15.221 + <para id="x_11e">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 <command role="hg-cmd">hg rollback</command>, come descritto nella <xref linkend="sec:undo:rollback"/>.</para> 15.222 + 15.223 + <para id="x_11f">Dopo che avete trasmesso un cambiamento sbagliato a un altro repository, <emphasis>potreste</emphasis> ancora usare <command role="hg-cmd">hg rollback</command> 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.</para> 15.224 15.225 <para id="x_120">Se vi trovate in una situazione come questa e sapete quali sono i repository verso cui si è propagato il vostro cambiamento sbagliato, potete <emphasis>provare</emphasis> a sbarazzarvi del cambiamento in <emphasis>ognuno</emphasis> di quei repository. Questa, naturalmente, non è una soluzione soddisfacente: se tralasciate anche un singolo repository quando state ripulendo, il cambiamento sarà ancora <quote>là fuori</quote> e potrebbe propagarsi ulteriormente.</para> 15.226 15.227 <para id="x_121">Se avete inserito uno o più cambiamenti <emphasis>dopo</emphasis> il cambiamento che vorreste veder sparire, le vostre opzioni si riducono ulteriormente. Mercurial non offre alcun modo per <quote>fare un buco</quote> nella cronologia lasciando gli altri changeset intatti.</para> 15.228 15.229 <sect2> 15.230 - <title>Ritirare un'unione</title> 15.231 - 15.232 - <para id="x_6ba">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.</para> 15.233 - 15.234 - <para id="x_6bb">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 <command role="hg-cmd">hg backout</command> può aiutare a rendere la pulizia più semplice attraverso l'opzione <option role="hg-opt-backout">--parent</option>, che vi consente di specificare a quale genitore tornare quando state ritirando un'unione.</para> 15.235 + <title>Ritirare un’unione</title> 15.236 + 15.237 + <para id="x_6ba">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.</para> 15.238 + 15.239 + <para id="x_6bb">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 <command role="hg-cmd">hg backout</command> può aiutare a rendere la pulizia più semplice attraverso l’opzione <option role="hg-opt-backout">--parent</option>, che vi consente di specificare a quale genitore tornare quando state ritirando un’unione.</para> 15.240 15.241 <figure id="fig:undo:bad-merge-1"> 15.242 - <title>Un'unione sbagliata</title> 15.243 + <title>Un’unione sbagliata</title> 15.244 <mediaobject> 15.245 <imageobject><imagedata fileref="figs/bad-merge-1.png"/></imageobject> 15.246 <textobject><phrase>XXX add text</phrase></textobject> 15.247 </mediaobject> 15.248 </figure> 15.249 15.250 - <para id="x_6bc">Supponete di avere un grafo delle revisioni simile a quello della <xref linkend="fig:undo:bad-merge-1"/>. Ci piacerebbe <emphasis>rifare</emphasis> l'unione tra le revisioni 2 e 3.</para> 15.251 + <para id="x_6bc">Supponete di avere un grafo delle revisioni simile a quello della <xref linkend="fig:undo:bad-merge-1"/>. Ci piacerebbe <emphasis>rifare</emphasis> l’unione tra le revisioni 2 e 3.</para> 15.252 15.253 <para id="x_6bd">Potremmo eseguire questa operazione nel modo seguente.</para> 15.254 15.255 <orderedlist> 15.256 <listitem> 15.257 - <para id="x_6be">Invocare <command role="hg-cmd">hg backout --rev=4 --parent=2</command>. Questo dice al comando <command role="hg-cmd">hg backout</command> 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 <xref linkend="fig:undo:bad-merge-2"/>.</para> 15.258 + <para id="x_6be">Invocare <command role="hg-cmd">hg backout --rev=4 --parent=2</command>. Questo dice al comando <command role="hg-cmd">hg backout</command> 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 <xref linkend="fig:undo:bad-merge-2"/>.</para> 15.259 <figure id="fig:undo:bad-merge-2"> 15.260 - <title>Ritirare l'unione favorendo un genitore</title> 15.261 + <title>Ritirare l’unione favorendo un genitore</title> 15.262 <mediaobject> 15.263 <imageobject><imagedata fileref="figs/bad-merge-2.png"/></imageobject> 15.264 <textobject><phrase>XXX add text</phrase></textobject> 15.265 @@ -337,9 +337,9 @@ 15.266 </listitem> 15.267 15.268 <listitem> 15.269 - <para id="x_6bf">Invocare <command role="hg-cmd">hg backout --rev=4 --parent=3</command>. Questo dice al comando <command role="hg-cmd">hg backout</command> di ritirare ancora la revisione 4, ma questa volta scegliendo il genitore 3, l'altro genitore dell'unione. Il risultato è visibile nella <xref linkend="fig:undo:bad-merge-3"/>, in cui il repository ora contiene tre teste.</para> 15.270 + <para id="x_6bf">Invocare <command role="hg-cmd">hg backout --rev=4 --parent=3</command>. Questo dice al comando <command role="hg-cmd">hg backout</command> di ritirare ancora la revisione 4, ma questa volta scegliendo il genitore 3, l’altro genitore dell’unione. Il risultato è visibile nella <xref linkend="fig:undo:bad-merge-3"/>, in cui il repository ora contiene tre teste.</para> 15.271 <figure id="fig:undo:bad-merge-3"> 15.272 - <title>Ritirare l'unione favorendo l'altro genitore</title> 15.273 + <title>Ritirare l’unione favorendo l’altro genitore</title> 15.274 <mediaobject> 15.275 <imageobject><imagedata fileref="figs/bad-merge-3.png"/></imageobject> 15.276 <textobject><phrase>XXX add text</phrase></textobject> 15.277 @@ -348,7 +348,7 @@ 15.278 </listitem> 15.279 15.280 <listitem> 15.281 - <para id="x_6c0">Rifare l'unione sbagliata unendo le due teste generate dai ritiri, riducendo quindi a due il numero di teste nel repository, come si può vedere nella <xref linkend="fig:undo:bad-merge-4"/>.</para> 15.282 + <para id="x_6c0">Rifare l’unione sbagliata unendo le due teste generate dai ritiri, riducendo quindi a due il numero di teste nel repository, come si può vedere nella <xref linkend="fig:undo:bad-merge-4"/>.</para> 15.283 <figure id="fig:undo:bad-merge-4"> 15.284 <title>Unire i risultati dei ritiri</title> 15.285 <mediaobject> 15.286 @@ -359,7 +359,7 @@ 15.287 </listitem> 15.288 15.289 <listitem> 15.290 - <para id="x_6c1">Eseguire un'unione con il commit che è stato eseguito dopo l'unione sbagliata, come mostrato nella <xref linkend="fig:undo:bad-merge-5"/>.</para> 15.291 + <para id="x_6c1">Eseguire un’unione con il commit che è stato eseguito dopo l’unione sbagliata, come mostrato nella <xref linkend="fig:undo:bad-merge-5"/>.</para> 15.292 <figure id="fig:undo:bad-merge-5"> 15.293 <title>Unire i risultati dei ritiri</title> 15.294 <mediaobject> 15.295 @@ -386,13 +386,13 @@ 15.296 15.297 <para id="x_6c2">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.</para> 15.298 15.299 - <para id="x_6c3">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 trapelate 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.</para> 15.300 + <para id="x_6c3">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 trapelate 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.</para> 15.301 15.302 <para id="x_6c4">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.</para> 15.303 15.304 <para id="x_6c5">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.</para> 15.305 15.306 - <para id="x_6c6">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 <quote>fa sparire questo file</quote> 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.</para> 15.307 + <para id="x_6c6">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 <quote>fa sparire questo file</quote> 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.</para> 15.308 </sect2> 15.309 </sect1> 15.310 15.311 @@ -401,7 +401,7 @@ 15.312 15.313 <para id="x_126">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 <command role="hg-cmd">hg bisect</command>, che vi aiuta ad automatizzare questo processo e a completarlo in maniera molto efficiente.</para> 15.314 15.315 - <para id="x_127">L'idea alla base del comando <command role="hg-cmd">hg bisect</command> è 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 <command role="hg-cmd">hg bisect</command> usa il vostro test per dirigere la propria ricerca del changeset che ha introdotto il codice che ha causato il bug.</para> 15.316 + <para id="x_127">L’idea alla base del comando <command role="hg-cmd">hg bisect</command> è 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 <command role="hg-cmd">hg bisect</command> usa il vostro test per dirigere la propria ricerca del changeset che ha introdotto il codice che ha causato il bug.</para> 15.317 15.318 <para id="x_128">Ecco alcuni scenari di esempio per aiutarvi a capire come potreste applicare questo comando.</para> 15.319 <itemizedlist> 15.320 @@ -409,18 +409,18 @@ 15.321 </listitem> 15.322 <listitem><para id="x_12a">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.</para> 15.323 </listitem> 15.324 - <listitem><para id="x_12b">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 è <quote>veloce</quote> o <quote>lento</quote>.</para> 15.325 + <listitem><para id="x_12b">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 è <quote>veloce</quote> o <quote>lento</quote>.</para> 15.326 </listitem> 15.327 <listitem><para id="x_12c">La dimensione dei componenti del progetto che rilasciate è esplosa di recente e sospettate che qualcosa sia cambiato nel modo in cui assemblate il progetto.</para> 15.328 </listitem></itemizedlist> 15.329 15.330 - <para id="x_12d">Da questi esempi, dovrebbe essere chiaro che il comando <command role="hg-cmd">hg bisect</command> non è utile solo per trovare le cause dei bug. Potete usarlo per trovare qualsiasi <quote>proprietà emergente</quote> 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.</para> 15.331 - 15.332 - <para id="x_12e">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 <emphasis>test</emphasis> è qualcosa che <emphasis>voi</emphasis> eseguite quando <command role="hg-cmd">hg bisect</command> sceglie un changeset. Una <emphasis>sonda</emphasis> è ciò che <command role="hg-cmd">hg bisect</command> esegue per dirvi se una revisione è buona. Infine, useremo la parola <quote>bisezione</quote> per intendere la <quote>ricerca tramite il comando <command role="hg-cmd">hg bisect</command></quote>.</para> 15.333 - 15.334 - <para id="x_12f">Un modo semplice per automatizzare il processo di ricerca sarebbe quello di collaudare semplicemente tutti i changeset. Tuttavia, questo approccio è scarsamente scalabile. Se ci volessero dieci minuti per collaudare un singolo changeset e il vostro repository contenesse 10.000 changeset, l'approccio completo impiegherebbe una media di 35 <emphasis>giorni</emphasis> 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.</para> 15.335 - 15.336 - <para id="x_130">Il comando <command role="hg-cmd">hg bisect</command> invece usa la propria conoscenza della <quote>forma</quote> della cronologia delle revisioni del vostro progetto per effettuare una ricerca in tempo proporzionale al <emphasis>logaritmo</emphasis> del numero dei changeset da controllare (il tipo di ricerca che esegue viene chiamata ricerca dicotomica). Con questo approccio, la ricerca attraverso 10.000 changeset impiegherà meno di 3 ore, anche a 10 minuti per test (la ricerca richiederà circa 14 test). Limitate la vostra ricerca agli ultimi cento changeset e il tempo impiegato sarà solo circa un'ora (approssimativamente sette test).</para> 15.337 + <para id="x_12d">Da questi esempi, dovrebbe essere chiaro che il comando <command role="hg-cmd">hg bisect</command> non è utile solo per trovare le cause dei bug. Potete usarlo per trovare qualsiasi <quote>proprietà emergente</quote> 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.</para> 15.338 + 15.339 + <para id="x_12e">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 <emphasis>test</emphasis> è qualcosa che <emphasis>voi</emphasis> eseguite quando <command role="hg-cmd">hg bisect</command> sceglie un changeset. Una <emphasis>sonda</emphasis> è ciò che <command role="hg-cmd">hg bisect</command> esegue per dirvi se una revisione è buona. Infine, useremo la parola <quote>bisezione</quote> per intendere la <quote>ricerca tramite il comando <command role="hg-cmd">hg bisect</command></quote>.</para> 15.340 + 15.341 + <para id="x_12f">Un modo semplice per automatizzare il processo di ricerca sarebbe quello di collaudare semplicemente tutti i changeset. Tuttavia, questo approccio è scarsamente scalabile. Se ci volessero dieci minuti per collaudare un singolo changeset e il vostro repository contenesse 10.000 changeset, l’approccio completo impiegherebbe una media di 35 <emphasis>giorni</emphasis> 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.</para> 15.342 + 15.343 + <para id="x_130">Il comando <command role="hg-cmd">hg bisect</command> invece usa la propria conoscenza della <quote>forma</quote> della cronologia delle revisioni del vostro progetto per effettuare una ricerca in tempo proporzionale al <emphasis>logaritmo</emphasis> del numero dei changeset da controllare (il tipo di ricerca che esegue viene chiamata ricerca dicotomica). Con questo approccio, la ricerca attraverso 10.000 changeset impiegherà meno di 3 ore, anche a 10 minuti per test (la ricerca richiederà circa 14 test). Limitate la vostra ricerca agli ultimi cento changeset e il tempo impiegato sarà solo circa un’ora (approssimativamente sette test).</para> 15.344 15.345 <para id="x_131">Il comando <command role="hg-cmd">hg bisect</command> è consapevole della natura <quote>ramificata</quote> della cronologia delle revisioni di un progetto Mercurial, quindi non ha problemi a trattare con rami, unioni, o molteplici teste in un repository. Opera in maniera così efficiente perché è in grado di potare interi rami di cronologia con una singola sonda.</para> 15.346 15.347 @@ -465,7 +465,7 @@ 15.348 15.349 &interaction.bisect.search.init; 15.350 15.351 - <para id="x_13f">Nel nostro caso, il test binario che usiamo è semplice: controlliamo il repository per vedere se qualche file contiene la stringa <quote>ho un gub</quote>. Se è così, questo changeset contiene il cambiamento che ha <quote>causato il bug</quote>. Per convenzione, un changeset che ha la proprietà che stiamo cercando è <quote>guasto</quote>, mentre uno che non ce l'ha è <quote>funzionante</quote>.</para> 15.352 + <para id="x_13f">Nel nostro caso, il test binario che usiamo è semplice: controlliamo il repository per vedere se qualche file contiene la stringa <quote>ho un gub</quote>. Se è così, questo changeset contiene il cambiamento che ha <quote>causato il bug</quote>. Per convenzione, un changeset che ha la proprietà che stiamo cercando è <quote>guasto</quote>, mentre uno che non ce l’ha è <quote>funzionante</quote>.</para> 15.353 15.354 <para id="x_140">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 <quote>guasta</quote>.</para> 15.355 15.356 @@ -482,11 +482,11 @@ 15.357 <listitem><para id="x_144">Ha aggiornato la directory di lavoro al prossimo changeset da collaudare e ci ha detto quale changeset sta collaudando.</para> 15.358 </listitem></itemizedlist> 15.359 15.360 - <para id="x_145">Ora eseguiamo il nostro test nella directory di lavoro, usando il comando <command>grep</command> per vedere se il nostro file <quote>guasto</quote> è presente. Se c'è, questa revisione è guasta, altrimenti è funzionante.</para> 15.361 + <para id="x_145">Ora eseguiamo il nostro test nella directory di lavoro, usando il comando <command>grep</command> per vedere se il nostro file <quote>guasto</quote> è presente. Se c’è, questa revisione è guasta, altrimenti è funzionante.</para> 15.362 15.363 &interaction.bisect.search.step1; 15.364 15.365 - <para id="x_146">Questo test sembra un perfetto candidato per l'automazione, quindi trasformiamolo in una funzione di shell.</para> 15.366 + <para id="x_146">Questo test sembra un perfetto candidato per l’automazione, quindi trasformiamolo in una funzione di shell.</para> 15.367 15.368 &interaction.bisect.search.mytest; 15.369 15.370 @@ -516,13 +516,13 @@ 15.371 <sect2> 15.372 <title>Fornite informazioni consistenti</title> 15.373 15.374 - <para id="x_14b">Il comando <command role="hg-cmd">hg bisect</command> 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 <emphasis>potrebbe</emphasis> essere in grado di scoprire l'inconsistenza. Se riesce a identificare un'inconsistenza nei vostri resoconti, vi dirà che un particolare changeset è sia funzionante che guasto. Tuttavia, non è in grado di farlo perfettamente ed è ugualmente probabile che vi restituisca il changeset sbagliato come causa del bug.</para> 15.375 + <para id="x_14b">Il comando <command role="hg-cmd">hg bisect</command> 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 <emphasis>potrebbe</emphasis> essere in grado di scoprire l’inconsistenza. Se riesce a identificare un’inconsistenza nei vostri resoconti, vi dirà che un particolare changeset è sia funzionante che guasto. Tuttavia, non è in grado di farlo perfettamente ed è ugualmente probabile che vi restituisca il changeset sbagliato come causa del bug.</para> 15.376 15.377 </sect2> 15.378 <sect2> 15.379 <title>Automatizzate il più possibile</title> 15.380 15.381 - <para id="x_14c">Quando ho cominciato a usare il comando <command role="hg-cmd">hg bisect</command>, 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.</para> 15.382 + <para id="x_14c">Quando ho cominciato a usare il comando <command role="hg-cmd">hg bisect</command>, 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.</para> 15.383 15.384 <para id="x_14d">I miei problemi iniziali nel guidare a mano il comando <command role="hg-cmd">hg bisect</command> 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 <command role="hg-cmd">hg bisect</command> 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.</para> 15.385 15.386 @@ -532,7 +532,7 @@ 15.387 </listitem> 15.388 <listitem><para id="x_150">fornite sempre informazioni consistenti al comando <command role="hg-cmd">hg bisect</command>.</para> 15.389 </listitem></itemizedlist> 15.390 - <para id="x_151">Nel mio esempio precedente, il comando <command>grep</command> verifica il sintomo e l'istruzione <literal>if</literal> usa il risultato di questo controllo per assicurarsi di fornire la stessa informazione al comando <command role="hg-cmd">hg bisect</command>. La funzione <literal>miotest</literal> ci permette di riprodurre insieme queste due operazioni, in modo che ogni test sia uniforme e consistente.</para> 15.391 + <para id="x_151">Nel mio esempio precedente, il comando <command>grep</command> verifica il sintomo e l’istruzione <literal>if</literal> usa il risultato di questo controllo per assicurarsi di fornire la stessa informazione al comando <command role="hg-cmd">hg bisect</command>. La funzione <literal>miotest</literal> ci permette di riprodurre insieme queste due operazioni, in modo che ogni test sia uniforme e consistente.</para> 15.392 15.393 </sect2> 15.394 <sect2> 15.395 @@ -542,7 +542,7 @@ 15.396 <itemizedlist> 15.397 <listitem><para id="x_153">Il changeset che il comando riporta come la prima revisione guasta. Il vostro test dovrebbe verificare che la revisione sia effettivamente guasta.</para> 15.398 </listitem> 15.399 - <listitem><para id="x_154">Il genitore di quel changeset (entrambi i genitori, se è un'unione). Il vostro test dovrebbe verificare che quel changeset sia funzionante.</para> 15.400 + <listitem><para id="x_154">Il genitore di quel changeset (entrambi i genitori, se è un’unione). Il vostro test dovrebbe verificare che quel changeset sia funzionante.</para> 15.401 </listitem> 15.402 <listitem><para id="x_155">Un figlio di quel changeset. Il vostro test dovrebbe verificare che quel changeset sia guasto.</para> 15.403 </listitem></itemizedlist> 15.404 @@ -553,11 +553,11 @@ 15.405 15.406 <para id="x_156">È 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.</para> 15.407 15.408 - <para id="x_157">È possibile che questo altro bug <quote>mascheri</quote> 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 <command role="hg-cmd">hg bisect</command> non è in grado di aiutarvi direttamente. Invece, invocando <command role="hg-cmd">hg bisect --skip</command> potete indicare un changeset come non collaudato.</para> 15.409 + <para id="x_157">È possibile che questo altro bug <quote>mascheri</quote> 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 <command role="hg-cmd">hg bisect</command> non è in grado di aiutarvi direttamente. Invece, invocando <command role="hg-cmd">hg bisect --skip</command> potete indicare un changeset come non collaudato.</para> 15.410 15.411 <para id="x_158">Potrebbe esserci un problema differente se il vostro test per la presenza di un bug non è abbastanza specifico. Se controllate che <quote>il mio programma si blocca</quote>, allora sia il vostro bug bloccante che il bug bloccante non correlato che lo maschera sembreranno la stessa cosa e fuorvieranno <command role="hg-cmd">hg bisect</command>.</para> 15.412 15.413 - <para id="x_159">Un'altra situazione utile per sfruttare <command role="hg-cmd">hg bisect --skip</command> è 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.</para> 15.414 + <para id="x_159">Un’altra situazione utile per sfruttare <command role="hg-cmd">hg bisect --skip</command> è 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.</para> 15.415 15.416 </sect2> 15.417 <sect2>
16.1 --- a/it/ch10-hook.xml Sat Aug 22 21:01:56 2009 +0200 16.2 +++ b/it/ch10-hook.xml Sat Aug 22 21:55:05 2009 +0200 16.3 @@ -7,11 +7,11 @@ 16.4 <para id="x_1e7">Il nome che Mercurial usa per indicare una di queste azioni è <emphasis>hook</emphasis> (letteralmente, gancio). In alcuni sistemi di controllo di revisione, gli hook vengono chiamati <quote>trigger</quote> (letteralmente, grilletto), ma i due nomi si riferiscono alla stessa idea.</para> 16.5 16.6 <sect1> 16.7 - <title>Un'introduzione agli hook di Mercurial</title> 16.8 + <title>Un’introduzione agli hook di Mercurial</title> 16.9 16.10 <para id="x_1e8">Qui di seguito troverete una breve lista degli hook supportati da Mercurial. Rivisiteremo ognuno di questi hook in maggior dettaglio più avanti, nella <xref linkend="sec:hook:ref"/>.</para> 16.11 16.12 - <para id="x_1f6">Ognuno degli hook che viene indicato come <quote>hook di controllo</quote> nella propria descrizione ha l'abilità di determinare se un'attività può procedere. Se l'hook ha successo, l'attività può procedere; se fallisce, l'attività non viene permessa oppure viene annullata, a seconda dell'hook.</para> 16.13 + <para id="x_1f6">Ognuno degli hook che viene indicato come <quote>hook di controllo</quote> nella propria descrizione ha l’abilità di determinare se un’attività può procedere. Se l’hook ha successo, l’attività può procedere; se fallisce, l’attività non viene permessa oppure viene annullata, a seconda dell’hook.</para> 16.14 16.15 <itemizedlist> 16.16 <listitem><para id="x_1e9"><literal role="hook">changegroup</literal>: viene eseguito dopo che un gruppo di changeset proveniente da qualche altra parte è stato propagato nel repository.</para> 16.17 @@ -29,17 +29,17 @@ 16.18 </listitem> 16.19 <listitem><para id="x_1ef"><literal role="hook">preoutgoing</literal>: hook di controllo. Viene eseguito prima di cominciare a trasmettere un gruppo di changeset da questo repository.</para> 16.20 </listitem> 16.21 - <listitem><para id="x_1f0"><literal role="hook">pretag</literal>: hook di controllo. Viene eseguito prima di creare un'etichetta.</para> 16.22 + <listitem><para id="x_1f0"><literal role="hook">pretag</literal>: hook di controllo. Viene eseguito prima di creare un’etichetta.</para> 16.23 </listitem> 16.24 <listitem><para id="x_1f1"><literal role="hook">pretxnchangegroup</literal>: hook di controllo. Viene eseguito dopo che un gruppo di changeset proveniente da un altro repository è stato propagato nel repository locale, ma prima di completare la transazione che renderebbe permanenti i cambiamenti nel repository.</para> 16.25 </listitem> 16.26 <listitem><para id="x_1f2"><literal role="hook">pretxncommit</literal>: hook di controllo. Viene eseguito dopo la creazione di un nuovo changeset nel repository locale, ma prima di completare la transazione che lo renderebbe permanente.</para> 16.27 </listitem> 16.28 - <listitem><para id="x_1f3"><literal role="hook">preupdate</literal>: hook di controllo. Viene eseguito prima di cominciare un aggiornamento o un'unione della directory di lavoro.</para> 16.29 - </listitem> 16.30 - <listitem><para id="x_1f4"><literal role="hook">tag</literal>: viene eseguito dopo la creazione di un'etichetta.</para> 16.31 - </listitem> 16.32 - <listitem><para id="x_1f5"><literal role="hook">update</literal>: viene eseguito dopo che un'operazione di aggiornamento o di unione della directory di lavoro è stata completata.</para> 16.33 + <listitem><para id="x_1f3"><literal role="hook">preupdate</literal>: hook di controllo. Viene eseguito prima di cominciare un aggiornamento o un’unione della directory di lavoro.</para> 16.34 + </listitem> 16.35 + <listitem><para id="x_1f4"><literal role="hook">tag</literal>: viene eseguito dopo la creazione di un’etichetta.</para> 16.36 + </listitem> 16.37 + <listitem><para id="x_1f5"><literal role="hook">update</literal>: viene eseguito dopo che un’operazione di aggiornamento o di unione della directory di lavoro è stata completata.</para> 16.38 </listitem></itemizedlist> 16.39 16.40 </sect1> 16.41 @@ -49,29 +49,29 @@ 16.42 <sect2> 16.43 <title>Gli hook vengono eseguiti con i vostri privilegi</title> 16.44 16.45 - <para id="x_1f7">Quando invocate un comando Mercurial in un repository e quel comando causa l'esecuzione di un hook, quell'hook viene eseguito sul <emphasis>vostro</emphasis> sistema, con il <emphasis>vostro</emphasis> account utente, al <emphasis>vostro</emphasis> livello di privilegio. Dato che gli hook sono frammenti di codice eseguibile, dovreste trattarli in maniera adeguatamente sospettosa. Non installate un hook a meno che non confidiate di sapere chi lo ha creato e che cosa fa.</para> 16.46 + <para id="x_1f7">Quando invocate un comando Mercurial in un repository e quel comando causa l’esecuzione di un hook, quell’hook viene eseguito sul <emphasis>vostro</emphasis> sistema, con il <emphasis>vostro</emphasis> account utente, al <emphasis>vostro</emphasis> livello di privilegio. Dato che gli hook sono frammenti di codice eseguibile, dovreste trattarli in maniera adeguatamente sospettosa. Non installate un hook a meno che non confidiate di sapere chi lo ha creato e che cosa fa.</para> 16.47 16.48 <para id="x_1f8">In alcuni casi, potreste essere esposti a hook che non avete installato voi. Se lavorate con Mercurial su un sistema che non vi è familiare, sappiate che Mercurial eseguirà gli hook definiti nel file <filename role="special">hgrc</filename> globale per quel sistema.</para> 16.49 16.50 - <para id="x_1f9">Se state lavorando con un repository posseduto da un altro utente, Mercurial può eseguire gli hook definiti nel repository di quell'utente, ma li eseguirà ancora sotto la <quote>vostra identità</quote>. Per esempio, se estraete i cambiamenti da quel repository tramite <command role="hg-cmd">hg pull</command>, e il suo file <filename role="special">.hg/hgrc</filename> definisce un hook <literal role="hook">outgoing</literal> locale, quell'hook verrà eseguito con il vostro account utente anche se non siete il proprietario di quel repository.</para> 16.51 + <para id="x_1f9">Se state lavorando con un repository posseduto da un altro utente, Mercurial può eseguire gli hook definiti nel repository di quell’utente, ma li eseguirà ancora sotto la <quote>vostra identità</quote>. Per esempio, se estraete i cambiamenti da quel repository tramite <command role="hg-cmd">hg pull</command>, e il suo file <filename role="special">.hg/hgrc</filename> definisce un hook <literal role="hook">outgoing</literal> locale, quell’hook verrà eseguito con il vostro account utente anche se non siete il proprietario di quel repository.</para> 16.52 16.53 <note> 16.54 - <para id="x_1fa">Questo avviene solo se estraete cambiamenti da un repository operando su un file system locale o di rete. Se state effettuando l'estrazione via HTTP o ssh, qualsiasi hook <literal role="hook">outgoing</literal> verrà eseguito sul server con l'account utente che è stato usato per eseguire il processo server.</para> 16.55 + <para id="x_1fa">Questo avviene solo se estraete cambiamenti da un repository operando su un file system locale o di rete. Se state effettuando l’estrazione via HTTP o ssh, qualsiasi hook <literal role="hook">outgoing</literal> verrà eseguito sul server con l’account utente che è stato usato per eseguire il processo server.</para> 16.56 </note> 16.57 16.58 - <para id="x_1fb">Per vedere quali hook sono definiti in un repository, usate il comando <command role="hg-cmd">hg showconfig hooks</command>. Se state lavorando in un repository, ma state comunicando con un repository di cui non siete i proprietari (per esempio, usando <command role="hg-cmd">hg pull</command> o <command role="hg-cmd">hg incoming</command>), ricordate che sono gli hook dell'altro repository che dovreste controllare, non i vostri.</para> 16.59 + <para id="x_1fb">Per vedere quali hook sono definiti in un repository, usate il comando <command role="hg-cmd">hg showconfig hooks</command>. Se state lavorando in un repository, ma state comunicando con un repository di cui non siete i proprietari (per esempio, usando <command role="hg-cmd">hg pull</command> o <command role="hg-cmd">hg incoming</command>), ricordate che sono gli hook dell’altro repository che dovreste controllare, non i vostri.</para> 16.60 </sect2> 16.61 16.62 <sect2> 16.63 <title>Gli hook non si propagano</title> 16.64 16.65 - <para id="x_1fc">In Mercurial, gli hook non sono soggetti a controllo di revisione e non si propagano quando clonate un repository o ne estraete i cambiamenti. La ragione è semplice: un hook è un frammento di codice eseguibile completamente arbitrario. Viene eseguito sotto l'identità del vostro utente, al vostro livello di privilegio, sulla vostra macchina.</para> 16.66 + <para id="x_1fc">In Mercurial, gli hook non sono soggetti a controllo di revisione e non si propagano quando clonate un repository o ne estraete i cambiamenti. La ragione è semplice: un hook è un frammento di codice eseguibile completamente arbitrario. Viene eseguito sotto l’identità del vostro utente, al vostro livello di privilegio, sulla vostra macchina.</para> 16.67 16.68 <para id="x_1fd">Sarebbe estremamente avventato per qualsiasi sistema distribuito di controllo di revisione implementare hook soggetti al controllo di revisione, dato che questo offrirebbe un modo facilmente sfruttabile per alterare gli account degli utenti del sistema di controllo di revisione.</para> 16.69 16.70 <para id="x_1fe">Dato che Mercurial non propaga gli hook, se state collaborando con altre persone su un progetto comune, non dovreste presumere che gli altri stiano usando gli stessi hook Mercurial che state usando voi, o che i loro siano correttamente configurati. Dovreste documentare quali sono gli hook che vi aspettate siano usati dalle altre persone.</para> 16.71 16.72 - <para id="x_1ff">In una intranet aziendale, questo aspetto è in qualche modo più facile da controllare, dato che per esempio potete fornire un'installazione <quote>standard</quote> di Mercurial su un file system NFS e usare un file <filename role="special">hgrc</filename> globale per definire hook che verranno visti da tutti gli utenti. Tuttavia, come constateremo nella prossima sezione, anche questo approccio ha dei limiti.</para> 16.73 + <para id="x_1ff">In una intranet aziendale, questo aspetto è in qualche modo più facile da controllare, dato che per esempio potete fornire un’installazione <quote>standard</quote> di Mercurial su un file system NFS e usare un file <filename role="special">hgrc</filename> globale per definire hook che verranno visti da tutti gli utenti. Tuttavia, come constateremo nella prossima sezione, anche questo approccio ha dei limiti.</para> 16.74 </sect2> 16.75 16.76 <sect2> 16.77 @@ -85,11 +85,11 @@ 16.78 <sect2> 16.79 <title>Assicurarsi che gli hook critici vengano eseguiti</title> 16.80 16.81 - <para id="x_202">Talvolta potreste voler imporre il rispetto di una politica in modo che gli altri non siano in grado di aggirarla. Per esempio, potreste richiedere a ogni changeset di passare una rigorosa serie di test. La definizione di questo requisito attraverso un hook in un file <filename role="special">hgrc</filename> globale non avrà effetto sui computer portatili degli utenti remoti, e naturalmente gli utenti locali potranno alterarla a piacimento ridefinendo quell'hook.</para> 16.82 - 16.83 - <para id="x_203">Invece, potete istituire le vostre politiche sull'uso di Mercurial in modo che le persone siano tenute a propagare i cambiamenti attraverso un server <quote>ufficiale</quote> ben noto che avete messo in sicurezza e configurato adeguatamente.</para> 16.84 - 16.85 - <para id="x_204">Questo risultato si può ottenere attraverso una combinazione di ingegneria sociale e tecnologia. Se impostate un account con accesso ristretto, gli utenti potranno trasmettere i cambiamenti attraverso la rete ai repository gestiti da questo account, ma non potranno usare l'account per entrare sul server ed eseguire i normali comandi di shell. In questo scenario, un utente può effettuare il commit di un changeset che contiene tutte le porcherie che desidera.</para> 16.86 + <para id="x_202">Talvolta potreste voler imporre il rispetto di una politica in modo che gli altri non siano in grado di aggirarla. Per esempio, potreste richiedere a ogni changeset di passare una rigorosa serie di test. La definizione di questo requisito attraverso un hook in un file <filename role="special">hgrc</filename> globale non avrà effetto sui computer portatili degli utenti remoti, e naturalmente gli utenti locali potranno alterarla a piacimento ridefinendo quell’hook.</para> 16.87 + 16.88 + <para id="x_203">Invece, potete istituire le vostre politiche sull’uso di Mercurial in modo che le persone siano tenute a propagare i cambiamenti attraverso un server <quote>ufficiale</quote> ben noto che avete messo in sicurezza e configurato adeguatamente.</para> 16.89 + 16.90 + <para id="x_204">Questo risultato si può ottenere attraverso una combinazione di ingegneria sociale e tecnologia. Se impostate un account con accesso ristretto, gli utenti potranno trasmettere i cambiamenti attraverso la rete ai repository gestiti da questo account, ma non potranno usare l’account per entrare sul server ed eseguire i normali comandi di shell. In questo scenario, un utente può effettuare il commit di un changeset che contiene tutte le porcherie che desidera.</para> 16.91 16.92 <para id="x_205">Quando qualcuno trasmette un changeset al server da cui tutti estraggono i cambiamenti, il server verificherà il changeset prima di accettarlo come permanente e lo rifiuterà se non riesce a passare i test. Se le persone si limitano a estrarre i cambiamenti da questo server di filtraggio, questo servirà ad assicurare che tutti i cambiamenti estratti dalle persone siano stati automaticamente controllati.</para> 16.93 16.94 @@ -97,16 +97,16 @@ 16.95 </sect1> 16.96 16.97 <sect1 id="sec:hook:simple"> 16.98 - <title>Una breve guida all'uso degli hook</title> 16.99 - 16.100 - <para id="x_212">Scrivere un hook Mercurial è facile. Cominciamo con un hook che viene invocato al termine dell'esecuzione di <command role="hg-cmd">hg commit</command> e che stampa semplicemente l'hash del changeset appena creato. L'hook è chiamato <literal role="hook">commit</literal>. 16.101 + <title>Una breve guida all’uso degli hook</title> 16.102 + 16.103 + <para id="x_212">Scrivere un hook Mercurial è facile. Cominciamo con un hook che viene invocato al termine dell’esecuzione di <command role="hg-cmd">hg commit</command> e che stampa semplicemente l’hash del changeset appena creato. L’hook è chiamato <literal role="hook">commit</literal>. 16.104 </para> 16.105 16.106 <para id="x_213">Tutti gli hook seguono lo schema presentato in questo esempio.</para> 16.107 16.108 &interaction.hook.simple.init; 16.109 16.110 - <para id="x_214">Aggiungete una voce alla sezione <literal role="rc-hooks">hooks</literal> del vostro file <filename role="special">~/.hgrc</filename>. Sulla sinistra si trova il nome dell'evento in risposta al quale attivarsi, sulla destra si trova l'azione da intraprendere. Come vedete, è possibile eseguire comandi di shell arbitrari in un hook. Mercurial passa informazioni aggiuntive all'hook usando le variabili d'ambiente (cercate <envar>HG_NODE</envar> nell'esempio).</para> 16.111 + <para id="x_214">Aggiungete una voce alla sezione <literal role="rc-hooks">hooks</literal> del vostro file <filename role="special">~/.hgrc</filename>. Sulla sinistra si trova il nome dell’evento in risposta al quale attivarsi, sulla destra si trova l’azione da intraprendere. Come vedete, è possibile eseguire comandi di shell arbitrari in un hook. Mercurial passa informazioni aggiuntive all’hook usando le variabili d’ambiente (cercate <envar>HG_NODE</envar> nell’esempio).</para> 16.112 16.113 <sect2> 16.114 <title>Effettuare molteplici azioni per evento</title> 16.115 @@ -115,39 +115,39 @@ 16.116 16.117 &interaction.hook.simple.ext; 16.118 16.119 - <para id="x_216">Mercurial vi permette di fare questo aggiungendo un'<emphasis>estensione</emphasis> alla fine del nome di un hook. Il nome di un hook si estende scrivendo il nome dell'hook, seguito da un punto (il carattere <quote><literal>.</literal></quote>), seguito da altro testo di vostra scelta. Per esempio, Mercurial eseguirà sia <literal>commit.foo</literal> che <literal>commit.bar</literal> all'occorrenza dell'evento <literal>commit</literal>.</para> 16.120 - 16.121 - <para id="x_217">Per stabilire un ordine di esecuzione ben definito quando più hook corrispondono allo stesso evento, Mercurial ordina gli hook secondo l'estensione ed esegue i comandi di hook in questo ordine. Nell'esempio precedente, eseguirà <literal>commit.bar</literal> prima di <literal>commit.foo</literal>, e <literal>commit</literal> prima di entrambi.</para> 16.122 - 16.123 - <para id="x_218">Per aiutarvi a ricordare lo scopo di un hook, è buona norma usare un'estensione abbastanza descrittiva quando ne definite uno nuovo. Se l'hook fallisce, otterrete un messaggio di errore che contiene il nome dell'hook e l'estensione, quindi l'impiego di un'estensione descrittiva potrebbe darvi un suggerimento immediato sul motivo per cui l'hook è fallito (si veda la <xref linkend="sec:hook:perm"/> per un esempio).</para> 16.124 + <para id="x_216">Mercurial vi permette di fare questo aggiungendo un’<emphasis>estensione</emphasis> alla fine del nome di un hook. Il nome di un hook si estende scrivendo il nome dell’hook, seguito da un punto (il carattere <quote><literal>.</literal></quote>), seguito da altro testo di vostra scelta. Per esempio, Mercurial eseguirà sia <literal>commit.foo</literal> che <literal>commit.bar</literal> all’occorrenza dell’evento <literal>commit</literal>.</para> 16.125 + 16.126 + <para id="x_217">Per stabilire un ordine di esecuzione ben definito quando più hook corrispondono allo stesso evento, Mercurial ordina gli hook secondo l’estensione ed esegue i comandi di hook in questo ordine. Nell’esempio precedente, eseguirà <literal>commit.bar</literal> prima di <literal>commit.foo</literal>, e <literal>commit</literal> prima di entrambi.</para> 16.127 + 16.128 + <para id="x_218">Per aiutarvi a ricordare lo scopo di un hook, è buona norma usare un’estensione abbastanza descrittiva quando ne definite uno nuovo. Se l’hook fallisce, otterrete un messaggio di errore che contiene il nome dell’hook e l’estensione, quindi l’impiego di un’estensione descrittiva potrebbe darvi un suggerimento immediato sul motivo per cui l’hook è fallito (si veda la <xref linkend="sec:hook:perm"/> per un esempio).</para> 16.129 16.130 </sect2> 16.131 <sect2 id="sec:hook:perm"> 16.132 - <title>Controllare se un'attività può procedere</title> 16.133 - 16.134 - <para id="x_219">Nei nostri primi esempi, abbiamo usato l'hook <literal role="hook">commit</literal>, che viene invocato al termine di un commit ed è uno dei vari hook Mercurial che vengono eseguiti dopo la conclusione di un'attività. Questi hook non hanno alcun modo di influenzare l'attività stessa.</para> 16.135 - 16.136 - <para id="x_21a">Mercurial definisce un certo numero di eventi che accadono prima che un'attività cominci, o dopo che è cominciata ma prima che termini. Gli hook attivati da questi eventi hanno l'ulteriore capacità di determinare se l'attività può continuare o se verrà abortita.</para> 16.137 - 16.138 - <para id="x_21b">L'hook <literal role="hook">pretxncommit</literal> viene invocato dopo che un commit è stato completamente eseguito ma non si è ancora concluso. In altre parole, i metadati che rappresentano il changeset sono stati scritti su disco, ma la transazione non ha ancora avuto il permesso di completarsi. L'hook <literal role="hook">pretxncommit</literal> ha la capacità di decidere se la transazione può completarsi oppure se deve essere abortita.</para> 16.139 - 16.140 - <para id="x_21c">Se l'hook <literal role="hook">pretxncommit</literal> termina con un codice di stato uguale a zero, la transazione può completare, il commit si conclude e l'hook <literal role="hook">commit</literal> viene eseguito. Se l'hook <literal role="hook">pretxncommit</literal> termina con un codice di stato diverso da zero, la transazione viene abortita, i metadati che rappresentano il changeset vengono cancellati e l'hook <literal role="hook">commit</literal> non viene eseguito.</para> 16.141 + <title>Controllare se un’attività può procedere</title> 16.142 + 16.143 + <para id="x_219">Nei nostri primi esempi, abbiamo usato l’hook <literal role="hook">commit</literal>, che viene invocato al termine di un commit ed è uno dei vari hook Mercurial che vengono eseguiti dopo la conclusione di un’attività. Questi hook non hanno alcun modo di influenzare l’attività stessa.</para> 16.144 + 16.145 + <para id="x_21a">Mercurial definisce un certo numero di eventi che accadono prima che un’attività cominci, o dopo che è cominciata ma prima che termini. Gli hook attivati da questi eventi hanno l’ulteriore capacità di determinare se l’attività può continuare o se verrà abortita.</para> 16.146 + 16.147 + <para id="x_21b">L’hook <literal role="hook">pretxncommit</literal> viene invocato dopo che un commit è stato completamente eseguito ma non si è ancora concluso. In altre parole, i metadati che rappresentano il changeset sono stati scritti su disco, ma la transazione non ha ancora avuto il permesso di completarsi. L’hook <literal role="hook">pretxncommit</literal> ha la capacità di decidere se la transazione può completarsi oppure se deve essere abortita.</para> 16.148 + 16.149 + <para id="x_21c">Se l’hook <literal role="hook">pretxncommit</literal> termina con un codice di stato uguale a zero, la transazione può completare, il commit si conclude e l’hook <literal role="hook">commit</literal> viene eseguito. Se l’hook <literal role="hook">pretxncommit</literal> termina con un codice di stato diverso da zero, la transazione viene abortita, i metadati che rappresentano il changeset vengono cancellati e l’hook <literal role="hook">commit</literal> non viene eseguito.</para> 16.150 16.151 &interaction.hook.simple.pretxncommit; 16.152 16.153 - <para id="x_21d">In questo esempio, l'hook controlla che il messaggio di commit contenga un identificatore di bug. Se lo contiene, il commit può completare, altrimenti il commit viene abortito.</para> 16.154 + <para id="x_21d">In questo esempio, l’hook controlla che il messaggio di commit contenga un identificatore di bug. Se lo contiene, il commit può completare, altrimenti il commit viene abortito.</para> 16.155 16.156 </sect2> 16.157 </sect1> 16.158 <sect1> 16.159 <title>Implementare i vostri hook</title> 16.160 16.161 - <para id="x_21e">Quando state scrivendo un hook, potreste trovare utile eseguire Mercurial con l'opzione <option role="hg-opt-global">-v</option> oppure con l'elemento di configurazione <envar role="rc-item-ui">verbose</envar> impostato a <quote>vero</quote>, in modo che Mercurial stampi un messaggio prima di invocare qualsiasi hook.</para> 16.162 + <para id="x_21e">Quando state scrivendo un hook, potreste trovare utile eseguire Mercurial con l’opzione <option role="hg-opt-global">-v</option> oppure con l’elemento di configurazione <envar role="rc-item-ui">verbose</envar> impostato a <quote>vero</quote>, in modo che Mercurial stampi un messaggio prima di invocare qualsiasi hook.</para> 16.163 16.164 <sect2 id="sec:hook:lang"> 16.165 <title>Scegliere la modalità di esecuzione del vostro hook</title> 16.166 16.167 - <para id="x_21f">Potete implementare un hook come un normale programma&emdash;tipicamente uno script di shell&emdash;o come una funzione Python che viene eseguita nell'ambito del processo Mercurial.</para> 16.168 + <para id="x_21f">Potete implementare un hook come un normale programma&emdash;tipicamente uno script di shell&emdash;o come una funzione Python che viene eseguita nell’ambito del processo Mercurial.</para> 16.169 16.170 <para id="x_220">Implementare un hook come programma esterno ha il vantaggio di non richiedere alcuna conoscenza del funzionamento interno di Mercurial. Potete invocare i normali comandi Mercurial per ottenere tutte le informazioni aggiuntive di cui avete bisogno. Lo svantaggio è che gli hook esterni sono più lenti rispetto agli hook interni.</para> 16.171 16.172 @@ -159,42 +159,42 @@ 16.173 <sect2 id="sec:hook:param"> 16.174 <title>I parametri di hook</title> 16.175 16.176 - <para id="x_223">Mercurial invoca ogni hook con un insieme di parametri ben definito. In Python, un parametro viene passato come un argomento con nome alla vostra funzione di hook. Per un programma esterno, un parametro viene passato come una variabile d'ambiente.</para> 16.177 - 16.178 - <para id="x_224">I nomi e i valori dei parametri specifici di un hook saranno gli stessi sia per gli hook implementati in Python sia per quelli realizzati come script di shell. Un parametro booleano sarà rappresentato come un valore booleano in Python, ma come una variabile d'ambiente con valore numerico 1 (per <quote>vero</quote>) o 0 (per <quote>falso</quote>) per un hook esterno. Se il nome di un parametro di hook è <literal>foo</literal>, anche l'argomento con nome per un hook Python sarà chiamato <literal>foo</literal>, mentre la variabile d'ambiente per un hook esterno sarà chiamata <literal>HG_FOO</literal>.</para> 16.179 + <para id="x_223">Mercurial invoca ogni hook con un insieme di parametri ben definito. In Python, un parametro viene passato come un argomento con nome alla vostra funzione di hook. Per un programma esterno, un parametro viene passato come una variabile d’ambiente.</para> 16.180 + 16.181 + <para id="x_224">I nomi e i valori dei parametri specifici di un hook saranno gli stessi sia per gli hook implementati in Python sia per quelli realizzati come script di shell. Un parametro booleano sarà rappresentato come un valore booleano in Python, ma come una variabile d’ambiente con valore numerico 1 (per <quote>vero</quote>) o 0 (per <quote>falso</quote>) per un hook esterno. Se il nome di un parametro di hook è <literal>foo</literal>, anche l’argomento con nome per un hook Python sarà chiamato <literal>foo</literal>, mentre la variabile d’ambiente per un hook esterno sarà chiamata <literal>HG_FOO</literal>.</para> 16.182 </sect2> 16.183 16.184 <sect2> 16.185 <title>I valori di ritorno degli hook e il controllo delle attività</title> 16.186 16.187 - <para id="x_225">Un hook che viene eseguito con successo deve terminare con uno stato uguale a zero se è esterno, o restituire il valore booleano <quote>falso</quote> se è interno. Il fallimento viene indicato con uno stato di terminazione diverso da zero per un hook esterno, o dal valore booleano <quote>vero</quote> per un hook interno. Se un hook interno solleva un'eccezione, l'hook si considera fallito.</para> 16.188 - 16.189 - <para id="x_226">Per un hook che controlla se un'attività può procedere, zero o falso significano <quote>concesso</quote>, mentre un numero diverso da zero, vero, o un'eccezione significano <quote>negato</quote>.</para> 16.190 + <para id="x_225">Un hook che viene eseguito con successo deve terminare con uno stato uguale a zero se è esterno, o restituire il valore booleano <quote>falso</quote> se è interno. Il fallimento viene indicato con uno stato di terminazione diverso da zero per un hook esterno, o dal valore booleano <quote>vero</quote> per un hook interno. Se un hook interno solleva un’eccezione, l’hook si considera fallito.</para> 16.191 + 16.192 + <para id="x_226">Per un hook che controlla se un’attività può procedere, zero o falso significano <quote>concesso</quote>, mentre un numero diverso da zero, vero, o un’eccezione significano <quote>negato</quote>.</para> 16.193 </sect2> 16.194 16.195 <sect2> 16.196 <title>Scrivere un hook esterno</title> 16.197 16.198 - <para id="x_227">Quando definite un hook esterno nel vostro file <filename role="special">~/.hgrc</filename> e l'hook viene invocato, il suo valore viene passato alla vostra shell, che lo interpreta. Questo significa che potete usare i normali costrutti di shell nel corpo dell'hook.</para> 16.199 + <para id="x_227">Quando definite un hook esterno nel vostro file <filename role="special">~/.hgrc</filename> e l’hook viene invocato, il suo valore viene passato alla vostra shell, che lo interpreta. Questo significa che potete usare i normali costrutti di shell nel corpo dell’hook.</para> 16.200 16.201 <para id="x_228">Un hook eseguibile viene sempre eseguito con la sua directory corrente impostata alla directory radice del repository.</para> 16.202 16.203 - <para id="x_229">Ogni parametro di hook viene passato come una variabile d'ambiente con il nome in maiuscolo preceduto dalla stringa <quote><literal>HG_</literal></quote>.</para> 16.204 - 16.205 - <para id="x_22a">Con l'eccezione dei parametri di hook, Mercurial non imposta o modifica alcuna variabile d'ambiente quando esegue un hook. Questo è utile da ricordare se state scrivendo un hook globale che potrebbe venire invocato da un certo numero di utenti differenti con differenti variabili d'ambiente impostate. In ambienti multi-utente, non dovreste fare affidamento sul fatto che le variabili d'ambiente abbiano i valori che avete impostato nel vostro ambiente di lavoro durante il collaudo dell'hook.</para> 16.206 + <para id="x_229">Ogni parametro di hook viene passato come una variabile d’ambiente con il nome in maiuscolo preceduto dalla stringa <quote><literal>HG_</literal></quote>.</para> 16.207 + 16.208 + <para id="x_22a">Con l’eccezione dei parametri di hook, Mercurial non imposta o modifica alcuna variabile d’ambiente quando esegue un hook. Questo è utile da ricordare se state scrivendo un hook globale che potrebbe venire invocato da un certo numero di utenti differenti con differenti variabili d’ambiente impostate. In ambienti multi-utente, non dovreste fare affidamento sul fatto che le variabili d’ambiente abbiano i valori che avete impostato nel vostro ambiente di lavoro durante il collaudo dell’hook.</para> 16.209 </sect2> 16.210 16.211 <sect2> 16.212 <title>Dire a Mercurial di usare un hook interno</title> 16.213 16.214 - <para id="x_22b">La sintassi del file <filename role="special">~/.hgrc</filename> per definire un hook interno è leggermente differente da quella per un hook eseguibile. Il valore dell'hook deve cominciare con il testo <quote><literal>python:</literal></quote> e proseguire con il nome completamente qualificato dell'oggetto invocabile da usare come valore dell'hook.</para> 16.215 - 16.216 - <para id="x_22c">Il modulo in cui si trova l'hook viene automaticamente importato quando l'hook viene invocato. Purché il nome del modulo e il valore di <envar>PYTHONPATH</envar> siano corretti, l'importazione dovrebbe <quote>funzionare e basta</quote>.</para> 16.217 + <para id="x_22b">La sintassi del file <filename role="special">~/.hgrc</filename> per definire un hook interno è leggermente differente da quella per un hook eseguibile. Il valore dell’hook deve cominciare con il testo <quote><literal>python:</literal></quote> e proseguire con il nome completamente qualificato dell’oggetto invocabile da usare come valore dell’hook.</para> 16.218 + 16.219 + <para id="x_22c">Il modulo in cui si trova l’hook viene automaticamente importato quando l’hook viene invocato. Purché il nome del modulo e il valore di <envar>PYTHONPATH</envar> siano corretti, l’importazione dovrebbe <quote>funzionare e basta</quote>.</para> 16.220 16.221 <para id="x_22d">Il seguente frammento di un file <filename role="special">~/.hgrc</filename> di esempio illustra la sintassi e il significato delle nozioni appena descritte.</para> 16.222 <programlisting>[hooks] 16.223 commit.esempio = python:miomodulo.sottomodulo.miohook</programlisting> 16.224 - <para id="x_22e">Quando Mercurial esegue l'hook <literal>commit.esempio</literal>, importa <literal>miomodulo.sottomodulo</literal>, cerca l'oggetto invocabile chiamato <literal>miohook</literal> e lo invoca.</para> 16.225 + <para id="x_22e">Quando Mercurial esegue l’hook <literal>commit.esempio</literal>, importa <literal>miomodulo.sottomodulo</literal>, cerca l’oggetto invocabile chiamato <literal>miohook</literal> e lo invoca.</para> 16.226 </sect2> 16.227 16.228 <sect2> 16.229 @@ -203,7 +203,7 @@ 16.230 <para id="x_22f">Il più semplice hook interno non fa nulla, ma illustra la forma base della API degli hook:</para> 16.231 <programlisting>def miohook(ui, repo, **kwargs): 16.232 pass</programlisting> 16.233 - <para id="x_230">Il primo argomento di un hook Python è sempre un oggetto <literal role="py-mod-mercurial.ui">mercurial.ui.ui</literal>. Il secondo è un oggetto repository, al momento sempre un'istanza di <literal role="py-mod-mercurial.localrepo">mercurial.localrepo.localrepository</literal>. Gli altri argomenti con nome seguono questi due argomenti. Quali argomenti con nome vengono passati dipende dall'hook che viene invocato, ma un hook può ignorare gli argomenti di cui non ha bisogno depositandoli in un dizionario di argomenti con nome, come succede con <literal>**kwargs</literal> qui sopra.</para> 16.234 + <para id="x_230">Il primo argomento di un hook Python è sempre un oggetto <literal role="py-mod-mercurial.ui">mercurial.ui.ui</literal>. Il secondo è un oggetto repository, al momento sempre un’istanza di <literal role="py-mod-mercurial.localrepo">mercurial.localrepo.localrepository</literal>. Gli altri argomenti con nome seguono questi due argomenti. Quali argomenti con nome vengono passati dipende dall’hook che viene invocato, ma un hook può ignorare gli argomenti di cui non ha bisogno depositandoli in un dizionario di argomenti con nome, come succede con <literal>**kwargs</literal> qui sopra.</para> 16.235 16.236 </sect2> 16.237 </sect1> 16.238 @@ -213,7 +213,7 @@ 16.239 <sect2> 16.240 <title>Scrivere messaggi di commit significativi</title> 16.241 16.242 - <para id="x_231">È difficile immaginare un messaggio di commit utile che sia anche molto breve. Il semplice hook <literal role="hook">pretxncommit</literal> dell'esempio seguente vi impedirà di esguire il commit di un changeset con un messaggio più piccolo di quindici byte.</para> 16.243 + <para id="x_231">È difficile immaginare un messaggio di commit utile che sia anche molto breve. Il semplice hook <literal role="hook">pretxncommit</literal> dell’esempio seguente vi impedirà di esguire il commit di un changeset con un messaggio più piccolo di quindici byte.</para> 16.244 16.245 &interaction.hook.msglen.go; 16.246 </sect2> 16.247 @@ -223,21 +223,21 @@ 16.248 16.249 <para id="x_232">Un uso interessante per un hook relativo ai commit è quello di aiutarvi a scrivere codice più pulito. Un semplice esempio di <quote>codice più pulito</quote> è la regola per cui un cambiamento non dovrebbe aggiungere nessuna nuova riga di testo contenente <quote>spazio bianco in coda</quote>. Lo spazio bianco in coda è composto da una serie di spazi e caratteri di tabulazione alla fine di una riga di testo. Nella maggior parte dei casi, lo spazio bianco in coda non è altro che rumore invisibile e superfluo, ma si rivela occasionalmente problematico e in genere le persone preferiscono sbarazzarsene.</para> 16.250 16.251 - <para id="x_233">Potete usare l'hook <literal role="hook">precommit</literal> o l'hook <literal role="hook">pretxncommit</literal> per scoprire se avete un problema di spazio bianco in coda. Se usate <literal role="hook">precommit</literal>, l'hook non saprà quali file state inserendo, quindi dovrà controllare ogni file modificato nel repository alla ricerca di spazio bianco in coda. Se volete inserire un cambiamento al solo file <filename>foo</filename>, ma il flie <filename>bar</filename> contiene spazio bianco in coda, effettuare un controllo tramite l'hook <literal role="hook">precommit</literal> vi impedirà di eseguire il commit di <filename>foo</filename> a causa dei problemi con <filename>bar</filename>. Questo comportamento non sembra corretto.</para> 16.252 - 16.253 - <para id="x_234">Se doveste scegliere l'hook <literal role="hook">pretxncommit</literal>, il controllo non avverrà fino al momento appena precedente il completamento della transazione di commit. Questo vi consentirà di controllare il problema solo sui file che verranno registrati. Tuttavia, se avete inserito il messaggio di commit interattivamente e l'hook fallisce, la transazione verrà abortita e dovrete riscrivere il messaggio di commit dopo aver corretto lo spazio bianco in coda e invocato ancora <command role="hg-cmd">hg commit</command>.</para> 16.254 + <para id="x_233">Potete usare l’hook <literal role="hook">precommit</literal> o l’hook <literal role="hook">pretxncommit</literal> per scoprire se avete un problema di spazio bianco in coda. Se usate <literal role="hook">precommit</literal>, l’hook non saprà quali file state inserendo, quindi dovrà controllare ogni file modificato nel repository alla ricerca di spazio bianco in coda. Se volete inserire un cambiamento al solo file <filename>foo</filename>, ma il flie <filename>bar</filename> contiene spazio bianco in coda, effettuare un controllo tramite l’hook <literal role="hook">precommit</literal> vi impedirà di eseguire il commit di <filename>foo</filename> a causa dei problemi con <filename>bar</filename>. Questo comportamento non sembra corretto.</para> 16.255 + 16.256 + <para id="x_234">Se doveste scegliere l’hook <literal role="hook">pretxncommit</literal>, il controllo non avverrà fino al momento appena precedente il completamento della transazione di commit. Questo vi consentirà di controllare il problema solo sui file che verranno registrati. Tuttavia, se avete inserito il messaggio di commit interattivamente e l’hook fallisce, la transazione verrà abortita e dovrete riscrivere il messaggio di commit dopo aver corretto lo spazio bianco in coda e invocato ancora <command role="hg-cmd">hg commit</command>.</para> 16.257 16.258 &interaction.ch09-hook.ws.simple; 16.259 16.260 - <para id="x_235">In questo esempio, abbiamo introdotto un semplice hook <literal role="hook">pretxncommit</literal> che controlla lo spazio bianco in coda. Questo hook è breve, ma non molto utile: termina con uno stato di errore se un changeset aggiunge una riga con spazio bianco in coda a un file qualsiasi, ma non stampa alcuna informazione che potrebbe aiutarci a individuare il file o la riga che contiene il problema. L'hook ha anche la piacevole proprietà di non prestare attenzione alle righe non modificate, in quanto solo le righe che introducono nuovo spazio bianco in coda causano problemi.</para> 16.261 + <para id="x_235">In questo esempio, abbiamo introdotto un semplice hook <literal role="hook">pretxncommit</literal> che controlla lo spazio bianco in coda. Questo hook è breve, ma non molto utile: termina con uno stato di errore se un changeset aggiunge una riga con spazio bianco in coda a un file qualsiasi, ma non stampa alcuna informazione che potrebbe aiutarci a individuare il file o la riga che contiene il problema. L’hook ha anche la piacevole proprietà di non prestare attenzione alle righe non modificate, in quanto solo le righe che introducono nuovo spazio bianco in coda causano problemi.</para> 16.262 16.263 &ch09-check_whitespace.py.lst; 16.264 16.265 - <para id="x_236">Questa versione è molto più complessa, ma anche molto più utile. Analizza un diff unificato per vedere se una qualsiasi riga aggiunge spazio bianco in coda e stampa il nome del file e il numero della riga di ogni occorrenza di questo tipo. In più, se il cambiamento aggiunge spazio bianco in coda, questo hook salva il messaggio di commit e stampa il nome del file salvato prima di uscire e dire a Mercurial di abortire la transazione, in modo che, dopo aver corretto il problema, possiate usare l'opzione <option role="hg-opt-commit">-l nomefile</option> del comando <command role="hg-cmd">hg commit</command> per riutilizzare il messaggio di commit salvato.</para> 16.266 + <para id="x_236">Questa versione è molto più complessa, ma anche molto più utile. Analizza un diff unificato per vedere se una qualsiasi riga aggiunge spazio bianco in coda e stampa il nome del file e il numero della riga di ogni occorrenza di questo tipo. In più, se il cambiamento aggiunge spazio bianco in coda, questo hook salva il messaggio di commit e stampa il nome del file salvato prima di uscire e dire a Mercurial di abortire la transazione, in modo che, dopo aver corretto il problema, possiate usare l’opzione <option role="hg-opt-commit">-l nomefile</option> del comando <command role="hg-cmd">hg commit</command> per riutilizzare il messaggio di commit salvato.</para> 16.267 16.268 &interaction.ch09-hook.ws.better; 16.269 16.270 - <para id="x_237">Come ultima nota a margine, osservate in questo esempio l'uso della funzione di modifica sul posto di <command>sed</command> per eliminare lo spazio bianco in coda da un file. Questo impiego è sufficientemente conciso e utile che lo riprodurrò qui di seguito (usando <command>perl</command> per sicurezza).</para> 16.271 + <para id="x_237">Come ultima nota a margine, osservate in questo esempio l’uso della funzione di modifica sul posto di <command>sed</command> per eliminare lo spazio bianco in coda da un file. Questo impiego è sufficientemente conciso e utile che lo riprodurrò qui di seguito (usando <command>perl</command> per sicurezza).</para> 16.272 <programlisting>perl -pi -e 's,[ \t]+$,,' nomefile</programlisting> 16.273 16.274 </sect2> 16.275 @@ -245,29 +245,29 @@ 16.276 <sect1> 16.277 <title>Hook inclusi</title> 16.278 16.279 - <para id="x_238">Mercurial viene distribuito con diversi hook inclusi che potete trovare nella directory <filename class="directory">hgext</filename> dell'albero dei sorgenti di Mercurial. Se state usando un pacchetto precompilato di Mercurial, gli hook si trovano nella directory <filename class="directory">hgext</filename> posizionata ovunque il vostro pacchetto abbia installato Mercurial.</para> 16.280 + <para id="x_238">Mercurial viene distribuito con diversi hook inclusi che potete trovare nella directory <filename class="directory">hgext</filename> dell’albero dei sorgenti di Mercurial. Se state usando un pacchetto precompilato di Mercurial, gli hook si trovano nella directory <filename class="directory">hgext</filename> posizionata ovunque il vostro pacchetto abbia installato Mercurial.</para> 16.281 16.282 <sect2> 16.283 <title><literal role="hg-ext">acl</literal>&emdash;controllo di accesso per parti di un repository</title> 16.284 16.285 - <para id="x_239">L'estensione <literal role="hg-ext">acl</literal> vi permette di controllare quali utenti remoti hanno il permesso di trasmettere changeset verso un server attraverso la rete. Potete proteggere qualsiasi porzione di un repository (compreso l'intero repository) in modo che uno specifico utente remoto possa trasmettere solo cambiamenti che non influenzano le parti protette.</para> 16.286 - 16.287 - <para id="x_23a">Questa estensione implementa il controllo di accesso sulla base dell'identità dell'utente che effettua la trasmissione, <emphasis>non</emphasis> di chi ha eseguito il commit dei changeset che vengono trasferiti. Ha senso usare questo hook solo se avete un ambiente server protetto che autentica gli utenti remoti e volete essere sicuri che solo specifici utenti possano trasmettere cambiamenti a quel server.</para> 16.288 + <para id="x_239">L’estensione <literal role="hg-ext">acl</literal> vi permette di controllare quali utenti remoti hanno il permesso di trasmettere changeset verso un server attraverso la rete. Potete proteggere qualsiasi porzione di un repository (compreso l’intero repository) in modo che uno specifico utente remoto possa trasmettere solo cambiamenti che non influenzano le parti protette.</para> 16.289 + 16.290 + <para id="x_23a">Questa estensione implementa il controllo di accesso sulla base dell’identità dell’utente che effettua la trasmissione, <emphasis>non</emphasis> di chi ha eseguito il commit dei changeset che vengono trasferiti. Ha senso usare questo hook solo se avete un ambiente server protetto che autentica gli utenti remoti e volete essere sicuri che solo specifici utenti possano trasmettere cambiamenti a quel server.</para> 16.291 16.292 <sect3> 16.293 - <title>Configurare l'hook <literal role="hook">acl</literal></title> 16.294 - 16.295 - <para id="x_23b">Per gestire i cambiamenti in entrata, l'hook <literal role="hg-ext">acl</literal> deve essere usato come un hook <literal role="hook">pretxnchangegroup</literal>. Questo vi permette di vedere quali file vengono modificati da ogni changeset in entrata e di abortire un gruppo di changeset se modifica qualche file <quote>proibito</quote>. Ecco un esempio di come attivare l'hook:</para> 16.296 + <title>Configurare l’hook <literal role="hook">acl</literal></title> 16.297 + 16.298 + <para id="x_23b">Per gestire i cambiamenti in entrata, l’hook <literal role="hg-ext">acl</literal> deve essere usato come un hook <literal role="hook">pretxnchangegroup</literal>. Questo vi permette di vedere quali file vengono modificati da ogni changeset in entrata e di abortire un gruppo di changeset se modifica qualche file <quote>proibito</quote>. Ecco un esempio di come attivare l’hook:</para> 16.299 <programlisting>[hooks] 16.300 pretxnchangegroup.acl = python:hgext.acl.hook</programlisting> 16.301 16.302 - <para id="x_23c">L'estensione <literal role="hg-ext">acl</literal> si configura usando tre sezioni.</para> 16.303 - 16.304 - <para id="x_23d">La sezione <literal role="rc-acl">acl</literal> contiene solo la voce <envar role="rc-item-acl">sources</envar>, che elenca le modalità di provenienza dei cambiamenti in entrata a cui l'hook deve fare attenzione. Di solito, non avrete bisogno di configurare questa sezione.</para> 16.305 + <para id="x_23c">L’estensione <literal role="hg-ext">acl</literal> si configura usando tre sezioni.</para> 16.306 + 16.307 + <para id="x_23d">La sezione <literal role="rc-acl">acl</literal> contiene solo la voce <envar role="rc-item-acl">sources</envar>, che elenca le modalità di provenienza dei cambiamenti in entrata a cui l’hook deve fare attenzione. Di solito, non avrete bisogno di configurare questa sezione.</para> 16.308 <itemizedlist> 16.309 - <listitem><para id="x_23e"><envar role="rc-item-acl">serve</envar>: controlla i changeset in entrata che arrivano da un repository remoto via HTTP o ssh. Questo è il valore predefinito di <envar role="rc-item-acl">sources</envar> e di solito è l'unica impostazione di cui avrete bisogno per questo elemento di configurazione.</para> 16.310 - </listitem> 16.311 - <listitem><para id="x_23f"><envar role="rc-item-acl">pull</envar>: controlla i changeset in entrata che arrivano attraverso un'estrazione da un repository locale.</para> 16.312 + <listitem><para id="x_23e"><envar role="rc-item-acl">serve</envar>: controlla i changeset in entrata che arrivano da un repository remoto via HTTP o ssh. Questo è il valore predefinito di <envar role="rc-item-acl">sources</envar> e di solito è l’unica impostazione di cui avrete bisogno per questo elemento di configurazione.</para> 16.313 + </listitem> 16.314 + <listitem><para id="x_23f"><envar role="rc-item-acl">pull</envar>: controlla i changeset in entrata che arrivano attraverso un’estrazione da un repository locale.</para> 16.315 </listitem> 16.316 <listitem><para id="x_240"><envar role="rc-item-acl">push</envar>: controlla i cambiamenti in entrata che arrivano attraverso una trasmissione da un repository locale.</para> 16.317 </listitem> 16.318 @@ -280,7 +280,7 @@ 16.319 16.320 <para id="x_244">La sintassi per le sezioni <literal role="rc-acl.allow">acl.allow</literal> e <literal role="rc-acl.deny">acl.deny</literal> è la stessa. Sulla sinistra di ogni voce si trova un pattern di tipo glob che corrisponde a file e directory relativi alla radice del repository, sulla destra si trova un nome utente.</para> 16.321 16.322 - <para id="x_245">Nell'esempio seguente, l'utente <literal>manualista</literal> può trasmettere cambiamenti solo al sottoalbero <filename class="directory">doc</filename> del repository, mentre l'utente <literal>stagista</literal> può trasmettere cambiamenti a qualsiasi file o directory tranne <filename class="directory">sorgenti/sensibili</filename>. 16.323 + <para id="x_245">Nell’esempio seguente, l’utente <literal>manualista</literal> può trasmettere cambiamenti solo al sottoalbero <filename class="directory">doc</filename> del repository, mentre l’utente <literal>stagista</literal> può trasmettere cambiamenti a qualsiasi file o directory tranne <filename class="directory">sorgenti/sensibili</filename>. 16.324 </para> 16.325 <programlisting>[acl.allow] 16.326 doc/** = manualista 16.327 @@ -291,11 +291,11 @@ 16.328 <sect3> 16.329 <title>Collaudo e risoluzione dei problemi</title> 16.330 16.331 - <para id="x_246">Se volete collaudare l'hook <literal role="hg-ext">acl</literal>, eseguitelo abilitando le informazioni di debug di Mercurial. Dato che probabilmente lo eseguirete su un server dove non è conveniente (e talvolta nemmeno possibile) passare l'opzione <option role="hg-opt-global">--debug</option>, non dimenticatevi che potete abilitare le informazioni di debug nel vostro file <filename role="special">~/.hgrc</filename>: 16.332 + <para id="x_246">Se volete collaudare l’hook <literal role="hg-ext">acl</literal>, eseguitelo abilitando le informazioni di debug di Mercurial. Dato che probabilmente lo eseguirete su un server dove non è conveniente (e talvolta nemmeno possibile) passare l’opzione <option role="hg-opt-global">--debug</option>, non dimenticatevi che potete abilitare le informazioni di debug nel vostro file <filename role="special">~/.hgrc</filename>: 16.333 </para> 16.334 <programlisting>[ui] 16.335 debug = true</programlisting> 16.336 - <para id="x_247">Con questa opzione abilitata, l'hook <literal role="hg-ext">acl</literal> stamperà abbastanza informazioni da permettervi di capire perché sta consentendo o vietando le trasmissioni da specifici utenti.</para> 16.337 + <para id="x_247">Con questa opzione abilitata, l’hook <literal role="hg-ext">acl</literal> stamperà abbastanza informazioni da permettervi di capire perché sta consentendo o vietando le trasmissioni da specifici utenti.</para> 16.338 16.339 </sect3> 16.340 </sect2> 16.341 @@ -304,33 +304,33 @@ 16.342 <title><literal 16.343 role="hg-ext">bugzilla</literal>&emdash;integrazione con Bugzilla</title> 16.344 16.345 - <para id="x_248">L'estensione <literal role="hg-ext">bugzilla</literal> aggiunge un commento a un bug su Bugzilla ogni volta che trova un riferimento all'identificatore di quel bug in un messaggio di commit. Potete installare questo hook su un server condiviso, in modo che l'hook venga eseguito ogni volta che un utente remoto trasmette i cambiamenti a quel server.</para> 16.346 - 16.347 - <para id="x_249">L'hook aggiunge al bug un commento che somiglia a questo (potete configurare i contenuti del commento, come vedrete fra un attimo):</para> 16.348 + <para id="x_248">L’estensione <literal role="hg-ext">bugzilla</literal> aggiunge un commento a un bug su Bugzilla ogni volta che trova un riferimento all’identificatore di quel bug in un messaggio di commit. Potete installare questo hook su un server condiviso, in modo che l’hook venga eseguito ogni volta che un utente remoto trasmette i cambiamenti a quel server.</para> 16.349 + 16.350 + <para id="x_249">L’hook aggiunge al bug un commento che somiglia a questo (potete configurare i contenuti del commento, come vedrete fra un attimo):</para> 16.351 <programlisting>Changeset aad8b264143a, creato da Mario Rossi <mario.rossi@example.com> nel repository vattelapesca, 16.352 fa riferimento a questo bug. 16.353 Per i dettagli completi, si veda 16.354 http://hg.example.com/vattelapesca?cmd=changeset;node=aad8b264143a 16.355 Descrizione del changeset: risolto bug 10483 proteggendo il codice da alcuni puntatori NULL.</programlisting> 16.356 - <para id="x_24a">Il valore di questo hook è che automatizza il processo di aggiornamento di un bug ogni volta che un changeset vi fa riferimento. Se lo configurate in maniera adeguata, l'hook faciliterà la navigazione diretta da un bug su Bugzilla a un changeset che si riferisce a quel bug.</para> 16.357 + <para id="x_24a">Il valore di questo hook è che automatizza il processo di aggiornamento di un bug ogni volta che un changeset vi fa riferimento. Se lo configurate in maniera adeguata, l’hook faciliterà la navigazione diretta da un bug su Bugzilla a un changeset che si riferisce a quel bug.</para> 16.358 16.359 <para id="x_24b">Potete usare il codice di questo hook come un punto di partenza per ricette più esotiche di integrazione con Bugzilla. Ecco alcune possibilità.</para> 16.360 <itemizedlist> 16.361 - <listitem><para id="x_24c">Richiedere che ogni changeset trasmesso al server abbia un identificatore di bug valido nel proprio messaggio di commit. In questo caso, vorrete configurare l'hook come un hook <literal role="hook">pretxncommit</literal> per consentirgli di rifiutare i cambiamenti che non contengono identificatori di bug.</para> 16.362 - </listitem> 16.363 - <listitem><para id="x_24d">Permettere ai changeset in entrata di modificare automaticamente lo <emphasis>stato</emphasis> di un bug, come pure di aggiungere semplicemente un commento. Per esempio, l'hook potrebbe riconoscere la stringa <quote>risolto bug 31337</quote> come il segnale che indica la necessità di aggiornare lo stato del bug 31337 a <quote>richiede un collaudo</quote>.</para> 16.364 + <listitem><para id="x_24c">Richiedere che ogni changeset trasmesso al server abbia un identificatore di bug valido nel proprio messaggio di commit. In questo caso, vorrete configurare l’hook come un hook <literal role="hook">pretxncommit</literal> per consentirgli di rifiutare i cambiamenti che non contengono identificatori di bug.</para> 16.365 + </listitem> 16.366 + <listitem><para id="x_24d">Permettere ai changeset in entrata di modificare automaticamente lo <emphasis>stato</emphasis> di un bug, come pure di aggiungere semplicemente un commento. Per esempio, l’hook potrebbe riconoscere la stringa <quote>risolto bug 31337</quote> come il segnale che indica la necessità di aggiornare lo stato del bug 31337 a <quote>richiede un collaudo</quote>.</para> 16.367 </listitem></itemizedlist> 16.368 16.369 <sect3 id="sec:hook:bugzilla:config"> 16.370 - <title>Configurare l'hook <literal role="hook">bugzilla</literal></title> 16.371 + <title>Configurare l’hook <literal role="hook">bugzilla</literal></title> 16.372 16.373 <para id="x_24e">Dovreste configurare questo hook nel file <filename role="special">hgrc</filename> del vostro server come un hook <literal role="hook">incoming</literal>, per esempio nel modo seguente:</para> 16.374 <programlisting>[hooks] 16.375 incoming.bugzilla = python:hgext.bugzilla.hook</programlisting> 16.376 16.377 - <para id="x_24f">A causa della natura specializzata dell'hook e dato che Bugzilla non è stato implementato con questo tipo di integrazioni in mente, configurare questo hook è un processo piuttosto complicato.</para> 16.378 - 16.379 - <para id="x_250">Prima di cominciare, dovete installare la libreria di interfaccia Python per MySQL sulla macchina (o le macchine) dove intendete eseguire l'hook. Se non è disponibile sotto forma di pacchetto precompilato per il vostro sistema, potete scaricarla da <citation><xref linkend="bib:mysql"/></citation>. 16.380 + <para id="x_24f">A causa della natura specializzata dell’hook e dato che Bugzilla non è stato implementato con questo tipo di integrazioni in mente, configurare questo hook è un processo piuttosto complicato.</para> 16.381 + 16.382 + <para id="x_250">Prima di cominciare, dovete installare la libreria di interfaccia Python per MySQL sulla macchina (o le macchine) dove intendete eseguire l’hook. Se non è disponibile sotto forma di pacchetto precompilato per il vostro sistema, potete scaricarla da <citation><xref linkend="bib:mysql"/></citation>. 16.383 </para> 16.384 16.385 <para id="x_251">Le informazioni di configurazione per questo hook si trovano nella sezione <literal role="rc-bugzilla">bugzilla</literal> del vostro file <filename role="special">hgrc</filename>. 16.386 @@ -338,31 +338,31 @@ 16.387 <itemizedlist> 16.388 <listitem><para id="x_252"><envar role="rc-item-bugzilla">version</envar>: la versione di Bugzilla installata sul server. Lo schema di database usato da Bugzilla cambia occasionalmente, quindi questo hook deve sapere esattamente quale schema usare.</para> 16.389 </listitem> 16.390 - <listitem><para id="x_253"><envar role="rc-item-bugzilla">host</envar>: il nome della macchina del server MySQL che memorizza i vostri dati per Bugzilla. Il database deve essere configurato per consentire le connessioni da qualunque macchina stia eseguendo l'hook <literal role="hook">bugzilla</literal>. 16.391 + <listitem><para id="x_253"><envar role="rc-item-bugzilla">host</envar>: il nome della macchina del server MySQL che memorizza i vostri dati per Bugzilla. Il database deve essere configurato per consentire le connessioni da qualunque macchina stia eseguendo l’hook <literal role="hook">bugzilla</literal>. 16.392 </para> 16.393 </listitem> 16.394 - <listitem><para id="x_254"><envar role="rc-item-bugzilla">user</envar>: il nome utente con il quale connettersi al server MySQL. Il database deve essere configurato per consentire a questo utente di connettersi da qualunque macchina stia eseguendo l'hook <literal role="hook">bugzilla</literal>. Questo utente deve essere in grado di modificare le tabelle di Bugzilla. Il valore predefinito di questo elemento è <literal>bugs</literal>, che è il nome standard dell'utente Bugzilla in un database MySQL.</para> 16.395 - </listitem> 16.396 - <listitem><para id="x_255"><envar role="rc-item-bugzilla">password</envar>: la password MySQL per l'utente che avete configurato alla voce precedente. Il testo della password viene memorizzato in chiaro, quindi dovreste assicurarvi che utenti non autorizzati non possano leggere il file <filename role="special">~/.hgrc</filename> dove avete inserito questa informazione.</para> 16.397 + <listitem><para id="x_254"><envar role="rc-item-bugzilla">user</envar>: il nome utente con il quale connettersi al server MySQL. Il database deve essere configurato per consentire a questo utente di connettersi da qualunque macchina stia eseguendo l’hook <literal role="hook">bugzilla</literal>. Questo utente deve essere in grado di modificare le tabelle di Bugzilla. Il valore predefinito di questo elemento è <literal>bugs</literal>, che è il nome standard dell’utente Bugzilla in un database MySQL.</para> 16.398 + </listitem> 16.399 + <listitem><para id="x_255"><envar role="rc-item-bugzilla">password</envar>: la password MySQL per l’utente che avete configurato alla voce precedente. Il testo della password viene memorizzato in chiaro, quindi dovreste assicurarvi che utenti non autorizzati non possano leggere il file <filename role="special">~/.hgrc</filename> dove avete inserito questa informazione.</para> 16.400 </listitem> 16.401 <listitem><para id="x_256"><envar role="rc-item-bugzilla">db</envar>: il nome del database Bugzilla sul server MySQL. Il valore predefinito di questo elemento è <literal>bugs</literal>, che è il nome standard del database MySQL dove Bugzilla memorizza i propri dati.</para> 16.402 </listitem> 16.403 - <listitem><para id="x_257"><envar role="rc-item-bugzilla">notify</envar>: se volete che Bugzilla spedisca un'email di notifica agli interessati dopo che questo hook ha aggiunto un commento a un bug, è necessario che questo hook esegua un comando ogni volta che aggiorna il database. Il comando da eseguire dipende da dove avete installato Bugzilla, ma tipicamente somiglierà al seguente, se avete installato Bugzilla in <filename class="directory">/var/www/html/bugzilla</filename>:</para> 16.404 + <listitem><para id="x_257"><envar role="rc-item-bugzilla">notify</envar>: se volete che Bugzilla spedisca un’email di notifica agli interessati dopo che questo hook ha aggiunto un commento a un bug, è necessario che questo hook esegua un comando ogni volta che aggiorna il database. Il comando da eseguire dipende da dove avete installato Bugzilla, ma tipicamente somiglierà al seguente, se avete installato Bugzilla in <filename class="directory">/var/www/html/bugzilla</filename>:</para> 16.405 <programlisting>cd /var/www/html/bugzilla && 16.406 ./processmail %s nessuno@example.com</programlisting> 16.407 - <para id="x_258">Il programma <literal>processmail</literal> di Bugzilla si aspetta che gli vengano passati un identificatore di bug (l'hook sostituisce <quote><literal>%s</literal></quote> con l'identificatore di bug) e un indirizzo email. Si aspetta anche di essere in grado di scrivere su alcuni file nella directory in cui viene eseguito. Se Bugzilla e questo hook non sono installati sulla stessa macchina, dovrete trovare un modo per eseguire <literal>processmail</literal> sul server dove Bugzilla è installato.</para> 16.408 + <para id="x_258">Il programma <literal>processmail</literal> di Bugzilla si aspetta che gli vengano passati un identificatore di bug (l’hook sostituisce <quote><literal>%s</literal></quote> con l’identificatore di bug) e un indirizzo email. Si aspetta anche di essere in grado di scrivere su alcuni file nella directory in cui viene eseguito. Se Bugzilla e questo hook non sono installati sulla stessa macchina, dovrete trovare un modo per eseguire <literal>processmail</literal> sul server dove Bugzilla è installato.</para> 16.409 </listitem></itemizedlist> 16.410 16.411 </sect3> 16.412 <sect3> 16.413 <title>Correlare i nomi utente Mercurial ai nomi utente Bugzilla</title> 16.414 16.415 - <para id="x_259">Per default, l'hook <literal role="hg-ext">bugzilla</literal> prova a utilizzare l'indirizzo email di chi ha eseguito il commit del changeset come il nome utente Bugzilla con cui aggiornare un bug. Se questa impostazione non vi soddisfa, potete correlare gli indirizzi email degli utenti Mercurial ai nomi utente Bugzilla tramite una sezione <literal role="rc-usermap">usermap</literal>.</para> 16.416 + <para id="x_259">Per default, l’hook <literal role="hg-ext">bugzilla</literal> prova a utilizzare l’indirizzo email di chi ha eseguito il commit del changeset come il nome utente Bugzilla con cui aggiornare un bug. Se questa impostazione non vi soddisfa, potete correlare gli indirizzi email degli utenti Mercurial ai nomi utente Bugzilla tramite una sezione <literal role="rc-usermap">usermap</literal>.</para> 16.417 16.418 <para id="x_25a">Ogni elemento nella sezione <literal role="rc-usermap">usermap</literal> contiene un indirizzo email sulla sinistra e un nome utente Bugzilla sulla destra.</para> 16.419 <programlisting>[usermap] 16.420 maria.bianchi@example.com = maria</programlisting> 16.421 - <para id="x_25b">Potete tenere i dati della sezione <literal role="rc-usermap">usermap</literal> in un normale file <filename role="special">hgrc</filename>, oppure dire all'hook <literal role="hg-ext">bugzilla</literal> di leggere le informazioni da un file <filename>usermap</filename> esterno. In quest'ultimo caso, potete memorizzare i dati del file <filename>usermap</filename> separatamente in un repository modificabile dall'utente, per esempio. Questo vi permette di dare ai vostri utenti la possibilità di mantenere le proprie voci nella sezione <envar role="rc-item-bugzilla">usermap</envar>. Il file <filename role="special">hgrc</filename> principale potrebbe somigliare a questo:</para> 16.422 + <para id="x_25b">Potete tenere i dati della sezione <literal role="rc-usermap">usermap</literal> in un normale file <filename role="special">hgrc</filename>, oppure dire all’hook <literal role="hg-ext">bugzilla</literal> di leggere le informazioni da un file <filename>usermap</filename> esterno. In quest’ultimo caso, potete memorizzare i dati del file <filename>usermap</filename> separatamente in un repository modificabile dall’utente, per esempio. Questo vi permette di dare ai vostri utenti la possibilità di mantenere le proprie voci nella sezione <envar role="rc-item-bugzilla">usermap</envar>. Il file <filename role="special">hgrc</filename> principale potrebbe somigliare a questo:</para> 16.423 <programlisting># il normale file hgrc fa riferimento a un file di correlazioni esterno 16.424 [bugzilla] 16.425 usermap = /home/hg/repos/datiutente/bugzilla-usermap.conf</programlisting> 16.426 @@ -377,16 +377,16 @@ 16.427 16.428 <para id="x_25d">Potete configurare il testo che questo hook aggiunge come commento specificandolo sotto forma di template Mercurial. Diverse voci del file <filename role="special">hgrc</filename> (sempre nella sezione <literal role="rc-bugzilla">bugzilla</literal>) controllano questo comportamento.</para> 16.429 <itemizedlist> 16.430 - <listitem><para id="x_25e"><literal>strip</literal>: il numero di parti iniziali da eliminare dal percorso di un repository per costruire un percorso parziale da usare in un URL. Per esempio, se i repository sul vostro server si trovano nella directory <filename class="directory">/home/hg/repos</filename>, e voi avete un repository il cui percorso è <filename class="directory">/home/hg/repos/app/test</filename>, allora impostando <literal>strip</literal> a <literal>4</literal> otterrete il percorso parziale <filename class="directory">app/test</filename>. L'hook renderà disponibile questo percorso parziale con il nome <literal>webroot</literal> durante l'espansione di un template.</para> 16.431 - </listitem> 16.432 - <listitem><para id="x_25f"><literal>template</literal>: il testo del template da usare. In aggiunta alle solite variabili relative ai changeset, questo template può usare <literal>hgweb</literal> (il valore dell'elemento di configurazione <literal>hgweb</literal> menzionato in precedenza) e <literal>webroot</literal> (il percorso costruito usando l'elemento <literal>strip</literal> appena descritto).</para> 16.433 + <listitem><para id="x_25e"><literal>strip</literal>: il numero di parti iniziali da eliminare dal percorso di un repository per costruire un percorso parziale da usare in un URL. Per esempio, se i repository sul vostro server si trovano nella directory <filename class="directory">/home/hg/repos</filename>, e voi avete un repository il cui percorso è <filename class="directory">/home/hg/repos/app/test</filename>, allora impostando <literal>strip</literal> a <literal>4</literal> otterrete il percorso parziale <filename class="directory">app/test</filename>. L’hook renderà disponibile questo percorso parziale con il nome <literal>webroot</literal> durante l’espansione di un template.</para> 16.434 + </listitem> 16.435 + <listitem><para id="x_25f"><literal>template</literal>: il testo del template da usare. In aggiunta alle solite variabili relative ai changeset, questo template può usare <literal>hgweb</literal> (il valore dell’elemento di configurazione <literal>hgweb</literal> menzionato in precedenza) e <literal>webroot</literal> (il percorso costruito usando l’elemento <literal>strip</literal> appena descritto).</para> 16.436 </listitem></itemizedlist> 16.437 16.438 - <para id="x_260">In più, potete aggiungere un elemento <envar role="rc-item-web">baseurl</envar> alla sezione <literal role="rc-web">web</literal> del vostro file <filename role="special">hgrc</filename>. L'hook <literal role="hg-ext">bugzilla</literal> lo renderà disponibile durante l'espansione di un template, come la stringa di base da usare nel costruire un URL che permetterà agli utenti di navigare da un commento Bugzilla verso un changeset correlato. Ecco un esempio di come usare questo elemento:</para> 16.439 + <para id="x_260">In più, potete aggiungere un elemento <envar role="rc-item-web">baseurl</envar> alla sezione <literal role="rc-web">web</literal> del vostro file <filename role="special">hgrc</filename>. L’hook <literal role="hg-ext">bugzilla</literal> lo renderà disponibile durante l’espansione di un template, come la stringa di base da usare nel costruire un URL che permetterà agli utenti di navigare da un commento Bugzilla verso un changeset correlato. Ecco un esempio di come usare questo elemento:</para> 16.440 <programlisting>[web] 16.441 baseurl = http://hg.example.com/</programlisting> 16.442 16.443 - <para id="x_261">Ecco un esempio dell'insieme di informazioni di configurazione da usare per l'hook <literal role="hg-ext">bugzilla</literal>.</para> 16.444 + <para id="x_261">Ecco un esempio dell’insieme di informazioni di configurazione da usare per l’hook <literal role="hg-ext">bugzilla</literal>.</para> 16.445 16.446 &ch10-bugzilla-config.lst; 16.447 16.448 @@ -394,23 +394,23 @@ 16.449 <sect3> 16.450 <title>Collaudo e risoluzione dei problemi</title> 16.451 16.452 - <para id="x_262">I problemi più comuni con la configurazione dell'hook <literal role="hg-ext">bugzilla</literal> sono relativi all'esecuzione dello script <filename>processmail</filename> di Bugzilla e alla correlazione tra nomi utente Mercurial e nomi utente Bugzilla.</para> 16.453 - 16.454 - <para id="x_263">Se ricordate quanto detto nella <xref linkend="sec:hook:bugzilla:config"/>, l'utente che esegue il processo Mercurial sul server è anche quello che eseguirà lo script <filename>processmail</filename>. Questo script talvolta chiederà a Bugzilla di modificare i file nella sua directory di configurazione, e di solito i file di configurazione di Bugzilla sono proprietà dell'utente che esegue il processo del vostro server web.</para> 16.455 - 16.456 - <para id="x_264">Potete far eseguire <filename>processmail</filename> con un'identità utente appropriata tramite il comando <command>sudo</command>. Ecco una voce di esempio da un file <filename>sudoers</filename>.</para> 16.457 + <para id="x_262">I problemi più comuni con la configurazione dell’hook <literal role="hg-ext">bugzilla</literal> sono relativi all’esecuzione dello script <filename>processmail</filename> di Bugzilla e alla correlazione tra nomi utente Mercurial e nomi utente Bugzilla.</para> 16.458 + 16.459 + <para id="x_263">Se ricordate quanto detto nella <xref linkend="sec:hook:bugzilla:config"/>, l’utente che esegue il processo Mercurial sul server è anche quello che eseguirà lo script <filename>processmail</filename>. Questo script talvolta chiederà a Bugzilla di modificare i file nella sua directory di configurazione, e di solito i file di configurazione di Bugzilla sono proprietà dell’utente che esegue il processo del vostro server web.</para> 16.460 + 16.461 + <para id="x_264">Potete far eseguire <filename>processmail</filename> con un’identità utente appropriata tramite il comando <command>sudo</command>. Ecco una voce di esempio da un file <filename>sudoers</filename>.</para> 16.462 <programlisting>hg_user = (httpd_user) 16.463 NOPASSWD: /var/www/html/bugzilla/processmail-wrapper %s</programlisting> 16.464 - <para id="x_265">Questo consente all'utente <literal>hg_user</literal> di eseguire il programma <filename>processmail-wrapper</filename> sotto l'identità dell'utente <literal>httpd_user</literal>.</para> 16.465 + <para id="x_265">Questo consente all’utente <literal>hg_user</literal> di eseguire il programma <filename>processmail-wrapper</filename> sotto l’identità dell’utente <literal>httpd_user</literal>.</para> 16.466 16.467 <para id="x_266">Questa invocazione indiretta attraverso uno script che funge da involucro è necessaria, perché <filename>processmail</filename> si aspetta di venire eseguito con la propria directory corrente impostata al percorso di installazione di Bugzilla, ma non è possibile specificare questo vincolo in un file <filename>sudoers</filename>. Il contenuto dello script involucro è semplice:</para> 16.468 <programlisting>#!/bin/sh 16.469 cd `dirname $0` && ./processmail "$1" nessuno@example.com</programlisting> 16.470 - <para id="x_267">Non sembra che l'indirizzo email passato a <filename>processmail</filename> abbia importanza.</para> 16.471 - 16.472 - <para id="x_268">Se la vostra sezione <literal role="rc-usermap">usermap</literal> non è impostata correttamente, gli utenti vedranno un messaggio di errore stampato dall'hook <literal role="hg-ext">bugzilla</literal> al momento di trasmettere i cambiamenti al server. Il messaggio di errore somiglierà al seguente:</para> 16.473 + <para id="x_267">Non sembra che l’indirizzo email passato a <filename>processmail</filename> abbia importanza.</para> 16.474 + 16.475 + <para id="x_268">Se la vostra sezione <literal role="rc-usermap">usermap</literal> non è impostata correttamente, gli utenti vedranno un messaggio di errore stampato dall’hook <literal role="hg-ext">bugzilla</literal> al momento di trasmettere i cambiamenti al server. Il messaggio di errore somiglierà al seguente:</para> 16.476 <programlisting>impossibile trovare un nome utente bugzilla per mario.rossi@example.com</programlisting> 16.477 - <para id="x_269">Questo significa che l'indirizzo email dell'utente Mercurial, <literal>mario.rossi@example.com</literal>, non è un nome utente Bugzilla valido, né possiede una voce nella vostra sezione <literal role="rc-usermap">usermap</literal> che lo metta in relazione con un nome utente Bugzilla valido.</para> 16.478 + <para id="x_269">Questo significa che l’indirizzo email dell’utente Mercurial, <literal>mario.rossi@example.com</literal>, non è un nome utente Bugzilla valido, né possiede una voce nella vostra sezione <literal role="rc-usermap">usermap</literal> che lo metta in relazione con un nome utente Bugzilla valido.</para> 16.479 16.480 </sect3> 16.481 </sect2> 16.482 @@ -418,16 +418,16 @@ 16.483 <sect2> 16.484 <title><literal role="hg-ext">notify</literal>&emdash;inviare notifiche via email</title> 16.485 16.486 - <para id="x_26a">Sebbene il server web predefinito di Mercurial fornisca i feed RSS dei cambiamenti per ogni repository, molte persone preferiscono ricevere le notifiche dei cambiamenti via email. L'hook <literal role="hg-ext">notify</literal> vi permette di inviare notifiche a un insieme di indirizzi email ogni volta che arrivano changeset a cui quelle persone sono interessate.</para> 16.487 - 16.488 - <para id="x_26b">Come l'hook <literal role="hg-ext">bugzilla</literal>, anche l'hook <literal role="hg-ext">notify</literal> è guidato da un template, in modo che possiate personalizzare il contenuto dei messaggi di notifica inviati.</para> 16.489 - 16.490 - <para id="x_26c">Per default, l'hook <literal role="hg-ext">notify</literal> include un diff di ogni changeset che spedisce, ma potete limitare le dimensioni del diff oppure disattivarlo interamente. L'inclusione del diff è utile per consentire agli interessati di revisionare i cambiamenti immediatamente piuttosto che obbligarli a cliccare per seguire un URL.</para> 16.491 + <para id="x_26a">Sebbene il server web predefinito di Mercurial fornisca i feed RSS dei cambiamenti per ogni repository, molte persone preferiscono ricevere le notifiche dei cambiamenti via email. L’hook <literal role="hg-ext">notify</literal> vi permette di inviare notifiche a un insieme di indirizzi email ogni volta che arrivano changeset a cui quelle persone sono interessate.</para> 16.492 + 16.493 + <para id="x_26b">Come l’hook <literal role="hg-ext">bugzilla</literal>, anche l’hook <literal role="hg-ext">notify</literal> è guidato da un template, in modo che possiate personalizzare il contenuto dei messaggi di notifica inviati.</para> 16.494 + 16.495 + <para id="x_26c">Per default, l’hook <literal role="hg-ext">notify</literal> include un diff di ogni changeset che spedisce, ma potete limitare le dimensioni del diff oppure disattivarlo interamente. L’inclusione del diff è utile per consentire agli interessati di revisionare i cambiamenti immediatamente piuttosto che obbligarli a cliccare per seguire un URL.</para> 16.496 16.497 <sect3> 16.498 - <title>Configurare l'hook <literal role="hg-ext">notify</literal></title> 16.499 - 16.500 - <para id="x_26d">Potete impostare l'hook <literal role="hg-ext">notify</literal> in modo che spedisca un messaggio email per ogni changeset in entrata, o uno per ogni gruppo di changeset in entrata (tutti quelli che sono arrivati in una singola estrazione o trasmissione).</para> 16.501 + <title>Configurare l’hook <literal role="hg-ext">notify</literal></title> 16.502 + 16.503 + <para id="x_26d">Potete impostare l’hook <literal role="hg-ext">notify</literal> in modo che spedisca un messaggio email per ogni changeset in entrata, o uno per ogni gruppo di changeset in entrata (tutti quelli che sono arrivati in una singola estrazione o trasmissione).</para> 16.504 <programlisting>[hooks] 16.505 # spedisci un'email per gruppo di cambiamenti 16.506 changegroup.notify = python:hgext.notify.hook 16.507 @@ -449,9 +449,9 @@ 16.508 <listitem><para id="x_274"><envar role="rc-item-notify">sources</envar>: una lista di modalità di provenienza dei changeset da considerare. Questo vi permette di limitare <literal role="hg-ext">notify</literal> in modo che spedisca email riguardanti solo utenti remoti che hanno trasmesso modifiche a questo repository attraverso un server, per esempio. Leggete la <xref linkend="sec:hook:sources"/> per sapere quali modalità potete specificare qui.</para> 16.509 </listitem></itemizedlist> 16.510 16.511 - <para id="x_275">Se impostate l'elemento <envar role="rc-item-web">baseurl</envar> nella sezione <literal role="rc-web">web</literal>, potete usarlo in un template, dove sarà disponibile con il nome <literal>webroot</literal>.</para> 16.512 - 16.513 - <para id="x_276">Ecco un esempio dell'insieme di informazioni di configurazione da usare per l'hook <literal role="hg-ext">notify</literal>.</para> 16.514 + <para id="x_275">Se impostate l’elemento <envar role="rc-item-web">baseurl</envar> nella sezione <literal role="rc-web">web</literal>, potete usarlo in un template, dove sarà disponibile con il nome <literal>webroot</literal>.</para> 16.515 + 16.516 + <para id="x_276">Ecco un esempio dell’insieme di informazioni di configurazione da usare per l’hook <literal role="hg-ext">notify</literal>.</para> 16.517 16.518 &ch10-notify-config.lst; 16.519 16.520 @@ -463,7 +463,7 @@ 16.521 <sect3> 16.522 <title>Collaudo e risoluzione dei problemi</title> 16.523 16.524 - <para id="x_278">Non dimenticate che il comportamento predefinito dell'estensione <literal role="hg-ext">notify</literal> è quello di <emphasis>non spedire alcuna mail</emphasis> fino a quando non lo avete esplicitamente configurato per farlo, impostando <envar role="rc-item-notify">test</envar> a <literal>false</literal>. Fino a quel momento, si limiterà a stampare il messaggio che <emphasis>verrebbe</emphasis> inviato.</para> 16.525 + <para id="x_278">Non dimenticate che il comportamento predefinito dell’estensione <literal role="hg-ext">notify</literal> è quello di <emphasis>non spedire alcuna mail</emphasis> fino a quando non lo avete esplicitamente configurato per farlo, impostando <envar role="rc-item-notify">test</envar> a <literal>false</literal>. Fino a quel momento, si limiterà a stampare il messaggio che <emphasis>verrebbe</emphasis> inviato.</para> 16.526 16.527 </sect3> 16.528 </sect2> 16.529 @@ -477,18 +477,18 @@ 16.530 <para id="x_279">Un hook interno viene invocato con argomenti della forma seguente:</para> 16.531 <programlisting>def miohook(ui, repo, **kwargs): 16.532 pass</programlisting> 16.533 - <para id="x_27a">Il parametro <literal>ui</literal> è un oggetto di tipo <literal role="py-mod-mercurial.ui">mercurial.ui.ui</literal>. Il parametro <literal>repo</literal> è un oggetto di tipo <literal role="py-mod-mercurial.localrepo">mercurial.localrepo.localrepository</literal>. I nomi e i valori dei parametri <literal>**kwargs</literal> dipendono dall'hook coinvolto, ma hanno le seguenti caratteristiche comuni:</para> 16.534 - <itemizedlist> 16.535 - <listitem><para id="x_27b">Se un parametro si chiama <literal>node</literal> o <literal>parentN</literal>, conterrà un identificatore esadecimale di changeset. Per rappresentare l'identificatore di changeset <quote>nullo</quote>, viene usata una stringa vuota invece di una stringa di zeri.</para> 16.536 - </listitem> 16.537 - <listitem><para id="x_27c">Se un parametro si chiama <literal>url</literal>, conterrà l'URL di un repository remoto, nel caso possa essere determinato.</para> 16.538 + <para id="x_27a">Il parametro <literal>ui</literal> è un oggetto di tipo <literal role="py-mod-mercurial.ui">mercurial.ui.ui</literal>. Il parametro <literal>repo</literal> è un oggetto di tipo <literal role="py-mod-mercurial.localrepo">mercurial.localrepo.localrepository</literal>. I nomi e i valori dei parametri <literal>**kwargs</literal> dipendono dall’hook coinvolto, ma hanno le seguenti caratteristiche comuni:</para> 16.539 + <itemizedlist> 16.540 + <listitem><para id="x_27b">Se un parametro si chiama <literal>node</literal> o <literal>parentN</literal>, conterrà un identificatore esadecimale di changeset. Per rappresentare l’identificatore di changeset <quote>nullo</quote>, viene usata una stringa vuota invece di una stringa di zeri.</para> 16.541 + </listitem> 16.542 + <listitem><para id="x_27c">Se un parametro si chiama <literal>url</literal>, conterrà l’URL di un repository remoto, nel caso possa essere determinato.</para> 16.543 </listitem> 16.544 <listitem><para id="x_27d">I parametri con valore booleano vengono rappresentati come oggetti Python di tipo <literal>bool</literal>.</para> 16.545 </listitem></itemizedlist> 16.546 16.547 - <para id="x_27e">Un hook interno viene invocato senza cambiare la directory di lavoro del processo (a differenza degli hook esterni, che vengono eseguiti nella radice del repository). L'hook non deve mai cambiare questa directory, altrimenti causerà il fallimento di tutte le proprie invocazioni alla API di Mercurial.</para> 16.548 - 16.549 - <para id="x_27f">Se un hook restituisce il valore booleano <quote>falso</quote>, si considera terminato con successo. Se restituisce il valore booleano <quote>vero</quote> oppure solleva un'eccezione, si considera fallito. Un modo utile di pensare a questa convenzione di esecuzione è <quote>dimmi se hai fallito</quote>.</para> 16.550 + <para id="x_27e">Un hook interno viene invocato senza cambiare la directory di lavoro del processo (a differenza degli hook esterni, che vengono eseguiti nella radice del repository). L’hook non deve mai cambiare questa directory, altrimenti causerà il fallimento di tutte le proprie invocazioni alla API di Mercurial.</para> 16.551 + 16.552 + <para id="x_27f">Se un hook restituisce il valore booleano <quote>falso</quote>, si considera terminato con successo. Se restituisce il valore booleano <quote>vero</quote> oppure solleva un’eccezione, si considera fallito. Un modo utile di pensare a questa convenzione di esecuzione è <quote>dimmi se hai fallito</quote>.</para> 16.553 16.554 <para id="x_280">Notate che gli identificatori di changeset vengono passati agli hook Python sotto forma di stringhe esadecimali, non degli hash binari che la API Mercurial usa normalmente. Per convertire un hash da esadecimale a binario, usate la funzione <literal>mercurial.node.bin</literal>. 16.555 </para> 16.556 @@ -497,11 +497,11 @@ 16.557 <sect2> 16.558 <title>Esecuzione degli hook esterni</title> 16.559 16.560 - <para id="x_281">Un hook esterno viene passato alla shell dell'utente che sta eseguendo Mercurial e può disporre delle funzionalità di quella shell, come la sostituzione delle variabili e la redirezione dei comandi. L'hook viene eseguito nella directory radice del repository (a differenza degli hook interni, che vengono eseguiti nella stessa directory in cui è stato eseguito Mercurial).</para> 16.561 - 16.562 - <para id="x_282">I parametri di hook sono passati all'hook sotto forma di variabili d'ambiente. Il nome di ogni variabile d'ambiente viene convertito in maiuscolo e fatto precedere dalla stringa <quote><literal>HG_</literal></quote>. Per esempio, se il nome di un parametro è <quote><literal>node</literal></quote>, il nome della variabile d'ambiente che rappresenta quel parametro sarà <quote><literal>HG_NODE</literal></quote>.</para> 16.563 - 16.564 - <para id="x_283">Un parametro booleano è rappresentato come la stringa <quote><literal>1</literal></quote> se è <quote>vero</quote> o <quote><literal>0</literal></quote> se è <quote>falso</quote>. Se una variabile d'ambiente è chiamata <envar>HG_NODE</envar>, <envar>HG_PARENT1</envar>, o <envar>HG_PARENT2</envar>, conterrà un identificatore di changeset rappresentato come una stringa esadecimale. Per rappresentare l'identificatore di changeset <quote>nullo</quote>, viene usata una stringa vuota invece di una stringa di zeri. Se una variabile d'ambiente è chiamata <envar>HG_URL</envar>, conterrà l'URL di un repository remoto, nel caso possa essere determinato.</para> 16.565 + <para id="x_281">Un hook esterno viene passato alla shell dell’utente che sta eseguendo Mercurial e può disporre delle funzionalità di quella shell, come la sostituzione delle variabili e la redirezione dei comandi. L’hook viene eseguito nella directory radice del repository (a differenza degli hook interni, che vengono eseguiti nella stessa directory in cui è stato eseguito Mercurial).</para> 16.566 + 16.567 + <para id="x_282">I parametri di hook sono passati all’hook sotto forma di variabili d’ambiente. Il nome di ogni variabile d’ambiente viene convertito in maiuscolo e fatto precedere dalla stringa <quote><literal>HG_</literal></quote>. Per esempio, se il nome di un parametro è <quote><literal>node</literal></quote>, il nome della variabile d’ambiente che rappresenta quel parametro sarà <quote><literal>HG_NODE</literal></quote>.</para> 16.568 + 16.569 + <para id="x_283">Un parametro booleano è rappresentato come la stringa <quote><literal>1</literal></quote> se è <quote>vero</quote> o <quote><literal>0</literal></quote> se è <quote>falso</quote>. Se una variabile d’ambiente è chiamata <envar>HG_NODE</envar>, <envar>HG_PARENT1</envar>, o <envar>HG_PARENT2</envar>, conterrà un identificatore di changeset rappresentato come una stringa esadecimale. Per rappresentare l’identificatore di changeset <quote>nullo</quote>, viene usata una stringa vuota invece di una stringa di zeri. Se una variabile d’ambiente è chiamata <envar>HG_URL</envar>, conterrà l’URL di un repository remoto, nel caso possa essere determinato.</para> 16.570 16.571 <para id="x_284">Se un hook termina con uno stato uguale a zero, si considera terminato con successo. Se termina con uno stato diverso da zero, si considera fallito.</para> 16.572 </sect2> 16.573 @@ -509,17 +509,17 @@ 16.574 <sect2> 16.575 <title>Scoprire da dove vengono i changeset</title> 16.576 16.577 - <para id="x_285">Un hook che coinvolge il trasferimento di changeset tra un repository locale e un altro potrebbe essere in grado di trovare informazioni sul <quote>lato opposto</quote>. Mercurial conosce il <emphasis>modo</emphasis> in cui i cambiamenti vengono trasferiti e in molti casi conosce anche l'ubicazione del <emphasis>luogo</emphasis> da cui o verso cui vengono trasferiti.</para> 16.578 + <para id="x_285">Un hook che coinvolge il trasferimento di changeset tra un repository locale e un altro potrebbe essere in grado di trovare informazioni sul <quote>lato opposto</quote>. Mercurial conosce il <emphasis>modo</emphasis> in cui i cambiamenti vengono trasferiti e in molti casi conosce anche l’ubicazione del <emphasis>luogo</emphasis> da cui o verso cui vengono trasferiti.</para> 16.579 16.580 <sect3 id="sec:hook:sources"> 16.581 <title>Le fonti dei changeset</title> 16.582 16.583 - <para id="x_286">Mercurial dirà a un hook quali sono, o sono stati, i mezzi usati per trasferire i changeset tra repository, fornendo questa informazione in un parametro Python chiamato <literal>source</literal> o in una variabile d'ambiente chiamata <envar>HG_SOURCE</envar>.</para> 16.584 + <para id="x_286">Mercurial dirà a un hook quali sono, o sono stati, i mezzi usati per trasferire i changeset tra repository, fornendo questa informazione in un parametro Python chiamato <literal>source</literal> o in una variabile d’ambiente chiamata <envar>HG_SOURCE</envar>.</para> 16.585 16.586 <itemizedlist> 16.587 <listitem><para id="x_287"><literal>serve</literal>: i changeset sono trasferiti da o verso un repository remoto via HTTP o ssh.</para> 16.588 </listitem> 16.589 - <listitem><para id="x_288"><literal>pull</literal>: i changeset sono trasferiti attraverso un'estrazione da un repository a un altro.</para> 16.590 + <listitem><para id="x_288"><literal>pull</literal>: i changeset sono trasferiti attraverso un’estrazione da un repository a un altro.</para> 16.591 </listitem> 16.592 <listitem><para id="x_289"><literal>push</literal>: i changeset sono trasferiti attraverso una trasmissione da un repository a un altro.</para> 16.593 </listitem> 16.594 @@ -530,13 +530,13 @@ 16.595 <sect3 id="sec:hook:url"> 16.596 <title>La destinazione dei cambiamenti&emdash;gli URL dei repository remoti</title> 16.597 16.598 - <para id="x_28b">Quando è possibile, Mercurial dirà a un hook l'ubicazione del <quote>lato opposto</quote> di un'attività che trasferisce i dati dei changeset tra repository, fornendo questa informazione in un parametro Python chiamato <literal>url</literal> o in una variabile d'ambiente chiamata <envar>HG_URL</envar>.</para> 16.599 - 16.600 - <para id="x_28c">Questa informazione non è sempre nota. Se un hook viene invocato in un repository condiviso via HTTP o ssh, Mercurial non è in grado di dire dove si trova il repository, ma potrebbe sapere da dove si sta connettendo il client. In questi casi, l'URL prenderà una delle seguenti forme:</para> 16.601 + <para id="x_28b">Quando è possibile, Mercurial dirà a un hook l’ubicazione del <quote>lato opposto</quote> di un’attività che trasferisce i dati dei changeset tra repository, fornendo questa informazione in un parametro Python chiamato <literal>url</literal> o in una variabile d’ambiente chiamata <envar>HG_URL</envar>.</para> 16.602 + 16.603 + <para id="x_28c">Questa informazione non è sempre nota. Se un hook viene invocato in un repository condiviso via HTTP o ssh, Mercurial non è in grado di dire dove si trova il repository, ma potrebbe sapere da dove si sta connettendo il client. In questi casi, l’URL prenderà una delle seguenti forme:</para> 16.604 <itemizedlist> 16.605 - <listitem><para id="x_28d"><literal>remote:ssh:1.2.3.4</literal>&emdash;client ssh remoto, all'indirizzo IP <literal>1.2.3.4</literal>.</para> 16.606 - </listitem> 16.607 - <listitem><para id="x_28e"><literal>remote:http:1.2.3.4</literal>&emdash;client HTTP remoto, all'indirizzo IP <literal>1.2.3.4</literal>. Se il client sta usando SSL, questo URL sarà nella forma <literal>remote:https:1.2.3.4</literal>.</para> 16.608 + <listitem><para id="x_28d"><literal>remote:ssh:1.2.3.4</literal>&emdash;client ssh remoto, all’indirizzo IP <literal>1.2.3.4</literal>.</para> 16.609 + </listitem> 16.610 + <listitem><para id="x_28e"><literal>remote:http:1.2.3.4</literal>&emdash;client HTTP remoto, all’indirizzo IP <literal>1.2.3.4</literal>. Se il client sta usando SSL, questo URL sarà nella forma <literal>remote:https:1.2.3.4</literal>.</para> 16.611 </listitem> 16.612 <listitem><para id="x_28f">Vuoto&emdash;Mercurial non è riuscito a scoprire nessuna informazione sul client remoto.</para> 16.613 </listitem></itemizedlist> 16.614 @@ -547,19 +547,19 @@ 16.615 <title>Guida di riferimento agli hook</title> 16.616 16.617 <sect2 id="sec:hook:changegroup"> 16.618 - <title><literal role="hook">changegroup</literal>&emdash;dopo l'aggiunta di changeset remoti</title> 16.619 - 16.620 - <para id="x_290">Questo hook viene eseguito dopo che un gruppo di changeset preesistenti è stato aggiunto al repository, per esempio tramite <command role="hg-cmd">hg pull</command> o <command role="hg-cmd">hg unbundle</command>. Questo hook viene eseguito una volta per ogni operazione che aggiunge uno o più changeset, a differenza dell'hook <literal role="hook">incoming</literal>, che viene eseguito una volta per ogni changeset a prescindere dal fatto che il changeset sia arrivato in un gruppo.</para> 16.621 - 16.622 - <para id="x_291">Alcuni possibili usi di questo hook includono l'avvio di un assemblaggio o di un collaudo automatico dei changeset aggiunti, l'aggiornamento di un database di bug, o la notifica che un repository contiene nuovi cambiamenti.</para> 16.623 + <title><literal role="hook">changegroup</literal>&emdash;dopo l’aggiunta di changeset remoti</title> 16.624 + 16.625 + <para id="x_290">Questo hook viene eseguito dopo che un gruppo di changeset preesistenti è stato aggiunto al repository, per esempio tramite <command role="hg-cmd">hg pull</command> o <command role="hg-cmd">hg unbundle</command>. Questo hook viene eseguito una volta per ogni operazione che aggiunge uno o più changeset, a differenza dell’hook <literal role="hook">incoming</literal>, che viene eseguito una volta per ogni changeset a prescindere dal fatto che il changeset sia arrivato in un gruppo.</para> 16.626 + 16.627 + <para id="x_291">Alcuni possibili usi di questo hook includono l’avvio di un assemblaggio o di un collaudo automatico dei changeset aggiunti, l’aggiornamento di un database di bug, o la notifica che un repository contiene nuovi cambiamenti.</para> 16.628 16.629 <para id="x_292">I parametri di questo hook sono i seguenti.</para> 16.630 <itemizedlist> 16.631 - <listitem><para id="x_293"><literal>node</literal>: un identificatore di changeset. L'identificatore del primo changeset nel gruppo che è stato aggiunto. Tutti i changeset tra questo e <literal role="tag">tip</literal> compresi sono stati aggiunti da una singola invocazione di <command role="hg-cmd">hg pull</command>, <command role="hg-cmd">hg push</command>, o <command role="hg-cmd">hg unbundle</command>.</para> 16.632 + <listitem><para id="x_293"><literal>node</literal>: un identificatore di changeset. L’identificatore del primo changeset nel gruppo che è stato aggiunto. Tutti i changeset tra questo e <literal role="tag">tip</literal> compresi sono stati aggiunti da una singola invocazione di <command role="hg-cmd">hg pull</command>, <command role="hg-cmd">hg push</command>, o <command role="hg-cmd">hg unbundle</command>.</para> 16.633 </listitem> 16.634 <listitem><para id="x_294"><literal>source</literal>: una stringa. La fonte di questi cambiamenti. Si veda la <xref linkend="sec:hook:sources"/> per i dettagli.</para> 16.635 </listitem> 16.636 - <listitem><para id="x_295"><literal>url</literal>: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la <xref linkend="sec:hook:url"/> per maggiori informazioni.</para> 16.637 + <listitem><para id="x_295"><literal>url</literal>: un URL. L’ubicazione del repository remoto, nel caso sia nota. Si veda la <xref linkend="sec:hook:url"/> per maggiori informazioni.</para> 16.638 </listitem></itemizedlist> 16.639 16.640 <para id="x_296">Si vedano anche gli hook <literal role="hook">incoming</literal> (<xref linkend="sec:hook:incoming"/>), <literal role="hook">prechangegroup</literal> (<xref linkend="sec:hook:prechangegroup"/>) e <literal role="hook">pretxnchangegroup</literal> (<xref linkend="sec:hook:pretxnchangegroup"/>).</para> 16.641 @@ -572,30 +572,30 @@ 16.642 16.643 <para id="x_298">I parametri di questo hook sono i seguenti.</para> 16.644 <itemizedlist> 16.645 - <listitem><para id="x_299"><literal>node</literal>: un identificatore di changeset. L'identificatore del changeset appena inserito.</para> 16.646 - </listitem> 16.647 - <listitem><para id="x_29a"><literal>parent1</literal>: un identificatore di changeset. L'identificatore di changeset del primo genitore del changeset appena inserito.</para> 16.648 - </listitem> 16.649 - <listitem><para id="x_29b"><literal>parent2</literal>: un identificatore di changeset. L'identificatore di changeset del secondo genitore del changeset appena inserito.</para> 16.650 + <listitem><para id="x_299"><literal>node</literal>: un identificatore di changeset. L’identificatore del changeset appena inserito.</para> 16.651 + </listitem> 16.652 + <listitem><para id="x_29a"><literal>parent1</literal>: un identificatore di changeset. L’identificatore di changeset del primo genitore del changeset appena inserito.</para> 16.653 + </listitem> 16.654 + <listitem><para id="x_29b"><literal>parent2</literal>: un identificatore di changeset. L’identificatore di changeset del secondo genitore del changeset appena inserito.</para> 16.655 </listitem></itemizedlist> 16.656 16.657 <para id="x_29c">Si vedano anche gli hook <literal role="hook">precommit</literal> (<xref linkend="sec:hook:precommit"/>) e <literal role="hook">pretxncommit</literal> (<xref linkend="sec:hook:pretxncommit"/>).</para> 16.658 </sect2> 16.659 16.660 <sect2 id="sec:hook:incoming"> 16.661 - <title><literal role="hook">incoming</literal>&emdash;dopo l'aggiunta di un changeset remoto</title> 16.662 - 16.663 - <para id="x_29d">Questo hook viene eseguito dopo che un changeset preesistente è stato aggiunto al repository, per esempio attraverso l'invocazione di <command role="hg-cmd">hg push</command>. Se un gruppo di changeset è stato aggiunto in una singola operazione, questo hook viene eseguito una volta per ogni changeset aggiunto.</para> 16.664 - 16.665 - <para id="x_29e">Potete usare questo hook per gli stessi scopi dell'hook <literal role="hook">changegroup</literal> (<xref linkend="sec:hook:changegroup"/>). A volte è semplicemente più comodo eseguire un hook per ogni gruppo di changeset, mentre altre volte è più conveniente eseguirlo per ogni changeset.</para> 16.666 + <title><literal role="hook">incoming</literal>&emdash;dopo l’aggiunta di un changeset remoto</title> 16.667 + 16.668 + <para id="x_29d">Questo hook viene eseguito dopo che un changeset preesistente è stato aggiunto al repository, per esempio attraverso l’invocazione di <command role="hg-cmd">hg push</command>. Se un gruppo di changeset è stato aggiunto in una singola operazione, questo hook viene eseguito una volta per ogni changeset aggiunto.</para> 16.669 + 16.670 + <para id="x_29e">Potete usare questo hook per gli stessi scopi dell’hook <literal role="hook">changegroup</literal> (<xref linkend="sec:hook:changegroup"/>). A volte è semplicemente più comodo eseguire un hook per ogni gruppo di changeset, mentre altre volte è più conveniente eseguirlo per ogni changeset.</para> 16.671 16.672 <para id="x_29f">I parametri di questo hook sono i seguenti.</para> 16.673 <itemizedlist> 16.674 - <listitem><para id="x_2a0"><literal>node</literal>: un identificatore di changeset. L'identificatore del changeset appena aggiunto.</para> 16.675 + <listitem><para id="x_2a0"><literal>node</literal>: un identificatore di changeset. L’identificatore del changeset appena aggiunto.</para> 16.676 </listitem> 16.677 <listitem><para id="x_2a1"><literal>source</literal>: una stringa. La fonte di questi cambiamenti. Si veda la <xref linkend="sec:hook:sources"/> per i dettagli.</para> 16.678 </listitem> 16.679 - <listitem><para id="x_2a2"><literal>url</literal>: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la <xref linkend="sec:hook:url"/> per maggiori informazioni.</para> 16.680 + <listitem><para id="x_2a2"><literal>url</literal>: un URL. L’ubicazione del repository remoto, nel caso sia nota. Si veda la <xref linkend="sec:hook:url"/> per maggiori informazioni.</para> 16.681 </listitem></itemizedlist> 16.682 16.683 <para id="x_2a3">Si vedano anche gli hook <literal role="hook">changegroup</literal> (<xref linkend="sec:hook:changegroup"/>), <literal role="hook">prechangegroup</literal> (<xref linkend="sec:hook:prechangegroup"/>) e <literal role="hook">pretxnchangegroup</literal> (<xref linkend="sec:hook:pretxnchangegroup"/>).</para> 16.684 @@ -604,20 +604,20 @@ 16.685 <sect2 id="sec:hook:outgoing"> 16.686 <title><literal role="hook">outgoing</literal>&emdash;dopo la propagazione dei changeset</title> 16.687 16.688 - <para id="x_2a4">Questo hook viene eseguito dopo che un gruppo di changeset è stato propagato al di fuori di questo repository, per esempio attraverso l'invocazione dei comandi <command role="hg-cmd">hg push</command> o <command role="hg-cmd">hg bundle</command>.</para> 16.689 + <para id="x_2a4">Questo hook viene eseguito dopo che un gruppo di changeset è stato propagato al di fuori di questo repository, per esempio attraverso l’invocazione dei comandi <command role="hg-cmd">hg push</command> o <command role="hg-cmd">hg bundle</command>.</para> 16.690 16.691 <para id="x_2a5">Un possibile impiego di questo hook è quello di notificare gli amministratori di un repository che alcuni cambiamenti sono stati estratti.</para> 16.692 16.693 <para id="x_2a6">I parametri di questo hook sono i seguenti.</para> 16.694 <itemizedlist> 16.695 - <listitem><para id="x_2a7"><literal>node</literal>: un identificatore di changeset. L'identificatore del primo changeset del gruppo che è stato propagato.</para> 16.696 - </listitem> 16.697 - <listitem><para id="x_2a8"><literal>source</literal>: una stringa. La fonte dell'operazione (si veda la <xref linkend="sec:hook:sources"/>). Se un client remoto ha estratto i cambiamenti da questo repository, il valore di <literal>source</literal> sarà <literal>serve</literal>. Se il client che ha ottenuto i cambiamenti di questo repository era locale, il valore di <literal>source</literal> sarà <literal>bundle</literal>, <literal>pull</literal>, o <literal>push</literal>, a seconda dell'operazione effettuata dal client.</para> 16.698 - </listitem> 16.699 - <listitem><para id="x_2a9"><literal>url</literal>: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la <xref linkend="sec:hook:url"/> per maggiori informazioni.</para> 16.700 - </listitem></itemizedlist> 16.701 - 16.702 - <para id="x_2aa">Si veda anche l'hook <literal role="hook">preoutgoing</literal> (<xref linkend="sec:hook:preoutgoing"/>).</para> 16.703 + <listitem><para id="x_2a7"><literal>node</literal>: un identificatore di changeset. L’identificatore del primo changeset del gruppo che è stato propagato.</para> 16.704 + </listitem> 16.705 + <listitem><para id="x_2a8"><literal>source</literal>: una stringa. La fonte dell’operazione (si veda la <xref linkend="sec:hook:sources"/>). Se un client remoto ha estratto i cambiamenti da questo repository, il valore di <literal>source</literal> sarà <literal>serve</literal>. Se il client che ha ottenuto i cambiamenti di questo repository era locale, il valore di <literal>source</literal> sarà <literal>bundle</literal>, <literal>pull</literal>, o <literal>push</literal>, a seconda dell’operazione effettuata dal client.</para> 16.706 + </listitem> 16.707 + <listitem><para id="x_2a9"><literal>url</literal>: un URL. L’ubicazione del repository remoto, nel caso sia nota. Si veda la <xref linkend="sec:hook:url"/> per maggiori informazioni.</para> 16.708 + </listitem></itemizedlist> 16.709 + 16.710 + <para id="x_2aa">Si veda anche l’hook <literal role="hook">preoutgoing</literal> (<xref linkend="sec:hook:preoutgoing"/>).</para> 16.711 </sect2> 16.712 16.713 <sect2 id="sec:hook:prechangegroup"> 16.714 @@ -633,26 +633,26 @@ 16.715 <itemizedlist> 16.716 <listitem><para id="x_2af"><literal>source</literal>: una stringa. La fonte di questi cambiamenti. Si veda la <xref linkend="sec:hook:sources"/> per i dettagli.</para> 16.717 </listitem> 16.718 - <listitem><para id="x_2b0"><literal>url</literal>: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la <xref linkend="sec:hook:url"/> per maggiori informazioni.</para> 16.719 + <listitem><para id="x_2b0"><literal>url</literal>: un URL. L’ubicazione del repository remoto, nel caso sia nota. Si veda la <xref linkend="sec:hook:url"/> per maggiori informazioni.</para> 16.720 </listitem></itemizedlist> 16.721 16.722 <para id="x_2b1">Si vedano anche gli hook <literal role="hook">changegroup</literal> (<xref linkend="sec:hook:changegroup"/>), <literal role="hook">incoming</literal> (<xref linkend="sec:hook:incoming"/>) e <literal role="hook">pretxnchangegroup</literal> (<xref linkend="sec:hook:pretxnchangegroup"/>).</para> 16.723 </sect2> 16.724 16.725 <sect2 id="sec:hook:precommit"> 16.726 - <title><literal role="hook">precommit</literal>&emdash;prima di cominciare l'inserimento di un changeset</title> 16.727 - 16.728 - <para id="x_2b2">Questo hook viene eseguito prima che Mercurial cominci l'inserimento di un nuovo changeset, quindi prima che Mercurial conosca i metadati dell'inserimento come i file da inserire, il messaggio e la data di commit.</para> 16.729 - 16.730 - <para id="x_2b3">Questo hook può essere usato per disabilitare la possibilità di inserire nuovi changeset, pur permettendo la trasmissione di changeset in entrata. Un'altra possibilità è quella di eseguire l'assemblaggio o il collaudo e consentire l'avvio dell'inserimento solo se l'assemblaggio o il collaudo hanno successo.</para> 16.731 + <title><literal role="hook">precommit</literal>&emdash;prima di cominciare l’inserimento di un changeset</title> 16.732 + 16.733 + <para id="x_2b2">Questo hook viene eseguito prima che Mercurial cominci l’inserimento di un nuovo changeset, quindi prima che Mercurial conosca i metadati dell’inserimento come i file da inserire, il messaggio e la data di commit.</para> 16.734 + 16.735 + <para id="x_2b3">Questo hook può essere usato per disabilitare la possibilità di inserire nuovi changeset, pur permettendo la trasmissione di changeset in entrata. Un’altra possibilità è quella di eseguire l’assemblaggio o il collaudo e consentire l’avvio dell’inserimento solo se l’assemblaggio o il collaudo hanno successo.</para> 16.736 16.737 <para id="x_2b4">I parametri di questo hook sono i seguenti.</para> 16.738 <itemizedlist> 16.739 - <listitem><para id="x_2b5"><literal>parent1</literal>: un identificatore di changeset. L'identificatore di changeset del primo genitore della directory di lavoro.</para> 16.740 - </listitem> 16.741 - <listitem><para id="x_2b6"><literal>parent2</literal>: un identificatore di changeset. L'identificatore di changeset del secondo genitore della directory di lavoro.</para> 16.742 - </listitem></itemizedlist> 16.743 - <para id="x_2b7">Se l'inserimento procede, i genitori della directory di lavoro diventeranno i genitori del nuovo changeset.</para> 16.744 + <listitem><para id="x_2b5"><literal>parent1</literal>: un identificatore di changeset. L’identificatore di changeset del primo genitore della directory di lavoro.</para> 16.745 + </listitem> 16.746 + <listitem><para id="x_2b6"><literal>parent2</literal>: un identificatore di changeset. L’identificatore di changeset del secondo genitore della directory di lavoro.</para> 16.747 + </listitem></itemizedlist> 16.748 + <para id="x_2b7">Se l’inserimento procede, i genitori della directory di lavoro diventeranno i genitori del nuovo changeset.</para> 16.749 16.750 <para id="x_2b8">Si vedano anche gli hook <literal role="hook">commit</literal> (<xref linkend="sec:hook:commit"/>) e <literal role="hook">pretxncommit</literal> (<xref linkend="sec:hook:pretxncommit"/>).</para> 16.751 </sect2> 16.752 @@ -666,128 +666,128 @@ 16.753 16.754 <para id="x_2bb">I parametri di questo hook sono i seguenti.</para> 16.755 <itemizedlist> 16.756 - <listitem><para id="x_2bc"><literal>source</literal>: una stringa. La fonte dell'operazione che sta tentando di ottenere i cambiamenti da questo repository (si veda la <xref linkend="sec:hook:sources"/>). Leggete la documentazione del parametro <literal>source</literal> dell'hook <literal role="hook">outgoing</literal> nella <xref linkend="sec:hook:outgoing"/> per conoscere i possibili valori di questo parametro.</para> 16.757 - </listitem> 16.758 - <listitem><para id="x_2bd"><literal>url</literal>: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la <xref linkend="sec:hook:url"/> per maggiori informazioni.</para> 16.759 - </listitem></itemizedlist> 16.760 - 16.761 - <para id="x_2be">Si veda anche l'hook <literal role="hook">outgoing</literal> (<xref linkend="sec:hook:outgoing"/>).</para> 16.762 + <listitem><para id="x_2bc"><literal>source</literal>: una stringa. La fonte dell’operazione che sta tentando di ottenere i cambiamenti da questo repository (si veda la <xref linkend="sec:hook:sources"/>). Leggete la documentazione del parametro <literal>source</literal> dell’hook <literal role="hook">outgoing</literal> nella <xref linkend="sec:hook:outgoing"/> per conoscere i possibili valori di questo parametro.</para> 16.763 + </listitem> 16.764 + <listitem><para id="x_2bd"><literal>url</literal>: un URL. L’ubicazione del repository remoto, nel caso sia nota. Si veda la <xref linkend="sec:hook:url"/> per maggiori informazioni.</para> 16.765 + </listitem></itemizedlist> 16.766 + 16.767 + <para id="x_2be">Si veda anche l’hook <literal role="hook">outgoing</literal> (<xref linkend="sec:hook:outgoing"/>).</para> 16.768 </sect2> 16.769 16.770 <sect2 id="sec:hook:pretag"> 16.771 <title><literal role="hook">pretag</literal>&emdash;prima di etichettare un changeset</title> 16.772 16.773 - <para id="x_2bf">Questo hook di controllo viene eseguito prima della creazione di un'etichetta. Se l'hook ha successo, la creazione dell'etichetta procede. Se l'hook fallisce, l'etichetta non viene creata.</para> 16.774 + <para id="x_2bf">Questo hook di controllo viene eseguito prima della creazione di un’etichetta. Se l’hook ha successo, la creazione dell’etichetta procede. Se l’hook fallisce, l’etichetta non viene creata.</para> 16.775 16.776 <para id="x_2c0">I parametri di questo hook sono i seguenti.</para> 16.777 <itemizedlist> 16.778 - <listitem><para id="x_2c1"><literal>local</literal>: un booleano. Indica se l'etichetta è locale a questa istanza del repository (cioè memorizzata nel file <filename role="special">.hg/localtags</filename>) o se è gestita da Mercurial (memorizzata nel file <filename role="special">.hgtags</filename>).</para> 16.779 - </listitem> 16.780 - <listitem><para id="x_2c2"><literal>node</literal>: un identificatore di changeset. L'identificatore del changeset da etichettare.</para> 16.781 - </listitem> 16.782 - <listitem><para id="x_2c3"><literal>tag</literal>: una stringa. Il nome dell'etichetta da creare.</para> 16.783 - </listitem></itemizedlist> 16.784 - 16.785 - <para id="x_2c4">Se l'etichetta da creare è soggetta a controllo di revisione, verranno eseguiti anche gli hook <literal role="hook">precommit</literal> e <literal role="hook">pretxncommit</literal> (<xref linkend="sec:hook:commit"/> e <xref linkend="sec:hook:pretxncommit"/>).</para> 16.786 - 16.787 - <para id="x_2c5">Si veda anche l'hook <literal role="hook">tag</literal> (<xref linkend="sec:hook:tag"/>).</para> 16.788 + <listitem><para id="x_2c1"><literal>local</literal>: un booleano. Indica se l’etichetta è locale a questa istanza del repository (cioè memorizzata nel file <filename role="special">.hg/localtags</filename>) o se è gestita da Mercurial (memorizzata nel file <filename role="special">.hgtags</filename>).</para> 16.789 + </listitem> 16.790 + <listitem><para id="x_2c2"><literal>node</literal>: un identificatore di changeset. L’identificatore del changeset da etichettare.</para> 16.791 + </listitem> 16.792 + <listitem><para id="x_2c3"><literal>tag</literal>: una stringa. Il nome dell’etichetta da creare.</para> 16.793 + </listitem></itemizedlist> 16.794 + 16.795 + <para id="x_2c4">Se l’etichetta da creare è soggetta a controllo di revisione, verranno eseguiti anche gli hook <literal role="hook">precommit</literal> e <literal role="hook">pretxncommit</literal> (<xref linkend="sec:hook:commit"/> e <xref linkend="sec:hook:pretxncommit"/>).</para> 16.796 + 16.797 + <para id="x_2c5">Si veda anche l’hook <literal role="hook">tag</literal> (<xref linkend="sec:hook:tag"/>).</para> 16.798 </sect2> 16.799 16.800 <sect2 id="sec:hook:pretxnchangegroup"> 16.801 <title><literal 16.802 - role="hook">pretxnchangegroup</literal>&emdash;prima di completare l'aggiunta di changeset remoti</title> 16.803 - 16.804 - <para id="x_2c6">Questo hook di controllo viene eseguito prima di completare la transazione che gestisce l'aggiunta di un gruppo di nuovi changeset provenienti dall'esterno del repository. Se l'hook ha successo, la transazione viene completata e tutti i changeset diventano permanenti all'interno di questo repository. Se l'hook fallisce, la transazione viene abortita e i dati relativi ai changeset vengono cancellati.</para> 16.805 - 16.806 - <para id="x_2c7">Questo hook può accedere ai metadati associati ai changeset in procinto di essere aggiunti, ma dovrebbe evitare di modificarli in maniera permanente. L'hook deve anche evitare di modificare la directory di lavoro.</para> 16.807 + role="hook">pretxnchangegroup</literal>&emdash;prima di completare l’aggiunta di changeset remoti</title> 16.808 + 16.809 + <para id="x_2c6">Questo hook di controllo viene eseguito prima di completare la transazione che gestisce l’aggiunta di un gruppo di nuovi changeset provenienti dall’esterno del repository. Se l’hook ha successo, la transazione viene completata e tutti i changeset diventano permanenti all’interno di questo repository. Se l’hook fallisce, la transazione viene abortita e i dati relativi ai changeset vengono cancellati.</para> 16.810 + 16.811 + <para id="x_2c7">Questo hook può accedere ai metadati associati ai changeset in procinto di essere aggiunti, ma dovrebbe evitare di modificarli in maniera permanente. L’hook deve anche evitare di modificare la directory di lavoro.</para> 16.812 16.813 <para id="x_2c8">Se altri processi Mercurial accedono al repository mentre questo hook è in esecuzione, saranno in grado di vedere i changeset quasi aggiunti come se fossero permanenti. Questo potrebbe portare a condizioni di corsa critica se non eseguite i passi necessari per evitarle.</para> 16.814 16.815 - <para id="x_2c9">Questo hook può essere usato per esaminare automaticamente un gruppo di changeset. Se l'hook fallisce, tutti i changeset vengono <quote>respinti</quote> quando la transazione viene abortita.</para> 16.816 + <para id="x_2c9">Questo hook può essere usato per esaminare automaticamente un gruppo di changeset. Se l’hook fallisce, tutti i changeset vengono <quote>respinti</quote> quando la transazione viene abortita.</para> 16.817 16.818 <para id="x_2ca">I parametri di questo hook sono i seguenti.</para> 16.819 <itemizedlist> 16.820 - <listitem><para id="x_2cb"><literal>node</literal>: un identificatore di changeset. L'identificatore del primo changeset nel gruppo che è stato aggiunto. Tutti i changeset tra questo e <literal role="tag">tip</literal> compresi sono stati aggiunti da una singola invocazione di <command role="hg-cmd">hg pull</command>, <command role="hg-cmd">hg push</command>, o <command role="hg-cmd">hg unbundle</command>.</para> 16.821 + <listitem><para id="x_2cb"><literal>node</literal>: un identificatore di changeset. L’identificatore del primo changeset nel gruppo che è stato aggiunto. Tutti i changeset tra questo e <literal role="tag">tip</literal> compresi sono stati aggiunti da una singola invocazione di <command role="hg-cmd">hg pull</command>, <command role="hg-cmd">hg push</command>, o <command role="hg-cmd">hg unbundle</command>.</para> 16.822 </listitem> 16.823 <listitem><para id="x_2cc"><literal>source</literal>: una stringa. La fonte di questi cambiamenti. Si veda la <xref linkend="sec:hook:sources"/> per i dettagli.</para> 16.824 </listitem> 16.825 - <listitem><para id="x_2cd"><literal>url</literal>: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la <xref linkend="sec:hook:url"/> per maggiori informazioni.</para> 16.826 + <listitem><para id="x_2cd"><literal>url</literal>: un URL. L’ubicazione del repository remoto, nel caso sia nota. Si veda la <xref linkend="sec:hook:url"/> per maggiori informazioni.</para> 16.827 </listitem></itemizedlist> 16.828 16.829 <para id="x_2ce">Si vedano anche gli hook <literal role="hook">changegroup</literal> (<xref linkend="sec:hook:changegroup"/>), <literal role="hook">incoming</literal> (<xref linkend="sec:hook:incoming"/>) e <literal role="hook">prechangegroup</literal> (<xref linkend="sec:hook:prechangegroup"/>).</para> 16.830 </sect2> 16.831 16.832 <sect2 id="sec:hook:pretxncommit"> 16.833 - <title><literal role="hook">pretxncommit</literal>&emdash;prima di completare l'inserimento di un nuovo changeset</title> 16.834 - 16.835 - <para id="x_2cf">Questo hook di controllo viene eseguito prima di completare la transazione che gestisce un nuovo inserimento. Se l'hook ha successo, la transazione viene completata e il changeset diventa permanente all'interno di questo repository. Se l'hook fallisce, la transazione viene abortita e i dati dell'inserimento vengono cancellati.</para> 16.836 - 16.837 - <para id="x_2d0">Questo hook può accedere ai metadati associati al changeset in procinto di essere inserito, ma dovrebbe evitare di modificarli in maniera permanente. L'hook deve anche evitare di modificare la directory di lavoro.</para> 16.838 + <title><literal role="hook">pretxncommit</literal>&emdash;prima di completare l’inserimento di un nuovo changeset</title> 16.839 + 16.840 + <para id="x_2cf">Questo hook di controllo viene eseguito prima di completare la transazione che gestisce un nuovo inserimento. Se l’hook ha successo, la transazione viene completata e il changeset diventa permanente all’interno di questo repository. Se l’hook fallisce, la transazione viene abortita e i dati dell’inserimento vengono cancellati.</para> 16.841 + 16.842 + <para id="x_2d0">Questo hook può accedere ai metadati associati al changeset in procinto di essere inserito, ma dovrebbe evitare di modificarli in maniera permanente. L’hook deve anche evitare di modificare la directory di lavoro.</para> 16.843 16.844 <para id="x_2d1">Se altri processi Mercurial accedono al repository mentre questo hook è in esecuzione, saranno in grado di vedere i changeset quasi aggiunti come se fossero permanenti. Questo potrebbe portare a condizioni di corsa critica se non eseguite i passi necessari per evitarle.</para> 16.845 16.846 <para id="x_2d2">I parametri di questo hook sono i seguenti.</para> 16.847 16.848 <itemizedlist> 16.849 - <listitem><para id="x_2d3"><literal>node</literal>: un identificatore di changeset. L'identificatore del changeset sul punto di essere inserito.</para> 16.850 - </listitem> 16.851 - <listitem><para id="x_2d4"><literal>parent1</literal>: un identificatore di changeset. L'identificatore di changeset del primo genitore del changeset sul punto di essere inserito.</para> 16.852 - </listitem> 16.853 - <listitem><para id="x_2d5"><literal>parent2</literal>: un identificatore di changeset. L'identificatore di changeset del secondo genitore del changeset sul punto di essere inserito.</para> 16.854 - </listitem></itemizedlist> 16.855 - 16.856 - <para id="x_2d6">Si veda anche l'hook <literal role="hook">precommit</literal> (<xref linkend="sec:hook:precommit"/>).</para> 16.857 + <listitem><para id="x_2d3"><literal>node</literal>: un identificatore di changeset. L’identificatore del changeset sul punto di essere inserito.</para> 16.858 + </listitem> 16.859 + <listitem><para id="x_2d4"><literal>parent1</literal>: un identificatore di changeset. L’identificatore di changeset del primo genitore del changeset sul punto di essere inserito.</para> 16.860 + </listitem> 16.861 + <listitem><para id="x_2d5"><literal>parent2</literal>: un identificatore di changeset. L’identificatore di changeset del secondo genitore del changeset sul punto di essere inserito.</para> 16.862 + </listitem></itemizedlist> 16.863 + 16.864 + <para id="x_2d6">Si veda anche l’hook <literal role="hook">precommit</literal> (<xref linkend="sec:hook:precommit"/>).</para> 16.865 </sect2> 16.866 16.867 <sect2 id="sec:hook:preupdate"> 16.868 - <title><literal role="hook">preupdate</literal>&emdash;prima di eseguire un aggiornamento o un'unione della directory di lavoro</title> 16.869 - 16.870 - <para id="x_2d7">Questo hook viene eseguito prima di cominciare un aggiornamento o un'unione della directory di lavoro. Viene eseguito solo se i normali controlli effettuati da Mercurial prima di un aggiornamento determinano che l'aggiornamento o l'unione possono procedere. Se l'hook ha successo, l'aggiornamento o l'unione possono procedere, ma se fallisce, l'aggiornamento o l'unione non vengono cominciati.</para> 16.871 + <title><literal role="hook">preupdate</literal>&emdash;prima di eseguire un aggiornamento o un’unione della directory di lavoro</title> 16.872 + 16.873 + <para id="x_2d7">Questo hook viene eseguito prima di cominciare un aggiornamento o un’unione della directory di lavoro. Viene eseguito solo se i normali controlli effettuati da Mercurial prima di un aggiornamento determinano che l’aggiornamento o l’unione possono procedere. Se l’hook ha successo, l’aggiornamento o l’unione possono procedere, ma se fallisce, l’aggiornamento o l’unione non vengono cominciati.</para> 16.874 16.875 <para id="x_2d8">I parametri di questo hook sono i seguenti.</para> 16.876 <itemizedlist> 16.877 - <listitem><para id="x_2d9"><literal>parent1</literal>: un identificatore di changeset. L'identificatore del genitore a cui la directory di lavoro sta per essere aggiornata. Se si sta per effettuare un'unione, questo genitore non verrà modificato.</para> 16.878 - </listitem> 16.879 - <listitem><para id="x_2da"><literal>parent2</literal>: un identificatore di changeset. Il suo valore viene impostato solo se si sta eseguendo un'unione. Contiene l'identificatore della revisione con cui la directory di lavoro viene unita.</para> 16.880 - </listitem></itemizedlist> 16.881 - 16.882 - <para id="x_2db">Si veda anche l'hook <literal role="hook">update</literal> (<xref linkend="sec:hook:update"/>).</para> 16.883 + <listitem><para id="x_2d9"><literal>parent1</literal>: un identificatore di changeset. L’identificatore del genitore a cui la directory di lavoro sta per essere aggiornata. Se si sta per effettuare un’unione, questo genitore non verrà modificato.</para> 16.884 + </listitem> 16.885 + <listitem><para id="x_2da"><literal>parent2</literal>: un identificatore di changeset. Il suo valore viene impostato solo se si sta eseguendo un’unione. Contiene l’identificatore della revisione con cui la directory di lavoro viene unita.</para> 16.886 + </listitem></itemizedlist> 16.887 + 16.888 + <para id="x_2db">Si veda anche l’hook <literal role="hook">update</literal> (<xref linkend="sec:hook:update"/>).</para> 16.889 </sect2> 16.890 16.891 <sect2 id="sec:hook:tag"> 16.892 <title><literal role="hook">tag</literal>&emdash;dopo aver etichettato un changeset</title> 16.893 16.894 - <para id="x_2dc">Questo hook viene eseguito dopo la creazione di un'etichetta.</para> 16.895 + <para id="x_2dc">Questo hook viene eseguito dopo la creazione di un’etichetta.</para> 16.896 16.897 <para id="x_2dd">I parametri di questo hook sono i seguenti.</para> 16.898 <itemizedlist> 16.899 - <listitem><para id="x_2de"><literal>local</literal>: un booleano. Indica se l'etichetta è locale a questa istanza del repository (cioè memorizzata nel file <filename role="special">.hg/localtags</filename>) o se è gestita da Mercurial (memorizzata nel file <filename role="special">.hgtags</filename>).</para> 16.900 - </listitem> 16.901 - <listitem><para id="x_2df"><literal>node</literal>: un identificatore di changeset. L'identificatore del changeset che è stato etichettato.</para> 16.902 - </listitem> 16.903 - <listitem><para id="x_2e0"><literal>tag</literal>: una stringa. Il nome dell'etichetta creata.</para> 16.904 - </listitem></itemizedlist> 16.905 - 16.906 - <para id="x_2e1">Se l'etichetta creata è soggetta a controllo di revisione, l'hook <literal role="hook">commit</literal> (<xref linkend="sec:hook:commit"/>) verrà eseguito prima di questo hook.</para> 16.907 - 16.908 - <para id="x_2e2">Si veda anche l'hook <literal role="hook">pretag</literal> (<xref linkend="sec:hook:pretag"/>).</para> 16.909 + <listitem><para id="x_2de"><literal>local</literal>: un booleano. Indica se l’etichetta è locale a questa istanza del repository (cioè memorizzata nel file <filename role="special">.hg/localtags</filename>) o se è gestita da Mercurial (memorizzata nel file <filename role="special">.hgtags</filename>).</para> 16.910 + </listitem> 16.911 + <listitem><para id="x_2df"><literal>node</literal>: un identificatore di changeset. L’identificatore del changeset che è stato etichettato.</para> 16.912 + </listitem> 16.913 + <listitem><para id="x_2e0"><literal>tag</literal>: una stringa. Il nome dell’etichetta creata.</para> 16.914 + </listitem></itemizedlist> 16.915 + 16.916 + <para id="x_2e1">Se l’etichetta creata è soggetta a controllo di revisione, l’hook <literal role="hook">commit</literal> (<xref linkend="sec:hook:commit"/>) verrà eseguito prima di questo hook.</para> 16.917 + 16.918 + <para id="x_2e2">Si veda anche l’hook <literal role="hook">pretag</literal> (<xref linkend="sec:hook:pretag"/>).</para> 16.919 </sect2> 16.920 16.921 <sect2 id="sec:hook:update"> 16.922 - <title><literal role="hook">update</literal>&emdash;dopo aver eseguito un aggiornamento o un'unione della directory di lavoro</title> 16.923 - 16.924 - <para id="x_2e3">Questo hook viene eseguito dopo il completamento di un aggiornamento o di un'unione della directory di lavoro. Dato che un'unione può fallire (nel caso il comando esterno <command>hgmerge</command> non sia in grado di risolvere i conflitti in un file), questo hook comunica se l'aggiornamento o l'unione sono stati completati in maniera pulita.</para> 16.925 + <title><literal role="hook">update</literal>&emdash;dopo aver eseguito un aggiornamento o un’unione della directory di lavoro</title> 16.926 + 16.927 + <para id="x_2e3">Questo hook viene eseguito dopo il completamento di un aggiornamento o di un’unione della directory di lavoro. Dato che un’unione può fallire (nel caso il comando esterno <command>hgmerge</command> non sia in grado di risolvere i conflitti in un file), questo hook comunica se l’aggiornamento o l’unione sono stati completati in maniera pulita.</para> 16.928 16.929 <para id="x_ffe">I parametri di questo hook sono i seguenti.</para> 16.930 <itemizedlist> 16.931 - <listitem><para id="x_2e4"><literal>error</literal>: un booleano. Indica se l'aggiornamento o l'unione sono stati completati con successo.</para> 16.932 - </listitem> 16.933 - <listitem><para id="x_2e5"><literal>parent1</literal>: un identificatore di changeset. L'identificatore del genitore a cui la directory di lavoro è stata aggiornata. Se è stata effettuata un'unione, questo genitore non viene modificato.</para> 16.934 - </listitem> 16.935 - <listitem><para id="x_2e6"><literal>parent2</literal>: un identificatore di changeset. Il suo valore viene impostato solo se è stata eseguita un'unione. Contiene l'identificatore della revisione con cui la directory di lavoro è stata unita.</para> 16.936 - </listitem></itemizedlist> 16.937 - 16.938 - <para id="x_2e7">Si veda anche l'hook <literal role="hook">preupdate</literal> (<xref linkend="sec:hook:preupdate"/>).</para> 16.939 + <listitem><para id="x_2e4"><literal>error</literal>: un booleano. Indica se l’aggiornamento o l’unione sono stati completati con successo.</para> 16.940 + </listitem> 16.941 + <listitem><para id="x_2e5"><literal>parent1</literal>: un identificatore di changeset. L’identificatore del genitore a cui la directory di lavoro è stata aggiornata. Se è stata effettuata un’unione, questo genitore non viene modificato.</para> 16.942 + </listitem> 16.943 + <listitem><para id="x_2e6"><literal>parent2</literal>: un identificatore di changeset. Il suo valore viene impostato solo se è stata eseguita un’unione. Contiene l’identificatore della revisione con cui la directory di lavoro è stata unita.</para> 16.944 + </listitem></itemizedlist> 16.945 + 16.946 + <para id="x_2e7">Si veda anche l’hook <literal role="hook">preupdate</literal> (<xref linkend="sec:hook:preupdate"/>).</para> 16.947 16.948 </sect2> 16.949 </sect1>
17.1 --- a/it/ch11-template.xml Sat Aug 22 21:01:56 2009 +0200 17.2 +++ b/it/ch11-template.xml Sat Aug 22 21:55:05 2009 +0200 17.3 @@ -2,14 +2,14 @@ 17.4 <?dbhtml filename="personalizzare-i-messaggi-di-mercurial.html"?> 17.5 <title>Personalizzare i messaggi di Mercurial</title> 17.6 17.7 - <para id="x_578">Mercurial vi offre un potente meccanismo basato sui template (letteralmente, modelli) per controllare il modo in cui visualizza le informazioni. Potete usare i template per generare una specifica presentazione dei risultati di un singolo comando, o per personalizzare l'intero aspetto dell'interfaccia web predefinita.</para> 17.8 + <para id="x_578">Mercurial vi offre un potente meccanismo basato sui template (letteralmente, modelli) per controllare il modo in cui visualizza le informazioni. Potete usare i template per generare una specifica presentazione dei risultati di un singolo comando, o per personalizzare l’intero aspetto dell’interfaccia web predefinita.</para> 17.9 17.10 <sect1 id="sec:style"> 17.11 <title>Usare gli stili di formattazione già pronti</title> 17.12 17.13 <para id="x_579">Mercurial include alcuni stili di formattazione che potete usare immediatamente. Uno stile è semplicemente un template già pronto che qualcuno ha scritto e installato in una posizione nota a Mercurial.</para> 17.14 17.15 - <para id="x_57a">Prima di dare un'occhiata agli stili distribuiti con Mercurial, rivediamo il normale risultato di un suo comando.</para> 17.16 + <para id="x_57a">Prima di dare un’occhiata agli stili distribuiti con Mercurial, rivediamo il normale risultato di un suo comando.</para> 17.17 17.18 &interaction.template.simple.normal; 17.19 17.20 @@ -17,7 +17,7 @@ 17.21 17.22 &interaction.template.simple.compact; 17.23 17.24 - <para id="x_57c">Lo stile <literal>changelog</literal> ci dà un'idea di quale sia il potere espressivo del motore di template di Mercurial. Questo stile tenta di seguire le linee guida per la formattazione di un registro dei cambiamenti stabilite dal progetto GNU <citation><xref linkend="bib:gnu"/></citation>.</para> 17.25 + <para id="x_57c">Lo stile <literal>changelog</literal> ci dà un’idea di quale sia il potere espressivo del motore di template di Mercurial. Questo stile tenta di seguire le linee guida per la formattazione di un registro dei cambiamenti stabilite dal progetto GNU <citation><xref linkend="bib:gnu"/></citation>.</para> 17.26 17.27 &interaction.template.simple.changelog; 17.28 17.29 @@ -48,7 +48,7 @@ 17.30 17.31 <para id="x_582">Nella sua forma più semplice, un template Mercurial è un frammento di testo. Parte del testo non cambia mai, mentre altre parti vengono <emphasis>espanse</emphasis>, cioè sostituite con nuovo testo, quando è necessario.</para> 17.32 17.33 - <para id="x_583">Prima di continuare, diamo un'altra occhiata al semplice esempio del normale risultato di un comando Mercurial.</para> 17.34 + <para id="x_583">Prima di continuare, diamo un’altra occhiata al semplice esempio del normale risultato di un comando Mercurial.</para> 17.35 17.36 &interaction.template.simple.normal; 17.37 17.38 @@ -56,15 +56,15 @@ 17.39 17.40 &interaction.template.simple.simplest; 17.41 17.42 - <para id="x_585">Questo esempio illustra il template più semplice possibile, composto solo da un messaggio di testo statico stampato una volta per ogni changeset. L'opzione <option role="hg-opt-log">--template</option> del comando <command role="hg-cmd">hg log</command> dice a Mercurial di usare il testo dato come template per stampare ogni changeset.</para> 17.43 - 17.44 - <para id="x_586">Notate che la stringa di template appena usata termina con il testo <quote><literal>\n</literal></quote>. Questa è una <emphasis>sequenza di escape</emphasis> che dice a Mercurial di stampare una carattere di nuova riga alla fine di ogni elemento di template. Se omettete questa nuova riga, Mercurial mostrerà un messaggio di testo di seguito all'altro. Leggete la <xref linkend="sec:template:escape"/> per maggiori dettagli sulle sequenze di escape.</para> 17.45 - 17.46 - <para id="x_587">Un template che stampa una stringa di testo fissa tutte le volte non è molto utile, perciò proviamo qualcosa di un po' più complesso.</para> 17.47 + <para id="x_585">Questo esempio illustra il template più semplice possibile, composto solo da un messaggio di testo statico stampato una volta per ogni changeset. L’opzione <option role="hg-opt-log">--template</option> del comando <command role="hg-cmd">hg log</command> dice a Mercurial di usare il testo dato come template per stampare ogni changeset.</para> 17.48 + 17.49 + <para id="x_586">Notate che la stringa di template appena usata termina con il testo <quote><literal>\n</literal></quote>. Questa è una <emphasis>sequenza di escape</emphasis> che dice a Mercurial di stampare una carattere di nuova riga alla fine di ogni elemento di template. Se omettete questa nuova riga, Mercurial mostrerà un messaggio di testo di seguito all’altro. Leggete la <xref linkend="sec:template:escape"/> per maggiori dettagli sulle sequenze di escape.</para> 17.50 + 17.51 + <para id="x_587">Un template che stampa una stringa di testo fissa tutte le volte non è molto utile, perciò proviamo qualcosa di un po’ più complesso.</para> 17.52 17.53 &interaction.template.simple.simplesub; 17.54 17.55 - <para id="x_588">Come potete vedere, la stringa <quote><literal>{desc}</literal></quote> nel template è stata sostituita con la descrizione di ogni changeset nel messaggio. Ogni volta che Mercurial trova un testo racchiuso tra parentesi graffe (<quote><literal>{</literal></quote> e <quote><literal>}</literal></quote>), proverà a sostituire le parentesi e il testo con l'espansione di qualunque cosa vi sia contenuta. Per stampare una parentesi graffa letterale dovete effettuarne l'escape, come descritto nella <xref linkend="sec:template:escape"/>.</para> 17.56 + <para id="x_588">Come potete vedere, la stringa <quote><literal>{desc}</literal></quote> nel template è stata sostituita con la descrizione di ogni changeset nel messaggio. Ogni volta che Mercurial trova un testo racchiuso tra parentesi graffe (<quote><literal>{</literal></quote> e <quote><literal>}</literal></quote>), proverà a sostituire le parentesi e il testo con l’espansione di qualunque cosa vi sia contenuta. Per stampare una parentesi graffa letterale dovete effettuarne l’escape, come descritto nella <xref linkend="sec:template:escape"/>.</para> 17.57 </sect1> 17.58 17.59 <sect1 id="sec:template:keyword"> 17.60 @@ -73,11 +73,11 @@ 17.61 <para id="x_589">Potete cominciare immediatamente a scrivere semplici template usando le seguenti parole chiave.</para> 17.62 17.63 <itemizedlist> 17.64 - <listitem><para id="x_58a"><literal role="template-keyword">author</literal>: stringa. Il nome non modificato dell'autore del changeset.</para> 17.65 + <listitem><para id="x_58a"><literal role="template-keyword">author</literal>: stringa. Il nome non modificato dell’autore del changeset.</para> 17.66 </listitem> 17.67 <listitem><para id="x_58b"><literal role="template-keyword">branches</literal>: stringa. Il nome del ramo su cui il changeset è stato inserito. Sarà vuoto se il nome del ramo è <literal>default</literal>.</para> 17.68 </listitem> 17.69 - <listitem><para id="x_58c"><literal role="template-keyword">date</literal>: informazioni di data. La data in cui il changeset è stato inserito. Questa informazione <emphasis>non</emphasis> è rappresentata in maniera comprensibile, bensì dovete passarla attraverso un filtro per presentarla in maniera appropriata. Leggete la <xref linkend="sec:template:filter"/> per maggiori informazioni sui filtri. La data viene espressa come una coppia di numeri. Il primo numero è una marcatura temporale che segue l'UTC Unix (e indica il numero di secondi trascorsi dal 1° gennaio 1970); il secondo è la differenza tra il fuso orario dell'autore del commit e l'UTC, espressa in secondi.</para> 17.70 + <listitem><para id="x_58c"><literal role="template-keyword">date</literal>: informazioni di data. La data in cui il changeset è stato inserito. Questa informazione <emphasis>non</emphasis> è rappresentata in maniera comprensibile, bensì dovete passarla attraverso un filtro per presentarla in maniera appropriata. Leggete la <xref linkend="sec:template:filter"/> per maggiori informazioni sui filtri. La data viene espressa come una coppia di numeri. Il primo numero è una marcatura temporale che segue l’UTC Unix (e indica il numero di secondi trascorsi dal 1° gennaio 1970); il secondo è la differenza tra il fuso orario dell’autore del commit e l’UTC, espressa in secondi.</para> 17.71 </listitem> 17.72 <listitem><para id="x_58d"><literal role="template-keyword">desc</literal>: stringa. Il testo della descrizione del changeset.</para> 17.73 </listitem> 17.74 @@ -87,7 +87,7 @@ 17.75 </listitem> 17.76 <listitem><para id="x_590"><literal role="template-keyword">file_dels</literal>: lista di stringhe. I file rimossi da questo changeset.</para> 17.77 </listitem> 17.78 - <listitem><para id="x_591"><literal role="template-keyword">node</literal>: stringa. L'hash di identificazione del changeset, sotto forma di una stringa esadecimale di 40 caratteri.</para> 17.79 + <listitem><para id="x_591"><literal role="template-keyword">node</literal>: stringa. L’hash di identificazione del changeset, sotto forma di una stringa esadecimale di 40 caratteri.</para> 17.80 </listitem> 17.81 <listitem><para id="x_592"><literal role="template-keyword">parents</literal>: lista di stringhe. I genitori del changeset.</para> 17.82 </listitem> 17.83 @@ -101,7 +101,7 @@ 17.84 17.85 &interaction.template.simple.keywords; 17.86 17.87 - <para id="x_596">Come abbiamo notato prima, la parola chiave per la data non produce un risultato comprensibile, così dobbiamo trattarla in maniera speciale. Questo implica l'uso dei <emphasis>filtri</emphasis>, che verranno trattati in maniera più approfondita nella <xref linkend="sec:template:filter"/>.</para> 17.88 + <para id="x_596">Come abbiamo notato prima, la parola chiave per la data non produce un risultato comprensibile, così dobbiamo trattarla in maniera speciale. Questo implica l’uso dei <emphasis>filtri</emphasis>, che verranno trattati in maniera più approfondita nella <xref linkend="sec:template:filter"/>.</para> 17.89 17.90 &interaction.template.simple.datekeyword; 17.91 </sect1> 17.92 @@ -128,20 +128,20 @@ 17.93 <listitem><para id="x_59e"><literal>\}</literal>: parentesi graffa chusa, <quote><literal>}</literal></quote>, codice ASCII 175.</para> 17.94 </listitem></itemizedlist> 17.95 17.96 - <para id="x_59f">Come appena indicato, se volete che l'espansione di un template contenga un carattere <quote><literal>\</literal></quote>, <quote><literal>{</literal></quote>, o <quote><literal>{</literal></quote> letterale, dovete effettuarne l'escape.</para> 17.97 + <para id="x_59f">Come appena indicato, se volete che l’espansione di un template contenga un carattere <quote><literal>\</literal></quote>, <quote><literal>{</literal></quote>, o <quote><literal>{</literal></quote> letterale, dovete effettuarne l’escape.</para> 17.98 </sect1> 17.99 17.100 <sect1 id="sec:template:filter"> 17.101 <title>Filtrare le parole chiave per modificarne i risultati</title> 17.102 17.103 - <para id="x_5a0">Alcuni dei risultati dell'espansione dei template non sono immediatamente facili da usare. Mercurial vi permette di specificare una catena opzionale di <emphasis>filtri</emphasis> per modificare il risultato dell'espansione di una parola chiave. Avete già visto in azione un filtro comune, <literal role="template-kw-filt-date">isodate</literal>, usato precedentemente per rendere leggibile una data.</para> 17.104 - 17.105 - <para id="x_5a1">Qui di seguito viene presentata una lista dei filtri più comunemente usati che Mercurial supporta. Mentre alcuni filtri possono essere applicati a qualunque testo, altri possono essere usati solo in circostanze specifiche. Il nome di ogni filtro è seguito prima da un'indicazione del contesto in cui può essere usato e poi da una descrizione dei suoi effetti.</para> 17.106 + <para id="x_5a0">Alcuni dei risultati dell’espansione dei template non sono immediatamente facili da usare. Mercurial vi permette di specificare una catena opzionale di <emphasis>filtri</emphasis> per modificare il risultato dell’espansione di una parola chiave. Avete già visto in azione un filtro comune, <literal role="template-kw-filt-date">isodate</literal>, usato precedentemente per rendere leggibile una data.</para> 17.107 + 17.108 + <para id="x_5a1">Qui di seguito viene presentata una lista dei filtri più comunemente usati che Mercurial supporta. Mentre alcuni filtri possono essere applicati a qualunque testo, altri possono essere usati solo in circostanze specifiche. Il nome di ogni filtro è seguito prima da un’indicazione del contesto in cui può essere usato e poi da una descrizione dei suoi effetti.</para> 17.109 17.110 <itemizedlist> 17.111 - <listitem><para id="x_5a2"><literal role="template-filter">addbreaks</literal>: qualunque testo. Aggiunge un elemento XHTML <quote><literal><br/></literal></quote> prima della fine di ogni riga tranne l'ultima. Per esempio, <quote><literal>foo\nbar</literal></quote> diventa <quote><literal>foo<br/>\nbar</literal></quote>.</para> 17.112 - </listitem> 17.113 - <listitem><para id="x_5a3"><literal role="template-kw-filt-date">age</literal>: parola chiave <literal role="template-keyword">date</literal>. Rappresenta l'età della data, relativa all'ora corrente. Produce stringhe come <quote><literal>10 minuti</literal></quote>.</para> 17.114 + <listitem><para id="x_5a2"><literal role="template-filter">addbreaks</literal>: qualunque testo. Aggiunge un elemento XHTML <quote><literal><br/></literal></quote> prima della fine di ogni riga tranne l’ultima. Per esempio, <quote><literal>foo\nbar</literal></quote> diventa <quote><literal>foo<br/>\nbar</literal></quote>.</para> 17.115 + </listitem> 17.116 + <listitem><para id="x_5a3"><literal role="template-kw-filt-date">age</literal>: parola chiave <literal role="template-keyword">date</literal>. Rappresenta l’età della data, relativa all’ora corrente. Produce stringhe come <quote><literal>10 minuti</literal></quote>.</para> 17.117 </listitem> 17.118 <listitem><para id="x_5a4"><literal role="template-filter">basename</literal>: qualunque testo, ma utile soprattutto per la parola chiave <literal role="template-keyword">files</literal> e simili. Tratta il testo come un percorso e restituisce il nome di base. Per esempio, <quote><literal>foo/bar/baz</literal></quote> diventa <quote><literal>baz</literal></quote>.</para> 17.119 </listitem> 17.120 @@ -171,22 +171,22 @@ 17.121 </listitem> 17.122 <listitem><para id="x_5b1"><literal role="template-kw-filt-node">short</literal>: hash di changeset. Produce la forma breve di un hash di changeset, cioè una stringa esadecimale di 12 caratteri.</para> 17.123 </listitem> 17.124 - <listitem><para id="x_5b2"><literal role="template-kw-filt-date">shortdate</literal>: parola chiave <literal role="template-keyword">date</literal>. Rappresenta l'anno, il mese e il giorno della data. Produce una stringa come <quote><literal>2006-09-04</literal></quote>.</para> 17.125 - </listitem> 17.126 - <listitem><para id="x_5b3"><literal role="template-filter">strip</literal>: qualunque testo. Rimuove lo spazio bianco all'inizio e alla fine di una stringa.</para> 17.127 + <listitem><para id="x_5b2"><literal role="template-kw-filt-date">shortdate</literal>: parola chiave <literal role="template-keyword">date</literal>. Rappresenta l’anno, il mese e il giorno della data. Produce una stringa come <quote><literal>2006-09-04</literal></quote>.</para> 17.128 + </listitem> 17.129 + <listitem><para id="x_5b3"><literal role="template-filter">strip</literal>: qualunque testo. Rimuove lo spazio bianco all’inizio e alla fine di una stringa.</para> 17.130 </listitem> 17.131 <listitem><para id="x_5b4"><literal role="template-filter">tabindent</literal>: qualunque testo. Produce il testo, facendo cominciare ogni riga tranne la prima con un carattere di tabulazione.</para> 17.132 </listitem> 17.133 - <listitem><para id="x_5b5"><literal role="template-filter">urlescape</literal>: qualunque testo. Effettua l'escape di tutti i caratteri che sono considerati <quote>speciali</quote> dai riconoscitori di URL. Per esempio, <literal>foo bar</literal> diventa <literal>foo%20bar</literal>.</para> 17.134 - </listitem> 17.135 - <listitem><para id="x_5b6"><literal role="template-kw-filt-author">user</literal>: qualunque testo, ma utile soprattutto per la parola chiave <literal role="template-keyword">author</literal>. Restituisce la porzione dell'<quote>utente</quote> di un indirizzo email. Per esempio <quote><literal>Bryan O'Sullivan <bos@serpentine.com></literal></quote> diventa <quote><literal>bos</literal></quote>.</para> 17.136 + <listitem><para id="x_5b5"><literal role="template-filter">urlescape</literal>: qualunque testo. Effettua l’escape di tutti i caratteri che sono considerati <quote>speciali</quote> dai riconoscitori di URL. Per esempio, <literal>foo bar</literal> diventa <literal>foo%20bar</literal>.</para> 17.137 + </listitem> 17.138 + <listitem><para id="x_5b6"><literal role="template-kw-filt-author">user</literal>: qualunque testo, ma utile soprattutto per la parola chiave <literal role="template-keyword">author</literal>. Restituisce la porzione dell’<quote>utente</quote> di un indirizzo email. Per esempio <quote><literal>Bryan O'Sullivan <bos@serpentine.com></literal></quote> diventa <quote><literal>bos</literal></quote>.</para> 17.139 </listitem> 17.140 </itemizedlist> 17.141 17.142 &interaction.template.simple.manyfilters; 17.143 17.144 <note> 17.145 - <para id="x_5b7">Se provate ad applicare un filtro a un frammento di dati che non può elaborare, Mercurial fallirà e stamperà un'eccezione Python. Per esempio, non è una buona idea provare a utilizzare l'output della parola chiave <literal role="template-keyword">desc</literal> con il filtro <literal role="template-kw-filt-date">isodate</literal>.</para> 17.146 + <para id="x_5b7">Se provate ad applicare un filtro a un frammento di dati che non può elaborare, Mercurial fallirà e stamperà un’eccezione Python. Per esempio, non è una buona idea provare a utilizzare l’output della parola chiave <literal role="template-keyword">desc</literal> con il filtro <literal role="template-kw-filt-date">isodate</literal>.</para> 17.147 </note> 17.148 17.149 <sect2> 17.150 @@ -196,9 +196,9 @@ 17.151 17.152 &interaction.template.simple.combine; 17.153 17.154 - <para id="x_5b9">Notate l'uso di <quote><literal>\t</literal></quote> (un carattere di tabulazione) nel template per indentare la prima riga, necessario dato che <literal role="template-keyword">tabindent</literal> indenta tutte le righe <emphasis>tranne</emphasis> la prima.</para> 17.155 - 17.156 - <para id="x_5ba">Tenete a mente che l'ordine dei filtri in una catena è significativo. Il primo filtro viene applicato al risultato della parola chiave, il secondo al risultato del primo filtro, e così via. Per esempio, usare <literal>fill68|tabindent</literal> dà risultati molto diversi rispetto a <literal>tabindent|fill68</literal>.</para> 17.157 + <para id="x_5b9">Notate l’uso di <quote><literal>\t</literal></quote> (un carattere di tabulazione) nel template per indentare la prima riga, necessario dato che <literal role="template-keyword">tabindent</literal> indenta tutte le righe <emphasis>tranne</emphasis> la prima.</para> 17.158 + 17.159 + <para id="x_5ba">Tenete a mente che l’ordine dei filtri in una catena è significativo. Il primo filtro viene applicato al risultato della parola chiave, il secondo al risultato del primo filtro, e così via. Per esempio, usare <literal>fill68|tabindent</literal> dà risultati molto diversi rispetto a <literal>tabindent|fill68</literal>.</para> 17.160 </sect2> 17.161 </sect1> 17.162 17.163 @@ -207,7 +207,7 @@ 17.164 17.165 <para id="x_5bb">Un template a riga di comando fornisce un modo semplice e veloce per formattare il risultato di un certo comando. Ma i template possono diventare prolissi, quindi è utile essere in grado di dare un nome a un template. Un file di stile è un template con un nome, memorizzato in un file.</para> 17.166 17.167 - <para id="x_5bc">Ma soprattutto, l'impiego di un file di stile sfrutta la potenza del motore di template di Mercurial in modi che non sono possibili usando l'opzione <option role="hg-opt-log">--template</option> a riga di comando.</para> 17.168 + <para id="x_5bc">Ma soprattutto, l’impiego di un file di stile sfrutta la potenza del motore di template di Mercurial in modi che non sono possibili usando l’opzione <option role="hg-opt-log">--template</option> a riga di comando.</para> 17.169 17.170 <sect2> 17.171 <title>Il più semplice dei file di stile</title> 17.172 @@ -227,15 +227,15 @@ 17.173 <itemizedlist> 17.174 <listitem><para id="x_5c0">Il file viene elaborato una riga alla volta.</para> 17.175 </listitem> 17.176 - <listitem><para id="x_5c1">Gli spazi bianchi all'inizio e alla fine di una riga vengono ignorati.</para> 17.177 + <listitem><para id="x_5c1">Gli spazi bianchi all’inizio e alla fine di una riga vengono ignorati.</para> 17.178 </listitem> 17.179 <listitem><para id="x_5c2">Le righe vuote vengono saltate.</para> 17.180 </listitem> 17.181 - <listitem><para id="x_5c3">Se una riga comincia con un carattere <quote><literal>#</literal></quote> o <quote><literal>;</literal></quote>, l'intera riga viene trattata come un commento e saltata come se fosse vuota.</para> 17.182 + <listitem><para id="x_5c3">Se una riga comincia con un carattere <quote><literal>#</literal></quote> o <quote><literal>;</literal></quote>, l’intera riga viene trattata come un commento e saltata come se fosse vuota.</para> 17.183 </listitem> 17.184 <listitem><para id="x_5c4">Una riga comincia con una parola chiave, che deve iniziare con un carattere alfabetico o di sottolineatura e successivamente può contenere qualsiasi carattere alfanumerico o di sottolineatura. (Nella notazione per le espressioni regolari, una parola chiave deve corrispondere a <literal>[A-Za-z_][A-Za-z0-9_]*</literal>.)</para> 17.185 </listitem> 17.186 - <listitem><para id="x_5c5">L'elemento successivo deve essere un carattere <quote><literal>=</literal></quote>, che può essere preceduto o seguito da una quantità arbitraria di spazio bianco.</para> 17.187 + <listitem><para id="x_5c5">L’elemento successivo deve essere un carattere <quote><literal>=</literal></quote>, che può essere preceduto o seguito da una quantità arbitraria di spazio bianco.</para> 17.188 </listitem> 17.189 <listitem><para id="x_5c6">Se il resto della riga comincia e finisce con caratteri corrispettivi di apice o di virgolette, viene trattato come il corpo di un template.</para> 17.190 </listitem> 17.191 @@ -266,15 +266,15 @@ 17.192 <listitem><para id="x_5cc">Il primo componente è semplicemente il modo in cui Mercurial dice <quote>rinuncio</quote>.</para> 17.193 <programlisting>___fallimento___: stile.errato:1: errore di riconoscimento</programlisting> 17.194 </listitem> 17.195 - <listitem><para id="x_5cd">Subito dopo, trovate il nome del file di stile che contiene l'errore.</para> 17.196 + <listitem><para id="x_5cd">Subito dopo, trovate il nome del file di stile che contiene l’errore.</para> 17.197 <programlisting>fallimento: ___stile.errato___:1: errore di riconoscimento</programlisting> 17.198 </listitem> 17.199 - <listitem><para id="x_5ce">Il nome del file è seguito dal numero di riga dove l'errore è stato incontrato.</para> 17.200 + <listitem><para id="x_5ce">Il nome del file è seguito dal numero di riga dove l’errore è stato incontrato.</para> 17.201 <programlisting>fallimento: stile.errato:___1___: errore di riconoscimento</programlisting> 17.202 </listitem> 17.203 <listitem><para id="x_5cf">Infine, viene fornita una descrizione di quello che è andato storto.</para> 17.204 <programlisting>fallimento: stile.errato:1: ___errore di riconoscimento___</programlisting> 17.205 - <para id="x_5d0">La descrizione del problema non è sempre chiara (come in questo caso) ma, anche quando è criptica, è quasi sempre banale trovare la causa dell'errore inspezionando visivamente la riga del file di stile che contiene il problema.</para> 17.206 + <para id="x_5d0">La descrizione del problema non è sempre chiara (come in questo caso) ma, anche quando è criptica, è quasi sempre banale trovare la causa dell’errore inspezionando visivamente la riga del file di stile che contiene il problema.</para> 17.207 </listitem> 17.208 </itemizedlist> 17.209 </sect2> 17.210 @@ -290,13 +290,13 @@ 17.211 <itemizedlist> 17.212 <listitem><para id="x_5d3">Questa tecnica non funzionerà in un repository completamente vuoto, perché un tale repository non possiede la revisione zero.</para> 17.213 </listitem> 17.214 - <listitem><para id="x_5d4">Questa tecnica non funzionerà nemmeno nel caso (estremamente raro) in cui un repository sia l'unione di due o più repository precedentemente indipendenti e quei repository siano ancora nei paraggi.</para> 17.215 + <listitem><para id="x_5d4">Questa tecnica non funzionerà nemmeno nel caso (estremamente raro) in cui un repository sia l’unione di due o più repository precedentemente indipendenti e quei repository siano ancora nei paraggi.</para> 17.216 </listitem></itemizedlist> 17.217 <para id="x_5d5">Ecco alcuni usi che potete fare di questo identificatore:</para> 17.218 <itemizedlist> 17.219 <listitem><para id="x_5d6">come chiave nella tabella di un database che gestisce i repository presenti su un server;</para> 17.220 </listitem> 17.221 - <listitem><para id="x_5d7">come metà di una tupla {<emphasis>identificatore di repository</emphasis>, <emphasis>identificatore di revisione</emphasis>}. Salvate questa informazione da qualche parte quando eseguite un assemblaggio automatico o un'altra attività simile, in modo che possiate <quote>rieseguire</quote> lo stesso assemblaggio in seguito se necessario.</para> 17.222 + <listitem><para id="x_5d7">come metà di una tupla {<emphasis>identificatore di repository</emphasis>, <emphasis>identificatore di revisione</emphasis>}. Salvate questa informazione da qualche parte quando eseguite un assemblaggio automatico o un’altra attività simile, in modo che possiate <quote>rieseguire</quote> lo stesso assemblaggio in seguito se necessario.</para> 17.223 </listitem> 17.224 </itemizedlist> 17.225 </sect2> 17.226 @@ -322,11 +322,11 @@ 17.227 17.228 <para id="x_5da">Questo template si discosta in alcuni modi dalla presentazione prodotta da Subversion.</para> 17.229 <itemizedlist> 17.230 - <listitem><para id="x_5db">Subversion stampa una data <quote>leggibile</quote> (il <quote><literal>Wed, 27 Sep 2006</literal></quote> nel risultato dell'esempio precedente) tra parentesi. Il motore di template di Mercurial non fornisce un modo per visualizzare una data in questo formato senza stampare anche l'ora e il fuso orario.</para> 17.231 + <listitem><para id="x_5db">Subversion stampa una data <quote>leggibile</quote> (il <quote><literal>Wed, 27 Sep 2006</literal></quote> nel risultato dell’esempio precedente) tra parentesi. Il motore di template di Mercurial non fornisce un modo per visualizzare una data in questo formato senza stampare anche l’ora e il fuso orario.</para> 17.232 </listitem> 17.233 <listitem><para id="x_5dc">Emuliamo la stampa di righe <quote>separatrici</quote> piene di caratteri <quote><literal>-</literal></quote> da parte di Subversion concludendo il template con una riga di quel tipo. Usiamo la parola chiave <literal role="template-keyword">header</literal> del motore di template per stampare una riga separatrice come prima riga (vedete più avanti), quindi ottenendo un risultato simile a quello di Subversion.</para> 17.234 </listitem> 17.235 - <listitem><para id="x_5dd">Il formato di Subversion include nell'intestazione il conteggio del numero di righe del messaggio di commit. Non possiamo replicare questa caratteristica in Mercurial, poiché attualmente il motore di template non fornisce un filtro che conti il numero di righe generate dal template.</para> 17.236 + <listitem><para id="x_5dd">Il formato di Subversion include nell’intestazione il conteggio del numero di righe del messaggio di commit. Non possiamo replicare questa caratteristica in Mercurial, poiché attualmente il motore di template non fornisce un filtro che conti il numero di righe generate dal template.</para> 17.237 </listitem></itemizedlist> 17.238 <para id="x_5de">Non mi ci sono voluti più di uno o due minuti di lavoro per sostituire il testo letterale di un esempio del messaggio di Subversion con alcune parole chiave e alcuni filtri per ottenere il template appena visto. Il file di stile fa semplicemente riferimento al template.</para> 17.239
18.1 --- a/it/ch12-mq.xml Sat Aug 22 21:01:56 2009 +0200 18.2 +++ b/it/ch12-mq.xml Sat Aug 22 21:55:05 2009 +0200 18.3 @@ -5,17 +5,17 @@ 18.4 <sect1 id="sec:mq:patch-mgmt"> 18.5 <title>Il problema della gestione delle patch</title> 18.6 18.7 - <para id="x_3ac">Ecco uno scenario comune: avete bisogno di installare un pacchetto software dai sorgenti, ma trovate un bug che dovete correggere nei sorgenti prima di poter cominciare a usare il pacchetto. Fate le vostre modifiche, vi dimenticate del pacchetto per un po' e alcuni mesi dopo avete bisogno di aggiornare il pacchetto a una nuova versione. Se la versione più nuova del pacchetto contiene ancora il bug, dovete estrarre la vostra correzione dal vecchio albero dei sorgenti e applicarla alla nuova versione. Questa è un'attività seccante durante la quale è facile commettere errori.</para> 18.8 - 18.9 - <para id="x_3ad">Questo è un semplice caso del problema di <quote>gestione delle patch</quote>. Avete un albero di sorgenti <quote>a monte</quote> che non potete cambiare, avete bisogno di fare alcune modifiche locali all'albero a monte e vi piacerebbe essere in grado di mantenere separate quelle modifiche, in modo da poterle applicare a nuove versioni dei sorgenti a monte.</para> 18.10 + <para id="x_3ac">Ecco uno scenario comune: avete bisogno di installare un pacchetto software dai sorgenti, ma trovate un bug che dovete correggere nei sorgenti prima di poter cominciare a usare il pacchetto. Fate le vostre modifiche, vi dimenticate del pacchetto per un po’ e alcuni mesi dopo avete bisogno di aggiornare il pacchetto a una nuova versione. Se la versione più nuova del pacchetto contiene ancora il bug, dovete estrarre la vostra correzione dal vecchio albero dei sorgenti e applicarla alla nuova versione. Questa è un’attività seccante durante la quale è facile commettere errori.</para> 18.11 + 18.12 + <para id="x_3ad">Questo è un semplice caso del problema di <quote>gestione delle patch</quote>. Avete un albero di sorgenti <quote>a monte</quote> che non potete cambiare, avete bisogno di fare alcune modifiche locali all’albero a monte e vi piacerebbe essere in grado di mantenere separate quelle modifiche, in modo da poterle applicare a nuove versioni dei sorgenti a monte.</para> 18.13 18.14 <para id="x_3ae">Il problema di gestione delle patch si presenta in molte situazioni. Probabilmente la più visibile è quella in cui un utente di un progetto software open source fornisce la correzione di un bug o una nuova funzione sotto forma di patch ai manutentori del progetto.</para> 18.15 18.16 <para id="x_3af">Chi distribuisce sistemi operativi che includono software open source ha spesso bisogno di effettuare modifiche ai pacchetti distribuiti in modo da assemblarli correttamente nel proprio ambiente.</para> 18.17 18.18 - <para id="x_3b0">Quando dovete mantenere solo alcune modifiche, potete facilmente gestire una singola patch usando i programmi standard <command>diff</command> e <command>patch</command> (si veda la <xref linkend="sec:mq:patch"/> per una discussione di questi strumenti). Una volta che il numero di modifiche cresce, comincia ad avere senso l'idea di mantenere le patch come <quote>frammenti di lavoro</quote> distinti in modo che, per esempio, una singola patch contenga solo una correzione di bug (la patch potrebbe modificare diversi file, ma sta facendo <quote>solo una cosa</quote>) e un certo numero di queste patch sia destinato a bug differenti che dovete correggere e a modifiche locali di cui avete bisogno. In questa situazione, se proponete una patch per la correzione di un bug ai manutentori del pacchetto a monte e questi includono la vostra correzione in una release successiva, potete semplicemente scartare quella singola patch quando state aggiornando il pacchetto a una nuova release.</para> 18.19 - 18.20 - <para id="x_3b1">Mantenere una singola patch per un albero a monte è un'attività un po' noiosa e soggetta a errori, ma non è difficile. Tuttavia, la complessità del problema cresce rapidamente man mano che il numero di patch che dovete mantenere aumenta. Con più di un piccolo numero di patch in mano, il compito di capire quali sono quelle che dovete applicare e di mantenerle passa da sgradevole a opprimente.</para> 18.21 + <para id="x_3b0">Quando dovete mantenere solo alcune modifiche, potete facilmente gestire una singola patch usando i programmi standard <command>diff</command> e <command>patch</command> (si veda la <xref linkend="sec:mq:patch"/> per una discussione di questi strumenti). Una volta che il numero di modifiche cresce, comincia ad avere senso l’idea di mantenere le patch come <quote>frammenti di lavoro</quote> distinti in modo che, per esempio, una singola patch contenga solo una correzione di bug (la patch potrebbe modificare diversi file, ma sta facendo <quote>solo una cosa</quote>) e un certo numero di queste patch sia destinato a bug differenti che dovete correggere e a modifiche locali di cui avete bisogno. In questa situazione, se proponete una patch per la correzione di un bug ai manutentori del pacchetto a monte e questi includono la vostra correzione in una release successiva, potete semplicemente scartare quella singola patch quando state aggiornando il pacchetto a una nuova release.</para> 18.22 + 18.23 + <para id="x_3b1">Mantenere una singola patch per un albero a monte è un’attività un po’ noiosa e soggetta a errori, ma non è difficile. Tuttavia, la complessità del problema cresce rapidamente man mano che il numero di patch che dovete mantenere aumenta. Con più di un piccolo numero di patch in mano, il compito di capire quali sono quelle che dovete applicare e di mantenerle passa da sgradevole a opprimente.</para> 18.24 18.25 <para id="x_3b2">Fortunatamente, Mercurial include una potente estensione, chiamata Mercurial Queues (letteralmente, Code di Mercurial) o semplicemente <quote>MQ</quote>, che semplifica notevolmente il problema di gestione delle patch.</para> 18.26 18.27 @@ -23,20 +23,20 @@ 18.28 <sect1 id="sec:mq:history"> 18.29 <title>La preistoria di Mercurial Queues</title> 18.30 18.31 - <para id="x_3b3">Verso la fine degli anni '90, diversi sviluppatori del kernel di Linux cominciarono a mantenere alcune <quote>serie di patch</quote> che modificavano il comportamento del kernel. Alcune di queste serie si concentravano sulla stabilità, alcune sull'inclusione di funzioni e altre erano più sperimentali.</para> 18.32 + <para id="x_3b3">Verso la fine degli anni ’90, diversi sviluppatori del kernel di Linux cominciarono a mantenere alcune <quote>serie di patch</quote> che modificavano il comportamento del kernel. Alcune di queste serie si concentravano sulla stabilità, alcune sull’inclusione di funzioni e altre erano più sperimentali.</para> 18.33 18.34 <para id="x_3b4">La dimensione di queste serie di patch crebbe rapidamente. Nel 2002, Andrew Morton pubblicò alcuni script di shell che aveva usato per automatizzare la gestione delle proprie code di patch. Andrew era riuscito a usare questi script per gestire centinaia (talvolta migliaia) di patch per il kernel di Linux.</para> 18.35 18.36 <sect2 id="sec:mq:quilt"> 18.37 <title>Una <quote>coperta a scacchi</quote></title> 18.38 18.39 - <para id="x_3b5">All'inizio del 2003, Andreas Gruenbacher e Martin Quinson presero in prestito l'approccio degli script di Andrew e pubblicarono uno strumento chiamato <quote>patchwork quilt</quote> (letteralmente, coperta a scacchi) <citation><xref linkend="bib:quilt"/></citation>, o semplicemente <quote>quilt</quote> (si veda <citation><xref linkend="bib:gru05"/></citation> per un articolo che lo descrive). Dato che quilt sostanzialmente automatizzava la gestione delle patch, guadagnò rapidamente un grande seguito tra gli sviluppatori di software open source.</para> 18.40 + <para id="x_3b5">All’inizio del 2003, Andreas Gruenbacher e Martin Quinson presero in prestito l’approccio degli script di Andrew e pubblicarono uno strumento chiamato <quote>patchwork quilt</quote> (letteralmente, coperta a scacchi) <citation><xref linkend="bib:quilt"/></citation>, o semplicemente <quote>quilt</quote> (si veda <citation><xref linkend="bib:gru05"/></citation> per un articolo che lo descrive). Dato che quilt sostanzialmente automatizzava la gestione delle patch, guadagnò rapidamente un grande seguito tra gli sviluppatori di software open source.</para> 18.41 18.42 <para id="x_3b6">Quilt gestisce una <emphasis>pila di patch</emphasis> per un albero di directory. Per cominciare a usarlo, dite a quilt di gestire un albero di directory e quali file volete che gestisca, in modo che memorizzi i nomi e il contenuto di quei file. Per correggere un bug, create una nuova patch (usando un singolo comando), modificate i file che dovete correggere, poi <quote>aggiornate</quote> la patch.</para> 18.43 18.44 - <para id="x_3b7">L'operazione di aggiornamento induce quilt a esaminare l'albero di directory completando la patch con tutte le modifiche che avete fatto. Sulla base di questa prima patch, potete creare un'altra patch che terrà traccia dei cambiamenti richiesti per modificare l'albero da <quote>albero con una patch applicata</quote> ad <quote>albero con due patch applicate</quote>.</para> 18.45 - 18.46 - <para id="x_3b8">Potete <emphasis>scegliere</emphasis> quali sono le patch da applicare all'albero. Se <quote>estraete</quote> una patch, i cambiamenti effettuati da quella patch spariranno dall'albero di directory. Quilt si ricorda quali patch avete estratto, comunque, così potete <quote>inserire</quote> nuovamente una patch estratta e l'albero di directory verrà ripristinato per contenere le modifiche di quella patch. La cosa più importante è che potete eseguire il comando di <quote>aggiornamento</quote> in ogni momento e la patch applicata più recentemente verrà aggiornata. Questo significa che, in ogni momento, potete modificare sia l'insieme delle patch da applicare sia l'insieme dei cambiamenti effettuati da quelle patch.</para> 18.47 + <para id="x_3b7">L’operazione di aggiornamento induce quilt a esaminare l’albero di directory completando la patch con tutte le modifiche che avete fatto. Sulla base di questa prima patch, potete creare un’altra patch che terrà traccia dei cambiamenti richiesti per modificare l’albero da <quote>albero con una patch applicata</quote> ad <quote>albero con due patch applicate</quote>.</para> 18.48 + 18.49 + <para id="x_3b8">Potete <emphasis>scegliere</emphasis> quali sono le patch da applicare all’albero. Se <quote>estraete</quote> una patch, i cambiamenti effettuati da quella patch spariranno dall’albero di directory. Quilt si ricorda quali patch avete estratto, comunque, così potete <quote>inserire</quote> nuovamente una patch estratta e l’albero di directory verrà ripristinato per contenere le modifiche di quella patch. La cosa più importante è che potete eseguire il comando di <quote>aggiornamento</quote> in ogni momento e la patch applicata più recentemente verrà aggiornata. Questo significa che, in ogni momento, potete modificare sia l’insieme delle patch da applicare sia l’insieme dei cambiamenti effettuati da quelle patch.</para> 18.50 18.51 <para id="x_3b9">Quilt non ha nulla a che fare con gli strumenti di controllo di revisione, così funziona altrettanto bene con un gruppo di file estratti da un archivio compresso che con una copia di lavoro di Subversion.</para> 18.52 </sect2> 18.53 @@ -44,7 +44,7 @@ 18.54 <sect2 id="sec:mq:quilt-mq"> 18.55 <title>Da patchwork quilt a Mercurial Queues</title> 18.56 18.57 - <para id="x_3ba">A metà del 2005, Chris Mason prese le funzioni di quilt e implementò un'estensione chiamata Mercurial Queues, che aggiungeva a Mercurial un comportamento simile a quello di quilt.</para> 18.58 + <para id="x_3ba">A metà del 2005, Chris Mason prese le funzioni di quilt e implementò un’estensione chiamata Mercurial Queues, che aggiungeva a Mercurial un comportamento simile a quello di quilt.</para> 18.59 18.60 <para id="x_3bb">La differenza chiave tra quilt e MQ è che quilt non è progettato per interagire con alcun sistema di controllo di revisione, mentre MQ è <emphasis>integrata</emphasis> in Mercurial. Ogni patch che inserite è rappresentata sotto forma di changeset Mercurial. Se estraete una patch, il changeset relativo sparisce.</para> 18.61 18.62 @@ -53,37 +53,37 @@ 18.63 </sect2> 18.64 </sect1> 18.65 <sect1> 18.66 - <title>L'enorme vantaggio di MQ</title> 18.67 - 18.68 - <para id="x_3bd">Non posso esagerare il valore dell'unificazione tra patch e controllo di revisione offerta da MQ.</para> 18.69 - 18.70 - <para id="x_3be">Una delle ragioni principali per cui le patch sono ancora continuamente usate nel mondo del software libero e open source&emdash;nonostante la disponibilità di strumenti di controllo di revisione sempre più sofisticati&emdash;è l'<emphasis>agilità</emphasis> che offrono.</para> 18.71 - 18.72 - <para id="x_3bf">I tradizionali strumenti di controllo di revisione effettuano una registrazione permanente di ogni vostra azione. Da un lato questo ha un grande valore, ma dall'altro è anche piuttosto soffocante. Se volete effettuare un esperimento stravagante, dovete stare molto attenti a come procedete, o rischiate di lasciare tracce inutili&emdash;o peggio, ingannevoli e destabilizzanti&emdash;dei vostri passi falsi e dei vostri errori nella registrazione permanente delle revisioni.</para> 18.73 - 18.74 - <para id="x_3c0">Al contrario, il matrimonio tra controllo di revisione distribuito e patch realizzato da MQ rende molto più facile isolare il vostro lavoro. Le vostre patch si basano sulla normale cronologia delle revisioni e potete farle sparire e comparire a piacere. Se non vi piace una patch, potete scartarla. Se una patch non è esattamente come volete che sia, vi basta correggerla&emdash;tutte le volte che ne avete bisogno, fino a quando non l'avete ritoccata facendole assumere la forma che desiderate.</para> 18.75 - 18.76 - <para id="x_3c1">Per esempio, l'integrazione delle patch con il controllo di revisione facilita <emphasis>enormemente</emphasis> la comprensione delle patch e delle interazioni con il codice su cui si basano, nonché la correzione dei loro effetti. Dato che ogni patch applicata è associata a un changeset, potete invocare <command role="hg-cmd">hg log</command> con un nome di file per vedere quali changeset e quali patch hanno avuto effetto sul file. Potete usare il comando <command role="hg-cmd">hg bisect</command> per condurre una ricerca binaria attraverso tutti i changeset e le patch applicate in modo da scoprire dov'è stato introdotto o corretto un bug. Potete usare il comando <command role="hg-cmd">hg annotate</command> per vedere quali changeset o patch hanno modificato una particolare riga di un file sorgente. E così via.</para> 18.77 + <title>L’enorme vantaggio di MQ</title> 18.78 + 18.79 + <para id="x_3bd">Non posso esagerare il valore dell’unificazione tra patch e controllo di revisione offerta da MQ.</para> 18.80 + 18.81 + <para id="x_3be">Una delle ragioni principali per cui le patch sono ancora continuamente usate nel mondo del software libero e open source&emdash;nonostante la disponibilità di strumenti di controllo di revisione sempre più sofisticati&emdash;è l’<emphasis>agilità</emphasis> che offrono.</para> 18.82 + 18.83 + <para id="x_3bf">I tradizionali strumenti di controllo di revisione effettuano una registrazione permanente di ogni vostra azione. Da un lato questo ha un grande valore, ma dall’altro è anche piuttosto soffocante. Se volete effettuare un esperimento stravagante, dovete stare molto attenti a come procedete, o rischiate di lasciare tracce inutili&emdash;o peggio, ingannevoli e destabilizzanti&emdash;dei vostri passi falsi e dei vostri errori nella registrazione permanente delle revisioni.</para> 18.84 + 18.85 + <para id="x_3c0">Al contrario, il matrimonio tra controllo di revisione distribuito e patch realizzato da MQ rende molto più facile isolare il vostro lavoro. Le vostre patch si basano sulla normale cronologia delle revisioni e potete farle sparire e comparire a piacere. Se non vi piace una patch, potete scartarla. Se una patch non è esattamente come volete che sia, vi basta correggerla&emdash;tutte le volte che ne avete bisogno, fino a quando non l’avete ritoccata facendole assumere la forma che desiderate.</para> 18.86 + 18.87 + <para id="x_3c1">Per esempio, l’integrazione delle patch con il controllo di revisione facilita <emphasis>enormemente</emphasis> la comprensione delle patch e delle interazioni con il codice su cui si basano, nonché la correzione dei loro effetti. Dato che ogni patch applicata è associata a un changeset, potete invocare <command role="hg-cmd">hg log</command> con un nome di file per vedere quali changeset e quali patch hanno avuto effetto sul file. Potete usare il comando <command role="hg-cmd">hg bisect</command> per condurre una ricerca binaria attraverso tutti i changeset e le patch applicate in modo da scoprire dov’è stato introdotto o corretto un bug. Potete usare il comando <command role="hg-cmd">hg annotate</command> per vedere quali changeset o patch hanno modificato una particolare riga di un file sorgente. E così via.</para> 18.88 </sect1> 18.89 18.90 <sect1 id="sec:mq:patch"> 18.91 <title>Capire le patch</title> 18.92 18.93 - <para id="x_3c2">Dato che MQ non nasconde la sua natura orientata alle patch, vi potrà essere d'aiuto capire cosa sono le patch e conoscere un po' gli strumenti che lavorano con esse.</para> 18.94 - 18.95 - <para id="x_3c3">Il tradizionale comando Unix <command>diff</command> confronta due file e stampa una lista di differenze tra loro. Il comando <command>patch</command> interpreta queste differenze come <emphasis>modifiche</emphasis> da effettuare a un file. Date un'occhiata qui di seguito per vedere un semplice esempio di questi comandi in azione.</para> 18.96 + <para id="x_3c2">Dato che MQ non nasconde la sua natura orientata alle patch, vi potrà essere d’aiuto capire cosa sono le patch e conoscere un po’ gli strumenti che lavorano con esse.</para> 18.97 + 18.98 + <para id="x_3c3">Il tradizionale comando Unix <command>diff</command> confronta due file e stampa una lista di differenze tra loro. Il comando <command>patch</command> interpreta queste differenze come <emphasis>modifiche</emphasis> da effettuare a un file. Date un’occhiata qui di seguito per vedere un semplice esempio di questi comandi in azione.</para> 18.99 18.100 &interaction.mq.dodiff.diff; 18.101 18.102 - <para id="x_3c4">Il tipo di file generato da <command>diff</command> (e che <command>patch</command> prende in ingresso) viene chiamato una <quote>patch</quote> (letteralmente, pezza) o un <quote>diff</quote>. Non c'è alcuna differenza tra una patch e un diff, ma noi useremo il termine <quote>patch</quote>, dato che è quello più comunemente usato.</para> 18.103 - 18.104 - <para id="x_3c5">Un file di patch può cominciare con testo arbitrario che il comando <command>patch</command> ignora, ma che MQ usa come messaggio di commit quando crea i changeset. Per trovare l'inizio del contenuto della patch, il comando <command>patch</command> cerca la prima riga che comincia con la stringa <quote><literal>diff -</literal></quote>.</para> 18.105 - 18.106 - <para id="x_3c6">MQ lavora con i diff <emphasis>unificati</emphasis> (<command>patch</command> può accettare molti altri formati di diff, ma MQ no). Un diff unificato contiene due tipi di intestazione. L'<emphasis>intestazione di file</emphasis> descrive il file che viene modificato e contiene il nome del file da modificare. Quando <command>patch</command> vede una nuova intestazione di file, cerca il file con quel nome per cominciare a modificarlo.</para> 18.107 - 18.108 - <para id="x_3c7">L'intestazione di file è seguita da una serie di <emphasis>blocchi</emphasis>. Ogni blocco comincia con un'intestazione che identifica l'intervallo di numeri di riga del file che il blocco dovrebbe modificare. Dopo l'intestazione, un blocco comincia e finisce con alcune (di solito tre) righe di testo proveniente dal file originale che vengono chiamate il <emphasis>contesto</emphasis> del blocco. Se c'è solo una quantità ridotta di contesto tra blocchi successivi, <command>diff</command> non stampa una nuova intestazione, ma si limita a unire insieme i blocchi inserendo alcune righe di contesto tra le modifiche.</para> 18.109 - 18.110 - <para id="x_3c8">Ogni riga di contesto comincia con un carattere di spazio. Nell'ambito di un blocco, una riga che comincia con <quote><literal>-</literal></quote> significa <quote>rimuovi questa riga</quote>, mentre una riga che comincia con <quote><literal>+</literal></quote> significa <quote>inserisci questa riga</quote>. Per esempio, una riga modificata viene rappresentata da una cancellazione e da un inserimento.</para> 18.111 + <para id="x_3c4">Il tipo di file generato da <command>diff</command> (e che <command>patch</command> prende in ingresso) viene chiamato una <quote>patch</quote> (letteralmente, pezza) o un <quote>diff</quote>. Non c’è alcuna differenza tra una patch e un diff, ma noi useremo il termine <quote>patch</quote>, dato che è quello più comunemente usato.</para> 18.112 + 18.113 + <para id="x_3c5">Un file di patch può cominciare con testo arbitrario che il comando <command>patch</command> ignora, ma che MQ usa come messaggio di commit quando crea i changeset. Per trovare l’inizio del contenuto della patch, il comando <command>patch</command> cerca la prima riga che comincia con la stringa <quote><literal>diff -</literal></quote>.</para> 18.114 + 18.115 + <para id="x_3c6">MQ lavora con i diff <emphasis>unificati</emphasis> (<command>patch</command> può accettare molti altri formati di diff, ma MQ no). Un diff unificato contiene due tipi di intestazione. L’<emphasis>intestazione di file</emphasis> descrive il file che viene modificato e contiene il nome del file da modificare. Quando <command>patch</command> vede una nuova intestazione di file, cerca il file con quel nome per cominciare a modificarlo.</para> 18.116 + 18.117 + <para id="x_3c7">L’intestazione di file è seguita da una serie di <emphasis>blocchi</emphasis>. Ogni blocco comincia con un’intestazione che identifica l’intervallo di numeri di riga del file che il blocco dovrebbe modificare. Dopo l’intestazione, un blocco comincia e finisce con alcune (di solito tre) righe di testo proveniente dal file originale che vengono chiamate il <emphasis>contesto</emphasis> del blocco. Se c’è solo una quantità ridotta di contesto tra blocchi successivi, <command>diff</command> non stampa una nuova intestazione, ma si limita a unire insieme i blocchi inserendo alcune righe di contesto tra le modifiche.</para> 18.118 + 18.119 + <para id="x_3c8">Ogni riga di contesto comincia con un carattere di spazio. Nell’ambito di un blocco, una riga che comincia con <quote><literal>-</literal></quote> significa <quote>rimuovi questa riga</quote>, mentre una riga che comincia con <quote><literal>+</literal></quote> significa <quote>inserisci questa riga</quote>. Per esempio, una riga modificata viene rappresentata da una cancellazione e da un inserimento.</para> 18.120 18.121 <para id="x_3c9">Ritorneremo su alcuni degli aspetti più sottili delle patch più avanti (nella <xref linkend="sec:mq:adv-patch"/>), ma ora dovreste avere abbastanza informazioni per usare MQ.</para> 18.122 </sect1> 18.123 @@ -91,16 +91,16 @@ 18.124 <sect1 id="sec:mq:start"> 18.125 <title>Cominciare a usare Mercurial Queues</title> 18.126 18.127 - <para id="x_3ca">Dato che MQ è implementata come un'estensione, dovete esplicitamente abilitarla prima di poterla usare. (Non avete bisogno di scaricare nulla, perché MQ è inclusa con la distribuzione standard di Mercurial.) Per abilitare MQ, modificate il vostro file <filename role="home">~/.hgrc</filename> aggiungendo le seguenti righe.</para> 18.128 + <para id="x_3ca">Dato che MQ è implementata come un’estensione, dovete esplicitamente abilitarla prima di poterla usare. (Non avete bisogno di scaricare nulla, perché MQ è inclusa con la distribuzione standard di Mercurial.) Per abilitare MQ, modificate il vostro file <filename role="home">~/.hgrc</filename> aggiungendo le seguenti righe.</para> 18.129 18.130 <programlisting>[extensions] 18.131 hgext.mq =</programlisting> 18.132 18.133 - <para id="x_3cb">Una volta che avete abilitato l'estensione, vi verranno messi a disposizione alcuni nuovi comandi. Per verificare che l'estensione funzioni, potete usare <command role="hg-cmd">hg help</command> per vedere se il comando <command role="hg-ext-mq">qinit</command> viene elencato come disponibile.</para> 18.134 + <para id="x_3cb">Una volta che avete abilitato l’estensione, vi verranno messi a disposizione alcuni nuovi comandi. Per verificare che l’estensione funzioni, potete usare <command role="hg-cmd">hg help</command> per vedere se il comando <command role="hg-ext-mq">qinit</command> viene elencato come disponibile.</para> 18.135 18.136 &interaction.mq.qinit-help.help; 18.137 18.138 - <para id="x_3cc">MQ può essere usata con <emphasis>qualsiasi</emphasis> repository Mercurial e i suoi comandi operano solo all'interno di quel repository. Per cominciare, preparate semplicemente il repository usando il comando <command role="hg-ext-mq">qinit</command>.</para> 18.139 + <para id="x_3cc">MQ può essere usata con <emphasis>qualsiasi</emphasis> repository Mercurial e i suoi comandi operano solo all’interno di quel repository. Per cominciare, preparate semplicemente il repository usando il comando <command role="hg-ext-mq">qinit</command>.</para> 18.140 18.141 &interaction.mq.tutorial.qinit; 18.142 18.143 @@ -133,7 +133,7 @@ 18.144 18.145 <para id="x_3d4">Questo comando include nella vostra patch i cambiamenti che avete fatto nella directory di lavoro e aggiorna il changeset corrispondente alla patch in modo che contenga quei cambiamenti.</para> 18.146 18.147 - <para id="x_3d5">Potete invocare <command role="hg-ext-mq">qrefresh</command> tutte le volte che volete, quindi questo comando rappresenta un buon modo per <quote>controllare</quote> il vostro lavoro. Aggiornate la vostra patch al momento opportuno, tentate un esperimento e se l'esperimento non funziona usate <command role="hg-cmd">hg revert</command> per ripristinare le vostre modifiche all'ultimo aggiornamento che avete compiuto.</para> 18.148 + <para id="x_3d5">Potete invocare <command role="hg-ext-mq">qrefresh</command> tutte le volte che volete, quindi questo comando rappresenta un buon modo per <quote>controllare</quote> il vostro lavoro. Aggiornate la vostra patch al momento opportuno, tentate un esperimento e se l’esperimento non funziona usate <command role="hg-cmd">hg revert</command> per ripristinare le vostre modifiche all’ultimo aggiornamento che avete compiuto.</para> 18.149 18.150 &interaction.mq.tutorial.qrefresh2; 18.151 </sect2> 18.152 @@ -141,13 +141,13 @@ 18.153 <sect2> 18.154 <title>Impilare e registrare le patch</title> 18.155 18.156 - <para id="x_3d6">Una volta che avete finito di lavorare su una patch, o avete bisogno di lavorare su un'altra patch, potete usare di nuovo il comando <command role="hg-ext-mq">qnew</command> per creare una nuova patch. Mercurial applicherà questa patch a partire dalla vostra patch esistente.</para> 18.157 + <para id="x_3d6">Una volta che avete finito di lavorare su una patch, o avete bisogno di lavorare su un’altra patch, potete usare di nuovo il comando <command role="hg-ext-mq">qnew</command> per creare una nuova patch. Mercurial applicherà questa patch a partire dalla vostra patch esistente.</para> 18.158 18.159 &interaction.mq.tutorial.qnew2; 18.160 18.161 <para id="x_3d7">Notate che la patch contiene le modifiche della nostra patch precedente come parte del proprio contesto (potete vederlo più chiaramente nel risultato di <command role="hg-cmd">hg annotate</command>).</para> 18.162 18.163 - <para id="x_3d8">Finora, con l'eccezione di <command role="hg-ext-mq">qnew</command> e <command role="hg-ext-mq">qrefresh</command>, siamo stati attenti a usare solo gli ordinari comandi Mercurial. Tuttavia, MQ fornisce molti comandi che sono più facili da usare quando state pensando in termini di patch, come illustrato di seguito.</para> 18.164 + <para id="x_3d8">Finora, con l’eccezione di <command role="hg-ext-mq">qnew</command> e <command role="hg-ext-mq">qrefresh</command>, siamo stati attenti a usare solo gli ordinari comandi Mercurial. Tuttavia, MQ fornisce molti comandi che sono più facili da usare quando state pensando in termini di patch, come illustrato di seguito.</para> 18.165 18.166 &interaction.mq.tutorial.qseries; 18.167 18.168 @@ -161,9 +161,9 @@ 18.169 <sect2> 18.170 <title>Manipolare la pila delle patch</title> 18.171 18.172 - <para id="x_3db">La discussione precedente implica che ci deve essere una differenza tra patch <quote>note</quote> e patch <quote>applicate</quote>, e in effetti c'è. MQ può gestire una patch senza che sia applicata al repository.</para> 18.173 - 18.174 - <para id="x_3dc">Una patch <emphasis>applicata</emphasis> ha un corrispondente changeset nel repository e gli effetti della patch e del changeset sono visibili nella directory di lavoro. Potete annullare l'applicazione di una patch usando il comando <command role="hg-ext-mq">qpop</command>. La patch estratta è ancora <emphasis>nota</emphasis>, cioè gestita da MQ, ma non ha più un corrispondente changeset nel repository, e la directory di lavoro non contiene più le modifiche apportate dalla patch. La <xref linkend="fig:mq:stack"/> illustra la differenza tra patch applicate e registrate.</para> 18.175 + <para id="x_3db">La discussione precedente implica che ci deve essere una differenza tra patch <quote>note</quote> e patch <quote>applicate</quote>, e in effetti c’è. MQ può gestire una patch senza che sia applicata al repository.</para> 18.176 + 18.177 + <para id="x_3dc">Una patch <emphasis>applicata</emphasis> ha un corrispondente changeset nel repository e gli effetti della patch e del changeset sono visibili nella directory di lavoro. Potete annullare l’applicazione di una patch usando il comando <command role="hg-ext-mq">qpop</command>. La patch estratta è ancora <emphasis>nota</emphasis>, cioè gestita da MQ, ma non ha più un corrispondente changeset nel repository, e la directory di lavoro non contiene più le modifiche apportate dalla patch. La <xref linkend="fig:mq:stack"/> illustra la differenza tra patch applicate e registrate.</para> 18.178 18.179 <figure id="fig:mq:stack"> 18.180 <title>Patch applicate e non applicate nella pila delle patch di MQ</title> 18.181 @@ -184,7 +184,7 @@ 18.182 <sect2> 18.183 <title>Inserire ed estrarre molte patch</title> 18.184 18.185 - <para id="x_3e0">Sebbene i comandi <command role="hg-ext-mq">qpush</command> e <command role="hg-ext-mq">qpop</command> operino in maniera predefinita su una singola patch alla volta, potete inserire ed estrarre molte patch in un unico passaggio. L'opzione <option role="hg-ext-mq-cmd-qpush-opt">-a</option> di <command role="hg-ext-mq">qpush</command> lo induce a inserire tutte le patch non applicate, mentre l'opzione <option role="hg-ext-mq-cmd-qpop-opt">-a</option> di <command role="hg-ext-mq">qpop</command> lo induce a estrarre tutte le patch applicate. (Per ulteriori modi di inserire ed estrarre molte patch, si veda la <xref linkend="sec:mq:perf"/> più avanti.)</para> 18.186 + <para id="x_3e0">Sebbene i comandi <command role="hg-ext-mq">qpush</command> e <command role="hg-ext-mq">qpop</command> operino in maniera predefinita su una singola patch alla volta, potete inserire ed estrarre molte patch in un unico passaggio. L’opzione <option role="hg-ext-mq-cmd-qpush-opt">-a</option> di <command role="hg-ext-mq">qpush</command> lo induce a inserire tutte le patch non applicate, mentre l’opzione <option role="hg-ext-mq-cmd-qpop-opt">-a</option> di <command role="hg-ext-mq">qpop</command> lo induce a estrarre tutte le patch applicate. (Per ulteriori modi di inserire ed estrarre molte patch, si veda la <xref linkend="sec:mq:perf"/> più avanti.)</para> 18.187 18.188 &interaction.mq.tutorial.qpush-a; 18.189 </sect2> 18.190 @@ -192,54 +192,54 @@ 18.191 <sect2> 18.192 <title>I controlli di sicurezza e come scavalcarli</title> 18.193 18.194 - <para id="x_3e1">Diversi comandi MQ esaminano la directory di lavoro prima di fare qualunque cosa e falliscono se trovano una qualsiasi modifica. Si comportano in questo modo per assicurarsi di non farvi perdere i cambiamenti che avete fatto ma che non avete ancora incorporato in una patch. L'esempio seguente illustra questo caso: il comando <command role="hg-ext-mq">qnew</command> eviterà di creare una nuova patch se ci sono cambiamenti in sospeso, causati in questo caso dall'invocazione di <command role="hg-cmd">hg add</command> su <filename>file3</filename>.</para> 18.195 + <para id="x_3e1">Diversi comandi MQ esaminano la directory di lavoro prima di fare qualunque cosa e falliscono se trovano una qualsiasi modifica. Si comportano in questo modo per assicurarsi di non farvi perdere i cambiamenti che avete fatto ma che non avete ancora incorporato in una patch. L’esempio seguente illustra questo caso: il comando <command role="hg-ext-mq">qnew</command> eviterà di creare una nuova patch se ci sono cambiamenti in sospeso, causati in questo caso dall’invocazione di <command role="hg-cmd">hg add</command> su <filename>file3</filename>.</para> 18.196 18.197 &interaction.mq.tutorial.add; 18.198 18.199 - <para id="x_3e2">Tutti i comandi che esaminano la directory di lavoro accettano un'opzione <quote>so cosa sto facendo</quote> che si chiama sempre <option>-f</option>. L'esatto significato di <option>-f</option> dipende dal comando. Per esempio, <command role="hg-cmd">hg qnew -f</command> incorporerà i cambiamenti in sospeso nella nuova patch creata, ma <command role="hg-cmd">hg qpop -f</command> annullerà le modifiche a qualsiasi file coinvolto dalla patch che sta estraendo. Assicuratevi di leggere la documentazione per l'opzione <option>-f</option> di un comando prima di usarla!</para> 18.200 + <para id="x_3e2">Tutti i comandi che esaminano la directory di lavoro accettano un’opzione <quote>so cosa sto facendo</quote> che si chiama sempre <option>-f</option>. L’esatto significato di <option>-f</option> dipende dal comando. Per esempio, <command role="hg-cmd">hg qnew -f</command> incorporerà i cambiamenti in sospeso nella nuova patch creata, ma <command role="hg-cmd">hg qpop -f</command> annullerà le modifiche a qualsiasi file coinvolto dalla patch che sta estraendo. Assicuratevi di leggere la documentazione per l’opzione <option>-f</option> di un comando prima di usarla!</para> 18.201 </sect2> 18.202 18.203 <sect2> 18.204 <title>Lavorare su diverse patch alla volta</title> 18.205 18.206 - <para id="x_3e3">Il comando <command role="hg-ext-mq">qrefresh</command> aggiorna sempre la patch applicata <emphasis>più recentemente</emphasis>. Questo significa che potete sospendere il lavoro su una patch (aggiornandola), operare estrazioni o inserimenti in modo che l'ultima patch applicata sia differente e lavorare su <emphasis>questa</emphasis> patch per un po'.</para> 18.207 - 18.208 - <para id="x_3e4">Ecco un esempio che illustra come potete sfruttare questa possibilità. Diciamo che state sviluppando una nuova funzione sotto forma di due patch. La prima è una modifica al nucleo del vostro software e la seconda&emdash;basata sulla prima&emdash;modifica l'interfaccia utente per usare il codice che avete appena aggiunto al nucleo. Se notate un bug nel nucleo mentre state lavorando sulla patch per l'interfaccia utente, per correggerlo vi basta usare <command role="hg-ext-mq">qrefresh</command>, in modo da salvare le modifiche in corso alla vostra patch di interfaccia, e poi usare <command role="hg-ext-mq">qpop</command> per poter operare sulla patch del nucleo. Correggete il bug nel nucleo, aggiornate la patch del nucleo con <command role="hg-ext-mq">qrefresh</command> e inserite la patch di interfaccia tramite <command role="hg-ext-mq">qpush</command> per continuare a lavorare dal punto dove avevate lasciato.</para> 18.209 + <para id="x_3e3">Il comando <command role="hg-ext-mq">qrefresh</command> aggiorna sempre la patch applicata <emphasis>più recentemente</emphasis>. Questo significa che potete sospendere il lavoro su una patch (aggiornandola), operare estrazioni o inserimenti in modo che l’ultima patch applicata sia differente e lavorare su <emphasis>questa</emphasis> patch per un po’.</para> 18.210 + 18.211 + <para id="x_3e4">Ecco un esempio che illustra come potete sfruttare questa possibilità. Diciamo che state sviluppando una nuova funzione sotto forma di due patch. La prima è una modifica al nucleo del vostro software e la seconda&emdash;basata sulla prima&emdash;modifica l’interfaccia utente per usare il codice che avete appena aggiunto al nucleo. Se notate un bug nel nucleo mentre state lavorando sulla patch per l’interfaccia utente, per correggerlo vi basta usare <command role="hg-ext-mq">qrefresh</command>, in modo da salvare le modifiche in corso alla vostra patch di interfaccia, e poi usare <command role="hg-ext-mq">qpop</command> per poter operare sulla patch del nucleo. Correggete il bug nel nucleo, aggiornate la patch del nucleo con <command role="hg-ext-mq">qrefresh</command> e inserite la patch di interfaccia tramite <command role="hg-ext-mq">qpush</command> per continuare a lavorare dal punto dove avevate lasciato.</para> 18.212 </sect2> 18.213 </sect1> 18.214 18.215 <sect1 id="sec:mq:adv-patch"> 18.216 <title>Ulteriori informazioni sulle patch</title> 18.217 18.218 - <para id="x_3e5">MQ usa il comando GNU <command>patch</command> per applicare le patch, quindi vi sarà d'aiuto conoscere qualche altro aspetto di dettaglio sul funzionamento di <command>patch</command> e sulle patch stesse.</para> 18.219 + <para id="x_3e5">MQ usa il comando GNU <command>patch</command> per applicare le patch, quindi vi sarà d’aiuto conoscere qualche altro aspetto di dettaglio sul funzionamento di <command>patch</command> e sulle patch stesse.</para> 18.220 18.221 <sect2> 18.222 <title>Il numero di cancellazioni</title> 18.223 18.224 <para id="x_3e6">Se osservate le intestazioni di file in una patch, noterete che i percorsi dei nomi di solito hanno un componente aggiuntivo iniziale che non è presente nel percorso reale. Questo è uno strascico del modo in cui le persone erano abituate a generare le patch (questo modo viene ancora impiegato, ma piuttosto raramente ora che sono disponibili strumenti di controllo di revisione più moderni).</para> 18.225 18.226 - <para id="x_3e7">Alice avrebbe estratto un archivio, modificato i file e poi deciso di voler creare una patch. Quindi avrebbe rinominato la directory di lavoro, estratto nuovamente l'archivio (da qui nasce il bisogno di modificare il nome) e usato le opzioni <option role="cmd-opt-diff">-r</option> e <option role="cmd-opt-diff">-N</option> del comando <command>diff</command> per generare ricorsivamente una patch tra la directory non modificata e quella modificata. Come risultato, il nome della directory non modificata si sarebbe trovato all'inizio del percorso sulla parte sinistra di ogni intestazione di file e il nome della directory modificata si sarebbe trovato all'inizio del percorso sulla parte destra.</para> 18.227 - 18.228 - <para id="x_3e8">Dato che chi riceveva una patch dalle Alice della rete probabilmente non avrebbe avuto le due copie, modificata e non, della directory con esattamente gli stessi nomi, il comando <command>patch</command> è stato dotato di un'opzione <option role="cmd-opt-patch">-p</option> che indica il numero di elementi iniziali da eliminare dal percorso al momento di applicare una patch. Questo numero viene chiamato il <emphasis>numero di cancellazioni</emphasis>.</para> 18.229 - 18.230 - <para id="x_3e9">Un'opzione <quote><literal>-p1</literal></quote> significa <quote>usa un numero di cancellazioni pari a uno</quote>. Se <command>patch</command> vede un nome di file <filename>foo/bar/baz</filename> in un'intestazione di file, eliminerà <filename>foo</filename> e proverà ad applicare la patch al file <filename>bar/baz</filename>. Strettamente parlando, il numero di cancellazioni si riferisce al numero di <emphasis>separatori di percorso</emphasis> (e dei relativi elementi) da eliminare. Un numero di cancellazioni pari a uno trasformerà <filename>foo/bar</filename> in <filename>bar</filename>, ma <filename>/foo/bar</filename> (notate lo slash iniziale) in <filename>foo/bar</filename>.</para> 18.231 + <para id="x_3e7">Alice avrebbe estratto un archivio, modificato i file e poi deciso di voler creare una patch. Quindi avrebbe rinominato la directory di lavoro, estratto nuovamente l’archivio (da qui nasce il bisogno di modificare il nome) e usato le opzioni <option role="cmd-opt-diff">-r</option> e <option role="cmd-opt-diff">-N</option> del comando <command>diff</command> per generare ricorsivamente una patch tra la directory non modificata e quella modificata. Come risultato, il nome della directory non modificata si sarebbe trovato all’inizio del percorso sulla parte sinistra di ogni intestazione di file e il nome della directory modificata si sarebbe trovato all’inizio del percorso sulla parte destra.</para> 18.232 + 18.233 + <para id="x_3e8">Dato che chi riceveva una patch dalle Alice della rete probabilmente non avrebbe avuto le due copie, modificata e non, della directory con esattamente gli stessi nomi, il comando <command>patch</command> è stato dotato di un’opzione <option role="cmd-opt-patch">-p</option> che indica il numero di elementi iniziali da eliminare dal percorso al momento di applicare una patch. Questo numero viene chiamato il <emphasis>numero di cancellazioni</emphasis>.</para> 18.234 + 18.235 + <para id="x_3e9">Un’opzione <quote><literal>-p1</literal></quote> significa <quote>usa un numero di cancellazioni pari a uno</quote>. Se <command>patch</command> vede un nome di file <filename>foo/bar/baz</filename> in un’intestazione di file, eliminerà <filename>foo</filename> e proverà ad applicare la patch al file <filename>bar/baz</filename>. Strettamente parlando, il numero di cancellazioni si riferisce al numero di <emphasis>separatori di percorso</emphasis> (e dei relativi elementi) da eliminare. Un numero di cancellazioni pari a uno trasformerà <filename>foo/bar</filename> in <filename>bar</filename>, ma <filename>/foo/bar</filename> (notate lo slash iniziale) in <filename>foo/bar</filename>.</para> 18.236 18.237 <para id="x_3ea">Il numero di cancellazioni <quote>standard</quote> per le patch è pari a uno, in quanto quasi tutte le patch contengono un elemento iniziale da eliminare nel percorso. Il comando <command role="hg-cmd">hg diff</command> di Mercurial genera nomi di percorso in questa forma e sia il comando <command role="hg-cmd">hg import</command> che MQ si aspettano patch con un numero di cancellazioni pari a uno.</para> 18.238 18.239 - <para id="x_3eb">Se qualcuno vi invia una patch che volete aggiungere alla vostra coda delle patch e la patch necessita di un numero di cancellazioni diverso da uno, non potete usare semplicemente <command role="hg-ext-mq">qimport</command> con la patch, perché <command role="hg-ext-mq">qimport</command> non è ancora dotato di un'opzione <literal>-p</literal> (si veda il <ulink role="hg-bug" url="http://www.selenic.com/mercurial/bts/issue311">problema 311</ulink> per i dettagli). L'alternativa migliore che avete è quella di creare una vostra patch con <command role="hg-ext-mq">qnew</command> e poi usare il comando <command>patch -pN</command> per applicare la patch che avete ricevuto, seguito da <command role="hg-cmd">hg addremove</command> per registrare qualsiasi file aggiunto o rimosso dalla patch, seguito da <command role="hg-ext-mq">hg qrefresh</command>. Questa complessità potrebbe diventare inutile una volta che il <ulink role="hg-bug" url="http://www.selenic.com/mercurial/bts/issue311">problema 311</ulink> verrà risolto. 18.240 + <para id="x_3eb">Se qualcuno vi invia una patch che volete aggiungere alla vostra coda delle patch e la patch necessita di un numero di cancellazioni diverso da uno, non potete usare semplicemente <command role="hg-ext-mq">qimport</command> con la patch, perché <command role="hg-ext-mq">qimport</command> non è ancora dotato di un’opzione <literal>-p</literal> (si veda il <ulink role="hg-bug" url="http://www.selenic.com/mercurial/bts/issue311">problema 311</ulink> per i dettagli). L’alternativa migliore che avete è quella di creare una vostra patch con <command role="hg-ext-mq">qnew</command> e poi usare il comando <command>patch -pN</command> per applicare la patch che avete ricevuto, seguito da <command role="hg-cmd">hg addremove</command> per registrare qualsiasi file aggiunto o rimosso dalla patch, seguito da <command role="hg-ext-mq">hg qrefresh</command>. Questa complessità potrebbe diventare inutile una volta che il <ulink role="hg-bug" url="http://www.selenic.com/mercurial/bts/issue311">problema 311</ulink> verrà risolto. 18.241 </para> 18.242 </sect2> 18.243 18.244 <sect2> 18.245 <title>Strategie per applicare una patch</title> 18.246 18.247 - <para id="x_3ec">Quando <command>patch</command> applica un blocco, prova a impiegare una serie di strategie successive sempre meno accurate per portare a termine l'operazione. Questo impiego di tecniche alternative rende spesso possibile prendere una patch che è stata generata a partire da una vecchia versione di un file e applicarla alla nuova versione di quel file.</para> 18.248 + <para id="x_3ec">Quando <command>patch</command> applica un blocco, prova a impiegare una serie di strategie successive sempre meno accurate per portare a termine l’operazione. Questo impiego di tecniche alternative rende spesso possibile prendere una patch che è stata generata a partire da una vecchia versione di un file e applicarla alla nuova versione di quel file.</para> 18.249 18.250 <para id="x_3ed">Come prima cosa, <command>patch</command> cerca una corrispondenza esatta, dove i numeri di riga, il contesto e il testo da modificare devono applicarsi perfettamente. Se non riesce a trovare una corrispondenza esatta, cerca una corrispondenza esatta per il contesto, senza onorare le informazioni sulla numerazione delle righe. Se questa strategia ha successo, il comando stampa una riga dicendo che il blocco è stato applicato, ma con un certo <emphasis>scostamento</emphasis> rispetto al numero di riga originale.</para> 18.251 18.252 - <para id="x_3ee">Se la corrispondenza con il solo contesto fallisce, <command>patch</command> rimuove la prima e l'ultima riga del contesto e tenta una corrispondenza con la sola versione <emphasis>ridotta</emphasis> del contesto. Se il blocco con il contesto ridotto ha successo, stampa un messaggio dicendo di aver applicato il blocco con un <emphasis>fattore di incertezza</emphasis> (il numero dopo il fattore di incertezza indica quante righe del contesto sono state escluse da <command>patch</command> prima che la patch si potesse applicare).</para> 18.253 - 18.254 - <para id="x_3ef">Quando nessuna di queste tecniche funziona, <command>patch</command> stampa un messaggio dicendo che il blocco in questione è stato rifiutato. Il comando salva i blocchi rifiutati (anche chiamati semplicemente <quote>rifiuti</quote>) in un file con lo stesso nome e un'estensione <filename role="special">.rej</filename> aggiuntiva. Le copie non modificate del file vengono salvate con un'estensione <filename role="special">.orig</filename>, mentre la copia del file senza alcuna estensione conterrà le modifiche fatte dai blocchi che sono stati <emphasis>effettivamente</emphasis> applicati. Se avete una patch che modifica il file <filename>foo</filename> con sei blocchi, ma uno di essi non si riesce ad applicare, otterrete una copia <filename>foo.orig</filename> non modificata del file originale, un file <filename>foo.rej</filename> contenente un blocco e il file <filename>foo</filename> contenente le modifiche effettuate dai cinque blocchi applicati con successo.</para> 18.255 + <para id="x_3ee">Se la corrispondenza con il solo contesto fallisce, <command>patch</command> rimuove la prima e l’ultima riga del contesto e tenta una corrispondenza con la sola versione <emphasis>ridotta</emphasis> del contesto. Se il blocco con il contesto ridotto ha successo, stampa un messaggio dicendo di aver applicato il blocco con un <emphasis>fattore di incertezza</emphasis> (il numero dopo il fattore di incertezza indica quante righe del contesto sono state escluse da <command>patch</command> prima che la patch si potesse applicare).</para> 18.256 + 18.257 + <para id="x_3ef">Quando nessuna di queste tecniche funziona, <command>patch</command> stampa un messaggio dicendo che il blocco in questione è stato rifiutato. Il comando salva i blocchi rifiutati (anche chiamati semplicemente <quote>rifiuti</quote>) in un file con lo stesso nome e un’estensione <filename role="special">.rej</filename> aggiuntiva. Le copie non modificate del file vengono salvate con un’estensione <filename role="special">.orig</filename>, mentre la copia del file senza alcuna estensione conterrà le modifiche fatte dai blocchi che sono stati <emphasis>effettivamente</emphasis> applicati. Se avete una patch che modifica il file <filename>foo</filename> con sei blocchi, ma uno di essi non si riesce ad applicare, otterrete una copia <filename>foo.orig</filename> non modificata del file originale, un file <filename>foo.rej</filename> contenente un blocco e il file <filename>foo</filename> contenente le modifiche effettuate dai cinque blocchi applicati con successo.</para> 18.258 </sect2> 18.259 18.260 <sect2> 18.261 @@ -253,21 +253,21 @@ 18.262 </listitem> 18.263 <listitem><para id="x_3f3"><command>patch</command> tratta la rimozione di un file come un diff tra il file da rimuovere e un file vuoto. Quindi la vostra idea di <quote>cancellare un file</quote> viene rappresentata in una patch come <quote>ogni riga di questo file è stata cancellata</quote>.</para> 18.264 </listitem> 18.265 - <listitem><para id="x_3f4">Tratta l'aggiunta di un file come un diff tra un file vuoto e il file da aggiungere. Quindi la vostra idea di <quote>aggiungere un file</quote> viene rappresentata in una patch come <quote>ogni riga di questo file è stata aggiunta</quote>.</para> 18.266 - </listitem> 18.267 - <listitem><para id="x_3f5">Tratta un file rinominato come la rimozione del file con il vecchio nome e l'aggiunta del file con il nuovo nome. Questo significa che i file rinominati occupano molto spazio in una patch. (Notate anche che Mercurial attualmente non cerca di inferire se i file in una patch sono stati rinominati o copiati.)</para> 18.268 - </listitem> 18.269 - <listitem><para id="x_3f6"><command>patch</command> non è in grado di rappresentare i file vuoti, quindi non potete usare una patch per rappresentare la nozione di <quote>aggiungere questo file vuoto all'albero</quote>.</para> 18.270 + <listitem><para id="x_3f4">Tratta l’aggiunta di un file come un diff tra un file vuoto e il file da aggiungere. Quindi la vostra idea di <quote>aggiungere un file</quote> viene rappresentata in una patch come <quote>ogni riga di questo file è stata aggiunta</quote>.</para> 18.271 + </listitem> 18.272 + <listitem><para id="x_3f5">Tratta un file rinominato come la rimozione del file con il vecchio nome e l’aggiunta del file con il nuovo nome. Questo significa che i file rinominati occupano molto spazio in una patch. (Notate anche che Mercurial attualmente non cerca di inferire se i file in una patch sono stati rinominati o copiati.)</para> 18.273 + </listitem> 18.274 + <listitem><para id="x_3f6"><command>patch</command> non è in grado di rappresentare i file vuoti, quindi non potete usare una patch per rappresentare la nozione di <quote>aggiungere questo file vuoto all’albero</quote>.</para> 18.275 </listitem> 18.276 </itemizedlist> 18.277 </sect2> 18.278 18.279 <sect2> 18.280 - <title>Fate attenzione all'incertezza</title> 18.281 - 18.282 - <para id="x_3f7">Anche se l'applicazione di un blocco con un certo scostamento o con un certo fattore di incertezza avrà spesso un successo completo, queste tecniche inesatte lasciano naturalmente aperta la possibilità di rovinare il file modificato. Il caso più comune è tipicamente quello in cui la patch viene applicata due volte o in una posizione sbagliata nel file. Se <command>patch</command> o <command role="hg-ext-mq">qpush</command> dovessero mai menzionare lo scostamento o il fattore di incertezza, dovreste assicurarvi che i file siano stati modificati in maniera corretta.</para> 18.283 - 18.284 - <para id="x_3f8">Spesso è una buona idea aggiornare una patch che è stata applicata con uno scostamento o un fattore di incertezza, perché l'aggiornamento della patch genera nuove informazioni di contesto che permetteranno di applicarla in maniera precisa. Dico <quote>spesso</quote>, non <quote>sempre</quote>, perché qualche volta l'aggiornamento di una patch ne renderà impossibile l'applicazione su una revisione differente dei file coinvolti. In alcuni casi, come quando state mantenendo una patch che deve essere applicabile a molteplici versioni di un albero di sorgenti, è considerato accettabile avere una patch che si applica con qualche incertezza, purché abbiate verificato i risultati del processo di applicazione in casi come questi.</para> 18.285 + <title>Fate attenzione all’incertezza</title> 18.286 + 18.287 + <para id="x_3f7">Anche se l’applicazione di un blocco con un certo scostamento o con un certo fattore di incertezza avrà spesso un successo completo, queste tecniche inesatte lasciano naturalmente aperta la possibilità di rovinare il file modificato. Il caso più comune è tipicamente quello in cui la patch viene applicata due volte o in una posizione sbagliata nel file. Se <command>patch</command> o <command role="hg-ext-mq">qpush</command> dovessero mai menzionare lo scostamento o il fattore di incertezza, dovreste assicurarvi che i file siano stati modificati in maniera corretta.</para> 18.288 + 18.289 + <para id="x_3f8">Spesso è una buona idea aggiornare una patch che è stata applicata con uno scostamento o un fattore di incertezza, perché l’aggiornamento della patch genera nuove informazioni di contesto che permetteranno di applicarla in maniera precisa. Dico <quote>spesso</quote>, non <quote>sempre</quote>, perché qualche volta l’aggiornamento di una patch ne renderà impossibile l’applicazione su una revisione differente dei file coinvolti. In alcuni casi, come quando state mantenendo una patch che deve essere applicabile a molteplici versioni di un albero di sorgenti, è considerato accettabile avere una patch che si applica con qualche incertezza, purché abbiate verificato i risultati del processo di applicazione in casi come questi.</para> 18.290 </sect2> 18.291 18.292 <sect2> 18.293 @@ -279,12 +279,12 @@ 18.294 18.295 <para id="x_3fb">Sfortunatamente, non esiste alcuna tecnica particolare per gestire i blocchi rifiutati. Molto spesso, dovrete esaminare il file <filename role="special">.rej</filename> e modificare il file di destinazione, applicando a mano i blocchi rifiutati.</para> 18.296 18.297 - <para id="x_3fd">Un programmatore del kernel di Linux, Chris Mason (l'autore di Mercurial Queues), ha realizzato uno strumento chiamato <command>mpatch</command> <citation><xref linkend="bib:mpatch"/></citation>, che adotta un metodo semplice per automatizzare l'applicazione dei blocchi rifiutati da <command>patch</command>. Il comando <command>mpatch</command> può aiutarvi nel caso il blocco sia stato rifiutato per quattro tipiche ragioni:</para> 18.298 + <para id="x_3fd">Un programmatore del kernel di Linux, Chris Mason (l’autore di Mercurial Queues), ha realizzato uno strumento chiamato <command>mpatch</command> <citation><xref linkend="bib:mpatch"/></citation>, che adotta un metodo semplice per automatizzare l’applicazione dei blocchi rifiutati da <command>patch</command>. Il comando <command>mpatch</command> può aiutarvi nel caso il blocco sia stato rifiutato per quattro tipiche ragioni:</para> 18.299 18.300 <itemizedlist> 18.301 <listitem><para id="x_3fe">il contesto in mezzo a un blocco è cambiato;</para> 18.302 </listitem> 18.303 - <listitem><para id="x_3ff">all'inizio o alla fine del blocco manca una certa quantità di contesto;</para> 18.304 + <listitem><para id="x_3ff">all’inizio o alla fine del blocco manca una certa quantità di contesto;</para> 18.305 </listitem> 18.306 <listitem><para id="x_400">un blocco più ampio potrebbe applicarsi meglio&emdash;interamente o in parte&emdash;se fosse suddiviso in blocchi più piccoli;</para> 18.307 </listitem> 18.308 @@ -292,7 +292,7 @@ 18.309 </listitem> 18.310 </itemizedlist> 18.311 18.312 - <para id="x_402">Se usate il comando <command>mpatch</command>, dovreste stare doppiamente attenti quando controllate i risultati al termine dell'esecuzione. In effetti, <command>mpatch</command> impone questo metodo di doppio controllo sul risultato dello strumento, avviando automaticamente un programma di gestione delle unioni quando ha concluso il proprio lavoro, in modo che possiate verificare i risultati e risolvere qualsiasi conflitto rimanente.</para> 18.313 + <para id="x_402">Se usate il comando <command>mpatch</command>, dovreste stare doppiamente attenti quando controllate i risultati al termine dell’esecuzione. In effetti, <command>mpatch</command> impone questo metodo di doppio controllo sul risultato dello strumento, avviando automaticamente un programma di gestione delle unioni quando ha concluso il proprio lavoro, in modo che possiate verificare i risultati e risolvere qualsiasi conflitto rimanente.</para> 18.314 </sect2> 18.315 </sect1> 18.316 18.317 @@ -316,13 +316,13 @@ 18.318 18.319 &interaction.ch11-qdelete.convert; 18.320 18.321 - <para id="x_6e0">Il comando <command role="hg-ext-mq">hg qfinish</command> accetta un'opzione <option>--all</option> o <option>-a</option> per trasformare tutte le patch applicate in normali changeset.</para> 18.322 - 18.323 - <para id="x_6de">È anche possibile trasformare un changeset esistente in una patch, passando l'opzione <option>-r</option> al comando <command role="hg-ext-mq">hg qimport</command>.</para> 18.324 + <para id="x_6e0">Il comando <command role="hg-ext-mq">hg qfinish</command> accetta un’opzione <option>--all</option> o <option>-a</option> per trasformare tutte le patch applicate in normali changeset.</para> 18.325 + 18.326 + <para id="x_6de">È anche possibile trasformare un changeset esistente in una patch, passando l’opzione <option>-r</option> al comando <command role="hg-ext-mq">hg qimport</command>.</para> 18.327 18.328 &interaction.ch11-qdelete.import; 18.329 18.330 - <para id="x_6df">Notate che ha senso convertire un changeset in una patch solo se non avete propagato quel changeset in altri repository. L'identificatore del changeset importato cambierà ogni volta che aggiornate la patch, cosa che indurrà Mercurial a trattarlo come se non fosse correlato al changeset originale che avete trasmesso da qualche altra parte.</para> 18.331 + <para id="x_6df">Notate che ha senso convertire un changeset in una patch solo se non avete propagato quel changeset in altri repository. L’identificatore del changeset importato cambierà ogni volta che aggiornate la patch, cosa che indurrà Mercurial a trattarlo come se non fosse correlato al changeset originale che avete trasmesso da qualche altra parte.</para> 18.332 </sect2> 18.333 </sect1> 18.334 18.335 @@ -347,9 +347,9 @@ 18.336 18.337 <para id="x_409">Capita spesso di mantenere una pila di patch su un repository sottostante che non modificate direttamente. Se state lavorando sui cambiamenti a codice di terze parti, o su una funzione che impiegate più tempo a sviluppare rispetto alla velocità di cambiamento del codice su cui si basa, avrete spesso bisogno di sincronizzarvi con il codice sottostante e di correggere ogni blocco delle vostre patch che non è più applicabile. Questa operazione si chiama <emphasis>rifondare</emphasis> la vostra serie di patch.</para> 18.338 18.339 - <para id="x_40a">Il modo più semplice per eseguire questa operazione è quello di usare <command role="hg-cmd">hg qpop -a</command> per estrarre le vostre patch, poi invocare <command role="hg-cmd">hg pull</command> per propagare i cambiamenti nel repository sottostante e infine eseguire <command role="hg-cmd">hg qpush -a</command> per inserire nuovamente le vostre patch. MQ interromperà l'inserimento ogni volta che incontra una patch che non riesce ad applicare a causa di qualche conflitto, dandovi la possibilità di risolvere i conflitti, aggiornare la patch interessata tramite <command role="hg-ext-mq">qrefresh</command> e continuare a inserire fino a quando non avrete corretto l'intera pila.</para> 18.340 - 18.341 - <para id="x_40b">Questo approccio è semplice e funziona bene se non vi aspettate che le modifiche al codice sottostante influenzino l'applicabilità delle vostre patch. Tuttavia, se la vostra pila di patch coinvolge codice che viene modificato in maniera frequente o invasiva nel repository sottostante, correggere a mano i blocchi rifiutati diventa velocemente una seccatura.</para> 18.342 + <para id="x_40a">Il modo più semplice per eseguire questa operazione è quello di usare <command role="hg-cmd">hg qpop -a</command> per estrarre le vostre patch, poi invocare <command role="hg-cmd">hg pull</command> per propagare i cambiamenti nel repository sottostante e infine eseguire <command role="hg-cmd">hg qpush -a</command> per inserire nuovamente le vostre patch. MQ interromperà l’inserimento ogni volta che incontra una patch che non riesce ad applicare a causa di qualche conflitto, dandovi la possibilità di risolvere i conflitti, aggiornare la patch interessata tramite <command role="hg-ext-mq">qrefresh</command> e continuare a inserire fino a quando non avrete corretto l’intera pila.</para> 18.343 + 18.344 + <para id="x_40b">Questo approccio è semplice e funziona bene se non vi aspettate che le modifiche al codice sottostante influenzino l’applicabilità delle vostre patch. Tuttavia, se la vostra pila di patch coinvolge codice che viene modificato in maniera frequente o invasiva nel repository sottostante, correggere a mano i blocchi rifiutati diventa velocemente una seccatura.</para> 18.345 18.346 <para id="x_40c">È possibile automatizzare parzialmente il processo di rifondazione. Se le vostre patch si applicano in maniera pulita su una qualche revisione del repository sottostante, MQ può usare questa informazione per aiutarvi a risolvere i conflitti tra le vostre patch e una revisione differente.</para> 18.347 18.348 @@ -359,16 +359,16 @@ 18.349 </listitem> 18.350 <listitem><para id="x_40f">Salvate una copia di backup della vostra directory delle patch usando <command role="hg-cmd">hg qsave -e -c</command>. Questo comando salva le patch in una directory chiamata <filename role="special" class="directory">.hg/patches.N</filename>, dove <literal>N</literal> è un piccolo intero, e stampa il nome della directory in cui sono state salvate le patch. Il comando inserisce anche un <quote>changeset di salvataggio</quote> dopo quelli corrispondenti alle vostre patch applicate, per registrare internamente gli stati dei file <filename role="special">series</filename> e <filename role="special">status</filename>.</para> 18.351 </listitem> 18.352 - <listitem><para id="x_410">Invocate <command role="hg-cmd">hg pull</command> per propagare i nuovi cambiamenti nel repository sottostante. (Non usate <command role="hg-cmd">hg pull -u</command>, perché l'aggiornamento dovrà essere fatto in maniera particolare, come vedrete nel prossimo punto.)</para> 18.353 + <listitem><para id="x_410">Invocate <command role="hg-cmd">hg pull</command> per propagare i nuovi cambiamenti nel repository sottostante. (Non usate <command role="hg-cmd">hg pull -u</command>, perché l’aggiornamento dovrà essere fatto in maniera particolare, come vedrete nel prossimo punto.)</para> 18.354 </listitem> 18.355 <listitem><para id="x_411">Aggiornate la directory di lavoro alla nuova revisione di punta, usando <command role="hg-cmd">hg update -C</command> per sovrascrivere le modifiche apportate dalle patch che avete inserito.</para> 18.356 </listitem> 18.357 - <listitem><para id="x_412">Unite tutte le patch usando <command>hg qpush -m -a</command>. L'opzione <option role="hg-ext-mq-cmd-qpush-opt">-m</option> di <command role="hg-ext-mq">qpush</command> dice a MQ di effettuare un'unione a tre vie se l'applicazione di una patch fallisce.</para> 18.358 + <listitem><para id="x_412">Unite tutte le patch usando <command>hg qpush -m -a</command>. L’opzione <option role="hg-ext-mq-cmd-qpush-opt">-m</option> di <command role="hg-ext-mq">qpush</command> dice a MQ di effettuare un’unione a tre vie se l’applicazione di una patch fallisce.</para> 18.359 </listitem></orderedlist> 18.360 18.361 - <para id="x_413">Durante l'esecuzione di <command role="hg-cmd">hg qpush -m</command>, ogni patch nel file <filename role="special">series</filename> viene applicata normalmente. Se una patch viene applicata con un fattore di incertezza o viene rifiutata, MQ esamina la coda che avete salvato tramite <command role="hg-ext-mq">qsave</command> ed effettua un'unione a tre vie con il changeset che corrisponde alla patch. Questa operazione sfrutta il normale meccanismo di unione di Mercurial, quindi potrebbe aprire uno strumento grafico di unione in modo da aiutarvi a risolvere i problemi.</para> 18.362 - 18.363 - <para id="x_414">Quando avete finito di risolvere gli effetti di una patch, MQ aggiornerà la vostra patch sulla base dei risultati dell'unione.</para> 18.364 + <para id="x_413">Durante l’esecuzione di <command role="hg-cmd">hg qpush -m</command>, ogni patch nel file <filename role="special">series</filename> viene applicata normalmente. Se una patch viene applicata con un fattore di incertezza o viene rifiutata, MQ esamina la coda che avete salvato tramite <command role="hg-ext-mq">qsave</command> ed effettua un’unione a tre vie con il changeset che corrisponde alla patch. Questa operazione sfrutta il normale meccanismo di unione di Mercurial, quindi potrebbe aprire uno strumento grafico di unione in modo da aiutarvi a risolvere i problemi.</para> 18.365 + 18.366 + <para id="x_414">Quando avete finito di risolvere gli effetti di una patch, MQ aggiornerà la vostra patch sulla base dei risultati dell’unione.</para> 18.367 18.368 <para id="x_415">Alla fine di questo processo, il vostro repository conterrà una testa aggiuntiva proveniente dalla vecchia coda delle patch e la directory <filename role="special" class="directory">.hg/patches.N</filename> conterrà una copia della vecchia coda delle patch. Potete rimuovere la testa aggiuntiva usando <command role="hg-cmd">hg qpop -a -n patches.N</command> o <command role="hg-cmd">hg strip</command>. Potete cancellare <filename role="special" class="directory">.hg/patches.N</filename> una volta che siete sicuri di non averne più bisogno come backup.</para> 18.369 </sect1> 18.370 @@ -382,11 +382,11 @@ 18.371 18.372 <para id="x_418">Il riferimento per indice non è molto diverso. La prima patch visualizzata da <command role="hg-ext-mq">qseries</command> è la patch numero zero (sì, è uno di quei sistemi di conteggio che partono da zero), la seconda è la patch numero uno, e così via.</para> 18.373 18.374 - <para id="x_419">MQ rende anche più facile lavorare con le patch usando i normali comandi Mercurial. Tutti i comandi che accettano un identificatore di changeset accettano anche il nome di una patch applicata. MQ aggiunge un'etichetta omonima per ogni patch applicata alle etichette normalmente presenti nel repository. In più, le etichette speciali <literal role="tag">qbase</literal> e <literal role="tag">qtip</literal> identificano rispettivamente la prima e l'ultima patch applicata.</para> 18.375 - 18.376 - <para id="x_41a">Queste aggiunte alla funzione di etichettatura di Mercurial facilitano ulteriormente l'uso delle patch.</para> 18.377 + <para id="x_419">MQ rende anche più facile lavorare con le patch usando i normali comandi Mercurial. Tutti i comandi che accettano un identificatore di changeset accettano anche il nome di una patch applicata. MQ aggiunge un’etichetta omonima per ogni patch applicata alle etichette normalmente presenti nel repository. In più, le etichette speciali <literal role="tag">qbase</literal> e <literal role="tag">qtip</literal> identificano rispettivamente la prima e l’ultima patch applicata.</para> 18.378 + 18.379 + <para id="x_41a">Queste aggiunte alla funzione di etichettatura di Mercurial facilitano ulteriormente l’uso delle patch.</para> 18.380 <itemizedlist> 18.381 - <listitem><para id="x_41b">Volete bombardare di patch una mailing list con l'ultima serie dei vostri cambiamenti?</para> 18.382 + <listitem><para id="x_41b">Volete bombardare di patch una mailing list con l’ultima serie dei vostri cambiamenti?</para> 18.383 <programlisting>hg email qbase:qtip</programlisting> 18.384 <para id="x_41c">(Non sapete cosa sia un <quote>bombardamento di patch</quote>? Leggete la <xref linkend="sec:hgext:patchbomb"/>.)</para> 18.385 </listitem> 18.386 @@ -395,9 +395,9 @@ 18.387 </listitem> 18.388 </itemizedlist> 18.389 18.390 - <para id="x_41e">Dato che MQ rende disponibili i nomi delle patch alle altre parti di Mercurial tramite il meccanismo interno delle etichette, non avete bisogno di digitare l'intero nome di una patch quando volete identificarla per nome.</para> 18.391 - 18.392 - <para id="x_41f">Un'altra piacevole conseguenza del rappresentare i nomi di patch come etichette è che il comando <command role="hg-cmd">hg log</command> mostrerà normalmente il nome di una patch come un'etichetta nel proprio elenco, rendendo facile distinguere visivamente le patch applicate dalle <quote>normali</quote> revisioni sottostanti. L'esempio seguente mostra alcuni comandi Mercurial in azione con le patch applicate.</para> 18.393 + <para id="x_41e">Dato che MQ rende disponibili i nomi delle patch alle altre parti di Mercurial tramite il meccanismo interno delle etichette, non avete bisogno di digitare l’intero nome di una patch quando volete identificarla per nome.</para> 18.394 + 18.395 + <para id="x_41f">Un’altra piacevole conseguenza del rappresentare i nomi di patch come etichette è che il comando <command role="hg-cmd">hg log</command> mostrerà normalmente il nome di una patch come un’etichetta nel proprio elenco, rendendo facile distinguere visivamente le patch applicate dalle <quote>normali</quote> revisioni sottostanti. L’esempio seguente mostra alcuni comandi Mercurial in azione con le patch applicate.</para> 18.396 18.397 &interaction.mq.id.output; 18.398 </sect1> 18.399 @@ -405,12 +405,12 @@ 18.400 <sect1> 18.401 <title>Informazioni utili</title> 18.402 18.403 - <para id="x_420">Ci sono alcuni aspetti dell'uso di MQ che non trovano posto in sezioni dedicate, ma che è bene conoscere. Li presento qui, in un unico posto.</para> 18.404 + <para id="x_420">Ci sono alcuni aspetti dell’uso di MQ che non trovano posto in sezioni dedicate, ma che è bene conoscere. Li presento qui, in un unico posto.</para> 18.405 18.406 <itemizedlist> 18.407 - <listitem><para id="x_421">Normalmente, quando estraete una patch tramite <command role="hg-ext-mq">qpop</command> e poi la reinserite tramite <command role="hg-ext-mq">qpush</command>, il changeset che rappresenta la patch dopo l'estrazione/inserimento avrà una <emphasis>diversa identità</emphasis> rispetto al changeset che rappresentava l'hash in precedenza. Leggete la <xref linkend="sec:mqref:cmd:qpush"/> per sapere perché.</para> 18.408 - </listitem> 18.409 - <listitem><para id="x_422">Non è una buona idea usare <command role="hg-cmd">hg merge</command> per unire i cambiamenti provenienti da un altro ramo con un changeset corrispondente a una patch, almeno se volete mantenere la <quote>natura di patch</quote> di quel changeset e dei changeset che si trovano sotto a quello nella pila delle patch. Se provate a farlo, sembrerà avere successo, ma l'effetto sarà quello di disorientare MQ.</para> 18.410 + <listitem><para id="x_421">Normalmente, quando estraete una patch tramite <command role="hg-ext-mq">qpop</command> e poi la reinserite tramite <command role="hg-ext-mq">qpush</command>, il changeset che rappresenta la patch dopo l’estrazione/inserimento avrà una <emphasis>diversa identità</emphasis> rispetto al changeset che rappresentava l’hash in precedenza. Leggete la <xref linkend="sec:mqref:cmd:qpush"/> per sapere perché.</para> 18.411 + </listitem> 18.412 + <listitem><para id="x_422">Non è una buona idea usare <command role="hg-cmd">hg merge</command> per unire i cambiamenti provenienti da un altro ramo con un changeset corrispondente a una patch, almeno se volete mantenere la <quote>natura di patch</quote> di quel changeset e dei changeset che si trovano sotto a quello nella pila delle patch. Se provate a farlo, sembrerà avere successo, ma l’effetto sarà quello di disorientare MQ.</para> 18.413 </listitem> 18.414 </itemizedlist> 18.415 </sect1> 18.416 @@ -420,26 +420,26 @@ 18.417 18.418 <para id="x_423">Dato che la directory <filename role="special" class="directory">.hg/patches</filename> di MQ risiede fuori dalla directory di lavoro di un repository Mercurial, il repository Mercurial <quote>sottostante</quote> non sa nulla della gestione o della presenza delle patch.</para> 18.419 18.420 - <para id="x_424">Questo presenta l'interessante possibilità di gestire i contenuti della directory delle patch come un repository Mercurial indipendente. Questo può essere un modo utile per lavorare. Per esempio, potete lavorare su una patch per un po', aggiornarla tramite <command role="hg-ext-mq">qrefresh</command>, poi usare <command role="hg-cmd">hg commit</command> per registrare lo stato corrente della patch. Questo vi permette di <quote>ritornare</quote> a quella versione della patch più tardi.</para> 18.421 - 18.422 - <para id="x_425">Potete quindi condividere differenti versioni della stessa pila di patch tra molteplici repository sottostanti. Uso questa tecnica quando sto sviluppando una funzione del kernel di Linux. Ho una copia intatta dei miei sorgenti del kernel per ogni diversa architettura di CPU e un repository clonato su ognuna di queste architetture che contiene le patch su cui sto lavorando. Quando voglio collaudare una modifica su un'architettura differente, trasmetto le mie patch correnti al repository associato con il kernel di quell'architettura, estraggo e inserisco tutte le mie patch, infine assemblo e collaudo quel kernel.</para> 18.423 + <para id="x_424">Questo presenta l’interessante possibilità di gestire i contenuti della directory delle patch come un repository Mercurial indipendente. Questo può essere un modo utile per lavorare. Per esempio, potete lavorare su una patch per un po’, aggiornarla tramite <command role="hg-ext-mq">qrefresh</command>, poi usare <command role="hg-cmd">hg commit</command> per registrare lo stato corrente della patch. Questo vi permette di <quote>ritornare</quote> a quella versione della patch più tardi.</para> 18.424 + 18.425 + <para id="x_425">Potete quindi condividere differenti versioni della stessa pila di patch tra molteplici repository sottostanti. Uso questa tecnica quando sto sviluppando una funzione del kernel di Linux. Ho una copia intatta dei miei sorgenti del kernel per ogni diversa architettura di CPU e un repository clonato su ognuna di queste architetture che contiene le patch su cui sto lavorando. Quando voglio collaudare una modifica su un’architettura differente, trasmetto le mie patch correnti al repository associato con il kernel di quell’architettura, estraggo e inserisco tutte le mie patch, infine assemblo e collaudo quel kernel.</para> 18.426 18.427 <para id="x_426">Gestire le patch in un repository consente a più sviluppatori di lavorare sulla stessa serie di patch senza scontrarsi tra loro e basandosi su sorgenti sottostanti che potrebbero o non potrebbero essere sotto il loro controllo.</para> 18.428 18.429 <sect2> 18.430 <title>Il supporto di MQ per i repository di patch</title> 18.431 18.432 - <para id="x_427">MQ vi aiuta a lavorare con la directory <filename role="special" class="directory">.hg/patches</filename> in qualità di repository. Quando preparate un repository per lavorare con le patch usando <command role="hg-ext-mq">qinit</command>, potete passare l'opzione <option role="hg-ext-mq-cmd-qinit-opt">-c</option> per creare la directory <filename role="special" class="directory">.hg/patches</filename> sotto forma di repository Mercurial.</para> 18.433 + <para id="x_427">MQ vi aiuta a lavorare con la directory <filename role="special" class="directory">.hg/patches</filename> in qualità di repository. Quando preparate un repository per lavorare con le patch usando <command role="hg-ext-mq">qinit</command>, potete passare l’opzione <option role="hg-ext-mq-cmd-qinit-opt">-c</option> per creare la directory <filename role="special" class="directory">.hg/patches</filename> sotto forma di repository Mercurial.</para> 18.434 18.435 <note> 18.436 - <para id="x_428">Se dimenticate di usare l'opzione <option role="hg-ext-mq-cmd-qinit-opt">-c</option>, potete semplicemente posizionarvi nella directory <filename role="special" class="directory">.hg/patches</filename> in qualsiasi momento e invocare <command role="hg-cmd">hg init</command>. Non dimenticate, però, di aggiungere una voce per il file <filename role="special">status</filename> al file <filename role="special">.hgignore</filename> (<command role="hg-cmd">hg qinit -c</command> lo fa automaticamente per voi), perché il file <filename role="special">status</filename> non andrebbe <emphasis>davvero</emphasis> amministrato.</para> 18.437 + <para id="x_428">Se dimenticate di usare l’opzione <option role="hg-ext-mq-cmd-qinit-opt">-c</option>, potete semplicemente posizionarvi nella directory <filename role="special" class="directory">.hg/patches</filename> in qualsiasi momento e invocare <command role="hg-cmd">hg init</command>. Non dimenticate, però, di aggiungere una voce per il file <filename role="special">status</filename> al file <filename role="special">.hgignore</filename> (<command role="hg-cmd">hg qinit -c</command> lo fa automaticamente per voi), perché il file <filename role="special">status</filename> non andrebbe <emphasis>davvero</emphasis> amministrato.</para> 18.438 </note> 18.439 18.440 <para id="x_42a">Per convenienza, se MQ nota che la directory <filename class="directory">.hg/patches</filename> è un repository, userà automaticamente <command role="hg-cmd">hg add</command> per aggiungere ogni patch che create e importate.</para> 18.441 18.442 <para id="x_42b">MQ fornisce il comando abbreviato <command role="hg-ext-mq">qcommit</command> che esegue <command role="hg-cmd">hg commit</command> nella directory <filename role="special" class="directory">.hg/patches</filename>, per risparmiarvi noiose digitazioni.</para> 18.443 18.444 - <para id="x_42c">Infine, sui sistemi Unix, potete definire l'alias <command>mq</command> come comando di convenienza per gestire la directory delle patch. Per esempio, sui sistemi Linux che usano la shell <command>bash</command>, potete aggiungere la riga seguente al vostro file <filename role="home">~/.bashrc</filename>.</para> 18.445 + <para id="x_42c">Infine, sui sistemi Unix, potete definire l’alias <command>mq</command> come comando di convenienza per gestire la directory delle patch. Per esempio, sui sistemi Linux che usano la shell <command>bash</command>, potete aggiungere la riga seguente al vostro file <filename role="home">~/.bashrc</filename>.</para> 18.446 18.447 <programlisting>alias mq=`hg -R $(hg root)/.hg/patches'</programlisting> 18.448 18.449 @@ -458,9 +458,9 @@ 18.450 <sect1 id="sec:mq:tools"> 18.451 <title>Strumenti di terze parti che lavorano con le patch</title> 18.452 18.453 - <para id="x_430">Una volta che avete lavorato con le patch per un po', vi troverete desiderosi di utilizzare strumenti che vi aiutino a capire e manipolare le patch di cui vi state occupando.</para> 18.454 - 18.455 - <para id="x_431">Il comando <command>diffstat</command> <citation><xref linkend="bib:diffstat"/></citation> genera un istogramma delle modifiche effettuate a ogni file in una patch. Fornisce un buon modo per <quote>farsi un'idea</quote> di una patch&emdash;quali file coinvolge e quante modifiche introduce a ogni file e nell'insieme. (Trovo che sia una buona idea usare regolarmente l'opzione <option role="cmd-opt-diffstat">-p</option> di <command>diffstat</command>, poiché altrimenti il comando proverà a manipolare i prefissi dei nomi di file in un modo che almeno io trovo inevitabilmente confuso.)</para> 18.456 + <para id="x_430">Una volta che avete lavorato con le patch per un po’, vi troverete desiderosi di utilizzare strumenti che vi aiutino a capire e manipolare le patch di cui vi state occupando.</para> 18.457 + 18.458 + <para id="x_431">Il comando <command>diffstat</command> <citation><xref linkend="bib:diffstat"/></citation> genera un istogramma delle modifiche effettuate a ogni file in una patch. Fornisce un buon modo per <quote>farsi un’idea</quote> di una patch&emdash;quali file coinvolge e quante modifiche introduce a ogni file e nell’insieme. (Trovo che sia una buona idea usare regolarmente l’opzione <option role="cmd-opt-diffstat">-p</option> di <command>diffstat</command>, poiché altrimenti il comando proverà a manipolare i prefissi dei nomi di file in un modo che almeno io trovo inevitabilmente confuso.)</para> 18.459 18.460 &interaction.mq.tools.tools; 18.461 18.462 @@ -474,9 +474,9 @@ 18.463 18.464 <para id="x_434">Date nomi descrittivi alle vostre patch. Un buon nome per una patch potrebbe essere <filename>riorganizza-allocazione-dispositivi.patch</filename>, perché vi suggerirà immediatamente qual è lo scopo della patch. I nomi lunghi non dovrebbero essere un problema: non digiterete i nomi spesso, ma <emphasis>invocherete</emphasis> comandi come <command role="hg-ext-mq">qapplied</command> e <command role="hg-ext-mq">qtop</command> più e più volte. Una buona denominazione diventa particolarmente importante quando state lavorando con un certo numero di patch, o se vi state destreggiando tra un certo numero di attività differenti e le vostre patch ottengono solo una frazione della vostra attenzione.</para> 18.465 18.466 - <para id="x_435">Siate consapevoli della patch su cui state lavorando. Usate frequentemente il comando <command role="hg-ext-mq">qtop</command> e date un'occhiata al testo delle vostre patch&emdash;per esempio, usando <command role="hg-cmd">hg tip -p</command>&emdash;per assicurarvi di sapere dove vi trovate. Mi è capitato molte volte di modificare e aggiornare una patch diversa da quella che intendevo, ed è spesso complicato trasferire le modifiche nella patch giusta dopo averle inserite in quella sbagliata.</para> 18.467 - 18.468 - <para id="x_436">Per questo motivo, vale davvero la pena di investire un po' di tempo per imparare a usare alcuni degli strumenti di terze parti che ho descritto nella <xref linkend="sec:mq:tools"/>, in particolare <command>diffstat</command> e <command>filterdiff</command>. Il primo vi darà velocemente un'idea di quali sono le modifiche effettuate dalla vostra patch, mentre il secondo vi renderà più facile selezionare blocchi particolari di una patch e inserirli in un'altra.</para> 18.469 + <para id="x_435">Siate consapevoli della patch su cui state lavorando. Usate frequentemente il comando <command role="hg-ext-mq">qtop</command> e date un’occhiata al testo delle vostre patch&emdash;per esempio, usando <command role="hg-cmd">hg tip -p</command>&emdash;per assicurarvi di sapere dove vi trovate. Mi è capitato molte volte di modificare e aggiornare una patch diversa da quella che intendevo, ed è spesso complicato trasferire le modifiche nella patch giusta dopo averle inserite in quella sbagliata.</para> 18.470 + 18.471 + <para id="x_436">Per questo motivo, vale davvero la pena di investire un po’ di tempo per imparare a usare alcuni degli strumenti di terze parti che ho descritto nella <xref linkend="sec:mq:tools"/>, in particolare <command>diffstat</command> e <command>filterdiff</command>. Il primo vi darà velocemente un’idea di quali sono le modifiche effettuate dalla vostra patch, mentre il secondo vi renderà più facile selezionare blocchi particolari di una patch e inserirli in un’altra.</para> 18.472 18.473 </sect1> 18.474 <sect1> 18.475 @@ -487,7 +487,7 @@ 18.476 18.477 <para id="x_437">Dato che il costo di aggiungere file in un nuovo repository Mercurial è così basso, ha molto senso gestire le patch in questo modo anche se volete semplicemente fare alcune modifiche a un archivo di sorgenti che avete scaricato.</para> 18.478 18.479 - <para id="x_438">Cominciate con lo scaricare l'archivio dei sorgenti, estraendone i contenuti e trasformandoli in un repository Mercurial.</para> 18.480 + <para id="x_438">Cominciate con lo scaricare l’archivio dei sorgenti, estraendone i contenuti e trasformandoli in un repository Mercurial.</para> 18.481 18.482 &interaction.mq.tarball.download; 18.483 18.484 @@ -499,7 +499,7 @@ 18.485 18.486 &interaction.mq.tarball.newsource; 18.487 18.488 - <para id="x_43b">La coppia di comandi che comincia con <command role="hg-cmd">hg locate</command> appena invocata cancella tutti i file dalla directory di lavoro, in modo che l'opzione <option role="hg-opt-commit">--addremove</option> di <command role="hg-cmd">hg commit</command> possa effettivamente dirvi quali file sono stati davvero rimossi nella nuova versione dei sorgenti.</para> 18.489 + <para id="x_43b">La coppia di comandi che comincia con <command role="hg-cmd">hg locate</command> appena invocata cancella tutti i file dalla directory di lavoro, in modo che l’opzione <option role="hg-opt-commit">--addremove</option> di <command role="hg-cmd">hg commit</command> possa effettivamente dirvi quali file sono stati davvero rimossi nella nuova versione dei sorgenti.</para> 18.490 18.491 <para id="x_43c">Infine, potete applicare le vostre patch al nuovo albero.</para> 18.492 18.493 @@ -509,17 +509,17 @@ 18.494 <sect2 id="sec:mq:combine"> 18.495 <title>Combinare intere patch</title> 18.496 18.497 - <para id="x_43d">MQ vi fornisce il comando <command role="hg-ext-mq">qfold</command> per consentirvi di combinare intere patch tra loro. Questo comando <quote>include</quote> le patch che nominate, nell'ordine in cui le nominate, nell'ultima patch applicata e concatena le loro descrizioni aggiungendole alla fine della descrizione di questa patch. Se le patch che includete sono applicate, devono essere estratte prima di poterle includere.</para> 18.498 - 18.499 - <para id="x_43e">L'ordine in cui includete le patch è importante. Se la vostra ultima patch applicata è <literal>foo</literal> e voi utilizzate <command role="hg-ext-mq">qfold</command> per includervi <literal>bar</literal> e <literal>quux</literal>, otterrete una patch che opererà come se aveste applicato prima <literal>foo</literal>, poi <literal>bar</literal>, seguita da <literal>quux</literal>.</para> 18.500 - </sect2> 18.501 - 18.502 - <sect2> 18.503 - <title>Unire parte di una patch a un'altra</title> 18.504 - 18.505 - <para id="x_43f">Unire <emphasis>parte</emphasis> di una patch a un'altra patch è più difficile che combinare intere patch tra loro.</para> 18.506 - 18.507 - <para id="x_440">Se volete spostare alcune modifiche su interi file, potete usare le opzioni <option role="cmd-opt-filterdiff">-i</option> e <option role="cmd-opt-filterdiff">-x</option> di <command>filterdiff</command> per scegliere le modifiche che desiderate ricavare da una patch, aggiungendo il risultato del comando in coda alla patch a cui unire i cambiamenti. Di solito non avrete bisogno di modificare la patch da cui prelevate le modifiche da unire. Piuttosto, MQ rifiuterà alcune parti della patch quando invocate <command role="hg-ext-mq">qpush</command> su di essa (a causa dei blocchi che avete spostato nell'altra patch) e voi potrete semplicemente aggiornare la patch tramite <command role="hg-ext-mq">qrefresh</command> per scartare i blocchi duplicati.</para> 18.508 + <para id="x_43d">MQ vi fornisce il comando <command role="hg-ext-mq">qfold</command> per consentirvi di combinare intere patch tra loro. Questo comando <quote>include</quote> le patch che nominate, nell’ordine in cui le nominate, nell’ultima patch applicata e concatena le loro descrizioni aggiungendole alla fine della descrizione di questa patch. Se le patch che includete sono applicate, devono essere estratte prima di poterle includere.</para> 18.509 + 18.510 + <para id="x_43e">L’ordine in cui includete le patch è importante. Se la vostra ultima patch applicata è <literal>foo</literal> e voi utilizzate <command role="hg-ext-mq">qfold</command> per includervi <literal>bar</literal> e <literal>quux</literal>, otterrete una patch che opererà come se aveste applicato prima <literal>foo</literal>, poi <literal>bar</literal>, seguita da <literal>quux</literal>.</para> 18.511 + </sect2> 18.512 + 18.513 + <sect2> 18.514 + <title>Unire parte di una patch a un’altra</title> 18.515 + 18.516 + <para id="x_43f">Unire <emphasis>parte</emphasis> di una patch a un’altra patch è più difficile che combinare intere patch tra loro.</para> 18.517 + 18.518 + <para id="x_440">Se volete spostare alcune modifiche su interi file, potete usare le opzioni <option role="cmd-opt-filterdiff">-i</option> e <option role="cmd-opt-filterdiff">-x</option> di <command>filterdiff</command> per scegliere le modifiche che desiderate ricavare da una patch, aggiungendo il risultato del comando in coda alla patch a cui unire i cambiamenti. Di solito non avrete bisogno di modificare la patch da cui prelevate le modifiche da unire. Piuttosto, MQ rifiuterà alcune parti della patch quando invocate <command role="hg-ext-mq">qpush</command> su di essa (a causa dei blocchi che avete spostato nell’altra patch) e voi potrete semplicemente aggiornare la patch tramite <command role="hg-ext-mq">qrefresh</command> per scartare i blocchi duplicati.</para> 18.519 18.520 <para id="x_441">Se avete una patch con più blocchi che modificano un file e volete spostare solo alcuni di questi blocchi, il lavoro diventa più complicato, ma potete comunque automatizzarlo parzialmente. Usate <command>lsdiff -nvv</command> per stampare alcuni metadati sulla patch.</para> 18.521 18.522 @@ -546,7 +546,7 @@ 18.523 18.524 <para id="x_448">Se avete già familiarità con quilt, MQ fornisce un insieme di comandi simile. Ci sono alcune differenze nel modo in cui questi comandi lavorano.</para> 18.525 18.526 - <para id="x_449">Avrete già notato che la maggior parte dei comandi di quilt hanno una controparte MQ che comincia semplicemente con una <quote><literal>q</literal></quote>. Le eccezioni sono i comandi <literal>add</literal> e <literal>remove</literal> di quilt, le cui controparti sono i normali comandi Mercurial <command role="hg-cmd">hg add</command> e <command role="hg-cmd">hg remove</command>. Non c'è alcun comando MQ equivalente al comando quilt <literal>edit</literal>.</para> 18.527 + <para id="x_449">Avrete già notato che la maggior parte dei comandi di quilt hanno una controparte MQ che comincia semplicemente con una <quote><literal>q</literal></quote>. Le eccezioni sono i comandi <literal>add</literal> e <literal>remove</literal> di quilt, le cui controparti sono i normali comandi Mercurial <command role="hg-cmd">hg add</command> e <command role="hg-cmd">hg remove</command>. Non c’è alcun comando MQ equivalente al comando quilt <literal>edit</literal>.</para> 18.528 18.529 </sect1> 18.530 </chapter>
19.1 --- a/it/ch13-mq-collab.xml Sat Aug 22 21:01:56 2009 +0200 19.2 +++ b/it/ch13-mq-collab.xml Sat Aug 22 21:55:05 2009 +0200 19.3 @@ -11,13 +11,13 @@ 19.4 <sect1> 19.5 <title>Il problema di gestire molti obiettivi</title> 19.6 19.7 - <para id="x_160">Il kernel di Linux cambia rapidamente e non è mai stato stabile internamente, in quanto gli sviluppatori effettuano frequentemente modifiche drastiche tra una release e l'altra. Questo significa che, di solito, una versione del driver che funziona bene con una particolare versione rilasciata del kernel non potrà nemmeno essere <emphasis>compilata</emphasis> correttamente su qualsiasi altra versione del kernel.</para> 19.8 + <para id="x_160">Il kernel di Linux cambia rapidamente e non è mai stato stabile internamente, in quanto gli sviluppatori effettuano frequentemente modifiche drastiche tra una release e l’altra. Questo significa che, di solito, una versione del driver che funziona bene con una particolare versione rilasciata del kernel non potrà nemmeno essere <emphasis>compilata</emphasis> correttamente su qualsiasi altra versione del kernel.</para> 19.9 19.10 <para id="x_161">Per mantenere un driver, dobbiamo considerare un certo numero di versioni di Linux differenti.</para> 19.11 <itemizedlist> 19.12 - <listitem><para id="x_162">Un obiettivo è l'albero di sviluppo principale del kernel di Linux. In questo caso, le attività di manutenzione del codice sono parzialmente condivise con altri sviluppatori della comunità del kernel, che effettuano modifiche <quote>estemporanee</quote> al driver man mano che sviluppano e rifiniscono i sottosistemi del kernel.</para> 19.13 - </listitem> 19.14 - <listitem><para id="x_163">Manteniamo anche un certo numero di <quote>backport</quote> (letteralmente, conversioni all'indietro) verso vecchie versioni del kernel di Linux, per soddisfare le necessità di clienti che stanno utilizzando distribuzioni di Linux più vecchie che non incorporano i nostri driver. (Effettuare il <emphasis>backport</emphasis> del codice significa modificarlo per farlo funzionare in una versione del suo ambiente di destinazione più vecchia di quella per la quale era stato sviluppato.)</para> 19.15 + <listitem><para id="x_162">Un obiettivo è l’albero di sviluppo principale del kernel di Linux. In questo caso, le attività di manutenzione del codice sono parzialmente condivise con altri sviluppatori della comunità del kernel, che effettuano modifiche <quote>estemporanee</quote> al driver man mano che sviluppano e rifiniscono i sottosistemi del kernel.</para> 19.16 + </listitem> 19.17 + <listitem><para id="x_163">Manteniamo anche un certo numero di <quote>backport</quote> (letteralmente, conversioni all’indietro) verso vecchie versioni del kernel di Linux, per soddisfare le necessità di clienti che stanno utilizzando distribuzioni di Linux più vecchie che non incorporano i nostri driver. (Effettuare il <emphasis>backport</emphasis> del codice significa modificarlo per farlo funzionare in una versione del suo ambiente di destinazione più vecchia di quella per la quale era stato sviluppato.)</para> 19.18 </listitem> 19.19 <listitem><para id="x_164">Infine, rilasciamo il software seguendo una tabella di marcia che non è necessariamente allineata con quella usata da chi sviluppa il kernel e da chi distribuisce il sistema operativo, in modo da poter consegnare nuove funzioni ai clienti senza obbligarli ad aggiornare il loro kernel o la loro intera distribuzione.</para> 19.20 </listitem> 19.21 @@ -28,11 +28,11 @@ 19.22 19.23 <para id="x_165">Ci sono due modi <quote>standard</quote> per mantenere un software che deve funzionare in molti ambienti diversi.</para> 19.24 19.25 - <para id="x_166">Il primo è mantenere un certo numero di rami, ognuno dedicato a un singolo obiettivo. Il problema di questo approccio è che dovete mantenere una ferrea disciplina nel flusso dei cambiamenti tra i repository. Una nuova funzione o correzione di bug deve prendere vita in un repository <quote>intatto</quote>, poi passare a tutti i repository di backport. Le modifiche di backport dovrebbero propagarsi verso un numero di rami più limitato, in quanto l'applicazione di una modifica di backport su un ramo a cui non appartiene probabilmente impedirà al driver di essere compilato.</para> 19.26 - 19.27 - <para id="x_167">Il secondo è quello di mantenere un singolo albero di sorgenti pieno di istruzioni condizionali che attivano o disattivano parti di codice a seconda dell'ambiente designato. Dato che queste istruzioni <quote>ifdef</quote> non sono permesse nell'albero del kernel di Linux, è necessario seguire una procedura manuale o automatica per eliminarle e produrre un albero pulito. Una base di codice mantenuta in questo modo diventa rapidamente un caos di blocchi condizionali che sono difficili da capire e mantenere.</para> 19.28 - 19.29 - <para id="x_168">Nessuno di questi approcci è particolarmente adatto a situazioni in cui non <quote>possedete</quote> la copia ufficiale di un albero di sorgenti. Nel caso di un driver Linux che viene distribuito insieme al kernel standard, l'albero di Linus contiene la copia del codice che verrà universalmente considerata ufficiale. La versione a monte del <quote>mio</quote> driver può essere modificata da persone che non conosco, senza che io nemmeno lo scopra fino a quando i cambiamenti non appaiono nell'albero di Linus.</para> 19.30 + <para id="x_166">Il primo è mantenere un certo numero di rami, ognuno dedicato a un singolo obiettivo. Il problema di questo approccio è che dovete mantenere una ferrea disciplina nel flusso dei cambiamenti tra i repository. Una nuova funzione o correzione di bug deve prendere vita in un repository <quote>intatto</quote>, poi passare a tutti i repository di backport. Le modifiche di backport dovrebbero propagarsi verso un numero di rami più limitato, in quanto l’applicazione di una modifica di backport su un ramo a cui non appartiene probabilmente impedirà al driver di essere compilato.</para> 19.31 + 19.32 + <para id="x_167">Il secondo è quello di mantenere un singolo albero di sorgenti pieno di istruzioni condizionali che attivano o disattivano parti di codice a seconda dell’ambiente designato. Dato che queste istruzioni <quote>ifdef</quote> non sono permesse nell’albero del kernel di Linux, è necessario seguire una procedura manuale o automatica per eliminarle e produrre un albero pulito. Una base di codice mantenuta in questo modo diventa rapidamente un caos di blocchi condizionali che sono difficili da capire e mantenere.</para> 19.33 + 19.34 + <para id="x_168">Nessuno di questi approcci è particolarmente adatto a situazioni in cui non <quote>possedete</quote> la copia ufficiale di un albero di sorgenti. Nel caso di un driver Linux che viene distribuito insieme al kernel standard, l’albero di Linus contiene la copia del codice che verrà universalmente considerata ufficiale. La versione a monte del <quote>mio</quote> driver può essere modificata da persone che non conosco, senza che io nemmeno lo scopra fino a quando i cambiamenti non appaiono nell’albero di Linus.</para> 19.35 19.36 <para id="x_169">Questi approcci hanno la debolezza aggiuntiva di rendere difficile generare patch ben formate da presentare a monte.</para> 19.37 19.38 @@ -49,7 +49,7 @@ 19.39 19.40 <para id="x_16c">Questo ci fornisce un piccolo repository contenente due patch che non hanno alcuna dipendenza reciproca, perché coinvolgono file differenti.</para> 19.41 19.42 - <para id="x_16d">L'idea alla base dell'applicazione condizionale è la possibilità di <quote>etichettare</quote> una patch con una <emphasis>guardia</emphasis>, che è semplicemente una stringa di testo di vostra scelta, per poi dire a MQ di selezionare le guardie specifiche da usare al momento di applicare le patch. MQ applicherà, o salterà, una patch con guardia a seconda delle guardie che avete selezionato.</para> 19.43 + <para id="x_16d">L’idea alla base dell’applicazione condizionale è la possibilità di <quote>etichettare</quote> una patch con una <emphasis>guardia</emphasis>, che è semplicemente una stringa di testo di vostra scelta, per poi dire a MQ di selezionare le guardie specifiche da usare al momento di applicare le patch. MQ applicherà, o salterà, una patch con guardia a seconda delle guardie che avete selezionato.</para> 19.44 19.45 <para id="x_16e">Una patch può avere un numero arbitrario di guardie, ognuna delle quali è <emphasis>positiva</emphasis> (<quote>applica questa patch se questa guardia è selezionata</quote>) o <emphasis>negativa</emphasis> (<quote>salta questa patch se questa guardia è selezionata</quote>). Una patch senza alcuna guardia viene sempre applicata.</para> 19.46 19.47 @@ -69,12 +69,12 @@ 19.48 19.49 &interaction.mq.guards.qguard.neg; 19.50 19.51 - <para id="x_74a">Notate che in questo caso gli argomenti del comando <command>hg qguard</command> sono introdotti con il prefisso <literal>--</literal>, così Mercurial eviterà di interpretare il testo <literal>-quux</literal> come un'opzione.</para> 19.52 + <para id="x_74a">Notate che in questo caso gli argomenti del comando <command>hg qguard</command> sono introdotti con il prefisso <literal>--</literal>, così Mercurial eviterà di interpretare il testo <literal>-quux</literal> come un’opzione.</para> 19.53 19.54 <note> 19.55 <title>Impostare e modificare</title> 19.56 19.57 - <para id="x_172">Il comando <command role="hg-ext-mq">qguard</command> <emphasis>imposta</emphasis> le guardie su una patch, ma non le <emphasis>modifica</emphasis>. Questo significa che se invocate <command role="hg-cmd">hg qguard +a +b</command> su una patch, quindi invocate <command role="hg-cmd">hg qguard +c</command> sulla stessa patch, l'<emphasis>unica</emphasis> guardia che risulterà successivamente impostata sarà <literal>+c</literal>.</para> 19.58 + <para id="x_172">Il comando <command role="hg-ext-mq">qguard</command> <emphasis>imposta</emphasis> le guardie su una patch, ma non le <emphasis>modifica</emphasis>. Questo significa che se invocate <command role="hg-cmd">hg qguard +a +b</command> su una patch, quindi invocate <command role="hg-cmd">hg qguard +c</command> sulla stessa patch, l’<emphasis>unica</emphasis> guardia che risulterà successivamente impostata sarà <literal>+c</literal>.</para> 19.59 </note> 19.60 19.61 <para id="x_173">Mercurial memorizza le guardie nel file <filename role="special">series</filename>, in una forma facile sia da capire che da modificare a mano. (In altre parole, non dovete usare il comando <command role="hg-ext-mq">qguard</command> se non volete, perché potete semplicemente modificare il file <filename role="special">series</filename>.)</para> 19.62 @@ -107,7 +107,7 @@ 19.63 19.64 &interaction.mq.guards.qselect.quux; 19.65 19.66 - <para id="x_17a">Potete vedere nell'esempio seguente che le guardie negative hanno la precedenza sulle guardie positive.</para> 19.67 + <para id="x_17a">Potete vedere nell’esempio seguente che le guardie negative hanno la precedenza sulle guardie positive.</para> 19.68 19.69 &interaction.mq.guards.qselect.foobar; 19.70 19.71 @@ -129,13 +129,13 @@ 19.72 19.73 </sect1> 19.74 <sect1> 19.75 - <title>Ridimensionare l'ambiente di lavoro</title> 19.76 - 19.77 - <para id="x_180">Lavorando sul driver di dispositivo menzionato in precedenza, non applico le patch a un normale albero del kernel di Linux, ma uso un repository che contiene solo una fotografia dei file sorgente rilevanti per lo sviluppo del dispositivo Infiniband. Lavorare con questo repository è più facile, perché le sue dimensioni sono l'1% delle dimensioni di un repository del kernel.</para> 19.78 - 19.79 - <para id="x_181">Poi scelgo una versione <quote>di base</quote> sulla quale le patch vengono applicate. Questa è una fotografia dell'albero del kernel di Linux scattata su una revisione di mia scelta. Quando scatto la fotografia, registro l'identificatore di changeset proveniente dal repository del kernel nel messaggio di commit. Dato che la fotografia mantiene la <quote>forma</quote> e il contenuto delle parti rilevanti dell'albero del kernel, posso applicare le mie patch sul mio repository ridotto o su un normale albero del kernel.</para> 19.80 - 19.81 - <para id="x_182">Normalmente, l'albero di base su cui applicare le patch dovrebbe essere una fotografia di un albero a monte molto recente. Questa è la condizione migliore per facilitare lo sviluppo di patch che possono essere presentate a monte con poche o addirittura nessuna modifica.</para> 19.82 + <title>Ridimensionare l’ambiente di lavoro</title> 19.83 + 19.84 + <para id="x_180">Lavorando sul driver di dispositivo menzionato in precedenza, non applico le patch a un normale albero del kernel di Linux, ma uso un repository che contiene solo una fotografia dei file sorgente rilevanti per lo sviluppo del dispositivo Infiniband. Lavorare con questo repository è più facile, perché le sue dimensioni sono l’1% delle dimensioni di un repository del kernel.</para> 19.85 + 19.86 + <para id="x_181">Poi scelgo una versione <quote>di base</quote> sulla quale le patch vengono applicate. Questa è una fotografia dell’albero del kernel di Linux scattata su una revisione di mia scelta. Quando scatto la fotografia, registro l’identificatore di changeset proveniente dal repository del kernel nel messaggio di commit. Dato che la fotografia mantiene la <quote>forma</quote> e il contenuto delle parti rilevanti dell’albero del kernel, posso applicare le mie patch sul mio repository ridotto o su un normale albero del kernel.</para> 19.87 + 19.88 + <para id="x_182">Normalmente, l’albero di base su cui applicare le patch dovrebbe essere una fotografia di un albero a monte molto recente. Questa è la condizione migliore per facilitare lo sviluppo di patch che possono essere presentate a monte con poche o addirittura nessuna modifica.</para> 19.89 19.90 </sect1> 19.91 <sect1> 19.92 @@ -143,25 +143,25 @@ 19.93 19.94 <para id="x_183">Categorizzo le patch nel file <filename role="special">series</filename> in un certo numero di gruppi logici. Ogni sezione di patch simili comincia con un blocco di commenti che descrive lo scopo delle patch che seguono.</para> 19.95 19.96 - <para id="x_184">La sequenza dei gruppi di patch che mantengo è la seguente. L'ordine di questi gruppi è importante per i motivi che verranno descritti dopo aver introdotto i gruppi.</para> 19.97 - <itemizedlist> 19.98 - <listitem><para id="x_185">Il gruppo delle patch <quote>accettate</quote>. Sono le patch che il gruppo di sviluppo ha proposto al manutentore del sottosistema Infiniband e che sono state accettate, ma che non sono presenti nella fotografia su cui si basa il repository ridotto. Queste sono patch <quote>a sola lettura</quote>, presenti unicamente allo scopo di trasformare l'albero in uno stato simile a quello in cui si trova nel repository del manutentore a monte.</para> 19.99 + <para id="x_184">La sequenza dei gruppi di patch che mantengo è la seguente. L’ordine di questi gruppi è importante per i motivi che verranno descritti dopo aver introdotto i gruppi.</para> 19.100 + <itemizedlist> 19.101 + <listitem><para id="x_185">Il gruppo delle patch <quote>accettate</quote>. Sono le patch che il gruppo di sviluppo ha proposto al manutentore del sottosistema Infiniband e che sono state accettate, ma che non sono presenti nella fotografia su cui si basa il repository ridotto. Queste sono patch <quote>a sola lettura</quote>, presenti unicamente allo scopo di trasformare l’albero in uno stato simile a quello in cui si trova nel repository del manutentore a monte.</para> 19.102 </listitem> 19.103 <listitem><para id="x_186">Il gruppo delle patch da <quote>rielaborare</quote>. Sono le patch che ho proposto ma per le quali il manutentore a monte ha richiesto alcune modifiche prima di poterle accettare.</para> 19.104 </listitem> 19.105 - <listitem><para id="x_187">Il gruppo delle patch <quote>in sospeso</quote>. Sono le patch che non ho ancora proposto al manutentore a monte, ma su cui dobbiamo finire di lavorare. Queste patch saranno <quote>a sola lettura</quote> per un po'. Se il manutentore a monte le accetta al momento di proporle, le sposterò alla fine del gruppo <quote>accettate</quote>. Se ne richiede la modifica, le sposterò all'inizio del gruppo da <quote>rielaborare</quote>.</para> 19.106 + <listitem><para id="x_187">Il gruppo delle patch <quote>in sospeso</quote>. Sono le patch che non ho ancora proposto al manutentore a monte, ma su cui dobbiamo finire di lavorare. Queste patch saranno <quote>a sola lettura</quote> per un po’. Se il manutentore a monte le accetta al momento di proporle, le sposterò alla fine del gruppo <quote>accettate</quote>. Se ne richiede la modifica, le sposterò all’inizio del gruppo da <quote>rielaborare</quote>.</para> 19.107 </listitem> 19.108 <listitem><para id="x_188">Il gruppo delle patch <quote>in corso</quote>. Sono le patch che vengono attivamente sviluppate e che non dovrebbero essere ancora presentate a nessuno.</para> 19.109 </listitem> 19.110 - <listitem><para id="x_189">Il gruppo delle patch di <quote>backport</quote>. Sono le patch che riadattano l'albero dei sorgenti a una vecchia versione dell'albero del kernel.</para> 19.111 - </listitem> 19.112 - <listitem><para id="x_18a">Il gruppo delle patch da <quote>non rilasciare</quote>. Sono le patch che per qualche ragione non dovrebbero mai essere presentate a monte. Per esempio, una patch di questo tipo potrebbe modificare le stringhe di identificazione incluse nei driver per rendere più facile distinguere, nel testo del campo, una versione del driver presa dall'albero da una versione consegnata a un rivenditore di distribuzioni.</para> 19.113 - </listitem> 19.114 - </itemizedlist> 19.115 - 19.116 - <para id="x_18b">Tornando alle ragioni per cui i gruppi di patch sono ordinati in questo modo, ci piacerebbe che le patch più in basso nella pila siano il più possibile stabili, in modo da non aver bisogno di rielaborare le patch più in alto a causa di modifiche al loro contesto. Mettere le patch che non verranno mai cambiate all'inizio del file <filename role="special">series</filename> serve proprio a questo scopo.</para> 19.117 - 19.118 - <para id="x_18c">Ci piacerebbe anche applicare le patch che sappiamo di aver bisogno di modificare su un albero di sorgenti che somiglia il più possibile all'albero a monte. Questo è il motivo per cui teniamo le patch accettate in giro per un po'.</para> 19.119 + <listitem><para id="x_189">Il gruppo delle patch di <quote>backport</quote>. Sono le patch che riadattano l’albero dei sorgenti a una vecchia versione dell’albero del kernel.</para> 19.120 + </listitem> 19.121 + <listitem><para id="x_18a">Il gruppo delle patch da <quote>non rilasciare</quote>. Sono le patch che per qualche ragione non dovrebbero mai essere presentate a monte. Per esempio, una patch di questo tipo potrebbe modificare le stringhe di identificazione incluse nei driver per rendere più facile distinguere, nel testo del campo, una versione del driver presa dall’albero da una versione consegnata a un rivenditore di distribuzioni.</para> 19.122 + </listitem> 19.123 + </itemizedlist> 19.124 + 19.125 + <para id="x_18b">Tornando alle ragioni per cui i gruppi di patch sono ordinati in questo modo, ci piacerebbe che le patch più in basso nella pila siano il più possibile stabili, in modo da non aver bisogno di rielaborare le patch più in alto a causa di modifiche al loro contesto. Mettere le patch che non verranno mai cambiate all’inizio del file <filename role="special">series</filename> serve proprio a questo scopo.</para> 19.126 + 19.127 + <para id="x_18c">Ci piacerebbe anche applicare le patch che sappiamo di aver bisogno di modificare su un albero di sorgenti che somiglia il più possibile all’albero a monte. Questo è il motivo per cui teniamo le patch accettate in giro per un po’.</para> 19.128 19.129 <para id="x_18d">Le patch di <quote>backport</quote> e da <quote>non rilasciare</quote> si trovano alla fine del file <filename role="special">series</filename>. Le patch di <quote>backport</quote> devono essere applicate su tutte le altre patch, e anche le patch da <quote>non rilasciare</quote> dovrebbero essere messe in un posto sicuro.</para> 19.130 19.131 @@ -174,7 +174,7 @@ 19.132 <itemizedlist> 19.133 <listitem><para id="x_18f">Le patch <quote>accettate</quote> sono sorvegliate da <literal>accettate</literal>. Questa guardia è abilitata per la maggior parte del tempo. Quando sto applicando le patch su un albero dove sono già presenti, posso disabilitare questa guardia così le patch che la seguono verranno applicate in maniera pulita.</para> 19.134 </listitem> 19.135 - <listitem><para id="x_190">Le patch che sono <quote>terminate</quote>, ma non sono ancora state proposte, non hanno guardie. Se sto applicando la pila delle patch a una copia dell'albero a monte, non ho bisogno di abilitare alcuna guardia per ottenere un albero di sorgenti ragionevolmente sicuro.</para> 19.136 + <listitem><para id="x_190">Le patch che sono <quote>terminate</quote>, ma non sono ancora state proposte, non hanno guardie. Se sto applicando la pila delle patch a una copia dell’albero a monte, non ho bisogno di abilitare alcuna guardia per ottenere un albero di sorgenti ragionevolmente sicuro.</para> 19.137 </listitem> 19.138 <listitem><para id="x_191">Le patch che hanno bisogno di essere rielaborate prima di venire nuovamente presentate sono sorvegliate da <literal>rielaborare</literal>.</para> 19.139 </listitem> 19.140 @@ -186,13 +186,13 @@ 19.141 <para id="x_194">Questa varietà di guardie mi concede una flessibilità considerevole nel determinare quale tipo di albero dei sorgenti creare. Nella maggior parte delle situazioni, la selezione delle guardie appropriate viene automatizzata durante il processo di assemblaggio, ma posso regolare manualmente le guardie da usare nelle circostanze meno comuni.</para> 19.142 19.143 <sect2> 19.144 - <title>L'arte di scrivere patch di backport</title> 19.145 + <title>L’arte di scrivere patch di backport</title> 19.146 19.147 <para id="x_195">Usando MQ, scrivere una patch di backport è un processo semplice. Tutto quello che una patch di questo tipo deve fare è modificare una parte di codice che usa una funzione del kernel non presente in una vecchia versione del kernel, in modo che il driver continui a funzionare correttamente con la vecchia versione.</para> 19.148 19.149 - <para id="x_196">Un obiettivo utile da raggiungere nella scrittura di una buona patch di backport è far sembrare che il codice sia stato scritto per la vecchia versione del kernel che state considerando. Meno intrusiva è la patch, più facile sarà da capire e mantenere. Se state scrivendo una collezione di patch di backport per evitare l'effetto <quote>caos</quote> causato da molte istruzioni <literal>#ifdef</literal> (contenenti blocchi di codice che vengono usati solo in maniera condizionata) nel vostro codice, evitate di introdurre <literal>#ifdef</literal> dipendenti dalle versioni del kernel nelle patch. Piuttosto, scrivete diverse patch, ognuna delle quali provoca cambiamenti incondizionati, e controllate la loro applicazione usando le guardie.</para> 19.150 - 19.151 - <para id="x_197">Ci sono due ragioni per separare le patch di backport in un gruppo distinto dalle patch <quote>normali</quote> i cui effetti vengono modificati da quelle. Il primo è che mescolarle insieme rende più difficile usare uno strumento come l'estensione <literal role="hg-ext">patchbomb</literal> per automatizzare il processo di spedizione delle patch a un manutentore a monte. Il secondo è che le patch di backport potrebbero perturbare il contesto in cui una successiva patch normale viene applicata, rendendo impossibile applicare la patch normale in maniera pulita <emphasis>senza</emphasis> che la patch di backport precedente sia già stata applicata.</para> 19.152 + <para id="x_196">Un obiettivo utile da raggiungere nella scrittura di una buona patch di backport è far sembrare che il codice sia stato scritto per la vecchia versione del kernel che state considerando. Meno intrusiva è la patch, più facile sarà da capire e mantenere. Se state scrivendo una collezione di patch di backport per evitare l’effetto <quote>caos</quote> causato da molte istruzioni <literal>#ifdef</literal> (contenenti blocchi di codice che vengono usati solo in maniera condizionata) nel vostro codice, evitate di introdurre <literal>#ifdef</literal> dipendenti dalle versioni del kernel nelle patch. Piuttosto, scrivete diverse patch, ognuna delle quali provoca cambiamenti incondizionati, e controllate la loro applicazione usando le guardie.</para> 19.153 + 19.154 + <para id="x_197">Ci sono due ragioni per separare le patch di backport in un gruppo distinto dalle patch <quote>normali</quote> i cui effetti vengono modificati da quelle. Il primo è che mescolarle insieme rende più difficile usare uno strumento come l’estensione <literal role="hg-ext">patchbomb</literal> per automatizzare il processo di spedizione delle patch a un manutentore a monte. Il secondo è che le patch di backport potrebbero perturbare il contesto in cui una successiva patch normale viene applicata, rendendo impossibile applicare la patch normale in maniera pulita <emphasis>senza</emphasis> che la patch di backport precedente sia già stata applicata.</para> 19.155 19.156 </sect2> 19.157 </sect1> 19.158 @@ -212,26 +212,26 @@ 19.159 19.160 <para id="x_19a">Se sviluppate un insieme di patch per un lungo periodo, è una buona idea mantenerle in un repository, come discusso nella <xref linkend="sec:mq:repo"/>. Se fate in questo modo, scoprirete velocemente che è impraticabile usare il comando <command role="hg-cmd">hg diff</command> per esaminare la cronologia dei cambiamenti di una patch. In parte, questo succede perché state osservando la derivata seconda del codice reale (un diff di un diff), ma anche perché MQ aggiunge rumore al processo modificando le marcature temporali e i nomi di directory quando aggiorna una patch.</para> 19.161 19.162 - <para id="x_19b">Tuttavia, potete usare l'estensione <literal role="hg-ext">extdiff</literal> inclusa in Mercurial per rendere leggibile il diff di due versioni di una patch. Per fare questo, avrete bisogno di un pacchetto di terze parti chiamato <literal role="package">patchutils</literal> <citation><xref linkend="bib:patchutils"/></citation>. Il pacchetto fornisce un comando chiamato <command>interdiff</command> che mostra le differenze tra due diff come un diff. Usato su due versioni dello stesso diff, genera un diff che rappresenta le differenze tra la prima e la seconda versione.</para> 19.163 - 19.164 - <para id="x_19c">Potete abilitare l'estensione <literal role="hg-ext">extdiff</literal> nel solito modo, aggiungendo una riga alla sezione <literal role="rc-extensions">extensions</literal> del vostro file <filename role="special">~/.hgrc</filename>.</para> 19.165 + <para id="x_19b">Tuttavia, potete usare l’estensione <literal role="hg-ext">extdiff</literal> inclusa in Mercurial per rendere leggibile il diff di due versioni di una patch. Per fare questo, avrete bisogno di un pacchetto di terze parti chiamato <literal role="package">patchutils</literal> <citation><xref linkend="bib:patchutils"/></citation>. Il pacchetto fornisce un comando chiamato <command>interdiff</command> che mostra le differenze tra due diff come un diff. Usato su due versioni dello stesso diff, genera un diff che rappresenta le differenze tra la prima e la seconda versione.</para> 19.166 + 19.167 + <para id="x_19c">Potete abilitare l’estensione <literal role="hg-ext">extdiff</literal> nel solito modo, aggiungendo una riga alla sezione <literal role="rc-extensions">extensions</literal> del vostro file <filename role="special">~/.hgrc</filename>.</para> 19.168 <programlisting>[extensions] 19.169 extdiff =</programlisting> 19.170 - <para id="x_19d">Il comando <command>interdiff</command> si aspetta che gli vengano passati i nomi di due file, ma l'estensione <literal role="hg-ext">extdiff</literal> passa una coppia di directory al programma che invoca, ognuna delle quali può contenere un numero arbitrario di file. Quindi abbiamo bisogno di un piccolo programma che invochi <command>interdiff</command> su ogni coppia di file in quelle due directory. Questo programma è disponibile sotto il nome di <filename role="special">hg-interdiff</filename> nella directory <filename class="directory">contrib</filename> del repository di codice sorgente che accompagna questo libro.<footnote><para id="x_ffa">[NdT] Potete scaricare il programma <filename role="special">hg-interdiff</filename> dal <ulink role="hg-script" url="http://bitbucket.org/bos/hgbook/raw/tip/contrib/hg-interdiff">repository Mercurial del libro</ulink> ospitato su Bitbucket.</para></footnote></para> 19.171 - 19.172 - <para id="x_19e">Dopo aver incluso il programma <filename role="special">hg-interdiff</filename> nel percorso di ricerca della vostra shell, potete eseguirlo come segue, dall'interno di una directory di patch gestita da MQ:</para> 19.173 + <para id="x_19d">Il comando <command>interdiff</command> si aspetta che gli vengano passati i nomi di due file, ma l’estensione <literal role="hg-ext">extdiff</literal> passa una coppia di directory al programma che invoca, ognuna delle quali può contenere un numero arbitrario di file. Quindi abbiamo bisogno di un piccolo programma che invochi <command>interdiff</command> su ogni coppia di file in quelle due directory. Questo programma è disponibile sotto il nome di <filename role="special">hg-interdiff</filename> nella directory <filename class="directory">contrib</filename> del repository di codice sorgente che accompagna questo libro.<footnote><para id="x_ffa">[NdT] Potete scaricare il programma <filename role="special">hg-interdiff</filename> dal <ulink role="hg-script" url="http://bitbucket.org/bos/hgbook/raw/tip/contrib/hg-interdiff">repository Mercurial del libro</ulink> ospitato su Bitbucket.</para></footnote></para> 19.174 + 19.175 + <para id="x_19e">Dopo aver incluso il programma <filename role="special">hg-interdiff</filename> nel percorso di ricerca della vostra shell, potete eseguirlo come segue, dall’interno di una directory di patch gestita da MQ:</para> 19.176 <programlisting>hg extdiff -p hg-interdiff -r A:B mio-cambiamento.patch</programlisting> 19.177 <para id="x_19f">Dato che vorrete usare questo comando prolisso molto spesso, potete fare in modo che <literal role="hg-ext">hgext</literal> lo renda disponibile come un normale comando Mercurial, modificando ancora una volta il vostro file <filename role="special">~/.hgrc</filename>.</para> 19.178 <programlisting>[extdiff] 19.179 cmd.interdiff = hg-interdiff</programlisting> 19.180 - <para id="x_1a0">Questa riga ordina a <literal role="hg-ext">hgext</literal> di rendere disponibile il comando <literal>interdiff</literal>, in modo che possiate ridurre l'invocazione precedente di <command role="hg-ext-extdiff">extdiff</command> a qualcosa di un po' più maneggevole.</para> 19.181 + <para id="x_1a0">Questa riga ordina a <literal role="hg-ext">hgext</literal> di rendere disponibile il comando <literal>interdiff</literal>, in modo che possiate ridurre l’invocazione precedente di <command role="hg-ext-extdiff">extdiff</command> a qualcosa di un po’ più maneggevole.</para> 19.182 <programlisting>hg interdiff -r A:B mio-cambiamento.patch</programlisting> 19.183 19.184 <note> 19.185 <para id="x_1a1">Il comando <command>interdiff</command> funziona bene solo se i file sottostanti dai quali vengono generate le versioni di una patch rimangono gli stessi. Se create una patch, modificate i file sottostanti e poi rigenerate la patch, <command>interdiff</command> potrebbe non produrre alcun risultato utile.</para> 19.186 </note> 19.187 19.188 - <para id="x_1a2">L'utilità dell'estensione <literal role="hg-ext">extdiff</literal> va oltre il semplice miglioramento della presentazione delle patch gestite da MQ. Per avere ulteriori informazioni, leggete la <xref linkend="sec:hgext:extdiff"/>.</para> 19.189 + <para id="x_1a2">L’utilità dell’estensione <literal role="hg-ext">extdiff</literal> va oltre il semplice miglioramento della presentazione delle patch gestite da MQ. Per avere ulteriori informazioni, leggete la <xref linkend="sec:hgext:extdiff"/>.</para> 19.190 19.191 </sect2> 19.192 </sect1>
20.1 --- a/it/ch14-hgext.xml Sat Aug 22 21:01:56 2009 +0200 20.2 +++ b/it/ch14-hgext.xml Sat Aug 22 21:55:05 2009 +0200 20.3 @@ -2,61 +2,61 @@ 20.4 <?dbhtml filename="aggiungere-funzionalità-con-le-estensioni.html"?> 20.5 <title>Aggiungere funzionalità con le estensioni</title> 20.6 20.7 - <para id="x_4fe">Se da una parte il nucleo di Mercurial è piuttosto completo dal punto di vista delle funzionalità, dall'altra è deliberatamente privo di caratteristiche ornamentali. Questo approccio orientato a preservare la semplicità mantiene il software facile da maneggiare sia per chi ne cura la manutenzione sia per chi lo usa.</para> 20.8 + <para id="x_4fe">Se da una parte il nucleo di Mercurial è piuttosto completo dal punto di vista delle funzionalità, dall’altra è deliberatamente privo di caratteristiche ornamentali. Questo approccio orientato a preservare la semplicità mantiene il software facile da maneggiare sia per chi ne cura la manutenzione sia per chi lo usa.</para> 20.9 20.10 <para id="x_4ff">Tuttavia, Mercurial non vi vincola a usare un insieme di comandi immutabile: potete aggiungere nuove funzioni a Mercurial sotto forma di <emphasis>estensioni</emphasis> (talvolta note come <emphasis>plugin</emphasis>). Abbiamo già discusso alcune di queste estensioni nei capitoli precedenti.</para> 20.11 <itemizedlist> 20.12 - <listitem><para id="x_500">La <xref linkend="sec:tour-merge:fetch"/> parla dell'estensione <literal role="hg-ext">fetch</literal>, che combina l'estrazione di nuovi cambiamenti e la loro unione con i cambiamenti locali in un singolo comando, <command role="hg-ext-fetch">fetch</command>.</para> 20.13 - </listitem> 20.14 - <listitem><para id="x_501">Nel <xref linkend="chap:hook"/>, abbiamo parlato di diverse estensioni le cui funzioni sono utilizzabili sotto forma di hook: <literal role="hg-ext">acl</literal> aggiunge le liste di controllo d'accesso, <literal role="hg-ext">bugzilla</literal> aggiunge l'integrazione con il sistema Bugzilla per la gestione dei bug e <literal role="hg-ext">notify</literal> invia email di notifica in reazione all'inserimento di nuovi cambiamenti.</para> 20.15 - </listitem> 20.16 - <listitem><para id="x_502">L'estensione Mercurial Queues per la gestione delle patch è talmente importante da meritare due capitoli e un'appendice interamente dedicati: il <xref linkend="chap:mq"/> copre le nozioni di base, il <xref linkend="chap:mq-collab"/> ne discute gli argomenti avanzati e l'<xref linkend="chap:mqref"/> tratta ogni comando nei dettagli.</para> 20.17 + <listitem><para id="x_500">La <xref linkend="sec:tour-merge:fetch"/> parla dell’estensione <literal role="hg-ext">fetch</literal>, che combina l’estrazione di nuovi cambiamenti e la loro unione con i cambiamenti locali in un singolo comando, <command role="hg-ext-fetch">fetch</command>.</para> 20.18 + </listitem> 20.19 + <listitem><para id="x_501">Nel <xref linkend="chap:hook"/>, abbiamo parlato di diverse estensioni le cui funzioni sono utilizzabili sotto forma di hook: <literal role="hg-ext">acl</literal> aggiunge le liste di controllo d’accesso, <literal role="hg-ext">bugzilla</literal> aggiunge l’integrazione con il sistema Bugzilla per la gestione dei bug e <literal role="hg-ext">notify</literal> invia email di notifica in reazione all’inserimento di nuovi cambiamenti.</para> 20.20 + </listitem> 20.21 + <listitem><para id="x_502">L’estensione Mercurial Queues per la gestione delle patch è talmente importante da meritare due capitoli e un’appendice interamente dedicati: il <xref linkend="chap:mq"/> copre le nozioni di base, il <xref linkend="chap:mq-collab"/> ne discute gli argomenti avanzati e l’<xref linkend="chap:mqref"/> tratta ogni comando nei dettagli.</para> 20.22 </listitem> 20.23 </itemizedlist> 20.24 20.25 <para id="x_503">In questo capitolo, parleremo di alcune delle altre estensioni disponibili per Mercurial e tratteremo brevemente alcuni dei meccanismi che avrete bisogno di conoscere se volete scrivere le vostre estensioni.</para> 20.26 <!-- 20.27 <itemizedlist> 20.28 - <listitem><para id="x_504">Nella <xref linkend="sec:hgext:inotify"/>, discuteremo la possibilità di <emphasis>enormi</emphasis> miglioramenti delle prestazioni tramite l'uso dell'estensione <literal role="hg-ext">inotify</literal>.</para> 20.29 + <listitem><para id="x_504">Nella <xref linkend="sec:hgext:inotify"/>, discuteremo la possibilità di <emphasis>enormi</emphasis> miglioramenti delle prestazioni tramite l’uso dell’estensione <literal role="hg-ext">inotify</literal>.</para> 20.30 </listitem> 20.31 </itemizedlist> 20.32 --> 20.33 20.34 <sect1 id="sec:hgext:inotify"> 20.35 - <title>Migliorare le prestazioni con l'estensione <literal role="hg-ext">inotify</literal></title> 20.36 + <title>Migliorare le prestazioni con l’estensione <literal role="hg-ext">inotify</literal></title> 20.37 20.38 <para id="x_505">Siete interessati a ottenere esecuzioni fino a cento volte più veloci per alcune delle più comuni operazioni compiute da Mercurial? Continuate a leggere!</para> 20.39 20.40 <para id="x_506">Le prestazioni di Mercurial sono tipicamente eccellenti. Per esempio, quando invocate il comando <command role="hg-cmd">hg status</command>, Mercurial deve esaminare quasi ogni file e directory nel vostro repository in modo da mostrare lo stato dei file. Molti altri comandi Mercurial devono fare lo stesso lavoro dietro le quinte: per esempio, il comando <command role="hg-cmd">hg diff</command> usa il meccanismo dello stato per evitare costose operazioni di confronto su file che ovviamente non sono stati modificati.</para> 20.41 20.42 - <para id="x_507">Dato che ottenere lo stato di un file è un'operazione cruciale per raggiungere buone prestazioni, gli autori di Mercurial hanno ottimizzato il più possibile questo codice. Tuttavia, quando invocate <command role="hg-cmd">hg status</command>, Mercurial dovrà necessariamente effettuare almeno una costosa chiamata di sistema per ogni file registrato in modo da determinare se è stato modificato dall'ultima volta che Mercurial ha controllato. Per repository di dimensioni sufficientemente grandi, questa operazione può durare molto tempo.</para> 20.43 + <para id="x_507">Dato che ottenere lo stato di un file è un’operazione cruciale per raggiungere buone prestazioni, gli autori di Mercurial hanno ottimizzato il più possibile questo codice. Tuttavia, quando invocate <command role="hg-cmd">hg status</command>, Mercurial dovrà necessariamente effettuare almeno una costosa chiamata di sistema per ogni file registrato in modo da determinare se è stato modificato dall’ultima volta che Mercurial ha controllato. Per repository di dimensioni sufficientemente grandi, questa operazione può durare molto tempo.</para> 20.44 20.45 <para id="x_508">Per esprimere numericamente la vastità di questo effetto, ho creato un repository contenente 150.000 file registrati e ho cronometrato <command role="hg-cmd">hg status</command> per scoprire che impiega dieci secondi a terminare, anche quando <emphasis>nessuno</emphasis> di quei file è stato modificato.</para> 20.46 20.47 <para id="x_509">Molti sistemi operativi moderni contengono utilità di notifica per i file. Se un programma si registra al servizio appropriato, il sistema operativo lo avvertirà ogni volta che un file di interesse viene creato, modificato, o cancellato. Sui sistemi Linux, il componente del kernel che si occupa di questa funzione si chiama <literal>inotify</literal>.</para> 20.48 20.49 - <para id="x_50a">L'estensione <literal role="hg-ext">inotify</literal> di Mercurial interagisce con il componente <literal>inotify</literal> per ottimizzare l'esecuzione di <command role="hg-cmd">hg status</command>. Questa estensione ha due componenti. Un demone viene eseguito in background e riceve le notifiche dal sottosistema <literal>inotify</literal>, accettando connessioni anche dai normali comandi Mercurial. L'estensione modifica il comportamento di Mercurial in modo che, invece di esaminare il file system, interroghi il demone. Dato che il demone possiede informazioni esatte sullo stato del repository, può rispondere istantaneamente con un risultato, senza dover esaminare tutti i file e le directory nel repository.</para> 20.50 - 20.51 - <para id="x_50b">Ricordate i dieci secondi che ho misurato come il tempo impiegato dal solo Mercurial per eseguire <command role="hg-cmd">hg status</command> su un repository di 150.000 file? Con l'estensione <literal role="hg-ext">inotify</literal> abilitata, il tempo è sceso a 0.1 secondi, più veloce di un fattore <emphasis>cento</emphasis>.</para> 20.52 + <para id="x_50a">L’estensione <literal role="hg-ext">inotify</literal> di Mercurial interagisce con il componente <literal>inotify</literal> per ottimizzare l’esecuzione di <command role="hg-cmd">hg status</command>. Questa estensione ha due componenti. Un demone viene eseguito in background e riceve le notifiche dal sottosistema <literal>inotify</literal>, accettando connessioni anche dai normali comandi Mercurial. L’estensione modifica il comportamento di Mercurial in modo che, invece di esaminare il file system, interroghi il demone. Dato che il demone possiede informazioni esatte sullo stato del repository, può rispondere istantaneamente con un risultato, senza dover esaminare tutti i file e le directory nel repository.</para> 20.53 + 20.54 + <para id="x_50b">Ricordate i dieci secondi che ho misurato come il tempo impiegato dal solo Mercurial per eseguire <command role="hg-cmd">hg status</command> su un repository di 150.000 file? Con l’estensione <literal role="hg-ext">inotify</literal> abilitata, il tempo è sceso a 0.1 secondi, più veloce di un fattore <emphasis>cento</emphasis>.</para> 20.55 20.56 <para id="x_50c">Prima di continuare, vi prego di fare attenzione ad alcuni avvertimenti.</para> 20.57 <itemizedlist> 20.58 - <listitem><para id="x_50d">L'estensione <literal role="hg-ext">inotify</literal> è specifica per Linux. Dato che si interfaccia direttamente con il sottosistema <literal>inotify</literal> del kernel di Linux, non funziona su altri sistemi operativi.</para> 20.59 - </listitem> 20.60 - <listitem><para id="x_50e">L'estensione dovrebbe funzionare su qualsiasi distribuzione Linux rilasciata dopo i primi mesi del 2005. È probabile che le distribuzioni più vecchie includano un kernel a cui manca <literal>inotify</literal>, o una versione di <literal>glibc</literal> senza il necessario supporto di interfaccia.</para> 20.61 - </listitem> 20.62 - <listitem><para id="x_50f">Non tutti i file system sono adatti per essere usati con l'estensione <literal role="hg-ext">inotify</literal>. I file system di rete come NFS sono fuori gioco, per esempio, in particolare se state eseguendo Mercurial su diversi sistemi che montano lo stesso file system di rete. Il sistema <literal>inotify</literal> del kernel non ha alcun modo di sapere quali cambiamenti sono avvenuti su un altro sistema. La maggior parte dei file system locali (e.g. ext3, XFS, ReiserFS) dovrebbe andare bene.</para> 20.63 + <listitem><para id="x_50d">L’estensione <literal role="hg-ext">inotify</literal> è specifica per Linux. Dato che si interfaccia direttamente con il sottosistema <literal>inotify</literal> del kernel di Linux, non funziona su altri sistemi operativi.</para> 20.64 + </listitem> 20.65 + <listitem><para id="x_50e">L’estensione dovrebbe funzionare su qualsiasi distribuzione Linux rilasciata dopo i primi mesi del 2005. È probabile che le distribuzioni più vecchie includano un kernel a cui manca <literal>inotify</literal>, o una versione di <literal>glibc</literal> senza il necessario supporto di interfaccia.</para> 20.66 + </listitem> 20.67 + <listitem><para id="x_50f">Non tutti i file system sono adatti per essere usati con l’estensione <literal role="hg-ext">inotify</literal>. I file system di rete come NFS sono fuori gioco, per esempio, in particolare se state eseguendo Mercurial su diversi sistemi che montano lo stesso file system di rete. Il sistema <literal>inotify</literal> del kernel non ha alcun modo di sapere quali cambiamenti sono avvenuti su un altro sistema. La maggior parte dei file system locali (e.g. ext3, XFS, ReiserFS) dovrebbe andare bene.</para> 20.68 </listitem></itemizedlist> 20.69 20.70 - <para id="x_510">A maggio 2007, l'estensione <literal role="hg-ext">inotify</literal> non viene ancora distribuita con Mercurial, quindi è un po' più complicata da installare rispetto ad altre estensioni.<footnote><para id="x_ffd">A partire da Mercurial 1.0, l'estensione <literal role="hg-ext">inotify</literal> è stata inclusa nella distribuzione. L'estensione deve comunque ancora considerarsi <ulink url="http://mercurial.selenic.com/wiki/InotifyExtension">assolutamente in fase sperimentale</ulink>.</para></footnote> Ma il miglioramento delle prestazioni ne vale la pena!</para> 20.71 - 20.72 - <para id="x_511">Attualmente, l'estensione è divisa in due parti: un insieme di patch al codice sorgente di Mercurial e una libreria di interfaccia Python al sottosistema <literal>inotify</literal>.</para> 20.73 + <para id="x_510">A maggio 2007, l’estensione <literal role="hg-ext">inotify</literal> non viene ancora distribuita con Mercurial, quindi è un po’ più complicata da installare rispetto ad altre estensioni.<footnote><para id="x_ffd">A partire da Mercurial 1.0, l’estensione <literal role="hg-ext">inotify</literal> è stata inclusa nella distribuzione. L’estensione deve comunque ancora considerarsi <ulink url="http://mercurial.selenic.com/wiki/InotifyExtension">assolutamente in fase sperimentale</ulink>.</para></footnote> Ma il miglioramento delle prestazioni ne vale la pena!</para> 20.74 + 20.75 + <para id="x_511">Attualmente, l’estensione è divisa in due parti: un insieme di patch al codice sorgente di Mercurial e una libreria di interfaccia Python al sottosistema <literal>inotify</literal>.</para> 20.76 <note> 20.77 <para id="x_512">Esistono <emphasis>due</emphasis> librerie di interfaccia Python per <literal>inotify</literal>. Una è chiamata <literal>pyinotify</literal> ed è inclusa in alcune distribuzioni Linux sotto il nome <literal>python-inotify</literal>. Questa <emphasis>non</emphasis> è quella di cui avete bisogno, dato che è troppo inefficiente e piena di problemi per essere pratica.</para> 20.78 </note> 20.79 <para id="x_513">Per cominciare, è meglio avere già installata una copia funzionante di Mercurial.</para> 20.80 <note> 20.81 - <para id="x_514">Se seguite le istruzioni qui sotto, finirete per <emphasis>sostituire</emphasis> e sovrascrivere qualsiasi installazione esistente di Mercurial possiate già avere, usando l'ultima versione <quote>sperimentale</quote> di Mercurial. Non dite che non siete stati avvertiti!</para> 20.82 + <para id="x_514">Se seguite le istruzioni qui sotto, finirete per <emphasis>sostituire</emphasis> e sovrascrivere qualsiasi installazione esistente di Mercurial possiate già avere, usando l’ultima versione <quote>sperimentale</quote> di Mercurial. Non dite che non siete stati avvertiti!</para> 20.83 </note> 20.84 <orderedlist> 20.85 <listitem><para id="x_515">Clonate il repository della libreria di interfaccia Python per <literal>inotify</literal>. Assemblate il software e installatelo.</para> 20.86 @@ -70,9 +70,9 @@ 20.87 hg clone crew inotify 20.88 hg clone http://hg.kublai.com/mercurial/patches/inotify inotify/.hg/patches</programlisting> 20.89 </listitem> 20.90 - <listitem><para id="x_517">Assicuratevi di aver abilitato <literal role="hg-ext">mq</literal>, l'estensione Mercurial Queues. Se non avete mai usato MQ, leggete la <xref linkend="sec:mq:start"/> per una rapida introduzione.</para> 20.91 - </listitem> 20.92 - <listitem><para id="x_518">Posizionatevi nel repository <filename class="directory">inotify</filename> e applicate tutte le patch per l'estensione <literal role="hg-ext">inotify</literal> usando l'opzione <option role="hg-ext-mq-cmd-qpush-opt">-a</option> del comando <command role="hg-ext-mq">qpush</command>.</para> 20.93 + <listitem><para id="x_517">Assicuratevi di aver abilitato <literal role="hg-ext">mq</literal>, l’estensione Mercurial Queues. Se non avete mai usato MQ, leggete la <xref linkend="sec:mq:start"/> per una rapida introduzione.</para> 20.94 + </listitem> 20.95 + <listitem><para id="x_518">Posizionatevi nel repository <filename class="directory">inotify</filename> e applicate tutte le patch per l’estensione <literal role="hg-ext">inotify</literal> usando l’opzione <option role="hg-ext-mq-cmd-qpush-opt">-a</option> del comando <command role="hg-ext-mq">qpush</command>.</para> 20.96 <programlisting>cd inotify 20.97 hg qpush -a</programlisting> 20.98 </listitem> 20.99 @@ -83,30 +83,30 @@ 20.100 sudo python setup.py install --skip-build</programlisting> 20.101 </listitem> 20.102 </orderedlist> 20.103 - <para id="x_51b">Una volta che avete assemblato una versione adeguatamente modificata di Mercurial, tutto ciò che dovete fare per abilitare l'estensione <literal role="hg-ext">inotify</literal> è aggiungere una voce al vostro file <filename role="special">~/.hgrc</filename>.</para> 20.104 + <para id="x_51b">Una volta che avete assemblato una versione adeguatamente modificata di Mercurial, tutto ciò che dovete fare per abilitare l’estensione <literal role="hg-ext">inotify</literal> è aggiungere una voce al vostro file <filename role="special">~/.hgrc</filename>.</para> 20.105 <programlisting>[extensions] 20.106 inotify =</programlisting> 20.107 - <para id="x_51c">Quando l'estensione <literal role="hg-ext">inotify</literal> è abilitata, Mercurial avvierà il demone in maniera automatica e trasparente la prima volta che invocherete un comando che ha bisogno di conoscere lo stato dei file nel repository. Mercurial esegue un demone di stato per ogni repository.</para> 20.108 - 20.109 - <para id="x_51d">Il demone di stato viene avviato silenziosamente ed eseguito in background. Se osservate la lista dei processi in esecuzione e invocate alcuni comandi in repository differenti dopo aver abilitato l'estensione <literal role="hg-ext">inotify</literal>, vedrete alcuni processi <literal>hg</literal> in attesa di aggiornamenti dal kernel e di richieste da Mercurial.</para> 20.110 - 20.111 - <para id="x_51e">La prima volta che invocate un comando Mercurial in un repository dopo aver abilitato l'estensione <literal role="hg-ext">inotify</literal>, il comando verrà eseguito con quasi le stesse prestazioni di un normale comando Mercurial. Questo accade perché il demone di stato deve effettuare una normale scansione di stato in modo da avere un rilevamento di base su cui applicare gli aggiornamenti successivi provenienti dal kernel. Tuttavia, <emphasis>ogni</emphasis> comando successivo che effettua qualunque tipo di controllo sullo stato dovrebbe essere visibilmente più veloce persino su repository di dimensioni abbastanza modeste. Ancora meglio, più grande è il vostro repository, più grande sarà il vantaggio che vedrete sulle prestazioni. Il demone <literal role="hg-ext">inotify</literal> rende le operazioni di stato quasi istantanee su repository di tutte le dimensioni!</para> 20.112 - 20.113 - <para id="x_51f">Se preferite, potete avviare manualmente un demone di stato usando il comando <command role="hg-ext-inotify">inserve</command>, che vi permette di controllare in maniera leggermente più accurata le modalità di esecuzione del demone. Naturalmente, questo comando sarà disponibile solo nel caso in cui l'estensione <literal role="hg-ext">inotify</literal> sia abilitata.</para> 20.114 - 20.115 - <para id="x_520">Quando state usando l'estensione <literal role="hg-ext">inotify</literal>, non dovreste notare <emphasis>nessuna differenza</emphasis> nel comportamento di Mercurial, con la sola eccezione dei comandi relativi allo stato, che vengono eseguiti molto più velocemente di quanto accadeva di solito. Dovreste espressamente aspettarvi che i comandi non stampino messaggi differenti né restituiscano risultati differenti. Se una di queste situazioni si verifica, vi prego di segnalare il bug.</para> 20.116 + <para id="x_51c">Quando l’estensione <literal role="hg-ext">inotify</literal> è abilitata, Mercurial avvierà il demone in maniera automatica e trasparente la prima volta che invocherete un comando che ha bisogno di conoscere lo stato dei file nel repository. Mercurial esegue un demone di stato per ogni repository.</para> 20.117 + 20.118 + <para id="x_51d">Il demone di stato viene avviato silenziosamente ed eseguito in background. Se osservate la lista dei processi in esecuzione e invocate alcuni comandi in repository differenti dopo aver abilitato l’estensione <literal role="hg-ext">inotify</literal>, vedrete alcuni processi <literal>hg</literal> in attesa di aggiornamenti dal kernel e di richieste da Mercurial.</para> 20.119 + 20.120 + <para id="x_51e">La prima volta che invocate un comando Mercurial in un repository dopo aver abilitato l’estensione <literal role="hg-ext">inotify</literal>, il comando verrà eseguito con quasi le stesse prestazioni di un normale comando Mercurial. Questo accade perché il demone di stato deve effettuare una normale scansione di stato in modo da avere un rilevamento di base su cui applicare gli aggiornamenti successivi provenienti dal kernel. Tuttavia, <emphasis>ogni</emphasis> comando successivo che effettua qualunque tipo di controllo sullo stato dovrebbe essere visibilmente più veloce persino su repository di dimensioni abbastanza modeste. Ancora meglio, più grande è il vostro repository, più grande sarà il vantaggio che vedrete sulle prestazioni. Il demone <literal role="hg-ext">inotify</literal> rende le operazioni di stato quasi istantanee su repository di tutte le dimensioni!</para> 20.121 + 20.122 + <para id="x_51f">Se preferite, potete avviare manualmente un demone di stato usando il comando <command role="hg-ext-inotify">inserve</command>, che vi permette di controllare in maniera leggermente più accurata le modalità di esecuzione del demone. Naturalmente, questo comando sarà disponibile solo nel caso in cui l’estensione <literal role="hg-ext">inotify</literal> sia abilitata.</para> 20.123 + 20.124 + <para id="x_520">Quando state usando l’estensione <literal role="hg-ext">inotify</literal>, non dovreste notare <emphasis>nessuna differenza</emphasis> nel comportamento di Mercurial, con la sola eccezione dei comandi relativi allo stato, che vengono eseguiti molto più velocemente di quanto accadeva di solito. Dovreste espressamente aspettarvi che i comandi non stampino messaggi differenti né restituiscano risultati differenti. Se una di queste situazioni si verifica, vi prego di segnalare il bug.</para> 20.125 20.126 </sect1> 20.127 <sect1 id="sec:hgext:extdiff"> 20.128 - <title>Supporto flessibile per i diff con l'estensione <literal role="hg-ext">extdiff</literal></title> 20.129 + <title>Supporto flessibile per i diff con l’estensione <literal role="hg-ext">extdiff</literal></title> 20.130 20.131 <para id="x_521">Il comando predefinito di Mercurial <command role="hg-cmd">hg diff</command> stampa il testo semplice di diff unificati.</para> 20.132 20.133 &interaction.extdiff.diff; 20.134 20.135 - <para id="x_522">Nel caso desideraste usare uno strumento esterno per visualizzare le modifiche, vorrete usare l'estensione <literal role="hg-ext">extdiff</literal>, che vi permetterà di impiegare, per esempio, uno strumento di diff grafico.</para> 20.136 - 20.137 - <para id="x_523">L'estensione <literal role="hg-ext">extdiff</literal> è inclusa in Mercurial, quindi è facile da installare. Per abilitare l'estensione, vi basta aggiungere una voce di una riga nella sezione <literal role="rc-extensions">extensions</literal> del vostro file <filename role="special">~/.hgrc</filename>.</para> 20.138 + <para id="x_522">Nel caso desideraste usare uno strumento esterno per visualizzare le modifiche, vorrete usare l’estensione <literal role="hg-ext">extdiff</literal>, che vi permetterà di impiegare, per esempio, uno strumento di diff grafico.</para> 20.139 + 20.140 + <para id="x_523">L’estensione <literal role="hg-ext">extdiff</literal> è inclusa in Mercurial, quindi è facile da installare. Per abilitare l’estensione, vi basta aggiungere una voce di una riga nella sezione <literal role="rc-extensions">extensions</literal> del vostro file <filename role="special">~/.hgrc</filename>.</para> 20.141 <programlisting>[extensions] 20.142 extdiff =</programlisting> 20.143 <para id="x_524">Questa estensione introduce un comando chiamato <command role="hg-ext-extdiff">extdiff</command>, il cui comportamento predefinito è quello di usare il comando <command>diff</command> del vostro sistema per generare un diff unificato allo stesso modo del comando <command 20.144 @@ -114,36 +114,36 @@ 20.145 20.146 &interaction.extdiff.extdiff; 20.147 20.148 - <para id="x_525">I risultati non saranno esattamente gli stessi ottenibili con le diverse versioni del comando predefinito <command role="hg-cmd">hg diff</command>, perché i risultati del comando <command>diff</command> variano da un sistema all'altro, persino quando gli vengono passate le stesse opzioni.</para> 20.149 + <para id="x_525">I risultati non saranno esattamente gli stessi ottenibili con le diverse versioni del comando predefinito <command role="hg-cmd">hg diff</command>, perché i risultati del comando <command>diff</command> variano da un sistema all’altro, persino quando gli vengono passate le stesse opzioni.</para> 20.150 20.151 <para id="x_526"><!--Come indica la riga <quote><literal>making snapshot</literal></quote> stampata qui sopra, -->Il comando <command role="hg-ext-extdiff">extdiff</command> funziona creando due fotografie <!--(in inglese, snapshot)-->del vostro albero sorgente. La prima fotografia è quella della revisione sorgente, la seconda è quella della revisione destinazione o della directory di lavoro. Il comando <command role="hg-ext-extdiff">extdiff</command> genera queste fotografie in una directory temporanea, passa il nome di ogni directory di fotografia a un visualizzatore di diff esterno, poi cancella la directory temporanea. Per lavorare in modo più efficiente, il comando fotografa solo le directory e i file che sono stati modificati tra le due revisioni.</para> 20.152 20.153 - <para id="x_527">Il nome delle directory di fotografia è uguale al nome base del vostro repository. Se il percorso del vostro repository è <filename class="directory">/quux/bar/foo</filename>, allora <filename class="directory">foo</filename> sarà il nome di ognuna delle directory di fotografia. Nel caso sia appropriato, ogni nome di directory di fotografia termina con il proprio identificatore di changeset. Se la fotografia è quella della revisione <literal>a631aca1083f</literal>, la directory verrà chiamata <filename class="directory">foo.a631aca1083f</filename>. Una fotografia della directory di lavoro non terminerà con un identificatore di changeset, quindi in questo esempio il suo nome sarebbe semplicemente <filename class="directory">foo</filename>. Per vedere come questo appare in pratica, osservate ancora l'esempio di <command role="hg-ext-extdiff">extdiff</command> precedente. Notate che il diff contiene i nomi delle directory di fotografia nella propria intestazione.</para> 20.154 - 20.155 - <para id="x_528">Il comando <command role="hg-ext-extdiff">extdiff</command> accetta due importanti opzioni. L'opzione <option role="hg-ext-extdiff-cmd-extdiff-opt">-p</option> vi permette di scegliere un programma diverso da <command>diff</command> con cui visualizzare le differenze. Con l'opzione <option role="hg-ext-extdiff-cmd-extdiff-opt">-o</option>, potete cambiare le opzioni che <command role="hg-ext-extdiff">extdiff</command> passa al programma (le opzioni predefinite sono <quote><literal>-Npru</literal></quote>, che hanno senso solo se state invocando <command>diff</command>). Sotto altri aspetti, il comando <command role="hg-ext-extdiff">extdiff</command> agisce in modo simile al comando predefinito <command role="hg-cmd">hg diff</command>: si usano gli stessi nomi di opzione, la stessa sintassi e gli stessi argomenti per specificare le revisioni che volete, i file che volete, e così via.</para> 20.156 - 20.157 - <para id="x_529">Per esempio, ecco come invocare il normale comando <command>diff</command> di sistema per fargli generare diff contestuali (usando l'opzione <option role="cmd-opt-diff">-c</option>) invece di diff unificati e per fargli mostrare cinque righe di contesto invece delle tre predefinite (passandogli <literal>5</literal> come argomento per l'opzione <option role="cmd-opt-diff">-C</option>).</para> 20.158 - 20.159 - &interaction.extdiff.extdiff-ctx; 20.160 + <para id="x_527">Il nome delle directory di fotografia è uguale al nome base del vostro repository. Se il percorso del vostro repository è <filename class="directory">/quux/bar/foo</filename>, allora <filename class="directory">foo</filename> sarà il nome di ognuna delle directory di fotografia. Nel caso sia appropriato, ogni nome di directory di fotografia termina con il proprio identificatore di changeset. Se la fotografia è quella della revisione <literal>a631aca1083f</literal>, la directory verrà chiamata <filename class="directory">foo.a631aca1083f</filename>. Una fotografia della directory di lavoro non terminerà con un identificatore di changeset, quindi in questo esempio il suo nome sarebbe semplicemente <filename class="directory">foo</filename>. Per vedere come questo appare in pratica, osservate ancora l’esempio di <command role="hg-ext-extdiff">extdiff</command> precedente. Notate che il diff contiene i nomi delle directory di fotografia nella propria intestazione.</para> 20.161 + 20.162 + <para id="x_528">Il comando <command role="hg-ext-extdiff">extdiff</command> accetta due importanti opzioni. L’opzione <option role="hg-ext-extdiff-cmd-extdiff-opt">-p</option> vi permette di scegliere un programma diverso da <command>diff</command> con cui visualizzare le differenze. Con l’opzione <option role="hg-ext-extdiff-cmd-extdiff-opt">-o</option>, potete cambiare le opzioni che <command role="hg-ext-extdiff">extdiff</command> passa al programma (le opzioni predefinite sono <quote><literal>-Npru</literal></quote>, che hanno senso solo se state invocando <command>diff</command>). Sotto altri aspetti, il comando <command role="hg-ext-extdiff">extdiff</command> agisce in modo simile al comando predefinito <command role="hg-cmd">hg diff</command>: si usano gli stessi nomi di opzione, la stessa sintassi e gli stessi argomenti per specificare le revisioni che volete, i file che volete, e così via.</para> 20.163 + 20.164 + <para id="x_529">Per esempio, ecco come invocare il normale comando <command>diff</command> di sistema per fargli generare diff contestuali (usando l’opzione <option role="cmd-opt-diff">-c</option>) invece di diff unificati e per fargli mostrare cinque righe di contesto invece delle tre predefinite (passandogli <literal>5</literal> come argomento per l’opzione <option role="cmd-opt-diff">-C</option>).</para> 20.165 + 20.166 + &interaction.extdiff.extdiff-ctx; 20.167 20.168 <para id="x_52a">Lanciare uno strumento di diff visuale è altrettanto facile. Ecco come invocare il visualizzatore <command>kdiff3</command>.</para> 20.169 <programlisting>hg extdiff -p kdiff3 -o</programlisting> 20.170 20.171 - <para id="x_52b">Se il comando che usate per visualizzare i diff non gestisce le directory, potete facilmente aggirare questo problema con un minimo di programmazione. Consultate la <xref linkend="mq-collab:tips:interdiff"/> per vedere un esempio di un programma simile in azione con l'estensione <literal role="hg-ext">mq</literal> e il comando <command>interdiff</command>.</para> 20.172 + <para id="x_52b">Se il comando che usate per visualizzare i diff non gestisce le directory, potete facilmente aggirare questo problema con un minimo di programmazione. Consultate la <xref linkend="mq-collab:tips:interdiff"/> per vedere un esempio di un programma simile in azione con l’estensione <literal role="hg-ext">mq</literal> e il comando <command>interdiff</command>.</para> 20.173 20.174 <sect2> 20.175 <title>Definire alias per i comandi</title> 20.176 20.177 - <para id="x_52c">Potrebbe essere scomodo ricordare le opzioni sia per il comando <command role="hg-ext-extdiff">extdiff</command> che per il visualizzatore di diff che volete usare, quindi l'estensione <literal role="hg-ext">extdiff</literal> vi permette di definire <emphasis>nuovi</emphasis> comandi che invocheranno il vostro visualizzatore di diff con le opzioni giuste.</para> 20.178 - 20.179 - <para id="x_52d">Tutto quello che dovete fare è modificare il vostro file <filename role="special">~/.hgrc</filename> aggiungendo una sezione chiamata <literal role="rc-extdiff">extdiff</literal> dove potete definire vari comandi. Ecco come aggiungere un comando <literal>kdiff3</literal>. Una volta che lo avete definito, potete digitare <quote><literal>hg kdiff3</literal></quote> e l'estensione <literal role="hg-ext">extdiff</literal> lancerà <command>kdiff3</command> per voi.</para> 20.180 + <para id="x_52c">Potrebbe essere scomodo ricordare le opzioni sia per il comando <command role="hg-ext-extdiff">extdiff</command> che per il visualizzatore di diff che volete usare, quindi l’estensione <literal role="hg-ext">extdiff</literal> vi permette di definire <emphasis>nuovi</emphasis> comandi che invocheranno il vostro visualizzatore di diff con le opzioni giuste.</para> 20.181 + 20.182 + <para id="x_52d">Tutto quello che dovete fare è modificare il vostro file <filename role="special">~/.hgrc</filename> aggiungendo una sezione chiamata <literal role="rc-extdiff">extdiff</literal> dove potete definire vari comandi. Ecco come aggiungere un comando <literal>kdiff3</literal>. Una volta che lo avete definito, potete digitare <quote><literal>hg kdiff3</literal></quote> e l’estensione <literal role="hg-ext">extdiff</literal> lancerà <command>kdiff3</command> per voi.</para> 20.183 <programlisting>[extdiff] 20.184 cmd.kdiff3 =</programlisting> 20.185 - <para id="x_52e">Se lasciate vuota la parte destra della definizione, come qui sopra, l'estensione <literal role="hg-ext">extdiff</literal> usa il nome del comando che avete definito come il nome del programma esterno da usare. Ma questi nomi non devono necessariamente essere uguali. Qui di seguito definiamo un comando chiamato <quote><literal>hg pippo</literal></quote> che invoca <command>kdiff3</command>.</para> 20.186 + <para id="x_52e">Se lasciate vuota la parte destra della definizione, come qui sopra, l’estensione <literal role="hg-ext">extdiff</literal> usa il nome del comando che avete definito come il nome del programma esterno da usare. Ma questi nomi non devono necessariamente essere uguali. Qui di seguito definiamo un comando chiamato <quote><literal>hg pippo</literal></quote> che invoca <command>kdiff3</command>.</para> 20.187 <programlisting>[extdiff] 20.188 cmd.pippo = kdiff3</programlisting> 20.189 20.190 - <para id="x_52f">Potete anche specificare le opzioni predefinite con cui volete invocare il vostro programma di visualizzazione di diff. Il prefisso da usare è <quote><literal>opts.</literal></quote>, seguito dal nome del comando a cui applicare le opzioni. Questo esempio definisce un comando <quote><literal>hg vimdiff</literal></quote> che esegue l'estensione <literal>DirDiff</literal> dell'editor <command>vim</command>.</para> 20.191 + <para id="x_52f">Potete anche specificare le opzioni predefinite con cui volete invocare il vostro programma di visualizzazione di diff. Il prefisso da usare è <quote><literal>opts.</literal></quote>, seguito dal nome del comando a cui applicare le opzioni. Questo esempio definisce un comando <quote><literal>hg vimdiff</literal></quote> che esegue l’estensione <literal>DirDiff</literal> dell’editor <command>vim</command>.</para> 20.192 <programlisting>[extdiff] 20.193 cmd.vimdiff = vim 20.194 opts.vimdiff = -f '+next' '+execute "DirDiff" argv(0) argv(1)'</programlisting> 20.195 @@ -160,22 +160,22 @@ 20.196 </sect1> 20.197 --> 20.198 <sect1 id="sec:hgext:patchbomb"> 20.199 - <title>Inviare cambiamenti via email con l'estensione <literal role="hg-ext">patchbomb</literal></title> 20.200 + <title>Inviare cambiamenti via email con l’estensione <literal role="hg-ext">patchbomb</literal></title> 20.201 20.202 <para id="x_531">Molti progetti seguono una pratica di <quote>revisione dei cambiamenti</quote> in cui gli sviluppatori inviano le proprie modifiche a una mailing list in modo che altri possano leggerle e commentarle prima che la loro versione finale venga inserita in un repository condiviso. Alcuni progetti assegnano a qualcuno il ruolo del custode che applica le modifiche di altre persone a un repository a cui quelle persone non hanno accesso.</para> 20.203 20.204 - <para id="x_532">Grazie alla sua estensione <literal role="hg-ext">patchbomb</literal>, Mercurial facilita l'invio di email contenenti modifiche da rivedere o applicare. L'estensione è chiamata così perché le modifiche vengono inviate in forma di patch e solitamente viene inviato un singolo changeset per ogni messaggio email. Quindi, inviare una lunga serie di cambiamenti via email è molto simile a <quote>bombardare</quote> la casella del ricevente, da cui il nome <quote>patchbomb</quote>.</para> 20.205 - 20.206 - <para id="x_533">Come al solito, la configurazione di base dell'estensione <literal role="hg-ext">patchbomb</literal> occupa solo una o due righe del vostro file <filename role="special">~/.hgrc</filename>.</para> 20.207 + <para id="x_532">Grazie alla sua estensione <literal role="hg-ext">patchbomb</literal>, Mercurial facilita l’invio di email contenenti modifiche da rivedere o applicare. L’estensione è chiamata così perché le modifiche vengono inviate in forma di patch e solitamente viene inviato un singolo changeset per ogni messaggio email. Quindi, inviare una lunga serie di cambiamenti via email è molto simile a <quote>bombardare</quote> la casella del ricevente, da cui il nome <quote>patchbomb</quote>.</para> 20.208 + 20.209 + <para id="x_533">Come al solito, la configurazione di base dell’estensione <literal role="hg-ext">patchbomb</literal> occupa solo una o due righe del vostro file <filename role="special">~/.hgrc</filename>.</para> 20.210 <programlisting>[extensions] 20.211 patchbomb =</programlisting> 20.212 - <para id="x_534">Una volta che avete abilitato l'estensione, avrete a disposizione un nuovo comando chiamato <command role="hg-ext-patchbomb">email</command>.</para> 20.213 - 20.214 - <para id="x_535">Il modo migliore e più sicuro di invocare il comando <command role="hg-ext-patchbomb">email</command> è quello di eseguirlo <emphasis>sempre</emphasis> una prima volta con l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-n</option>. Questo vi mostrerà ciò che il comando <emphasis>invierebbe</emphasis>, senza in effetti inviare nulla. Una volta che avete dato una veloce occhiata ai cambiamenti e avete verificato di stare mandando quelli giusti, potete rieseguire lo stesso comando, questa volta senza l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-n</option>.</para> 20.215 + <para id="x_534">Una volta che avete abilitato l’estensione, avrete a disposizione un nuovo comando chiamato <command role="hg-ext-patchbomb">email</command>.</para> 20.216 + 20.217 + <para id="x_535">Il modo migliore e più sicuro di invocare il comando <command role="hg-ext-patchbomb">email</command> è quello di eseguirlo <emphasis>sempre</emphasis> una prima volta con l’opzione <option role="hg-ext-patchbomb-cmd-email-opt">-n</option>. Questo vi mostrerà ciò che il comando <emphasis>invierebbe</emphasis>, senza in effetti inviare nulla. Una volta che avete dato una veloce occhiata ai cambiamenti e avete verificato di stare mandando quelli giusti, potete rieseguire lo stesso comando, questa volta senza l’opzione <option role="hg-ext-patchbomb-cmd-email-opt">-n</option>.</para> 20.218 20.219 <para id="x_536">Il comando <command role="hg-ext-patchbomb">email</command> accetta lo stesso tipo di sintassi di revisione di tutti gli altri comandi Mercurial. Per esempio, questo comando invierà ogni revisione tra 7 e <literal>tip</literal> comprese.</para> 20.220 <programlisting>hg email -n 7:tip</programlisting> 20.221 - <para id="x_537">Potete anche specificare un <emphasis>repository</emphasis> con cui effettuare un confronto. Se fornite un repository senza indicare alcuna revisione, il comando <command role="hg-ext-patchbomb">email</command> invierà tutte le revisioni del repository locale che non sono presenti nel repository remoto. Se in aggiunta specificate revisioni o il nome di un ramo (quest'ultimo usando l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-b</option>), questo vincolerà le revisioni inviate.</para> 20.222 + <para id="x_537">Potete anche specificare un <emphasis>repository</emphasis> con cui effettuare un confronto. Se fornite un repository senza indicare alcuna revisione, il comando <command role="hg-ext-patchbomb">email</command> invierà tutte le revisioni del repository locale che non sono presenti nel repository remoto. Se in aggiunta specificate revisioni o il nome di un ramo (quest’ultimo usando l’opzione <option role="hg-ext-patchbomb-cmd-email-opt">-b</option>), questo vincolerà le revisioni inviate.</para> 20.223 20.224 <para id="x_538">È assolutamente sicuro invocare il comando <command role="hg-ext-patchbomb">email</command> senza i nomi delle persone a cui volete spedire un messaggio: se fate in questo modo, i destinatari vi verranno chiesti interattivamente. (Se state usando un sistema di tipo Unix o Linux, dovreste avere a disposizione le capacità avanzate di digitazione fornite da <literal>readline</literal> o librerie simili quando immettete quelle intestazioni, cosa che vi si rivelerà utile.)</para> 20.225 20.226 @@ -186,21 +186,21 @@ 20.227 <sect2> 20.228 <title>Modificare il comportamento di <literal role="hg-ext">patchbomb</literal></title> 20.229 20.230 - <para id="x_53b">Non tutti i progetti hanno esattamente le stesse convenzioni per spedire cambiamenti via email, così l'estensione <literal role="hg-ext">patchbomb</literal> prova a fornire un certo numero di variazioni attraverso le opzioni a riga di comando.</para> 20.231 + <para id="x_53b">Non tutti i progetti hanno esattamente le stesse convenzioni per spedire cambiamenti via email, così l’estensione <literal role="hg-ext">patchbomb</literal> prova a fornire un certo numero di variazioni attraverso le opzioni a riga di comando.</para> 20.232 <itemizedlist> 20.233 - <listitem><para id="x_53c">Potete scrivere un oggetto per il messaggio introduttivo sulla riga di comando usando l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-s</option>. Questa opzione accetta come argomento il testo da usare per l'oggetto.</para> 20.234 - </listitem> 20.235 - <listitem><para id="x_53d">Per cambiare l'indirizzo email da cui vengono spediti i messaggi usate l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-f</option>. Questa opzione accetta come argomento l'indirizzo email da usare.</para> 20.236 - </listitem> 20.237 - <listitem><para id="x_53e">Il comportamento predefinito è quello di inviare diff unificati (leggete la <xref linkend="sec:mq:patch"/> per una descrizione del formato), uno per ogni messaggio. Potete invece usare l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-b</option> per inviare un bundle eseguibile.</para> 20.238 - </listitem> 20.239 - <listitem><para id="x_53f">I diff unificati sono normalmente preceduti da un'intestazione di metadati. Potete ometterla e inviare diff disadorni con l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">--plain</option>.</para> 20.240 - </listitem> 20.241 - <listitem><para id="x_540">I diff vengono normalmente spediti <quote>in linea</quote>, nella stessa parte del corpo che contiene la descrizione della patch. Questo è il modo più facile per consentire al più ampio numero di lettori di rispondere citando parti di un diff, dato che alcuni client email citeranno soltanto la prima parte MIME del corpo di un messaggio. Se preferite inviare la descrizione e il diff in parti separate del corpo, usate l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-a</option>.</para> 20.242 - </listitem> 20.243 - <listitem><para id="x_541">Invece di spedire messaggi email, potete salvarli in una cartella email in formato <literal>mbox</literal> usando l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-m</option>. Questa opzione accetta come argomento il nome del file su cui scrivere.</para> 20.244 - </listitem> 20.245 - <listitem><para id="x_542">Se preferite aggiungere un riepilogo nel formato del comando <command>diffstat</command> a ogni patch e uno al messaggio introduttivo, usate l'opzione <option role="hg-ext-patchbomb-cmd-email-opt">-d</option>. Il comando <command>diffstat</command> mostra una tabella contenente il nome di ogni file coinvolto nella patch, il numero di righe modificate e un istogramma che illustra quante modifiche sono state apportate a ogni file. Questo riepilogo offre a chi legge una visione qualitativa della complessità di una patch.</para> 20.246 + <listitem><para id="x_53c">Potete scrivere un oggetto per il messaggio introduttivo sulla riga di comando usando l’opzione <option role="hg-ext-patchbomb-cmd-email-opt">-s</option>. Questa opzione accetta come argomento il testo da usare per l’oggetto.</para> 20.247 + </listitem> 20.248 + <listitem><para id="x_53d">Per cambiare l’indirizzo email da cui vengono spediti i messaggi usate l’opzione <option role="hg-ext-patchbomb-cmd-email-opt">-f</option>. Questa opzione accetta come argomento l’indirizzo email da usare.</para> 20.249 + </listitem> 20.250 + <listitem><para id="x_53e">Il comportamento predefinito è quello di inviare diff unificati (leggete la <xref linkend="sec:mq:patch"/> per una descrizione del formato), uno per ogni messaggio. Potete invece usare l’opzione <option role="hg-ext-patchbomb-cmd-email-opt">-b</option> per inviare un bundle eseguibile.</para> 20.251 + </listitem> 20.252 + <listitem><para id="x_53f">I diff unificati sono normalmente preceduti da un’intestazione di metadati. Potete ometterla e inviare diff disadorni con l’opzione <option role="hg-ext-patchbomb-cmd-email-opt">--plain</option>.</para> 20.253 + </listitem> 20.254 + <listitem><para id="x_540">I diff vengono normalmente spediti <quote>in linea</quote>, nella stessa parte del corpo che contiene la descrizione della patch. Questo è il modo più facile per consentire al più ampio numero di lettori di rispondere citando parti di un diff, dato che alcuni client email citeranno soltanto la prima parte MIME del corpo di un messaggio. Se preferite inviare la descrizione e il diff in parti separate del corpo, usate l’opzione <option role="hg-ext-patchbomb-cmd-email-opt">-a</option>.</para> 20.255 + </listitem> 20.256 + <listitem><para id="x_541">Invece di spedire messaggi email, potete salvarli in una cartella email in formato <literal>mbox</literal> usando l’opzione <option role="hg-ext-patchbomb-cmd-email-opt">-m</option>. Questa opzione accetta come argomento il nome del file su cui scrivere.</para> 20.257 + </listitem> 20.258 + <listitem><para id="x_542">Se preferite aggiungere un riepilogo nel formato del comando <command>diffstat</command> a ogni patch e uno al messaggio introduttivo, usate l’opzione <option role="hg-ext-patchbomb-cmd-email-opt">-d</option>. Il comando <command>diffstat</command> mostra una tabella contenente il nome di ogni file coinvolto nella patch, il numero di righe modificate e un istogramma che illustra quante modifiche sono state apportate a ogni file. Questo riepilogo offre a chi legge una visione qualitativa della complessità di una patch.</para> 20.259 </listitem> 20.260 </itemizedlist> 20.261
21.1 --- a/it/web/index-home.html.in Sat Aug 22 21:01:56 2009 +0200 21.2 +++ b/it/web/index-home.html.in Sat Aug 22 21:55:05 2009 +0200 21.3 @@ -3,9 +3,9 @@ 21.4 <div class="book"> 21.5 <h2>Benvenuti a Mercurial: la guida definitiva</h2> 21.6 21.7 - <p>Questo è il sito web del libro “Mercurial: la guida definitiva”, traduzione italiana del libro inglese “Mercurial: The Definitive Guide“ scritto da Bryan O’Sullivan e pubblicato da O'Reilly Media nel 2009.</p> 21.8 + <p>Questo è il sito web del libro “Mercurial: la guida definitiva”, traduzione italiana del libro inglese “Mercurial: The Definitive Guide“ scritto da Bryan O’Sullivan e pubblicato da O’Reilly Media nel 2009.</p> 21.9 21.10 - <p>Il contenuto della traduzione italiana è <a href="/read/">liberamente disponibile online</a>. Attualmente, la traduzione italiana non è pubblicata da nessun editore, perciò se il libro vi piace e volete sostenere l'autore (e la causa del software libero) potete acquistare una copia del libro in inglese.</p> 21.11 + <p>Il contenuto della traduzione italiana è <a href="/read/">liberamente disponibile online</a>. Attualmente, la traduzione italiana non è pubblicata da nessun editore, perciò se il libro vi piace e volete sostenere l’autore (e la causa del software libero) potete acquistare una copia del libro in inglese.</p> 21.12 <!-- 21.13 <p>For news updates, please visit <a href="http://www.serpentine.com/blog/">my blog</a>.</p> 21.14 --> 21.15 @@ -15,11 +15,11 @@ 21.16 21.17 <pre class="screen">hg clone http://bitbucket.org/gpiancastelli/hgbook-it</pre> 21.18 21.19 - <p>Se siete utenti Bitbucket, il servizio offre la possibilità di clonare repository attraverso l'interfaccia web, nonché di richiedere che le modifiche di un clone vengano estratte e propagate al repository originale.</p> 21.20 + <p>Se siete utenti Bitbucket, il servizio offre la possibilità di clonare repository attraverso l’interfaccia web, nonché di richiedere che le modifiche di un clone vengano estratte e propagate al repository originale.</p> 21.21 21.22 - <p>A differenza della versione inglese, le pagine web della versione italiana del libro non includono un sistema di commenti. Il modo migliore per segnalare problemi, errori, o sviste e comunicare suggerimenti è quello di usare l'<a href="http://bitbucket.org/gpiancastelli/hgbook-it/issues">apposito strumento</a> messo a disposizione da Bitbucket. In alternativa, potete inviare un'email all'indirizzo <a href="mailto:giulio.piancastelli@gmail.com">giulio.piancastelli@gmail.com</a> per contattare direttamente Giulio Piancastelli, l'autore della traduzione italiana.</p> 21.23 + <p>A differenza della versione inglese, le pagine web della versione italiana del libro non includono un sistema di commenti. Il modo migliore per segnalare problemi, errori, o sviste e comunicare suggerimenti è quello di usare l’<a href="http://bitbucket.org/gpiancastelli/hgbook-it/issues">apposito strumento</a> messo a disposizione da Bitbucket. In alternativa, potete inviare un’email all’indirizzo <a href="mailto:giulio.piancastelli@gmail.com">giulio.piancastelli@gmail.com</a> per contattare direttamente Giulio Piancastelli, l’autore della traduzione italiana.</p> 21.24 21.25 - <h2>Che cos'è Mercurial?</h2> 21.26 + <h2>Che cos’è Mercurial?</h2> 21.27 21.28 <p><a href="http://www.selenic.com/mercurial">Mercurial</a> è un sistema per il controllo di revisione veloce e leggero, progettato per gestire progetti distribuiti di grandi dimensioni in maniera semplice ed efficiente.</p> 21.29 21.30 @@ -29,8 +29,8 @@ 21.31 21.32 <p>Bryan O’Sullivan, ha deciso di donare le proprie royalty sulle vendite di questo libro alla Software Freedom Conservancy e incoraggia anche i lettori a supportare il lavoro di questa organizzazione.</p> 21.33 21.34 - <p>La SFC può <a href="http://conservancy.softwarefreedom.org/?donate">accettare donazioni</a> (esenti dalle tasse secondo la disposizione IRS 501(c)(3), all'interno degli Stati Uniti) per conto dei suoi progetti membro. Se volete supportare Mercurial direttamente, considerate la possibilità di fare una donazione alla SFC per destinarla al progetto.</p> 21.35 + <p>La SFC può <a href="http://conservancy.softwarefreedom.org/?donate">accettare donazioni</a> (esenti dalle tasse secondo la disposizione IRS 501(c)(3), all’interno degli Stati Uniti) per conto dei suoi progetti membro. Se volete supportare Mercurial direttamente, considerate la possibilità di fare una donazione alla SFC per destinarla al progetto.</p> 21.36 21.37 - <p>Se volete aiutare gli sviluppatori di software libero a fornire il proprio importante servizio pubblico senza essere ostacolati da problemi legali, considerate la possibilità di fare una donazione al <a href="http://www.softwarefreedom.org/">Software Freedom Law Center</a>, un centro legale che costituisce un'organizzazione gemella della SFC.</p> 21.38 + <p>Se volete aiutare gli sviluppatori di software libero a fornire il proprio importante servizio pubblico senza essere ostacolati da problemi legali, considerate la possibilità di fare una donazione al <a href="http://www.softwarefreedom.org/">Software Freedom Law Center</a>, un centro legale che costituisce un’organizzazione gemella della SFC.</p> 21.39 </div> 21.40