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 --config convert.hg.usebranchnames=false 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.

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 --authors al comando hg convert. Questa opzione accetta un nome di file che dovrebbe contenere voci nel seguente formato.

arist = Aristotele <[email protected]>
soc = Socrate <[email protected]>

Ogni volta che convert incontra un commit associato al nome utente arist nel repository sorgente, userà il nome Aristotele <[email protected]> nella revisione convertita in Mercurial. Se non viene trovata alcuna corrispondenza per un certo nome, quel nome viene usato alla lettera.

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 --filemap 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 state esplicitamente incluse. 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.

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.

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.