So far I have used the following method in migrating existing local Subversion repositories to Mercurial. While doing it, I have placed them at BitBucket, since they offer free, unlimited private repositories for both Mercurial and Git.
The reason for not using Git (or GitHub or Gitorious for that matter) is that I needed to extend my understanding of daily/weekly use of different Version Control Systems to include Mercurial.
All the example commands used in the page are based on the latest versions of Subversion and Mercurial in Windows OS. Command line tools are included in both tortoises listed below, but in the case of TortoiseSVN, they needed to be selected specifically while installing.
- TortoiseHg 2.8.2 (10th July 2013). includes Mercurial 2.6.3
- TortoiseSVN 1.8.1 (23rd July 2013), includes Subversion 1.8.1
Once both of the installed, start up the command prompt and check the versions. For Mercurial:
hg --version
Excepted to see something like:
Mercurial Distributed SCM (version 2.6.3)
Same for Subversion:
svn --version
Expected to see something starting like:
svn, version 1.8.1 (r1503906)
compiled Jul 22 2013, 19:58:17 on x86-microsoft-windows
Before starting the conversion operation, the Mercurial plugin for it needs to be enabled.
This can be achieved by adding the following to the (possibly not yet existing)
file mercurial.ini
in the current users home folder
[extensions]
convert=
It will enable to run hg convert
which will take few options, however
not limited to these:
-s
, type of the source repository-d
, the type of the target repository hg--authormap
, file listing the authors of Subversion and how to map them in Mercurial--filemap
, list files that are excluded, renamed or need some other special handling
The command in the case of my conversion is shown later in this page. More information of the specifics and of other options are available at the Mercurial Convert plugin web site.
Since the metadata format was upgraded in 1.8 to revision 31 and 1.7 was using revision 29, it might be the case that the checkout copy in which the authors list is being collected, needs to be upgraded. This can be done by simply calling
svn upgrade
Also, if the you have direct access to the Subversion repository, as the case would be in the locally hosted, run the following command to check the integrity of that repository:
svnadmin verify D:\Repository\MugennoBudo
List of authors can be fetched to a file, each author to their own line.
svn log --quiet D:\Repository\MugennoBudo | \
grep '^r' | awk '{print $3}' | sort | \
uniq > mugenno_authors.txt
In my case it contained the following names, which were the Windows user at the time:
Juga
paazio
Wugi
Below is the contents of the file after the authors have been mapped to the people I wish them to be in the Mercurial.
Juga=Juga Paazmaya <olavic@gmail.com>
paazio=Hjalmar Joonas Valkoviiksi <paazio@users.sf.net>
Wugi=Juga Paazmaya <olavic@gmail.com>
In case there are any files in the Subversion repository that should not be included in the resulting Mercurial repository, the file mapping feature of the convert plugin can be used.
Now the hard part of the task, the actual conversion.
hg convert -s svn -d hg \
--authormap mugenno_authors.txt \
file:///D:/Repository/MugennoBudo \
file:///D:/paazmaya-bitbucket/mugenno-budo \
> mugenno_conversion.log
Conversion log will contain something similar to (most of the commits omitted):
initializing destination file:///D:/paazmaya-bitbucket/mugenno-budo repository
scanning source...
sorting...
converting...
66 Import from elsewhere.
65 Rei and Seiza.
...
1 Move to Office 2010 since I have it officially
0 ?
writing author map file D:\paazmaya-bitbucket\mugenno-budo\.hg\authormap
Check that the history of this just created Mercurial repository looks good.
hg log > mugenno.hg.log
svn log > mugenno.svn.log
Use hg update to get the files of the latest commit to fill in the new repository.
Finally push the new Mercurial repository to the server if everything looks good.
hg push https://paazmaya@bitbucket.org/paazmaya/mugenno-budo
In case you feel that the push gets stuck, run the previous command with --debug
to
see what is going on. Since it is pushing the whole repository up to the
server for the first time, it will take quite a bit of time. Be patient.