# HG changeset patch # User giulio@macbeth # Date 1250442582 -7200 # Node ID 4d4e9bea43595d1b932ec0db522b44bb2f0e6702 # Parent eca3a16c0114c1c9253b61b141b5c015a17a8018# Parent 632d4854b2b24471bf3f31a48ba824229037b3f8 Merge latest updates from other hgbook versions. diff -r eca3a16c0114 -r 4d4e9bea4359 .hgignore --- a/.hgignore Fri Aug 14 12:12:19 2009 -0700 +++ b/.hgignore Sun Aug 16 19:09:42 2009 +0200 @@ -25,6 +25,8 @@ en/examples/results en/html en/svn +it/examples/results +it/html stylesheets/system-xsl tools web/hgbook/.database.sqlite3 diff -r eca3a16c0114 -r 4d4e9bea4359 it/00book.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/00book.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,120 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +%SHORTCUTS; + + + + +%AUTOSNIPPETS; + +]> + + + Mercurial: la guida definitiva + + + Compiled from $rev_id$ + + 1 + 9780596800673 + + + Bryan + O'Sullivan + + + + + Mike + Loukides + + + + 2006 + 2007 + 2008 + 2009 + Bryan O'Sullivan + + + + Giulio + Piancastelli + + + + 2009 + Giulio Piancastelli + + + + + &ch00; + + &ch01; + + &ch02; + + &ch03; + + &ch04; + + &ch05; + + &ch06; + + &ch07; + + &ch08; + + &ch09; + + &ch10; + + &ch11; + + &ch12; + + &ch13; + + &ch14; + + &appA; + + &appB; + + &appC; + + &appD; + diff -r eca3a16c0114 -r 4d4e9bea4359 it/Makefile --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/Makefile Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,59 @@ +include Makefile.vars + +# Makefile.vars include the following system-dependent variables: +# +# dtd-url = the location of the DocBook 4.5 DTD on your filesystem +# system-xsl-dir = the location of DocBook XSLT on your filesystem +# python = the location of Python 3.x on your filesystem + +xml-src-files := \ + 00book.xml \ + $(wildcard ch*.xml) + #$(wildcard app*.xml) + +xsltproc-opts := --nonet --xinclude +xmllint-opts := --noout --nonet --valid --path '$(dtd-url)' + +obj-web := html +figs-web := ${obj-web}/figs +script-web := $(obj-web)/javascript +web-global := ../web +web-local := web + +html: ${obj-web}/index.html ${web-local}/index-read.html.in + +#$(obj-web)/index.html: ../stylesheets/system-xsl .validated-00book.xml #../web/index-read.html.in +$(obj-web)/index.html: .validated-00book.xml + xsltproc $(xsltproc-opts) -o $(obj-web)/x ../stylesheets/it/web.xsl 00book.xml +# xsltproc $(xsltproc-opts) -o $(obj-web)/x ../stylesheets/chunk-stylesheet.xsl 00book.xml + cp ${web-global}/styles.css ${obj-web} + mkdir -p ${figs-web} + cp -f ${web-global}/icons/*.png $(figs-web) + cp -f examples/figs/*.png $(figs-web) + mkdir -p $(script-web) + cp -f $(web-local)/*.js $(script-web) + sed -i -e "s|/support/||g" ${obj-web}/*.html +# python ../web/texpand.py ../web/index-read.html.in html/read/index.html +# for i in $(obj-web-read)/*.html; do \ +# gzip -9 -c $$i > $$i.gz; \ +# done + +#../stylesheets/system-xsl: $(system-xsl-dir) +# ln -s $< $@ + +$(web-local)/index-read.html.in: $(web-local)/genindex.py $(xml-src-files) + cp $(web-local)/index-template.html $(obj-web)/index.html + sed -i -e "s|{% block bodycontent %}{% endblock %}|$(shell cat $(web-local)/index-read.html.in)|g" ${obj-web}/index.html + +$(web-local)/genindex.py: $(xml-src-files) + cd $(web-local) && $(python) genindex.py + +valid: .validated-00book.xml + +.validated-00book.xml: $(xml-src-files) #examples/.run + xmllint $(xmllint-opts) $< + touch $@ + +clean: + rm -f $(web-local)/index-read.html.in + rm -rf $(obj-web) diff -r eca3a16c0114 -r 4d4e9bea4359 it/appA-svn.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/appA-svn.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,336 @@ + + +Migrare verso Mercurial + + Un modo comune di esplorare un nuovo strumento di controllo di revisione è quello di sperimentarlo trasferendo un progetto esistente piuttosto che cominciare un nuovo progetto da zero. + + In questa appendice, parleremo di come importare la cronologia di un progetto in Mercurial e di quello a cui dovete essere preparati se siete abituati a un sistema di controllo di revisione differente. + + + Importare la cronologia da un altro sistema + + Mercurial include un'estensione chiamata convert 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: + + + Subversion + + + CVS + + + git + + + Darcs + + + Bazaar + + + Monotone + + + GNU Arch + + + Mercurial + + + + (Per verificare perché lo stesso Mercurial sia supportato come sorgente da cui importare la cronologia, si veda la .) + + Potete attivare l'estensione nel solito modo, modificando il vostro file ~/.hgrc. + + [extensions] +convert = + + Questo renderà disponibile il comando hg convert. 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à. + + $ hg convert http://python-nose.googlecode.com/svn/trunk + + L'estensione convert opera in maniera incrementale. In altre parole, dopo che avete invocato hg convert 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 hg convert nello stesso repository Mercurial che avete usato in origine, perché l'estensione convert salva alcuni metadati privati all'interno del repository in un file chiamato .hg/shamap non soggetto al controllo di revisione. + + 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. + + + Convertire molti rami + + Il comando hg convert eseguito in precedenza converte solo la cronologia del trunk del repository Subversion. Se invece usiamo l'URL http://python-nose.googlecode.com/svn, Mercurial individuerà automaticamente le directory trunk, tags e branches che compongono la struttura usata di solito dai progetti Subversion e le importerà come rami separati. + + 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 hg branches -a. Se preferite importare i rami Subversion senza nomi, passate l'opzione al comando hg convert. + + 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 hg clone -r nomedelramo. + + + + Correlare i nomi utente + + 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. + + 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 al comando hg convert. Questa opzione accetta un nome di file che dovrebbe contenere voci nel seguente formato. + + arist = Aristotele <aristotele@filo.example.gr> +soc = Socrate <socrate@filo.example.gr> + + Ogni volta che convert incontra un commit associato al nome utente arist nel repository sorgente, userà il nome Aristotele <aristotele@filo.example.gr> nella revisione convertita in Mercurial. Se non viene trovata alcuna corrispondenza per un certo nome, quel nome viene usato alla lettera. + + + + Riordinare l'albero + + 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. + + L'estensione convert supporta l'idea di una mappa di file 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. + + Per specificare una mappa di file, usate l'opzione e fornitele un nome di file. Una mappa di file contiene righe nei seguenti formati. + + # Questo è un commento +# Le righe vuote vengono ignorate + +include percorso/del/file + +exclude percorso/del/file + +rename da/qualche/percorso a/qualche/altra/posizione + + + La direttiva include 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 stati esplicitamente inclusi. La direttiva exclude provoca l'esclusione dei file e delle directory indicate e di tutti quegli altri percorsi che non sono stati esplicitamente menzionati per essere inclusi. + + Per spostare un file o una directory da una posizione a un'altra, usate la direttiva rename. Se dovete spostare un file o una directory da una sottodirectory alla radice del repository, usate . come secondo argomento della direttiva rename. + + + + Migliorare le prestazioni della conversione da Subversion + + 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. + + Il comando svnsync 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. + + 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. + + $ svnadmin create memcached-mirror + + Successivamente, impostiamo un hook Subversion di cui svnsync ha bisogno. + + $ echo '#!/bin/sh' > memcached-mirror/hooks/pre-revprop-change +$ chmod +x memcached-mirror/hooks/pre-revprop-change + + Poi inizializziamo svnsync in questo repository. + + $ svnsync --init file://`pwd`/memcached-mirror \ + http://code.sixapart.com/svn/memcached + + Il passo successivo consiste nell'avviare il processo di creazione del mirror con il comando svnsync. + + $ svnsync sync file://`pwd`/memcached-mirror + + Infine, importiamo la cronologia del nostro mirror locale del repository Subversion in un repository Mercurial. + + $ hg convert memcached-mirror + + Se il repository Subversion è ancora attivo, possiamo usare questo processo in maniera incrementale. Invochiamo svnsync per propagare i nuovi cambiamenti verso il nostro mirror e poi invochiamo hg convert per importarli nel nostro albero Mercurial. + + Un'importazione in due stadi realizzata con svnsync ha due vantaggi. Il primo è che svnsync usa una sincronizzazione di rete con Subversion più efficiente rispetto al comando hg convert, 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. + + + + + Migrare da Subversion + + Attualmente Subversion è il sistema di controllo di revisione open source più popolare. Sebbene ci siano molte differenze tra Mercurial e Subversion, effettuare una transizione da Subversion a Mercurial non è particolarmente difficile. I due sistemi hanno insiemi di comandi simili e interfacce generalmente uniformi. + + + Differenze filosofiche + + 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. + + 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. + + + L'ambito dei comandi + + 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 svn log, otterrete la cronologia di qualunque parte dell'albero stiate osservando, non dell'intero albero. + + Il comportamento predefinito di Mercurial è differente perché i suoi comandi operano sull'intero repository. Eseguite hg log 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. hg log sorgenti. + + 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. + + + + Operazioni multi-utente e sicurezza + + 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. + + 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. + + 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. + + + + Cambiamenti locali o pubblici + + Il comando svn commit pubblica immediatamente i cambiamenti su un server dove possono essere visti da chiunque abbia accesso in lettura. + + Con Mercurial, i commit sono sempre locali e devono essere pubblicati successivamente tramite il comando hg push. + + 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 alla leggera i permessi di scrittura. + + 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. + + + + + Guida rapida + + + Equivalenze tra i comandi Subversion e Mercurial + + + + Subversion + Mercurial + Notes + + + + + svn add + hg add + + + + svn blame + hg annotate + + + + svn cat + hg cat + + + + svn checkout + hg clone + + + + svn cleanup + n/a + Nessuna pulizia necessaria + + + svn commit + hg commit; hg + push + hg push pubblica le modifiche dopo il commit + + + svn copy + hg clone + Per creare un nuovo ramo + + + svn copy + hg copy + Per copiare file o directory + + + svn delete (svn + remove) + hg remove + + + + svn diff + hg diff + + + + svn export + hg archive + + + + svn help + hg help + + + + svn import + hg addremove; hg + commit + + + + svn info + hg parents + Mostra quale revisione è stata estratta + + + svn info + hg showconfig + paths.parent + Mostra da quale URL è avvenuta l'estrazione + + + svn list + hg manifest + + + + svn log + hg log + + + + svn merge + hg merge + + + + svn mkdir + n/a + Mercurial non tiene traccia delle directory + + + svn move (svn + rename) + hg rename + + + + svn resolved + hg resolve -m + + + + svn revert + hg revert + + + + svn status + hg status + + + + svn update + hg pull -u + + + + +

+ + + + + Suggerimenti utili per i principianti + + 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 svn diff -r104653:104654. Mercurial elimina la necessità di digitare due volte l'identificatore di revisione in questo caso comune. Per ottenere solo le differenze, digitate hg export 104654. Per ottenere un messaggio dal registro della cronologia seguito dalle differenze, digitate hg log -r104654 -p. + + Quando eseguite hg status 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 hg status alla riga di comando. Se eseguite hg status passandogli il nome di un file o di una directory, il comando stamperà i percorsi relativi alla vostra posizione corrente. Quindi, per ottenere da hg status lo stato di tutto l'albero, con i percorsi relativi alla vostra directory corrente invece che alla radice del repository, passate il risultato di hg root al comando hg status. Su un sistema di tipo Unix, potete farlo facilmente nel modo che segue: + + $ hg status `hg root` + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/appB-mq-ref.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/appB-mq-ref.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,278 @@ + + + Guida di riferimento a Mercurial Queues + + + Guida di riferimento ai comandi MQ + + Per un'introduzione ai comandi forniti da MQ, usate il comando hg help mq. + + + <command role="hg-ext-mq">qapplied</command>&emdash;stampa le patch applicate + + Il comando qapplied 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 in cima alla pila. + + + + <command role="hg-ext-mq">qcommit</command>&emdash;registra i cambiamenti nel repository della coda + + Il comando qcommit registra qualsiasi cambiamento in sospeso nel repository .hg/patches. Questo comando funziona solo se la directory .hg/patches è un repository, i.e. se avete creato la directory usando hg qinit o avete invocato hg init nella directory dopo aver eseguito qinit. + + Questo comando è un'abbreviazione di hg commit --cwd .hg/patches. + + + <command role="hg-ext-mq">qdelete</command>&emdash;elimina una patch dal file <filename role="special">series</filename> + + Il comando qdelete rimuove la voce relativa a una patch dal file series nella directory .hg/patches. Non estrae la patch se la patch è già applicata. Per default, non cancella il file della patch, perciò dovrete usare l'opzione se volete fare questo. + + Opzioni: + + : cancella il file della patch. + + + + + + <command role="hg-ext-mq">qdiff</command>&emdash;stampa un diff dell'ultima patch applicata + + Il comando qdiff stampa un diff dell'ultima patch applicata. È equivalente al comando hg diff -r-2:-1. + + + + <command role="hg-ext-mq">qfinish</command>&emdash;sposta le patch applicate nella cronologia del repository + + Il comando hg qfinish converte le patch applicate specificate in modifiche permanenti, spostandole fuori dal controllo di MQ in modo che siano trattate come normale cronologia del repository. + + + + <command role="hg-ext-mq">qfold</command>&emdash;unisce (<quote>include</quote>) diverse patch in una + + Il comando qfold 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. + + Le patch da includere non devono essere applicate, altrimenti qfold terminerà segnalando un errore. L'ordine in cui le patch vengono incluse è significativo: hg qfold a b significa applica la patch più recente, seguita da a, seguita da b. + + 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 (*). Usate l'opzione per modificare il messaggio di commit della patch/changeset combinata dopo che l'inclusione è stata completata. + + Opzioni: + + : modifica il messaggio di commit e la descrizione di patch per la nuova patch combinata. + + : usa il testo contenuto nel file dato come nuovo messaggio di commit e descrizione di patch per la patch combinata. + + : usa il testo dato come nuovo messaggio di commit e descrizione di patch per la patch combinata. + + + + + + <command role="hg-ext-mq">qheader</command>&emdash;mostra l'intestazione/descrizione di una patch + + Il comando qheader 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. + + + + <command role="hg-ext-mq">qimport</command>&emdash;importa una patch di terze parti nella coda + + Il comando qimport aggiunge una voce per una patch esterna al file series e copia la patch nella directory .hg/patches. Aggiunge la voce immediatamente dopo l'ultima patch applicata, ma non inserisce la patch. + + Se la directory .hg/patches è un repository, qimport usa hg add per aggiungere automaticamente la patch importata. + + + + <command role="hg-ext-mq">qinit</command>&emdash;prepara un repository per lavorare con MQ + + Il comando qinit prepara un repository per lavorare con MQ. Crea una directory chiamata .hg/patches. + + Opzioni: + + : Crea .hg/patches sotto forma di repository. Crea anche un file .hgignore che ignorerà il file status. + + + + Quando la directory .hg/patches è un repository, i comandi qimport e qnew useranno automaticamente hg add per aggiungere nuove patch. + + + + <command role="hg-ext-mq">qnew</command>&emdash;crea una nuova patch + + Il comando qnew 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 series dopo l'ultima patch applicata e viene immediatamente inserita sopra quella patch. + + Se qnew trova qualche file modificato nella directory di lavoro, si rifiuterà di creare una nuova patch a meno che non usiate l'opzione (vedete più avanti). Questo comportamento vi permette di aggiornare l'ultima patch applicata tramite qrefresh prima di applicare una nuova patch. + + Opzioni: + + : 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. + + : usa il testo dato come messaggio di commit. Il testo verrà memorizzato all'inizio del file di patch, prima dei dati di patch. + + + + + + <command role="hg-ext-mq">qnext</command>&emdash;stampa il nome della patch successiva + + Il comando qnext stampa il nome della patch nel file series che segue la patch applicata più recentemente. Questa patch diventerà l'ultima patch applicata se invocate qpush. + + + + <command role="hg-ext-mq">qpop</command>&emdash;estrae le patch dalla pila + + Il comando qpop rimuove patch applicate dalla cima della pila delle patch applicate. Per default, rimuove solo una patch. + + Questo comando rimuove dal repository i changeset che rappresentano le patch estratte e aggiorna la directory di lavoro per annullare gli effetti delle patch. + + 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, qpop 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. + + Il comando qpop non legge e non modifica né le patch né il file series. Perciò, potete tranquillamente usare qpop su una patch che avete rimosso dal file series, 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. + + Per default, il comando qpop non estrarrà alcuna patch se la directory di lavoro è stata modificata. Potete cambiare questo comportamento usando l'opzione , che annulla tutte le modifiche nella directory di lavoro. + + Opzioni: + + : estrae tutte le patch applicate, riportando il repository allo stato in cui era prima che applicaste qualunque patch. + + : annulla forzatamente qualsiasi modifica alla directory di lavoro al momento dell'estrazione. + + : estrae una patch dalla coda nominata. + + + + Il comando qpop rimuove una riga alla fine del file status per ogni patch che ha estratto. + + + + <command role="hg-ext-mq">qprev</command>&emdash;stampa il nome della patch precedente + + Il comando qprev stampa il nome della patch nel file series che precede la patch applicata più recentemente. Questa patch diventerà l'ultima patch applicata se invocate qpop. + + + + <command role="hg-ext-mq">qpush</command>&emdash;inserisce le patch in cima alla pila + + Il comando qpush aggiunge le patch in cima alla pila delle patch applicate. Per default, aggiunge solo una patch. + + Questo comando crea un nuovo changeset per rappresentare ogni patch applicata e aggiorna la directory di lavoro per applicare gli effetti delle patch. + + I dati predefiniti usati per creare un changeset sono i seguenti. + + 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 qpop su una patch e poi invocate qpush sulla stessa patch, il changeset che inserite avrà un'identità diversa dal changeset che avete estratto. + + L'autore è quello predefinito usato dal comando hg commit. + + 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. + + + Se una patch contiene un'intestazione di patch Mercurial, i dati nell'intestazione di patch sostituiscono quelli predefiniti. + + Opzioni: + + : inserisce tutte le patch non applicate contenute nel file series fino a quando non ne rimane nessuna da inserire. + + : aggiunge il nome della patch alla fine del messaggio di commit. + + : 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. + + : usa la coda nominata se effettua un'unione durante l'inserimento. + + + + Il comando qpush legge, ma non modifica, il file series. Aggiunge una riga alla fine del file status per ogni patch inserita. + + + + <command + role="hg-ext-mq">qrefresh</command>&emdash;aggiorna l'ultima patch applicata + + Il comando qrefresh 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. + + Il comando qrefresh si occupa delle seguenti modifiche. + + I cambiamenti al messaggio di commit, i.e. il testo che precede la prima intestazione di diff nel file di patch, vengono riflessi nel nuovo changeset che rappresenta la patch. + + Le modifiche ai file registrati nella directory di lavoro vengono aggiunte alla patch. + + Per quanto riguarda le modifiche ai file registrati apportate tramite hg add, hg copy, hg remove, o hg rename, i file aggiunti e i file destinazione di copie e cambiamenti di nome vengono aggiunti alla patch, mentre i file rimossi e i file sorgente dei cambiamenti di nome vengono rimossi. + + + + Anche se qrefresh 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. + + Opzioni: + + : modifica il messaggio di commit e la descrizione della patch, usando l'editor di testo preferito. + + : modifica il messaggio di commit e la descrizione della patch, usando il testo dato. + + : modifica il messaggio di commit e la descrizione della patch, usando il testo contenuto nel file dato. + + + + + + <command role="hg-ext-mq">qrename</command>&emdash;rinomina una patch + + Il comando qrename rinomina una patch e modifica la voce relativa alla patch nel file series. + + Con un singolo argomento, qrename rinomina l'ultima patch applicata. Con due argomenti, cambia il nome del primo argomento al secondo argomento. + + + + <command role="hg-ext-mq">qseries</command>&emdash;stampa l'intera serie di patch + + Il comando qseries stampa l'intera serie di patch contenuta nel file series. 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. + + + + <command role="hg-ext-mq">qtop</command>&emdash;stampa il nome della patch corrente + + Il comando qtop stampa il nome della patch attualmente in cima alla pila delle patch applicate. + + + + <command + role="hg-ext-mq">qunapplied</command>&emdash;stampa le patch non ancora applicate + + Il comando qunapplied stampa i nomi delle patch non ancora applicate contenute nel file series, nell'ordine in cui le patch verrebbero inserite. + + + + <command role="hg-cmd">hg strip</command>&emdash;rimuove una revisione e i suoi discendenti + + Il comando hg strip rimuove una revisione e tutti i suoi discendenti dal repository. Annulla gli effetti delle revisioni rimosse dal repository e aggiorna la directory di lavoro al primo genitore della revisione rimossa. + + Il comando hg strip salva una copia di backup dei changeset rimossi in un bundle, in modo che possano essere riapplicati se sono stati rimossi per errore. + + Opzioni: + + : salva i changeset non correlati che sono mescolati ai changeset eliminati nel bundle di backup. + + : se un ramo ha più teste, rimuove tutte le teste. + + : evita di salvare il bundle di backup. + + + + + + Guida di riferimento ai file di MQ + + + Il file <filename role="special">series</filename> + + Il file series 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. + + Le righe possono contenere commenti. Un commento comincia con il carattere # e si estende fino alla fine della riga. Le righe vuote e le righe che contengono solo commenti vengono ignorate. + + Avrete spesso bisogno di modificare il file series 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 qpush la salti quando applica le patch. Potete anche cambiare l'ordine in cui le patch vengono applicate riordinando le loro voci nel file series. + + Viene anche supportata la possibilità di mettere il file series 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 del comando qinit, questo verrà fatto per voi automaticamente. + + + + Il file <filename role="special">status</filename> + + Il flie status contiene i nomi e gli hash di changeset per tutte le patch che MQ ha attualmente applicato. A differenza del file series, questo file non è destinato a essere modificato. Non dovreste mettere questo file sotto controllo di revisione, né modificarlo in alcun modo. Viene usato da MQ per mantenere traccia di informazioni strettamente private. + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/appC-srcinstall.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/appC-srcinstall.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,33 @@ + + + Installare Mercurial dai sorgenti + + + Sistemi di tipo Unix + + Se state usando un sistema di tipo Unix che include una versione sufficientemente recente di Python (2.3 o superiore), installare Mercurial dai sorgenti è facile. + + Scaricate un archivio dei sorgenti recente da http://www.selenic.com/mercurial/download. + + Estraete i contenuti dell'archivio: + gzip -dc mercurial-VERSIONE.tar.gz | tar xf - + + Posizionatevi nella directory dei sorgenti ed eseguite lo script di installazione che assemblerà Mercurial e lo installerà nella vostra directory personale. + cd mercurial-VERSIONE +python setup.py install --force --home=$HOME + + + Una volta che l'installazione è terminata, Mercurial si troverà nella sottodirectory bin della vostra directory personale. Non dimenticate di assicurarvi che questa directory sia presente nel percorso di ricerca della vostra shell. + + Probabilmente avrete bisogno di impostare la variabile d'ambiente PYTHONPATH 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 /home/bos/lib/python. 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 mercurial sono stati installati. + + + + Windows + + 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 non seguire questa strada se siete un utente occasionale. A meno che non intendiate lavorare su Mercurial, vi raccomando invece di usare un pacchetto di installazione eseguibile. + + Se avete intenzione di assemblare Mercurial dai sorgenti su Windows, seguite le direttive pratiche sul wiki di Mercurial all'indirizzo http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall e aspettatevi che il processo comporti lo svolgimento di numerose operazioni complicate. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/appD-license.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/appD-license.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,90 @@ + + + Open Publication License + + Questo volume è stato rilasciato sotto licenza Open Publication License, il cui testo viene qui di seguito riportato integralmente nella versione in lingua inglese non essendo disponibile, al momento della pubblicazione del libro, una traduzione ufficiale italiana con il corrispondente valore legale. Il testo della licenza fa riferimento alla Open Publication License versione 1.0, datata 8 giugno 1999. + + + Requirements on both unmodified and modified versions + + The Open Publication works may be reproduced and distributed in whole or in part, in any medium physical or electronic, provided that the terms of this license are adhered to, and that this license or an incorporation of it by reference (with any options elected by the author(s) and/or publisher) is displayed in the reproduction. + + Proper form for an incorporation by reference is as follows: + +

+ Copyright (c) year by author's name or designee. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, vx.y or later (the latest version is presently available at http://www.opencontent.org/openpub/). +

+ + The reference must be immediately followed with any options elected by the author(s) and/or publisher of the document (see ). + + Commercial redistribution of Open Publication-licensed material is permitted. + + 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. + + + + Copyright + + The copyright to each Open Publication is owned by its author(s) or designee. + + + + Scope of license + + The following license terms apply to all Open Publication works, unless otherwise explicitly stated in the document. + + Mere aggregation of Open Publication works or a portion of an Open Publication work with other works or programs on the same media shall not cause this license to apply to those other works. The aggregate work shall contain a notice specifying the inclusion of the Open Publication material and appropriate copyright notice. + + Severability. If any part of this license is found to be unenforceable in any jurisdiction, the remaining portions of the license remain in force. + + No warranty. Open Publication works are licensed and provided as is without warranty of any kind, express or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose or a warranty of non-infringement. + + + + Requirements on modified works + + All modified versions of documents covered by this license, including translations, anthologies, compilations and partial documents, must meet the following requirements: + + + The modified version must be labeled as such. + + The person making the modifications must be identified and the modifications dated. + + Acknowledgement of the original author and publisher if applicable must be retained according to normal academic citation practices. + + The location of the original unmodified document must be identified. + + 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. + + + + + Good-practice recommendations + + In addition to the requirements of this license, it is requested from and strongly recommended of redistributors that: + + + If you are distributing Open Publication works on hardcopy or CD-ROM, you provide email notification to the authors of your intent to redistribute at least thirty days before your manuscript or media freeze, to give the authors time to provide updated documents. This notification should describe modifications, if any, made to the document. + + All substantive modifications (including deletions) be either clearly marked up in the document or else described in an attachment to the document. + + Finally, while it is not mandatory under this license, it is considered good form to offer a free copy of any hardcopy and CD-ROM expression of an Open Publication-licensed work to its author(s). + + + + + License options + + The author(s) and/or publisher of an Open Publication-licensed document may elect certain options by appending language to the reference to or copy of the license. These options are considered part of the license instance and must be included with the license (or its incorporation by reference) in derived works. + + + To prohibit distribution of substantively modified versions without the explicit permission of the author(s). Substantive modification is defined as a change to the semantic content of the document, and excludes mere changes in format or typographical corrections. + To accomplish this, add the phrase Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. to the license reference or copy. + + To prohibit any publication of this work or derivative works in whole or in part in standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder. + To accomplish this, add the phrase Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder. to the license reference or copy. + + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/book-shortcuts.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/book-shortcuts.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch00-preface.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch00-preface.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,148 @@ + + + Prefazione + + + Raccontare la tecnologia + + 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. + + Sebbene a quel tempo fossi abbastanza impegnato a lavorare ai 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. + + 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. + + + + Grazie per il vostro sostegno a Mercurial + + Acquistando una copia di questo libro state sostenendo l'evoluzione e la libertà ininterrotta di Mercurial in particolare e del software free e open source in generale. O'Reilly Media e io stiamo donando le mie royalty sulle vendite di questo libro alla Software Freedom Conservancy (http://www.softwarefreedom.org/) 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. + + + + Ringraziamenti + + 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. + + I miei figli, Cian e Ruairi, si sono sempre fatti trovare pronti ad aiutarmi a rilassarmi con meravigliosi e spericolati giochi per bambini. Vorrei anche ringraziare la mia ex moglie, Shannon, per il suo supporto. + + 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. + + 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. + + 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. + + 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. + + Vorrei anche ringraziare le tante persone che mi hanno aiutato notando errori e fornendo utili suggerimenti in ogni parte del libro. + + Jeremy W. Sherman, Brian Mearns, Vincent Furia, Iwan Luijks, Billy Edwards, Andreas Sliwka, Paweł Sołyga, Eric Hanchrow, Steve Nicolai, Michał Masłowski, Kevin Fitch, Johan Holmberg, Hal Wine, Volker Simonis, Thomas P Jakobsen, Ted Stresen-Reuter, Stephen Rasku, Raphael Das Gupta, Ned Batchelder, Lou Keeble, Li Linxiao, Kao Cardoso Félix, Joseph Wecker, Jon Prescot, Jon Maken, John Yeary, Jason Harris, Geoffrey Zheng, Fredrik Jonson, Ed Davies, David Zumbrunnen, David Mercer, David Cabana, Ben Karel, Alan Franzoni, Yousry Abdallah, Whitney Young, Vinay Sajip, Tom Towle, Tim Ottinger, Thomas Schraitle, Tero Saarni, Ted Mielczarek, Svetoslav Agafonkin, Shaun Rowland, Rocco Rutte, Polo-Francois Poli, Philip Jenvey, Petr Tesałék, Peter R. Annema, Paul Bonser, Olivier Scherler, Olivier Fournier, Nick Parker, Nick Fabry, Nicholas Guarracino, Mike Driscoll, Mike Coleman, Mietek Bák, Michael Maloney, László Nagy, Kent Johnson, Julio Nobrega, Jord Fita, Jonathan March, Jonas Nockert, Jim Tittsler, Jeduan Cornejo Legorreta, Jan Larres, James Murphy, Henri Wiechers, Hagen Möbius, Gábor Farkas, Fabien Engels, Evert Rol, Evan Willms, Eduardo Felipe Castegnaro, Dennis Decker Jensen, Deniz Dogan, David Smith, Daed Lee, Christine Slotty, Charles Merriam, Guillaume Catto, Brian Dorsey, Bob Nystrom, Benoit Boissinot, Avi Rosenschein, Andrew Watts, Andrew Donkin, Alexey Rodriguez, Ahmed Chaudhary. + + + + Convenzioni usate in questo libro + + Questo libro adotta le seguenti convenzioni tipografiche: + + + + Corsivo + + + Indica nuovi termini, URL, indirizzi email, nomi di file ed estensioni di file. + + + + + Spaziatura fissa + + + Usato per i listati dei programmi, così come 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. + + + + + Spaziatura fissa in grassetto + + + Mostra comandi o altro testo che dovrebbe essere digitato letteralmente dall'utente. + + + + + Spaziatura fissa in corsivo + + + Mostra testo che dovrebbe essere sostituito da valori forniti dall'utente oppure determinati dal contesto. + + + + + + Questa icona indica un consiglio, suggerimento, o nota generale. + + + + Questa icona indica un avviso o avvertimento. + + + + + Usare gli esempi di codice + + 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. + + 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: “Titolo del libro di Qualche Autore. Copyright 2008 O’Reilly Media, Inc., 978-0-596-xxxx-x.” + + 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 permissions@oreilly.com. + + + + Safari® Books Online + + + 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. + + + 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 http://my.safaribooksonline.com. + + + + Come contattarci + + Per favore spedite commenti e domande riguardanti questo libro all'editore: + + + O’Reilly Media, Inc. + + 1005 Gravenstein Highway North + + Sebastopol, CA 95472 + + 800-998-9938 (negli Stati Uniti o in Canada) + + 707-829-0515 (internazionale o locale) + + 707 829-0104 (fax) + + + 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: + + + + + + Per inviare un commento o porre domande tecniche su questo libro, spedite un'email a: + + + bookquestions@oreilly.com + + + Per maggiori informazioni sui nostri libri, sulle conferenze, sui Centri di Risorse, e su O'Reilly Network, visitate il nostro sito web all'indirizzo: + + + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch01-intro.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch01-intro.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,267 @@ + + + Come siamo arrivati qui? + + + Perché il controllo di revisione? Perché Mercurial? + + 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. + + Tuttavia, gestire più versioni anche solo di un singolo file è un'operazione soggetta a errori, quindi 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. + + La comparsa del controllo di revisione distribuito è relativamente recente, e finora questo nuovo campo è cresciuto grazie alla propensione umana per l'esplorazione di territori sconosciuti. + + 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. + + + Perché usare il controllo di revisione? + + 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. + + + Terrà traccia della storia e dell'evoluzione del vostro progetto, così voi non dovete farlo. Per ogni modifica, registrerà informazioni riguardanti chi l'ha fatta, perché l'ha fatta, quando è stata fatta e cosa è stato modificato. + 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. + 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 davvero buono vi aiuterà a calcolare efficientemente il momento esatto in cui un problema è stato introdotto (si veda la per i dettagli). + Vi aiuterà a lavorare simultaneamente su molteplici versioni del vostro progetto e a gestire gli spostamenti tra una versione e l'altra. + + + 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. + + Un aspetto chiave della praticità del controllo di revisione a queste due dimensioni di sviluppo differenti (programmatore solitario e gruppo gigantesco) è il confronto tra i suoi benefici e i suoi costi. Uno strumento di controllo di revisione che sia difficile da capire e usare finirà per imporre un costo piuttosto alto. + + È 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 senza di esso il fallimento del progetto è quasi garantito. + + D'altra parte, il lavoretto veloce 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? + + Mercurial supporta in maniera unica entrambe 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 davvero cercando di fare senza farvi distrarre da 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. + + Nessuno strumento di controllo di revisione può salvare un progetto gestito male, ma la scelta degli strumenti adeguati può fare una notevole differenza nella fluidità con cui potete lavorare su un progetto. + + + + + I molti nomi del controllo di revisione + + Il controllo di revisione è un campo talmente vario che vi si fa spesso riferimento attraverso diversi nomi e acronimi. Ecco alcune delle variazioni più comuni che incontrerete: + + controllo di revisione (RCS); + gestione della configurazione del software (SCM), o gestione della configurazione; + gestione del codice sorgente; + controllo del codice sorgente, o controllo dei sorgenti; + controllo di versione (VCS). + + 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. + + + + + + A proposito degli esempi in questo libro + + Questo libro tratta gli esempi di codice in maniera inusuale. Tutti gli esempi sono vivi&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 costruita dai suoi sorgenti, tutti gli script di esempio vengono automaticamente eseguiti e i loro risultati correnti vengono confrontati con i loro risultati attesi. + + Il vantaggio di questo approccio è che gli esempi sono sempre accurati, in quanto descrivono esattamente 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. + + C'è un piccolo svantaggio in questo approccio, cioè che le date e gli orari che vedete negli esempi tendono a venire compressi 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. + + 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 bisect nella , tanto per farvi un'idea. + + Quindi, mentre leggete gli esempi, non date troppo peso alle date e agli orari che vedete nei risultati dei comandi, ma potete decisamente fare affidamento sulla consistenza e riproducibilità del comportamento illustrato. + + + + + Le tendenze nel campo + + 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. + + 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. + + 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 essere in grado di parlare al 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. + + 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. + + + + Alcuni vantaggi del controllo di revisione distribuito + + 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. + + 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 aggiuntivo 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. + + 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. + + 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. + + + Vantaggi per i progetti open source + + Se siete affascinati da un progetto open source e decidete che vi piacerebbe cominciare a lavorarci sopra, e quel progetto usa uno strumento distribuito di controllo di revisione, potete immediatamente operare su un piano di parità con il gruppo di persone che si considerano il cuore di quel progetto. Se il gruppo pubblica il proprio repository, potete immediatamente copiare la cronologia del progetto, cominciare a effettuare modifiche e registrare il vostro lavoro utilizzando gli stessi strumenti allo stesso modo dei membri del gruppo. Al contrario, con uno strumento centralizzato, siete costretti a usare il software in modalità di sola lettura a meno che qualcuno non vi conceda il permesso di inserire i vostri cambiamenti sul server centrale. Fino a quel momento non sarete in grado di registrare i cambiamenti, e le vostre modifiche rischieranno di venire rovinate ogni volta che provate ad aggiornare la vista del repository dal vostro client. + + + Il falso problema dei fork + + È 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 biforcare (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. + + Talvolta le parti di un fork decidono di riconciliare le loro differenze. Con uno strumento centralizzato di controllo di revisione, il processo tecnico di riconciliazione è doloroso e deve essere in gran parte effettuato a mano. Dovete decidere quale cronologia delle revisioni dovrà prevalere 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. + + Gli strumenti distribuiti rendono la biforcazione l'unico 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 unire (in inglese, merge) due fork, perché i fork sono assolutamente fondamentali: vengono effettuati in ogni momento. + + 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 fork diventa un problema puramente sociale. Gli strumenti distribuiti in realtà non fanno altro che ridurre la probabilità di un vero e proprio fork: + + 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; + 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. + + + 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 fluidamente con chiunque si senta in dovere di duplicare la cronologia del vostro progetto. + + + + + Vantaggi per i progetti commerciali + + 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. + + 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. + + 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. + + + + + Perché scegliere Mercurial? + + Mercurial possiede un insieme di caratteristiche unico che lo rende una scelta particolarmente valida come sistema di controllo di revisione. + + È facile da imparare e usare. + È leggero. + Scala in maniera eccellente. + È facile da personalizzare. + + + 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. + + 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 tenta di essere agile e di non starvi tra i piedi combinando un basso costo cognitivo con operazioni estremamente veloci. + + 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. + + 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 alla identificazione dei bug fino al miglioramento delle prestazioni. + + + + Un confronto tra Mercurial e altri strumenti + + Prima di proseguire, vi prego di tenere a mente che questa sezione riflette necessariamente la mia esperienza, i miei interessi e (oserei dire) i miei pregiudizi. Ho usato tutti i sistemi di controllo di revisione qui elencati, in più casi per diversi anni alla volta. + + + Subversion + + Subversion è un sistema di controllo di revisione piuttosto popolare, sviluppato per sostituire CVS. Ha un'architettura client/server centralizzata. + + 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. + + 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 complicata e difettosa. + + 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 ra_local 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. + + 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 (status) e visualizzare le modifiche rispetto alla revisione corrente (diff). 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. + + 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. + + 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. + + 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. + + 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 sentire l'acqua 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. + + + + Git + + 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. + + 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à. + + 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. + + Mentre un repository Mercurial non ha bisogno di alcuna manutenzione, un repository Git richiede frequenti reimpacchettamenti 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. + + 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. + + Mercurial può importare la cronologia di revisione da un repository Git. + + + + + CVS + + 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. + + Ha un'architettura client/server centralizzata. Non raggruppa cambiamenti di file correlati in inserimenti atomici, esponendo gli utenti al rischio di guastare il software: 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). + + 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. + + Mercurial può importare la cronologia di revisione da 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). + + Mercurial può importare la cronologia di revisione da un repository CVS. + + + + Strumenti commerciali + + 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. + + 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. + + + + Scegliere uno strumento di controllo di revisione + + Con l'eccezione di CVS, tutti gli strumenti elencati sopra 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. + + 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. + + Personalmente trovo che le caratteristiche di Mercurial, come la semplicità, le prestazioni e un buon supporto per le unioni, siano una combinazione irresistibile che mi ha servito bene per diversi anni. + + + + + Passare da un altro strumento a Mercurial + + Mercurial viene distribuito con un'estensione chiamata convert, che può importare incrementalmente la cronologia delle revisioni da diversi altri strumenti di controllo di revisione. Con incrementale 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. + + Gli strumenti di controllo di revisione supportati da convert sono i seguenti: + + Subversion + CVS + Git + Darcs + + In più, convert 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. + + Il comando convert è 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. + + + + Una breve storia del controllo di revisione + + 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. + + 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. + + 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. + + 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. + + 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.) + + 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; non gestisce bene la sua 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 soglia del dolore da oltrepassare per correggere questi problemi architetturali. + + 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. + + 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 ai primi (e ai successivi) strumenti di controllo di revisione in un certo numero di modi innovativi, usando hash crittografici come identificatori e adottando una nozione integrale di fiducia per autenticare il codice che proviene da sorgenti differenti. + + 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. + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch02-tour-basic.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch02-tour-basic.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,509 @@ + + + Una panoramica di Mercurial: i concetti di base + + + Installare Mercurial sul vostro sistema + + I pacchetti di installazione precompilati che sono disponibili per tutti i sistemi operativi più popolari vi permettono di cominciare facilmente a usare subito Mercurial sul vostro computer. + + + Windows + + La miglior versione di Mercurial per Windows è TortoiseHg, che può essere trovata all'indirizzo http://bitbucket.org/tortoisehg/stable/wiki/Home. 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. + + + + + Mac OS X + + Lee Cantey fornisce un pacchetto di installazione di Mercurial per Mac OS X all'indirizzo http://mercurial.berkwood.com. + + + + Linux + + 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. + + Per semplificare le cose, mi concentrerò sull'installazione di Mercurial dalla linea di comando sotto le 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 mercurial. + + + Ubuntu e Debian: + apt-get install mercurial + Fedora: + yum install mercurial + OpenSUSE: + zypper install mercurial + Gentoo: + emerge mercurial + + + + + Solaris + + SunFreeWare, all'indirizzo http://www.sunfreeware.com, allestisce pacchetti precompilati di Mercurial. + + + + + + + Per cominciare + + Come prima cosa, useremo il comando hg version 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. + + &interaction.tour.version; + + + Aiuto predefinito + + 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 hg help 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. + + &interaction.tour.help; + + Per ottenere un livello di dettaglio ancora maggiore (che di solito non vi servirà) eseguite hg help . L'opzione è l'abbreviazione di e dice a Mercurial di stampare più informazioni di quanto farebbe di solito. + + + + + Lavorare con un repository + + In Mercurial, tutto accade all'interno di un repository. Il repository di un progetto contiene tutti i file che appartengono a quel progetto insieme a una registrazione cronologica delle loro modifiche. + + 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 linea di comando sia il vostro programma preferito di gestione dei file. + + + Fare una copia locale di un repository + + Copiare 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 hg clone, perché crea una copia identica di un repository esistente. + + &interaction.tour.clone; + + Come possiamo vedere qui sopra, il comando hg clone ha il vantaggio di poter clonare un repository attraverso la rete. Un altro vantaggio di questo comando è quello di ricordare da dove abbiamo effettuato la copia, cosa che ci tornerà utile molto presto quando vorremo prelevare nuovi cambiamenti da un altro repository. + + Se la nostra clonazione ha avuto successo, ora dovremmo avere una directory locale chiamata hello. Questa directory contiene alcuni file. + + &interaction.tour.ls; + + Il contenuto e la cronologia di questi file nel nostro repository sono gli stessi di quelli presenti nel repository che abbiamo clonato. + + 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. + + Per ora, questo significa che siamo liberi di effettuare esperimenti con il nostro repository, sapendo con sicurezza che è un ambiente di prova privato le cui variazioni non avranno effetto su nessun altro. + + + + Che cosa contiene un repository? + + Se diamo un'occhiata più dettagliata all'interno di un repository, possiamo vedere che contiene una directory chiamata .hg. Questo è il luogo dove Mercurial tiene tutti i propri metadati sul repository. + + &interaction.tour.ls-a; + + Il contenuto della directory .hg e delle sue sottodirectory è riservato a Mercurial. Tutti gli altri file e directory nel repository sono vostri e potete farne ciò che volete. + + Per introdurre un po' di terminologia, diciamo che la directory .hg è il repository reale e che tutti gli altri file e directory che coesistono con esso si trovano nella directory di lavoro. Potete ricordare facilmente questa distinzione se considerate che il repository contiene la cronologia del progetto, mentre la directory di lavoro contiene una fotografia del vostro progetto in un punto particolare della cronologia. + + + + + Un viaggio attraverso la cronologia + + Una delle prime cose che potremmo voler fare con un nuovo repository che non ci è familiare è conoscere la sua storia. Il comando hg log ci permette di vedere la cronologia dei cambiamenti nel repository. + + &interaction.tour.log; + + Secondo le sue impostazioni predefinite, questo comando stampa un breve paragrafo per ogni cambiamento che è stato registrato nel progetto. Nella terminologia di Mercurial, chiamiamo changeset (letteralmente, insieme di cambiamenti) ognuno di questi eventi registrati perché contiene la registrazione dei cambiamenti a diversi file. + + I campi di una singola registrazione mostrata da hg log sono i seguenti. + + + changeset: questo campo ha il formato di un numero, seguito dal carattere di due punti, seguito da una stringa esadecimale. Questi sono gli identificatori 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. + + user: 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. + date: 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.) + summary: la prima riga del messaggio di testo che il creatore del changeset ha utilizzato per descrivere il changeset. + + Alcuni changeset, come il primo della lista mostrata qui sopra, sono contrassegnati da un'etichetta contenuta in un campo tag. Un'etichetta è un altro modo di identificare un changeset, dandogli un nome facile da ricordare. (L'etichetta chiamata tip è speciale: si riferisce sempre alla modifica più recente nel repository.) + + + + Il testo stampato dall'esecuzione predefinita del comando hg log è un semplice riepilogo e in quanto tale non contiene molti dettagli. + + La mostra una rappresentazione grafica della cronologia del repository hello, in modo che sia un po' più facile vedere qual è la direzione in cui la cronologia si sta sviluppando. Ritorneremo a questa figura diverse volte in questo capitolo e nei capitoli che seguono. + +

+ Rappresentazione grafica della cronologia per il repository <filename class="directory">hello</filename> + + + XXX add text + + + + + Parlare di changeset o revisioni con altre persone + + 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 usa una varietà di termini ed espressioni per indicare la stessa cosa. Se parlate della cronologia di Mercurial con altre persone, scoprirete che il termine changeset è spesso abbreviato in change (in italiano, cambiamento) o in cset (nella sua forma scritta) e che talvolta ci si riferisce a un changeset chiamandolo revisione oppure rev. + + Mentre non ha importanza quale parola voi usiate per riferirvi al concetto di un changeset, l'identificatore che usate per riferirvi a uno specifico changeset è di grande importanza. Ricordatevi che il campo changeset nel riepilogo mostrato da hg log identifica un changeset utilizzando sia un numero che una stringa esadecimale. + + Il numero di revisione è una notazione comoda che è valida solo in quel repository. + La stringa esadecimale è l'identificatore permanente e non modificabile che individuerà sempre quell'esatto changeset in qualsiasi copia del repository. + + + Questa distinzione è importante. Se spedite un'email a qualcuno parlando della revisione 33, c'è un'alta probabilità che la sua revisione 33 non sia la stessa 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 a,b,c possono facilmente comparire in un repository come 0,1,2 e in un altro repository come 0,2,1. + + 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. + + + + Vedere revisioni specifiche + + Per ridurre l'elenco stampato dal comando hg log a una singola revisione, usate l'opzione (o ). Potete usare sia un numero di revisione che un identificatore esadecimale e potete fornire al comando tutte le revisioni che volete. + + &interaction.tour.log-r; + + Se volete vedere la cronologia di diverse revisioni senza doverle elencare tutte potete usare la notazione di intervallo, che vi permette di esprimere l'idea di operare su tutte le revisioni tra abc e def comprese. + + &interaction.tour.log.range; + + Mercurial rispetta anche l'ordine in cui specificate le revisioni, quindi il comando hg log -r 2:4 stamperà le revisioni 2, 3 e 4, mentre il comando hg log -r 4:2 stamperà le revisioni 4, 3 e 2. + + + + Informazioni più dettagliate + + Mentre le informazioni di riepilogo stampate da hg log 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 (o ) del comando hg log vi fornisce questi dettagli aggiuntivi. + + &interaction.tour.log-v; + + Se volete vedere sia la descrizione che il contenuto di un cambiamento, aggiungete l'opzione (o ). In questo modo il contenuto del cambiamento verrà stampato come un diff unificato (se non avete mai visto un diff unificato prima d'ora, date un'occhiata alla per un'introduzione). + + &interaction.tour.log-vp; + + L'opzione è tremendamente utile, quindi merita di essere ricordata. + + + + + + Tutto quello che dovete sapere sulle opzioni dei comandi + + 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 parnoramica. + + 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. + + + + Ogni opzione ha un nome lungo. Per esempio, come avete già visto, il comando hg log accetta un'opzione . + + + La maggior parte delle opzioni ha anche un nome breve. Invece di , possiamo usare . (Alcune opzioni non hanno un nome breve perché vengono usate raramente.) + + + Le opzioni lunghe cominciano con due trattini (e.g. ), mentre le opzioni brevi cominciano con un solo trattino (e.g. ). + + + Lo schema di denominazione e di utilizzo delle opzioni è consistente attraverso tutti i comandi. Per esempio, ogni comando che vi permette di specificare un identificatore di changeset o un numero di revisione accetta entrambi gli argomenti e . + + + Se state usando le opzioni brevi, potete risparmiare altri caratteri raggruppandole insieme. Per esempio, il comando hg log -v -p -r 2 può essere scritto come hg log -vpr2. + + + + 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. + + La maggior parte dei comandi che stampano un testo di qualche tipo stamperanno più testo quando gli verrà passata l'opzione (o ) e meno testo quando gli verrà passata l'opzione (o ). + + + La consistenza nella denominazione delle opzioni + + 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 o . L'uso consistente dei nomi delle opzioni rende più facile ricordarsi quali opzioni sono accettate da un particolare comando. + + + + + Come effettuare e rivedere i cambiamenti + + Ora che sappiamo come ispezionare la cronologia in Mercurial, diamo un'occhiata al modo in cui si apportano e si esaminano i cambiamenti. + + Per cominciare, isoleremo il nostro esperimento in un apposito repository. Usiamo il comando hg clone, 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 + 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. + . + + &interaction.tour.reclone; + + Come nota a margine, è buona pratica tenere da parte una copia intatta 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. + + Nel nostro repository my-hello abbiamo un file hello.c che contiene il classico programma ciao, mondo. + + &interaction.tour.cat1; + + Modifichiamo questo file in modo da fargli stampare una seconda riga. + + &interaction.tour.cat2; + + Il comando hg status di Mercurial ci dirà quello che Mercurial sa sullo stato dei file nel repository. + + &interaction.tour.status; + + Il comando hg status non stampa nulla per alcuni file e stampa una riga che comincia con M per hello.c. A meno che non glielo chiediate, hg status non stamperà alcuna informazione per i file che non sono stati modificati. + + La M indica che Mercurial ha notato che abbiamo modificato il file hello.c. Non abbiamo avuto bisogno di informare Mercurial che stavamo per modificare il file prima di cominciare o che abbiamo modificato il file dopo aver finito. Mercurial è stato in grado di rendersene conto da solo. + + In qualche modo, è utile sapere che abbiamo modificato hello.c, ma potremmo preferire sapere esattamente quali cambiamenti abbiamo apportato. Per fare questo, utilizziamo il comando hg diff. + + &interaction.tour.diff; + + + Capire le patch + + Ricordate di dare un'occhiata alla se non sapete come interpretare il risultato del comando appena eseguito. + + + + Registrare i cambiamenti in un nuovo changeset + + Possiamo modificare i file, compilare e collaudare i nostri cambiamenti, e usare hg status e hg diff per rivisitare le nostre modifiche fino a quando non siamo soddisfatti di quello che abbiamo ottenuto e arriviamo a un naturale punto fermo in cui vogliamo registrare il nostro lavoro in un nuovo changeset. + + Il comando hg commit ci permette di creare un nuovo changeset. Faremo riferimento a questa operazione con le espressioni effettuare un commit o eseguire un commit oppure con il termine inglese commit e talvolta con il termine italiano inserimento. + + + Impostare un nome utente + + Quando provate a eseguire hg commit 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. + + La precedenza più alta verrà data al nome utente che segue l'opzione del comando hg commit. + Successivamente, verrà controllato il valore della variabile d'ambiente HGUSER. + Quindi, verrà usato l'elemento username contenuto in un file chiamato .hgrc che potreste aver creato nella vostra directory personale. Per vedere come dovrebbero apparire i contenuti di questo file, fate riferimento alla più avanti. + Successivamente, verrà controllato il valore della variabile d'ambiente EMAIL. + 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. + + 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. + Dovreste considerare la variabile d'ambiente HGUSER e l'opzione del comando hg commit 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 .hgrc. + + Creare un file di configurazione per Mercurial + + Per impostare un nome utente, usate il vostro editor preferito e create un file chiamato .hgrc nella vostra directory personale. Mercurial userà questo file per cercare le vostre impostazioni di configurazione personalizzate. Il contenuto iniziale del vostro file.hgrc dovrebbe somigliare al seguente. + + + La <quote>directory personale</quote> sotto Windows + + In una installazione italiana di Windows, la vostra directory perosnale di solito corrisponde a una cartella chiamata con il vostro nome utente che si trova in C:\Documents and Settings. Potete scoprire l'esatto nome della vostra directory personale aprendo una finestra del prompt dei comandi e invocando il comando seguente. + + C:\> echo %UserProfile% + + + # Questo è un file di configurazione per Mercurial. +[ui] +username = Nome Cognome <indirizzo.email@example.org> + + La riga [ui] comincia una sezione del file di configurazione, così potete leggere la riga username = ... con il significato di imposta il valore dell'elemento username nella sezione ui. 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 # come un commento. + + + + Scegliere un nome utente + + Potete usare il testo che preferite come valore dell'elemento di configurazione username, 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. + + 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. + + + + Scrivere un messaggio di commit + + Quando inseriamo un cambiamento, Mercurial apre un editor di testo per farci scrivere un messaggio di commit 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 hg log successive alla terminazione dell'inserimento. + + &interaction.tour.commit; + + L'editor aperto dal comando hg commit conterrà una o due righe vuote, seguite da un certo numero di righe che cominciano con HG:. + + +Potete digitare qui il vostro messaggio di commit. + +HG: Inserite un messaggio di commit. Le righe che cominciano con 'HG:' verranno rimosse. +HG: -- +HG: utente: Bryan O'Sullivan <bos@serpentine.com> +HG: ramo 'default' +HG: modificato hello.c + + Mercurial ignora le righe che cominciano con HG: e le usa solamente per dirci a quali file appartengono i cambiamenti che sta per registrare. Modificare o cancellare quelle righe non ha alcun effetto. + + + Scrivere un buon messaggio di commit + + Dato che hg log stampa per default solo la prima riga del messaggio di commit, è meglio scrivere un messaggio di commit in cui la prima riga stia in piedi da sola. Ecco un esempio reale di un messaggio di commit che non segue questa linea guida e che quindi presenta un riepilogo incomprensibile. + + +changeset: 73:584af0e231be +user: Persona Censurata <persona.censurata@example.org> +date: Tue Sep 26 21:37:07 2006 -0700 +summary: incluso buildmeister/commondef. Aggiunti gli export. + + Non ci sono regole ferree da seguire per quanto riguarda il resto del contenuto del messaggio di commit. Lo stesso Mercurial non interpreta né si occupa del contenuto del messaggio, sebbene il vostro progetto possa adottare politiche che vi obbligano a un certo tipo di formattazione. + Personalmente, prediligo messaggi di commit brevi ma informativi che mi dicano qualcosa che non sono in grado di capire attraverso una veloce occhiata al risultato del comando hg log --patch. + Se eseguiamo hg commit senza argomenti, il comando registra tutti i cambiamenti che abbiamo effettuato, come riportati dai comandi hg status e hg diff. + + + Una sorpresa per gli utenti Subversion + + Come altri comandi Mercurial, hg commit opererà su tutta la directory di lavoro del repository se non forniamo esplicitamente al comando i nomi dei file da inserire. Dovete fare attenzione a questa particolarità se venite dal mondo Subversion o CVS, perché potreste aspettarvi di operare solo nella directory corrente in cui vi trovate e nelle sue sottodirectory. + + + + + Abortire un commit + + 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. + + + + Ammirare la nostra nuova opera + + Una volta che abbiamo terminato l'inserimento, possiamo usare il comando hg tip per visualizzare il changeset che abbiamo appena creato. Questo comando produce una stampa identica a quella del comando hg log, ma mostra solamente la revisione più recente nel repository. + + &interaction.tour.tip; + + Ci riferiremo alla revisione più recente nel repository come alla revisione di punta, o semplicemente la punta. + + Notate che il comando hg tip accetta molte delle stesse opzioni viste per hg log, quindi l'opzione nell'esempio precedente chiede al comando di essere verboso e l'opzione specifica di stampare una patch. L'uso di per stampare le patch è un altro esempio della denominazione consistente che avevamo menzionato in precedenza. + + + + + Condividere i cambiamenti + + Come abbiamo già detto, i repository Mercurial sono auto-contenuti. Questo significa che il cambiamento che abbiamo appena creato esiste solo nel nostro repository my-hello. Vediamo ora alcuni modi in cui possiamo propagare questa modifica verso altri repository. + + + Estrarre i cambiamenti da altri repository + + Per cominciare, cloniamo il nostro repository hello originale, che non contiene la modifica che abbiamo appena introdotto. Chiameremo hello-pull il nostro repository temporaneo. + + &interaction.tour.clone-pull; + + Useremo il comando hg pull per propagare i cambiamenti dal repository my-hello al repository hello-pull. Tuttavia, estrarre alla cieca cambiamenti sconosciuti da un repository è una prospettiva che può incutere qualche timore. Mercurial fornisce il comando hg incoming proprio allo scopo di elencare quali cambiamenti verrebbero estratti dal repository senza effettivamente procedere con l'operazione. + + &interaction.tour.incoming; + + Propagare i cambiamenti in un repository è semplicemente questione di eseguire il comando hg pull, dicendogli opzionalmente da quale repository compiere l'estrazione. + + &interaction.tour.pull; + + Come potete vedere se confrontate il risultato di hg tip 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. + + + Estrarre cambiamenti specifici + + È possibile che, a causa del ritardo tra l'esecuzione di hg incoming e hg pull, 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 hg incoming, 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 hg incoming. + + Se volete estrarre solamente quei particolari cambiamenti che sono stati elencati da hg incoming, o avete qualche altra ragione per estrarre un sottoinsieme dei cambiamenti, è sufficiente utilizzare l'identificatore di changeset del cambiamento che volete estrarre, e.g. hg pull -r7e95bb. + + + + + Aggiornare la directory di lavoro + + Finora abbiamo glissato sulla relazione tra il repository e la sua directory di lavoro. Il comando hg pull che abbiamo eseguito nella 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 hg pull prevede di non modificare la directory di lavoro. Per fare questo, dobbiamo invece usare il comando hg update. + + &interaction.tour.update; + + Potrebbe sembrare un po' strano che hg pull non aggiorni automaticamente la directory di lavoro, ma c'è una buona ragione per questo: hg update è in grado di aggiornare la directory di lavoro allo stato in cui era in qualsiasi revisione 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 hg pull da voi eseguito aggiornare automaticamente la directory di lavoro a una nuova revisione. + + Dato che la sequenza di estrazione e aggiornamento è così comune, Mercurial vi permette di combinare le due operazioni passando l'opzione al comando hg pull. + + Se tornate indietro alla e osservate il testo visualizzato dal comando hg pull eseguito senza l'opzione , potete vedere che contiene un promemoria utile a ricordarci che dobbiamo effettuare un passo esplicito per aggiornare la directory di lavoro. + + Per scoprire a quale revisione è aggiornata la directory di lavoro, usate il comando hg parents. + + &interaction.tour.parents; + + Se tornate indietro a guardare la , vedrete che ogni changeset è collegato da frecce. Ogni nodo da cui parte una freccia è un genitore e il nodo corrispondente a cui la freccia arriva è suo figlio. Analogamente, anche la directory di lavoro possiede un genitore, che è il changeset contenuto nella directory in quel momento. + + Per aggiornare la directory di lavoro a una particolare revisione, fornite un numero di revisione o un identificatore di changeset al comando hg update. + + &interaction.tour.older; + + Se omettete una revisione esplicita, hg update effettuerà l'aggiornamento alla revisione più recente (la revisione di punta), come mostrato nella seconda invocazione di hg update nell'esempio precedente. + + + + Pubblicare i cambiamenti in un altro repository + + Mercurial ci permette di trasmettere i nostri cambiamenti dal repository in cui ci troviamo verso un altro repository. Come per l'esempio del comando hg pull appena illustrato, creeremo un repository temporaneo a cui trasmettere i nostri cambiamenti. + + &interaction.tour.clone-push; + + Il comando hg outgoing ci dice quali cambiamenti verrebbero trasmessi verso un altro repository. + + &interaction.tour.outgoing; + + E il comando hg push esegue l'effettiva trasmissione. + + &interaction.tour.push; + + Allo stesso modo di hg pull, il comando hg push non aggiorna la directory di lavoro nel repository verso il quale sta trasmettendo i cambiamenti. Diversamente da hg pull, hg push non fornisce un'opzione -u 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. + + Cosa succede se proviamo a estrarre o trasmettere cambiamenti che il repository contiene già? Nulla di particolarmente eccitante. + + &interaction.tour.push.nothing; + + + + Ubicazioni predefinite + + Quando cloniamo un repository, Mercurial registra l'ubicazione del repository che abbiamo clonato nel file .hg/hgrc del nuovo repository. I comandi hg pull e hg push useranno quella ubicazione come impostazione predefinita quando vengono invocati senza fornire esplicitamente un percorso. Anche i comandi hg incoming e hg outgoing si comporteranno allo stesso modo. + + Se aprite il file .hg/hgrc di un repository con un editor di testo, vedrete contenuti simili ai seguenti. + + [paths] +default = http://www.selenic.com/repo/hg + + È possibile&emdash;e spesso utile&emdash;impostare le ubicazioni per hg push e hg outgoing con valori differenti rispetto a quelle per hg pull e hg incoming, aggiungendo un elemento default-push alla sezione [paths] del file .hg/hgrc nel modo seguente. + + [paths] +default = http://www.selenic.com/repo/hg +default-push = http://hg.example.com/hg + + + + Condividere i cambiamenti attraverso la rete + + I comandi che abbiamo trattato nelle precedenti sezioni non si limitano a lavorare con repository locali. Ogni comando funziona esattamente allo stesso modo attraverso una connessione di rete quando gli viene passato un URL invece di un percorso locale. + + &interaction.tour.outgoing.net; + + In questo esempio, possiamo vedere quali cambiamenti potremmo trasmettere al repository remoto, ma il repository è comprensibilmente impostato per evitare che gli utenti anonimi vi pubblichino le proprie modifiche. + + &interaction.tour.push.net; + + + + + Cominciare un nuovo progetto + + Cominciare un nuovo progetto è tanto facile quanto lavorare su un progetto esistente. Il comando hg init crea un nuovo repository Mercurial vuoto. + + &interaction.ch01-new.init; + + Questa invocazione non fa altro che creare un repository chiamato mioprogetto nella directory corrente. + + &interaction.ch01-new.ls; + + Possiamo dire che mioprogetto è un repository Mercurial perché contiene una directory .hg. + + &interaction.ch01-new.ls2; + + Se vogliamo aggiungere alcuni file preesistenti al repository, possiamo copiarveli e utilizzare il comando hg add per dire a Mercurial di cominciare a monitorarli. + + &interaction.ch01-new.add; + + Una volta che siamo soddisfatti del corretto aspetto del nostro progetto, possiamo effettuare il commit dei nostri cambiamenti. + + &interaction.ch01-new.commit; + + Ci vogliono solo pochi minuti per cominciare a usare Mercurial su un nuovo progetto, e questo è parte del suo fascino. Il controllo di revisione è diventato facile da impiegare anche sui progetti più piccoli per i quali non lo avremmo preso in considerazione se avessimo dovuto usare uno strumento più complicato. + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch03-tour-merge.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch03-tour-merge.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,234 @@ + + + Una panoramica di Mercurial: le unioni + + 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 unire le modifiche provenienti da repository separati. + + + Unire flussi di lavoro + + Le unioni giocano un ruolo fondamentale quando si lavora con uno strumento di controllo di revisione distribuito. Ecco alcuni casi in cui può presentarsi il bisogno di unire tra loro due o più flussi di lavoro. + + + Alice e Bruno hanno ognuno una copia personale di un repository per un progetto su cui stanno collaborando. Mentre Alice corregge un bug nel suo repository, Bruno aggiunge una nuova funzione nel proprio. Entrambi vogliono che il repository condiviso contenga sia la correzione del bug sia la nuova funzione. + + + Cinzia lavora frequentemente su più attività differenti alla volta per un singolo progretto, ognuna isolata al sicuro nel proprio repository. Lavorando in questo modo, Cinzia ha spesso bisogno di unire una parte del proprio lavoro con un'altra. + + + + Dato che abbiamo spesso bisogno di eseguire unioni, Mercurial ci viene in aiuto agevolando questo processo. Per capire come funzionano le unioni, seguiamone una passo per passo. Cominceremo creando ancora un altro clone del nostro repository (vedete quante volte spuntano fuori?) apportandovi poi alcune modifiche. + + &interaction.tour.merge.clone; + + Ora abbiamo due copie di hello.c con contenuti differenti e le cronologie dei due repository divergono l'una dall'altra, come illustrato nella . Ecco la copia del nostro file presente nel primo repository. + + &interaction.tour.merge.cat1; + + Ed ecco la versione leggermente differente contenuta nell'altro repository. + + &interaction.tour.merge.cat2; + +

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

+ I contenuti del repository dopo aver propagato i cambiamenti da <filename class="directory">my-hello</filename> a <filename class="directory">my-new-hello</filename> + + + + + XXX add text + + + + Dalla , potete vedere l'effetto della propagazione dei cambiamenti dal repository my-hello al repository my-new-hello. La cronologia già presente in my-new-hello non viene toccata, ma al repository è stata aggiunta una nuova revisione. Riferendoci alla , possiamo vedere che nel nuovo repository l'identificatore di changeset rimane lo stesso, ma il numero di revisione è cambiato. (Questo, incidentalmente, è un buon esempio del perché sia inopportuno usare i numeri di revisione per discutere i changeset.) Possiamo vedere le teste di un repository utilizzando il comando hg heads. + + &interaction.tour.merge.heads; + + + + Effettuare l'unione + + Cosa succede se proviamo a usare normalmente il comando hg update per aggiornare la directory di lavoro alla nuova punta? + + &interaction.tour.merge.update; + + Mercurial ci sta dicendo che hg update 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 hg update -C provocherebbe la perdita di tutte le modifiche contenute nella directory di lavoro e non ancora inserite nel repository.) + + Per avviare un'unione tra le due teste, usiamo il comando hg merge. + + &interaction.tour.merge.merge; + + Il contenuto del file hello.c viene sistemato. L'operazione aggiorna la directory di lavoro in modo che contenga le modifiche provenienti da entrambe le teste, cosa che si riflette sia nell'elenco visualizzato dal comando hg parents sia nei contenuti del file hello.c. + + &interaction.tour.merge.parents; + + + + Inserire i risultati dell'unione nel repository + + Ogni volta che eseguiamo un'unione, il comando hg parents mostrerà due genitori fino a quando non invocheremo hg commit per inserire i risultati dell'unione nel repository. + + &interaction.tour.merge.commit; + + Ora abbiamo una nuova revisione di punta che, come potete notare, possiede entrambe le nostre vecchie teste come genitori. Queste sono le stesse revisioni che erano state precedentemente mostrate da hg parents. + + &interaction.tour.merge.tip; + + Nella , potete vedere una rappresentazione di quanto accade alla directory di lavoro durante l'unione e di come questo abbia effetto sul repository quando avviene l'inserimento. Durante l'unione, la directory di lavoro possiede due changeset genitori che poi diventano i genitori del nuovo changeset. + +

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

+ Modifiche in conflitto a un documento + + + XXX add text + + + + La illustra un esempio di due diversi cambiamenti a uno stesso documento che sono in conflitto tra loro. Siamo partiti da una singola versione del file, a cui poi abbiamo apportato alcune modifiche mentre qualcun altro faceva modifiche differenti allo stesso testo. Nella risoluzione del conflitto tra i cambiamenti, il nostro compito è quello di decidere che cosa dovrebbe contenere il file. + + Mercurial non è dotato di alcuna 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. + + È anche possibile far eseguire a Mercurial uno specifico programma, impostando il valore della variable di ambiente HGMERGE al nome del vostro programma preferito. + + + Usare uno strumento grafico di unione + + Il mio strumento grafico preferito per gestire le unioni è kdiff3, che userò per descrivere le caratteristiche comuni a queste applicazioni. Potete vedere kdiff3 in azione nella . Il tipo di unione che sta eseguendo si chiama unione a tre vie, perché ci sono tre differenti versioni di un file che ci interessano. La porzione superiore della finestra è divisa in tre pannelli: + + a sinistra troviamo la versione base del file, i.e. la versione più recente da cui discendono le due versioni che stiamo cercando di unire; + + nel mezzo troviamo la nostra versione del file, con i contenuti che abbiamo modificato; + + a destra troviamo la loro versione del file, quella che proviene dal changeset che stiamo cercando di incorporare. + + Il pannello sottostante contiene il risultato corrente dell'unione. Il nostro compito è quello di sostituire tutto il testo in rosso, che indica conflitti irrisolti, con una qualche combinazione ragionevole della nostra e della loro versione del file. + + Tutti e quattro questi pannelli sono collegati tra loro: se ci spostiamo in verticale o in orizzontale in un pannello qualsiasi, gli altri vengono aggiornati per mostrare le sezioni corrispondenti dei rispettivi file. + +

+ Usare <command>kdiff3</command> per unire diverse versioni di un file + + + + + XXX add text + + + + + Per ogni porzione conflittuale del file, possiamo scegliere di risolvere il conflitto usando una qualche combinazione di testo dalla versione base, dalla nostra, o dalla loro. Possiamo anche modificare manualmente il file risultante in ogni momento, nel caso avessimo bisogno di effettuare ulteriori cambiamenti. + + Esistono molti strumenti per 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). + + + + Un esempio risolto + + In questo esempio, riprodurremo la cronologia delle modifiche ai file della vista in precedenza. Per cominciare, creiamo un repository con una versione base del nostro documento. + + &interaction.tour-merge-conflict.wife; + + Cloniamo il repository e apportiamo un cambiamento al file. + + &interaction.tour-merge-conflict.cousin; + + E ora aggiungiamo un altro clone, per simulare qualcun altro che effettui un cambiamento al file. (Questo suggerisce l'idea che non è affatto inusuale ritrovarsi a unire tra loro i propri repository contenenti attività isolate, risolvendo i conflitti incontrati nel corso di questo processo.) + + &interaction.tour-merge-conflict.son; + + Avendo creato due versioni differenti del file, predisponiamo un ambiente adeguato a eseguire la nostra unione. + + &interaction.tour-merge-conflict.pull; + + In questo esempio, imposterò la variabile d'ambiente HGMERGE per dire a Mercurial di usare il comando non interattivo merge. Questo comando è incluso in molti sistemi di tipo Unix. (Se state seguendo questo esempio sul vostro computer, non preoccupatevi di impostare HGMERGE. Vi verrà presentata un'applicazione grafica da utilizzare per unire i file, che è un'alternativa di gran lunga preferibile.) + + &interaction.tour-merge-conflict.merge; + + Dato che merge non riesce a risolvere il conflitto tra i cambiamenti, inserisce alcuni marcatori di unione all'interno del file che esibisce i conflitti, per indicare quali righe sono in conflitto e se quelle righe provengono dalla nostra versione del file o dalla loro. + + Dal modo in cui merge termina, Mercurial riconosce che non è stato in grado di operare con successo, quindi ci dice quali comandi abbiamo bisogno di eseguire se vogliamo rifare l'operazione di unione. Questo potrebbe essere utile se, per esempio, stessimo lavorando con un'applicazione grafica per la gestione delle unioni e la chiudessimo perché siamo confusi o realizziamo di aver commesso un errore. + + Nel caso in cui l'unione automatica o manuale fallisca, nulla ci impedisce di correggere i file interessati per conto nostro, per poi inserire i risultati della nostra unione nel repository: + + &interaction.tour-merge-conflict.commit; + + + Dov'è il comando <command>hg resolve</command>? + + Il comando hg resolve è stato introdotto nella verisone 1.1 di Mercurial rilasciata nel dicembre 2008. Se state usando una versione più vecchia (eseguite hg version per controllare) questo comando non sarà presente. Nel caso la vostra versione di Mercurial sia precedente alla 1.1, vi consiglio vivamente di installare una versione più recente prima di affrontare unioni complicate. + + + + + + Semplificare la sequenza di estrazione-unione-inserimento + + Il processo di unione dei cambiamenti appena delineato è molto semplice, ma richiede di eseguire tre comandi in sequenza. + hg pull -u +hg merge +hg commit -m 'Incorporati i cambiamenti remoti' + Nel caso dell'inserimento finale, avete anche bisogno di includere un messaggio di commit, che sarà quasi sempre composto da testo standard non particolarmente interessante. + + Se fosse possibile, sarebbe comodo ridurre il numero di passi necessari. In effetti, Mercurial viene distribuito con un'estensione chiamata fetch pensata proprio per questo scopo. + + Mercurial fornisce un meccanismo flessibile per consentire ad altre persone di estendere le sue funzionalità, preservando le dimensioni ridotte e la manutenibilità del proprio nucleo. Alcune estensioni aggiungono nuovi comandi che potete usare dalla riga di comando, mentre altri lavorano dietro le quinte, per esempio accrescendo le funzionalità della modalità server predefinita di Mercurial. + + L'estensione fetch aggiunge un nuovo comando chiamato, naturalmente, hg fetch. Questa estensione agisce come una combinazione di hg pull -u, hg merge e hg commit. Comincia propagando verso il repository corrente i cambiamenti estratti da un altro repository. Se si accorge che i cambiamenti hanno aggiunto una nuova testa al repository, aggiorna la directory di lavoro alla nuova testa, poi avvia il processo di unione e infine, se l'unione ha successo, ne inserisce il risultato nel repository con un messaggio di commit generato automaticamente. Se non sono state aggiunte nuove teste, il comando si limita ad aggiornare la directory di lavoro alla nuova revisione di punta. + + Abilitare l'estensione fetch è facile. Aprite il file .hgrc che si trova nella vostra directory personale e andate alla sezione extensions (oppure createla se non esiste già). Poi aggiungete una riga che contenga semplicemente fetch=. + + [extensions] +fetch = + + (Normalmente, la parte a destra del simbolo = indicherebbe dove trovare l'estensione, ma dato che l'estensione fetch è compresa nella distribuzione standard, Mercurial sa già dove andarla a cercare.) + + + + Rinominare, copiare e unire + + Durante la vita di un progetto, vorremo spesso cambiare la disposizione dei suoi file e delle sue directory. Queste modifiche possono essere tanto semplici quanto rinominare un singolo file, o tanto complesse quanto ristrutturare l'intera gerarchia dei file nell'ambito del progetto. + + Mercurial supporta questi tipi di cambiamenti in maniera fluida, a patto che gli diciamo quello che stiamo facendo. Se vogliamo rinominare un file, dovremmo usare il comando hg rename + Se siete utenti Unix, sarete felici di sapere che il comando hg rename si può abbreviare in hg mv. + per cambiare il nome del file, in modo che Mercurial possa comportarsi in maniera appropriata nel caso più tardi effettuassimo un'unione. + + Tratteremo l'uso di questi comandi in maniera più estesa nella . + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch04-concepts.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch04-concepts.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,346 @@ + + + Dietro le quinte + + 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 modello concettuale del suo funzionamento. + + 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 sicuro che efficiente. 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. + + Inizieremo questo capitolo parlando dei concetti chiave alla base della progettazione di Mercurial, poi proseguiremo discutendo alcuni dei dettagli più interessanti della sua implementazione. + + + La registrazione della cronologia di Mercurial + + + Memorizzare la cronologia di un singolo file + + Quando Mercurial tiene traccia delle modifiche a un file, memorizza la cronologia di quel file in un oggetto di metadati chiamato filelog (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 .hg/store/data. Un filelog contiene due tipi di informazione: dati di revisione, più un indice per aiutare Mercurial a trovare una revisione in maniera efficiente. + + 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 .d) e l'indice (con un suffisso .i). Per file di piccole dimensioni con una cronologia ridotta, i dati di revisione e l'indice vengono combinati in un singolo file .i. La corrispondenza tra un file nella directory di lavoro e il filelog che tiene traccia della sua cronologia nel repository è illustrata nella . + +

+ Relazioni tra i file nella directory di lavoro e i filelog nel repository + + + XXX add text + + + + + + Gestire i file archiviati + + Mercurial usa una struttura chiamata manifest (in italiano, manifesto) per collezionare informazioni sui file di cui tiene traccia. Ogni voce nel manifest contiene informazioni sui file presenti in un singolo changeset e registra quali file sono contenuti nel changeset, la revisione di ogni file e alcuni altri metadati sui file. + + + + Registrare le informazioni di changeset + + Il changelog (letteralmente, registro dei cambiamenti) contiene informazioni su tutti i changeset. Ogni revisione memorizza chi ha inserito un cambiamento, il commento del changeset, altre informazioni relative al changeset e la revisione del manifest da usare. + + + + Relazioni tra le revisioni + + 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 attraverso queste strutture, e tali relazioni sono di natura gerarchica. + + 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 archiviato quando il changeset è stato creato. Queste relazioni sono illustrate nella . + +

+ Relazioni tra i metadati + + + XXX add text + + + + Come mostrato in figura, non c'è una relazione uno a uno 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 + È 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. + . + + + + + Memorizzazione sicura ed efficiente + + Il supporto su cui si basano i changelog, i manifest e i filelog viene fornito da una singola struttura chiamata revlog (letteralmente, registro di revisione). + + + Memorizzazione efficiente + + Il revlog permette di memorizzare le revisioni in maniera efficiente usando un meccanismo basato su differenze chiamate delta. 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. + + 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. + + + + Operazioni sicure + + Mercurial si limita ad aggiungere 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. + + In più, Mercurial tratta ogni scrittura come parte di una transazione che può coinvolgere un qualsiasi numero di file. Una transazione è atomica: 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. + + 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 che vengano fatte correttamente. + + + + Reperimento veloce + + Mercurial evita astutamente un'insidia comune a tutti i primi sistemi di controllo di revisione: il problema del reperimento inefficiente. La maggior parte dei sistemi di controllo di revisione memorizza i contenuti di una revisione come una serie incrementale di modifiche rispetto a una fotografia. (Alcuni basano la fotografia sulla revisione più vecchia, altri su quella più nuova.) 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. + +

+ Fotografia di un revlog, con delta incrementali + + + XXX add text + + + + 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 qualsiasi revisione di un file e funziona così bene che in seguito è stato copiato da molti altri sistemi di controllo di revisione. + + La 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. + + + Digressione: l'influenza della compressione video + + 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. + + Mercurial prende in prestito questa idea per fare in modo che sia possibile ricostruire una revisione da una fotografia e da un ridotto numero di delta. + + + + + Identificazione e integrità forte + + Insieme alle informazioni di delta e di fotografia, una voce di revlog contiene un hash crittografico dei dati che rappresenta. Questo rende difficile contraffare i contenuti di una revisione e facilita la scoperta di corruzioni accidentali dei dati. + + 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. + + 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. + + 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. + + + + + Cronologia delle revisioni, ramificazioni e unioni + + Ogni voce in un revlog di Mercurial conosce l'identità della propria revisione progenitrice diretta, di solito chiamata genitore. In effetti, una revisione contiene spazio non solo per un genitore, ma per due. Mercurial usa un hash speciale, chiamato identificatore nullo, per rappresentare l'idea che non c'è alcun genitore qui. Questo hash è semplicemente una stringa di zeri. + + Nella , 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. + + 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 normale, 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 rami. Una revisione che rappresenta un'unione tra rami ha due identificatori di revisione normali negli spazi dedicati ai propri genitori. + +

+ La struttura concettuale di un revlog + + + XXX add text + + + + + + La directory di lavoro + + Nella directory di lavoro, Mercurial mantiene una fotografia dei file contenuti nel repository scattata su un changeset particolare. + + La directory di lavoro sa 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. + + Il dirstate (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 .hg/dirstate all'interno di un repository. Il dirstate contiene i dettagli del changeset a cui la directory di lavoro è aggiornata e di tutti i file di cui Mercurial sta tenendo traccia 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. + + 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 hg update, il changeset a cui aggiornate la directory di lavoro viene memorizzato nello spazio del primo genitore e l'identificatore nullo nello spazio del secondo. Quando incorporate un altro changeset tramite hg merge, il primo genitore rimane lo stesso e il secondo genitore diventa il changeset che state incorporando. Il comando hg parents vi dice quali sono i genitori del dirstate. + + + Cosa succede quando eseguite un commit + + Il dirstate mantiene le informazioni sui genitori per altri scopi oltre alla mera contabilità. Mercurial usa i genitori del dirstate come i genitori di un nuovo changeset quando effettuate un commit. + +

+ La directory di lavoro può avere due genitori + + + XXX add text + + + + La mostra il normale stato della directory di lavoro, in cui la directory ha un singolo changeset come genitore. Quel changeset è la punta, il changeset più recente senza figli nel repository. + +

+ La directory di lavoro acquisisce nuovi genitori dopo un commit + + + XXX add text + + + + È utile pensare alla directory di lavoro come al changeset che state per inserire. 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. + + 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 . 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. + + + + Creare una nuova testa + + È perfettamente normale aggiornare la directory di lavoro a un changeset diverso dalla punta corrente. Per esempio, potreste voler sapere come il vostro progetto appariva lo scorso martedì, oppure potreste dover scorrere i changeset per trovare quello che ha introdotto un bug. In questi casi, la cosa naturale da fare è aggiornare la directory di lavoro al changeset che vi interessa e poi esaminare i file direttamente nella directory di lavoro per vedere quali erano i loro contenuti quando avete inserito quel changeset. Gli effetti di questa azione si possono vedere nella . + +

+ La directory di lavoro, aggiornata a un vecchio changeset + + + XXX add text + + + + Avendo aggiornato la directory di lavoro a un vecchio changeset, cosa succede se apportate alcuni cambiamenti e poi li inserite? Mercurial si comporta nello stesso modo delineato in precedenza. I genitori della directory di lavoro diventano i genitori del nuovo changeset. Questo nuovo changeset non ha figli, quindi diventa la nuova punta. E il repository ora contiene due changeset senza figli che vengono chiamati teste. Potete vedere la struttura creata da questa operazione nella . + +

+ La situazione dopo un commit effettuato su un aggiornamento a un vecchio changeset + + + XXX add text + + + + + Se avete appena cominciato a lavorare con Mercurial, dovreste tenere a mente un errore comune, che è quello di usare il comando hg pull senza alcuna opzione. Per default, il comando hg pull non aggiorna la directory di lavoro, ma propagherà i nuovi cambiamenti nel vostro repository lasciandola sincronizzata allo stesso changeset in cui si trovava prima della propagazione. Se ora effettuate alcuni cambiamenti e poi li inserite, creerete una nuova testa, perché la vostra directory di lavoro non è stata sincronizzata alla revisione di punta corrente. Per combinare le operazioni di estrazione e aggiornamento, eseguite hg pull -u. + + Ho messo la parola errore tra virgolette perché tutto quello che dovete fare per rettificare la situazione in cui avete creato una nuova testa per sbaglio è eseguire il comando hg merge seguito da hg commit. In altre parole, questo errore non ha quasi mai conseguenze negative, ma è solo qualcosa che può sorprendere i nuovi utenti. Più avanti, discuterò altri modi per evitare questo comportamento e le ragioni per cui Mercurial si comporta in questo modo inizialmente sorprendente. + + + + + Unire i cambiamenti + + Quando eseguite il comando hg merge, Mercurial lascia invariato il primo genitore della directory di lavoro e imposta il secondo genitore al cambiamento che state incorporando, come mostrato nella . + +

+ Unire due teste + + + + + XXX add text + + + + 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. + + Se nessuno dei changeset ha modificato il file, non fare nulla con quel file. + + Se un changeset ha modificato il file e l'altro non lo ha modificato, crea la copia modificata del file nella directory di lavoro. + + 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. + + 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? + + 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. + + 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. + + 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. + + Se considerate quello che succede quando effettuate un commit dopo un'unione, ancora una volta la directory di lavoro è il changeset che state per inserire. Dopo che il comando hg merge ha terminato, la directory di lavoro possiede due genitori, che poi diventeranno i genitori del nuovo changeset. + + 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. + + + + + Le unioni e i cambiamenti di nome + + Un numero sorprendente di sistemi di controllo di revisione dedica poca o addirittura nessuna attenzione ai cambiamenti del nome 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. + + 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. + + + + + Altre caratteristiche di progettazione interessanti + + 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 di primo piano 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. + + + Compressione intelligente + + Quando è appropriato, Mercurial memorizzerà sia la fotografia che le delta in forma compressa, cercando sempre di comprimere una fotografia o una delta, ma memorizzando la versione compressa solo se è più piccola della versione originale. + + Questo significa che Mercurial fa la cosa giusta quando memorizza un file il cui formato sia già compresso, come un archivio zip 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 zip o JPEG. + + 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 la cosa giusta 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. + + + Ricompressione di rete + + Nel memorizzare le revisioni su disco, Mercurial usa l'algoritmo di compressione deflate (lo stesso usato dal popolare formato zip), 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. + + 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 bzip2). 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. + + Se la connessione avviene via ssh, Mercurial non ricomprime il flusso, perché ssh è già in grado di farlo da sé. Potete dire a Mercurial di usare sempre la funzione di compressione di ssh modificando il file .hgrc che si trova nella vostra directory personale nel modo seguente. + + [ui] +ssh = ssh -C + + + + + Ordinamento e atomicità delle operazioni di lettura e scrittura + + 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 , le revisioni in un changelog puntano alle revisioni nel manifest e le revisioni nel manifest puntano alle revisioni nel filelog. Questa gerarchia è intenzionale. + + Un'operazione di scrittura avvia una transazione modificando i dati nel 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 nel filelog. + + Dato che la scrittura ha sempre terminato di modificare i dati nel 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 del filelog. + + + + Accesso concorrente + + Le garanzie sull'ordinamento e sull'atomicità delle operazioni di lettura significano che Mercurial non avrà mai bisogno di bloccare 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. + + 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 scrittura al vostro repository per consentire loro di clonarlo o estrarne i cambiamenti, ma saranno sufficienti i permessi di lettura. (Questa non è 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.) + + 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.) + + + Accesso sicuro al dirstate + + Come con i dati di revisione, Mercurial non blocca il file di dirstate per leggerlo, ma acquisisce un blocco solo per modificarlo. Per evitare la possibilità di leggere una copia parzialmente modificata di un file di dirstate, Mercurial scrive su un file con un nome unico nella stessa directory del file di dirstate, poi cambia il nome del file temporaneo a dirstate in maniera atomica. In questo modo si garantisce che il file chiamato dirstate sia sempre completo e mai parzialmente modificato. + + + + + Evitare le operazioni di seek + + 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. + + 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. + + Mercurial adotta anche una strategia copy-on-write per clonare un repository su disco locale. Invece di copiare ogni file di revlog dal vecchio repository al nuovo, utilizza collegamenti fisici per indicare che due nomi puntano allo stesso file. 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. + + Alcuni sviluppatori di sistemi per il controllo di revisione hanno fatto notare che la creazione di una copia privata completa di un file non usa 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 facilità nell'uso quotidiano. + + + + Altre informazioni contenute nel dirstate + + 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 efficientemente 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. + + Quando utilizzate esplicitamente hg add, hg remove, hg rename, o hg copy su un file, Mercurial aggiorna il dirstate in modo che sappia cosa fare con quel file quando effettuate un commit. + + Il dirstate aiuta Mercurial a controllare in maniera efficiente lo stato dei file in un repository. + + + + 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 registrata 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. + + + 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. + + + + Memorizzare le dimensioni e la data di ultima modifica riduce drammaticamente il numero di operazioni di lettura che Mercurial deve effettuare quando invochiamo comandi come hg status. Da questo stratagemma deriva un notevole miglioramento delle prestazioni. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch05-daily.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch05-daily.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,415 @@ + + + L'uso quotidiano di Mercurial + + + Aggiungere file a un repository Mercurial + + Mercurial lavora solo con i file che gli dite di gestire nel vostro repository. Il comando hg status vi dirà quali sono i file che Mercurial non conosce, usando un ? per mostrare questi file. + + Per dire a Mercurial di tenere traccia di un file, usate il comando hg add. Una volta che avete aggiunto un file, la voce per quel file nell'elenco visualizzato da hg status cambia da ? ad A. + + &interaction.daily.files.add; + + Dopo aver eseguito hg commit, i file che avete aggiunto prima dell'inserimento non verranno più elencati dal comando hg status, perché il comportamento predefinito di hg status è quello di segnalarvi solo i file interessanti 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.) + + 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. + + + Designazione esplicita o implicita dei file + + Se passate un nome di una directory a un comando, ogni comando Mercurial interpreterà opportunamente questa azione come la richiesta di operare su ogni file in questa directory e nelle sue sottodirectory. + + &interaction.daily.files.add-dir; + + 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 miofile.txt nell'esempio precedente. + + 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. + + Tuttavia, quando implichiamo i nomi dei file dando il nome di una directory, Mercurial compie il passo aggiuntivo di stampare il nome di ogni file su cui agisce. Questo rende più chiaro ciò che sta succedendo e riduce la probabilità di una sorpresa sgradita e silenziosa. La maggior parte dei comandi Mercurial si comporta in questo modo. + + + + Mercurial registra i file, non le directory + + Mercurial non tiene traccia delle informazioni sulle directory, ma tiene traccia del percorso di un file. Prima di creare un file, crea tutte le directory mancanti che ne compongono il percorso. Dopo che ha cancellato un file, cancella ogni directory vuota che faceva parte del percorso del file cancellato. Questa sembra una distinzione irrilevante, ma ha una conseguenza pratica di secondaria importanza: Mercurial non vi permette di rappresentare una directory completamente vuota. + + Le directory vuote sono raramente utili e ci sono soluzioni non invadenti che potete usare per ottenere un effetto appropriato. Quindi, gli sviluppatori di Mercurial hanno deciso che la complessità che sarebbe stata richiesta per gestire le directory vuote non valesse il limitato beneficio che questa caratteristica avrebbe portato. + + Se avete bisogno di una directory vuota nel vostro repository, ci sono alcuni modi per ottenerla. Uno dei modi possibili è quello di creare una directory e usare hg add per aggiungere un file nascosto a quella directory. Sui sistemi di tipo Unix, ogni file il cui nome comincia con un punto (.) viene considerato nascosto dalla maggior parte dei comandi e delle applicazioni con interfaccia grafica. Questo approccio è illustrato qui di seguito. + + &interaction.daily.files.hidden; + + Un altro modo per soddisfare il bisogno di una directory vuota è semplicemente quello di farla creare al vostro programma automatico di assemblaggio del progetto nel momento in cui ne avete bisogno. + + + + + Come rimuovere un file dal repository + + Una volta che avete deciso che un file non appartiene più al vostro repository, usate il comando hg remove. 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 R nell'elenco prodotto da hg status. + + &interaction.daily.files.remove; + + Dopo che avete rimosso un file tramite hg remove, Mercurial non terrà più traccia di quel file anche se ricreate un file con lo stesso nome nella vostra directory di lavoro. Se ricreate davvero un file con lo stesso nome e volete che Mercurial registri il nuovo file, usate semplicemente hg add. Mercurial saprà che il nuovo file non è in alcun modo legato al vecchio file con lo stesso nome. + + + La rimozione di un file non ha effetti sulla sua cronologia. + + È importante capire che la rimozione di un file ha solo due effetti. + + Cancella la versione corrente del file dalla directory di lavoro. + + Induce Mercurial a smettere di monitorare i cambiamenti del file dal commit successivo in poi. + + La rimozione di un file non altera la cronologia del file in alcun modo. + + Se aggiornate la directory di lavoro a un changeset che era stato inserito quando Mercurial stava ancora tenendo traccia del file che più tardi avete rimosso, il file riapparirà nella directory di lavoro con i contenuti che aveva quando avete inserito quel changeset. Se poi aggiornate la directory di lavoro a un changeset successivo in cui il file è stato rimosso, Mercurial cancellerà ancora una volta il file dalla directory di lavoro. + + + + File mancanti + + Mercurial considera mancante un file che avete cancellato senza usare hg remove. Un file mancante viene rappresentato con ! nell'elenco mostrato da hg status. Di solito, i comandi Mercurial non agiscono mai sui file mancanti. + + &interaction.daily.files.missing; + + Se il vostro repository contiene un file che hg status riporta come mancante, e volete che il file rimanga assente, potete eseguire hg remove in qualsiasi momento, per dire a Mercurial che volevate effettivamente rimuovere il file. + + &interaction.daily.files.remove-after; + + D'altra parte, se avete cancellato il file mancante per errore, passate al comando hg revert il nome del file da recuperare e il file riapparirà senza alcun cambiamento. + + &interaction.daily.files.recover-missing; + + + + Digressione: perché dire esplicitamente a Mercurial di rimuovere un file? + + 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 hg commit e avrebbe smesso di monitorarlo. In pratica, questo modo di operare rendeva troppo facile rimuovere accidentalmente un file senza accorgersene. + + + + Utile scorciatoia&emdash;aggiungere e rimuovere i file in un unico passo + + Mercurial fornisce il comando combinato hg addremove per aggiungere i file non ancora registrati e segnare i file mancanti come rimossi. + + &interaction.daily.files.addremove; + + Il comando hg commit offre anche un'opzione che effettua la stessa operazione di aggiunta-e-rimozione, immediatamente seguita da un commit. + + &interaction.daily.files.commit-addremove; + + + + + Copiare i file + + Mercurial fornisce un comando hg copy 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. + + + I risultati di una copia durante un'unione + + Quello che succede durante un'unione è che i cambiamenti seguono la copia. Per illustrare al meglio cosa questo significa, creiamo un esempio. Cominceremo con il solito piccolo repository che contiene un singolo file. + + &interaction.daily.copy.init; + + Abbiamo bisogno di fare alcune modifiche in parallelo, in modo da avere due cambiamenti da unire tra loro. Quindi cloniamo il nostro repository. + + &interaction.daily.copy.clone; + + Tornando al nostro repository iniziale, usiamo il comando hg copy per fare una copia del primo file che abbiamo creato. + + &interaction.daily.copy.copy; + + Se successivamente osserviamo il risultato del comando hg status, il file copiato appare come un normale file aggiunto. + + &interaction.daily.copy.status; + + Ma se passiamo l'opzione al comando hg status, otterremo un'altra riga nell'elenco stampato: questo è il file da cui il nostro file appena aggiunto è stato copiato. + + &interaction.daily.copy.status-copy; + + Ora, tornando al repository che abbiamo clonato, apportiamo un cambiamento in parallelo. Aggiungeremo una riga al contenuto del file originale che abbiamo creato. + + &interaction.daily.copy.other; + + Ora abbiamo un file modificato in questo repository. Quando estraiamo i cambiamenti dal primo repository e uniamo le due teste, Mercurial propagherà i cambiamenti che abbiamo apportato localmente a file nella sua copia nuovo-file. + + &interaction.daily.copy.merge; + + + + Perché i cambiamenti dovrebbero seguire le copie? + + 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. + + Prima di tutto, ricordatevi che questa propagazione avviene solamente durante un'unione. Quindi se usate hg copy su un file e in seguito modificate il file originale nel normale corso del vostro lavoro, non accadrà nulla. + + La seconda cosa da sapere è che le modifiche si propagheranno alla copia solo se il changeset da cui state incorporando le modifiche non ha ancora visto la copia. + + Il motivo per cui Mercurial si comporta in questo modo è il seguente. Diciamo che io correggo un bug importante in un file sorgente e inserisco i miei cambiamenti nel repository. Nel frattempo, voi avete deciso di eseguire hg copy per fare una copia del file nel vostro repository, senza sapere del bug o aver visto la correzione, e avete cominciato a lavorare sulla vostra copia del file. + + Se dopo aver estratto e incorporato le mie modifiche Mercurial non 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 rimarrebbe nella vostra copia del file. + + 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 è l'unico sistema di controllo di revisione che propaga i cambiamenti verso le copie in questo modo. + + 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. + + + + Come <emphasis>evitare</emphasis> che i cambiamenti seguano una copia + + Se per qualche ragione decidete che questa faccenda di propagare automaticamente i cambiamenti verso le copie non fa per voi, utilizzate il normale comando per la copia di file fornito dal vostro sistema (cp per i sistemi di tipo Unix) per effettuare la copia di un file, poi aggiungete a mano la nuova copia invocando hg add. Prima di farlo, però, rileggete la e prendete una decisione informata sulla validità di questo comportamento nel vostro caso specifico. + + + + Il comportamento del comando <command role="hg-cmd">hg copy</command> + + Quando usate il comando hg copy, 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 hg copy 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.) + + Il comando hg copy agisce in maniera simile al comando Unix cp (potete usare l'alias hg cp se preferite). Dobbiamo fornirgli due o più argomenti, di cui l'ultimo viene trattato come destinazione e tutti gli altri vengono trattati come sorgenti. + + Se invocate hg copy con un singolo file come sorgente e la destinazione non esiste, il comando crea un nuovo file con quel nome. + + &interaction.daily.copy.simple; + + Se la destinazione è una directory, Mercurial copia le sorgenti in quella directory. + + &interaction.daily.copy.dir-dest; + + Copiare una directory è un'operazione ricorsiva e preserva la struttura delle directory della sorgente. + + &interaction.daily.copy.dir-src; + + Se la sorgente e la destinazione sono entrambe directory, l'albero della sorgente viene ricreato nella directory di destinazione. + + &interaction.daily.copy.dir-src-dest; + + Come con il comando hg remove, se copiate un file manualmente e poi volete informare Mercurial di aver copiato il file, usate semplicemente l'opzione di hg copy. + + &interaction.daily.copy.after; + + + + + Rinominare i file + + È molto più comune aver bisogno di rinominare un file piuttosto che aver bisogno di copiarlo. La ragione per cui ho discusso il comando hg copy prima di parlare di come rinominare i file è che Mercurial tratta un cambiamento di nome essenzialmente nello stesso modo di una copia. Perciò, se sapete cosa fa Mercurial quando copiate un file, sapete anche cosa aspettarvi quando rinominate un file. + + Quando usate il comando hg rename, Mercurial crea una copia del file originale, poi lo cancella e segnala il file come rimosso. + + &interaction.daily.rename.rename; + + Il comando hg status mostra la nuova copia del file come aggiunta e il file da cui è stata effettuata la copia come rimosso. + + &interaction.daily.rename.status; + + Come accade per i risultati del comando hg copy, dobbiamo usare l'opzione del comando hg status per vedere che Mercurial considera il file aggiunto come una copia del file originale ora rimosso. + + &interaction.daily.rename.status-copy; + + Come con hg remove e hg copy, potete usare l'opzione per informare Mercurial del cambiamento di nome dopo che il fatto è avvenuto. Nella maggior parte degli altri aspetti, il comportamento del comando hg rename e le opzioni che accetta sono simili a quelli del comando hg copy. + + Se avete familiarità con la riga di comando Unix, sarete felici di sapere che il comando hg rename può essere invocato come hg mv. + + + Rinominare i file e unire i cambiamenti + + 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. + + 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 funzioni e basta ma in realtà non tutti i sistemi di controllo di revisione lo fanno.) + + Sebbene la propagazione dei cambiamenti alle copie sia una funzione che potreste approvare dicendo sì, questo potrebbe essere utile, deve essere chiaro che propagare i cambiamenti ai file rinominati è assolutamente importante. Senza questo meccanismo, i cambiamenti a un file si potrebbero perdere con troppa facilità quando il file viene rinominato. + + + + Cambiamenti di nome divergenti e unioni + + Il caso dei nomi divergenti si verifica quando due sviluppatori cominciano con un file&emdash;chiamiamolo foo&emdash;nei loro rispettivi repository. + + &interaction.rename.divergent.clone; + + Anna cambia il nome del file a bar. + + &interaction.rename.divergent.rename.anne; + + Nel frattempo, Bruno lo rinomina quux. (Ricordatevi che hg mv è un alias di hg rename.) + + &interaction.rename.divergent.rename.bob; + + 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. + + Cosa pensate che dovrebbe accadere quando Anna e Bruno uniscono il loro lavoro? L'effettivo comportamento di Mercurial è quello di preservare sempre entrambi i nomi quando unisce changeset che contengono cambiamenti di nome divergenti. + + &interaction.rename.divergent.merge; + + Notate che, sebbene Mercurial vi avverta del cambiamento di nome divergente, lascia che siate voi a riconciliare la divergenza dopo l'unione. + + + + Cambiamenti di nome convergenti e unioni + + Un altro tipo di conflitto tra i cambiamenti di nome avviene quando due persone rinominano differenti file sorgente alla stessa destinazione. In questo caso, Mercurial esegue l'unione normalmente e lascia che siate voi a guidarlo verso una risoluzione ragionevole. + + + + Altri casi particolari legati ai nomi + + 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 problema 29. + + &interaction.issue29.go; + + + + + + Rimediare agli errori + + Mercurial possiede alcuni comandi utili che vi aiuteranno a rimediare a diversi errori comuni. + + Il comando hg revert vi permette di annullare i cambiamenti che avete apportato alla vostra directory di lavoro. Per esempio, se avete aggiunto un file invocando hg add per errore, vi basta eseguire hg revert con il nome del file che avete aggiunto e il file non verrà toccato in alcun modo né sarà più considerato per essere aggiunto da Mercurial. Potete anche usare hg revert per disfarvi di cambiamenti sbagliati apportati a un file. + + È utile ricordare che il comando hg revert serve per i cambiamenti che non avete ancora inserito. Una volta che avete inserito un cambiamento, se decidete che è stato un errore potete ancora fare qualcosa, sebbene le vostre opzioni siano molto più limitate. + + Per maggiori informazioni sul comando hg revert e dettagli su come trattare i cambiamenti che avete gia inserito, leggete il . + + + + Affrontare unioni complesse + + 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. + + Costruiamoci un semplice esempio di questa eventualità e vediamo come affrontarlo. Cominceremo con un repository contenente un file e lo cloneremo due volte. + + &interaction.ch04-resolve.init; + + In uno dei cloni, modificheremo il file in un modo. + + &interaction.ch04-resolve.left; + + Nell'altro, modificheremo il file in modo differente. + + &interaction.ch04-resolve.right; + + Poi, propagheremo entrambi i cambiamenti nel nostro repository originale. + + &interaction.ch04-resolve.pull; + + Ora ci aspettiamo che il nostro repository contenga due teste. + + &interaction.ch04-resolve.heads; + + Normalmente, se eseguissimo il comando hg merge a questo punto, ci verrebbe presentata un'applicazione grafica tramite la quale riconciliare manualmente le modifiche in conflitto su miofile.txt. Tuttavia, per semplificare le cose ai fini della presentazione, vorremmo invece che l'unione fallisse immediatamente. Ecco un modo in cui possiamo farlo. + + &interaction.ch04-resolve.export; + + Abbiamo chiesto al meccanismo di unione di Mercurial di eseguire il comando false (che, come desideriamo, fallisce immediatamente) se si accorge di non riuscire a risolvere un'unione automaticamente. + + Se ora lanciamo hg merge, il comando dovrebbe fermarsi e riportare un fallimento. + + &interaction.ch04-resolve.merge; + + Se anche non avessimo notato che l'unione è fallita, Mercurial eviterà di farci accidentalmente inserire nel repository i risultati di un'unione fallita. + + &interaction.ch04-resolve.cifail; + + In questo caso, hg commit fallisce e ci suggerisce di usare il comando hg resolve, che noi ancora non conosciamo. Come al solito, hg help resolve stamperà una pratica sinossi. + + + Gli stati di risoluzione di un file + + 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. + + + + Un file risolto è stato unito con successo, o automaticamente da Mercurial o con un intervento umano. + + + Un file irrisolto non è stato unito con successo e necessita di ulteriori attenzioni. + + + + Se Mercurial vede un qualsiasi file nello stato irrisolto dopo un'unione, considera fallita l'unione. Fortunatamente, non abbiamo bisogno di ricominciare l'intera unione da zero. + + L'opzione o del comando hg resolve mostra lo stato di ogni file coinvolto in un'unione. + + &interaction.ch04-resolve.list; + + Nell'elenco stampato da hg resolve, un file risolto è contrassegnato con una R mentre un file irrisolto è contrassegnato con una U. Se un file qualsiasi viene elencato con una U, sappiamo che un tentativo di inserire i risultati dell'unione nel repository andrà incontro al fallimento. + + + + Risolvere un'unione di file + + Abbiamo diverse opzioni per far passare un file dallo stato irrisolto a quello risolto. Quella di gran lunga più comune consiste nell'eseguire nuovamente hg resolve. 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 o per riprovare a unire tutti i file irrisolti. + + Mercurial ci permette anche di modificare direttamente lo stato di risoluzione di un file. Possiamo contrassegnare manualmente un file come risolto usando l'opzione o come irrisolto usando l'opzione . 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. + + + + + Formati di diff più utili + + Il formato predefinito del testo stampato dal comando hg diff è compatibile all'indietro con il normale comando diff, ma questo presenta alcuni svantaggi. + + Considerate il caso in cui si utilizzi hg rename per rinominare un file. + + &interaction.ch04-diff.rename.basic; + + Il risultato di hg diff mostrato qui sopra offusca il fatto che abbiamo semplicemente rinominato un file. Il comando hg diff accetta l'opzione o per usare un formato di diff più nuovo che presenta queste informazioni in una forma più leggibile. + + &interaction.ch04-diff.rename.git; + + Questa opzione ci viene in aiuto anche in un caso che altrimenti risulterebbe confuso: un file che sembra essere stato modificato secondo hg status, ma per il quale hg diff non stampa nulla. Questa situazione può presentarsi se cambiamo i permessi di esecuzione di un file. + + &interaction.ch04-diff.chmod; + + Il normale comando diff non considera i permessi dei file, perciò la semplice invocazione di hg diff non stampa nulla. Se però utilizziamo l'opzione , il comando ci dice che cos'è realmente accaduto. + + &interaction.ch04-diff.chmod.git; + + + + Quali file gestire e quali file evitare + + 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. + + 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. + + Dato che di solito è impossibile unire due modifiche a un file binario in conflitto tra loro, spesso i sistemi centralizzati forniscono un meccanismo di bloccaggio dei file che permette a un utente di dire sono la sola persona che può modificare questo file. + + Rispetto a un sistema centralizzato, un sistema distribuito di controllo di revisione modifica alcuni dei fattori che guidano le decisioni su quali file gestire e come gestirli. + + Per esempio, un sistema distribuito di controllo di revisione non può, per sua natura, offrire un meccanismo di bloccaggio dei file. Quindi non esiste alcun meccanismo predefinito per evitare che due persone apportino cambiamenti in conflitto a un file binario. Se fate parte di un gruppo in cui diverse persone potrebbero modificare frequentemente i file binari, potrebbe non essere una buona idea impiegare Mercurial&emdash;o un qualsiasi altro sistema distribuito di controllo di revisione&emdash;per gestire quei file. + + Quando memorizza le modifiche a un file, di solito Mercurial 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. + + 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 di 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. + + Anche 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. + + Quindi, ci sono alcune chiare raccomandazioni da fare sui tipi di file ai quali dovete stare molto attenti. + + + + I file che sono molto grandi e incomprimibili, e.g. le immagini ISO dei CD-ROM, renderanno la clonazione attraverso la rete molto lenta semplicemente a causa delle loro dimensioni. + + + I file che cambiano parecchio da una revisione alla successiva potrebbero essere costosi da memorizzare se li modificate frequentemente, e i conflitti causati da modifiche in parallelo a questi file potrebbero essere difficili da risolvere. + + + + + + Realizzare backup e mirror + + 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. + + Usare Mercurial per effettuare backup separati e mirror remoti è piuttosto semplice. Impostate un'attività periodica (e.g. tramite il comando cron) 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. + + Se effettuate un backup tradizionale dei vostri repository principali su nastro o su disco e volete fare il backup di un repository chiamato miorepo, usate il comando hg clone -U miorepo miorepo.bak per creare un clone di miorepo prima di cominciare a registrare i vostri backup. L'opzione evita di popolare la directory di lavoro dopo che la clonazione si è conclusa, dato che sarebbe superfluo e renderebbe più lungo il backup. + + Se poi effettuate il backup di miorepo.bak invece di miorepo, 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. + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch06-collab.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch06-collab.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,637 @@ + + + Collaborare con altre persone + + 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 da adottare. + + + L'interfaccia web di Mercurial + + Mercurial è dotato di una potente interfaccia web che possiede diverse caratteristiche utili. + + 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. + + L'interfaccia web offre ai visitatori anche i feed RSS e Atom dei cambiamenti in un repository. Questo vi permette di abbonarvi a un repository usando il vostro lettore di feed preferito e di venire automaticamente informati sulle attività in quel repository non appena cominciano. 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 servendo il repository. + + 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. + + 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 http://www.selenic.com/repo/hg. + + Se siete interessati a fornire un'interfaccia web ai vostri repository, esistono diversi buoni modi per farlo. + + In un ambiente informale, il modo più facile e veloce di cominciare è quello di usare il comando hg serve, che è particolarmente adatto per offrire un servizio leggero a breve termine. Leggete la più avanti per i dettagli su come usare questo comando. + + 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 http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting. + + 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) e WSGI (acronimo di Web Services Gateway Interface). Leggete la per i dettagli sulle configurazioni di CGI e WSGI. + + + + Modelli di collaborazione + + Con uno strumento adeguatamente flessibile, prendere decisioni sul workflow non è tanto una sfida tecnica quanto una sfida di ingegneria sociale. Mercurial impone poche limitazioni su come potete strutturare il flusso di lavoro in un progetto, quindi sta a voi e al vostro gruppo impostare e procedere con un modello che corrisponda ai vostri particolari bisogni. + + + Fattori da considerare + + 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. + + 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. + + 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. + + + + Anarchia informale + + Non vorrei suggerire che un approccio in cui tutto è permesso sia qualcosa di sostenibile, ma è un modello che è facile da capire e funziona perfettamente in alcune situazioni inusuali. + + Per esempio, molti progetti hanno un gruppo sparso di collaboratori che si incontrano fisicamente solo di rado. Alcuni gruppi preferiscono superare l'isolamento del lavoro a distanza organizzando maratone 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. + + Una maratona o una sessione di programmazione in un locale sono le occasioni perfette per usare il comando hg serve, dato che hg serve non richiede alcuna infrastruttura server elaborata. Potete cominciare a usare hg serve in pochi minuti, leggendo la 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. + + 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 n diversi repository da cui estrarre modifiche. + + + + Un singolo repository centrale + + Per progetti di dimensioni ridotte che stanno migrando da uno strumento centralizzato di controllo di revisione, forse il modo più facile per cominciare è far passare i cambiamenti attraverso un singolo repository centrale condiviso. Questo è anche il più comune mattone da costruzione per schemi di workflow più ambiziosi. + + I collaboratori cominciano clonando una copia di questo repository, potendo estrarne i cambiamenti ogni volta che ne hanno bisogno. Alcuni sviluppatori (forse tutti) hanno il permesso di trasmettere le modifiche al repository quando sono pronte per essere viste da altre persone. + + In questo modello, può ancora aver senso che alcune persone propaghino i cambiamenti direttamente tra loro, senza passare dal repository centrale. Considerate il caso in cui io ho creato una possibile correzione di un bug, ma sono preoccupato che, se la pubblicassi sul repository centrale, tutti gli altri possano successivamente danneggiare i propri alberi nel momento in cui la estraggono. Per ridurre il danno potenziale, posso chiedervi di clonare temporaneamente il mio repository in un vostro repository privato e di collaudare la correzione. Questo ci permette di rimandare la pubblicazione di cambiamenti potenzialmente pericolosi fino a quando non hanno subìto una ragionevole verifica. + + Se un gruppo sta mantenendo il repository sui propri server in questo tipo di scenario, di solito i membri useranno il protocollo ssh per trasmettere in sicurezza i cambiamenti al repository centrale, come documentato nella . Di solito, viene anche pubblicata una copia del repository in sola lettura via HTTP, come nella . Pubblicare via HTTP soddisfa le necessità di chi non ha accesso in scrittura e di chi preferisce usare un browser per navigare la cronologia del repository. + + + + Un repository centrale su un servizio di hosting + + Una caratteristica meravigliosa dei servizi di hosting come Bitbucket è 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. + + 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. + + In più, un buon servizio di hosting permetterà alle persone di comunicare tra loro, per esempio per segnalare che questo albero contiene modifiche pronte per la tua revisione. + + + + Lavorare con più rami + + 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 manutenzione 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 ramo (in inglese, branch) per indicare una di queste direzioni leggermente differenti in cui lo sviluppo sta procedendo. + + Mercurial è particolarmente adatto a gestire un certo numero di rami paralleli ma non identici. Ogni direzione di sviluppo 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. + + Ecco un esempio di come questo processo può funzionare in pratica. Diciamo che avete un ramo principale su un server centrale. + + &interaction.branching.init; + + Altre persone lo clonano, effettuano modifiche locali, le collaudano e le trasmettono indietro. + + Una volta che il ramo principale raggiunge la milestone (letteralmente, pietra miliare) di una release, potete usare il comando hg tag per dare un nome permanente alla revisione di milestone. + + &interaction.branching.tag; + + Diciamo che alcune modifiche esterne vengono effettuate sul ramo principale. + + &interaction.branching.main; + + Grazie all'etichetta registrata sulla milestone, chi clonerà quel repository in futuro potrà usare hg update per ottenere una copia della directory di lavoro nello stato esatto in cui si trovava quando quella revisione etichettata è stata inserita. + + &interaction.branching.update; + + In più, immediatamente dopo che il ramo principale è stato etichettato, possiamo clonare il ramo principale sul server creando un nuovo ramo stabile, anche quello sul server. + + &interaction.branching.clone; + + Se abbiamo bisogno di fare una modifica al ramo stabile, possiamo clonare quel repository, fare i nostri cambiamenti, effettuarne il commit, e trasmetterli indietro a quello stesso repository. + + &interaction.branching.stable; + + Dato che i repository Mercurial sono indipendenti e che Mercurial non sposta automaticamente i cambiamenti da un repository a un altro, il ramo principale e quello stabile sono isolati tra loro. I cambiamenti che abbiamo fatto al ramo principale non filtreranno verso il ramo stabile e viceversa. + + Vorremo spesso che tutte le nostre correzioni di bug nel ramo stabile compaiano anche nel ramo principale. Piuttosto che riscrivere una correzione sul ramo principale, possiamo semplicemente estrarre i cambiamenti dal ramo stabile e unirli a quello principale, così sarà Mercurial a introdurre per noi quelle correzioni di bug. + + &interaction.branching.merge; + + 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. + + + + Rami di funzione + + Per progetti di dimensioni più grandi, un modo efficace di gestire i cambiamenti è quello di dividere un gruppo in piccoli sottogruppi. Ogni sottogruppo gestisce un proprio ramo condiviso, clonato da un singolo ramo principale usato dall'intero progetto. Le persone che lavorano su un singolo ramo sono tipicamente piuttosto isolate dagli sviluppi che accadono negli altri rami. + +

+ Rami di funzione + + + XXX add text + + + + Quando si ritiene che una funzione particolare sia in una forma appropriata, qualche membro del sottogruppo di quella funzione estrae i cambiamenti dal ramo principale e li unisce al ramo della funzione, poi trasmette le modifiche indietro al ramo principale. + + + + Il treno delle release + + L'organizzazione di alcuni progetti può ricordare quella di un treno: le release sono fissate a intervalli di alcuni mesi e includono tutte le funzioni che sono pronte quando il treno è pronto a partire. + + 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. + + + + Il modello del kernel di Linux + + 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 git, 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. + + Al centro della comunità siede Linus Torvalds, il creatore di Linux. Linus pubblica un singolo repository di sorgenti che è considerato il ramo autoritativo 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. + + Linus ha un certo numero di luogotenenti di fiducia. 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 manutentori 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. + + 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 stabili 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. + + Questo modello ha due caratteristiche importanti. La prima è quella di essere a sola estrazione. 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. + + 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 buone 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. + + 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. + + 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. + + + + Collaborazione in sola lettura o in scrittura condivisa + + 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 meglio di un modello in cui più persone possono trasmettere modifiche a un repository condiviso. + + 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 costruire il vostro approccio al di sopra di quel modello (per esempio, applicando una patch a mano). + + Un buon sistema distribuito di controllo di revisione supporterà entrambi i modelli. Voi e i vostri collaboratori poterete quindi strutturare il modo di lavorare insieme sulla base dei vostri bisogni e delle vostre preferenze, non delle acrobazie a cui vi costringono gli strumenti. + + + Dove la collaborazione incontra la gestione dei rami + + Una volta che voi e il vostro gruppo avete configurato qualche repository condiviso e cominciato a propagare cambiamenti avanti e indietro tra i repository locali e quelli condivisi, comincerete ad affrontare una sfida correlata ma leggermente differente: quella di gestire le diverse direzioni in cui il vostro gruppo potrebbe muoversi contemporaneamente. Anche se questa materia è intimamente legata al modo in cui il vostro gruppo collabora, è abbastanza densa da meritare una trattazione separata, nel . + + + + + Il lato tecnico della condivisione + + Il resto di questo capitolo è dedicato alle questioni tecniche relative alla condivisione dei cambiamenti con i vostri collaboratori. + + + + Condivisione informale con <command role="hg-cmd">hg serve</command> + + Il comando hg serve 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. + + Invocate hg serve 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 hg serve in esecuzione su un computer portatile somiglierà probabilmente a qualcosa come http://mio-portatile.local:8000/. + + Il comando hg serve non è un server web di uso generale, ma può fare solo due cose: + + consentire alle persone di usare il proprio browser web per navigare la cronologia del repository che sta servendo; + + comunicare attraverso il protocollo di rete di Mercurial, in modo che le persone possano usare comandi come hg clone o hg pull su quel repository. + + In particolare, hg serve non permetterà agli utenti di modificare il vostro repository, perché è stato pensato per un uso in sola lettura. + + Se avete appena cominciato a lavorare con Mercurial, non c'è nulla che vi impedisca di usare hg serve per servire i dati di un repository sul vostro computer, poi usare comandi come hg clone, hg incoming, 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. + + + Alcune cose da tenere a mente + + Dato che hg serve 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. + + Il comando hg serve 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 hg serve in esecuzione, la seconda cosa che dovreste fare (dopo aver verificato che stiano usando l'URL corretto) è controllare la configurazione del vostro firewall. + + Per default, hg serve 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 . + + Normalmente, quando hg serve 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 hg serve con l'opzione . + + + + + Usare il protocollo di Shell Sicura (ssh) + + Potete estrarre e trasmettere cambiamenti in sicurezza attraverso la rete usando il protocollo di Shell Sicura (ssh). Per usarlo con successo, potreste dover sistemare la configurazione sia del lato client che del lato server. + + Se non avete familiarità con ssh, sappiate che è il nome di un comando e di un protocollo di rete che vi permette di comunicare in sicurezza con un altro computer. Per usarlo con Mercurial, dovrete impostare uno o più account utente su un server in maniera che gli utenti remoti possano entrare ed eseguire comandi. + + (Se avete familiarità con ssh, probabilmente una parte del materiale che segue vi sembrerà elementare.) + + + Come leggere e scrivere URL ssh + + Un URL ssh tende ad avere la forma seguente: + ssh://bos@hg.serpentine.com:22/hg/libro + + La parte ssh:// dice a Mercurial di usare il protocollo ssh. + + Il componente bos@ indica qual è il nome utente con cui accedere al server. Potete ometterlo se il nome utente remoto è uguale al vostro nome utente locale. + + hg.serpentine.com rappresenta il nome del server a cui accedere. + + :22 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 non state usando la porta 22. + + Il resto dell'URL è il percorso locale del repository sul server. + + + 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. + + Mercurial tratta il percorso di un repository sul server come se fosse relativo alla directory personale dell'utente remoto. Per esempio, se l'utente foo possiede una directory personale /home/foo sul server, allora un URL ssh che contiene un percorso bar si riferisce in realtà alla directory /home/foo/bar. + + 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 altroutente) in questo modo. + ssh://server/~altroutente/hg/repo + + E se proprio volete specificare un percorso assoluto sul server, iniziate il percorso con due caratteri di slash, come in questo esempio. + ssh://server//percorso/assoluto + + + + Trovare un client ssh per il vostro sistema + + Quasi tutti i sistemi di tipo Unix includono un'installazione di OpenSSH. Se state usando uno di questi sistemi, eseguite which ssh per scoprire se il comando ssh è installato (di solito si trova nella directory /usr/bin). Nell'improbabile eventualità in cui non sia presente, date un'occhiata alla documentazione del vostro sistema per capire come installarlo. + + Su Windows, il pacchetto TortoiseHg comprende una versione dell'eccellente comando plink, realizzato da Simon Tatham, che non dovrebbe avere bisogno di ulteriori configurazioni. + + + + Generare una coppia di chiavi + + Per evitare di dover ripetutamente digitare una password ogni volta che avete bisogno di usare il vostro client ssh, vi suggerisco di generare una coppia di chiavi. + + + Le coppie di chiavi non sono obbligatorie + + Mercurial non sa nulla di autenticazione ssh o coppie di chiavi. Se volete, potete tranquillamente ignorare questa sezione e quella che segue fino a quando non vi stancherete di digitare ripetutamente le password ssh. + + + + + Su un sistema di tipo Unix, il comando ssh-keygen dovrebbe servire allo scopo. + + + Per generare una coppia di chiavi su Windows, se state usando TortoiseHg potreste dover scaricare il comando puttygen dal sito web di PuTTY. Leggete la documentazione di puttygen per i dettagli su come usare il comando. + + + + Quando generate una coppia di chiavi, di solito è altamente 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.) + + 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 authorized_keys nella directory .ssh dell'utente. + + Su un sistema di tipo Unix, la vostra chiave pubblica avrà una estensione .pub. Se state usando puttygen 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 authorized_keys. + + + Usare un agente di autenticazione + + 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 (e.g. ogni volta che estraete o trasmettete cambiamenti). + + 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. + + + + Su sistemi di tipo Unix, l'agente è chiamato ssh-agent e spesso viene eseguito automaticamente quando entrate nel sistema. Dovrete usare il comando ssh-add per aggiungere una nuova passphrase alla memoria dell'agente. + + + Su Windows, se state usando TortoiseHg, il comando pageant funziona come un agente. Come con puttygen, avrete bisogno di scaricare pageant dal sito web di PuTTY e di leggere la sua documentazione. Il comando pageant aggiunge alla vostra area di notifica un'icona che vi permetterà di gestire le passphrase memorizzate. + + + + + + Configurare adeguatamente il server + + Dato che ssh può essere complicato da configurare se non siete esperti, un certo numero di cose potrebbero andare storte. Aggiungete Mercurial a tutto questo, e le possibilità di fare confusione aumenteranno ulteriormente. La maggior parte di questi potenziali problemi si presenta sul lato server, non sul lato client. La buona notizia è che, una volta che avete una configurazione funzionante, di solito continuerà a funzionare indefinitamente. + + Prima di provare a usare Mercurial per comunicare con un server ssh, è preferibile che vi assicuriate di poter usare i normali comandi ssh o putty per contattare il server. Se incontrate problemi usando direttamente questi comandi, Mercurial sicuramente non funzionerà e quel che è peggio è che 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 prima di preoccuparvi di eventuali problemi con Mercurial. + + 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 ssh o putty 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. + + Se l'errore è di tipo connection refused (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. + + Se l'errore è di tipo no route to host (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. + + Se l'errore è di tipo permission denied (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. + + 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. + + Se state usando un agente di autenticazione sul lato client per memorizzare le passphrase per le vostre chiavi, dovreste essere in grado di accedere al server senza che vi vengano chieste una passphrase o una password. Se vi viene comunque richiesta una passphrase, ecco alcune possibili cause. + + Potreste aver dimenticato di usare ssh-add o pageant per memorizzare la passphrase. + + Potreste aver memorizzato la passphrase per la chiave sbagliata. + + Se vi viene richiesta la password per l'utente remoto, ecco altri possibili cause. + + La directory personale dell'utente o la sua directory .ssh potrebbero avere permessi eccessivamente liberali. Come risultato, il demone ssh non si fiderà dei contenuti del file authorized_keys e quindi non lo leggerà. Per esempio, una directory personale o una directory .ssh con il permesso di scrittura di gruppo abilitato causerà spesso questo effetto. + + Il file authorized_keys 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à. + + + 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. + ssh mioserver date + + 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, o peggio, potrebbero potenzialmente causare problemi durante l'esecuzione remota dei comandi Mercurial. Mercurial prova a scoprire e ignorare questi messaggi durante le sessioni ssh 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 tty -s.) + + 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: + + ssh mioserver hg version + + Se vedete un messaggio di errore invece del normale risultato di hg version, di solito questo accade perché non avete installato Mercurial in /usr/bin. Se questo è il caso, non preoccupatevi: non avete bisogno di farlo. Ma dovreste controllare alcuni possibili problemi. + + Mercurial è veramente installato sul server? So che sembra una cosa ovvia, ma vale la pena di controllare! + + Forse il percorso di ricerca della vostra shell (solitamente impostato attraverso la variabile d'ambiente PATH) è semplicemente configurato male. + + Forse la vostra variabile d'ambiente PATH è impostata per puntare all'ubicazione dell'eseguibile hg 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. + + La variabile d'ambiente PYTHONPATH 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. + + + Se riuscite a eseguire hg version 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 ospitato da quel nome utente su quel server. Se a questo punto incontrate qualche problema con Mercurial e ssh, provate a usare l'opzione per avere un'immagine più chiara di quello che sta succedendo. + + + Usare la compressione con ssh + + 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 non richiedere la compressione. + + 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. + + Sia ssh che plink richiedono l'opzione per attivare la compressione. Potete facilmente modificare il vostro file ~/.hgrc 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 ssh sui sistemi di tipo Unix. + [ui] +ssh = ssh -C + + Se usate ssh su un sistema di tipo Unix, potete configurarlo per usare sempre la compressione quando comunicate con il vostro server. Per fare questo, modificate il vostro file .ssh/config (che potrebbe anche non esistere) come segue. + + Host hg + Compression yes + HostName hg.example.com + + Questo definisce l'alias hg per il nome della macchina. Quando usate l'alias sulla riga di comando ssh o in un URL ssh di Mercurial, ssh si connetterà a hg.example.com 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.. + + + + + Servire i dati attraverso HTTP usando CGI + + 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. + + A seconda di quanto siete ambiziosi, configurare l'interfaccia CGI di Mercurial può portarvi via da pochi minuti a diverse ore. + + 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. + + + Si richiede alta sopportazione del dolore + + 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. + + 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. + + + + Lista di controllo per la configurazione di un server web + + Prima di proseguire, prendetevi qualche momento per controllare alcuni aspetti delle impostazioni del vostro sistema. + + + Avete un server web installato? Mac OS X e alcune distribuzioni Linux includono Apache, ma molti altri sistemi potrebbero non avere un server web già installato. + + Se avete un server web installato, è davvero in esecuzione? Sulla maggior parte dei sistemi, anche se un server web è presente, sarà disabilitato per default. + + 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. + + + Se non avete un server web installato e non avete una considerevole esperienza nel configurare Apache, dovreste considerare l'uso del server web lighttpd invece di Apache. Le configurazioni di Apache hanno la reputazione ben meritata di essere complicate e di confondere gli utenti. Mentre Apache è dotato di un numero maggiore di funzioni rispetto a lighttpd, buona parte di queste funzioni non è rilevante per servire repository Mercurial. E lighttpd è innegabilmente molto più facile da affrontare di Apache. + + + + Configurazione CGI di base + + Su sistemi di tipo Unix, di solito gli utenti hanno una sottodirectory con un nome simile a public_html nella propria directory personale da cui possono servire pagine web. Un file chiamato foo in questa directory sarà accessibile tramite un URL della forma http://www.example.com/~nomeutente/foo. + + Per cominciare, prendete lo script hgweb.cgi 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 http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi. + + Dovrete copiare questo script nella vostra directory public_html e assicurarvi che sia eseguibile. + cp .../hgweb.cgi ~/public_html +chmod 755 ~/public_html/hgweb.cgi + L'argomento 755 passato a chmod 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 gruppo e gli altri non siano concessi. Se lasciaste abilitati quei permessi, probabilmente il sottosistema suexec di Apache si rifiuterebbe di eseguire lo script. In effetti, suexec insiste sul fatto che anche la directory in cui risiede lo script non sia modificabile da altri. + chmod 755 ~/public_html + + + Che cosa <emphasis>potrebbe</emphasis> andare storto? + + Una volta che avete copiato lo script CGI al suo posto, aprite un browser web e provate a visitare l'URL http://nomemacchina/~nomeutente/hgweb.cgi, ma 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 che ho creato espressamente per effettuare questo esercizio. + + Il vostro server web potrebbe aver disabilitato le directory di pubblicazione per utente. Se state usando Apache, cercate la direttiva UserDir nel vostro file di configurazione. Se non è presente, o se è presente ma il suo valore è disabled, allora le directory per utente sono disabilitate. Altrimenti, la stringa che segue UserDir è il nome della sottodirectory della vostra directory personale che verrà letta da Apache, per esempio public_html. + + I vostri permessi di accesso ai file potrebbero essere troppo restrittivi. Il server web deve essere in grado di attraversare la vostra directory personale e le directory contenute nella vostra directory public_html, nonché di leggere i file in essa contenuti. Ecco una ricetta veloce per aiutarvi a rendere i vostri permessi più appropriati. + chmod 755 ~ +find ~/public_html -type d -print0 | xargs -0r chmod 755 +find ~/public_html -type f -print0 | xargs -0r chmod 644 + + 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 troppo permissivi. Per esempio, il sottosistema suexec di Apache non eseguirà uno script che può essere modificato dal gruppo o dagli altri. + + 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. + + &ch06-apache-config.lst; + + Se trovate un gruppo Directory simile a questo nella vostra configurazione di Apache, la direttiva da cercare in questo gruppo si chiama Options. Aggiungete ExecCGI alla fine di questa lista, se non è già presente, e riavviate il server web. + + 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. + AddHandler cgi-script .cgi + + 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 mercurial. 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 hgweb.cgi e seguite le indicazioni che trovate per impostare correttamente la vostra variabile d'ambiente PYTHONPATH. + + Infine, otterrete sicuramente un'altra traccia colorata dello stack di esecuzione di Python: questa volta l'interprete si lamenterà di non poter trovare /path/to/repository. Modificate il vostro script hgweb.cgi per sostituire la stringa /path/to/repository con il percorso completo del repository che volete condividere. + + A questo punto, quando provate a ricaricare la pagina, vi si dovrebbe presentare una gradevole vista HTML della cronologia del vostro repository. Whew! + + + + Configurare lighttpd + + Per completare i miei esperimenti, ho provato a configurare il sempre più popolare server web lighttpd per condividere lo stesso repository come appena descritto nel caso di Apache. Avevo già superato tutti i problemi illustrati con Apache, molti dei quali non sono dovuti a uno specifico server. Come risultato, ero piuttosto sicuro che i miei permessi per i file e le directory fossero corretti e che il mio script hgweb.cgi fosse adeguatamente modificato. + + Una volta messo in esecuzione Apache, riuscire a condividere il repository tramite lighttpd è stato un attimo (in altre parole, anche se state provando a usare lighttpd, dovreste leggere la sezione su Apache). Per prima cosa ho dovuto modificare la sezione mod_access del suo file di configurazione per abilitare mod_cgi e mod_userdir, che erano entrambi disabilitati per default sul mio sistema. Poi ho aggiunto alcune righe alla fine del file di configurazione per configurare questi moduli. + userdir.path = "public_html" +cgi.assign = (".cgi" => "" ) + Fatto questo, lighttpd ha funzionato immediatamente. Se avessi configurato lighttpd prima di Apache, mi sarei quasi certamente imbattuto negli stessi problemi di configurazione a livello di sistema incontrati con Apache. Tuttavia, ho trovato lighttpd notevolmente più facile da configurare di Apache, anche se ho usato Apache per più di una decade e questa è stata la mia prima esperienza con lighttpd. + + + + + Condividere più repository con un solo script CGI + + Lo script hgweb.cgi 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 hgwebdir.cgi. + + La procedura per configurare hgwebdir.cgi è solo leggermente più complicata di quella per hgweb.cgi. Per prima cosa, dovete ottenere una copia dello script. Se non ne avete una sottomano, potete scaricala dal repository principale di Mercurial all'indirizzo http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi. + + Dovrete copiare questo script nella vostra directory public_html e assicurarvi che sia eseguibile. + + cp .../hgwebdir.cgi ~/public_html +chmod 755 ~/public_html ~/public_html/hgwebdir.cgi + + Una volta effettuata questa configurazione di base, provando a visitare http://nomemacchina/~nomeutente/hgwebdir.cgi con il vostro browser, dovreste vedere una lista di repository vuota. Se ottenete una finestra bianca o un messaggio di errore, provate a ripercorrere la lista di possibili problemi già vista nella . + + Lo script hgwebdir.cgi si basa su un file di configurazione esterno. Per default, cerca un file chiamato hgweb.config nella stessa directory in cui si trova. Dovrete creare questo file e renderlo leggibile agli altri. Il formato di questo file è simile a quello di un file ini di Windows, riconoscibile dal modulo ConfigParser web:configparser di Python. + + Il modo più facile di configurare hgwebdir.cgi è tramite una sezione chiamata collections. Questo pubblicherà automaticamente tutti i repository contenuti nelle directory che nominate. La sezione dovrebbe somigliare a questa: + [collections] +/mia/radice = /mia/radice + Mercurial la interpreta guardando al nome della directory sul lato destro del segno =, trovando i repository nella gerarchia contenuta in quella directory e usando il testo sul lato sinistro per eliminare il testo corrispondente dai nomi che elencherà effettivamente nell'interfaccia web. I componenti del percorso che rimangono dopo questa eliminazione formano un percorso virtuale. + + Dato l'esempio precedente, se abbiamo un repository il cui percorso locale è /mia/radice/questo/repository, lo script CGI eliminerà la parte /mia/radice iniziale dal nome e pubblicherà il repository con il percorso virtuale questo/repository. Se l'URL per il nostro script CGI è http://nomemacchina/~nomeutente/hgwebdir.cgi, l'URL completo per quel repository sarà http://nomemacchina/~nomeutente/hgwebdir.cgi/questo/repository. + + Se sostituiamo /mia/radice sul lato sinstro di questo esempio con /mia, allora hgwebdir.cgi eliminerà solo /mia dal nome del repository e ci darà il percorso virtuale radice/questo/repository invece di questo/repository. + + Lo script hgwebdir.cgi cercherà i repository ricorsivamente in ogni directory elencata nella sezione collections del suo file di configurazione, ma non navigherà ricorsivamente nei repository che trova. + + Il meccanismo delle collezioni nella sezione collections facilita la pubblicazione di molti repository in modalità spara e dimentica. Dovete impostare lo script CGI e il file di configurazione una volta sola, dopodiché potete pubblicare o ritirare un repository in ogni momento semplicemente spostandolo dentro o fuori dalla gerarchia di directory in cui hgwebdir.cgi è configurato per guardare. + + + Specificare esplicitamente quali repository pubblicare + + In aggiunta al meccanismo basato su collections, lo script hgwebdir.cgi vi consente di pubblicare una lista specifica di repository. Per fare questo, create una sezione paths con un contenuto simile al seguente. + [paths] +repo1 = /mio/percorso/a/qualche/repository +repo2 = /qualche/percorso/a/un/altro + 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. + + Se lo desiderate, potete usare entrambe le sezioni collections e paths contemporaneamente in un unico file di configurazione. + + + Fate attenzione ai percorsi virtuali duplicati + + Se diversi repository hanno lo stesso percorso virtuale, hgwebdir.cgi non segnalerà un errore, ma si comporterà in maniera imprevedibile. + + + + + + Scaricare gli archivi dei sorgenti + + 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. + + Per default, questa funzione è disabilitata. Per abilitarla, dovrete aggiungere un elemento allow_archive alla sezione web del vostro file ~/.hgrc come spiegato in dettaglio nella prossima sezione. + + + Le opzioni di configurazione web + + Le interfacce web di Mercurial (il comando hg serve e gli script hgweb.cgi e hgwebdir.cgi) hanno un certo numero di opzioni di configurazione che potete impostare. Queste opzioni appartengono a una sezione chiamata web. + + allow_archive: 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. + + bz2: un archivio tar, compresso usando la compressione bzip2. Questo formato ha il miglior rapporto di compressione, ma usa più tempo di CPU sul server. + + gz: un archivio tar, compresso usando la compressione gzip. + + zip: un archivio zip, compresso usando la compressione LZW. Questo formato ha il peggior rapporto di compressione, ma è largamente usato nel mondo Windows. + + + Se fornite una lista vuota o se non avete una voce allow_archive, questa funzione sarà disabilitata. Ecco un esempio di come abilitare tutti e tre i formati supportati. + [web] +allow_archive = bz2 gz zip + + allowpull: booleano. Determina se l'interfaccia web permette agli utenti remoti di usare i comandi hg pull e hg clone su questo repository via HTTP. Se impostato a no o a false, solo la parte orientata agli umani dell'interfaccia web sarà disponibile. + + contact: 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 .hg/hgrc del singolo repository, ma può anche avere senso utilizzarla in un file ~/.hgrc globale se tutti i repository hanno un singolo manutentore. + + maxchanges: intero. Il numero massimo predefinito di changeset da visualizzare in una singola pagina web. + + maxfiles: intero. Il numero massimo predefinito di file modificati da visualizzare in una singola pagina web. + + stripes: 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. + + style: controlla il template usato da Mercurial per visualizzare l'interfaccia web. Mercurial include diversi template web. + + + coal è monocromatico. + + + gitweb emula lo stile visivo dell'interfaccia web di git. + + + monoblue usa blu e grigi uniformi. + + + paper è il template predefinito. + + + spartan è stato il template predefinito per lungo tempo. + + + Potete anche specificare un vostro template personalizzato, come vedrete in dettaglio nel . Qui potete vedere come abilitare lo stile gitweb. + [web] +style = gitweb + + templates: percorso. La directory in cui cercare i file di template. Per default, Mercurial li cerca nella directory in cui è stato installato. + + Se state usando hgwebdir.cgi, potete inserire gli elementi di configurazione motd e style nella sezione web del file hgweb.config invece che nel file ~/.hgrc, nel caso lo troviate più conveniente. + + + Opzioni specifiche per un singolo repository + + Alcuni elementi di configurazione della sezione web dovrebbero essere inseriti nel file .hg/hgrc locale di un repository piuttosto che nel file ~/.hgrc globale o di un utente. + + description: stringa. Una stringa di testo libero (ma preferibilmente breve) che descrive i contenuti o lo scopo del repository. + + name: 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. + + + + + Opzioni specifiche per il comando <command role="hg-cmd">hg serve</command> + + Alcuni degli elementi nella sezione web di un file ~/.hgrc possono essere usati solo con il comando hg serve. + + accesslog: percorso. Il nome di un file in cui tenere un registro degli accessi. Normalmente, il comando hg serve scrive queste informazioni sul canale di uscita predefinito, non su un file. Le voci del registro vengono scritte nel formato combinato che è uno standard usato da quasi tutti i server web. + + address: 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. + + errorlog: percorso. Il nome di un file in cui tenere un registro degli errori. Normalmente, il comando hg serve scrive queste informazioni sul canale di uscita predefinito, non su un file. + + ipv6: booleano. Indica se usare il protocollo IPv6. Per default, IPv6 non viene usato. + + port: intero. Il numero di porta TCP su cui il server dovrebbe essere in ascolto. Il numero di porta predefinito è 8000. + + + + + Scegliere il giusto file <filename role="special">~/.hgrc</filename> a cui aggiungere elementi della sezione <literal role="rc-web">web</literal> + + È importante ricordare che un server web come Apache o lighttpd sarà in esecuzione sotto l'identità di un utente diverso dal vostro. Anche gli script CGI eseguiti dal vostro server, come hgweb.cgi, verranno solitamente eseguiti sotto quell'identità. + + Se aggiungete elementi della sezione web al vostro file ~/.hgrc personale, gli script CGI non potranno leggere quel file ~/.hgrc. Quelle impostazioni quindi avranno effetto solo sul comportamento del comando hg serve quando sarete voi a eseguirlo. Per fare in modo che gli script CGI vedano le vostre impostazioni, create un file ~/.hgrc nella directory personale dell'utente la cui identità viene usata per eseguire il vostro server web, oppure aggiungete quelle impostazioni a un file hgrc di sistema. + + + + + + Configurazione di sistema + + 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. + + Se il file /etc/mercurial/hgrc 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 .rc in una directory chiamata /etc/mercurial/hgrc.d e applicherà le impostazioni di configurazione trovate in ognuno di quei file. + + + Rendere Mercurial meno prevenuto + + Un file hgrc 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 .hg/hgrc 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 .hg/hgrc di quel repository. + + Se tutti i membri di uno specifico gruppo Unix fanno parte dello stesso gruppo di sviluppo e dovrebbero 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 hgrc di sistema come il seguente: + + # Salva questo file con un nome tipo /etc/mercurial/hgrc.d/trust.rc +[trusted] +# Fidati di tutte le voci in qualsiasi file hgrc posseduto +# dai gruppi "editors" o "www-data" +groups = editors, www-data + +# Fidati delle voci nei file hgrc posseduti dai seguenti utenti. +users = apache, bobo + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch07-filenames.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch07-filenames.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,215 @@ + + + Nomi di file e corrispondenze di pattern + + Mercurial fornisce meccanismi che vi permettono di lavorare con i nomi dei file in modo coerente ed espressivo. + + + Denominazione semplice dei file + + A livello di implementazione, Mercurial usa un unico meccanismo per gestire i nomi dei file. Tutti i comandi si comportano in maniera uniforme rispetto ai nomi dei file e lavorano nel modo seguente. + + Se indicate esplicitamente nomi di file esistenti sulla riga di comando, Mercurial lavora esattamente con quei file, come vi aspettereste. + + &interaction.filenames.files; + + Quando fornite un nome di directory, Mercurial interpreterà questa azione come la volontà di operare su tutti i file in questa directory e nelle sue sottodirectory. 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. + + &interaction.filenames.dirs; + + + + Eseguire comandi senza nomi di file + + 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. + + La maggior parte dei comandi opererà sull'intera directory di lavoro. Per esempio, questo è quello che fa il comando hg add. + + 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 hg remove senza argomenti. + + + Se questi comportamenti predefiniti non vi soddisfano, è facile aggirarli. Se normalmente un comando opera sull'intera directory di lavoro, potete passargli il nome . per invocarlo solo sulla directory corrente e sulle sue sottodirectory. + + &interaction.filenames.wdir-subdir; + + 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 hg status 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 hg root. + + &interaction.filenames.wdir-relname; + + + + Mercurial vi dice cosa sta succedendo + + L'esempio di hg add 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. + + In questo caso, Mercurial segue il principio della minima sorpresa. Se avete fornito il nome esatto di un file sulla riga di comando, non ha senso ripetervelo. Se Mercurial sta agendo implicitamente su un file, e.g. 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. + + Potete ridurre al silenzio i comandi che si comportano in questo modo usando l'opzione . Potete anche dire loro di stampare il nome di tutti i file, anche quelli che avete nominato esplicitamente, usando l'opzione . + + + + Usare i pattern per identificare i file + + Oltre a lavorare con i nomi di file e directory, Mercurial vi consente di usare i pattern per identificare i file. La gestione dei pattern da parte di Mercurial è espressiva. + + Su sistemi di tipo Unix (Linux, Mac OS X, etc.), di solito è la shell ad occuparsi di trovare le corrispondenze tra i pattern e i nomi dei file. Su questi sistemi, dovete esplicitamente dire a Mercurial che un nome è un pattern. Su Windows, la shell non si occupa di espandere i pattern, quindi Mercurial identificherà automaticamente i nomi che sono pattern e li espanderà per voi. + + Per fornire un pattern al posto di un nome ordinario sulla riga di comando, il meccanismo è semplice: + sintassi:corpodelpattern + Cioè, un pattern viene identificato da una breve stringa di testo che indica il tipo del pattern, seguita dai due punti, seguiti dall'effettivo pattern. + + Mercurial supporta due tipi di sintassi per i pattern. Quello usato più spesso è chiamato glob: è lo stesso tipo di pattern usato dalla shell Unix e dovrebbe essere familiare anche agli utenti del prompt dei comandi di Windows. + + Quando Mercurial effettua la corrispondenza automatica di un pattern su Windows, usa la sintassi glob. Quindi, potete omettere il prefisso glob: su Windows, ma se volete potete anche usarlo tranquillamente. + + La sintassi re è più potente perché vi permette di specificare i pattern usando le espressioni regolari, indicate a volte con il termine regexp. + + Notate che, negli esempi che seguono, farò molta attenzione a racchiudere tutti i miei pattern tra caratteri di apice, in modo che non vengano espansi dalla shell prima che Mercurial li veda. + + + I pattern <literal>glob</literal> sullo stile della shell + + Questa è un'introduzione ai tipi di pattern che potete usare quando state cercando una corrispondenza con un pattern di tipo glob. + + Il carattere * corrisponde a qualsiasi stringa all'interno di una singola directory. + + &interaction.filenames.glob.star; + + Il pattern ** corrisponde a qualsiasi stringa e attraversa i confini delle directory. Non è un simbolo di tipo glob standard su Unix, ma viene accettato da diverse shell Unix popolari ed è molto utile. + + &interaction.filenames.glob.starstar; + + Il pattern ? corrisponde a qualsiasi carattere singolo. + + &interaction.filenames.glob.question; + + Il carattere [ comincia una classe di caratteri. Questo pattern corrisponde a qualsiasi carattere compreso nella classe. La classe viene terminata da un carattere ]. Una classe può contenere molteplici intervalli della forma a-f, che è una abbreviazione per abcdef. + + &interaction.filenames.glob.range; + + Se il primo carattere dopo [ in una classe di caratteri è !, si ottiene l'effetto di negare la classe, facendola corrispondere a qualsiasi carattere non compreso nella classe. + + Un carattere { comincia un gruppo di sottopattern, che trova una corrispondenza se un qualsiasi sottopattern nel gruppo trova una corrispondenza. Il carattere , separa i sottopattern e il carattere } termina il gruppo. + + &interaction.filenames.glob.group; + + + Fate attenzione! + + Non dimenticate che, se volete trovare corrispondenze a un pattern in qualsiasi directory, non dovreste usare il simbolo *, dato che questo troverà corrispondenze solo in una directory, ma dovreste usare il simbolo **. Questo piccolo esempio illustra la differenza tra i due. + + &interaction.filenames.glob.star-starstar; + + + + + Corrispondenze di espressioni regolari con i pattern <literal>re</literal> + + Mercurial accetta la stessa sintassi per le espressioni regolari che viene usata dal linugaggio di programmazione Python (usa internamente il motore di regexp di Python). Questa sintassi è basata su quella del linguaggio Perl, che è il dialetto più popolare attualmente in uso (è anche utilizzato in Java, per esempio). + + 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. + + 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 foo, se volete una corrispondenza con i file in questa directory il vostro pattern dovrà cominciare con foo/. + + Una cosa da notare, se avete familiarità con le regexp in stile Perl, è che le espressioni regolari di Mercurial sono vincolate, 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 .*. + + + + + Filtrare i file + + Mercurial non vi fornisce solo una varietà di modi per specificare i file, ma vi permette di vagliare ulteriormente quei file usando i filtri. I comandi che lavorano con i nomi dei file accettano due opzioni di filtraggio. + + L'opzione , o , vi permette di specificare un pattern a cui i nomi dei file devono corrispondere per poter essere elaborati. + + L'opzione , o , vi fornisce un modo per evitare di elaborare i file che corrispondono a questo pattern. + + Potete passare più opzioni e 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). + + Potete interpretare un filtro come una richiesta di elaborare solo i file che corrispondono a questo filtro. + + &interaction.filenames.filter.include; + + L'interpretazione migliore del filtro è quella di una richiesta di elaborare solo i file che non corrispondono a questo pattern. + + &interaction.filenames.filter.exclude; + + + + Ignorare permanentemente file e directory indesiderate + + Quando create un nuovo repository, è possibile che nel tempo cresca fino a contenere file che non dovrebbero essere gestiti da Mercurial, ma che non vorreste vedere elencati ogni volta che invocate hg status. Per esempio, i prodotti di assemblaggio 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. + + Per fare in modo che Mercurial ignori permanentemente quei file, create un file chiamato .hgignore alla radice del vostro repository. Dovreste registrare questo file tramite hg add in modo che Mercurial ne tenga traccia insieme al resto dei contenuti del vostro repository, dato che anche i vostri collaboratori potrebbero trovarlo utile. + + Mercurial si aspetta che il file .hgignore contenga una lista di espressioni regolari, una per riga. Le linee vuote vengono saltate. La maggior parte delle persone preferisce descrivere i file che vuole ignorare utilizzando la sintassi glob che abbiamo descritto in precedenza, quindi un tipico file .hgignore comincerà con questa direttiva: + + syntax: glob + + Questa riga dice a Mercurial di interpretare le righe che seguono come pattern di tipo glob, non espressioni regolari. + + Ecco un esempio di un tipico file .hgignore. + + syntax: glob +# Questa riga è un commento e verrà saltata. +# Anche le righe vuote vengono saltate. + +# File di backup lasciati dall'editor Emacs. +*~ + +# File di bloccaggio usati dall'editor Emacs. +# Notate che il carattere "#" è preceduto da un backslash. +# Questo evita che venga interpretato come l'inizio di un commento. +.\#* + +# File temporanei usati dall'editor vim. +.*.swp + +# Un file nascosto creato dal Finder di Mac OS X. +.DS_Store + + + + + Sensibilità alle maiuscole + + Se state lavorando in un ambiente di sviluppo misto che contiene sia sistemi Linux (o di tipo Unix) che Mac e Windows, dovreste tenere a mente che questi sistemi trattano le lettere maiuscole (N rispetto a n) nei nomi dei file in modi incompatibili tra loro. È improbabile che questo abbia effetti su di voi ed è facile occuparsene quando succede, ma potrebbe sorprendervi se non lo sapete. + + I sistemi operativi e i file system differiscono nel modo in cui gestiscono le maiuscole dei caratteri nei nomi di file e directory. Esistono tre modi comuni di gestire le maiuscole nei nomi. + + Completa insensibilità alle maiuscole. Le versioni maiuscole e minuscole di una lettera sono trattate come se fossero identiche, sia quando un file viene creato sia durante i successivi accessi. Questo è il funzionamento comune dei vecchi sistemi basati su DOS. + + Conservazione delle maiuscole, ma insensibilità ad esse. Quando un file o una directory vengono creati, le maiuscole nel loro nome vengono memorizzate e possono essere recuperate e visualizzate dal sistema operativo. Quando un file esistente viene cercato, le maiuscole nel suo nome vengono ignorate. Questa è la situazione standard su Windows e MacOS. I nomi foo e FoO identificano lo stesso file. Questo trattamento intercambiabile delle lettere maiuscole e minuscole è anche chiamato ripiegamento delle maiuscole. + + Sensibilità alle maiuscole. Le lettere maiuscole di un nome sono significative in ogni momento. I nomi foo e FoO identificano due file differenti. Questo è il modo in cui i sistemi Linux e Unix lavorano normalmente. + + + Su sistemi di tipo Unix è possibile avere uno qualsiasi o tutti e tre i modi di gestire le maiuscole in azione allo stesso tempo. Per esempio, se usate Linux per operare su una chiave USB formattata con un file system FAT32, il sistema operativo gestirà i nomi su quel file system in modo da conservare le maiuscole senza essere sensibile ad esse. + + + Memorizzazione del repository sicura e portabile + + Il meccanismo di memorizzazione dei repository Mercurial è sicuro per le maiuscole. Traduce i nomi dei file in modo che possano essere memorizzati senza problemi sia su file system sensibili alle maiuscole sia su quelli insensibili alle maiuscole. Questo significa che, per esempio, potete usare i normali strumenti per la copia di file per trasferire un repository Mercurial su una chiave USB, e spostare la chiavetta e il repository avanti e indietro tra un Mac, un PC con Windows e una macchina Linux senza problemi. + + + + Riconoscere i conflitti tra maiuscole e minuscole + + 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 ad esse, Mercurial tratterà i nomi che differiscono solo per le maiuscole come se fossero uguali. + + È 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 miofile.c e l'altro chiamato MioFile.c, questi file verranno memorizzati correttamente. E gli stessi file verranno correttamente rappresentati come due file separati nella directory di lavoro di altri utenti Linux. + + 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 hg update, o a unire il proprio lavoro con quel changeset tramite hg merge, 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. + + + + Correggere un conflitto tra maiuscole e minuscole + + Se state usando Windows o Mac in un ambiente misto dove alcuni dei vostri collaboratori usano Linux o Unix, e Mercurial riporta un conflitto di ripiegamento delle maiuscole (indicandolo con il termine inglese case folding nel messaggio di errore) quando provate a eseguire hg update o hg merge, la procedura per correggere il problema è semplice. + + Trovate la macchina Linux o Unix più vicina, clonatevi il repository problematico e usate il comando hg rename di Mercurial per cambiare i nomi di qualsiasi file o directory che crea complicazioni, in modo da non causare più alcun conflitto di ripiegamento delle maiuscole. Inserite queste modifiche nel repository, eseguite hg pull o hg push attraverso i vostri sistemi Windows o MacOS e usate hg update per aggiornare la directory di lavoro alla revisione che contiene i nomi senza conflitti. + + Il changeset con i nomi in conflitto rimarrà nella cronologia del vostro progetto e non sarete comunque in grado di usare hg update per aggiornare la directory di lavoro a quel changeset su un sistema Windows o MacOS, ma potrete continuare a sviluppare senza impedimenti. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch08-branch.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch08-branch.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,240 @@ + + + Gestire le release e lo sviluppo con i rami + + Mercurial vi fornisce diversi meccanismi per gestire un progetto che sta facendo progressi su più fronti contemporaneamente. Per comprendere questi meccanismi, come prima cosa daremo una breve occhiata alla struttura di un progetto software abbastanza ordinario. + + Molti progetti software distribuiscono periodicamente release principali (o maggiori) che contengono nuove funzionalità sostanziali. In parallelo, possono distribuire release secondarie (o minori) che di solito sono identiche alle release principali su cui sono basate e in più contengono alcune correzioni di bug. + + In questo capitolo, cominceremo parlando di come mantenere una registrazione delle milestone di progetto come le release, poi continueremo parlando del flusso di lavoro tra fasi differenti di un progetto e di come Mercurial può aiutarvi a isolare e gestire questo lavoro. + + + Dare un nome persistente a una revisione + + Una volta che avete deciso che vi piacerebbe chiamare release 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). + + &interaction.tag.init; + + Mercurial vi consente di dare un nome permanente a qualsiasi revisione usando il comando hg tag. Ovviamente, questi nomi sono chiamati etichette (in inglese, appunto, tag). + + &interaction.tag.tag; + + Un'etichetta non è altro che un nome simbolico 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: + + due punti (codice ASCII 58, + :) + + ritorno a capo (codice ASCII 13, + \r) + + nuova riga (codice ASCII 10, + \n) + + + Potete usare il comando hg tags 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. + + &interaction.tag.tags; + + Notate che tip viene inclusa nell'elenco mostrato da hg tags. L'etichetta tip è una speciale etichetta mobile che identifica sempre la revisione più recente contenuta in un repository. + + Il comando hg tags 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 tip è sempre la prima etichetta elencata nel risultato di hg tags. + + Il comando hg log stamperà le etichette associate a ogni revisione visualizzata. + + &interaction.tag.log; + + 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. + + &interaction.tag.log.v1.0; + + 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 troppe (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. + + 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 in modo pulito, 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. + + Se volete rimuovere un'etichetta che non volete più, usate hg tag --remove. + + &interaction.tag.remove; + + Potete anche modificare un'etichetta in qualsiasi momento, in modo che identifichi una revisione differente, semplicemente invocando di nuovo il comando hg tag. Dovrete usare l'opzione per dire a Mercurial che volete davvero aggiornare l'etichetta. + + &interaction.tag.replace; + + 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. + + 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 .hgtags alla radice del vostro repository. Quando eseguite il comando hg tag, Mercurial modifica questo file, poi ne effettua automaticamente il commit registrandone i cambiamenti. Questo significa che ad ogni esecuzione di hg tag corrisponderà un changeset nell'elenco mostrato da hg log. + + &interaction.tag.tip; + + + Gestire i conflitti di etichette durante un'unione + + Avrete raramente bisogno di preoccuparvi del file .hgtags, 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. + + Se state risolvendo un conflitto nel file .hgtags durante un'unione, c'è una particolarità da ricordare quando modificate il file .hgtags: quando Mercurial sta analizzando le etichette in un repository, non legge mai la copia di lavoro del file .hgtags, ma legge la revisione del file registrata più recentemente. + + Una sfortunata conseguenza di questo comportamento è che non potete verificare la correttezza del file .hgtags risultato dall'unione se non dopo aver effettuato il commit di un cambiamento. Quindi, se vi trovate a risolvere un conflitto su .hgtags durante un'unione, assicuratevi di eseguire hg tags dopo aver effettuato il commit. Se il comando trova un errore nel file .hgtags, vi indicherà la posizione dell'errore, che potrete dunque correggere, registrando la correzione nel repository. Dovreste poi eseguire ancora hg tags, giusto per essere sicuri che la vostra correzione sia valida. + + + + Etichette e cloni + + Potreste aver notato che il comando hg clone offre un'opzione 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. + + Se ricordate, un'etichetta viene memorizzata come una revisione del file .hgtags. Quando create un'etichetta, il changeset in cui viene registrata si riferisce a un changeset precedente. Quando eseguite hg clone -r foo per clonare un repository all'etichetta foo, il nuovo clone non conterrà alcuna revisione più recente di quella a cui si riferisce l'etichetta, compresa la revisione in cui l'etichetta è stata creata. Come risultato, otterrete esattamente il sottoinsieme corretto della cronologia del progetto nel nuovo repository, ma non l'etichetta che vi sareste potuti aspettare. + + + + Quando le etichette permanenti sono eccessive + + 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 4237e45506ee è in realtà la v2.0.2. Se state provando a rintracciare un bug intricato, poteste volere un'etichetta per ricordarvi di qualcosa come Anna ha visto gli effetti del bug in questa revisione. + + In casi come questo, quello che potreste voler usare sono le etichette locali. Un'etichetta locale viene creata tramite l'opzione del comando hg tag e viene memorizzata in un file chiamato .hg/localtags. Diversamente da .hgtags, .hg/localtags non è soggetto a controllo di revisione, quindi qualsiasi etichetta creiate usando l'opzione rimarrà strettamente locale al repository in cui state attualmente lavorando. + + + + + Il flusso dei cambiamenti&emdash;la visione d'insieme e la visione di dettaglio + + Per ritornare allo schema abbozzato all'inizio del capitolo, consideriamo un progetto che contiene molteplici attività di sviluppo parallele in lavorazione contemporaneamente. + + Potrebbero esserci attività dedicate a una nuova release principale, a una nuova release minore che corregge alcuni bug trovati nell'ultima release principale e a un'inattesa correzione a caldo di una vecchia release che ora si trova in fase di manutenzione. + + Di solito, ognuna di queste direzioni di sviluppo parallele viene chiamata ramo (in inglese, branch). Tuttavia, abbiamo già visto più volte che Mercurial tratta tutta la cronologia come una serie di rami e unioni. In realtà, quello che abbiamo qui sono due idee marginalmente correlate che condividono casualmente lo stesso nome. + + Nella visione d'insieme 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. + + Nella visione di dettaglio 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. + + + + + Gestire i rami nella visione d'insieme + + Nella visione d'insieme, il modo più facile per isolare un ramo in Mercurial è quello di utilizzare un repository dedicato. Se avete un repository condiviso esistente&emdash;chiamiamolo mioprogetto&emdash;che raggiunge una milestone 1.0, 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. + + &interaction.branch-repo.tag; + + Potete quindi clonare un nuovo repository condiviso mioprogetto-1.0.1 da quella etichetta. + + &interaction.branch-repo.clone; + + Successivamente, chi ha bisogno di lavorare sulla correzione di un bug che dovrebbe essere contenuta in una prossima release minore 1.0.1 potrà clonare il repository mioprogetto-1.0.1, fare le proprie modifiche e poi trasmetterle a quel repository. + + &interaction.branch-repo.bugfix; + + Nel frattempo, lo sviluppo della prossima release principale può continuare, isolato e ininterrotto, nel repository mioprogetto. + + &interaction.branch-repo.new; + + + + Non ripetetevi: le unioni tra rami + + 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. + + 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. + + &interaction.branch-repo.pull; + + Poi dovrete unire le teste dei due rami e trasmettere i cambiamenti al ramo principale. + + &interaction.branch-repo.merge; + + + + Denominare i rami in un repository + + 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. + + Se invece appartenete alla categoria degli utenti avanzati (e 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 visione di dettaglio e nella visione d'insieme. Se Mercurial lavora con molteplici rami di dettaglio alla volta in un repository (per esempio dopo che avete propagato i cambiamenti, ma prima di incorporarli), può anche lavorare con molteplici rami d'insieme. + + La chiave per lavorare in questo modo è che Mercurial vi permette di assegnare un nome persistente a un ramo. In ogni repository c'è sempre un ramo chiamato default. Anche prima che cominciate a creare voi stessi nuovi rami con il proprio nome, potete trovare tracce del ramo default se le cercate. + + Per esempio, quando eseguite il comando hg commit e vi viene presentato un editor in modo che possiate inserire un messaggio di commit, cercate una riga che contiene il testo HG: ramo default verso il fondo. Questo comando vi informa che il vostro commit avverrà sul ramo chiamato default. + + Per cominciare a lavorare con i rami con nome, usate il comando hg branches. Questo comando elenca i rami con nome già presenti nel vostro repository, dicendovi quale changeset è in cima a ognuno di loro. + + &interaction.branch-named.branches; + + Dato che non avete ancora creato alcun ramo con nome, l'unico ramo esistente è default. + + Per trovare qual è il ramo attuale, eseguite il comando hg branch senza passargli alcun argomento. Otterrete il nome del ramo in cui trova il genitore del changeset corrente. + + &interaction.branch-named.branch; + + Per creare un nuovo ramo, eseguite ancora il comando hg branch. Questa volta, passategli un argomento: il nome del ramo che volete creare. + + &interaction.branch-named.create; + + Dopo che avete creato un ramo, potreste chiedervi qual è stato l'effetto del comando hg branch. Che cosa ci dicono i comandi hg status e hg tip? + + &interaction.branch-named.status; + + Nulla è cambiato nella directory di lavoro e non è stata creata nuova cronologia. Come queste osservazioni suggeriscono, il comando hg branch non ha alcun effetto permanente, ma si limita a dire a Mercurial quale nome di ramo usare la prossima volta che effettuerete il commit di un changeset. + + Quando inserite un cambiamento nel repository, Mercurial registra il nome del ramo su cui lo avete inserito. Una volta che siete passati dal ramo default a un altro e avete eseguito il commit, vedrete apparire il nome del nuovo ramo nel risultato di hg log, hg tip e altri comandi che mostrano lo stesso tipo di informazioni. + + &interaction.branch-named.commit; + + I comandi come hg log stamperanno il nome del ramo di ogni changeset che non appartiene al ramo default. Come risultato, se non avete mai usato i rami con nome, non vedrete mai questa informazione. + + Una volta che avete denominato un ramo e inserito un cambiamento in quel ramo, ogni commit successivo che discende da quel cambiamento erediterà lo stesso nome di ramo. Potete cambiare il nome a un ramo in ogni momento, usando il comando hg branch. + + &interaction.branch-named.rebranch; + + 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.) + + + + Gestire molti rami con nome in un repository + + 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 hg update o hg pull -u 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 del comando hg update. + + 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. + + &interaction.branch-named.parents; + + Ci troviamo sul ramo bar, ma esiste anche un ramo più vecchio chiamato foo. + + Possiamo utilizzare hg update per spostarci avanti e indietro tra le revisioni di punta dei rami foo e bar senza aver bisogno di impiegare l'opzione , perché questi spostamenti avvengono linearmente attraverso la nostra cronologia dei cambiamenti. + + &interaction.branch-named.update-switchy; + + Se torniamo indietro al ramo foo e invochiamo hg update, il comando ci manterrà su foo piuttosto che spostarci alla punta di bar. + + &interaction.branch-named.update-nothing; + + Il commit di una nuova modifica sul ramo foo introduce una nuova testa. + + &interaction.branch-named.foo-commit; + + + + I nomi di ramo e le unioni + + Come avete probabilmente notato, le unioni in Mercurial non sono simmetriche. Diciamo che il nostro repository possiede due teste, 17 e 23. Se uso hg update per aggiornare alla 17 e poi eseguo hg merge per incorporare la 23, Mercurial registra la 17 come primo genitore dell'unione e la 23 come secondo. Ma se uso hg update per aggiornare alla 23 e poi eseguo hg merge per incorporare la 17, Mercurial registra la 23 come primo genitore e la 17 come secondo. + + 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 è foo e unite quel ramo con bar, dopo l'unione il nome del ramo in cui vi troverete sarà ancora foo. + + Capita spesso che un repository contenga più teste, ognuna con lo stesso nome di ramo. Diciamo che io sto lavorando sul ramo foo 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 foo. Sperabilmente, il risultato di un'unione sarà una singola testa sul ramo foo. + + Ma se io sto lavorando sul ramo bar e incorporo il lavoro dal ramo foo, il risultato rimarrà sul ramo bar. + + &interaction.branch-named.merge; + + Per farvi un esempio più concreto, se sto lavorando sul ramo sperimentale e voglio incorporare le ultime correzioni dal ramo stabile, Mercurial sceglierà il nome del ramo corretto (sperimentale) quando estrarrò e incorporerò i cambiamenti da stabile. + + + + La denominazione dei rami è generalmente utile + + 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. + + 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. + + Se state lavorando con repository condivisi, potete impostare un hook pretxnchangegroup su ogni repository in modo da bloccare i cambiamenti in entrata che appartengono al nome di ramo sbagliato. Questo accorgimento vi offre una difesa semplice ma efficace nei confronti di chi trasmette accidentalmente i cambiamenti da un ramo sperimentale a un ramo stabile. Un hook di questo tipo potrebbe somigliare al seguente, contenuto all'interno del file /.hgrc del repository condiviso. + [hooks] +pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mioramo + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch09-undo.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch09-undo.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,568 @@ + + + Trovare e correggere gli errori + + Sbagliare potrebbe essere umano, ma per gestire davvero bene le conseguenze degli errori ci vuole un sistema di controllo di revisione di prima qualità. In questo capitolo, discuteremo alcune tecniche che potete usare quando scoprite che un problema si è insinuato nel vostro progetto. Mercurial è dotato di alcune funzioni particolarmente efficaci che vi aiuteranno a isolare le cause dei problemi e a trattarle in maniera appropriata. + + + Cancellare la cronologia locale + + + L'inserimento accidentale + + In maniera occasionale ma persistente mi capita di digitare più velocemente di quanto riesca a pensare, cosa che talvolta provoca come conseguenza l'inserimento di un changeset incompleto o completamente sbagliato. Nel mio caso, il classico tipo di changeset incompleto è quello in cui ho creato un nuovo file sorgente ma ho dimenticato di usare hg add per aggiungerlo al repository. Un changeset completamente sbagliato non è così comune, ma non è meno fastidioso. + + + + Abortire una transazione + + Nella , ho menzionato che Mercurial tratta ogni modifica del repository come una transazione. Ogni volta che inserite un changeset o estraete i cambiamenti da un altro repository, Mercurial ricorda cosa avete fatto. Potete annullare, o abortire, esattamente una di queste azioni usando il comando hg rollback. (Leggete la per un importante avvertimento su come usare questo comando.) + + Ecco un errore che mi ritrovo spesso a commettere: inserire un changeset in cui ho creato un nuovo file dimenticandomi di aggiungerlo tramite hg add. + + &interaction.rollback.commit; + + Un'occhiata al risultato di hg status dopo l'inserimento conferma immediatamente l'errore. + + &interaction.rollback.status; + + Il commit ha catturato le modifiche al file a, ma non il nuovo file b. È molto probabile che qualcosa in a si riferisca a b, ma se trasmettessi questo changeset a un repository condiviso, i collaboratori che estrarranno i miei cambiamenti non troverebbero b nei loro repository. Di conseguenza, diventerei oggetto di una certa indignazione. + + Tuttavia, la fortuna è dalla mia parte&emdash;mi sono accorto dell'errore prima di trasmettere il changeset. Ora uso il comando hg rollback e Mercurial farà sparire quell'ultimo changeset. + + &interaction.rollback.rollback; + + Notate che il changeset non è più presente nella cronologia del repository e che la directory di lavoro pensa ancora che il file a sia stato modificato. Il commit e la sua cancellazione hanno lasciato la directory di lavoro esattamente nello stato in cui si trovava prima dell'inserimento: il changeset è stato completamente rimosso. Ora posso tranquillamente usare hg add per aggiungere il file b e rieseguire il commit. + + &interaction.rollback.add; + + + + L'estrazione sbagliata + + È pratica comune usare Mercurial mantenendo in repository differenti i rami di sviluppo separati di un progetto. Il vostro gruppo di sviluppo potrebbe avere un repository condiviso per la release 0.9 del vostro progetto e un altro, contenente cambiamenti differenti, per la release 1.0. + + In questa situazione, potete immaginare che pasticcio accadrebbe se aveste un repository 0.9 locale e vi propagaste accidentalmente i cambiamenti dal repository 1.0 condiviso. Nel caso peggiore, potreste non fare abbastanza attenzione e trasmettere quei cambiamenti nell'albero 0.9 condiviso, confondendo tutti gli altri sviluppatori (ma non preoccupatevi, ritorneremo a questo orribile scenario più avanti). Tuttavia, è più probabile che notiate immediatamente l'errore, perché Mercurial vi mostrerà l'URL da cui sta estraendo i cambiamenti, o perché vedrete Mercurial propagare un numero sospettosamente alto di cambiamenti nel repository. + + Il comando hg rollback cancellerà scrupolosamente tutti i changeset che avete appena estratto. Mercurial raggruppa tutti i cambiamenti provenienti da un'invocazione di hg pull in una singola transazione, quindi un'unica invocazione di hg rollback è tutto quello che vi serve per annullare questo errore. + + + + Abortire una transazione è inutile se avete già trasmesso le modifiche + + Il valore di hg rollback scende a zero una volta che avete trasmesso le vostre modifiche a un altro repository. Abortire un cambiamento lo fa scomparire interamente, ma solo nel repository in cui invocate hg rollback. Dato che una cancellazione elimina parte della cronologia, non è possibile che la scomparsa di un cambiamento si propaghi tra i repository. + + Se avete trasmesso un cambiamento a un altro repository&emdash;in particolare se è un repository condiviso&emdash;le modifiche sono essenzialmente scappate dal recinto e dovrete rimediare all'errore in un altro modo. Se trasmettete un changeset da qualche parte, lo abortite e poi estraete i cambiamenti dal repository verso cui avete effettuato la trasmissione, il changeset di cui credevate di esservi sbarazzati riapparirà semplicemente nel vostro repository. + + Se siete assolutamente sicuri che il cambiamento che volete abortire è quello più recente contenuto nel repository a cui lo avete trasmesso e sapete che nessun altro può averlo estratto da quel repository, potete ritirare il changeset anche là, ma non dovreste aspettarvi che questo funzioni in maniera affidabile. Presto o tardi un cambiamento finirà in un repository su cui non avete un controllo diretto (o vi siete dimenticati di averlo) e vi si ritorcerà contro. + + + + Potete abortire una sola transazione + + Mercurial memorizza esattamente una transazione nel suo registro delle transazioni: quella più recente avvenuta nel repository. Questo significa che potete abortire solo una transazione. Se vi aspettate di poter abortire una transazione e poi quella che la precede, questo non è il comportamento che otterrete. + + &interaction.rollback.twice; + + Una volta che avete abortito una transazione in un repository, non potete effettuare un'altra cancellazione in quel repository fino a quando non avete eseguito un nuovo inserimento o una nuova estrazione. + + + + + Rimediare alle modifiche sbagliate + + Se fate un cambiamento a un file e poi decidete che in realtà non volevate affatto modificare il file, ma non avete ancora inserito i vostri cambiamenti nel repository, il comando che vi serve è hg revert. Questo comando esamina il changeset genitore della directory di lavoro e ripristina il contenuto del file allo stato in cui era in quel changeset. (Questo è un modo prolisso per dire che, nel caso normale, annulla le vostre modifiche.) + + Vediamo come funziona il comando hg revert, ancora con un altro piccolo esempio. Cominceremo modificando un file che Mercurial ha già registrato. + + &interaction.daily.revert.modify; + + Se non vogliamo quella modifica, possiamo semplicemente usare hg revert sul file. + + &interaction.daily.revert.unmodify; + + Il comando hg revert ci fornisce un ulteriore grado di protezione salvando il nostro file modificato con un'estensione .orig. + + &interaction.daily.revert.status; + + + Fate attenzione ai file <filename>.orig</filename> + + È estremamente improbabile che stiate usando Mercurial per gestire file con estensione .orig o persino che siate interessati al contenuto di quei file. Nel caso, comunque, è utile ricordare che hg revert sovrascriverà incondizionatamente un file con estensione .orig esistente. Per esempio, se avete già un file foo.orig quando ritornate alla versione precedente del file foo, il contenuto di foo.orig verrà cestinato. + + + Ecco un riepilogo dei casi che il comando hg revert è in grado di gestire. Li descriveremo in dettaglio nella prossima sezione. + + Se modificate un file, il comando lo ripristinerà al suo stato non modificato. + + Se usate hg add su un file, hg revert annullerà lo stato di aggiunto del file ma lascerà intatti i contenuti del file. + + Se cancellate un file senza dirlo a Mercurial, il comando ripristinerà i contenuti del file. + + Se usate il comando hg remove per cancellare un file, hg revert annullerà lo stato di rimosso del file e ne ripristinerà i contenuti. + + + + Errori nella gestione dei file + + Il comando hg revert non è utile solo per i file modificati, ma vi permette di invertire i risultati di tutti i comandi Mercurial di gestione dei file come hg add, hg remove, e così via. + + Se usate hg add su un file, poi decidete che in effetti non volete che Mercurial ne tenga traccia, potete usare hg revert per annullare l'operazione di aggiunta. Non preoccupatevi, Mercurial non modificherà il file in alcun modo, ma si limiterà a eliminare il contrassegno per quel file. + + &interaction.daily.revert.add; + + Similmente, se chiedete a Mercurial di rimuovere un file tramite hg remove, potete usare hg revert per ripristinarne i contenuti allo stato in cui erano nel genitore della directory di lavoro. + + &interaction.daily.revert.remove; + + Questo funziona altrettanto bene con un file che avete cancellato a mano senza dirlo a Mercurial (ricordatevi che, nella terminologia di Mercurial, questo file viene detto mancante). + + &interaction.daily.revert.missing; + + Se invertite l'azione del comando hg copy, 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. + + &interaction.daily.revert.copy; + + + + + Gestire i cambiamenti inseriti + + Considerate il caso in cui avete inserito un cambiamento a e subito dopo un altro cambiamento b basato sul precedente, poi realizzate che il cambiamento a era sbagliato. Mercurial vi consente di ritirare sia un intero changeset automaticamente, sia certi mattoni da costruzione che vi permettono di invertire a mano parte di un changeset. + + Prima di leggere questa sezione, c'è una cosa che dovete tenere a mente: il comando hg backout annulla gli effetti di un cambiamento effettuando un'aggiunta alla cronologia del vostro repository invece di modificarla o di eliminarne una parte. È lo strumento giusto da usare se state correggendo un bug, ma non se state cercando di annullare qualche cambiamento che potrebbe avere conseguenze catastrofiche. Per trattare con questi ultimi, leggete la . + + + Ritirare un changeset + + Il comando hg backout vi consente di annullare gli effetti di un intero changeset in modo automatico. Dato che la cronologia di Mercurial è immutabile, questo comando non si sbarazza del changeset che volete annullare, ma crea un nuovo changeset che inverte l'effetto del changeset da annullare. + + Le operazioni del comando hg backout sono un po' intricate, quindi le illustreremo con alcuni esempi. Per prima cosa, creiamo un repository con alcuni semplici cambiamenti. + + &interaction.backout.init; + + Il comando hg backout prende come argomento un singolo identificatore di changeset che indica il changeset da annullare. Normalmente, hg backout vi presenterà un editor di testo per farvi scrivere un messaggio di commit, in modo che possiate registrare il motivo per cui state ritirando il cambiamento. In questo esempio, forniremo un messaggio di commit sulla riga di comando usando l'opzione . + + + + Ritirare il changeset di punta + + Cominceremo ritirando l'ultimo changeset che abbiamo inserito. + + &interaction.backout.simple; + + Potete vedere che la seconda riga di miofile non è più presente. Un'occhiata all'elenco generato da hg log ci dà un'idea di quello che il comando hg backout ha fatto. + + &interaction.backout.simple.log; + + Notate che il nuovo changeset creato da hg backout è un figlio del changeset che abbiamo ritirato. Questo è più facile da vedere nella , che mostra una rappresentazione grafica della cronologia dei cambiamenti. Come potete vedere, la cronologia è gradevolmente lineare. + +

+ Ritirare un cambiamento tramite il comando <command role="hg-cmd">hg backout</command> + + + XXX add text + + + + + + Ritirare un changeset diverso dalla punta + + Se volete ritirare un cambiamento diverso dall'ultimo che avete inserito, passate l'opzione al comando hg backout. + + &interaction.backout.non-tip.clone; + + Questo rende il ritiro di qualsiasi changeset una singola operazione che di solito è semplice e veloce. + + &interaction.backout.non-tip.backout; + + Se date un'occhiata al contenuto di miofile dopo che l'operazione di ritiro si è conclusa, vedrete che il primo e il terzo cambiamento sono presenti, ma non il secondo. + + &interaction.backout.non-tip.cat; + + Come illustrato nella rappresentazione grafica della cronologia nella , Mercurial inserisce ancora un cambiamento in questo tipo di situazione (il nodo rettangolare è quello che Mercurial inserisce automaticamente) ma il grafo delle revisioni ora è diverso. Prima di cominciare il processo di ritiro, Mercurial mantiene in memoria l'identità del genitore corrente della directory di lavoro. Poi ritira il changeset indicato e inserisce quel genitore come un changeset. Infine, incorpora il genitore precedente della directory di lavoro, ma notate che non esegue il commit dei risultati dell'unione. Il repository ora contiene due teste e la directory di lavoro contiene i risultati di un'unione. + +

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

+ Ritirare un cambiamento tramite il comando <command role="hg-cmd">hg backout</command> + + + XXX add text + + + + Dopo che il comando hg backout ha terminato, lascia il nuovo changeset ritirato come genitore della directory di lavoro. + + &interaction.backout.manual.parents; + + Ora abbiamo due insiemi isolati di cambiamenti. + + &interaction.backout.manual.heads; + + Pensiamo a quello che ora ci aspettiamo di vedere come contenuto di miofile. Il primo cambiamento dovrebbe essere presente, perché non lo abbiamo mai ritirato. Il secondo cambiamento non dovrebbe esserci, dato che quello è il cambiamento che abbiamo ritirato. Visto che il grafo della cronologia mostra il terzo cambiamento come una testa separata, non ci aspettiamo di vedere il terzo cambiamento nel contenuto di miofile. + + &interaction.backout.manual.cat; + + Per riottenere il terzo cambiamento nel file, eseguiamo semplicemente una normale unione tra le nostre due teste. + + &interaction.backout.manual.merge; + + Successivamente, la cronologia del nostro repository può essere rappresentata graficamente come nella . + +

+ Incorporare manualmente un cambiamento ritirato + + + XXX add text + + + + + + Perché <command role="hg-cmd">hg backout</command> funziona in questo modo + + Ecco una breve descrizione del funzionamento del comando hg backout. + + Si assicura che la directory di lavoro sia pulita, i.e. che l'elenco generato da hg status sia vuoto. + + Memorizza il genitore corrente della directory di lavoro. Chiamiamo orig questo changeset. + + Esegue l'equivalente di un'invocazione di hg update per sincronizzare la directory di lavoro con il changeset che volete ritirare. Chiamiamo backout questo changeset. + + Trova il genitore di quel changeset. Chiamiamo parent questo changeset. + + Per ogni file su cui il changeset backout ha avuto effetto, esegue l'equivalente del comando hg revert -r parent sul file per ripristinare il contenuto che aveva prima che quel changeset venisse inserito. + + Esegue il commit del risultato come un nuovo changeset che ha backout come genitore. + + Se specificate l'opzione sulla riga di comando, esegue un'unione con orig e inserisce i risultati dell'unione nel repository. + + + In alternativa, sarebbe possibile implementare hg backout utilizzando hg export per esportare il changeset da ritirare sotto forma di diff e poi impiegando l'opzione del comando patch per invertire l'effetto del cambiamento senza gingillarsi con la directory di lavoro. Questo procedimento sembra molto più semplice, ma non funzionerebbe affatto altrettanto bene. + + Il comando hg backout esegue un aggiornamento, un inserimento, un'unione e un altro inserimento per dare al meccanismo di unione la possibilità di fare il miglior lavoro possibile nel gestire tutte le modifiche avvenute tra il cambiamento che state ritirando e la revisione di punta corrente. + + Se state ritirando un cambiamento che si trova 100 revisioni indietro nella cronologia del vostro progetto, le probabilità che il comando patch sia in grado di applicare un diff invertito in maniera pulita non sono molto alte, perché i cambiamenti intercorsi avranno probabilmente rovinato il contesto utilizzato da patch per determinare se può applicare una patch (se questo vi sembra incomprensibile, leggete la per una discussione sul comando patch). In più, il meccanismo di unione di Mercurial riesce a gestire i cambiamenti di nome e di permessi per file e directory e le modifiche ai file binari, mentre patch non è in grado di farlo. + + + + + Modifiche che non avrebbero mai dovuto essere fatte + + Quasi sempre, il comando hg backout è esattamente quello che vi serve se volete annullare gli effetti di un cambiamento. Il comando lascia una registrazione permanente di quello che avete fatto, sia quando avete inserito il changeset originale che quando avete successivamente rimesso in ordine. + + In rare occasioni, comunque, potreste scoprire di aver inserito un cambiamento che non dovrebbe essere presente nel repository proprio per niente. Per esempio, sarebbe molto inusuale, e di solito considerato un errore, inserire in un repository i file oggetto di un progetto software insieme ai suoi file sorgente. I file oggetto non hanno praticamente alcun valore intrinseco e sono grandi, quindi aumentano la dimensione del repository e il tempo necessario a clonarlo o a estrarne i cambiamenti. + + Prima di illustrare le opzioni a vostra disposizione se eseguite il commit di un cambiamento da sacchetto di carta marrone (quel tipo di modifiche talmente infelici che vorreste nascondere la testa in un sacchetto di carta marrone), lasciatemi discutere alcuni approcci che probabilmente non funzioneranno. + + Dato che Mercurial tratta la cronologia in maniera cumulativa&emdash;ogni cambiamento si basa su tutti i cambiamenti che lo precedono&emdash;in genere non è possibile far semplicemente sparire i cambiamenti disastrosi. L'unica eccezione capita quando avete appena inserito una modifica che non è ancora stata propagata verso qualche altro repository. In questo caso, potete tranquillamente usare il comando hg rollback, come descritto nella . + + Dopo che avete trasmesso un cambiamento sbagliato a un altro repository, potreste ancora usare hg rollback per far scomparire la vostra copia locale del cambiamento, ma questa azione non avrà le conseguenze che volete. Il cambiamento sarà ancora presente nel repository remoto, quindi riapparirà nel vostro repository locale la prossima volta che effettuerete un'estrazione. + + Se vi trovate in una situazione come questa e sapete quali sono i repository verso cui si è propagato il vostro cambiamento sbagliato, potete provare a sbarazzarvi del cambiamento in ognuno di quei repository. Questa, naturalmente, non è una soluzione soddisfacente: se tralasciate anche un singolo repository quando state ripulendo, il cambiamento sarà ancora là fuori e potrebbe propagarsi ulteriormente. + + Se avete inserito uno o più cambiamenti dopo il cambiamento che vorreste veder sparire, le vostre opzioni si riducono ulteriormente. Mercurial non offre alcun modo per fare un buco nella cronologia lasciando gli altri changeset intatti. + + + Ritirare un'unione + + Dato che le unioni sono spesso complicate, si sono sentiti casi di unioni gravemente rovinate, ma i cui risultati sono stati erroneamente inseriti in un repository. Mercurial fornisce un'importante protezione contro le unioni sbagliate rifiutandosi di eseguire il commit di file irrisolti, ma l'ingenuità umana garantisce che sia ancora possibile mettere sottosopra un'unione e registrarne i risultati. + + Di solito, il modo migliore per affrontare la registrazione di un'unione sbagliata è semplicemente quello di provare a riparare il danno a mano. Un completo disastro che non possa venire corretto a mano dovrebbe essere molto raro, ma il comando hg backout può aiutare a rendere la pulizia più semplice attraverso l'opzione , che vi consente di specificare a quale genitore tornare quando state ritirando un'unione. + +

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

+ Ritirare l'unione favorendo un genitore + + + XXX add text + + + + + + Invocare hg backout --rev=4 --parent=3. Questo dice al comando hg backout di ritirare ancora la revisione 4, ma questa volta scegliendo il genitore 3, l'altro genitore dell'unione. Il risultato è visibile nella , in cui il repository ora contiene tre teste. +

+ Ritirare l'unione favorendo l'altro genitore + + + XXX add text + + + + + + 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 . +

+ Unire i risultati dei ritiri + + + XXX add text + + + + + + Eseguire un'unione con il commit che è stato eseguito dopo l'unione sbagliata, come mostrato nella . +

+ Unire i risultati dei ritiri + + + XXX add text + + + + + + + + Proteggervi dai cambiamenti che vi sono <quote>sfuggiti</quote> + + Se avete inserito alcuni cambiamenti nel vostro repository locale e li avete propagati da qualche altra parte, questo non è necessariamente un disastro. Potete proteggervi prevenendo la comparsa di alcuni tipi di changeset sbagliati. Questo è particolarmente facile se di solito il vostro gruppo di lavoro estrae i cambiamenti da un repository centrale. + + Configurando alcuni hook su quel repository per convalidare i changeset in entrata (si veda il ), potete automaticamente evitare che alcuni tipi di changeset sbagliati compaiano nel repository centrale. Con una tale configurazione, alcuni tipi di changeset sbagliati tenderanno naturalmente a estinguersi perché non possono propagarsi verso il repository centrale. Ancora meglio, questo accade senza alcun bisogno di un intervento esplicito. + + Per esempio, un hook sui cambiamenti in entrata programmato per verificare che un changeset si possa effettivamente compilare è in grado di prevenire involontari guasti al processo di assemblaggio. + + + + Cosa fare con i cambiamenti sensibili che sfuggono + + Persino un progetto gestito con attenzione può subire eventi sfortunati come il commit di un file che contiene password importanti e la sua incontrollata propagazione. + + Se qualcosa del genere dovesse accadervi e le informazioni che vengono accidentalmente propagate fossero davvero sensibili, il vostro primo passo dovrebbe essere quello di mitigare l'effetto della perdita senza cercare di controllare la perdita stessa. Se non siete sicuri al 100% di sapere esattamente chi può aver visto i cambiamenti, dovreste immediatamente cambiare le password, cancellare le carte di credito, o trovare qualche altro modo per assicurarvi che le informazioni 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. + + Potreste sperare che ci sia qualche meccanismo da usare per scoprire chi ha visto un cambiamento o per cancellare il cambiamento permanentemente e ovunque, ma ci sono buone ragioni per cui queste operazioni non sono possibili. + + Mercurial non fornisce una traccia registrata di chi ha estratto i cambiamenti da un repository, perché di solito questa informazione è impossibile da raccogliere o è facile da falsificare. In un ambiente multi-utente o di rete, dovreste quindi dubitare fortemente di voi stessi se pensate di aver identificato ogni luogo in cui un cambiamento sensibile si è propagato. Non dimenticate che le persone possono spedire allegati via email, salvare i propri dati su altri computer tramite il software di backup, trasportare i repository su chiavi USB e trovare altri modi completamente innocenti di confondere i vostri tentativi di rintracciare ogni copia di un cambiamento problematico. + + In più, Mercurial non vi fornisce un modo per far completamente sparire un changeset dalla cronologia perché non c'è alcun modo di imporre la sua sparizione, dato che qualcuno potrebbe facilmente modificare la propria copia di Mercurial per ignorare quelle direttive. E poi, se anche Mercurial fornisse questa funzione, qualcuno che semplicemente non abbia estratto il changeset che fa sparire questo file non ne godrebbe gli effetti, né lo farebbero i programmi di indicizzazione web che visitano un repository al momento sbagliato, i backup del disco, o altri meccanismi. In effetti, nessun sistema distribuito di controllo di revisione può far sparire dati in maniera affidabile. Dare l'illusione di un controllo di questo tipo potrebbe facilmente conferirvi un falso senso di sicurezza, peggiorando le cose rispetto a non darvela affatto. + + + + + Trovare la causa di un bug + + Essere in grado di ritirare un changeset che ha introdotto un bug va benissimo, ma richiede che sappiate quale changeset va ritirato. Mercurial offre un inestimabile comando, chiamato hg bisect, che vi aiuta ad automatizzare questo processo e a completarlo in maniera molto efficiente. + + L'idea alla base del comando hg bisect è che un changeset abbia introdotto una modifica di comportamento che potete identificare con un semplice test binario di successo o fallimento. Non sapete quale porzione di codice ha introdotto il cambiamento, ma sapete come verificare la presenza del bug. Il comando hg bisect usa il vostro test per dirigere la propria ricerca del changeset che ha introdotto il codice che ha causato il bug. + + Ecco alcuni scenari di esempio per aiutarvi a capire come potreste applicare questo comando. + + La versione più recente del vostro software ha un bug che non ricordate fosse presente alcune settimane prima, ma non sapete quando il bug è stato introdotto. Qui, il vostro test binario controlla la presenza di quel bug. + + Avete corretto un bug in tutta fretta e ora è il momento di chiudere la relativa voce nel database dei bug del vostro gruppo. Il database dei bug richiede un identificatore di changeset quando chiudete una voce, ma non ricordate in quale changeset avete corretto il bug. Ancora una volta, il vostro test binario controlla la presenza del bug. + + Il vostro software funziona correttamente, ma è più lento del 15% rispetto all'ultima volta che avete compiuto questa misurazione. Volete sapere quale changeset ha introdotto il calo di prestazioni. In questo caso, il vostro test binario misura le prestazioni del vostro software per vedere se è veloce o lento. + + La dimensione dei componenti del progetto che rilasciate è esplosa di recente e sospettate che qualcosa sia cambiato nel modo in cui assemblate il progetto. + + + Da questi esempi, dovrebbe essere chiaro che il comando hg bisect non è utile solo per trovare le cause dei bug. Potete usarlo per trovare qualsiasi proprietà emergente di un repository (qualsiasi cosa che non potete trovare con una semplice ricerca di testo sui file contenuti nell'albero) per la quale sia possibile scrivere un test binario. + + Ora introdurremo un po' di terminologia, giusto per chiarire quali sono le parti del processo di ricerca di cui siete responsabili voi e quali sono quelle di cui è responsabile Mercurial. Un test è qualcosa che voi eseguite quando hg bisect sceglie un changeset. Una sonda è ciò che hg bisect esegue per dirvi se una revisione è buona. Infine, useremo la parola bisezione per intendere la ricerca tramite il comando hg bisect. + + Un modo semplice per automatizzare il processo di ricerca sarebbe quello di collaudare semplicemente ogni changeset. Tuttavia, questo approccio è scarsamente scalabile. Se ci volessero dieci minuti per collaudare un singolo changeset e il vostro repository contenesse 10.000 changeset, l'approccio completo impiegherebbe una media di 35 giorni per trovare il changeset che ha introdotto un bug. Anche se sapeste che il bug è stato introdotto in uno degli ultimi 500 changeset e limitaste la ricerca a quelli, dovrebbero trascorrere più di 40 ore per trovare il changeset che ha introdotto il vostro bug. + + Il comando hg bisect invece usa la propria conoscenza della forma della cronologia delle revisioni del vostro progetto per effettuare una ricerca in tempo proporzionale al logaritmo del numero dei changeset da controllare (il tipo di ricerca che esegue viene chiamata ricerca dicotomica). Con questo approccio, la ricerca attraverso 10.000 changeset impiegherà meno di 3 ore, anche a 10 minuti per ogni test (la ricerca richiederà circa 14 test). Limitate la vostra ricerca agli ultimi cento changeset e il tempo impiegato sarà solo circa un'ora (approssimativamente sette test). + + Il comando hg bisect è consapevole della natura ramificata 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. + + + Usare il comando <command role="hg-cmd">hg bisect</command> + + Ecco un esempio di hg bisect in azione. + + + Fino alla versione 0.9.5 di Mercurial compresa, hg bisect non era uno dei comandi principali, ma veniva distribuito con Mercurial sotto forma di estensione. Questa sezione descrive il comando predefinito, non la vecchia estensione. + + + Ora creiamo un nuovo repository in modo che possiate provare il comando hg bisect in isolamento. + + &interaction.bisect.init; + + Simuleremo un progetto con un bug in modo molto semplice: creiamo cambiamenti elementari in un ciclo e designamo uno specifico cambiamento che conterrà il bug. Questo ciclo crea 35 changeset, ognuno dei quali aggiunge un singolo file al repository. Rappresenteremo il nostro bug con un file che contiene il testo ho un gub. + + &interaction.bisect.commits; + + La prossima cosa che vorremmo fare è capire come usare il comando hg bisect. Possiamo usare il normale meccanismo di aiuto predefinito di Mercurial per fare questo. + + &interaction.bisect.help; + + Il comando hg bisect lavora in più passi. Ogni passo procede nella maniera seguente. + + Eseguite il vostro test binario. + + Se il test ha avuto successo, informate hg bisect invocando il comando hg bisect --good. + + Se il test è fallito, invocate il comando hg bisect --bad. + + + + Il comando usa le vostre informazioni per decidere quale changeset collaudare successivamente. + + Il comando aggiorna la directory di lavoro a quel changeset e il processo ricomincia da capo. + + Il processo termina quando hg bisect identifica un unico cambiamento che indica il punto in cui il vostro test passa dallo stato di successo a quello di fallimento. + + Per cominciare la ricerca, dobbiamo eseguire il comando hg bisect --reset. + + &interaction.bisect.search.init; + + Nel nostro caso, il test binario che usiamo è semplice: controlliamo il repository per vedere se qualche file contiene la stringa ho un gub. Se è così, questo changeset contiene il cambiamento che ha causato il bug. Per convenzione, un changeset che ha la proprietà che stiamo cercando è guasto, mentre uno che non ce l'ha è funzionante. + + Quasi sempre, la revisione su cui la directory di lavoro è sincronizzata (di solito, la punta) esibisce già il problema introdotto dal cambiamento malfunzionante, quindi la indicheremo come guasta. + + &interaction.bisect.search.bad-init; + + Il nostro compito successivo consiste nel nominare un changeset che sappiamo non contenere il bug, in modo che il comando hg bisect possa circoscrivere la ricerca tra il primo changeset funzionante e il primo changeset guasto. Nel nostro caso, sappiamo che la revisione 10 non conteneva il bug. (Spiegherò meglio come scegliere il primo changeset funzionante più avanti.) + + &interaction.bisect.search.good-init; + + Notate che questo comando ha stampato alcune informazioni. + + Ci ha detto quanti changeset deve considerare prima di poter identificare quello che ha introdotto il bug e quanti test saranno richiesti dal processo. + + Ha aggiornato la directory di lavoro al prossimo changeset da collaudare e ci ha detto quale changeset sta collaudando. + + + Ora eseguiamo il nostro test nella directory di lavoro, usando il comando grep per vedere se il nostro file guasto è presente. Se c'è, questa revisione è guasta, altrimenti è funzionante. + + &interaction.bisect.search.step1; + + Questo test sembra un perfetto candidato per l'automazione, quindi trasformiamolo in una funzione di shell. + + &interaction.bisect.search.mytest; + + Ora possiamo eseguire un intero passo di collaudo con il singolo comando miotest. + + &interaction.bisect.search.step2; + + Ancora qualche altra invocazione del comando che abbiamo preparato per il passo di collaudo e abbiamo finito. + + &interaction.bisect.search.rest; + + Anche se avevamo 40 changeset attraverso cui cercare, il comando hg bisect ci ha permesso di trovare il changeset che ha introdotto il nostro bug usando solo cinque test. Dato che il numero di test effettuati dal comando hg bisect cresce con il logaritmo del numero dei changeset da analizzare, il vantaggio che ha rispetto a una ricerca che usa la strategia della forza bruta aumenta con ogni changeset che aggiungete. + + + + Riordinare dopo la vostra ricerca + + Quando avete finito di usare il comando hg bisect in un repository, potete invocare il comando hg bisect --reset in modo da scartare le informazioni che venivano usate per guidare la vostra ricerca. Il comando non usa molto spazio, quindi non è un problema se vi dimenticate di effettuare questa invocazione. Tuttavia, hg bisect non vi permetterà di cominciare una nuova ricerca in quel repository fino a quando non avrete eseguito hg bisect --reset. + + &interaction.bisect.search.reset; + + + + + Suggerimenti per trovare efficacemente i bug + + + Fornite informazioni consistenti + + Il comando hg bisect vi richiede di indicare correttamente il risultato di ogni test che eseguite. Se gli dite che un test è fallito quando in realtà ha avuto successo, il comando potrebbe essere in grado di scoprire l'inconsistenza. Se riesce a identificare un'incosistenza nei vostri resoconti, vi dirà che un particolare changeset è sia funzionante che guasto. Tuttavia, non è in grado di farlo perfettamente ed è ugualmente probabile che vi restituisca il changeset sbagliato come causa del bug. + + + + Automatizzate il più possibile + + Quando ho cominciato a usare il comando hg bisect, ho provato a eseguire alcune volte i miei test a mano sulla riga di comando. Questo non è l'approccio adatto, almeno per me. Dopo alcune prove, mi sono accorto che stavo facendo abbastanza errori da dover ricominciare le mie ricerche diverse volte prima di riuscire a ottenere i risultati corretti. + + I miei problemi iniziali nel guidare a mano il comando hg bisect si sono verificati anche con ricerche semplici su repository di piccole dimensioni, ma se il problema che state cercando è più sottile, o se il numero di test che hg bisect deve eseguire aumenta, la probabilità che un errore umano rovini la ricerca è molto più alta. Una volta che ho cominciato ad automatizzare i miei test, ho ottenuto risultati molto migliori. + + La chiave del collaudo automatizzato è duplice: + + verificate sempre lo stesso sintomo, e + + fornite sempre informazioni consistenti al comando hg bisect. + + Nel mio esempio precedente, il comando grep verifica il sintomo e l'istruzione if usa il risultato di questo controllo per assicurarsi di fornire la stessa informazione al comando hg bisect. La funzione miotest ci permette di riprodurre insieme queste due operazioni, in modo che ogni test sia uniforme e consistente. + + + + Controllate i vostri risultati + + Dato che il risultato di una ricerca con hg bisect è solo tanto buono quanto le informazioni che passate al comando, non prendete il changeset che vi indica come la verità assoluta. Un modo semplice di effettuare un riscontro sul risultato è quello di eseguire manualmente il vostro test su ognuno dei changeset seguenti. + + Il changeset che il comando riporta come la prima revisione guasta. Il vostro test dovrebbe verificare che la revisione sia effettivamente guasta. + + Il genitore di quel changeset (entrambi i genitori, se è un'unione). Il vostro test dovrebbe verificare che quel changeset sia funzionante. + + Un figlio di quel changeset. Il vostro test dovrebbe verificare che quel changeset sia guasto. + + + + + Fate attenzione alle interferenze tra i bug + + È possibile che la vostra ricerca di un bug venga rovinata dalla presenza di un altro bug. Per esempio, diciamo che il vostro software si blocca alla revisione 100 e funziona correttamente alla revisione 50. Senza che voi lo sappiate, qualcun altro ha introdotto un diverso bug bloccante alla revisione 60 e lo ha corretto alla revisione 80. Questo potrebbe distorcere i vostri risultati in vari modi. + + È possibile che questo altro bug mascheri completamente il vostro, cioè che sia comparso prima che il vostro bug abbia avuto la possibilità di manifestarsi. Se non potete evitare quell'altro bug (per esempio, impedisce al vostro progetto di venire assemblato) e quindi non potete dire se il vostro bug è presente in un particolare changeset, il comando hg bisect non è in grado di aiutarvi direttamente. Invece, invocando hg bisect --skip potete indicare un changeset come non collaudato. + + Potrebbe esserci un problema differente se il vostro test per la presenza di un bug non è abbastanza specifico. Se controllate che il mio programma si blocca, allora sia il vostro bug bloccante che il bug bloccante non correlato che lo maschera sembreranno la stessa cosa e fuorvieranno hg bisect. + + Un'altra situazione utile per sfruttare hg bisect --skip è quella in cui non potete collaudare una revisione perché il vostro progetto era guasto e quindi in uno stato non collaudabile in quella revisione, magari perché qualcuno aveva introdotto un cambiamento che impediva al progetto di venire assemblato. + + + + Circoscrivete la vostra ricerca in maniera approssimativa + + Scegliere il primo changeset funzionante e il primo changeset guasto che rappresenteranno i punti estremi della vostra ricerca è spesso facile, ma merita comunque una breve discussione. Dal punto di vista di hg bisect, il changeset più recente è convenzionalmente guasto e il changeset più vecchio è funzionante. + + Se avete problemi a ricordare dove trovare un changeset funzionante da fornire al comando hg bisect, non potreste fare di meglio che collaudare changeset a caso. Ricordatevi di eliminare i contendenti che non possono esibire il bug (magari perché la funzione con il bug non era ancora presente) e quelli in cui un altro problema nasconde il bug (come ho discusso in precedenza). + + Anche se i vostri tentativi si concludono in anticipo di migliaia di changeset o di mesi di cronologia, aggiungerete solo una manciata di test al numero totale che hg bisect deve eseguire, grazie al suo comportamento logaritmico. + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch10-hook.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch10-hook.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,796 @@ + + + Usare gli hook per gestire gli eventi nei repository + + Mercurial vi offre un potente meccanismo per effettuare azioni automatiche in risposta agli eventi che accadono in un repository. In alcuni casi, potete persino controllare la risposta di Mercurial a questi eventi. + + Il nome che Mercurial usa per indicare una di queste azioni è hook (letteralmente, gancio). Gli hook vengono chiamati trigger (letteralmente, grilletto) in alcuni sistemi di controllo di revisione, ma i due nomi si riferiscono alla stessa idea. + + + Un'introduzione agli hook di Mercurial + + Qui di seguito troverete una breve lista degli hook supportati da Mercurial. Rivisiteremo ognuno di questi hook in maggior dettaglio più avanti, nella . + + Ognuno degli hook che viene indicato come hook di controllo 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. + + + changegroup: viene eseguito dopo che un gruppo di changeset proveniente da qualche altra parte è stato propagato nel repository. + + commit: viene eseguito dopo la creazione di un nuovo changeset nel repository locale. + + incoming: viene eseguito una volta per ogni nuovo changeset proveniente da qualche altra parte che è stato propagato nel repository. Notate la differenza con changegroup, che viene eseguito una volta per ogni gruppo di changeset propagato nel repository. + + outgoing: viene eseguito dopo che un gruppo di changeset è stato trasmesso da questo repository. + + prechangegroup: viene eseguito prima di cominciare a propagare un gruppo di changeset nel repository. + + precommit: + hook di controllo. Viene eseguito prima di cominciare un inserimento. + + preoutgoing: hook di controllo. Viene eseguito prima di cominciare a trasmettere un gruppo di changeset da questo repository. + + pretag: hook di controllo. Viene eseguito prima di creare un'etichetta. + + pretxnchangegroup: 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. + + pretxncommit: 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. + + preupdate: hook di controllo. Viene eseguito prima di cominciare un aggiornamento o un'unione della directory di lavoro. + + tag: viene eseguito dopo la creazione di un'etichetta. + + update: viene eseguito dopo che un'operazione di aggiornamento o di unione della directory di lavoro è stata completata. + + + + + Hook e sicurezza + + + Gli hook vengono eseguiti con i vostri privilegi + + Quando invocate un comando Mercurial in un repository e quel comando causa l'esecuzione di un hook, quell'hook viene eseguito sul vostro sistema, con il vostro account utente, al vostro 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. + + 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 ~/.hgrc globale per quel sistema. + + 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 vostra identità. Per esempio, se estraete i cambiamenti da quel repository tramite hg pull, e il suo file .hg/hgrc definisce un hook outgoing locale, quell'hook verrà eseguito con il vostro account utente anche se non siete il proprietario di quel repository. + + + 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 outgoing verrà eseguito sul server con l'account utente che è stato usato per eseguire il processo server. + + + Per vedere quali hook sono definiti in un repository, usate il comando hg showconfig hooks. Se state lavorando in un repository, ma state comunicando con un repository di cui non siete i proprietari (e.g. usando hg pull o hg incoming), ricordate che sono gli hook dell'altro repository che dovreste controllare, non i vostri. + + + + Gli hook non si propagano + + 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. + + 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. + + 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. + + In una intranet aziendale, questo aspetto è in qualche modo più facile da controllare, dato che per esempio potete fornire un'installazione standard di Mercurial su un file system NFS e usare un file ~/.hgrc globale per definire hook che verranno visti da tutti gli utenti. Tuttavia, come constateremo nella prossima sezione, anche questo approccio ha dei limiti. + + + + Gli hook possono essere sostituiti + + Mercurial vi consente di sostituire una definizione di hook attraverso la sua ridefinizione. Potete disabilitare un hook impostando il suo valore alla stringa vuota, o cambiare il suo comportamento come desiderate. + + Se fate ricorso a un file ~/.hgrc di sistema o globale che definisce alcuni hook, dovreste quindi tenere presente che i vostri utenti sono in grado di disabilitare o sostituire quegli hook. + + + + Assicurarsi che gli hook critici vengano eseguiti + + 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 ~/.hgrc globale non avrà effetto sui computer portatili degli utenti remoti, e naturalmente gli utenti locali potranno alterarla a piacimento sostituendo quell'hook. + + Invece, potete istituire le vostre politiche sull'uso di Mercurial in modo che le persone siano tenute a propagare i cambiamenti attraverso un server ufficiale ben noto che avete messo in sicurezza e configurato adeguatamente. + + 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. + + 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. + + + + + + Una breve guida all'uso degli hook + + Scrivere un hook Mercurial è facile. Cominciamo con un hook che viene invocato al termine dell'esecuzione di hg commit e che stampa semplicemente l'hash del changeset appena creato. L'hook è chiamato commit. + + + Tutti gli hook seguono lo schema presentato in questo esempio. + + &interaction.hook.simple.init; + + Aggiungete una voce alla sezione hooks del vostro file ~/.hgrc. 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 HG_NODE nell'esempio). + + + Effettuare molteplici azioni per evento + + Vi capiterà piuttosto spesso di voler definire più di un hook per un particolare tipo di evento, come mostrato qui sotto. + + &interaction.hook.simple.ext; + + Mercurial vi permette di fare questo aggiungendo un'estensione 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 .), seguito da altro testo di vostra scelta. Per esempio, Mercurial eseguirà sia commit.foo che commit.bar all'occorrenza dell'evento commit. + + 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à commit.bar prima di commit.foo, e commit prima di entrambi. + + 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 per un esempio). + + + + Controllare se un'attività può procedere + + Nei nostri primi esempi, abbiamo usato l'hook commit, 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. + + 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. + + L'hook pretxncommit 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 pretxncommit ha la capacità di decidere se la transazione può completarsi oppure se deve essere abortita. + + Se l'hook pretxncommit termina con un codice di stato uguale a zero, la transazione può completare, il commit si conclude e l'hook commit viene eseguito. Se l'hook pretxncommit termina con un codice di stato diverso da zero, la transazione viene abortita, i metadati che rappresentano il changeset vengono cancellati e l'hook commit non viene eseguito. + + &interaction.hook.simple.pretxncommit; + + 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. + + + + + Implementare i vostri hook + + Quando state scrivendo un hook, potreste trovare utile eseguire Mercurial con l'opzione oppure con l'elemento di configurazione verbose impostato a vero, in modo che Mercurial stampi un messaggio prima di invocare qualsiasi hook. + + + Scegliere la modalità di esecuzione del vostro hook + + 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. + + 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. + + Un hook Python interno ha accesso completo alla API di Mercurial e non deve pagare la creazione di un altro processo, quindi è intrinsecamente più veloce rispetto a un hook esterno. Per ottenere la maggior parte delle informazioni richieste da un hook è anche più facile usare la API di Mercurial che eseguire i comandi Mercurial. + + Se siete a vostro agio con Python, o avete bisogno di prestazioni elevate, implementare i vostri hook in Python potrebbe essere una buona scelta. Tuttavia, quando il vostro hook è semplice da scrivere e le prestazioni non vi interessano (cose che probabilmente capitano per la maggior parte degli hook), uno script di shell è perfettamente adeguato. + + + + I parametri di hook + + 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. + + 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 vero) o 0 (per falso) per un hook esterno. Se il nome di un parametro di hook è foo, anche l'argomento con nome per un hook Python sarà chiamato foo, mentre la variabile d'ambiente per un hook esterno sarà chiamata HG_FOO. + + + + I valori di ritorno degli hook e il controllo delle attività + + Un hook che viene eseguito con successo deve terminare con uno stato uguale a zero se è esterno, o restituire il valore booleano falso se è interno. Il fallimento viene indicato con uno stato di terminazione diverso da zero per un hook esterno, o dal valore booleano vero per un hook interno. Se un hook interno solleva un'eccezione, l'hook si considera fallito. + + Per un hook che controlla se un'attività può procedere, zero o falso significano concesso, mentre un numero diverso da zero, vero, o un'eccezione significano negato. + + + + Scrivere un hook esterno + + Quando definite un hook esterno nel vostro file ~/.hgrc 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. + + Un hook eseguibile viene sempre eseguito con la sua directory corrente impostata alla directory radice del repository. + + Ogni parametro di hook viene passato come una variabile d'ambiente con il nome in maiuscolo preceduto dalla stringa HG_. + + 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. + + + + Dire a Mercurial di usare un hook interno + + La sintassi del file ~/.hgrc per definire un hook interno è leggermente differente da quella per un hook eseguibile. Il valore dell'hook deve cominciare con il testo python: e proseguire con il nome completamente qualificato dell'oggetto invocabile da usare come valore dell'hook. + + 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 PYTHONPATH siano corretti, l'importazione dovrebbe funzionare e basta. + + Il seguente frammento di un file ~/.hgrc di esempio illustra la sintassi e il significato delle nozioni appena descritte. + [hooks] +commit.esempio = python:miomodulo.sottomodulo.miohook + Quando Mercurial esegue l'hook commit.esempio, importa miomodulo.sottomodulo, cerca l'oggetto invocabile chiamato miohook e lo invoca. + + + + Implementare un hook interno + + Il più semplice hook interno non fa nulla, ma illustra la forma base della API degli hook: + def miohook(ui, repo, **kwargs): + pass + Il primo argomento di un hook Python è sempre un oggetto mercurial.ui.ui. Il secondo è un oggetto repository, al momento sempre un'istanza di mercurial.localrepo.localrepository. 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 **kwargs qui sopra. + + + + + Alcuni hook di esempio + + + Scrivere messaggi di commit significativi + + È difficile immaginare un messaggio di commit utile che sia anche molto breve. Il semplice hook pretxncommit dell'esempio seguente vi impedirà di esguire il commit di un changeset con un messaggio più piccolo di quindici byte. + + &interaction.hook.msglen.go; + + + + Controllare lo spazio bianco in coda + + Un uso interessante per un hook relativo ai commit è quello di aiutarvi a scrivere codice più pulito. Un semplice esempio di codice più pulito è la regola per cui un cambiamento non dovrebbe aggiungere nessuna nuova riga di testo contenente spazio bianco in coda. 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. + + Potete usare l'hook precommit o l'hook pretxncommit per scoprire se avete un problema di spazio bianco in coda. Se usate precommit, 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 foo, ma il flie bar contiene spazio bianco in coda, effettuare un controllo tramite l'hook precommit vi impedirà di eseguire il commit di foo a causa dei problemi con bar. Questo comportamento non sembra corretto. + + Se doveste scegliere l'hook pretxncommit, 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 hg commit. + + &interaction.ch09-hook.ws.simple; + + In questo esempio, abbiamo introdotto un semplice hook pretxncommit 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. + + &ch09-check_whitespace.py.lst; + + 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. Anche meglio, 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 possiate usare l'opzione del comando hg commit per riutilizzare il messaggio di commit salvato una volta che avete corretto il problema. + + &interaction.ch09-hook.ws.better; + + Come ultima nota a margine, osservate in questo esempio l'uso della funzione di modifica sul posto di sed per eliminare lo spazio bianco in coda da un file. Questo impiego è sufficientemente conciso e utile che lo riprodurrò qui di seguito (usando perl per sicurezza). + perl -pi -e 's,\s+$,,' nomefile + + + + + Hook inclusi + + Mercurial viene distribuito con diversi hook inclusi che potete trovare nella directory hgext dell'albero dei sorgenti di Mercurial. Se state usando un pacchetto precompilato di Mercurial, gli hook si trovano nella directory hgext posizionata ovunque il vostro pacchetto abbia installato Mercurial. + + + <literal role="hg-ext">acl</literal>&emdash;controllo di accesso per parti di un repository + + L'estensione acl 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. + + Questa estensione implementa il controllo di accesso sulla base dell'identità dell'utente che effettua la trasmissione, non 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. + + + Configurare l'hook <literal role="hook">acl</literal> + + Per gestire i cambiamenti in entrata, l'hook acl deve essere usato come un hook pretxnchangegroup. 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 proibito. Ecco un esempio di come attivare l'hook: + [hooks] +pretxnchangegroup.acl = python:hgext.acl.hook + + L'estensione acl si configura usando tre sezioni. + + La sezione acl contiene solo la voce sources, 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. + + serve: controlla i changeset in entrata che arrivano da un repository remoto via HTTP o ssh. Questo è il valore predefinito di sources e di solito è l'unica impostazione di cui avrete bisogno per questo elemento di configurazione. + + pull: controlla i changeset in entrata che arrivano attraverso un'estrazione da un repository locale. + + push: controlla i cambiamenti in entrata che arrivano attraverso una trasmissione da un repository locale. + + bundle: controlla i changeset in entrata che arrivano da un altro repository attraverso un bundle.FIXME Cos'è un bundle? + + + La sezione acl.allow controlla gli utenti a cui è permesso aggiungere changeset al repository. Se questa sezione non è presente, il permesso viene concesso a tutti gli utenti a cui non viene esplicitamente negato. Se questa sezione è presente, il permesso viene negato a tutti gli utenti a cui non viene esplicitamente concesso (quindi una sezione vuota significa che il permesso viene negato a tutti gli utenti). + + La sezione acl.deny determina quali sono gli utenti a cui viene impedito di aggiungere changeset al repository. Se questa sezione non è presente o è vuota, tutti gli utenti hanno il permesso di aggiungere modifiche. + + La sintassi per le sezioni acl.allow e acl.deny è 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. + + Nell'esempio seguente, l'utente manualista può trasmettere cambiamenti solo al sottoalbero doc del repository, mentre l'utente stagista può trasmettere cambiamenti a qualsiasi file o directory tranne sorgenti/sensibili. + + [acl.allow] +doc/** = manualista +[acl.deny] +sorgenti/sensibili/** = stagista + + + + Collaudo e risoluzione dei problemi + + Se volete collaudare l'hook acl, 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 , non dimenticatevi che potete abilitare le informazioni di debug nel vostro file ~/.hgrc: + + [ui] +debug = true + Con questa opzione abilitata, l'hook acl stamperà abbastanza informazioni da permettervi di capire perché sta consentendo o vietando le trasmissioni da specifici utenti. + + + + + + <literal + role="hg-ext">bugzilla</literal>&emdash;integrazione con Bugzilla + + L'estensione bugzilla 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. + + L'hook aggiunge al bug un commento che somiglia a questo (potete configurare i contenuti del commento, come vedrete fra un attimo): + Changeset aad8b264143a, creato da Mario Rossi + <mario.rossi@example.com> nel repository vattelapesca, + fa riferimento a questo bug. + Per i dettagli completi, si veda + http://hg.example.com/vattelapesca?cmd=changeset;node=aad8b264143a + Descrizione del changeset: risolto bug 10483 proteggendo il codice da alcuni + puntatori NULL. + 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. + + Potete usare il codice di questo hook come un punto di partenza per ricette più esotiche di integrazione con Bugzilla. Ecco alcune possibilità. + + 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 pretxncommit per consentirgli di rifiutare i cambiamenti che non contengono identificatori di bug. + + Permettere ai changeset in entrata di modificare automaticamente lo stato di un bug, come pure di aggiungere semplicemente un commento. Per esempio, l'hook potrebbe riconoscere la stringa risolto bug 31337 come il segnale che indica la necessità di aggiornare lo stato del bug 31337 a richiede un collaudo. + + + + Configurare l'hook <literal role="hook">bugzilla</literal> + + Dovreste configurare questo hook nel file ~/.hgrc del vostro server come un hook incoming, per esempio nel modo seguente: + [hooks] +incoming.bugzilla = python:hgext.bugzilla.hook + + 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. + + 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 web:mysql-python. + + + Le informazioni di configurazione per questo hook si trovano nella sezione bugzilla del vostro file ~/.hgrc. + + + version: 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. + + host: 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 bugzilla. + + + user: 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 bugzilla. Questo utente deve essere in grado di modificare le tabelle di Bugzilla. Il valore predefinito di questo elemento è bugs, che è il nome standard dell'utente Bugzilla in un database MySQL. + + password: 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 ~/.hgrc dove avete inserito questa informazione. + + db: il nome del database Bugzilla sul server MySQL. Il valore predefinito di questo elemento è bugs, che è il nome standard del database MySQL dove Bugzilla memorizza i propri dati. + + notify: se volete che Bugzilla spedisca un'email di notifica agli interessati dopo che questo hook ha aggiunto un commento a un bug, avrete bisogno 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 /var/www/html/bugzilla: + cd /var/www/html/bugzilla && + ./processmail %s nessuno@example.com + Il programma processmail di Bugzilla si aspetta che gli vengano passati un identificatore di bug (l'hook sostituisce %s 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 processmail sul server dove Bugzilla è installato. + + + + + Correlare i nomi utente Mercurial ai nomi utente Bugzilla + + Per default, l'hook bugzilla 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 usermap. + + Ogni elemento nella sezione usermap contiene un indirizzo email sulla sinistra e un nome utente Bugzilla sulla destra. + [usermap] +maria.bianchi@example.com = maria + Potete tenere i dati della sezione usermap in un normale file ~/.hgrc, oppure dire all'hook bugzilla di leggere le informazioni da un file usermap esterno. In quest'ultimo caso, potete memorizzare i dati del file usermap 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 usermap. Il file ~/.hgrc principale potrebbe somigliare a questo: + # il normale file hgrc fa riferimento a un file di correlazioni esterno +[bugzilla] +usermap = /home/hg/repos/datiutente/bugzilla-usermap.conf + Mentre il file usermap a cui fa riferimento potrebbe somigliare a questo: + # bugzilla-usermap.conf - all'interno di un repository Mercurial +[usermap] +stefania@example.com = stef + + + + Configurare il testo che viene aggiunto a un bug + + Potete configurare il testo che questo hook aggiunge come commento specificandolo sotto forma di template Mercurial. Diverse voci del file ~/.hgrc (sempre nella sezione bugzilla) controllano questo comportamento. + + strip: 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 /home/hg/repos, e voi avete un repository il cui percorso è /home/hg/repos/app/test, allora impostando strip a 4 otterrete il percorso parziale app/test. L'hook renderà disponibile questo percorso parziale con il nome webroot durante l'espansione di un template. + + template: il testo del template da usare. In aggiunta alle solite variabili relative ai changeset, questo template può usare hgweb (il valore dell'elemento di configurazione hgweb menzionato in precedenza) e webroot (il percorso costruito usando l'elemento strip appena descritto). + + + In più, potete aggiungere un elemento baseurl alla sezione web del vostro file ~/.hgrc. L'hook bugzilla 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: + [web] +baseurl = http://hg.example.com/ + + Ecco un esempio dell'insieme di informazioni di configurazione da usare per l'hook bugzilla. + + &ch10-bugzilla-config.lst; + + + + Collaudo e risoluzione dei problemi + + I problemi più comuni con la configurazione dell'hook bugzilla sono relativi all'esecuzione dello script processmail di Bugzilla e alla correlazione tra nomi utente Mercurial e nomi utente Bugzilla. + + Se ricordate quanto detto nella , l'utente che esegue il processo Mercurial sul server è anche quello che eseguirà lo script processmail. 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. + + Potete far eseguire processmail con un'identità utente appropriata tramite il comando sudo. Ecco una voce di esempio da un file sudoers. + hg_user = (httpd_user) +NOPASSWD: /var/www/html/bugzilla/processmail-wrapper %s + Questo consente all'utente hg_user di eseguire il programma processmail-wrapper sotto l'identità dell'utente httpd_user. + + Questa invocazione indiretta attraverso uno script che funge da involucro è necessaria, perché processmail 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 sudoers. Il contenuto dello script involucro è semplice: + #!/bin/sh +cd `dirname $0` && ./processmail "$1" nessuno@example.com + Non sembra che l'indirizzo email passato a processmail abbia importanza. + + Se la vostra sezione usermap non è impostata correttamente, gli utenti vedranno un messaggio di errore stampato dall'hook bugzilla al momento di trasmettere i cambiamenti al server. Il messaggio di errore somiglierà al seguente: + impossibile trovare un nome utente bugzilla per mario.rossi@example.com + Questo significa che l'indirizzo email dell'utente Mercurial, mario.rossi@example.com, non è un nome utente Bugzilla valido, né possiede una voce nella vostra sezione usermap che lo metta in relazione con un nome utente Bugzilla valido. + + + + + + <literal role="hg-ext">notify</literal>&emdash;inviare notifiche via email + + 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 notify vi permette di inviare notifiche a un insieme di indirizzi email ogni volta che arrivano changeset a cui quelle persone sono interessate. + + Come l'hook bugzilla, anche l'hook notify è guidato da un template, in modo che possiate personalizzare il contenuto dei messaggi di notifica inviati. + + Per default, l'hook notify 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. + + + Configurare l'hook <literal role="hg-ext">notify</literal> + + Potete impostare l'hook notify 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). + [hooks] +# spedisci un'email per gruppo di cambiamenti +changegroup.notify = python:hgext.notify.hook +# spedisci un'email per cambiamento +incoming.notify = python:hgext.notify.hook + + Le informazioni di configurazione per questo hook si trovano nella sezione notify del file ~/.hgrc. + + test: per default, questo hook non spedisce alcuna email, ma stampa il messaggio che avrebbe inviato. Impostate questo elemento a false per consentire la spedizione delle email. La ragione per cui la spedizione delle email è disabilitata per default è che ci vogliono diverse prove per configurare questa estensione esattamente come vorreste, e non starebbe bene infastidire gli interessati con un certo numero di notifiche guaste mentre correggete la vostra configurazione. + + config: il percorso di un file di configurazione che contiene le informazioni di iscrizione. Questo viene tenuto separato dal file ~/.hgrc principale in modo che possiate mantenerlo in un proprio repository. Le persone possono poi clonare quel repository, aggiornare le proprie iscrizioni e trasmettere i cambiamenti al vostro server. + + strip: il numero di parti iniziali da eliminare dal percorso di un repository quando state decidendo se è possibile iscriversi al servizio di notifica per un repository. Per esempio, se i repository sul vostro server si trovano in /home/hg/repos, e notify sta considerando un repository chiamato /home/hg/repos/condivisi/test, impostare strip a 4 farà in modo che notify restringa il percorso da considerare a condivisi/test e associ le iscrizioni a questo percorso. + + template: il testo del template da usare per inviare i messaggi. Questo specifica i contenuti sia delle intestazioni che del corpo del messaggio. + + maxdiff: il massimo numero di righe di dati di diff da aggiungere alla fine di un messaggio. Se un diff è più lungo di questo limite, viene troncato. Per default, questo valore è impostato a 300. Impostate questo valore a 0 per omettere i diff dalle email di notifica. + + sources: una lista di modalità di provenienza dei changeset da considerare. Questo vi permette di limitare notify in modo che spedisca email riguardanti solo utenti remoti che hanno trasmesso modifiche a questo repository attraverso un server, per esempio. Leggete la per sapere quali modalità potete specificare qui. + + + Se impostate l'elemento baseurl nella sezione web, potete usarlo in un template, dove sarà disponibile con il nome webroot. + + Ecco un esempio dell'insieme di informazioni di configurazione da usare per l'hook notify. + + &ch10-notify-config.lst; + + Questo produrrà un messaggio che somiglierà al seguente: + + &ch10-notify-config-mail.lst; + + + + Collaudo e risoluzione dei problemi + + Non dimenticate che il comportamento predefinito dell'estensione notify è quello di non spedire alcuna mail fino a quando non lo avete esplicitamente configurato per farlo, impostando test a false. Fino a quel momento, si limiterà a stampare il messaggio che avrebbe inviato. + + + + + + Informazioni per gli implementatori di hook + + + Esecuzione degli hook interni + + Un hook interno viene invocato con argomenti della forma seguente: + def miohook(ui, repo, **kwargs): + pass + Il parametro ui è un oggetto di tipo mercurial.ui.ui. Il parametro repo è un oggetto di tipo mercurial.localrepo.localrepository. I nomi e i valori dei parametri **kwargs dipendono dall'hook coinvolto, ma hanno le seguenti caratteristiche comuni: + + Se un parametro si chiama node o parentN, conterrà un identificatore esadecimale di changeset. La stringa vuota viene usata per rappresentare l'identificatore di changeset nullo invece di una stringa di zeri. + + Se un parametro si chiama url, conterrà l'URL di un repository remoto, nel caso possa essere determinato. + + I parametri con valore booleano vengono rappresentati come oggetti Python di tipo bool. + + + 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. + + Se un hook restituisce il valore booleano falso, si considera terminato con successo. Se restituisce il valore booleano vero oppure solleva un'eccezione, si considera fallito. Un modo utile di pensare a questa convenzione di esecuzione è dimmi se hai fallito. + + 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 mercurial.node.bin. + + + + + Esecuzione degli hook esterni + + 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). + + 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 HG_. Per esempio, se il nome di un parametro è node, il nome della variabile d'ambiente che rappresenta quel parametro sarà HG_NODE. + + Un parametro booleano è rappresentato come la stringa 1 se è vero o 0 se è falso. Se una variabile d'ambiente è chiamata HG_NODE, HG_PARENT1, o HG_PARENT2, conterrà un identificatore di changeset rappresentato come una stringa esadecimale. La stringa vuota viene usata per rappresentare l'identificatore di changeset nullo invece di una stringa di zeri. Se una variabile d'ambiente è chiamata HG_URL, conterrà l'URL di un repository remoto, nel caso possa essere determinato. + + 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. + + + + Scoprire da dove vengono i changeset + + Un hook che coinvolge il trasferimento di changeset tra un repository locale e un altro potrebbe essere in grado di trovare informazioni sul lato opposto. Mercurial conosce il modo in cui i cambiamenti vengono trasferiti e in molti casi conosce anche l'ubicazione del luogo da cui o verso cui vengono trasferiti. + + + Le fonti dei changeset + + 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 source o in una variabile d'ambiente chiamata HG_SOURCE. + + + serve: i changeset sono trasferiti da o verso un repository remoto via HTTP o ssh. + + pull: i changeset sono trasferiti attraverso un'estrazione da un repository a un altro. + + push: i changeset sono trasferiti attraverso una trasmissione da un repository a un altro. + + bundle: i changeset sono trasferiti da o verso un bundle. + + + + + La destinazione dei cambiamenti&emdash;gli URL dei repository remoti + + Quando è possibile, Mercurial dirà a un hook l'ubicazione del lato opposto di un'attività che trasferisce i dati dei changeset tra repository, fornendo questa informazione in un parametro Python chiamato url o in una variabile d'ambiente chiamata HG_URL. + + 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: + + remote:ssh:1.2.3.4&emdash;client ssh remoto, all'indirizzo IP 1.2.3.4. + + remote:http:1.2.3.4&emdash;client HTTP remoto, all'indirizzo IP 1.2.3.4. Se il client sta usando SSL, questo URL sarà nella forma remote:https:1.2.3.4. + + Vuoto&emdash;Mercurial non è riuscito a scoprire nessuna informazione sul client remoto. + + + + + + Guida di riferimento agli hook + + + <literal role="hook">changegroup</literal>&emdash;dopo l'aggiunta di changeset remoti + + Questo hook viene eseguito dopo che un gruppo di changeset preesistenti è stato aggiunto al repository, per esempio tramite hg pull o hg unbundle. Questo hook viene eseguito una volta per ogni operazione che aggiunge uno o più changeset, a differenza dell'hook incoming, che viene eseguito una volta per ogni changeset a prescindere dal fatto che il changeset sia arrivato in un gruppo. + + 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. + + I parametri di questo hook sono i seguenti. + + node: un identificatore di changeset. L'identificatore del primo changeset nel gruppo che è stato aggiunto. Tutti i changeset tra questo e tip compresi sono stati aggiunti da una singola invocazione di hg pull, hg push, o hg unbundle. + + source: una stringa. La fonte di questi cambiamenti. Si veda la per i dettagli. + + url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per maggiori informazioni. + + + Si vedano anche gli hook incoming (), prechangegroup () e pretxnchangegroup (). + + + + <literal role="hook">commit</literal>&emdash;dopo la creazione di un nuovo changeset + + Questo hook viene eseguito dopo che un nuovo changeset è stato creato. + + I parametri di questo hook sono i seguenti. + + node: un identificatore di changeset. L'identificatore del changeset appena inserito. + + parent1: un identificatore di changeset. L'identificatore di changeset del primo genitore del changeset appena inserito. + + parent2: un identificatore di changeset. L'identificatore di changeset del secondo genitore del changeset appena inserito. + + + Si vedano anche gli hook precommit () e pretxncommit (). + + + + <literal role="hook">incoming</literal>&emdash;dopo l'aggiunta di un changeset remoto + + Questo hook viene eseguito dopo che un changeset preesistente è stato aggiunto al repository, per esempio attraverso l'invocazione di hg push. Se un gruppo di changeset è stato aggiunto in una singola operazione, questo hook viene eseguito una volta per ogni changeset aggiunto. + + Potete usare questo hook per gli stessi scopi dell'hook changegroup (). A volte è semplicemente più comodo eseguire un hook per ogni gruppo di changeset, mentre altre volte è più conveniente eseguirlo per ogni changeset. + + I parametri di questo hook sono i seguenti. + + node: un identificatore di changeset. L'identificatore del changeset appena aggiunto. + + source: una stringa. La fonte di questi cambiamenti. Si veda la per i dettagli. + + url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per maggiori informazioni. + + + Si vedano anche gli hook changegroup (), prechangegroup () e pretxnchangegroup (). + + + + <literal role="hook">outgoing</literal>&emdash;dopo la propagazione dei changeset + + 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 hg push o hg bundle. + + Un possibile impiego di questo hook è quello di notificare gli amministratori di un repository che alcuni cambiamenti sono stati estratti. + + I parametri di questo hook sono i seguenti. + + node: un identificatore di changeset. L'identificatore del primo changeset del gruppo che è stato propagato. + + source: una stringa. La fonte dell'operazione (si veda la ). Se un client remoto ha estratto i cambiamenti da questo repository, il valore di source sarà serve. Se il client che ha ottenuto i cambiamenti di questo repository era locale, il valore di source sarà bundle, pull, o push, a seconda dell'operazione effettuata dal client. + + url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per maggiori informazioni. + + + Si veda anche l'hook preoutgoing (). + + + + <literal role="hook">prechangegroup</literal>&emdash;prima di cominciare ad aggiungere changeset remoti + + Questo hook di controllo viene eseguito prima che Mercurial cominci ad aggiungere un gruppo di changeset proveniente da un altro repository. + + Questo hook non possiede alcuna informazione sui changeset che verranno aggiunti, perché viene eseguito prima che la trasmissione di quei changeset possa cominciare. Se questo hook fallisce, i changeset non verranno trasmessi. + + Un possibile impiego di questo hook è quello di evitare che i cambiamenti vengano aggiunti a un repository. Per esempio, potreste usarlo per congelare temporaneamente o permanentemente un ramo ospitato su un server in modo che gli utenti non possano trasmettervi alcuna modifica, consentendo comunque a un amministratore locale di modificare il repository. + + I parametri di questo hook sono i seguenti. + + source: una stringa. La fonte di questi cambiamenti. Si veda la per i dettagli. + + url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per maggiori informazioni. + + + Si vedano anche gli hook changegroup (), incoming () e pretxnchangegroup (). + + + + <literal role="hook">precommit</literal>&emdash;prima di cominciare l'inserimento di un changeset + + 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. + + 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. + + I parametri di questo hook sono i seguenti. + + parent1: un identificatore di changeset. L'identificatore di changeset del primo genitore della directory di lavoro. + + parent2: un identificatore di changeset. L'identificatore di changeset del secondo genitore della directory di lavoro. + + Se l'inserimento procede, i genitori della directory di lavoro diventeranno i genitori del nuovo changeset. + + Si vedano anche gli hook commit () e pretxncommit (). + + + + <literal role="hook">preoutgoing</literal>&emdash;prima di cominciare la propagazione dei changeset + + Questo hook viene invocato prima che Mercurial conosca le identità dei changeset da trasmettere. + + Un possibile impiego di questo hook è quello di evitare che i changeset vengano trasmessi a un altro repository. + + I parametri di questo hook sono i seguenti. + + source: una stringa. La fonte dell'operazione che sta tentando di ottenere i cambiamenti da questo repository (si veda la ). Leggete la documentazione del parametro source dell'hook outgoing nella per conoscere i possibili valori di questo parametro. + + url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per maggiori informazioni. + + + Si veda anche l'hook outgoing (). + + + + <literal role="hook">pretag</literal>&emdash;prima di etichettare un changeset + + 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. + + I parametri di questo hook sono i seguenti. + + local: un booleano. Indica se l'etichetta è locale a questa istanza del repository (i.e. memorizzata nel file .hg/localtags) o se è gestita da Mercurial (memorizzata nel file .hgtags). + + node: un identificatore di changeset. L'identificatore del changeset da etichettare. + + tag: una stringa. Il nome dell'etichetta da creare. + + + Se l'etichetta da creare è soggetta a controllo di revisione, verranno eseguiti anche gli hook precommit e pretxncommit ( e ). + + Si veda anche l'hook tag (). + + + + <literal + role="hook">pretxnchangegroup</literal>&emdash;prima di completare l'aggiunta di changeset remoti + + 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. + + 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. + + 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. + + Questo hook può essere usato per esaminare automaticamente un gruppo di changeset. Se l'hook fallisce, tutti i changeset vengono respinti quando la transazione viene abortita. + + I parametri di questo hook sono i seguenti. + + node: un identificatore di changeset. L'identificatore del primo changeset nel gruppo che è stato aggiunto. Tutti i changeset tra questo e tip compresi sono stati aggiunti da una singola invocazione di hg pull, hg push, o hg unbundle. + + source: una stringa. La fonte di questi cambiamenti. Si veda la per i dettagli. + + url: un URL. L'ubicazione del repository remoto, nel caso sia nota. Si veda la per maggiori informazioni. + + + Si vedano anche gli hook changegroup (), incoming () e prechangegroup (). + + + + <literal role="hook">pretxncommit</literal>&emdash;prima di completare l'inserimento di un nuovo changeset + + 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. + + 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. + + 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. + + I parametri di questo hook sono i seguenti. + + + node: un identificatore di changeset. L'identificatore del changeset sul punto di essere inserito. + + parent1: un identificatore di changeset. L'identificatore di changeset del primo genitore del changeset sul punto di essere inserito. + + parent2: un identificatore di changeset. L'identificatore di changeset del secondo genitore del changeset sul punto di essere inserito. + + + Si veda anche l'hook precommit (). + + + + <literal role="hook">preupdate</literal>&emdash;prima di eseguire un aggiornamento o un'unione della directory di lavoro + + 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'aggiornameno o l'unione non vengono cominciati. + + I parametri di questo hook sono i seguenti. + + parent1: 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. + + parent2: 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. + + + Si veda anche l'hook update (). + + + + <literal role="hook">tag</literal>&emdash;dopo aver etichettato un changeset + + Questo hook viene eseguito dopo la creazione di un'etichetta. + + I parametri di questo hook sono i seguenti. + + local: un booleano. Indica se l'etichetta è locale a questa istanza del repository (i.e. memorizzata nel file .hg/localtags) o se è gestita da Mercurial (memorizzata nel file .hgtags). + + node: un identificatore di changeset. L'identificatore del changeset che è stato etichettato. + + tag: una stringa. Il nome dell'etichetta creata. + + + Se l'etichetta creata è soggetta a controllo di revisione, l'hook commit () verrà eseguito prima di questo hook. + + Si veda anche l'hook pretag (). + + + + <literal role="hook">update</literal>&emdash;dopo aver eseguito un aggiornamento o un'unione della directory di lavoro + + 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 hgmerge 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. + + I parametri di questo hook sono i seguenti. + + error: un booleano. Indica se l'aggiornamento o l'unione sono stati completati con successo. + + parent1: 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. + + parent2: 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. + + + Si veda anche l'hook preupdate (). + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch11-template.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch11-template.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,338 @@ + + + Personalizzare i messaggi di Mercurial + + Mercurial vi offre un potente meccanismo basato sui template 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. + + + Usare gli stili di formattazione già pronti + + 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. + + Prima di dare un'occhiata agli stili distribuiti con Mercurial, rivediamo il normale risultato di un suo comando. + + &interaction.template.simple.normal; + + Questo messaggio ci dà alcune informazioni, ma porta via molto spazio&emdash;cinque righe per ogni changeset. Lo stile compact riduce questo spazio a tre righe, presentate in maniera sparsa. + + &interaction.template.simple.compact; + + Lo stile changelog ci dà un'idea 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 web:changelog. + + &interaction.template.simple.changelog; + + Non vi sorprenderà sapere che lo stile di formattazione predefinito di Mercurial è chiamato default. + + + Impostare uno stile predefinito + + Potete modificare lo stile di formattazione che Mercurial userà per ogni comando aggiungendo al vostro file ~/.hgrc il nome dello stile che preferireste usare. + + [ui] +style = compact + + Se create un vostro stile, potete usarlo inserendo il percorso del vostro file di stile, oppure copiando il vostro file di stile in un luogo dove Mercurial possa trovarlo (tipicamente la sottodirectory templates della vostra directory di installazione di Mercurial). + + + + + Comandi che supportano stili e template + + Tutti i comandi Mercurial di tipo log vi permettono di usare stili e template: hg incoming, hg log, hg outgoing e hg tip. + + Al momento di scrivere questo manuale, quelli elencati sono i comandi che finora supportano stili e template. Dato che questi sono i comandi più importanti che necessitino di una formattazione personalizzabile, la comunità utenti di Mercurial non ha fatto molta pressione per aggiungere il supporto per stili e template ad altri comandi. + + + + Nozioni di base sui template + + Nella sua forma più semplice, un template Mercurial è un frammento di testo. Parte del testo non cambia mai, mentre altre parti vengono espanse, cioè sostituite con nuovo testo, quando è necessario. + + Prima di continuare, diamo un'altra occhiata al semplice esempio del normale risultato di un comando Mercurial. + + &interaction.template.simple.normal; + + Ora, eseguiamo lo stesso comando, ma usando un template per cambiare il messaggio visualizzato. + + &interaction.template.simple.simplest; + + Questo esempio illustra il template più semplice possibile, composto solo da un messaggio di testo statico stampato una volta per ogni changeset. L'opzione del comando hg log dice a Mercurial di usare il testo dato come template per stampare ogni changeset. + + Notate che la stringa di template appena usata termina con il testo \n. Questa è una sequenza di escape 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 per maggiori dettagli sulle sequenze di escape. + + Un template che stampa una stringa di testo fissa tutte le volte non è molto utile, perciò proviamo qualcosa di un po' più complesso. + + &interaction.template.simple.simplesub; + + Come potete vedere, la stringa {desc} nel template è stata sostituita con la descrizione di ogni changeset nel messaggio. Ogni volta che Mercurial trova un testo racchiuso tra parentesi graffe ({ e }), 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 . + + + + Parole chiave comuni nei template + + Potete cominciare immediatamente a scrivere semplici template usando le seguenti parole chiave. + + + author: stringa. Il nome non modificato dell'autore del changeset. + + branches: stringa. Il nome del ramo su cui il changeset è stato inserito. Sarà vuoto se il nome del ramo è default. + + date: informazioni di data. La data in cui il changeset è stato inserito. Questa informazione non è rappresentata in maniera comprensibile, bensì dovete passarla attraverso un filtro per presentarla in maniera appropriata. Leggete la 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. + + desc: stringa. Il testo della descrizione del changeset. + + files: lista di stringhe. Tutti i file modificati, aggiunti, o rimossi da questo changeset. + + file_adds: lista di stringhe. I file aggiunti da questo changeset. + + file_dels: lista di stringhe. I file rimossi da questo changeset. + + node: stringa. L'hash di identificazione del changeset, sotto forma di una stringa esadecimale di 40 caratteri. + + parents: lista di stringhe. I genitori del changeset. + + rev: intero. Il numero di revisione del changeset locale per il repository. + + tags: lista di stringhe. Qualsiasi etichetta associata al changeset. + + + + Alcuni semplici esperimenti ci mostreranno cosa aspettarci quando usiamo queste parole chiave. Potete vederne i risultati qui di seguito. + + &interaction.template.simple.keywords; + + 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 filtri, che verranno trattati in maniera più approfondita nella . + + &interaction.template.simple.datekeyword; + + + + Sequenze di escape + + Il motore di template di Mercurial riconosce le sequenze di escape più comunemente usate nelle stringhe. Quando trova un carattere di backslash (\), esamina il carattere successivo e rimpiazza i due caratteri con un unico sostituto, come descritto qui di seguito. + + + \: + backslash, \, corrispondente al codice ASCII 134. + + \n: nuova riga, codice ASCII 12. + + \r: ritorno a capo, codice ASCII 15. + + \t: tabulazione, codice ASCII 11. + + \v: tabulazione verticale, codice ASCII 13. + + \{: parentesi graffa aperta, {, codice ASCII 173. + + \}: parentesi graffa chusa, }, codice ASCII 175. + + + Come appena indicato, se volete che l'espansione di un template contenga un carattere \, {, o { letterale, dovete effettuarne l'escape. + + + + Filtrare le parole chiave per modificarne i risultati + + Alcuni dei risultati dell'espansione dei template non sono immediatamente facili da usare. Mercurial vi permette di specificare una catena opzionale di filtri per modificare il risultato dell'espansione di una parola chiave. Avete già visto in azione un filtro comune, isodate, usato precedentemente per rendere leggibile una data. + + 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. + + + addbreaks: qualunque testo. Aggiunge un elemento XHTML <br/> prima della fine di ogni riga tranne l'ultima. Per esempio, foo\nbar diventa foo<br/>\nbar. + + age: parola chiave date. Rappresenta l'età della data, relativa all'ora corrente. Produce stringhe come 10 minuti. + + basename: qualunque testo, ma utile soprattutto per la parola chiave files e simili. Tratta il testo come un percorso e restituisce il nome di base. Per esempio, foo/bar/baz diventa baz. + + date: parola chiave date. Presenta una data in un formato simile al comando Unix date, ma includendo il fuso orario. Produce stringhe come Mon Sep 04 15:13:13 2006 -0700. + + domain: qualunque testo, ma utile soprattutto per la parola chiave author. Trova la prima stringa che somiglia a un indirizzo email e ne estrae il componente del dominio. Per esempio, Bryan O'Sullivan <bos@serpentine.com> diventa serpentine.com. + + email: qualunque testo, ma utile soprattutto per la parola chiave author. Estrae la prima stringa che somiglia a un indirizzo email. Per esempio, Bryan O'Sullivan <bos@serpentine.com> diventa bos@serpentine.com. + + escape: qualunque testo. Sostituisce i caratteri speciali XML/XHTML &, < e > con entità XML. + + fill68: qualunque testo. Manda a capo il testo per farlo stare in 68 colonne. Questo filtro è utile da applicare prima di combinarlo con il filtro tabindent, se volete che il testo non esca dai bordi di una finestra di 80 colonne con caratteri a spaziatura fissa. + + fill76: qualunque testo. Manda a capo il testo per farlo stare in 76 colonne. + + firstline: qualunque testo. Produce la prima riga del testo, senza alcun carattere di nuova riga alla fine. + + hgdate: parola chiave date. Rappresenta la data come una coppia di numeri leggibili. Produce una stringa come 1157407993 25200. + + isodate: parola chiave date. Rappresenta una data come stringa di testo in formato ISO 8601. Produce una stringa come 2006-09-04 15:13:13 -0700. + + obfuscate: qualunque testo, ma utile soprattutto per la parola chiave author. Riproduce il testo in ingresso rappresentandolo come una sequenza di entità XML. Questo è utile per impedire ad alcuni programmi particolarmente stupidi utilizzati dagli spammer per raccogliere indirizzi email di copiare i dati destinati a essere visualizzati su schermo. + + person: qualunque testo, ma utile soprattutto per la parola chiave author. Produce il testo che precede un indirizzo email. Per esempio, Bryan O'Sullivan <bos@serpentine.com> diventa Bryan O'Sullivan. + + rfc822date: parola chiave date. Rappresenta una data usando lo stesso formato impiegato nelle intestazioni email. Produce una stringa come Mon, 04 Sep 2006 15:13:13 -0700. + + short: hash di changeset. Produce la forma breve di un hash di changeset, i.e. una stringa esadecimale di 12 caratteri. + + shortdate: parola chiave date. Rappresenta l'anno, il mese e il giorno della data. Produce una stringa come 2006-09-04. + + strip: qualunque testo. Rimuove lo spazio bianco all'inizio e alla fine di una stringa. + + tabindent: qualunque testo. Produce il testo, facendo cominciare ogni riga tranne la prima con un carattere di tabulazione. + + urlescape: qualunque testo. Effettua l'escape di tutti i caratteri che sono considerati speciali dai riconoscitori di URL. Per esempio, foo bar diventa foo%20bar. + + user: qualunque testo, ma utile soprattutto per la parola chiave author. Restituisce la porzione dell'utente di un indirizzo email. Per esempio Bryan O'Sullivan <bos@serpentine.com> diventa bos. + + + + &interaction.template.simple.manyfilters; + + + 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 desc con il filtro isodate. + + + + Combinare i filtri + + È facile combinare filtri per produrre un testo formattato nel modo che preferite. La seguente catena di filtri ripulisce una descrizione, poi si assicura che stia tranquillamente in 68 colonne, infine la indenta ulteriormente di 8 caratteri (almeno sui sistemi di tipo Unix, dove una tabulazione è convenzionalmente larga 8 caratteri). + + &interaction.template.simple.combine; + + Notate l'uso di \t (un carattere di tabulazione) nel template per indentare la prima riga, necessario dato che tabindent indenta tutte le righe tranne la prima. + + 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 fill68|tabindent dà risultati molto diversi rispetto a tabindent|fill68. + + + + + Dai template agli stili + + 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. + + 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 a riga di comando. + + + Il più semplice dei file di stile + + Il nostro semplice file di stile contiene solo una riga: + + &interaction.template.simple.rev; + + Questo dice a Mercurial: se stai stampando un changeset, usa il testo sulla destra come template. + + + + La sintassi dei file di stile + + Le regole della sintassi per un file di stile sono semplici. + + + Il file viene elaborato una riga alla volta. + + Gli spazi bianchi all'inizio e alla fine di una riga vengono ignorati. + + Le righe vuote vengono saltate. + + Se una riga comincia con un carattere # o ;, l'intera riga viene trattata come un commento e saltata come se fosse vuota. + + 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 [A-Za-z_][A-Za-z0-9_]*.) + + L'elemento successivo deve essere un carattere =, che può essere preceduto o seguito da una quantità arbitraria di spazio bianco. + + Se il resto della riga comincia e finisce con caratteri corrispettivi di apice o di virgolette, viene trattato come il corpo di un template. + + Se il resto della riga non comincia con caratteri di apice o di virgolette, viene trattato come il nome di un file i cui contenuti saranno letti e usati come il corpo di un template. + + + + + + Esempi di file di stile + + Per illustrare come scrivere un file di stile, ne costruiremo alcuni esempi. Piuttosto che fornire un file di stile completo e ripercorrerlo passo per passo, replicheremo il classico processo di sviluppo di un file di stile cominciando con qualcosa di molto semplice e proseguendo attraverso una serie di esempi successivi più completi. + + + Identificare errori in un file di stile + + Se Mercurial incontra un problema in un file di stile su cui state lavorando, stampa uno stringato messaggio di errore che si rivela in effetti piuttosto utile una volta scoperto cosa significa. + + &interaction.template.svnstyle.syntax.input; + + Notate che stile.errato tenta di definire una parola chiave changeset, ma dimentica di darle un contenuto qualsiasi. Quando gli si chiede di usare questo file di stile, Mercurial si lamenta prontamente. + + &interaction.template.svnstyle.syntax.error; + + Questo messaggio di errore sembra minaccioso, ma non è troppo difficile da seguire. + + + Il primo componente è semplicemente il modo in cui Mercurial dice rinuncio. + ___fallimento___: stile.errato:1: errore di riconoscimento + + Subito dopo, trovate il nome del file di stile che contiene l'errore. + fallimento: ___stile.errato___:1: errore di riconoscimento + + Il nome del file è seguito dal numero di riga dove l'errore è stato incontrato. + fallimento: stile.errato:___1___: errore di riconoscimento + + Infine, viene fornita una descrizione di quello che è andato storto. + fallimento: stile.errato:1: ___errore di riconoscimento___ + 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. + + + + + + Identificare univocamente un repository + + Se volete essere in grado di identificare un repository Mercurial in maniera abbastanza univoca usando una breve stringa come identificatore, potete usare la prima revisione contenuta nel repository. + + &interaction.template.svnstyle.id; + + È molto probabile che questo identificatore sia unico, quindi si rivela utile in molti casi. Ci sono alcune avvertenze. + + Questa tecnica non funzionerà in un repository completamente vuoto, perché un tale repository non possiede la revisione zero. + + 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. + + Ecco alcuni usi che potete fare di questo identificatore: + + come chiave nella tabella di un database che gestisce i repository presenti su un server; + + come metà di una tupla {identificatore di repository, identificatore di revisione}. Salvate questa informazione da qualche parte quando eseguite un assemblaggio automatico o un'altra attività simile, in modo che possiate rieseguire lo stesso assemblaggio in seguito se necessario. + + + + + + Elencare file su più righe + + Supponete di voler elencare i file modificati da un changeset uno per riga, aggiungendo una piccola indentazione prima di ogni nome di file. + + &interaction.ch10-multiline.go; + + + + Imitare i messaggi di Subversion + + Proviamo a emulare il formato predefinito usato da un altro strumento di controllo di revisione, Subversion, per mostrare le voci del proprio registro. + + &interaction.template.svnstyle.short; + + Dato che lo stile della rappresentazione di Subversion è abbastanza semplice, è facile copiare e incollare uno dei suoi messaggi in un file e rimpiazzare il testo prodotto da Subversion con i valori di template che vorremmo vedere espansi. + + &interaction.template.svnstyle.template; + + Questo template si discosta in alcuni modi dalla presentazione prodotta da Subversion. + + Subversion stampa una data leggibile (il Wed, 27 Sep 2006 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. + + Emuliamo la stampa di righe separatrici piene di caratteri - da parte di Subversion concludendo il template con una riga di quel tipo. Usiamo la parola chiave header del motore di template per stampare una riga separatrice come prima riga (vedete più avanti), quindi ottenendo un risultato simile a quello di Subversion. + + 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. + + 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. + + &interaction.template.svnstyle.style; + + Avremmo potuto includere il testo del file di template direttamente nel file di stile, circondandolo con virgolette e rimpiazzando le nuove righe con sequenze \n, ma questo avrebbe reso il file di stile troppo difficile da leggere. La leggibilità è una buon criterio da cui farsi guidare per decidere se un certo testo appartiene a un file di stile o a un file di template a cui il file di stile fa riferimento. Nel caso il file di stile vi sembri troppo grande o disordinato se inserite un frammento letterale di testo, allora spostate il testo in un template. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch12-mq.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch12-mq.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,552 @@ + + + Gestire il cambiamento con Mercurial Queues + + + Il problema della gestione delle patch + + 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. + + Questo è un semplice caso del problema di gestione delle patch. Avete un albero di sorgenti a monte 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. + + 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. + + Chi distribuisce sistemi operativi che includono software open source ha spesso bisogno di effettuare modifiche ai pacchetti che distribuisce in modo da assemblarli correttamente nel proprio ambiente. + + Quando dovete mantenere solo alcune modifiche, potete facilmente gestire una singola patch usando i programmi standard diff e patch (si veda la 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 frammenti di lavoro distinti in modo che, per esempio, una singola patch contenga solo una correzione di bug (la patch potrebbe modificare diversi file, ma sta facendo solo una cosa) 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. + + 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. + + Fortunatamente, Mercurial include una potente estensione, chiamata Mercurial Queues (letteralmente, Code di Mercurial) o semplicemente MQ, che semplifica notevolmente il problema di gestione delle patch. + + + + La preistoria di Mercurial Queues + + Verso la fine degli anni '90, diversi sviluppatori del kernel di Linux cominciarono a mantenere alcune serie di patch che modificavano il comportamento del kernel. Alcune di queste serie si concentravano sulla stabilità, alcune sull'inclusione di funzioni e altre erano più sperimentali. + + 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. + + + Una <quote>coperta a scacchi</quote> + + All'inizio del 2003, Andreas Gruenbacher e Martin Quinson presero in prestito l'approccio degli script di Andrew e pubblicarono uno strumento chiamato patchwork quilt (letteralmente, coperta a scacchi) web:quilt, o semplicemente quilt (si veda gruenbacher:2005 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. + + Quilt gestisce una pila di patch 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 aggiornate la patch. + + 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 albero con una patch applicata ad albero con due patch applicate. + + Potete scegliere quali sono le patch da applicare all'albero. Se estraete una patch, i cambiamenti effettuati da quella patch spariranno dall'albero di directory. Quilt si ricorda quali patch avete estratto, comunque, così potete inserire 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 aggiornamento 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. + + 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. + + + + Da patchwork quilt a Mercurial Queues + + 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. + + La differenza chiave tra quilt e MQ è che quilt non è progettato per interagire con alcun sistema di controllo di revisione, mentre MQ è integrata in Mercurial. Ogni patch che inserite è rappresentata sotto forma di changeset Mercurial. Se estraete una patch, il changeset relativo sparisce. + + Dato che quilt non si preoccupa degli strumenti di controllo di revisione, rimane un software tremendamente utile da conoscere per impiegarlo nelle situazioni in cui non potete usare Mercurial e MQ. + + + + + L'enorme vantaggio di MQ + + Non posso esagerare il valore dell'unificazione tra patch e controllo di revisione offerta da MQ. + + 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'agilità che offrono. + + 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. + + 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. + + Per esempio, l'integrazione delle patch con il controllo di revisione facilita enormemente 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 hg log con un nome di file per vedere quali changeset e quali patch hanno avuto effetto sul file. Potete usare il comando hg bisect 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 hg annotate per vedere quali changeset o patch hanno modificato una particolare riga di un file sorgente. E così via. + + + + Capire le patch + + 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. + + Il tradizionale comando Unix diff confronta due file e stampa una lista di differenze tra loro. Il comando patch interpreta queste differenze come modifiche da effettuare a un file. Date un'occhiata qui di seguito per vedere un semplice esempio di questi comandi in azione. + + &interaction.mq.dodiff.diff; + + Il tipo di file generato da diff (e che patch prende in ingresso) viene chiamato una patch (letteralmente, pezza) o un diff. Non c'è alcuna differenza tra una patch e un diff, ma noi useremo il termine patch, dato che è quello più comunemente usato. + + Un file di patch può cominciare con testo arbitrario che il comando patch ignora, ma che MQ usa come messaggio di commit quando crea i changeset. Per trovare l'inizio del contenuto della patch, il comando patch cerca la prima riga che comincia con la stringa diff -. + + MQ lavora con i diff unificati (patch può accettare molti altri formati di diff, ma MQ no). Un diff unificato contiene due tipi di intestazione. L'intestazione di file descrive il file che viene modificato e contiene il nome del file da modificare. Quando patch vede una nuova intestazione di file, cerca il file con quel nome per cominciare a modificarlo. + + L'intestazione di file è seguita da una serie di blocchi. 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 contesto del blocco. Se c'è solo una quantità ridotta di contesto tra blocchi successivi, diff non stampa una nuova intestazione, ma si limita a unire insieme i blocchi inserendo alcune righe di contesto tra le modifiche. + + Ogni riga di contesto comincia con un carattere di spazio. Nell'ambito di un blocco, una riga che comincia con - significa rimuovi questa riga, mentre una riga che comincia con + significa inserisci questa riga. Per esempio, una riga modificata viene rappresentata da una cancellazione e da un inserimento. + + Ritorneremo su alcuni degli aspetti più sottili delle patch più avanti (nella ), ma ora dovreste avere abbastanza informazioni per usare MQ. + + + + Cominciare a usare Mercurial Queues + + 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 ~/.hgrc aggiungendo le seguenti righe. + + [extensions] +hgext.mq = + + Una volta che avete abilitato l'estensione, vi verranno messi a disposizione alcuni nuovi comandi. Per verificare che l'estensione funzioni, potete usare hg help per vedere se il comando qinit viene elencato come disponibile. + + &interaction.mq.qinit-help.help; + + MQ può essere usata con qualsiasi repository Mercurial e i suoi comandi operano solo all'interno di quel repository. Per cominciare, preparate semplicemente il repository usando il comando qinit. + + &interaction.mq.tutorial.qinit; + + Questo comando crea una directory vuota chiamata .hg/patches, dove MQ terrà i propri metadati. Come accade con molti comandi Mercurial, il comando qinit non stamperà nulla nel caso termini con successo. + + + Creare una nuova patch + + Per cominciare a lavorare su una nuova patch, usate il comando qnew. Questo comando prende come argomento il nome della patch da creare. + + MQ userà questo nome per memorizzare un file nella directory .hg/patches, come potete vedere qui sotto. + + &interaction.mq.tutorial.qnew; + + La directory .hg/patches contiene anche altri due nuovi file, series e status. Il file series elenca tutte le patch per questo repository di cui MQ è a conoscenza, con una patch per ogni riga. Mercurial usa il file status per tenere traccia internamente di tutte le patch che MQ ha applicato a questo repository. + + + A volte potreste voler modificare il file series a mano, per esempio per cambiare la sequenza in cui sono applicate alcune patch. Tuttavia, modificare manualmente il file status è quasi sempre una cattiva idea, dato che così facendo si rischia facilmente di disorientare MQ. + + + Una volta che avete creato la vostra nuova patch, potete modificare i file nella directory di lavoro come fareste di solito. Tutti i normali comandi Mercurial, come hg diff e hg annotate, funzionano allo stesso modo in cui funzionavano prima. + + + + Aggiornare una patch + + Quando raggiungete un punto in cui volete salvare il vostro lavoro, usate il comando qrefresh per aggiornare la patch su cui state lavorando. + + &interaction.mq.tutorial.qrefresh; + + 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. + + Potete invocare qrefresh tutte le volte che volete, quindi questo comando rappresenta un buon modo per controllare il vostro lavoro. Aggiornate la vostra patch al momento opportuno, tentate un esperimento e se l'esperimento non funziona usate hg revert per ripristinare le vostre modifiche all'ultimo aggiornamento che avete compiuto. + + &interaction.mq.tutorial.qrefresh2; + + + + Impilare e registrare le patch + + 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 qnew per creare una nuova patch. Mercurial applicherà questa patch a partire dalla vostra patch esistente. + + &interaction.mq.tutorial.qnew2; + + Notate che la patch contiene le modifiche della nostra patch precedente come parte del proprio contesto (potete vederlo più chiaramente nel risultato di hg annotate). + + Finora, con l'eccezione di qnew e qrefresh, 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. + + &interaction.mq.tutorial.qseries; + + + Il comando qseries elenca tutte le patch per questo repository di cui MQ è a conoscenza, dalla più vecchia alla più recente (più recentemente creata). + + Il comando qapplied elenca tutte le patch che MQ ha applicato a questo repository, sempre dalla più vecchia alla più recente (più recentemente applicata). + + + + + Manipolare la pila delle patch + + La discussione precedente implica che ci deve essere una differenza tra patch note e patch applicate, e in effetti c'è. MQ può gestire una patch senza che sia applicata al repository. + + Una patch applicata 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 qpop. La patch estratta è ancora nota, 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 illustra la differenza tra patch applicate e registrate. + +

+ Patch applicate e non applicate nella pila delle patch di MQ + + + XXX add text + + + + Potete riapplicare una patch non applicata o estratta usando il comando qpush. Questo comando crea un nuovo changeset da far corrispondere alla patch, e le modifiche della patch compaiono nuovamente nella directory di lavoro. Di seguito, vengono mostrati esempi di qpop e qpush in azione. + + &interaction.mq.tutorial.qpop; + + Notate che, dopo aver estratto una patch o due patch, il risultato di qseries rimane lo stesso, mentre quello di qapplied è cambiato. + + + + + Inserire ed estrarre molte patch + + Sebbene i comandi qpush e qpop operino in maniera predefinita su una singola patch alla volta, potete inserire ed estrarre molte patch in un unico passaggio. L'opzione di qpush lo induce a inserire tutte le patch non applicate, mentre l'opzione di qpop lo induce a estrarre tutte le patch applicate. (Per ulteriori modi di inserire ed estrarre molte patch, si veda la più avanti.) + + &interaction.mq.tutorial.qpush-a; + + + + I controlli di sicurezza e come scavalcarli + + 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 qnew eviterà di creare una nuova patch se ci sono cambiamenti in sospeso, causati in questo caso dall'invocazione di hg add su file3. + + &interaction.mq.tutorial.add; + + Tutti i comandi che esaminano la directory di lavoro accettano un'opzione so cosa sto facendo che si chiama sempre . L'esatto significato di dipende dal comando. Per esempio, hg qnew incorporerà i cambiamenti in sospeso nella nuova patch creata, ma hg qpop annullerà le modifiche a qualsiasi file coinvolto dalla patch che sta estraendo. Assicuratevi di leggere la documentazione per l'opzione di un comando prima di usarla! + + + + Lavorare su diverse patch alla volta + + Il comando qrefresh aggiorna sempre la patch applicata più recentemente. 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 questa patch per un po'. + + 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 qrefresh, in modo da salvare le modifiche in corso alla vostra patch di interfaccia, e poi usare qpop per estrarre la patch del nucleo. Correggete il bug nel nucleo, aggiornate la patch del nucleo con qrefresh e inserite la patch di interfaccia tramite qpush per continuare a lavorare dal punto dove avevate lasciato. + + + + + Ulteriori informazioni sulle patch + + MQ usa il comando GNU patch per applicare le patch, quindi vi sarà d'aiuto conoscere qualche altro aspetto di dettaglio sul funzionamento di patch e sulle patch stesse. + + + Il numero di cancellazioni + + 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). + + 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 e del comando diff 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. + + 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 patch è stato dotato di un'opzione che indica il numero di elementi iniziali da eliminare dal percorso al momento di applicare una patch. Questo numero viene chiamato il numero di cancellazioni. + + Un'opzione -p1 significa usa un numero di cancellazioni pari a uno. Se patch vede un nome di file foo/bar/baz in un'intestazione di file, eliminerà foo e proverà ad applicare la patch al file bar/baz. Strettamente parlando, il numero di cancellazioni si riferisce al numero di separatori di percorso (e dei relativi elementi) da eliminare. Un numero di cancellazioni pari a uno trasformerà foo/bar in bar, ma /foo/bar (notate lo slash iniziale) in foo/bar. + + Il numero di cancellazioni standard per le patch è pari a uno, in quanto quasi tutte le patch contengono un elemento iniziale da eliminare nel percorso. Il comando hg diff di Mercurial genera nomi di percorso in questa forma e sia il comando hg import che MQ si aspettano patch con un numero di cancellazioni pari a uno. + + 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 qimport con la patch, perché qimport non è ancora dotato di un'opzione -p (si veda il problema 311 per i dettagli). L'alternativa migliore che avete è quella di creare una vostra patch con qnew e poi usare il comando patch -pN per applicare la patch che avete ricevuto, seguito da hg addremove per registrare qualsiasi file aggiunto o rimosso dalla patch, seguito da hg qrefresh. Questa complessità potrebbe diventare inutile una volta che il problema 311 verrà risolto. + + + + + Strategie per applicare una patch + + Quando patch 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. + + Come prima cosa, patch 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 scostamento rispetto al numero di riga originale. + + Se la corrispondenza con il solo contesto fallisce, patch rimuove la prima e l'ultima riga del contesto e tenta una corrispondenza con la sola versione ridotta del contesto. Se il blocco con il contesto ridotto ha successo, stampa un messaggio dicendo di aver applicato il blocco con un fattore di incertezza (il numero dopo il fattore di incertezza indica quante righe del contesto sono state escluse da patch prima che la patch si potesse applicare). + + Quando nessuna di queste tecniche funziona, patch stampa un messaggio dicendo che il blocco in questione è stato rifiutato. Il comando salva i blocchi rifiutati (anche chiamati semplicemente rifiuti) in un file con lo stesso nome e un'estensione .rej aggiuntiva. Le copie non modificate del file vengono salvate con un'estensione .orig, mentre la copia del file senza alcuna estensione conterrà le modifiche fatte dai blocchi che sono stati effettivamente applicati. Se avete una patch che modifica il file foo con sei blocchi, ma uno di essi non si riesce ad applicare, otterrete una copia foo.orig non modificata del file originale, un file foo.rej contenente un blocco e il file foo contenente le modifiche effettuate dai cinque blocchi applicati con successo. + + + + Alcune stranezze nella rappresentazione delle patch + + Ci sono alcune cose utili da sapere sul modo in cui patch lavora con i file. + + Questo dovrebbe già essere ovvio, ma patch non è in grado di gestire i file binari. + + Il comando non si cura neanche del bit di esecuzione, bensì crea i nuovi file come leggibili, ma non eseguibili. + + patch tratta la rimozione di un file come un diff tra il file da rimuovere e un file vuoto. Quindi la vostra idea di cancellare un file viene rappresentata in una patch come ogni riga di questo file è stata cancellata. + + Tratta l'aggiunta di un file come un diff tra un file vuoto e il file da aggiungere. Quindi la vostra idea di aggiungere un file viene rappresentata in una patch come ogni riga di questo file è stata aggiunta. + + 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.) + + patch non è in grado di rappresentare i file vuoti, quindi non potete usare una patch per rappresentare la nozione di aggiungere questo file vuoto all'albero. + + + + + + Fate attenzione all'incertezza + + 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 patch o qpush dovessero mai menzionare lo scostamento o il fattore di incertezza, dovreste assicurarvi che i file siano stati modificati in maniera corretta. + + 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 pulita. Dico spesso, non sempre, 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. + + + + Gestire il rifiuto + + Se qpush non riesce ad applicare una patch, stamperà un messaggio di errore e terminerà. Se ha lasciato alcuni file .rej, normalmente è meglio correggere i blocchi rifiutati prima di inserire altre patch o fare qualsiasi ulteriore modifica. + + Se di solito la vostra patch si applicava in maniera pulita e ora non lo fa più perché avete modificato il codice sottostante su cui si basavano le vostre patch, Mercurial Queues può aiutarvi: leggete la per i dettagli. + + Sfortunatamente, non esiste alcuna tecnica particolare per gestire i blocchi rifiutati. Molto spesso, dovrete esaminare il file .rej e modificare il file di destinazione, applicando a mano i blocchi rifiutati. + + Un programmatore del kernel di Linux, Chris Mason (l'autore di Mercurial Queues), ha realizzato uno strumento chiamato mpatch (http://oss.oracle.com/~mason/mpatch/), che adotta un metodo semplice per automatizzare l'applicazione dei blocchi rifiutati da patch. Il comando mpatch può aiutarvi nel caso il blocco sia stato rifiutato per quattro tipiche ragioni: + + + il contesto in mezzo a un blocco è cambiato; + + all'inizio o alla fine del blocco manca una certa quantità di contesto; + + un blocco più ampio potrebbe applicarsi meglio&emdash;interamente o in parte&emdash;se fosse suddiviso in blocchi più piccoli; + + un blocco rimuove righe con un contesto leggermente differente rispetto a quello attualmente presente nel file. + + + + Se usate il comando mpatch, dovreste stare doppiamente attenti quando controllate i risultati al termine dell'esecuzione. In effetti, mpatch 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. + + + + + Ulteriori informazioni sulla gestione delle patch + + Man mano che acquisite familiarità con MQ, comincerete a voler eseguire altri tipi di operazioni di gestione delle patch. + + + Cancellare le patch indesiderate + + Se volete sbarazzarvi di una patch, usate il comando hg qdelete per cancellare il file contenente la patch e rimuovere la sua voce dalla serie di patch. Se provate a cancellare una patch che è ancora applicata, hg qdelete si rifiuterà di operare. + + &interaction.ch11-qdelete.go; + + + + Convertire in e da revisioni permanenti + + Una volta che avete finito di lavorare con una patch e volete trasformarla in un changeset permanente, usate il comando hg qfinish. Passate una revisione al comando per identificare la patch che volete trasformare in un normale changeset; questa patch deve essere già stata applicata. + + &interaction.ch11-qdelete.convert; + + Il comando hg qfinish accetta un'opzione o per trasformare tutte le patch applicate in normali changeset. + + È anche possibile trasformare un changeset esistente in una patch, passando l'opzione al comando hg qimport. + + &interaction.ch11-qdelete.import; + + 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. + + + + + Ottenere le prestazioni migliori da MQ + + MQ è molto efficiente nel gestire un grande numero di patch. Ho effettuato alcuni esperimenti sulle prestazioni a metà del 2006 per una presentazione che ho tenuto alla conferenza EuroPython 2006 (su macchine più moderne, dovreste aspettarvi risultati migliori di quelli che vedrete nel seguito). Come dati campione ho usato la serie di patch 2.6.17-mm1 per il kernel di Linux, contenente 1.738 patch. Ho applicato queste patch a un repository del kernel di Linux contenente tutte le 27.472 revisioni intercorse tra Linux 2.6.12-rc2 e Linux 2.6.17. + + Sul mio vecchio e lento portatile, sono riuscito a eseguire hg qpush per tutte le 1.738 patch in 3.5 minuti e a eseguire hg qpop per tutte le patch in 30 secondi. (Su portatili più recenti, il tempo per estrarre tutte le patch è sceso a due minuti.) Ho potuto aggiornare una delle patch più grandi (che ha effettuato 22.779 righe di cambiamenti a 287 file) eseguendo qrefresh in 6.6 secondi. + + Chiaramente, MQ è particolarmente adatto per lavorare su alberi di grandi dimensioni, ma ci sono alcuni trucchi che potete usare per ottenere prestazioni ancora migliori. + + Prima di tutto, provate a raggruppare insieme le operazioni. Ogni volta che eseguite qpush o qpop, questi comandi esaminano la directory di lavoro una volta per assicurarsi che non abbiate effettuato alcuna modifica dimenticandovi poi di invocare qrefresh. Su alberi di piccole dimensioni, il tempo impiegato da questa disamina è insignificante. Tuttavia, su un albero di medie dimensioni (contenente decine di migliaia di file), questa operazione può impiegare anche più di un secondo. + + I comandi qpush e qpop vi permettono di estrarre e inserire più patch alla volta. Come prima cosa, identificate la patch di destinazione che volete raggiungere. Quando usate qpush specificando una destinazione, il comando inserirà patch finché quella patch non si troverà in cima alla pila delle patch applicate. Quando usate qpop con una destinazione, MQ estrarrà patch finché la patch di destinazione non si troverà in cima a quella pila. + + Potete indicare una patch di destinazione usando il nome della patch oppure un numero. Se usate un identificatore numerico, il conteggio delle patch parte da zero: questo significa che la prima patch corrisponde a zero, la seconda a uno, e così via. + + + + Aggiornare le vostre patch quando il codice sottostante cambia + + 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 rifondare la vostra serie di patch. + + Il modo più semplice per eseguire questa operazione è quello di usare hg qpop per estrarre le vostre patch, poi invocare hg pull per propagare i cambiamenti nel repository sottostante e infine eseguire hg qpush 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 qrefresh e continuare a inserire fino a quando non avrete corretto l'intera pila. + + 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. + + È 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. + + Il processo è leggermente complicato. + + Come prima cosa, invocate hg qpush -a per inserire tutte le vostre patch sulla revisione su cui sapete che si applicano in maniera pulita. + + Salvate una copia di backup della vostra directory delle patch usando hg qsave . Questo comando salva le patch in una directory chiamata .hg/patches.N, dove N è un piccolo intero, e stampa il nome della directory in cui sono state salvate le patch. Il comando inserisce anche un changeset di salvataggio dopo quelli corrispondenti alle vostre patch applicate, per registrare internamente gli stati dei file series e status. + + Invocate hg pull per propagare i nuovi cambiamenti nel repository sottostante. (Non usate hg pull -u, perché l'aggiornamento dovrà essere fatto in maniera particolare, come vedrete nel prossimo punto.) + + Aggiornate la directory di lavoro alla nuova revisione di punta, usando hg update per sovrascrivere le modifiche apportate dalle patch che avete inserito. + + Unite tutte le patch usando hg qpush -m -a. L'opzione di qpush dice a MQ di effettuare un'unione a tre vie se l'applicazione di una patch fallisce. + + + Durante l'esecuzione di hg qpush , ogni patch nel file series viene applicata normalmente. Se una patch viene applicata con un fattore di incertezza o viene rifiutata, MQ esamina la coda che avete salvato tramite qsave 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. + + Quando avete finito di risolvere gli effetti di una patch, MQ aggiornerà la vostra patch sulla base dei risultati dell'unione. + + Alla fine di questo processo, il vostro repository conterrà una testa aggiuntiva proveniente dalla vecchia coda delle patch e la directory .hg/patches.N conterrà una copia della vecchia coda delle patch. Potete rimuovere la testa aggiuntiva usando hg qpop -a -n patches.N o hg strip. Potete cancellare .hg/patches.N una volta che siete sicuri di non averne più bisogno come backup. + + + + Identificare le patch + + I comandi MQ che lavorano con le patch vi permettono di fare riferimento a una patch usando il suo nome o un numero. Il riferimento per nome funziona in modo abbastanza ovvio: passate il nome foo.patch a qpush, per esempio, e il comando inserirà patch fino a quando foo.patch non verrà applicata. + + Potete abbreviare il riferimento a una patch usando sia un nome che una differenza numerica: foo.patch-2 significa due patch prima di foo.patch, mentre bar.patch+4 significa quattro patch dopo bar.patch. + + Il riferimento per indice non è molto diverso. La prima patch visualizzata da qseries è la patch numero zero (sì, è uno di quei sistemi di conteggio che partono da zero), la seconda è la patch numero uno, e così via. + + 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 qbase e qtip identificano rispettivamente la prima e l'ultima patch applicata. + + Queste aggiunte alla funzione di etichettatura di Mercurial facilitano ulteriormente l'uso delle patch. + + Volete bombardare di patch una mailing list con l'ultima serie dei vostri cambiamenti? + hg email qbase:qtip + (Non sapete cosa sia un bombardamento di patch? Leggete la .) + + Avete bisogno di vedere tutte le patch che da foo.patch in poi hanno coinvolto i file contenuti in una sottodirectory del vostro albero? + hg log -r foo.patch:qtip sottodirectory + + + + 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. + + Un'altra piacevole conseguenza del rappresentare i nomi di patch come etichette è che il comando hg log mostrerà normalmente il nome di una patch come un'etichetta nel proprio elenco, rendendo facile distinguere visivamente le patch applicate dalle normali revisioni sottostanti. L'esempio seguente mostra alcuni comandi Mercurial in azione con le patch applicate. + + &interaction.mq.id.output; + + + + Informazioni utili + + 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. + + + Normalmente, quando estraete una patch tramite qpop e poi la reinserite tramite qpush, il changeset che rappresenta la patch dopo l'estrazione/inserimento avrà una diversa identità rispetto al changeset che rappresentava l'hash in precedenza. Leggete la per sapere perché. + + Non è una buona idea usare hg merge per unire i cambiamenti provenienti da un altro ramo con un changeset corrispondente a una patch, almeno se volete mantenere la natura di patch 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. + + + + + + Gestire le patch in un repository + + Dato che la directory .hg/patches di MQ risiede fuori dalla directory di lavoro di un repository Mercurial, il repository Mercurial sottostante non sa nulla della gestione o della presenza delle patch. + + 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', aggiornala tramite qrefresh, poi usare hg commit per registrare lo stato corrente della patch. Questo vi permette di ritornare a quella versione della patch più tardi. + + 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. + + 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. + + + Il supporto di MQ per i repository di patch + + MQ vi aiuta a lavorare con la directory .hg/patches in qualità di repository. Quando preparate un repository per lavorare con le patch usando qinit, potete passare l'opzione per creare la directory .hg/patches sotto forma di repository Mercurial. + + + Se dimenticate di usare l'opzione , potete semplicemente posizionarvi nella directory .hg/patches in qualsiasi momento e invocare hg init. Non dimenticate, però, di aggiungere una voce per il file status al file .hgignore (hg qinit lo fa automaticamente per voi), perché il file status non andrebbe davvero amministrato. + + + Per convenienza, se MQ nota che la directory .hg/patches è un repository, userà automaticamente hg add per aggiungere ogni patch che create e importate. + + MQ fornisce il comando abbreviato qcommit che esegue hg commit nella directory .hg/patches, per risparmiarvi noiose digitazioni. + + Infine, sui sistemi Unix, potete definire l'alias mq come comando di convenienza per gestire la directory delle patch. Per esempio, sui sistemi Linux che usano la shell bash, potete aggiungere la riga seguente al vostro file ~/.bashrc. + + alias mq=`hg -R $(hg root)/.hg/patches' + + Potete poi invocare comandi della forma mq pull dal repository principale. + + + + Alcune cose a cui fare attenzione + + Il supporto di MQ per lavorare con un repository pieno di patch è limitato in alcuni aspetti di dettaglio. + + MQ non può automaticamente scoprire quali modifiche avete fatto alla directory delle patch. Se usate hg pull, apportate cambiamenti a mano, o invocate hg update per aggiornare le modifiche alle patch o al file series, dovrete usare hg qpop e poi hg qpush nel repository sottostante per fare in modo che quelle modifiche compaiano anche là. Se dimenticate di fare questo, potreste confondere le idee a MQ in merito a quali patch sono state effettivamente applicate. + + + + + Strumenti di terze parti che lavorano con le patch + + 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. + + Il comando diffstat web:diffstat genera un istogramma delle modifiche effettuate a ogni file in una patch. Fornisce un buon modo per farsi un'idea 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 di diffstat, poiché altrimenti il comando proverà a manipolare i prefissi dei nomi di file in un modo che almeno io trovo inevitabilmente confuso.) + + &interaction.mq.tools.tools; + + Il pacchetto patchutils web:patchutils è inestimabile. Fornisce un insieme di piccole utilità che seguono la filosofia Unix: ognuna effettua una singola operazione utile su una patch. Il comando di patchutils che uso di più è filterdiff, che estrae sottoinsiemi di un file di patch. Per esempio, data una patch che modifica centinaia di file attraverso dozzine di directory, una singola invocazione di filterdiff può generare una patch più piccola che coinvolge solo i file il cui nome corrisponde a un particolare pattern di tipo glob. Leggete la per un altro esempio. + + + + Strategie valide per lavorare con le patch + + Sia che stiate lavorando su una serie di patch da sottoporre a un progetto software libero od open source, o su una serie che intendete trattare come una sequenza di normali changeset una volta che avete finito, potete usare alcune semplici tecniche per mantenere bene organizzato il vostro lavoro. + + Date nomi descrittivi alle vostre patch. Un buon nome per una patch potrebbe essere riorganizza-allocazione-dispositivi.patch, perché vi suggerirà immediatamente qual è lo scopo della patch. I nomi lunghi non dovrebbero essere un problema: non digiterete i nomi spesso, ma invocherete comandi come qapplied e qtop 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. + + Siate consapevoli della patch su cui state lavorando. Usate frequentemente il comando qtop e date un'occhiata al testo delle vostre patch&emdash;per esempio, usando hg tip &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. + + 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 , in particolare diffstat e filterdiff. 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. + + + + Il ricettario di MQ + + + Gestire patch <quote>elementari</quote> + + 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. + + Cominciate con lo scaricare l'archivio dei sorgenti, estraendone i contenuti e trasformandoli in un repository Mercurial. + + &interaction.mq.tarball.download; + + Continuate creando una pila di patch e facendo le vostre modifiche. + + &interaction.mq.tarball.qinit; + + Diciamo che trascorrono alcune settimane o mesi e gli autori di quel pacchetto rilasciano una nuova versione. Prima di tutto, propagate i loro cambiamenti nel repository. + + &interaction.mq.tarball.newsource; + + La coppia di comandi che comincia con hg locate appena invocata cancella tutti i file dalla directory di lavoro, in modo che l'opzione di hg commit possa effettivamente dirvi quali file sono stati davvero rimossi nella nuova versione dei sorgenti. + + Infine, potete applicare le vostre patch al nuovo albero. + + &interaction.mq.tarball.repush; + + + + Combinare intere patch + + MQ vi fornisce il comando qfold per consentirvi di combinare intere patch tra loro. Questo comando include 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. + + L'ordine in cui includete le patch è importante. Se la vostra ultima patch applicata è foo e voi utilizzate qfold per includervi bar e quux, otterrete una patch che opererà come se aveste applicato prima foo, poi bar, seguita da quux. + + + + Unire parte di una patch a un'altra + + Unire parte di una patch a un'altra patch è più difficile che combinare intere patch tra loro. + + Se volete spostare alcune modifiche su interi file, potete usare le opzioni e di filterdiff 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 qpush su di essa (a causa dei blocchi che avete spostato nell'altra patch) e voi potrete semplicemente aggiornare la patch tramite qrefresh per scartare i blocchi duplicati. + + 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 lsdiff -nvv per stampare alcuni metadati sulla patch. + + &interaction.mq.tools.lsdiff; + + Questo comando stampa tre tipi diversi di numeri: + + (nella prima colonna) un numero di file per identificare ogni file modificato dalla patch; + + (sulla riga seguente, indentato) il numero di riga del file modificato dove comincia il blocco; e + + (sulla stessa riga) un numero di blocco per identificare quel blocco. + + + + Dovrete leggere e ispezionare visivamente la patch per identificare i numeri di file e di blocco che volete, ma poi potrete passarli alle opzioni e di filterdiff per selezionare esattamente quel file e il blocco che volete estrarre. + + Una volta che avete questo blocco, potete aggiungerlo in coda alla vostra patch di destinazione e continuare con il resto della . + + + + + Differenze tra quilt e MQ + + Se avete già familiarità con quilt, MQ fornisce un insieme di comandi simile. Ci sono alcune differenze nel modo in cui questi comandi lavorano. + + Avrete già notato che la maggior parte dei comandi di quilt hanno una controparte MQ che comincia semplicemente con una q. Le eccezioni sono i comandi add e remove di quilt, le cui controparti sono i normali comandi Mercurial hg add e hg remove. Non c'è alcun comando MQ equivalente al comando quilt edit. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch13-mq-collab.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch13-mq-collab.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,238 @@ + + + Usi avanzati di Mercurial Queues + + Sebbene sia facile imparare gli usi più semplici di Mercurial Queues, sono un pizzico di disciplina e alcune delle funzioni meno usate di MQ che rendono possibile lavorare in ambienti di sviluppo complicati. + + In questo capitolo, userò come esempio una tecnica che ho impiegato per gestire lo sviluppo di un driver del kernel di Linux per un dispositivo Infiniband. Il driver in questione è grande (almeno per le dimensioni dei driver), poiché contiene 25.000 righe di codice distribuite su 35 file sorgente, e viene mantenuto da un piccolo gruppo di sviluppatori. + + Sebbene la maggior parte del materiale in questo capitolo sia specifica per Linux, gli stessi principi si applicano per qualsiasi base di codice di cui non siate i proprietari principali e su cui dobbiate fare parecchio lavoro. + + + Il problema dei molti obiettivi + + 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 compilata correttamente su qualsiasi altra versione del kernel. + + Per mantenere un driver, dobbiamo considerare un certo numero di versioni di Linux differenti. + + 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 estemporanee al driver man mano che sviluppano e rifiniscono i sottosistemi del kernel. + + Manteniamo anche un certo numero di backport (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. (Effetuare il backport 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.) + + 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 funzionalità ai clienti senza obbligarli ad aggiornare il loro kernel o la loro intera distribuzione. + + + + + Approcci seducenti che non funzionano bene + + Ci sono due modi standard per mantenere un software che deve funzionare in molti ambienti diversi. + + Il primo è mantenere un certo numero di rami, ognuno dedicato a un singolo ambiente. 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 intatto, 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. + + 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 ifdef 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. + + Nessuno di questi approcci è particolarmente adatto a situazioni in cui non possedete 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 mio 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. + + Questi approcci hanno la debolezza aggiuntiva di rendere difficile generare patch ben formate da presentare a monte. + + In linea di principio, Mercurial Queues sembra un buon candidato per gestire uno scenario di sviluppo come quello qui delineato. Non solo questo è indubbiamente il caso, ma MQ contiene anche alcune funzioni aggiuntive che rendono il lavoro più piacevole. + + + + + Applicare patch in maniera condizionata con le guardie + + Forse il miglior modo per non impazzire con così tanti ambienti obiettivo è quello di essere in grado di scegliere patch specifiche da applicare a una data situazione. MQ fornisce una funzione chiamata guardie (originata dal comando guards di quilt) che fa proprio questo. Per cominciare, creiamo un semplice repository per fare qualche esperimento. + + &interaction.mq.guards.init; + + Questo ci fornisce un piccolo repository contenente due patch che non hanno alcuna dipendenza reciproca, perché coinvolgono file differenti. + + L'idea alla base dell'applicazione condizionale è la possibilità di etichettare una patch con una guardia, 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. + + Una patch può avere un numero arbitrario di guardie, ognuna delle quali è positiva (applica questa patch se questa guardia è selezionata) o negativa (salta questa patch se questa guardia è selezionata). Una patch senza alcuna guardia viene sempre applicata. + + + + Controllare le guardie su una patch + + Il comando qguard vi permette di determinare quali guardie dovrebbero applicarsi a una patch, o di visualizzare le guardie già attive. Senza alcun argomento, il comando mostra le guardie della patch attualmente in cima alla pila. + + &interaction.mq.guards.qguard; + + Per impostare una guardia positiva su una patch, fate precedere il nome della guardia da un +. + + &interaction.mq.guards.qguard.pos; + + Per impostare una guardia negativa, fate precedere il nome della guardia da un -. + + &interaction.mq.guards.qguard.neg; + + Notate che in questo caso gli argomenti del comando hg qguard sono introdotti con il prefisso --, così Mercurial eviterà di interpretare il testo -quux come un'opzione. + + + Impostare e modificare + + Il comando qguard imposta le guardie su una patch, ma non le modifica. Questo significa che se invocate hg qguard +a +b su una patch, quindi invocate hg qguard +c sulla stessa patch, l'unica guardia che risulterà successivamente impostata sarà +c. + + + Mercurial memorizza le guardie nel file series, in una forma facile sia da capire che da modificare a mano. (In altre parole, non dovete usare il comando qguard se non volete, perché potete semplicemente modificare il file series.) + + &interaction.mq.guards.series; + + + + Selezionare le guardie da usare + + Il comando qselect determina quali guardie sono attive in un dato momento. Il suo effetto è quello di determinare quali patch verranno applicate da MQ la prossima volta che invocherete qpush. Non ha alcun altro effetto, in particolare non agisce in alcun modo sulle patch che sono già applicate. + + Invocato senza argomenti, il comando qselect elenca le guardie attualmente attive, una per ogni riga. Gli argomenti vengono trattati come i nomi delle guardie da applicare. + + &interaction.mq.guards.qselect.foo; + + Nel caso siate interessati, le guardie attualmente selezionate vengono memorizzate nel file guards. + + &interaction.mq.guards.qselect.cat; + + Possiamo vedere gli effetti delle guardie selezionate quando invochiamo qpush. + + &interaction.mq.guards.qselect.qpush; + + Una guardia non può cominciare con un carattere + o un carattere -. Il nome di una guardia non deve contenere spazio bianco, ma la maggior parte degli altri caratteri sono accettabili. Se provate a usare una guardia con un nome non valido, MQ se ne lamenterà. + + &interaction.mq.guards.qselect.error; + + Cambiare le guardie selezionate cambia le patch che vengono applicate. + + &interaction.mq.guards.qselect.quux; + + Potete vedere nell'esempio seguente che le guardie negative hanno la precedenza sulle guardie positive. + + &interaction.mq.guards.qselect.foobar; + + + + Le regole di MQ per applicare le patch + + Le regole usate da MQ per decidere se applicare una patch sono le seguenti. + + Una patch che non ha guardie viene sempre applicata. + + Se la patch ha una guardia negativa che corrisponde a una guardia attualmente selezionata, la patch viene saltata. + + Se la patch ha una guardia positiva che corrisponde a una guardia attualmente selezionata, la patch viene applicata. + + Se la patch ha guardie positive o negative, ma nessuna corrisponde a una guardia attualmente selezionata, la patch viene saltata. + + + + + + Ridimensionare l'ambiente di lavoro + + 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. + + Poi scelgo una versione di base 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 forma 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. + + Normalmente, l'albero di base a 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. + + + + Suddividere il file <filename role="special">series</filename> + + Categorizzo le patch nel file series 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. + + 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. + + Il gruppo delle patch accettate. 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 a sola lettura, presenti unicamente allo scopo di trasformare l'albero in uno stato simile a quello in cui si trova nel repository del manutentore a monte. + + Il gruppo delle patch da rielaborare. Sono le patch che ho proposto ma per le quali il manutentore a monte ha richiesto alcune modifiche prima di poterle accettare. + + Il gruppo delle patch in sospeso. Sono le patch che non ho ancora proposto al manutentore a monte, ma su cui dobbiamo finire di lavorare. Queste patch saranno a sola lettura per un po'. Se il manutentore a monte le accetta al momento di proporle, le sposterò alla fine del gruppo accettate. Se ne richiede la modifica, le sposterò all'inizio del gruppo da rielaborare. + + Il gruppo delle patch in corso. Sono le patch che vengono attivamente sviluppate e che non dovrebbero essere ancora presentate a nessuno. + + Il gruppo delle patch di backport. Sono le patch che riadattano l'albero dei sorgenti a una vecchia versione dell'albero del kernel. + + Il gruppo delle patch da non rilasciare. 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. + + + + 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 series serve proprio a questo scopo. + + 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'. + + Le patch di backport e da non rilasciare si trovano alla fine del file series. Le patch di backport devono essere applicate su tutte le altre patch, e anche le patch da non rilasciare dovrebbero essere messe in un posto sicuro. + + + + Mantenere le serie di patch + + Nel mio lavoro, uso un certo numero di guardie per controllare quali patch devono essere applicate. + + + Le patch accettate sono sorvegliate da accettate. Questa guardia è abilitata per la maggior parte del tempo. Quando sto applicando le patch su un albero dove le patch sono già presenti, posso disabilitare questa guardia così le patch che la seguono verranno applicate in maniera pulita. + + Le patch che sono terminate, 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. + + Le patch che hanno bisogno di essere rielaborate prima di venire nuovamente presentate sono sorvegliate da rielaborare. + + Per quelle patch che sono ancora in lavorazione, uso sviluppo. + + Una patch di backport potrebbe avere diverse guardie, una per ogni versione del kernel a cui si applica. Per esempio, una patch che effettua il backport di una parte del codice alla versione 2.6.9 del kernel avrà una guardia 2.6.9. + + + 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. + + + L'arte di scrivere patch di backport + + 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. + + 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 caos causato da molte istruzioni #ifdef (contenenti blocchi di codice che vengono usati solo in maniera condizionata) nel vostro codice, evitate di introdurre #ifdef 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. + + Ci sono due ragioni per separare le patch di backport in un gruppo distinto dalle patch normali i cui effetti vengono modificati da quelle. Il primo è che mescolarle insieme rende più difficile usare uno strumento come l'estensione patchbomb 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 senza che la patch di backport precedente sia già stata applicata. + + + + + Suggerimenti utili per sviluppare con MQ + + + Organizzare le patch in directory + + Se state lavorando su un progetto considerevole con MQ, non è difficile accumulare un grande numero di patch. Per esempio, mi è capitato di avere un repository di patch contenente più di 250 patch. + + Se riuscite a raggruppare queste patch in categorie logiche separate, potete memorizzarle in directory differenti, in quanto MQ non ha problemi a usare nomi di patch che contengono separatori di percorso. + + + + Visualizzare la cronologia di una patch + + Se sviluppate un insieme di patch per un lungo periodo, è una buona idea mantenerle in un repository, come discusso nella . Se fate in questo modo, scoprirete velocemente che è impraticabile usare il comando hg diff per esaminare la cronolgia 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. + + Tuttavia, potete usare l'estensione extdiff 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 patchutils web:patchutils. Il pacchetto fornisce un comando chiamato interdiff che mostra le differenze tra due diff di un diff. Usato su due versioni dello stesso diff, genera un diff che rappresenta le differenze tra la prima e la seconda versione. + + Potete abilitare l'estensione extdiff nel solito modo, aggiungendo una riga alla sezione extensions del vostro file ~/.hgrc. + [extensions] +extdiff = + Il comando interdiff si aspetta che gli vengano passati i nomi di due file, ma l'estensione extdiff 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 interdiff su ogni coppia di file in quelle due directory. Questo programma è disponibile sotto il nome di hg-interdiff nella directory examples del repository di codice sorgente che accompagna questo libro.FIXME Where in the world is the file in that repository? + + Dopo aver incluso il programma hg-interdiff nel percorso di ricerca della vostra shell, potete eseguirlo come segue, dall'interno di una directory di patch gestita da MQ: + hg extdiff -p hg-interdiff -r A:B mio-cambiamento.patch + Dato che vorrete usare questo comando prolisso molto spesso, potete fare in modo che hgext lo renda disponibile come un normale comando Mercurial, modificando ancora una volta il vostro file ~/.hgrc. + [extdiff] +cmd.interdiff = hg-interdiff + Questa riga ordina a hgext di rendere disponibile il comando interdiff, in modo che possiate ridurre l'invocazione precedente di extdiff a qualcosa di un po' più maneggevole. + hg interdiff -r A:B mio-cambiamento.patch + + + Il comando interdiff 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, interdiff potrebbe non produrre alcun risultato utile. + + + L'utilità dell'estensione extdiff va oltre il semplice miglioramento della presentazione delle patch gestite da MQ. Per avere ulteriori informazioni, leggete la . + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/ch14-hgext.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/ch14-hgext.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,207 @@ + + + Aggiungere funzionalità con le estensioni + + 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. + + Tuttavia, Mercurial non vi vincola a usare un insieme di comandi immutabile: potete aggiungere nuove funzioni a Mercurial sotto forma di estensioni (talvolta note come plugin). Abbiamo già discusso alcune di queste estensioni nei capitoli precedenti. + + La parla dell'estensione fetch, che combina l'estrazione di nuovi cambiamenti e la loro unione con i cambiamenti locali in un singolo comando, fetch. + + Nel , abbiamo parlato di diverse estensioni le cui funzioni sono utilizzabili sotto forma di hook: acl aggiunge le liste di controllo d'accesso, bugzilla aggiunge l'integrazione con il sistema Bugzilla per la gestione dei bug e notify invia email di notifica in reazione all'inserimento di nuovi cambiamenti. + + L'estensione Mercurial Queues per la gestione delle patch è talmente importante da meritare due capitoli e un'appendice interamente dedicati: il copre le nozioni di base, il ne discute gli argomenti avanzati e l' tratta ogni comando nei dettagli. + + + + 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. + + Nella , discuteremo la possibilità di enormi miglioramenti delle prestazioni tramite l'uso dell'estensione inotify. + + + + + Migliorare le prestazioni con l'estensione <literal role="hg-ext">inotify</literal> + + Siete interessati a ottenere esecuzioni fino a cento volte più veloci per alcune delle più comuni operazioni compiute da Mercurial? Continuate a leggere! + + Le prestazioni di Mercurial sono tipicamente eccellenti. Per esempio, quando invocate il comando hg status, 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 hg diff usa il meccanismo dello stato per evitare costose operazioni di confronto su file che ovviamente non sono stati modificati. + + 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 hg status, 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. + + Per esprimere numericamente la vastità di questo effetto, ho creato un repository contenente 150.000 file registrati e ho cronometrato hg status per scoprire che impiega dieci secondi a terminare, anche quando nessuno di quei file è stato modificato. + + 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 inotify. + + L'estensione inotify di Mercurial interagisce con il componente inotify per ottimizzare l'esecuzione di hg status. Questa estensione ha due componenti. Un demone viene eseguito in background e riceve le notifiche dal sottosistema inotify, 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, evitando il bisogno di esaminare tutti i file e le directory nel repository. + + Ricordate i dieci secondi che ho misurato come il tempo impiegato dal solo Mercurial per eseguire hg status su un repository di 150.000 file? Con l'estensione inotify abilitata, il tempo è sceso a 0.1 secondi, più veloce di un fattore cento. + + Prima di continuare, vi prego di fare attenzione ad alcuni avvertimenti. + + L'estensione inotify è specifica per Linux. Dato che si interfaccia direttamente con il sottosistema inotify del kernel di Linux, non funziona su altri sistemi operativi. + + 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 inotify, o una versione di glibc senza il necessario supporto di interfaccia. + + Non tutti i file system sono adatti per essere usati con l'estensione inotify. 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 inotify 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. + + + A maggio 2007, l'estensione inotify non viene ancora distribuita con Mercurial, quindi è un po' più complicata da installare rispetto ad altre estensioni. Ma il miglioramento delle prestazioni ne vale la pena! + + Attualmente, l'estensione è divisa in due parti: un insieme di patch al codice sorgente di Mercurial e una libreria di interfaccia Python al sottosistema inotify. + + Esistono due librerie di interfaccia Python per inotify. Una è chiamata pyinotify ed è inclusa in alcune distribuzioni Linux sotto il nome python-inotify. Questa non è quella di cui avete bisogno, dato che è troppo inefficiente e piena di problemi per essere pratica. + + Per cominciare, è meglio avere già installata una copia funzionante di Mercurial. + + Se seguite le istruzioni qui sotto, finirete per sostituire e sovrascrivere qualsiasi installazione esistente di Mercurial possiate già avere, usando l'ultima versione sperimentale di Mercurial. Non dite che non siete stati avvertiti! + + + Clonate il repository della libreria di interfaccia Python per inotify. Assemblate il software e installatelo. + hg clone http://hg.kublai.com/python/inotify +cd inotify +python setup.py build --force +sudo python setup.py install --skip-build + + Clonate il repository Mercurial crew. Clonate il repository di patch per inotify in modo che Mercurial Queues sia in grado di applicare le patch alla vostra copia del repository crew. + hg clone http://hg.intevation.org/mercurial/crew +hg clone crew inotify +hg clone http://hg.kublai.com/mercurial/patches/inotify inotify/.hg/patches + + Assicuratevi di aver abilitato mq, l'estensione Mercurial Queues. Se non avete mai usato MQ, leggete la per una rapida introduzione. + + Posizionatevi nel repository inotify e applicate tutte le patch per l'estensione inotify usando l'opzione del comando qpush. + cd inotify +hg qpush -a + + Se ottenete un messaggio di errore da qpush, dovreste fermarvi e chiedere aiuto. + + Assemblate e installate la versione modificata di Mercurial. + python setup.py build --force +sudo python setup.py install --skip-build + + + Una volta che avete assemblato una versione adeguatamente modificata di Mercurial, tutto ciò che dovete fare per abilitare l'estensione inotify è aggiungere una voce al vostro file ~/.hgrc. + [extensions] +inotify = + Quando l'estensione inotify è 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. + + 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 inotify, vedrete alcuni processi hg in attesa di aggiornamenti dal kernel e di richieste da Mercurial. + + La prima volta che invocate un comando Mercurial in un repository dopo aver abilitato l'estensione inotify, 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, ogni 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 inotify rende le operazioni di stato quasi istantanee su repository di tutte le dimensioni! + + Se preferite, potete avviare manualmente un demone di stato usando il comando inserve, 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 inotify sia abilitata. + + Quando state usando l'estensione inotify, non dovreste notare nessuna differenza 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. + + + + Supporto flessibile per i diff con l'estensione <literal role="hg-ext">extdiff</literal> + + Il comando predefinito di Mercurial hg diff stampa il testo semplice di diff unificati. + + &interaction.extdiff.diff; + + Nel caso desideraste usare uno strumento esterno per visualizzare le modifiche, vorrete usare l'estensione extdiff, che vi permetterà di impiegare, per esempio, uno strumento di diff grafico. + + L'estensione extdiff è inclusa in Mercurial, quindi è facile da installare. Per abilitare l'estensione, vi basta aggiungere una voce di una riga nella sezione extensions del vostro file ~/.hgrc. + [extensions] +extdiff = + Questa estensione introduce un comando chiamato extdiff, il cui comportamento predefinito è quello di usare il comando diff del vostro sistema per generare un diff unificato allo stesso modo del comando hg diff predefinito. + + &interaction.extdiff.extdiff; + + I risultati non saranno esattamente gli stessi ottenibili con le diverse versioni del comando predefinito hg diff, perché i risultati del comando diff variano da un sistema all'altro, persino quando gli vengono passate le stesse opzioni. + + Il comando extdiff funziona creando due fotografie del vostro albero sorgente. La prima fotografia è quella della revisione sorgente, la seconda è quella della revisione destinazione o della directory di lavoro. Il comando extdiff 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. + + Il nome delle directory di fotografia è uguale al nome base del vostro repository. Se il percorso del vostro repository è /quux/bar/foo, allora foo 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 a631aca1083f, la directory verrà chiamata foo.a631aca1083f. Una fotografia della directory di lavoro non terminerà con un identificatore di changeset, quindi in questo esempio il suo nome sarebbe semplicemente foo. Per vedere come questo appare in pratica, osservate ancora l'esempio di extdiff precedente. Notate che il diff contiene i nomi delle directory di fotografia nella propria intestazione. + + Il comando extdiff accetta due importanti opzioni. L'opzione vi permette di scegliere un programma diverso da diff con cui visualizzare le differenze. Con l'opzione , potete cambiare le opzioni che extdiff passa al programma (le opzioni predefinite sono -Npru, che hanno senso solo se state invocando diff). Sotto altri aspetti, il comando extdiff agisce in modo simile al comando predefinito hg diff: 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. + + Per esempio, ecco come invocare il normale comando diff di sistema per fargli generare diff contestuali (usando l'opzione ) invece di diff unificati e per fargli mostrare cinque righe di contesto invece delle tre predefinite (passandogli 5 come argomento per l'opzione ). + + &interaction.extdiff.extdiff-ctx; + + Lanciare uno strumento di diff visuale è altrettanto facile. Ecco come invocare il visualizzatore kdiff3. + hg extdiff -p kdiff3 -o + + 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 per vedere un esempio di un programma simile in azione con l'estensione mq e il comando interdiff. + + + Definire alias per i comandi + + Potrebbe essere scomodo ricordare le opzioni sia per il comando extdiff che per il visualizzatore di diff che volete usare, quindi l'estensione extdiff vi permette di definire nuovi comandi che invocheranno il vostro visualizzatore di diff con le opzioni giuste. + + Tutto quello che dovete fare è modificare il vostro file ~/.hgrc aggiungendo una sezione chiamata extdiff dove potete definire vari comandi. Ecco come aggiungere un comando kdiff3. Una volta che lo avete definito, potete digitare hg kdiff3 e l'estensione extdiff lancerà kdiff3 per voi. + [extdiff] +cmd.kdiff3 = + Se lasciate vuota la parte destra della definizione, come qui sopra, l'estensione extdiff 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 hg pippo che invoca kdiff3. + [extdiff] +cmd.pippo = kdiff3 + + Potete anche specificare le opzioni predefinite con cui volete invocare il vostro programma di visualizzazione di diff. Il prefisso da usare è opts., seguito dal nome del comando a cui applicare le opzioni. Questo esempio definisce un comando hg vimdiff che esegue l'estensione DirDiff dell'editor vim. + [extdiff] + cmd.vimdiff = vim +opts.vimdiff = -f '+next' '+execute "DirDiff" argv(0) argv(1)' + + + + + + Inviare cambiamenti via email con l'estensione <literal role="hg-ext">patchbomb</literal> + + Molti progetti seguono una pratica di revisione dei cambiamenti 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. + + Grazie alla sua estensione patchbomb, 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 bombardare la casella del ricevente, da cui il nome patchbomb. + + Come al solito, la configurazione di base dell'estensione patchbomb occupa solo una o due righe del vostro file /.hgrc. + [extensions] +patchbomb = + Una volta che avete abilitato l'estensione, avrete a disposizione un nuovo comando chiamato email. + + Il modo migliore e più sicuro di invocare il comando email è quello di eseguirlo sempre una prima volta con l'opzione . Questo vi mostrerà ciò che il comando invierebbe, 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 . + + Il comando email accetta lo stesso tipo di sintassi di revisione di tutti gli altri comandi Mercurial. Per esempio, questo comando invierà ogni revisione tra 7 e tip comprese. + hg email -n 7:tip + Potete anche specificare un repository con cui effettuare un confronto. Se fornite un repository senza indicare alcuna revisione, il comando email 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 ), questo vincolerà le revisioni inviate. + + È assolutamente sicuro invocare il comando email 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 readline o librerie simili quando immettete quelle intestazioni, cosa che vi si rivelerà utile.) + + Quando state inviando una sola revisione, il comando email userà la prima riga della descrizione del changeset come oggetto predefinito del singolo messaggio email da spedire. + + Se inviate revisioni multiple, di solito il comando email spedirà un messaggio per ogni changeset. Farà precedere la serie da un messaggio introduttivo in cui dovreste descrivere lo scopo della serie di cambiamenti che state inviando. + + + Modificare il comportamento di <literal role="hg-ext">patchbomb</literal> + + Non tutti i progetti hanno esattamente le stesse convenzioni per spedire cambiamenti via email, così l'estensione patchbomb prova a fornire un certo numero di variazioni attraverso le opzioni a riga di comando. + + Potete scrivere un oggetto per il messaggio introduttivo sulla riga di comando usando l'opzione . Questa opzione accetta un argomento, il testo da usare per l'oggetto. + + Per cambiare l'indirizzo email da cui vengono spediti i messaggi usate l'opzione . Questa opzione accetta un argomento, l'indirizzo email da usare. + + Il comportamento predefinito è quello di inviare diff unificati (leggete la per una descrizione del formato), uno per ogni messaggio. Potete invece usare l'opzione per inviare un bundle eseguibile. + + I diff unificati sono normalmente preceduti da un'intestazione di metadati. Potete ometterla e inviare diff disadorni con l'opzione . + + I diff vengono normalmente spediti in linea, 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 . + + Invece di spedire messaggi email, potete salvarli in una cartella email in formato mbox usando l'opzione . Questa opzione accetta un argomento, il nome del file su cui scrivere. + + Se preferite aggiungere un riepilogo nel formato del comando diffstat a ogni patch e uno al messaggio introduttivo, usate l'opzione . Il comando diffstat 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. + + + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/auto-snippets.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/auto-snippets.xml Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,276 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.init.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg init miorepo +$ cd miorepo +$ echo prima modifica >> miofile +$ hg add miofile +$ hg commit -m 'Prima modifica.' +$ echo seconda modifica >> miofile +$ hg commit -m 'Seconda modifica.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.manual.backout.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.backout.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,11 @@ + +$ echo terza modifica >> miofile +$ hg commit -m 'Terza modifica.' +$ hg backout -m 'Ritira la seconda modifica.' 1 +ripristino miofile +creata una nuova testa +il changeset 3:f3e79edd2b05 ritira il changeset 1:51969da8cdc5 +il changeset che ha compiuto il ritiro è una nuova testa - ricordatevi di unire +(usate "backout --merge" se volete unire automaticamente) + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.manual.cat.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.cat.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ cat miofile +prima modifica + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.manual.clone.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.clone.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ cd .. +$ hg clone -r1 miorepo nuovorepo +richiedo tutte le modifiche +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 2 changeset con 2 cambiamenti a 1 file +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd nuovorepo + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.manual.heads.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.heads.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ hg heads +changeset: 3:f3e79edd2b05 +tag: tip +parent: 1:51969da8cdc5 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:48:47 2009 +0000 +summary: Ritira la seconda modifica. + +changeset: 2:629da9559a9e +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:48:46 2009 +0000 +summary: Terza modifica. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.manual.log.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.log.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ hg log --style compact +3[tip]:1 f3e79edd2b05 2009-06-05 15:48 +0000 bos + Ritira la seconda modifica. + +2 629da9559a9e 2009-06-05 15:48 +0000 bos + Terza modifica. + +1 51969da8cdc5 2009-06-05 15:48 +0000 bos + Seconda modifica. + +0 efd26e99cc79 2009-06-05 15:48 +0000 bos + Prima modifica. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.manual.merge.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.merge.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ hg merge +fallimento: modifiche in sospeso non registrate +$ hg commit -m 'Unisce il changeset che ha compiuto il ritiro con la punta precedente.' +$ cat miofile +prima modifica + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.manual.parents.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.manual.parents.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,9 @@ + +$ hg parents +changeset: 2:629da9559a9e +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:48:46 2009 +0000 +summary: Terza modifica. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.non-tip.backout.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.non-tip.backout.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ echo terza modifica >> miofile +$ hg commit -m 'Terza modifica.' +$ hg backout --merge -m 'Ritira la seconda modifica.' 1 +ripristino miofile +creata una nuova testa +il changeset 3:af281715005d ritira il changeset 1:51969da8cdc5 +unisco con il changeset 3:af281715005d +unisco miofile +0 file aggiornati, 1 file uniti, 0 file rimossi, 0 file irrisolti +(unione tra rami, ricordatevi di eseguire il commit) + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.non-tip.cat.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.non-tip.cat.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ cat miofile +prima modifica +terza modifica + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.non-tip.clone.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.non-tip.clone.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ cd .. +$ hg clone -r1 miorepo repo-non-di-punta +richiedo tutte le modifiche +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 2 changeset con 2 cambiamenti a 1 file +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd repo-non-di-punta + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.simple.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.simple.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ hg backout -m 'Ritira la seconda modifica.' tip +ripristino miofile +il changeset 2:a4abdbaa35f1 ritira il changeset 1:51969da8cdc5 +$ cat miofile +prima modifica + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/backout.simple.log.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/backout.simple.log.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ hg log --style compact +2[tip] a4abdbaa35f1 2009-06-05 15:48 +0000 bos + Ritira la seconda modifica. + +1 51969da8cdc5 2009-06-05 15:48 +0000 bos + Seconda modifica. + +0 efd26e99cc79 2009-06-05 15:48 +0000 bos + Prima modifica. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/bisect.commits.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.commits.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ cambiamento_difettoso=22 +$ for (( i = 0; i < 35; i++ )); do +> if [[ $i = $cambiamento_difettoso ]]; then +> echo 'ho un gub' > miofile$i +> hg commit -q -A -m 'Changeset difettoso.' +> else +> echo 'niente da vedere, circolate' > miofile$i +> hg commit -q -A -m 'Changeset normale.' +> fi +> done + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/bisect.help.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.help.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,40 @@ + +$ hg help bisect +hg bisect [-gbsr] [-c CMD] [REV] + +ricerca di changeset tramite suddivisioni + + Questo comando vi aiuta a cercare changeset che introducono problemi. + Per usarlo, contrassegnate il changeset più recente che esibisce il + problema come guasto, poi contrassegnate l'ultimo changeset libero dal + problema come funzionante. La bisezione aggiornerà la vostra directory di + lavoro a una revisione di collaudo (a meno che l'opzione --noupdate sia + specificata). Una volta che avete effettuato i test, contrassegnate la + directory di lavoro come guasta o funzionante e bisect la aggiornerà a + un altro changeset candidato o vi comunicherà di aver trovato la revisione + guasta. + + Come scorciatoia, potete anche usare l'argomento revisione per + contrassegnare una revisione come funzionante o guasta senza prima + controllarla. + + Se fornite un comando, verrà usato per operare la bisezione in modo + automatico. Lo stato di uscita del comando verrà usato come indicatore per + contrassegnare una revisione come guasta o funzionante. Nel caso lo stato + di uscita sia 0 la revisione viene contrassegnata come funzionante; 125 - + viene saltata; 127 (comando non trovato) - la bisezione verrà bloccata; + qualsiasi altro stato maggiore di zero contrassegnerà la revisione come + guasta. + +opzioni: + + -r --reset inizializza lo stato della bisezione + -g --good contrassegna un changeset come funzionante + -b --bad contrassegna un changeset come guasto + -s --skip salta il collaudo del changeset + -c --command usa un comando per controllare lo stato del changeset + -U --noupdate non aggiorna alla revisione da collaudare + +usate "hg -v help bisect" per vedere le opzioni globali + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/bisect.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.init.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg init miobug +$ cd miobug + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/bisect.search.bad-init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.bad-init.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg bisect --bad + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/bisect.search.good-init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.good-init.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ hg bisect --good 10 +Collaudo il changeset 22:b8789808fc48 (24 changeset rimanenti, ~4 test) +0 file aggiornati, 0 file uniti, 12 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/bisect.search.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.init.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg bisect --reset + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/bisect.search.mytest.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.mytest.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ miotest() { +$ if grep -q 'ho un gub' * +> then +> risultato=bad +> else +> risultato=good +> fi +> echo il contrassegno di questa revisione è $risultato +> hg bisect --$risultato +> } + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/bisect.search.reset.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.reset.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg bisect --reset + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/bisect.search.rest.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.rest.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,18 @@ + +$ miotest +il contrassegno di questa revisione è good +Collaudo il changeset 20:bf7ea9a054e6 (3 changeset rimanenti, ~1 test) +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ miotest +il contrassegno di questa revisione è good +Collaudo il changeset 21:921391dd45c1 (2 changeset rimanenti, ~1 test) +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ miotest +il contrassegno di questa revisione è good +La prima revisione guasta è: +changeset: 22:b8789808fc48 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Tue May 05 06:55:14 2009 +0000 +summary: Changeset difettoso. + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/bisect.search.step1.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.step1.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,14 @@ + +$ if grep -q 'ho un gub' * +> then +> risultato=bad +> else +> risultato=good +> fi +$ echo il contrassegno di questa revisione è $risultato +il contrassegno di questa revisione è bad +$ hg bisect --$risultato +Collaudo il changeset 16:e61fdddff53e (12 changeset rimanenti, ~3 test) +0 file aggiornati, 0 file uniti, 6 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/bisect.search.step2.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/bisect.search.step2.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ miotest +il contrassegno di questa revisione è good +Collaudo il changeset 19:706df39b003b (6 changeset rimanenti, ~2 test) +3 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-named.branch.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-named.branch.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg branch +default + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-named.branches.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-named.branches.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,12 @@ + +$ hg tip +changeset: 0:fc8fb1089cc0 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:48:56 2009 +0000 +summary: Commit iniziale. + +$ hg branches +default 0:fc8fb1089cc0 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-named.commit.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-named.commit.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ echo 'ancora ciao' >> miofile +$ hg commit -m 'Secondo commit.' +$ hg tip +changeset: 1:b15761055392 +branch: foo +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:48:59 2009 +0000 +summary: Secondo commit. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-named.create.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-named.create.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg branch foo +la directory di lavoro è stata segnata come ramo foo +$ hg branch +foo + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-named.foo-commit.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-named.foo-commit.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,22 @@ + +$ echo qualcosa > qualchefile +$ hg commit -A -m 'Nuovo file.' +aggiungo qualchefile +creata una nuova testa +$ hg heads +changeset: 3:859c842ea668 +branch: foo +tag: tip +parent: 1:b15761055392 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:49:04 2009 +0000 +summary: NUovo file. + +changeset: 2:4dce38140953 +branch: bar +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:49:00 2009 +0000 +summary: Terzo commit. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-named.merge.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-named.merge.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,19 @@ + +$ hg branch +bar +$ hg merge foo +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +(unione tra rami, ricordatevi di effettuare il commit) +$ hg commit -m 'Unione.' +$ hg tip +changeset: 4:f50f493d0dc0 +branch: bar +tag: tip +parent: 2:4dce38140953 +parent: 3:859c842ea668 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:49:06 2009 +0000 +summary: Unione. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-named.parents.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-named.parents.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,15 @@ + +$ hg parents +changeset: 2:4dce38140953 +branch: bar +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:49:00 2009 +0000 +summary: Terzo commit. + +$ hg branches +bar 2:4dce38140953 +foo 1:b15761055392 (inattivo) +default 0:fc8fb1089cc0 (inattivo) + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-named.rebranch.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-named.rebranch.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,18 @@ + +$ hg branch +foo +$ hg branch bar +la directory di lavoro è stata segnata come ramo bar +$ echo nuovo file > nuovofile +$ hg commit -A -m 'Terzo commit.' +aggiungo nuovofile +$ hg tip +changeset: 2:4dce38140953 +branch: bar +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:49:00 2009 +0000 +summary: Terzo commit. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-named.status.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-named.status.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,11 @@ + +$ hg status +$ hg tip +changeset: 0:fc8fb1089cc0 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:48:56 2009 +0000 +summary: Commit iniziale + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-named.update-nothing.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-named.update-nothing.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg update foo +0 file aggiornati, 0 file uniti, 1 file rimossi, 0 file irrisolti +$ hg update +0 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-named.update-switchy.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-named.update-switchy.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,22 @@ + +$ hg update foo +0 file aggiornati, 0 file uniti, 1 file rimossi, 0 file irrisolti +$ hg parents +changeset: 1:b15761055392 +branch: foo +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:48:59 2009 +0000 +summary: Secondo commit. + +$ hg update bar +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ hg parents +changeset: 2:4dce38140953 +branch: bar +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:49:00 2009 +0000 +summary: Terzo commit. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-repo.bugfix.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-repo.bugfix.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ hg clone mioprogetto-1.0.1 mia-1.0.1-correzione +aggiorno la directory di lavoro +2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd mia-1.0.1-correzione +$ echo 'Ho corretto un bug usando solo echo!' >> miofile +$ hg commit -m 'Importante correzione per la versione 1.0.1.' +$ hg push +trasmetto a /tmp/mioprogetto-1.0.1 +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-repo.clone.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-repo.clone.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ cd .. +$ hg clone mioprogetto mioprogetto-1.0.1 +aggiorno la directory di lavoro +2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-repo.merge.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-repo.merge.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,14 @@ + +$ hg merge +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +(unione tra rami, ricordatevi di eseguire il commit) +$ hg commit -m 'Incorpora la correzione dal ramo 1.0.1.' +$ hg push +trasmetto a /tmp/mioprogetto +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 2 changeset con 1 cambiamenti a 1 file + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-repo.new.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-repo.new.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,18 @@ + +$ cd .. +$ hg clone mioprogetto mia-funzione +aggiorno la directory di lavoro +2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd mia-funzione +$ echo 'Questa è sicuramente una nuova ed eccitante funzione!' > mionuovofile +$ hg commit -A -m 'Nuova funzione.' +aggiungo mionuovofile +$ hg push +trasmetto a /tmp/mioprogetto +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-repo.pull.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-repo.pull.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ cd .. +$ hg clone mioprogetto mioprogetto-unione +aggiorno la directory di lavoro +3 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd mioprogetto-unione +$ hg pull ../mioprogetto-1.0.1 +estraggo da ../myproject-1.0.1 +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file (+1 teste) +(eseguite 'hg heads' per vedere le teste, 'hg merge' per unire) + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branch-repo.tag.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branch-repo.tag.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ cd mioprogetto +$ hg tag v1.0 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branching.clone.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branching.clone.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,12 @@ + +$ cd .. +$ hg clone -rv1.0 principale stabile +richiedo tutte le modifiche +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branching.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branching.init.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ hg init principale +$ cd principale +$ echo 'Questa è una funzione noiosa.' > miofile +$ hg commit -A -m 'Abbiamo raggiunto una pietra miliare importante!' +aggiungo miofile + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branching.main.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branching.main.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,9 @@ + +$ cd ../principale +$ echo 'Questa è nuova ed eccitante!' >> miofile +$ hg commit -m 'Aggiunge una nuova funzione.' +$ cat miofile +Questa è una funzione noiosa. +Questa è nuova ed eccitante! + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branching.merge.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branching.merge.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,20 @@ + +$ cd ../principale +$ hg pull ../stabile +estraggo da ../stabile +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file (+1 teste) +(eseguite 'hg heads' per vedere le teste, 'hg merge' per unire) +$ hg merge +unisco miofile +0 file aggiornati, 1 file uniti, 0 file rimossi, 0 file irrisolti +(unione tra rami, ricordatevi di eseguire il commit) +$ hg commit -m 'Incorpora la correzione del bug dal ramo stabile.' +$ cat miofile +Questa è una correzione a una funzione noiosa. +Questa è nuova ed eccitante! + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branching.stable.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branching.stable.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ hg clone stabile stabile-con-correzione +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd stabile-con-correzione +$ echo 'Questa è una correzione a una funzione noiosa.' > miofile +$ hg commit -m 'Corretto un bug' +$ hg push +trasmetto a /tmp/stabile +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branching.tag.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branching.tag.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,14 @@ + +$ hg tag v1.0 +$ hg tip +changeset: 1:be452d95a1d0 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:49:15 2009 +0000 +summary: Aggiunta l'etichetta v1.0 per il changeset c93791f54ca9 + +$ hg tags +tip 1:be452d95a1d0 +v1.0 0:c93791f54ca9 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/branching.update.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/branching.update.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ cd .. +$ hg clone -U principale principale-vecchio +$ cd principale-vecchio +$ hg update v1.0 +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cat miofile +Questa è una funzione noiosa. + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch01-new.add.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch01-new.add.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,12 @@ + +$ cd mioprogetto +$ cp ../hello.c . +$ cp ../goodbye.c . +$ hg add +aggiungo goodbye.c +aggiungo hello.c +$ hg status +A goodbye.c +A hello.c + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch01-new.commit.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch01-new.commit.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg commit -m 'Inserimento iniziale' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch01-new.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch01-new.init.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg init mioprogetto + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch01-new.ls.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch01-new.ls.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ ls -l +total 12 +-rw-rw-r-- 1 bos bos 47 May 5 06:55 goodbye.c +-rw-rw-r-- 1 bos bos 45 May 5 06:55 hello.c +drwxrwxr-x 3 bos bos 4096 May 5 06:55 mioprogetto + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch01-new.ls2.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch01-new.ls2.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ ls -al mioprogetto +total 12 +drwxrwxr-x 3 bos bos 4096 May 5 06:55 . +drwx------ 3 bos bos 4096 May 5 06:55 .. +drwxrwxr-x 3 bos bos 4096 May 5 06:55 .hg + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-diff.chmod.git.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-diff.chmod.git.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg diff -g +diff --git a/a b/a +vecchia modalità 100644 +nuova modalità 100755 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-diff.chmod.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-diff.chmod.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ chmod +x a +$ hg st +M a +$ hg diff + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-diff.rename.basic.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-diff.rename.basic.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,15 @@ + +$ hg rename a b +$ hg diff +diff -r b01d46ff402d a +--- a/a Fri Jun 05 15:49:22 2009 +0000 ++++ /dev/null Thu Jan 01 00:00:00 1970 +0000 +@@ -1,1 +0,0 @@ +-a +diff -r b01d46ff402d b +--- /dev/null Thu Jan 01 00:00:00 1970 +0000 ++++ b/b Fri Jun 05 15:49:23 2009 +0000 +@@ -0,0 +1,1 @@ ++a + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-diff.rename.git.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-diff.rename.git.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg diff -g +diff --git a/a b/b +cambiamento di nome da a +cambiamento di nome a b + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-resolve.cifail.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-resolve.cifail.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg commit -m 'Tentativo di inserire i risultati di un'unione fallita.' +fallimento: conflitti di unione irrisolti (si veda hg resolve) + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-resolve.export.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-resolve.export.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,4 @@ + +$ export HGMERGE=false + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-resolve.heads.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-resolve.heads.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ hg heads +changeset: 2:6e8cd0b94b4c +tag: tip +parent: 0:05f41910a168 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:49:28 2009 +0000 +summary: destra + +changeset: 1:ab0fbd8c502d +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:49:27 2009 +0000 +summary: sinistra + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-resolve.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-resolve.init.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,15 @@ + +$ hg init conflitto +$ cd conflitto +$ echo primo > miofile.txt +$ hg ci -A -m primo +aggiungo miofile.txt +$ cd .. +$ hg clone conflitto sinistra +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ hg clone conflitto destra +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-resolve.left.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-resolve.left.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ cd sinistra +$ echo sinistra >> miofile.txt +$ hg ci -m sinistra + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-resolve.list.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-resolve.list.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg resolve -l +U miofile.txt + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-resolve.merge.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-resolve.merge.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,9 @@ + +$ hg merge +unisco miofile.txt +merge: attenzione: conflitti durante l'unione +unione di miofile.txt fallita! +0 file aggiornati, 0 file uniti, 0 file rimossi, 1 file irrisolti +usate 'hg resolve' per riprovare a unire i file irrisolti o 'hg up --clean' per abbandonare + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-resolve.pull.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-resolve.pull.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,21 @@ + +$ cd ../conflitto +$ hg pull -u ../sinistra +estraggo da ../sinistra +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file +1 file aggiornati, 0 file uniti, 1 file rimossi, 0 file irrisolti +$ hg pull -u ../destra +estraggo da ../destra +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file (+1 teste) +non aggiorno, sono state aggiunte nuove teste +(eseguite 'hg heads' per vedere le teste, 'hg merge' per unire) + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch04-resolve.right.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch04-resolve.right.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ cd ../destra +$ echo destra >> miofile.txt +$ hg ci -m destra + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch06-apache-config.lst.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch06-apache-config.lst.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +<Directory /home/*/public_html> + AllowOverride FileInfo AuthConfig Limit + Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec + <Limit GET POST OPTIONS> + Order allow,deny + Allow from all + </Limit> + <LimitExcept GET POST OPTIONS> + Order deny,allow Deny from all + </LimitExcept> +</Directory> + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch09-check_whitespace.py.lst.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch09-check_whitespace.py.lst.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,49 @@ + +#!/usr/bin/env python +# +# salvate il file come .hg/controllo_spazio_bianco.py e rendetelo eseguibile + +import re + +def spazio_bianco_in_coda(righe_di_diff): + # + numriga, intestazione = 0, False + + for riga in righe_di_diff: + if intestazione: + # ricorda il nome del file coinvolto in questo diff + m = re.match(r'(?:---|\+\+\+) ([^\t]+)', riga) + if m and m.group(1) != '/dev/null': + nomefile = m.group(1).split('/', 1)[-1] + if riga.startswith('+++ '): + intestazione = False + continue + if riga.startswith('diff '): + intestazione = True + continue + # intestazione - salva il numero di riga + m = re.match(r'@@ -\d+,\d+ \+(\d+),', riga) + if m: + numriga = int(m.group(1)) + continue + # corpo - cerca una riga aggiunta con spazio bianco in coda + m = re.match(r'\+.*\s$', riga) + if m: + yield nomefile, numriga + if riga and riga[0] in ' +': + numriga += 1 + +if __name__ == '__main__': + import os, sys + + aggiunte = 0 + for nomefile, numriga in spazio_bianco_in_coda(os.popen('hg export tip')): + print >> sys.stderr, ('%s, riga %d: aggiunto spazio bianco in coda' % + (nomefile, numriga)) + aggiunte += 1 + if aggiunte: + # salva il messaggio di commit in modo da non doverlo digitare di nuovo + os.system('hg tip --template "{desc}" > .hg/commit.save') + print >> sys.stderr, 'messaggio di commit salvato nel file .hg/commit.save' + sys.exit(1) + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch09-hook.ws.better.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch09-hook.ws.better.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,20 @@ + +$ cat .hg/hgrc +[hooks] +pretxncommit.spazio_bianco = .hg/controllo_spazio_bianco.py +$ echo 'a ' >> a +$ hg commit -A -m 'Aggiunge una nuova riga con spazio bianco in coda.' +a, riga 2: aggiunto spazio bianco in coda +messaggio di commit salvato nel file .hg/commit.save +transazione abortita! +ripristino completato +fallimento: l'hook pretxncommit.spazio_bianco è terminato con codice di stato 1 +$ sed -i 's, *$,,' a +$ hg commit -A -m 'Rimosso spazio bianco in coda.' +a, riga 2: aggiunto spazio bianco in coda +messaggio di commit salvato nel file .hg/commit.save +transazione abortita! +ripristino completato +fallimento: l'hook pretxncommit.spazio_bianco è terminato con codice di stato 1 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch09-hook.ws.simple.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch09-hook.ws.simple.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,14 @@ + +$ cat .hg/hgrc +[hooks] +pretxncommit.spazio_bianco = hg export tip | (! egrep -q '^\+.*[ \t]$') +$ echo 'a ' > a +$ hg commit -A -m 'Collaudo con spazio bianco in coda.' +aggiungo a +transazione abortita! +ripristino completato +fallimento: l'hook pretxncommit.spazio_bianco è terminato con codice di stato 1 +$ echo 'a' > a +$ hg commit -A -m 'Elimina lo spazio bianco in coda e riprova.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch10-bugzilla-config.lst.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch10-bugzilla-config.lst.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,17 @@ + +[bugzilla] +host = bugzilla.example.com +password = miapassword +version = 2.16 +# i repository sul lato server si trovano in /home/hg/repos, quindi devono +# essere eliminati 4 separatori iniziali +strip = 4 +hgweb = http://hg.example.com/ +usermap = /home/hg/repos/notify/bugzilla.conf +template = Changeset {node|short}, creato da {author} nel repository {webroot} + fa riferimento a questo bug.\n + Per i dettagli completi, si veda + {hgweb}{webroot}?cmd=changeset;node={node|short}\n + Descrizione del changeset:\n + \t{desc|tabindent} + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch10-multiline.go.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch10-multiline.go.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,12 @@ + +$ cat > multiriga << EOF +> changeset = "Modificati in {node|short}:\n{files}" +> file = " {file}\n" +> EOF +$ hg log --style multiriga +Modificati in 7daf1d1b51e4: + .bashrc + .hgrc + test.c + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch10-notify-config-mail.lst.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch10-notify-config-mail.lst.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,20 @@ + +X-Hg-Repo: test/slave +Subject: test/slave: Gestisce l'errore nel caso in cui uno slave non ha alcun master. +Date: Wed, 2 Aug 2006 15:25:46 -0700 (PDT) + +changeset 3cba9bfe74b5 nel repository /home/hg/repos/test/slave + +details: +http://hg.example.com/test/slave?cmd=changeset;node=3cba9bfe74b5 + +description: Gestisce l'errore nel caso in cui uno slave non ha alcun master. + +diffs (54 lines): +diff -r 9d95df7cf2ad -r 3cba9bfe74b5 include/test.h +--- a/include/test.h Wed Aug 02 15:19:52 2006 -0700 ++++ b/include/test.h Wed Aug 02 15:25:26 2006 -0700 +@@ -212,6 +212,15 @@ static __inline__ +void test_headers(void *h) +[...omissis...] + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch10-notify-config.lst.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch10-notify-config.lst.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,21 @@ + +[notify] +# spedisci davvero le email +test = false +# i dati delle sottoscrizioni si trovano nel repository notify +config = /home/hg/repos/notify/notify.conf +# i repository si trovano in /home/hg/repos sul server, quindi +# eliminiamo 4 caratteri "/" +strip = 4 +template = X-Hg-Repo: {webroot}\n + Subject: {webroot}: {desc|firstline|strip}\n + From: {author} + \n\n + changeset {node|short} nel repository {root} + \n\ndettagli: + {baseurl}{webroot}?cmd=changeset;node={node|short} + descrizione: {desc|tabindent|strip} + +[web] +baseurl = http://hg.example.com/ + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch11-qdelete.convert.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch11-qdelete.convert.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ hg qnew buona.patch +$ echo a > a +$ hg add a +$ hg qrefresh -m 'Buona modifica.' +$ hg qfinish tip +$ hg qapplied +$ hg tip --style=compact +0[tip] 8eae2605f537 2009-06-05 15:49 +0000 bos + Buona modifica. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/ch11-qdelete.go.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/ch11-qdelete.go.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,15 @@ + +$ hg init miorepo +$ cd miorepo +$ hg qinit +$ hg qnew cattiva.patch +$ echo a > a +$ hg add a +$ hg qrefresh +$ hg qdelete cattiva.patch +fallimento: non posso cancellare la patch applicata cattiva.patch +$ hg qpop +la coda delle patch è vuota +$ hg qdelete cattiva.patch + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.copy.after.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.copy.after.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ cp a n +$ hg copy --after a n + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.copy.clone.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.copy.clone.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ cd .. +$ hg clone mia-copia vostra-copia +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.copy.copy.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.copy.copy.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ cd mia-copia +$ hg copy file nuovo-file + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.copy.dir-dest.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.copy.dir-dest.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ mkdir d +$ hg copy a b d +$ ls d +a b + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.copy.dir-src-dest.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.copy.dir-src-dest.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg copy z d +copio z/a/c in d/z/a/c + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.copy.dir-src.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.copy.dir-src.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg copy z e +copio z/a/c in e/a/c + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.copy.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.copy.init.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ hg init mia-copia +$ cd mia-copia +$ echo riga > file +$ hg add file +$ hg commit -m 'Aggiunto un file.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.copy.merge.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.copy.merge.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,18 @@ + +$ hg pull ../mia-copia +estraggo da ../mia-copia +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file (+1 teste) +(eseguite 'hg heads' per vedere le teste, 'hg merge' per unire) +$ hg merge +unisco file e nuovo-file in nuovo-file +0 file aggiornati, 1 file uniti, 0 file rimossi, 0 file irrisolti +(unione tra rami, ricordatevi di eseguire il commit) +$ cat nuovo-file +riga +nuovi contenuti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.copy.other.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.copy.other.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ cd ../vostra-copia +$ echo 'nuovi contenuti' >> file +$ hg commit -m 'File modificato.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.copy.simple.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.copy.simple.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ mkdir k +$ hg copy a k +$ ls k +a + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.copy.status-copy.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.copy.status-copy.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg status -C +A nuovo-file + file +$ hg commit -m 'File copiato.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.copy.status.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.copy.status.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg status +A nuovo-file + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.files.add-dir.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.files.add-dir.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ mkdir b +$ echo b > b/qualchefile.txt +$ echo c > b/sorgente.cpp +$ mkdir b/d +$ echo d > b/d/test.h +$ hg add b +aggiungo b/d/test.h +aggiungo b/qualchefile.txt +agginugo b/sorgente.cpp +$ hg commit -m 'Aggiunti tutti i file nella sottodirectory.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.files.add.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.files.add.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ hg init esempio-add +$ cd esempio-add +$ echo a > miofile.txt +$ hg status +? miofile.txt +$ hg add miofile.txt +$ hg status +A miofile.txt +$ hg commit -m 'Aggiunto un file.' +$ hg status + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.files.addremove.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.files.addremove.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg init esempio-addremove +$ cd esempio-addremove +$ echo a > a +$ echo b > b +$ hg addremove +aggiungo a +aggiungo b + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.files.commit-addremove.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.files.commit-addremove.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ echo c > c +$ hg commit -A -m 'Commit con addremove.' +aggiungo c + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.files.hidden.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.files.hidden.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,17 @@ + +$ hg init esempio-nascosto +$ cd esempio-nascosto +$ mkdir vuota +$ touch vuota/.nascosto +$ hg add vuota/.nascosto +$ hg commit -m 'Gestisce una directory che sembra vuota.' +$ ls vuota +$ cd .. +$ hg clone esempio-nascosto temp +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ ls temp +vuota +$ ls temp/vuota + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.files.missing.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.files.missing.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,11 @@ + +$ hg init esempio-mancante +$ cd esempio-mancante +$ echo a > a +$ hg add a +$ hg commit -m 'Il file sta per diventare mancante.' +$ rm a +$ hg status +! a + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.files.recover-missing.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.files.recover-missing.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg revert a +$ cat a +a +$ hg status + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.files.remove-after.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.files.remove-after.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ hg remove --after a +$ hg status +R a + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.files.remove.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.files.remove.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ hg init esempio-remove +$ cd esempio-remove +$ echo a > a +$ mkdir b +$ echo b > b/b +$ hg add a b +aggiungo b/b +$ hg commit -m 'Piccolo esempio di rimozione di file.' +$ hg remove a +$ hg status +R a +$ hg remove b +rimuovo b/b + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.rename.rename.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.rename.rename.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg rename a b + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.rename.status-copy.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.rename.status-copy.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg status -C +A b + a +R a + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.rename.status.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.rename.status.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ hg status +A b +R a + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.revert.add.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.add.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ echo oops > oops +$ hg add oops +$ hg status oops +A oops +$ hg revert oops +$ hg status +? oops + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.revert.copy.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.copy.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg copy file nuovo-file +$ hg revert nuovo-file +$ hg status +? nuovo-file + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.revert.missing.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.missing.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,9 @@ + +$ rm file +$ hg status +! file +$ hg revert file +$ ls file +file + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.revert.modify.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.modify.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ cat file +contenuto originale +$ echo cambiamento non voluto >> file +$ hg diff file +diff -r d17672b9fe6b file +--- a/file Fri Jun 05 15:50:07 2009 +0000 ++++ b/file Fri Jun 05 15:50:07 2009 +0000 +@@ -1,1 +1,2 @@ + contenuto originale ++cambiamento non voluto + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.revert.remove.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.remove.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg remove file +$ hg status +R file +$ hg revert file +$ hg status +$ ls file +file + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.revert.status.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.status.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ hg status +? file.orig +$ cat file.orig +contenuto originale +cambiamento non voluto + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/daily.revert.unmodify.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/daily.revert.unmodify.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ hg status +M file +$ hg revert file +$ cat file +contenuto originale + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/extdiff.diff.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/extdiff.diff.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg diff +diff -r dc7b09ad1097 miofile +--- a/miofile Fri Jun 05 15:50:16 2009 +0000 ++++ b/miofile Fri Jun 05 15:50:17 2009 +0000 +@@ -1,1 +1,2 @@ + La prima riga. ++La seconda riga. + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/extdiff.extdiff-ctx.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/extdiff.extdiff-ctx.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,11 @@ + +$ hg extdiff -o -NprcC5 +*** a.dc7b09ad1097/miofile Fri Jun 5 15:50:18 2009 +--- /tmp/a/miofile Fri Jun 5 15:50:16 2009 +*************** +*** 1 **** +--- 1,2 ---- + La prima riga. ++ La seconda riga. + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/extdiff.extdiff.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/extdiff.extdiff.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,9 @@ + +$ hg extdiff +--- a.dc7b09ad1097/miofile 2009-06-05 15:50:17.000000000 +0000 ++++ /tmp/a/miofile 2009-06-05 15:50:16.000000000 +0000 +@@ -1 +1,2 @@ + La prima riga. ++La seconda riga. + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/filenames.dirs.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/filenames.dirs.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ hg status sorgenti +? sorgenti/principale.py +? sorgenti/controllore/_controllore.c +? sorgenti/controllore/controllore.py +? sorgenti/xyzzy.txt + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/filenames.files.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/filenames.files.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg add COPIARE LEGGIMI esempi/semplice.py + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/filenames.filter.exclude.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/filenames.filter.exclude.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ hg status -X '**.py' sorgenti +? sorgenti/controllore/_controllore.c +? sorgenti/xyzzy.txt + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/filenames.filter.include.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/filenames.filter.include.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg status -I '*.in' +? MANIFEST.in + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/filenames.glob.group.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/filenames.glob.group.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ hg status 'glob:*.{in,py}' +? MANIFEST.in +? setup.py + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/filenames.glob.question.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/filenames.glob.question.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg status 'glob:**.?' +? sorgenti/controllore/_controllore.c + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/filenames.glob.range.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/filenames.glob.range.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ hg status 'glob:**[nr-t]' +? MANIFEST.in +? sorgenti/xyzzy.txt + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/filenames.glob.star-starstar.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/filenames.glob.star-starstar.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,11 @@ + +$ hg status 'glob:*.py' +? setup.py +$ hg status 'glob:**.py' +A esempi/semplice.py +A sorgenti/principale.py +? esempi/efficiente.py +? setup.py +? sorgenti/controllore/controllore.py + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/filenames.glob.star.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/filenames.glob.star.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg add 'glob:*.py' +aggiungo principale.py + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/filenames.glob.starstar.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/filenames.glob.starstar.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ cd .. +$ hg status 'glob:**.py' +A esempi/semplice.py +A sorgenti/principale.py +? esempi/efficiente.py +? setup.py +? sorgenti/controllore/controllore.py + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/filenames.wdir-relname.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/filenames.wdir-relname.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,25 @@ + +$ hg status +A COPIARE +A LEGGIMI +A esempi/semplice.py +? MANIFEST.in +? esempi/efficiente.py +? setup.py +? sorgenti/principale.py +? sorgenti/controllore/_controllore.c +? sorgenti/controllore/controllore.py +? sorgenti/xyzzy.txt +$ hg status `hg root` +A ../COPIARE +A ../LEGGIMI +A ../esempi/semplice.py +? ../MANIFEST.in +? ../esempi/performante.py +? ../setup.py +? principale.py +? controllore/_controllore.c +? controllore/controllore.py +? xyzzy.txt + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/filenames.wdir-subdir.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/filenames.wdir-subdir.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,17 @@ + +$ cd sorgenti +$ hg add -n +aggiungo ../MANIFEST.in +aggiungo ../esempi/efficiente.py +aggiungo ../setup.py +aggiungo principale.py +aggiungo controllore/_controllore.c +aggiungo controllore/controllore.py +aggiungo xyzzy.txt +$ hg add -n . +aggiungo principale.py +aggiungo controllore/_controllore.c +aggiungo controllore/controllore.py +aggiungo xyzzy.txt + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/hook.msglen.go.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/hook.msglen.go.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ cat .hg/hgrc +[hooks] +pretxncommit.lunghezza_messaggio = test `hg tip --template {desc} | wc -c` -ge 15 +$ echo a > a +$ hg add a +$ hg commit -A -m 'Troppo breve.' +transazione abortita! +ripristino completato +fallimento: l'hook pretxncommit.lunghezza_messaggio è terminato con codice di stato 1 +$ hg commit -A -m 'Abbastanza lungo.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/hook.simple.ext.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/hook.simple.ext.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ echo 'commit.quando = echo -n "data di inserimento: "; date' >> .hg/hgrc +$ echo a >> a +$ hg commit -m 'Ho due hook.' +inserito c62525b70eac19cfd72060e1654e8c62eab4ebee +data di inserimento: Fri Jun 5 15:50:28 GMT 2009 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/hook.simple.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/hook.simple.init.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,14 @@ + +$ hg init hook-di-test +$ cd hook-di-test +$ echo '[hooks]' >> .hg/hgrc +$ echo 'commit = echo inserito $HG_NODE' >> .hg/hgrc +$ cat .hg/hgrc +[hooks] +commit = echo inserito $HG_NODE +$ echo a > a +$ hg add a +$ hg commit -m "Collaudo l'hook di commit" +inserito 35ce7b98906996dea87740158ba6c3d7bcfa2448 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/hook.simple.pretxncommit.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/hook.simple.pretxncommit.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ cat controlla_bug_id +#!/bin/sh +# controlla che un messaggio di commit contenga un identificatore numerico di bug +hg log -r $1 --template {desc} | grep -q "\<bug *[0-9]" +$ echo 'pretxncommit.bug_id_richiesto = ./controlla_bug_id $HG_NODE' >> .hg/hgrc +$ echo a >> a +$ hg commit -m 'Non ho menzionato alcun identificatore di bug.' +transazione abortita! +ripristino completato +fallimento: l'hook pretxncommit.bug_id_richiesto è terminato con codice di stato 1 +$ hg commit -m 'Vi rimando al bug 666.' +inserito f753cb1e1e77ea944429e1a84d8728e96b41446e +data di inserimento: Fri Jun 5 15:50:29 GMT 2009 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/issue29.go.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/issue29.go.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,20 @@ + +$ hg init problema29 +$ cd problema29 +$ echo a > a +$ hg ci -Ama +aggiungo a +$ echo b > b +$ hg ci -Amb +aggiungo b +$ hg up 0 +0 file aggiornati, 0 file uniti, 1 file rimossi, 0 file irrisolti +$ mkdir b +$ echo b > b/b +$ hg ci -Amc +aggiungo b/b +creata una nuova testa +$ hg merge +fallimento: è una directory: /tmp/problema29jbjGH5/problema29/b + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.dodiff.diff.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.dodiff.diff.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ echo 'questo è il mio primo pensiero' > vecchiofile +$ echo 'ho cambiato idea' > nuovofile +$ diff -u vecchiofile nuovofile > piccola.patch +$ cat piccola.patch +--- vecchiofile 2009-06-05 15:50:32.000000000 +0000 ++++ nuovofile 2009-06-05 15:50:32.000000000 +0000 +@@ -1 +1 @@ +-questo è il mio primo pensiero ++ho cambiato idea +$ patch < piccola.patch +correggo il file vecchiofile +$ cat vecchiofile +ho cambiato idea + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.guards.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.guards.init.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,12 @@ + +$ hg qinit +$ hg qnew ciao.patch +$ echo ciao > ciao +$ hg add ciao +$ hg qrefresh +$ hg qnew arrivederci.patch +$ echo arrivederci > arrivederci +$ hg add arrivederci +$ hg qrefresh + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.guards.qguard.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.guards.qguard.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg qguard +arrivederci.patch: senza guardie + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.guards.qguard.neg.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.guards.qguard.neg.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ hg qguard -- ciao.patch -quux +$ hg qguard ciao.patch +ciao.patch: -quux + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.guards.qguard.pos.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.guards.qguard.pos.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ hg qguard +foo +$ hg qguard +arrivederci.patch: +foo + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.guards.qselect.cat.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.guards.qselect.cat.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ cat .hg/patches/guards +foo + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.guards.qselect.error.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.guards.qselect.error.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg qselect +foo +fallimento: la guardia '+foo' comincia con un carattere non valido: '+' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.guards.qselect.foo.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.guards.qselect.foo.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,11 @@ + +$ hg qpop -a +la coda delle patch è vuota +$ hg qselect +nessuna guardia attiva +$ hg qselect foo +il numero di patch non applicate senza guardia è cambiato da 1 a 2 +$ hg qselect +foo + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.guards.qselect.foobar.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.guards.qselect.foobar.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,11 @@ + +$ hg qselect foo bar +il numero di patch non applicate senza guardia è cambiato da 0 a 2 +$ hg qpop -a +nessuna patch applicata +$ hg qpush -a +applico ciao.patch +applico arrivederci.patch +ora a: arrivederci.patch + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.guards.qselect.qpush.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.guards.qselect.qpush.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg qpush -a +applico ciao.patch +applico arrivederci.patch +ora a: arrivederci.patch + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.guards.qselect.quux.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.guards.qselect.quux.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,9 @@ + +$ hg qselect quux +il numero di patch applicate con guardia è cambiato da 0 a 2 +$ hg qpop -a +la coda delle patch è vuota +$ hg qpush -a +la serie di patch è già stata completamente applicata + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.guards.series.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.guards.series.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ cat .hg/patches/series +ciao.patch #-quux +arrivederci.patch #+foo + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.id.output.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.id.output.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,35 @@ + +$ hg qapplied +prima.patch +seconda.patch +$ hg log -r qbase:qtip +changeset: 1:32b3cae9e753 +tag: prima.patch +tag: qbase +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:50:45 2009 +0000 +summary: [mq]: prima.patch + +changeset: 2:dee839d89dc6 +tag: qtip +tag: seconda.patch +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:50:46 2009 +0000 +summary: [mq]: seconda.patch + +$ hg export seconda.patch +# HG changeset di patch +# Utente Bryan O'Sullivan <bos@serpentine.com> +# Data 1244217046 0 +# ID di nodo dee839d89dc6e420682b02551b31e8375929aa7c +# Genitore 32b3cae9e753537be60bb2fbfefe0de3e19ec4a3 +[mq]: seconda.patch + +diff -r 32b3cae9e753 -r dee839d89dc6 altro.c +--- /dev/null Thu Jan 01 00:00:00 1970 +0000 ++++ b/altro.c Fri Jun 05 15:50:46 2009 +0000 +@@ -0,0 +1,1 @@ ++double u; + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.qinit-help.help.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.qinit-help.help.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,20 @@ + +$ hg help qinit +hg qinit [-c] + +inizializza un nuovo repository di coda + + Per default, il repository di coda non è sotto controllo di + versione. Se viene specificato -c, qinit creerà un repository + annidato separato per le patch (qinit -c può anche essere + invocato più tardi per convertire un repository di patch non + gestito in uno gestito). Potete usare qcommit per inserire + modifiche in questo repository di coda. + +opzioni: + + -c --create-repo crea il repository di coda + +usate "hg -v help qinit" per vedere le opzioni globali + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tarball.download.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tarball.download.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,12 @@ + +$ download netplug-1.2.5.tar.bz2 +$ tar jxf netplug-1.2.5.tar.bz2 +$ cd netplug-1.2.5 +$ hg init +$ hg commit -q --addremove --message netplug-1.2.5 +$ cd .. +$ hg clone netplug-1.2.5 netplug +aggiorno la directory di lavoro +18 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tarball.newsource.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tarball.newsource.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ hg qpop -a +la coda delle patch è vuota +$ cd .. +$ download netplug-1.2.8.tar.bz2 +$ hg clone netplug-1.2.5 netplug-1.2.8 +aggiorno la directory di lavoro +18 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd netplug-1.2.8 +$ hg locate -0 | xargs -0 rm +$ cd .. +$ tar jxf netplug-1.2.8.tar.bz2 +$ cd netplug-1.2.8 +$ hg commit --addremove --message netplug-1.2.8 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tarball.qinit.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tarball.qinit.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,31 @@ + +$ cd netplug +$ hg qinit +$ hg qnew -m 'corregge un problema di assemblaggio con gcc 4' correzione-assemblaggio.patch +$ perl -pi -e 's/int addr_len/socklen_t addr_len/' netlink.c +$ hg qrefresh +$ hg tip -p +changeset: 1:5227ba4b6a8b +tag: qtip +tag: correzione-assemblaggio.patch +tag: tip +tag: qbase +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:50:51 2009 +0000 +summary: corregge un problema di assemblaggio con gcc 4 + +diff -r e709896f2959 -r 5227ba4b6a8b netlink.c +--- a/netlink.c Fri Jun 05 15:50:49 2009 +0000 ++++ b/netlink.c Fri Jun 05 15:50:51 2009 +0000 +@@ -275,7 +275,7 @@ + exit(1); + } + +- int addr_len = sizeof(addr); ++ socklen_t addr_len = sizeof(addr); + + if (getsockname(fd, (struct sockaddr *) &addr, &addr_len) == -1) { + do_log(LOG_ERR, "Could not get socket details: %m"); + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tarball.repush.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tarball.repush.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ cd ../netplug +$ hg pull ../netplug-1.2.8 +estraggo da ../netplug-1.2.8 +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 12 cambiamenti a 12 file +(eseguite 'hg update' per ottenere una copia di lavoro) +$ hg qpush -a +(la directory di lavoro non è alla punta) +applico correzione-assemblaggio.patch +ora a: correzione-assemblaggio.patch + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tools.lsdiff.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tools.lsdiff.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,24 @@ + +$ lsdiff -nvv rimuove-controlli-ridondati-su-null.patch +22 File #1 a/drivers/char/agp/sgi-agp.c + 24 Blocco #1 static int __devinit agp_sgi_init(void) +37 File #2 a/drivers/char/hvcs.c + 39 Blocco #1 static struct tty_operations hvcs_ops = + 53 Blocco #2 static int hvcs_alloc_index_list(int n) +69 File #3 a/drivers/message/fusion/mptfc.c + 71 Blocco #1 mptfc_GetFcDevPage0(MPT_ADAPTER *ioc, in +85 File #4 a/drivers/message/fusion/mptsas.c + 87 Blocco #1 mptsas_probe_hba_phys(MPT_ADAPTER *ioc) +98 File #5 a/drivers/net/fs_enet/fs_enet-mii.c + 100 Blocco #1 static struct fs_enet_mii_bus *create_bu +111 File #6 a/drivers/net/wireless/ipw2200.c + 113 Blocco #1 static struct ipw_fw_error *ipw_alloc_er + 126 Blocco #2 static ssize_t clear_error(struct device + 140 Blocco #3 static void ipw_irq_tasklet(struct ipw_p + 150 Blocco #4 static void ipw_pci_remove(struct pci_de +164 File #7 a/drivers/scsi/libata-scsi.c + 166 Blocco #1 int ata_cmd_ioctl(struct scsi_device *sc +178 File #8 a/drivers/video/au1100fb.c + 180 Blocco #1 void __exit au1100fb_cleanup(void) + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tools.tools.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tools.tools.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,26 @@ + +$ diffstat -p1 rimuove-controlli-ridondati-su-null.patch + drivers/char/agp/sgi-agp.c | 5 ++--- + drivers/char/hvcs.c | 11 +++++------ + drivers/message/fusion/mptfc.c | 6 ++---- + drivers/message/fusion/mptsas.c | 3 +-- + drivers/net/fs_enet/fs_enet-mii.c | 3 +-- + drivers/net/wireless/ipw2200.c | 22 ++++++---------------- + drivers/scsi/libata-scsi.c | 4 +--- + drivers/video/au1100fb.c | 3 +-- + 8 file modificati, 19 inserimenti(+), 38 cancellazioni(-) +$ filterdiff -i '*/video/*' rimuove-controlli-ridondati-su-null.patch +--- a/drivers/video/au1100fb.c~rimuove-controlli-ridondanti-su-null-prima-di-free-nei-driver ++++ a/drivers/video/au1100fb.c +@@ -743,8 +743,7 @@ void __exit au1100fb_cleanup(void) + { + driver_unregister(&au1100fb_driver); + +- if (drv_info.opt_mode) +- kfree(drv_info.opt_mode); ++ kfree(drv_info.opt_mode); + } + + module_init(au1100fb_init); + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tutorial.add.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tutorial.add.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ echo 'file 3, riga 1' >> file3 +$ hg qnew aggiunta-file3.patch +$ hg qnew -f aggiunta-file3.patch +fallimento: la patch "aggiunta-file3.patch" esiste già + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tutorial.qinit.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tutorial.qinit.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg init mq-prova +$ cd mq-prova +$ echo 'riga 1' > file1 +$ echo "un'altra riga 1" > file2 +$ hg add file1 file2 +$ hg commit -m 'Prima modifica.' +$ hg qinit + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tutorial.qnew.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tutorial.qnew.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,23 @@ + +$ hg tip +changeset: 0:c6618fa9eed7 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:50:56 2009 +0000 +summary: Prima modifica. + +$ hg qnew prima.patch +$ hg tip +changeset: 1:f32697f1a94e +tag: qtip +tag: prima.patch +tag: tip +tag: qbase +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:50:57 2009 +0000 +summary: [mq]: prima.patch + +$ ls .hg/patches +prima.patch series status + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tutorial.qnew2.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tutorial.qnew2.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,31 @@ + +$ hg qnew seconda.patch +$ hg log --style=compact --limit=2 +2[qtip,seconda.patch,tip] 2d7ecb80769d 2009-06-05 15:51 +0000 bos + [mq]: seconda.patch + +1[prima.patch,qbase] 8593307a06ec 2009-06-05 15:51 +0000 bos + [mq]: prima.patch + +$ echo 'riga 4' >> file1 +$ hg qrefresh +$ hg tip --style=compact --patch +2[qtip,seconda.patch,tip] 78d47e79ab59 2009-06-05 15:51 +0000 bos + [mq]: seconda.patch + +diff -r 8593307a06ec -r 78d47e79ab59 file1 +--- a/file1 Fri Jun 05 15:51:00 2009 +0000 ++++ b/file1 Fri Jun 05 15:51:02 2009 +0000 +@@ -1,3 +1,4 @@ + riga 1 + riga 2 + riga 3 ++riga 4 + +$ hg annotate file1 +0: riga 1 +1: riga 2 +1: riga 3 +2: riga 4 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tutorial.qpop.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tutorial.qpop.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,17 @@ + +$ hg qapplied +prima.patch +seconda.patch +$ hg qpop +ora a: prima.patch +$ hg qseries +prima.patch +seconda.patch +$ hg qapplied +prima.patch +$ cat file1 +riga 1 +riga 2 +riga 3 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tutorial.qpush-a.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tutorial.qpush-a.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,11 @@ + +$ hg qpush -a +applico seconda.patch +ora a: seconda.patch +$ cat file1 +riga 1 +riga 2 +riga 3 +riga 4 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tutorial.qrefresh.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tutorial.qrefresh.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,24 @@ + +$ echo 'riga 2' >> file1 +$ hg diff +diff -r f32697f1a94e file1 +--- a/file1 Fri Jun 05 15:50:57 2009 +0000 ++++ b/file1 Fri Jun 05 15:50:58 2009 +0000 +@@ -1,1 +1,2 @@ + riga 1 ++riga 2 +$ hg qrefresh +$ hg diff +$ hg tip --style=compact --patch +1[qtip,prima.patch,tip,qbase] 18f39bf02ad5 2009-06-05 15:50 +0000 bos + [mq]: prima.patch + +diff -r c6618fa9eed7 -r 18f39bf02ad5 file1 +--- a/file1 Fri Jun 05 15:50:56 2009 +0000 ++++ b/file1 Fri Jun 05 15:50:59 2009 +0000 +@@ -1,1 +1,2 @@ + riga 1 ++riga 2 + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tutorial.qrefresh2.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tutorial.qrefresh2.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,19 @@ + +$ echo 'riga 3' >> file1 +$ hg status +M file1 +$ hg qrefresh +$ hg tip --style=compact --patch +1[qtip,prima.patch,tip,qbase] 8593307a06ec 2009-06-05 15:51 +0000 bos + [mq]: prima.patch + +diff -r c6618fa9eed7 -r 8593307a06ec file1 +--- a/file1 Fri Jun 05 15:50:56 2009 +0000 ++++ b/file1 Fri Jun 05 15:51:00 2009 +0000 +@@ -1,1 +1,3 @@ + line 1 ++riga 2 ++riga 3 + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/mq.tutorial.qseries.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/mq.tutorial.qseries.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,9 @@ + +$ hg qseries +prima.patch +seconda.patch +$ hg qapplied +prima.patch +seconda.patch + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/rename.divergent.clone.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rename.divergent.clone.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,9 @@ + +$ hg clone orig anna +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ hg clone orig bruno +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/rename.divergent.merge.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rename.divergent.merge.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,29 @@ + +# Si veda http://www.selenic.com/mercurial/bts/issue455 +$ cd ../orig +$ hg pull -u ../anna +estraggo da ../anna +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file +1 file aggiornati, 0 file uniti, 1 file rimossi, 0 file irrisolti +$ hg pull ../bruno +estraggo da ../bruno +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file (+1 teste) +(eseguite 'hg heads' per vedere le teste, 'hg merge' per unire) +$ hg merge +attenzione: cambiamenti di nome divergenti di foo a: + bar + quux +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +(unione tra rami, ricordatevi di eseguire il commit) +$ ls +bar quux + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/rename.divergent.rename.anne.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rename.divergent.rename.anne.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ cd anna +$ hg rename foo bar +$ hg ci -m 'Rinominato foo a bar.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/rename.divergent.rename.bob.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rename.divergent.rename.bob.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ cd ../bruno +$ hg mv foo quux +$ hg ci -m 'Riominato foo a quux.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/rollback.add.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rollback.add.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg add b +$ hg commit -m 'Aggiunge il file b, questa volta per davvero.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/rollback.commit.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rollback.commit.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg status +M a +$ echo b > b +$ hg commit -m 'Aggiunge il file b.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/rollback.rollback.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rollback.rollback.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,15 @@ + +$ hg rollback +abortisco l'ultima transazione +$ hg tip +changeset: 0:ce49f5b59f20 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:13 2009 +0000 +summary: Primo commit. + +$ hg status +M a +? b + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/rollback.status.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rollback.status.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,12 @@ + +$ hg status +? b +$ hg tip +changeset: 1:249cc777b54f +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:13 2009 +0000 +summary: Aggiunge il file b. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/rollback.twice.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/rollback.twice.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg rollback +abortisco l'ultima transazione +$ hg rollback +nessuna informazione disponibile per abortire una transazione + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tag.init.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tag.init.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ hg init miaetichetta +$ cd miaetichetta +$ echo ciao > miofile +$ hg commit -A -m 'Commit iniziale.' +aggiungo miofile + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tag.log.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tag.log.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ hg log +changeset: 1:87dee45bf6ec +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:18 2009 +0000 +summary: Aggiunta l'etichetta v1.0 per il changeset 35aa95ccc713. + +changeset: 0:35aa95ccc713 +tag: v1.0 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:18 2009 +0000 +summary: Commit iniziale. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tag.log.v1.0.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tag.log.v1.0.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ echo arrivederci > miofile2 +$ hg commit -A -m 'Secondo commit.' +aggiungo miofile2 +$ hg log -r v1.0 +changeset: 0:35aa95ccc713 +tag: v1.0 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:18 2009 +0000 +summary: Commit iniziale. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tag.remove.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tag.remove.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ hg tag --remove v1.0 +$ hg tags +tip 3:f0420ed65292 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tag.replace.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tag.replace.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ hg tag -r 1 v1.1 +$ hg tags +tip 4:2f0219ae190a +v1.1 1:87dee45bf6ec +$ hg tag -r 2 v1.1 +fallimento: l'etichetta 'v1.1' esiste già (usate -f per forzare) +$ hg tag -f -r 2 v1.1 +$ hg tags +tip 5:9a0bd94354ec +v1.1 2:35418c351c2b + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tag.tag.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tag.tag.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg tag v1.0 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tag.tags.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tag.tags.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ hg tags +tip 1:87dee45bf6ec +v1.0 0:35aa95ccc713 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tag.tip.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tag.tip.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg tip +changeset: 5:9a0bd94354ec +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:22 2009 +0000 +summary: Aggiunta l'etichetta v1.1 per il changeset 35418c351c2b. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.simple.changelog.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.simple.changelog.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,25 @@ + +$ hg log --style changelog +2009-06-05 Bryan O'Sullivan <bos@serpentine.com> + + * .hgtags: + Aggiunta etichetta v0.1 per il changeset a5ff5617a0be + [1102dd469cfc] [tip] + + * .hgtags: + Aggiunta etichetta miaetichetta per il changeset fb5e3583537a + [a5ff5617a0be] [v0.1] + + * goodbye, hello: + Aggiunta una riga alla fine del file <<hello>>. + + In più, aggiunto un file con il nome indicativo (almeno spero che qualcuno + possa considerarlo tale) di goodbye. + [fb5e3583537a] [miaetichetta] + + * hello: + Aggiunto file hello. + [0afbebcdeafc] + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.simple.combine.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.simple.combine.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,9 @@ + +$ hg log -r1 --template 'descrizione:\n\t{desc|strip|fill68|tabindent}\n' +descrizione: + Aggiunta una riga alla fine del file <<hello>>. + + In più, aggiunto un file con il nome indicativo (almeno spero che + qualcuno possa considerarlo tale) di goodbye. + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.simple.compact.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.simple.compact.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ hg log --style compact +3[tip] 1102dd469cfc 2009-06-05 15:51 +0000 bos + Aggiunta etichetta v0.1 per il changeset a5ff5617a0be + +2[v0.1] a5ff5617a0be 2009-06-05 15:51 +0000 bos + Aggiunta etichetta miaetichetta per il changeset fb5e3583537a + +1[mytag] fb5e3583537a 2009-06-05 15:51 +0000 bos + Aggiunta una riga alla fine del file <<hello>>. + +0 0afbebcdeafc 2009-06-05 15:51 +0000 bos + Aggiunto file hello. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.simple.datekeyword.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.simple.datekeyword.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg log -r1 --template 'data: {date}\n' +data: 1244217084.00 +$ hg log -r1 --template 'data: {date|isodate}\n' +data: 2009-06-05 15:51 +0000 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.simple.keywords.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.simple.keywords.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,24 @@ + +$ hg log -r1 --template 'autore: {author}\n' +autore: Bryan O'Sullivan <bos@serpentine.com> +$ hg log -r1 --template 'desc:\n{desc}\n' +desc: +Aggiunta una riga alla fine del file <<hello>>. + +In più, aggiunto un file con il nome indicativo (almeno spero che qualcuno possa considerarlo tale) di goodbye. +$ hg log -r1 --template 'file: {files}\n' +file: goodbye hello +$ hg log -r1 --template 'file aggiunti: {file_adds}\n' +file aggiunti: goodbye +$ hg log -r1 --template 'file rimossi: {file_dels}\n' +file rimossi: +$ hg log -r1 --template 'nodo: {node}\n' +nodo: fb5e3583537ab9d278f45d18bcb07262af1e7226 +$ hg log -r1 --template 'genitori: {parents}\n' +genitori: +$ hg log -r1 --template 'revisione: {rev}\n' +revisione: 1 +$ hg log -r1 --template 'etichette: {tags}\n' +etichette: miaetichetta + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.simple.manyfilters.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.simple.manyfilters.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,65 @@ + +$ hg log -r1 --template '{author}\n' +Bryan O'Sullivan <bos@serpentine.com> +$ hg log -r1 --template '{author|domain}\n' +serpentine.com +$ hg log -r1 --template '{author|email}\n' +bos@serpentine.com +$ hg log -r1 --template '{author|obfuscate}\n' | cut -c-76 +Bryan O'Sulli&#11 +$ hg log -r1 --template '{author|person}\n' +Bryan O'Sullivan +$ hg log -r1 --template '{author|user}\n' +bos +$ hg log -r1 --template 'sembra quasi giusta, ma in realtà è inutilizzabile: {date}\n' +sembra quasi giusta, ma in realtà è inutilizzabile: 1244217084.00 +$ hg log -r1 --template '{date|age}\n' +10 secondi +$ hg log -r1 --template '{date|date}\n' +Fri Jun 05 15:51:24 2009 +0000 +$ hg log -r1 --template '{date|hgdate}\n' +1244217084 0 +$ hg log -r1 --template '{date|isodate}\n' +2009-06-05 15:51 +0000 +$ hg log -r1 --template '{date|rfc822date}\n' +Fri, 05 Jun 2009 15:51:24 +0000 +$ hg log -r1 --template '{date|shortdate}\n' +2009-06-05 +$ hg log -r1 --template '{desc}\n' | cut -c-76 +Aggiunta una riga alla fine del file <<hello>>. + +In più, aggiunto un file con il nome indicativo (almeno spero che qualcuno +$ hg log -r1 --template '{desc|addbreaks}\n' | cut -c-76 +Aggiunta una riga alla fine del file <<hello>>.<br/> +<br/> +In più, aggiunto un file con il nome indicativo (almeno spero che qualcuno +$ hg log -r1 --template '{desc|escape}\n' | cut -c-76 +Aggiunta una riga alla fine del file <<hello>>. + +In più, aggiunto un file con il nome indicativo (almeno spero che qualcuno +$ hg log -r1 --template '{desc|fill68}\n' +Aggiunta una riga alla fine del file <<hello>>. + +In più, aggiunto un file con il nome indicativo (almeno spero che +qualcuno possa considerarlo tale) di goodbye. +$ hg log -r1 --template '{desc|fill76}\n' +Aggiunta una riga alla fine del file <<hello>>. + +In più, aggiunto un file con il nome indicativo (almeno spero che qualcuno +possa considerarlo tale) di goodbye. +$ hg log -r1 --template '{desc|firstline}\n' +Aggiunta una riga alla fine del file <<hello>>. +$ hg log -r1 --template '{desc|strip}\n' | cut -c-76 +Aggiunta una riga alla fine del file <<hello>>. + +In più, aggiunto un file con il nome indicativo (almeno spero che qualcuno +$ hg log -r1 --template '{desc|tabindent}\n' | expand | cut -c-76 +Aggiunta una riga alla fine del file <<hello>>. + + In più, aggiunto un file con il nome indicativo (almeno spero che qu +$ hg log -r1 --template '{node}\n' +fb5e3583537ab9d278f45d18bcb07262af1e7226 +$ hg log -r1 --template '{node|short}\n' +fb5e3583537a + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.simple.normal.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.simple.normal.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg log -r1 +changeset: 1:fb5e3583537a +tag: miaetichetta +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:24 2009 +0000 +summary: Aggiunta una riga alla fine del file <<hello>>. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.simple.rev.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.simple.rev.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ echo 'changeset = "revisione: {rev}\n"' > rev +$ hg log -l1 --style ./rev +revisione: 3 + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.simple.simplest.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.simple.simplest.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg log -r1 --template 'ho visto un changeset\n' +ho visto un changeset + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.simple.simplesub.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.simple.simplesub.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg log --template 'ho visto un changeset: {desc}\n' +ho visto un changeset: Aggiunta etichetta v0.1 per il changeset a5ff5617a0be +ho visto un changeset: Aggiunta etichetta miaetichetta per il changeset fb5e3583537a +ho visto un changeset: Aggiunta una riga alla fine del file <<hello>>. + +In più, aggiunto un file con il nome indicativo (almeno spero che qualcuno possa considerarlo tale) di goodbye. +ho visto un changeset: Aggiunto file hello. + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.svnstyle.id.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.svnstyle.id.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg log -r0 --template '{node}' +6d6d6f73864f8fc2d56e1f788c751e0445bdb13e + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.svnstyle.short.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.svnstyle.short.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,14 @@ + +$ svn log -r9653 +------------------------------------------------------------------------ +r9653 | sean.hefty | 2006-09-27 14:39:55 -0700 (Wed, 27 Sep 2006) | 6 righe + +Indicando un errore di connessione, includi anche il codice di +stato per l'errore, piuttosto che usare un codice di stato pari +a 0 quando è avvenuto un errore. + +Firmato-da: Sean Hefty <sean.hefty@intel.com> + +------------------------------------------------------------------------ + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.svnstyle.style.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.svnstyle.style.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ cat svn.stile +header = '------------------------------------------------------------------------\n\n' +changeset = svn.template + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.svnstyle.syntax.error.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.svnstyle.syntax.error.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg log -r1 --style stile.errato +fallimento: stile.errato:1: errore di riconoscimento + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.svnstyle.syntax.input.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.svnstyle.syntax.input.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ cat stile.errato +changeset = + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/template.svnstyle.template.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/template.svnstyle.template.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,9 @@ + +$ cat svn.template +r{rev} | {author|user} | {date|isodate} ({date|rfc822date}) + +{desc|strip|fill76} + +------------------------------------------------------------------------ + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour-merge-conflict.commit.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour-merge-conflict.commit.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,19 @@ + +$ cat > lettera.txt <<EOF +> Salve! +> Sono Bryan O'Sullivan, nessuna parentela con l'ex +> dittatore nigeriano Sani Abacha. +> EOF +$ hg resolve -m lettera.txt +$ hg commit -m 'Mandatemi i vostri soldi' +$ hg tip +changeset: 3:df19ae0ef4d4 +tag: tip +parent: 1:ae14113af250 +parent: 2:11ab3b2b6d1b +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:52:13 2009 +0000 +summary: Mandatemi i vostri soldi + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour-merge-conflict.cousin.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour-merge-conflict.cousin.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,14 @@ + +$ cd .. +$ hg clone truffa truffa-cugino +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd truffa-cugino +$ cat > lettera.txt <<EOF +> Salve! +> Sono Shehu Musa Abacha, cugino dell'ex +> dittatore nigeriano Sani Abacha. +> EOF +$ hg commit -m 'truffa 419, con cugino' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour-merge-conflict.merge.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour-merge-conflict.merge.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,18 @@ + +$ export HGMERGE=merge +$ hg merge +unisco lettera.txt +merge: attenzione: conflitti durante l'unione +unione di lettera.txt fallita! +0 file aggiornati, 0 file uniti, 0 file rimossi, 1 file irrisolti +usate 'hg resolve' per riprovare a unire i file irrisolti o 'hg up --clean' per abbandonare +$ cat lettera.txt +Salve! +<<<<<<< /tmp/panoramica-unioni-conflitto/truffa-unione/lettera.txt +Sono Shehu Musa Abacha, cugino dell'ex +======= +Sono Alhaji Abba Abacha, figlio dell'ex +>>>>>>> /tmp/lettera.txt~other.01poS4 +dittatore nigeriano Sani Abacha. + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour-merge-conflict.pull.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour-merge-conflict.pull.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,17 @@ + +$ cd .. +$ hg clone truffa-cugino truffa-unione +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd truffa-unione +$ hg pull -u ../truffa-figlio +estraggo da ../scam-son +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file (+1 teste) +non aggiorno, sono state aggiunte nuove teste +(eseguite 'hg heads' per vedere le teste, 'hg merge' per unire) + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour-merge-conflict.son.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour-merge-conflict.son.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,14 @@ + +$ cd .. +$ hg clone truffa truffa-figlio +aggiorno la directory di lavoro +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd truffa-figlio +$ cat > lettera.txt <<EOF +> Salve! +> Sono Alhaji Abba Abacha, figlio dell'ex +> dittatore nigeriano Sani Abacha. +> EOF +$ hg commit -m 'truffa 419, con figlio' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour-merge-conflict.wife.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour-merge-conflict.wife.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ cat > lettera.txt <<EOF +> Salve! +> Sono Mariam Abacha, la moglie dell'ex +> dittatore nigeriano Sani Abacha. +> EOF +$ hg add letter.txt +$ hg commit -m 'truffa 419, prima bozza' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.cat1.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.cat1.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,17 @@ + +$ cat hello.c +/* + * Rilasciato nel pubblico dominio da Bryan O'Sullivan. Questo + * programma non è protetto da brevetti negli Stati Uniti o in + * altri paesi. + */ + +#include <stdio.h> + +int main(int argc, char **argv) +{ + printf("ciao, mondo!\"); + return 0; +} + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.cat2.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.cat2.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,19 @@ + +# ... modifichiamo il file ... +$ cat hello.c +/* + * Rilasciato nel pubblico dominio da Bryan O'Sullivan. Questo + * programma non è protetto da brevetti negli Stati Uniti o in + * altri paesi. + */ + +#include <stdio.h> + +int main(int argc, char **argv) +{ + printf("ciao, mondo!\"); + printf("ancora ciao!\n"); + return 0; +} + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.clone-pull.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.clone-pull.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ cd .. +$ hg clone hello hello-pull +aggiorno la directory di lavoro +2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.clone-push.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.clone-push.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ cd .. +$ hg clone hello hello-push +aggiorno la directory di lavoro +2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.clone.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.clone.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,12 @@ + +$ hg clone http://hg.serpentine.com/tutorial/hello +directory di destinazione: hello +richiedo tutte le modifiche +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 5 changeset con 5 cambiamenti a 2 file +aggiorno la directory di lavoro +2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.commit.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.commit.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg commit + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.diff.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.diff.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,14 @@ + +$ hg diff +diff -r 2278160e78d4 hello.c +--- a/hello.c Sat Aug 16 22:16:53 2008 +0200 ++++ b/hello.c Fri Jun 05 15:51:51 2009 +0000 +@@ -8,5 +8,6 @@ + int main(int argc, char **argv) + { + printf("ciao, mondo!\"); ++ printf("ancora ciao!\n"); + return 0; + } + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.help.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.help.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,23 @@ + +$ hg help init +hg init [-e CMD] [--remotecmd CMD] [DEST] + +crea un nuovo repository nella directory data + + Inizializza un nuovo repository nella directory data. Se questa + directory non esiste, viene creata. + + Se non viene data alcuna directory, il comando usa la directory + corrente. + + È possibile specificare un URL ssh:// come destinazione. + Si veda 'hg help urls' per maggiori informazioni. + +opzioni: + + -e --ssh specifica il comando ssh da usare + --remotecmd specifica il comando hg da eseguire in remoto + +usate "hg -v help init" per vedere le opzioni globali + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.incoming.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.incoming.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ cd hello-pull +$ hg incoming ../my-hello +confronto con ../my-hello +cerco i cambiamenti +changeset: 5:764347e47e75 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:52 2009 +0000 +summary: Inserisce una riga con un messaggio aggiuntivo. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.log-r.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.log-r.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,27 @@ + +$ hg log -r 3 +changeset: 3:0272e0d5a517 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:08:02 2008 +0200 +summary: Induce make a generare l'eseguibile finale dal file .o. + +$ hg log -r 0272e0d5a517 +changeset: 3:0272e0d5a517 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:08:02 2008 +0200 +summary: Induce make a generare l'eseguibile finale dal file .o. + +$ hg log -r 1 -r 4 +changeset: 1:82e55d328c8c +user: mpm@selenic.com +date: Fri Aug 26 01:21:28 2005 -0700 +summary: Crea un makefile. + +changeset: 4:2278160e78d4 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:16:53 2008 +0200 +summary: Aggiusta i commenti. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.log-v.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.log-v.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,12 @@ + +$ hg log -v -r 3 +changeset: 3:0272e0d5a517 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:08:02 2008 +0200 +files: Makefile +description: +Induce make a generare l'eseguibile finale dal file .o. + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.log-vp.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.log-vp.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,24 @@ + +$ hg log -v -p -r 2 +changeset: 2:fef857204a0c +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:05:04 2008 +0200 +files: hello.c +description: +Introduce un errore in hello.c. + + +diff -r 82e55d328c8c -r fef857204a0c hello.c +--- a/hello.c Fri Aug 26 01:21:28 2005 -0700 ++++ b/hello.c Sat Aug 16 22:05:04 2008 +0200 +@@ -11,6 +11,6 @@ + + int main(int argc, char **argv) + { +- printf("ciao, mondo!\n"); ++ printf("ciao, mondo!\"); + return 0; + } + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.log.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.log.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,30 @@ + +$ hg log +changeset: 4:2278160e78d4 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:16:53 2008 +0200 +summary: Aggiusta i commenti. + +changeset: 3:0272e0d5a517 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:08:02 2008 +0200 +summary: Induce make a generare l'eseguibile finale dal file .o. + +changeset: 2:fef857204a0c +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:05:04 2008 +0200 +summary: Introduce un errore in hello.c. + +changeset: 1:82e55d328c8c +user: mpm@selenic.com +date: Fri Aug 26 01:21:28 2005 -0700 +summary: Crea un makefile. + +changeset: 0:0a04b987be5a +user: mpm@selenic.com +date: Fri Aug 26 01:20:50 2005 -0700 +summary: Crea il classico programma "ciao, mondo". + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.log.range.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.log.range.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,20 @@ + +$ hg log -r 2:4 +changeset: 2:fef857204a0c +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:05:04 2008 +0200 +summary: Introduce un errore in hello.c. + +changeset: 3:0272e0d5a517 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:08:02 2008 +0200 +summary: Induce make a generare l'eseguibile finale dal file .o. + +changeset: 4:2278160e78d4 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:16:53 2008 +0200 +summary: Aggiusta i commenti. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.ls-a.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.ls-a.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,6 @@ + +$ cd hello +$ ls -a +. .. .hg Makefile hello.c + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.ls.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.ls.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ ls -l +total 4 +drwxrwxr-x 3 bos bos 4096 May 5 06:55 hello +$ ls hello +Makefile hello.c + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.merge.cat1.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.merge.cat1.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,19 @@ + +$ cat hello.c +/* + * Rilasciato nel pubblico dominio da Bryan O'Sullivan. Questo + * programma non è protetto da brevetti negli Stati Uniti o in + * altri paesi. + */ + +#include <stdio.h> + +int main(int argc, char **argv) +{ + printf("ancora una volta, ciao.\n"); + printf("ciao, mondo!\"); + printf("ancora ciao!\n"); + return 0; +} + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.merge.cat2.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.merge.cat2.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,18 @@ + +$ cat ../my-hello/hello.c +/* + * Rilasciato nel pubblico dominio da Bryan O'Sullivan. Questo + * programma non è protetto da brevetti negli Stati Uniti o in + * altri paesi. + */ + +#include <stdio.h> + +int main(int argc, char **argv) +{ + printf("ciao, mondo!\"); + printf("ancora ciao!\n"); + return 0; +} + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.merge.clone.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.merge.clone.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,11 @@ + +$ cd .. +$ hg clone hello my-new-hello +aggiorno la directory di lavoro +2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd my-new-hello +# Apportiamo alcune semplici modifiche a hello.c... +$ mio-editor-di-testo hello.c +$ hg commit -m 'Un nuovo saluto per un nuovo giorno.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.merge.commit.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.merge.commit.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,4 @@ + +$ hg commit -m 'Unisce i cambiamenti.' + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.merge.heads.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.merge.heads.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,16 @@ + +$ hg heads +changeset: 6:764347e47e75 +tag: tip +parent: 4:2278160e78d4 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:52 2009 +0000 +summary: Inserisce una riga con un messaggio aggiuntivo. + +changeset: 5:1c343117a2e3 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:52:03 2009 +0000 +summary: Un nuovo saluto per un nuovo giorno. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.merge.merge.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.merge.merge.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg merge +unisco hello.c +0 file aggiornati, 1 file uniti, 0 file rimossi, 0 file irrisolti +(unione tra rami, ricordatevi di eseguire il commit) + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.merge.parents.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.merge.parents.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,32 @@ + +$ hg parents +changeset: 5:1c343117a2e3 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:52:03 2009 +0000 +summary: Un nuovo saluto per un nuovo giorno. + +changeset: 6:764347e47e75 +tag: tip +parent: 4:2278160e78d4 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:52 2009 +0000 +summary: Inserisce una riga con un messaggio aggiuntivo. + +$ cat hello.c +/* + * Rilasciato nel pubblico dominio da Bryan O'Sullivan. Questo + * programma non è protetto da brevetti negli Stati Uniti o in + * altri paesi. + */ + +#include <stdio.h> + +int main(int argc, char **argv) +{ + printf("ancora una volta, ciao.\n"); + printf("ciao, mondo!\"); + printf("ancora ciao!\n"); + return 0; +} + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.merge.pull.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.merge.pull.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,11 @@ + +$ hg pull ../my-hello +estraggo da ../my-hello +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 1 file (+1 teste) +(eseguite 'hg heads' per vedere le teste, 'hg merge' per unire) + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.merge.tip.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.merge.tip.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,12 @@ + +$ hg tip +changeset: 7:e300c3dcceca +tag: tip +parent: 5:1c343117a2e3 +parent: 6:764347e47e75 +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:52:07 2009 +0000 +summary: Unisce i cambiamenti. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.merge.update.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.merge.update.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,5 @@ + +$ hg update +fallimento: attraversa i rami (usate 'hg merge' o 'hg update -C') + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.older.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.older.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,20 @@ + +$ hg update 2 +2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ hg parents +changeset: 2:fef857204a0c +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:05:04 2008 +0200 +summary: Introduce un errore in hello.c. + +$ hg update +2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ hg parents +changeset: 5:764347e47e75 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:52 2009 +0000 +summary: Inserisce una riga con un messaggio aggiuntivo. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.outgoing.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.outgoing.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,13 @@ + +$ cd my-hello +$ hg outgoing ../hello-push +confronto con ../hello-push +cerco i cambiamenti +changeset: 5:764347e47e75 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:52 2009 +0000 +summary: Inserisce una riga con un messaggio aggiuntivo. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.outgoing.net.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.outgoing.net.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,12 @@ + +$ hg outgoing http://hg.serpentine.com/tutorial/hello +confronto con http://hg.serpentine.com/tutorial/hello +cerco i cambiamenti +changeset: 5:764347e47e75 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:52 2009 +0000 +summary: Inserisce una riga con un messaggio aggiuntivo. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.parents.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.parents.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg parents +changeset: 5:764347e47e75 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:52 2009 +0000 +summary: Inserisce una riga con un messaggio aggiuntivo. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.pull.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.pull.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,25 @@ + +$ hg tip +changeset: 4:2278160e78d4 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Sat Aug 16 22:16:53 2008 +0200 +summary: Aggiusta i commenti. + +$ hg pull ../my-hello +estraggo da ../my-hello +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 2 file +(eseguite 'hg update' per ottenere una copia di lavoro) +$ hg tip +changeset: 5:764347e47e75 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:52 2009 +0000 +summary: Inserisce una riga con un messaggio aggiuntivo. + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.push.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.push.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg push ../hello-push +trasmetto a ../hello-push +cerco i cambiamenti +aggiungo i changeset +aggiungo i manifest +aggiungo i cambiamenti ai file +aggiunti 1 changeset con 1 cambiamenti a 2 file + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.push.net.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.push.net.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg push http://hg.serpentine.com/tutorial/hello +trasmetto a http://hg.serpentine.com/tutorial/hello +cerco i cambiamenti +connessione ssl richiesta + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.push.nothing.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.push.nothing.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ hg push ../hello-push +trasmetto a ../hello-push +cerco i cambiamenti +nessun cambiamento trovato + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.reclone.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.reclone.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + +$ cd .. +$ hg clone hello my-hello +aggiorno la directory di lavoro +2 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ cd my-hello + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.status.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.status.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ + +$ ls +Makefile hello.c +$ hg status +M hello.c + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.tip.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.tip.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,24 @@ + +$ hg tip -vp +changeset: 5:764347e47e75 +tag: tip +user: Bryan O'Sullivan <bos@serpentine.com> +date: Fri Jun 05 15:51:52 2009 +0000 +files: hello.c +description: +Inserisce una riga con un messaggio aggiuntivo. + + +diff -r 2278160e78d4 -r 764347e47e75 hello.c +--- a/hello.c Sat Aug 16 22:16:53 2008 +0200 ++++ b/hello.c Fri Jun 05 15:51:52 2009 +0000 +@@ -8,5 +8,6 @@ + int main(int argc, char **argv) + { + printf("ciao, mondo!\"); ++ printf("ancora ciao!\n"); + return 0; + } + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.update.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.update.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ grep printf hello.c + printf("ciao, mondo!\"); +$ hg update tip +1 file aggiornati, 0 file uniti, 0 file rimossi, 0 file irrisolti +$ grep printf hello.c + printf("ciao, mondo!\"); + printf("ancora ciao!\n"); + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/examples/tour.version.it --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/examples/tour.version.it Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + +$ hg version +Mercurial SCM distribuito (versione 1.2) + +Copyright (C) 2005-2008 Matt Mackall <mpm@selenic.com> e altri +Questo è software libero, si vedano i sorgenti per le condizioni di +copia. NON c'è alcuna garanzia, neppure di COMMERCIABILITÀ o IDONEITÀ +AD UNO SCOPO PARTICOLARE. + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/web/genindex.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/web/genindex.py Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,58 @@ +# This script works with Python 3.0 or above + +import glob, os, re + +chapter_re = re.compile(r'<(chapter|appendix|preface)\s+id="([^"]+)">') +filename_re = re.compile(r'<\?dbhtml filename="([^"]+)"\?>') +title_re = re.compile(r'(.*)') + +chapters = (sorted(glob.glob('../ch*.xml')) + + sorted(glob.glob('../app*.xml'))) + +fp = open('index-read.html.in', 'w', encoding='utf-8') + +print(''' +

Mercurial: la guida definitiva
di Bryan O'Sullivan

%(date)s%(num)s. %(title)s

', file=fp) + +fp.close() diff -r eca3a16c0114 -r 4d4e9bea4359 it/web/hgbook.js --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/web/hgbook.js Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,7 @@ +$(document).ready(function() { + $("div.toc>p") + .toggle(function() { $(this).nextAll().show("normal"); }, + function() { $(this).nextAll().hide("normal"); }) + .hover(function() { $(this).fadeTo("normal", 0.8); }, + function() { $(this).fadeTo("normal", 0.35); }); +}); diff -r eca3a16c0114 -r 4d4e9bea4359 it/web/index-template.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/web/index-template.html Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,37 @@ + + + + + Mercurial: la guida definitiva + + + + + + + + {% block bodycontent %}{% endblock %} + +

Volete rimanere aggiornati? Abbonatevi al feed delle modifiche per qualsiasi capitolo o per l'intero libro.

+ + + + diff -r eca3a16c0114 -r 4d4e9bea4359 it/web/jquery-min.js --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/it/web/jquery-min.js Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,31 @@ +/* + * jQuery 1.2.1 - New Wave Javascript + * + * Copyright (c) 2007 John Resig (jquery.com) + * Dual licensed under the MIT (MIT-LICENSE.txt) + * and GPL (GPL-LICENSE.txt) licenses. + * + * $Date: 2007-09-16 23:42:06 -0400 (Sun, 16 Sep 2007) $ + * $Rev: 3353 $ + */ +(function(){if(typeof jQuery!="undefined")var _jQuery=jQuery;var jQuery=window.jQuery=function(selector,context){return this instanceof jQuery?this.init(selector,context):new jQuery(selector,context);};if(typeof $!="undefined")var _$=$;window.$=jQuery;var quickExpr=/^[^<]*(<(.|\s)+>)[^>]*$|^#(\w+)$/;jQuery.fn=jQuery.prototype={init:function(selector,context){selector=selector||document;if(typeof selector=="string"){var m=quickExpr.exec(selector);if(m&&(m[1]||!context)){if(m[1])selector=jQuery.clean([m[1]],context);else{var tmp=document.getElementById(m[3]);if(tmp)if(tmp.id!=m[3])return jQuery().find(selector);else{this[0]=tmp;this.length=1;return this;}else +selector=[];}}else +return new jQuery(context).find(selector);}else if(jQuery.isFunction(selector))return new jQuery(document)[jQuery.fn.ready?"ready":"load"](selector);return this.setArray(selector.constructor==Array&&selector||(selector.jquery||selector.length&&selector!=window&&!selector.nodeType&&selector[0]!=undefined&&selector[0].nodeType)&&jQuery.makeArray(selector)||[selector]);},jquery:"1.2.1",size:function(){return this.length;},length:0,get:function(num){return num==undefined?jQuery.makeArray(this):this[num];},pushStack:function(a){var ret=jQuery(a);ret.prevObject=this;return ret;},setArray:function(a){this.length=0;Array.prototype.push.apply(this,a);return this;},each:function(fn,args){return jQuery.each(this,fn,args);},index:function(obj){var pos=-1;this.each(function(i){if(this==obj)pos=i;});return pos;},attr:function(key,value,type){var obj=key;if(key.constructor==String)if(value==undefined)return this.length&&jQuery[type||"attr"](this[0],key)||undefined;else{obj={};obj[key]=value;}return this.each(function(index){for(var prop in obj)jQuery.attr(type?this.style:this,prop,jQuery.prop(this,obj[prop],type,index,prop));});},css:function(key,value){return this.attr(key,value,"curCSS");},text:function(e){if(typeof e!="object"&&e!=null)return this.empty().append(document.createTextNode(e));var t="";jQuery.each(e||this,function(){jQuery.each(this.childNodes,function(){if(this.nodeType!=8)t+=this.nodeType!=1?this.nodeValue:jQuery.fn.text([this]);});});return t;},wrapAll:function(html){if(this[0])jQuery(html,this[0].ownerDocument).clone().insertBefore(this[0]).map(function(){var elem=this;while(elem.firstChild)elem=elem.firstChild;return elem;}).append(this);return this;},wrapInner:function(html){return this.each(function(){jQuery(this).contents().wrapAll(html);});},wrap:function(html){return this.each(function(){jQuery(this).wrapAll(html);});},append:function(){return this.domManip(arguments,true,1,function(a){this.appendChild(a);});},prepend:function(){return this.domManip(arguments,true,-1,function(a){this.insertBefore(a,this.firstChild);});},before:function(){return this.domManip(arguments,false,1,function(a){this.parentNode.insertBefore(a,this);});},after:function(){return this.domManip(arguments,false,-1,function(a){this.parentNode.insertBefore(a,this.nextSibling);});},end:function(){return this.prevObject||jQuery([]);},find:function(t){var data=jQuery.map(this,function(a){return jQuery.find(t,a);});return this.pushStack(/[^+>] [^+>]/.test(t)||t.indexOf("..")>-1?jQuery.unique(data):data);},clone:function(events){var ret=this.map(function(){return this.outerHTML?jQuery(this.outerHTML)[0]:this.cloneNode(true);});var clone=ret.find("*").andSelf().each(function(){if(this[expando]!=undefined)this[expando]=null;});if(events===true)this.find("*").andSelf().each(function(i){var events=jQuery.data(this,"events");for(var type in events)for(var handler in events[type])jQuery.event.add(clone[i],type,events[type][handler],events[type][handler].data);});return ret;},filter:function(t){return this.pushStack(jQuery.isFunction(t)&&jQuery.grep(this,function(el,index){return t.apply(el,[index]);})||jQuery.multiFilter(t,this));},not:function(t){return this.pushStack(t.constructor==String&&jQuery.multiFilter(t,this,true)||jQuery.grep(this,function(a){return(t.constructor==Array||t.jquery)?jQuery.inArray(a,t)<0:a!=t;}));},add:function(t){return this.pushStack(jQuery.merge(this.get(),t.constructor==String?jQuery(t).get():t.length!=undefined&&(!t.nodeName||jQuery.nodeName(t,"form"))?t:[t]));},is:function(expr){return expr?jQuery.multiFilter(expr,this).length>0:false;},hasClass:function(expr){return this.is("."+expr);},val:function(val){if(val==undefined){if(this.length){var elem=this[0];if(jQuery.nodeName(elem,"select")){var index=elem.selectedIndex,a=[],options=elem.options,one=elem.type=="select-one";if(index<0)return null;for(var i=one?index:0,max=one?index+1:options.length;i=0||jQuery.inArray(this.name,val)>=0);else if(jQuery.nodeName(this,"select")){var tmp=val.constructor==Array?val:[val];jQuery("option",this).each(function(){this.selected=(jQuery.inArray(this.value,tmp)>=0||jQuery.inArray(this.text,tmp)>=0);});if(!tmp.length)this.selectedIndex=-1;}else +this.value=val;});},html:function(val){return val==undefined?(this.length?this[0].innerHTML:null):this.empty().append(val);},replaceWith:function(val){return this.after(val).remove();},eq:function(i){return this.slice(i,i+1);},slice:function(){return this.pushStack(Array.prototype.slice.apply(this,arguments));},map:function(fn){return this.pushStack(jQuery.map(this,function(elem,i){return fn.call(elem,i,elem);}));},andSelf:function(){return this.add(this.prevObject);},domManip:function(args,table,dir,fn){var clone=this.length>1,a;return this.each(function(){if(!a){a=jQuery.clean(args,this.ownerDocument);if(dir<0)a.reverse();}var obj=this;if(table&&jQuery.nodeName(this,"table")&&jQuery.nodeName(a[0],"tr"))obj=this.getElementsByTagName("tbody")[0]||this.appendChild(document.createElement("tbody"));jQuery.each(a,function(){var elem=clone?this.cloneNode(true):this;if(!evalScript(0,elem))fn.call(obj,elem);});});}};function evalScript(i,elem){var script=jQuery.nodeName(elem,"script");if(script){if(elem.src)jQuery.ajax({url:elem.src,async:false,dataType:"script"});else +jQuery.globalEval(elem.text||elem.textContent||elem.innerHTML||"");if(elem.parentNode)elem.parentNode.removeChild(elem);}else if(elem.nodeType==1)jQuery("script",elem).each(evalScript);return script;}jQuery.extend=jQuery.fn.extend=function(){var target=arguments[0]||{},a=1,al=arguments.length,deep=false;if(target.constructor==Boolean){deep=target;target=arguments[1]||{};}if(al==1){target=this;a=0;}var prop;for(;a-1;}},swap:function(e,o,f){for(var i in o){e.style["old"+i]=e.style[i];e.style[i]=o[i];}f.apply(e,[]);for(var i in o)e.style[i]=e.style["old"+i];},css:function(e,p){if(p=="height"||p=="width"){var old={},oHeight,oWidth,d=["Top","Bottom","Right","Left"];jQuery.each(d,function(){old["padding"+this]=0;old["border"+this+"Width"]=0;});jQuery.swap(e,old,function(){if(jQuery(e).is(':visible')){oHeight=e.offsetHeight;oWidth=e.offsetWidth;}else{e=jQuery(e.cloneNode(true)).find(":radio").removeAttr("checked").end().css({visibility:"hidden",position:"absolute",display:"block",right:"0",left:"0"}).appendTo(e.parentNode)[0];var parPos=jQuery.css(e.parentNode,"position")||"static";if(parPos=="static")e.parentNode.style.position="relative";oHeight=e.clientHeight;oWidth=e.clientWidth;if(parPos=="static")e.parentNode.style.position="static";e.parentNode.removeChild(e);}});return p=="height"?oHeight:oWidth;}return jQuery.curCSS(e,p);},curCSS:function(elem,prop,force){var ret,stack=[],swap=[];function color(a){if(!jQuery.browser.safari)return false;var ret=document.defaultView.getComputedStyle(a,null);return!ret||ret.getPropertyValue("color")=="";}if(prop=="opacity"&&jQuery.browser.msie){ret=jQuery.attr(elem.style,"opacity");return ret==""?"1":ret;}if(prop.match(/float/i))prop=styleFloat;if(!force&&elem.style[prop])ret=elem.style[prop];else if(document.defaultView&&document.defaultView.getComputedStyle){if(prop.match(/float/i))prop="float";prop=prop.replace(/([A-Z])/g,"-$1").toLowerCase();var cur=document.defaultView.getComputedStyle(elem,null);if(cur&&!color(elem))ret=cur.getPropertyValue(prop);else{for(var a=elem;a&&color(a);a=a.parentNode)stack.unshift(a);for(a=0;a]*?)\/>/g,function(m,all,tag){return tag.match(/^(abbr|br|col|img|input|link|meta|param|hr|area)$/i)?m:all+">";});var s=jQuery.trim(arg).toLowerCase(),div=doc.createElement("div"),tb=[];var wrap=!s.indexOf("",""]||!s.indexOf("",""]||s.match(/^<(thead|tbody|tfoot|colg|cap)/)&&[1,"","

"]||!s.indexOf("",""]||(!s.indexOf("",""]||!s.indexOf("",""]||jQuery.browser.msie&&[1,"div

","

"]||[0,"",""];div.innerHTML=wrap[1]+arg+wrap[2];while(wrap[0]--)div=div.lastChild;if(jQuery.browser.msie){if(!s.indexOf(""&&s.indexOf("=0;--n)if(jQuery.nodeName(tb[n],"tbody")&&!tb[n].childNodes.length)tb[n].parentNode.removeChild(tb[n]);if(/^\s/.test(arg))div.insertBefore(doc.createTextNode(arg.match(/^\s*/)[0]),div.firstChild);}arg=jQuery.makeArray(div.childNodes);}if(0===arg.length&&(!jQuery.nodeName(arg,"form")&&!jQuery.nodeName(arg,"select")))return;if(arg[0]==undefined||jQuery.nodeName(arg,"form")||arg.options)r.push(arg);else +r=jQuery.merge(r,arg);});return r;},attr:function(elem,name,value){var fix=jQuery.isXMLDoc(elem)?{}:jQuery.props;if(name=="selected"&&jQuery.browser.safari)elem.parentNode.selectedIndex;if(fix[name]){if(value!=undefined)elem[fix[name]]=value;return elem[fix[name]];}else if(jQuery.browser.msie&&name=="style")return jQuery.attr(elem.style,"cssText",value);else if(value==undefined&&jQuery.browser.msie&&jQuery.nodeName(elem,"form")&&(name=="action"||name=="method"))return elem.getAttributeNode(name).nodeValue;else if(elem.tagName){if(value!=undefined){if(name=="type"&&jQuery.nodeName(elem,"input")&&elem.parentNode)throw"type property can't be changed";elem.setAttribute(name,value);}if(jQuery.browser.msie&&/href|src/.test(name)&&!jQuery.isXMLDoc(elem))return elem.getAttribute(name,2);return elem.getAttribute(name);}else{if(name=="opacity"&&jQuery.browser.msie){if(value!=undefined){elem.zoom=1;elem.filter=(elem.filter||"").replace(/alpha$[^)]*$/,"")+(parseFloat(value).toString()=="NaN"?"":"alpha(opacity="+value*100+")");}return elem.filter?(parseFloat(elem.filter.match(/opacity=([^)]*)/)[1])/100).toString():"";}name=name.replace(/-([a-z])/ig,function(z,b){return b.toUpperCase();});if(value!=undefined)elem[name]=value;return elem[name];}},trim:function(t){return(t||"").replace(/^\s+|\s+$/g,"");},makeArray:function(a){var r=[];if(typeof a!="array")for(var i=0,al=a.length;i\\s*("+chars+"+)"),quickID=new RegExp("^("+chars+"+)(#)("+chars+"+)"),quickClass=new RegExp("^([#.]?)("+chars+"*)");jQuery.extend({expr:{"":"m[2]=='*'||jQuery.nodeName(a,m[2])","#":"a.getAttribute('id')==m[2]",":":{lt:"im[3]-0",nth:"m[3]-0==i",eq:"m[3]-0==i",first:"i==0",last:"i==r.length-1",even:"i%2==0",odd:"i%2","first-child":"a.parentNode.getElementsByTagName('*')[0]==a","last-child":"jQuery.nth(a.parentNode.lastChild,1,'previousSibling')==a","only-child":"!jQuery.nth(a.parentNode.lastChild,2,'previousSibling')",parent:"a.firstChild",empty:"!a.firstChild",contains:"(a.textContent||a.innerText||jQuery(a).text()||'').indexOf(m[3])>=0",visible:'"hidden"!=a.type&&jQuery.css(a,"display")!="none"&&jQuery.css(a,"visibility")!="hidden"',hidden:'"hidden"==a.type||jQuery.css(a,"display")=="none"||jQuery.css(a,"visibility")=="hidden"',enabled:"!a.disabled",disabled:"a.disabled",checked:"a.checked",selected:"a.selected||jQuery.attr(a,'selected')",text:"'text'==a.type",radio:"'radio'==a.type",checkbox:"'checkbox'==a.type",file:"'file'==a.type",password:"'password'==a.type",submit:"'submit'==a.type",image:"'image'==a.type",reset:"'reset'==a.type",button:'"button"==a.type||jQuery.nodeName(a,"button")',input:"/input|select|textarea|button/i.test(a.nodeName)",has:"jQuery.find(m[3],a).length",header:"/h\\d/i.test(a.nodeName)",animated:"jQuery.grep(jQuery.timers,function(fn){return a==fn.elem;}).length"}},parse:[/^(\[) *@?([\w-]+) *([!*$^~=]*) *('?"?)(.*?)\4 *\]/,/^(:)([\w-]+)$"?'?(.*?(\(.*?$)?[^(]*?)"?'?\)/,new RegExp("^([:.#]*)("+chars+"+)")],multiFilter:function(expr,elems,not){var old,cur=[];while(expr&&expr!=old){old=expr;var f=jQuery.filter(expr,elems,not);expr=f.t.replace(/^\s*,\s*/,"");cur=not?elems=f.r:jQuery.merge(cur,f.r);}return cur;},find:function(t,context){if(typeof t!="string")return[t];if(context&&!context.nodeType)context=null;context=context||document;var ret=[context],done=[],last;while(t&&last!=t){var r=[];last=t;t=jQuery.trim(t);var foundToken=false;var re=quickChild;var m=re.exec(t);if(m){var nodeName=m[1].toUpperCase();for(var i=0;ret[i];i++)for(var c=ret[i].firstChild;c;c=c.nextSibling)if(c.nodeType==1&&(nodeName=="*"||c.nodeName.toUpperCase()==nodeName.toUpperCase()))r.push(c);ret=r;t=t.replace(re,"");if(t.indexOf(" ")==0)continue;foundToken=true;}else{re=/^([>+~])\s*(\w*)/i;if((m=re.exec(t))!=null){r=[];var nodeName=m[2],merge={};m=m[1];for(var j=0,rl=ret.length;j=0;if(!not&&pass||not&&!pass)tmp.push(r[i]);}return tmp;},filter:function(t,r,not){var last;while(t&&t!=last){last=t;var p=jQuery.parse,m;for(var i=0;p[i];i++){m=p[i].exec(t);if(m){t=t.substring(m[0].length);m[2]=m[2].replace(/\\/g,"");break;}}if(!m)break;if(m[1]==":"&&m[2]=="not")r=jQuery.filter(m[3],r,true).r;else if(m[1]==".")r=jQuery.classFilter(r,m[2],not);else if(m[1]=="["){var tmp=[],type=m[3];for(var i=0,rl=r.length;i=0)^not)tmp.push(a);}r=tmp;}else if(m[1]==":"&&m[2]=="nth-child"){var merge={},tmp=[],test=/(\d*)n\+?(\d*)/.exec(m[3]=="even"&&"2n"||m[3]=="odd"&&"2n+1"||!/\D/.test(m[3])&&"n+"+m[3]||m[3]),first=(test[1]||1)-0,last=test[2]-0;for(var i=0,rl=r.length;i<\/script>");var script=document.getElementById("__ie_init");if(script)script.onreadystatechange=function(){if(this.readyState!="complete")return;jQuery.ready();};script=null;}else if(jQuery.browser.safari)jQuery.safariTimer=setInterval(function(){if(document.readyState=="loaded"||document.readyState=="complete"){clearInterval(jQuery.safariTimer);jQuery.safariTimer=null;jQuery.ready();}},10);jQuery.event.add(window,"load",jQuery.ready);}jQuery.fn.extend({load:function(url,params,callback){if(jQuery.isFunction(url))return this.bind("load",url);var off=url.indexOf(" ");if(off>=0){var selector=url.slice(off,url.length);url=url.slice(0,off);}callback=callback||function(){};var type="GET";if(params)if(jQuery.isFunction(params)){callback=params;params=null;}else{params=jQuery.param(params);type="POST";}var self=this;jQuery.ajax({url:url,type:type,data:params,complete:function(res,status){if(status=="success"||status=="notmodified")self.html(selector?jQuery("

").append(res.responseText.replace(//g,"")).find(selector):res.responseText);setTimeout(function(){self.each(callback,[res.responseText,status,res]);},13);}});return this;},serialize:function(){return jQuery.param(this.serializeArray());},serializeArray:function(){return this.map(function(){return jQuery.nodeName(this,"form")?jQuery.makeArray(this.elements):this;}).filter(function(){return this.name&&!this.disabled&&(this.checked||/select|textarea/i.test(this.nodeName)||/text|hidden|password/i.test(this.type));}).map(function(i,elem){var val=jQuery(this).val();return val==null?null:val.constructor==Array?jQuery.map(val,function(val,i){return{name:elem.name,value:val};}):{name:elem.name,value:val};}).get();}});jQuery.each("ajaxStart,ajaxStop,ajaxComplete,ajaxError,ajaxSuccess,ajaxSend".split(","),function(i,o){jQuery.fn[o]=function(f){return this.bind(o,f);};});var jsc=(new Date).getTime();jQuery.extend({get:function(url,data,callback,type){if(jQuery.isFunction(data)){callback=data;data=null;}return jQuery.ajax({type:"GET",url:url,data:data,success:callback,dataType:type});},getScript:function(url,callback){return jQuery.get(url,null,callback,"script");},getJSON:function(url,data,callback){return jQuery.get(url,data,callback,"json");},post:function(url,data,callback,type){if(jQuery.isFunction(data)){callback=data;data={};}return jQuery.ajax({type:"POST",url:url,data:data,success:callback,dataType:type});},ajaxSetup:function(settings){jQuery.extend(jQuery.ajaxSettings,settings);},ajaxSettings:{global:true,type:"GET",timeout:0,contentType:"application/x-www-form-urlencoded",processData:true,async:true,data:null},lastModified:{},ajax:function(s){var jsonp,jsre=/=(\?|%3F)/g,status,data;s=jQuery.extend(true,s,jQuery.extend(true,{},jQuery.ajaxSettings,s));if(s.data&&s.processData&&typeof s.data!="string")s.data=jQuery.param(s.data);if(s.dataType=="jsonp"){if(s.type.toLowerCase()=="get"){if(!s.url.match(jsre))s.url+=(s.url.match(/\?/)?"&":"?")+(s.jsonp||"callback")+"=?";}else if(!s.data||!s.data.match(jsre))s.data=(s.data?s.data+"&":"")+(s.jsonp||"callback")+"=?";s.dataType="json";}if(s.dataType=="json"&&(s.data&&s.data.match(jsre)||s.url.match(jsre))){jsonp="jsonp"+jsc++;if(s.data)s.data=s.data.replace(jsre,"="+jsonp);s.url=s.url.replace(jsre,"="+jsonp);s.dataType="script";window[jsonp]=function(tmp){data=tmp;success();complete();window[jsonp]=undefined;try{delete window[jsonp];}catch(e){}};}if(s.dataType=="script"&&s.cache==null)s.cache=false;if(s.cache===false&&s.type.toLowerCase()=="get")s.url+=(s.url.match(/\?/)?"&":"?")+"_="+(new Date()).getTime();if(s.data&&s.type.toLowerCase()=="get"){s.url+=(s.url.match(/\?/)?"&":"?")+s.data;s.data=null;}if(s.global&&!jQuery.active++)jQuery.event.trigger("ajaxStart");if(!s.url.indexOf("http")&&s.dataType=="script"){var head=document.getElementsByTagName("head")[0];var script=document.createElement("script");script.src=s.url;if(!jsonp&&(s.success||s.complete)){var done=false;script.onload=script.onreadystatechange=function(){if(!done&&(!this.readyState||this.readyState=="loaded"||this.readyState=="complete")){done=true;success();complete();head.removeChild(script);}};}head.appendChild(script);return;}var requestDone=false;var xml=window.ActiveXObject?new ActiveXObject("Microsoft.XMLHTTP"):new XMLHttpRequest();xml.open(s.type,s.url,s.async);if(s.data)xml.setRequestHeader("Content-Type",s.contentType);if(s.ifModified)xml.setRequestHeader("If-Modified-Since",jQuery.lastModified[s.url]||"Thu, 01 Jan 1970 00:00:00 GMT");xml.setRequestHeader("X-Requested-With","XMLHttpRequest");if(s.beforeSend)s.beforeSend(xml);if(s.global)jQuery.event.trigger("ajaxSend",[xml,s]);var onreadystatechange=function(isTimeout){if(!requestDone&&xml&&(xml.readyState==4||isTimeout=="timeout")){requestDone=true;if(ival){clearInterval(ival);ival=null;}status=isTimeout=="timeout"&&"timeout"||!jQuery.httpSuccess(xml)&&"error"||s.ifModified&&jQuery.httpNotModified(xml,s.url)&&"notmodified"||"success";if(status=="success"){try{data=jQuery.httpData(xml,s.dataType);}catch(e){status="parsererror";}}if(status=="success"){var modRes;try{modRes=xml.getResponseHeader("Last-Modified");}catch(e){}if(s.ifModified&&modRes)jQuery.lastModified[s.url]=modRes;if(!jsonp)success();}else +jQuery.handleError(s,xml,status);complete();if(s.async)xml=null;}};if(s.async){var ival=setInterval(onreadystatechange,13);if(s.timeout>0)setTimeout(function(){if(xml){xml.abort();if(!requestDone)onreadystatechange("timeout");}},s.timeout);}try{xml.send(s.data);}catch(e){jQuery.handleError(s,xml,null,e);}if(!s.async)onreadystatechange();return xml;function success(){if(s.success)s.success(data,status);if(s.global)jQuery.event.trigger("ajaxSuccess",[xml,s]);}function complete(){if(s.complete)s.complete(xml,status);if(s.global)jQuery.event.trigger("ajaxComplete",[xml,s]);if(s.global&&!--jQuery.active)jQuery.event.trigger("ajaxStop");}},handleError:function(s,xml,status,e){if(s.error)s.error(xml,status,e);if(s.global)jQuery.event.trigger("ajaxError",[xml,s,e]);},active:0,httpSuccess:function(r){try{return!r.status&&location.protocol=="file:"||(r.status>=200&&r.status<300)||r.status==304||jQuery.browser.safari&&r.status==undefined;}catch(e){}return false;},httpNotModified:function(xml,url){try{var xmlRes=xml.getResponseHeader("Last-Modified");return xml.status==304||xmlRes==jQuery.lastModified[url]||jQuery.browser.safari&&xml.status==undefined;}catch(e){}return false;},httpData:function(r,type){var ct=r.getResponseHeader("content-type");var xml=type=="xml"||!type&&ct&&ct.indexOf("xml")>=0;var data=xml?r.responseXML:r.responseText;if(xml&&data.documentElement.tagName=="parsererror")throw"parsererror";if(type=="script")jQuery.globalEval(data);if(type=="json")data=eval("("+data+")");return data;},param:function(a){var s=[];if(a.constructor==Array||a.jquery)jQuery.each(a,function(){s.push(encodeURIComponent(this.name)+"="+encodeURIComponent(this.value));});else +for(var j in a)if(a[j]&&a[j].constructor==Array)jQuery.each(a[j],function(){s.push(encodeURIComponent(j)+"="+encodeURIComponent(this));});else +s.push(encodeURIComponent(j)+"="+encodeURIComponent(a[j]));return s.join("&").replace(/%20/g,"+");}});jQuery.fn.extend({show:function(speed,callback){return speed?this.animate({height:"show",width:"show",opacity:"show"},speed,callback):this.filter(":hidden").each(function(){this.style.display=this.oldblock?this.oldblock:"";if(jQuery.css(this,"display")=="none")this.style.display="block";}).end();},hide:function(speed,callback){return speed?this.animate({height:"hide",width:"hide",opacity:"hide"},speed,callback):this.filter(":visible").each(function(){this.oldblock=this.oldblock||jQuery.css(this,"display");if(this.oldblock=="none")this.oldblock="block";this.style.display="none";}).end();},_toggle:jQuery.fn.toggle,toggle:function(fn,fn2){return jQuery.isFunction(fn)&&jQuery.isFunction(fn2)?this._toggle(fn,fn2):fn?this.animate({height:"toggle",width:"toggle",opacity:"toggle"},fn,fn2):this.each(function(){jQuery(this)[jQuery(this).is(":hidden")?"show":"hide"]();});},slideDown:function(speed,callback){return this.animate({height:"show"},speed,callback);},slideUp:function(speed,callback){return this.animate({height:"hide"},speed,callback);},slideToggle:function(speed,callback){return this.animate({height:"toggle"},speed,callback);},fadeIn:function(speed,callback){return this.animate({opacity:"show"},speed,callback);},fadeOut:function(speed,callback){return this.animate({opacity:"hide"},speed,callback);},fadeTo:function(speed,to,callback){return this.animate({opacity:to},speed,callback);},animate:function(prop,speed,easing,callback){var opt=jQuery.speed(speed,easing,callback);return this[opt.queue===false?"each":"queue"](function(){opt=jQuery.extend({},opt);var hidden=jQuery(this).is(":hidden"),self=this;for(var p in prop){if(prop[p]=="hide"&&hidden||prop[p]=="show"&&!hidden)return jQuery.isFunction(opt.complete)&&opt.complete.apply(this);if(p=="height"||p=="width"){opt.display=jQuery.css(this,"display");opt.overflow=this.style.overflow;}}if(opt.overflow!=null)this.style.overflow="hidden";opt.curAnim=jQuery.extend({},prop);jQuery.each(prop,function(name,val){var e=new jQuery.fx(self,opt,name);if(/toggle|show|hide/.test(val))e[val=="toggle"?hidden?"show":"hide":val](prop);else{var parts=val.toString().match(/^([+-]=)?([\d+-.]+)(.*)$/),start=e.cur(true)||0;if(parts){var end=parseFloat(parts[2]),unit=parts[3]||"px";if(unit!="px"){self.style[name]=(end||1)+unit;start=((end||1)/e.cur(true))*start;self.style[name]=start+unit;}if(parts[1])end=((parts[1]=="-="?-1:1)*end)+start;e.custom(start,end,unit);}else +e.custom(start,val,"");}});return true;});},queue:function(type,fn){if(jQuery.isFunction(type)){fn=type;type="fx";}if(!type||(typeof type=="string"&&!fn))return queue(this[0],type);return this.each(function(){if(fn.constructor==Array)queue(this,type,fn);else{queue(this,type).push(fn);if(queue(this,type).length==1)fn.apply(this);}});},stop:function(){var timers=jQuery.timers;return this.each(function(){for(var i=0;i-10000?r:parseFloat(jQuery.css(this.elem,this.prop))||0;},custom:function(from,to,unit){this.startTime=(new Date()).getTime();this.start=from;this.end=to;this.unit=unit||this.unit||"px";this.now=this.start;this.pos=this.state=0;this.update();var self=this;function t(){return self.step();}t.elem=this.elem;jQuery.timers.push(t);if(jQuery.timers.length==1){var timer=setInterval(function(){var timers=jQuery.timers;for(var i=0;ithis.options.duration+this.startTime){this.now=this.end;this.pos=this.state=1;this.update();this.options.curAnim[this.prop]=true;var done=true;for(var i in this.options.curAnim)if(this.options.curAnim[i]!==true)done=false;if(done){if(this.options.display!=null){this.elem.style.overflow=this.options.overflow;this.elem.style.display=this.options.display;if(jQuery.css(this.elem,"display")=="none")this.elem.style.display="block";}if(this.options.hide)this.elem.style.display="none";if(this.options.hide||this.options.show)for(var p in this.options.curAnim)jQuery.attr(this.elem.style,p,this.options.orig[p]);}if(done&&jQuery.isFunction(this.options.complete))this.options.complete.apply(this.elem);return false;}else{var n=t-this.startTime;this.state=n/this.options.duration;this.pos=jQuery.easing[this.options.easing||(jQuery.easing.swing?"swing":"linear")](this.state,n,0,1,this.options.duration);this.now=this.start+((this.end-this.start)*this.pos);this.update();}return true;}};jQuery.fx.step={scrollLeft:function(fx){fx.elem.scrollLeft=fx.now;},scrollTop:function(fx){fx.elem.scrollTop=fx.now;},opacity:function(fx){jQuery.attr(fx.elem.style,"opacity",fx.now);},_default:function(fx){fx.elem.style[fx.prop]=fx.now+fx.unit;}};jQuery.fn.offset=function(){var left=0,top=0,elem=this[0],results;if(elem)with(jQuery.browser){var absolute=jQuery.css(elem,"position")=="absolute",parent=elem.parentNode,offsetParent=elem.offsetParent,doc=elem.ownerDocument,safari2=safari&&parseInt(version)<522;if(elem.getBoundingClientRect){box=elem.getBoundingClientRect();add(box.left+Math.max(doc.documentElement.scrollLeft,doc.body.scrollLeft),box.top+Math.max(doc.documentElement.scrollTop,doc.body.scrollTop));if(msie){var border=jQuery("html").css("borderWidth");border=(border=="medium"||jQuery.boxModel&&parseInt(version)>=7)&&2||border;add(-border,-border);}}else{add(elem.offsetLeft,elem.offsetTop);while(offsetParent){add(offsetParent.offsetLeft,offsetParent.offsetTop);if(mozilla&&/^t[d|h]$/i.test(parent.tagName)||!safari2)border(offsetParent);if(safari2&&!absolute&&jQuery.css(offsetParent,"position")=="absolute")absolute=true;offsetParent=offsetParent.offsetParent;}while(parent.tagName&&!/^body|html$/i.test(parent.tagName)){if(!/^inline|table-row.*$/i.test(jQuery.css(parent,"display")))add(-parent.scrollLeft,-parent.scrollTop);if(mozilla&&jQuery.css(parent,"overflow")!="visible")border(parent);parent=parent.parentNode;}if(safari2&&absolute)add(-doc.body.offsetLeft,-doc.body.offsetTop);}results={top:top,left:left};}return results;function border(elem){add(jQuery.css(elem,"borderLeftWidth"),jQuery.css(elem,"borderTopWidth"));}function add(l,t){left+=parseInt(l)||0;top+=parseInt(t)||0;}};})(); \ No newline at end of file diff -r eca3a16c0114 -r 4d4e9bea4359 stylesheets/it/fo.xsl --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/stylesheets/it/fo.xsl Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,10 @@ + + + + + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 stylesheets/it/html-single.xsl --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/stylesheets/it/html-single.xsl Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + + + + + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 stylesheets/it/html.xsl --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/stylesheets/it/html.xsl Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,8 @@ + + + + + + + + diff -r eca3a16c0114 -r 4d4e9bea4359 stylesheets/it/web.xsl --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/stylesheets/it/web.xsl Sun Aug 16 19:09:42 2009 +0200 @@ -0,0 +1,39 @@ + + + + + + + + styles.css + + + + + + + + + + + +

Mercurial: la guida definitiva di Bryan O'Sullivan

+ + + +

Volete rimanere aggiornati? Abbonatevi al feed delle modifiche per questo capitolo o per l'intero libro.

+ + + + + + +

Mercurial: la guida definitivadi Bryan O'Sullivan

Mercurial: la guida definitiva di Bryan O'Sullivan

Mercurial: la guida definitiva
di Bryan O'Sullivan