Among a lot of other things you can add names for remote repositories to your mercurial.ini so you can access them without having to type that long path. This can be quite convenient e.g.

[path]
dzlib=ssh://twm@hg.code.sf.net/p/dzlib/hgdzmaincode


allows me to clone a copy of my dzlib+tools main repository on sourceforge like this:

hg clone dzlib dzlib+tools


rather than having to type:

hg clone ssh://twm@hg.code.sf.net/p/dzlib/hgdzmaincode dzlib+tools


Unfortunately this also tends to add the possibility for undesired side effects. Consider this:

hg clone dzlib dzlib


What is it supposed to do? What I wanted it to do, is simple: Clone the remote repository dzlib (as configured in the [path] section) to the subdirectory dzlib.
What it actually tries to do is: Clone the remote repository dzlib to the remote repository dzlib, which is definitely not what I wanted it to do.

Since I rarely create new clones from the remote repository I have removed the entries in [path] again, because the time potentially spent on troubleshooting these side effects is much longer than having to look up the remote url the few times I actually want to clone a remote repository.

As described in a previous post I initially had some problems connecting to Mercurial repositories on SourceForge that went away without me changing anything. In that post I give the following entry for mercurial.ini:

[ui]
ssh="C:\Program Files (x86)\PuTTY\plink.exe" -ssh -agent -v -i "D:\path\to\my\private_key.ppk"


While this works well, if Pageant is already running and has loaded the key, it results in a non responsive console if either of these conditions is missing. This is quite annoying because I tend to forget to start Pageant and it takes me quite a while to realize what the problem is. A little bit of digging into the command line parameters of plink gave me the fix: Add the -batch switch, so it won’t accept any interactive prompts. So it should look like this:

[ui]
ssh="C:\Program Files (x86)\PuTTY\plink.exe" -ssh -batch -agent -v -i "D:\path\to\my\private_key.ppk"


If Pageant is not running or the private key not loaded, any connection attempt will within seconds result in the following error message:

hg incoming
abort: no suitable response from remote hg!


In my previous post about converting from Subversion to Mercurial I assumed that I would want to migrate the history of changes from my svn repository to the new hg repository.

For some projects, I don’t really care about the history so I decided to take the quick and dirty route:

• Create a new, empty master hg repository (on a server)
• Clone that hg repository to a local directory
• Check out the project from svn to the same local directory
• Add a new .hgignore file to ignore the .svn subdirectory
• Add the .hg subdirectory to the svn:ignore property
• Add .hgignore to svn and commit that change
• Add everything to hg, commit and push that change

That’s it. Now you have got a directory that contains your sources and they are managed with both, Subversion and Mercurial. Now, get into the habit of committing changes to both as long as you want. Once you are comfortable with Mercurial, just stop using Subversion. You might want to delete the .svn subdirectory at that point.

I was just about to post the following to stackexchange.com:

I have got a mercurial repository on sourceforge.net, generated an ssh key with PuttyGen and uploaded it to Shell Services Configuration as described in the relevant site documentation. I then started Pageant and entered my passphrase.

Now, I can connect to shell.sourceforge.net without entering a password and create a session there that works fine. So, the key has been generated correctly and uploading the public key also worked fine.

As I understand it, I should now also be able to use the command

hg pull


on a sourceforge repository without the need to enter my password. I therefore added the following line to my mercurial.ini file, in the ui section:

ssh="C:\Program Files (x86)\PuTTY\plink.exe" -ssh -agent -v -i "D:\path\to\my\private_key.ppk"


Unfortunately any hg command that requires a connection to the sourceforge repository times out. If I remove that line again, everything works fine, but I have to enter my password.

hg --debug pull


emits the following lines:

And then I tried it again to get the error messages for posting into the question. Guess what? This time it worked. I swear, I didn’t do anything different than before and I haven’t changed anything. All previous attempts failed with the error “Server refused our key”. So I guess sourceforge changed something. Maybe it was a case of synchronizing the public key to all servers taking forever (several days) or maybe they came around to reading my support request and doing something about it.

Don’t you hate it when things start working without you knowing what caused it to fail in the first place? I certainly do!

Here, I will be posting notes on converting Subversion repositories to Mercurial.

NOTE: This is work in progress. I will probably come back and change things as well as adding.

Hg Init: a Mercurial tutorial by Joel Spolsky
QuickStart in the Mercurial Wiki

I have got TortoiseSVN 1.8.3 including the command line clients and TortoiseHG 2.10.1 installed.

There are several short tutorials on converting from svn to hg. They all suggest that you first create a local copy of your subversion repository to work on.

A – Create a local copy of your subversion repository
Creating this local copy can easily be done as described by Massimo Iacolare, which I used as a guide.

1 – Create a local svn repository
You can use any local directory as the path to your local svn repository, I will be using the extension .svn to remind me that it is a svn repository. The converted Mercurial repository will not get an extension.

Unfortunately there is the first gotcha: Massimo seemed to be using an older version of svn that used db format 4. The current svn 1.8 uses db format 6 by default, and as Jeroen W. Pluimers found out, the current Mercurial does not support it yet. So, what can we do until the Mercurial developers fix this problem? Why, use db format 4, of course:

svnadmin create --compatible-version 1.7 [path\to\your\new\repository.svn]

I am not sure whether the steps 2 to 4 are necessary, it seemed to work fine without them. I’ll keep them here just in case I run into trouble later because I left them out.

2 – Enable writing on your new repository
Open the file [path\to\your\new\repository.svn]\conf\svnserve.conf and uncomment the line

[general]
password-db = passwd

This tells SVN which file stores the user credentials.

3 – Add a new user
Open the file [path\to\your\new\repository.svn]\conf\passwd and add a new user:

[users]
svnsync_user = svnsync

Open the file [path\to\your\new\repository.svn]\conf\authz and add:

[/]
svnsync_user = rw

5 – Enable rev propchange (revision property change)
create a text file pre-revprop-change.bat in [path\to\your\new\repository.svn]\hooks containing:

exit 0

This can be done easily with

echo exit 0 > [path\to\your\new\repository.svn]\hooks\pre-revprop-change.bat

6 – Initialize the repository

svnsync init file:///[path/to/your/new/repository.svn] [REMOTE PATH]

Getting the local repository path right can be tricky. Pay close attention to the number of slashes and use forward slashes. e.g.

svnsync init file:///c:/some/path/here.svn https://svn.somesvnserver.com/svn/repository

7 – Synchronize
Once the repository is initialized, you can synchronize it as often as you like:

svnsync sync file:///[path/to/your/new/repository.svn]

Be aware, if your repository is big, the first synchronization may take very long.
After the synchronization has been done once, you can keep it in sync by just repeating step 7.

B – convert your local Subversion repository to a Mercurial repository

This is a one step action:

hg convert [path/to/your/new/repository.svn] [path/to/your/hg/repository]

If you omit the second parameter, hg convert will assume [path/to/your/new/repository.svn-hg] which is probably not what you want, but you can easily rename the directory later on.

The above converts the whole svn repository, including any branches to a single Mercurial repository, as this command shows:

hg branches -a

(You must execute it inside the repository.)
This will also list the pseudo branch “default” which corresponds to the “trunk” in svn.

You can also specify any path within the svn repository to convert, e.g. only the trunk:

hg convert file:///[path/to/your/new/repository.svn]/trunk [path/to/your/hg/repository]

Alternatively, you can convert the whole repository and clone it for every branch to a new Mercurial repository, like this:

hg clone -r [branchname] [path/to/your/hg/repository] [path/to/your/hg/branch]

Due to different concepts of users in svn and Mercurial (one uses names, the other uses email adresses), you can provide a mapping file for users to emails. It must contain one line per user like this:

arist = Aristotle <aristotle@phil.example.gr>
soc = Socrates <socrates@phil.example.gr>

(This example is taken from Mercurial: The Definitive Guideby Bryan O’Sullivan)
And you pass it to the conversion with the –authors option.