Update: excellent tip from Eric Larson.
I’m a long-time CVS head, and I recognize CVS is quite showing is age, but I’ve never had much of a taste for the pundit’s heir apparent Subversion. I could go on about why, but I think it all boils down to SVN’s not fitting my head. I’ve been thinking of VCS and hosting options for my FOSS projects, and have discussed some of this in the community. I’m leaning heavily towards Mercurial (with Bazaar a close second). I decided to set up Hg on my MacBookPro so that I can play with it, and so that I can see if I can start doing local work on my machine in Hg and then push to a centralized SVN repo as a bit of insulation from SVN. Herein a few notes on the matter.
I installed Hg 0.9.4 plus latest patches for Mac. I’d already installed MacPython 2.5, so it all seemed to work once I went through the installer, and the hg command was available without further ado.
There are three main scenarios for my Hg work:
* Working exclusively on Hg for my Bright Content Weblog project, presently in SVN (on Google code hosting)
* Working exclusively on Hg for the 2.x branch of the Amara XML Toolkit project, presently (1.x branch) in CVS
* Working locally in Hg with a repository (my employer’s) managed centrally in SVN
For the first scenario I followed the migration instructions from SVN. I didn’t feel like dealing with all the fiddling that seems necessary for svnsync, so I decided to work directly from the remote repository. Unfortunately, after a lot of wrestling with “hg convert:” I just couldn’t get it to work. I kept getting:
$ hg convert http://brightcontent.googlecode.com/svn/trunk/ brightcontent
destination brightcontent is a Mercurial repository
subversion python bindings could not be loaded
scanning source...
abort: 'http://brightcontent.googlecode.com/svn/' does not appear to be an hg repository!
I also tried https, and after logging in, got the same error. I gather that “hg convet” really wants to work with a local repository, and I don’t have the time to give it that, so I may have to defer until they improve it.
Note: yes, I did install pysvn and I even chased down the hg command to check the instance of Python it uses and confirm that instance can import pysvn.
I’ll get around to thge second scenario later, but for the third I gave hgsvn (easy_install hgsvn) a go. It seemed to work, but I learned that I can’t easily push changes back to the central SVN, so I may have to wait until a “hgpushsvn” command emerges.
It looks like my best bet for working with Hg right now is the second scenario, which is a bit more of a clean start (Amara’s 2.x branch is a full rewrite). I’ll give that a go and post my notes and progress here.
Update: Eric Larson pointed out to me that I could use hgsvn rather than hg convert. On my MacBookPro I did:
hgimportsvn http://brightcontent.googlecode.com/svn/trunk/ bc-hgtrunk
cd bc-hgtrunk
hgpullsvn
Then on cvs.4suite.org:
mkdir /var/local/hg/brightcontent
cd /var/local/hg/brightcontent
hg init
Then back on my laptop:
hg push ssh://$REMOTEUSER@cvs.4suite.org//var/local/hg/brightcontent
Notice the double-slash after the host name. This one tripped me up. If you use a single slash the rest is relative to the home directory.
Anyway, now I have a hub repository that I’ll use in a partially decentralized manner for Bright Content. And I’ll start adjusting my mindset to the DVCS way.


One thing to consider as well is to simply use the ignore files to keep the mercurial/svn details hidden from each other and just commit to the respective system when doing granular commits. When you are just working on it, then work on it in mercurial and when you are ready to commit for the actual release, svn commit.
I have done this with CVS and it is pretty easy, but YMMV of course.
I worked on porting trac + svn to a NAS linux platform once. As I understand, there're at least two separate python extensions for svn. One comes with subversion and is based on SWIG, "import svn"; the other usually called pysvn, "import pysvn". Which one does "hg convert" need?
I think the one thing that would put bzr over the top is if they gave their docs a little more attention. I've just started with bzr, and I like it, but I keep finding details missing from the docs.
FWIW, pysvn is not the same thing as the subversion python bindings. The bindings (generated with SWIG) should be distributed with subversion.
pysvn is an unrelated high level interface.
Thanks for the post, it contained the little bit of information I was missing about installing hgsvn on my MacBook Pro. My SVN repository is importing as I type.
Thanks again,
Ivan