hgsubversion on windows

Who likes mercurial? I do. Lately, I even started using mercurial as a client for subversion repositories. Let me describe the hgsubversion installation steps that worked for me; on my laptop that is boldly supplied with The Only Right operation system…

I heavily borrow from excellent entry by Ben Collins-Sussman and from outrageously diligent post by Dave Cameron. I want to focus on the smallest possible installation routine on windows. Also, I want to emphasize that you don’t have to build anything on windows. All the prepackaged installables or binaries are ready, waiting for you to grab them.

Oh right, here are the steps that worked for me:

  1. Install svn
  2. Install mercurial (TortoiseHg)
  3. Clone hgsubversion
  4. Configure hgsubversion extension
  5. Start cloning svn repos!
  6. Understand the gotchas
  7. Stay happy

1. Install svn command line client and put it on path. I downloaded, unzipped and PATH’ed svn 1.6.5.
Your cmd should react nicely to: svn help (Update 08-12-2009, according to feedback and my quicky tests this step might not be necessary).

2. Install mercurial (TortoiseHg). I installed TortoiseHg (mercurial + tortoise). Your cmd should nicely take: hg version.

In theory you can install different Mercurial client. However, there is a huge advantage of installing TortoiseHg: you don’t have to install python, svn python bindings & make your Mercurial use it. All because TortoiseHg comes with python+svn bindings (thanks Afriza for a hint!).

3. Clone hgsubversion:

hg clone http://bitbucket.org/durin42/hgsubversion SomeFantasticFolder

In my case SomeFantasticFolder is c:\projects\open-source\hgsubversion. At the moment I cloned hgsubversion the tip was the changeset 500.

4. Configure hgsubversion extension. Add extensions to your USER_HOME/.hgrc, which on windows is Documents and Settings\SomeFabulousName. In my case SomeFabulousName is sg0897xxx (after years in IT industry I’m still just a number…). Note that hgsubversion is duplicated at the end – that’s fine. Your .hgrc should contain something like:

[extensions]
rebase=
svn=c:\projects\open-source\hgsubversion\hgsubversion

Your cmd should print enabled extensions at the bottom of the screen when you do: hg help extensions

5. Start cloning svn repos! For example:

hg clone http://example-for-hgsubversion.googlecode.com/svn example-for-hgsubversion

6. Understand the gotchas.

  • gotcha 1. If svn requires authentication, you may be asked to enter user/password… 3 times. Don’t worry, just enter correct credentials patiently. Three shall be the number thou shalt count, and the number of the counting shall be three. (update) Augie Fackler, the mastermind of hgsubversion points out svn+http or svn+https can be used to work around this gotcha
  • gotcha 2: After updating changes from svn (hg pull, hg update) never use ‘hg merge’, instead use ‘hg rebase’. Merges are not yet supported by hgsubversion I heard. If you accidentally do hg merge you probably have to rollback the merge in order to push.
  • gotcha 3: (new) From my experience it is better to clone entire repo, not only trunk. Cloning trunk worked for me but I noticed exceptions thrown during unsuccessful rebase. Working with full repo clone was smooth for me so far.
  • gotcha 4: (new) Commands you should know: 
    hg help svn
hg rebase --svn
hg svn info
hg svn rebuildmeta
  • last gotcha: I’m not a mercurial expert so feel free to comment & give feedback. Also, newer (different) versions of before mentioned installables should work as well.

7. Stay happy. Are you kidding me? You know what to do =)

This entry was posted on Wednesday, November 4th, 2009 at 6:40 pm and is filed under coding, mercurial, svn. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

17 Responses to “hgsubversion on windows”

  1. Augie Fackler Says:
    November 4, 2009 at 9:57 pm | Reply

    Regarding gotcha #1, you can use svn+http or svn+https to avoid the multiple-authentication problem. Not elegant, but the best we’ve come up with so far.

  2. Przemek Bielicki Says:
    November 5, 2009 at 7:25 am | Reply

    Hi,

    everything looks just fine for me but I think you missed one tiny important thing in this post, namely answering the question “Why?”.

    Why the “Rydzyk” should I use mercurial instead of my Eclipse SVN client (or TortoiseSVN). Why the hell should I clone my repositories? Any reasonable explanations/use cases for this?

    Thanks,
    Przemek

  3. szczepiq Says:
    November 5, 2009 at 8:12 am | Reply

    @Augie

    Thanks for info – I will update the gotcha #1

    @Przemek

    Haha, good point. What can I say? I guess there is an important prerequisite to the hgsubversion installation guide: liking Mercurial & preferring distributed SCM =)

  4. Phil Says:
    November 12, 2009 at 9:06 am | Reply

    @Przemek

    Several reasons:

    1) Using SVN as your “blessed” repo.
    2) Allowing some team members to use DVCS if they are comfortable with the concepts whilst others can still use SVN clients.
    3) To allow you to work in a disconnected environment (logs, diffs with previous versions, rollbacks are now all possible if, say, travelling by plane with no internet connection).
    4) Investigating if DVCS is really for you without potentially losing some revision history whilst you try it out.
    5) Allowing existing automated processes (e.g. a build/deployment system that pulls from SVN) to continue working as is whilst everyone else moves to DVCS.
    6) If you’re stuck on a version of SVN < 1.5 to allow easy branching and merging without having to pull your hair out. Even if you have SVN 1.5/1.6 it's still easier in mercurial than in SVN IMHO.

  5. Przemek Bielicki Says:
    November 13, 2009 at 7:54 am | Reply

    Hi Guys,

    thanks for your responses.

    That makes sense – and I think I even use some of these concepts i.e. I’m having my own SVN repo installed on my laptop and I suppose that here the idea is to merge my local changes with some distributed SCM from time to time so that others can see my changes. In the same time I don’t need any network because I have my own SVN.

    I have to take a look a Mercurial then :)

    Thanks!
    Przemek

  6. wes Says:
    November 17, 2009 at 7:59 am | Reply

    finally tried this, seems to be working but the clone is really slow :(

  7. szczepiq Says:
    November 17, 2009 at 8:06 am | Reply

    Right, the clone is slow. It took ~1 hour for Mockito that is fairly small repo. I’ll add a gotcha about it.

    Extenuating circumstance: you do it only once =)

  8. wes Says:
    November 17, 2009 at 8:42 am | Reply

    i am new to hg as well but is there a way to clone the repo and only get the latest N versions?

  9. Phil Says:
    November 17, 2009 at 8:49 am | Reply

    Hi wes, that’s currently not possible but is on their roadmap for the future. A possible way to do it would be a mercurial->mercurial conversion on a selected commit range.

  10. Phil Says:
    November 17, 2009 at 9:46 am | Reply

    Cloning SVN repos is indeed fairly slow. The convert extension is slightly faster, especially if you are running it on a local SVN repository via the file:/// uri scheme, but over a network you are relying on webdav which is very, very slow (which, by extension, makes Subversion slow).

  11. wes Says:
    November 17, 2009 at 9:56 am | Reply

    thanks Phil, I was using a different way of using hg where I had a local hg repo that I pushed to and then only a final version was pushed to svn. this was much faster but only the latest version goes to svn so not as good. i will deal with speed since it is only on the initial clone.

  12. zajefajnyx Says:
    November 23, 2009 at 6:29 pm | Reply

    Chcemy wiecej :D

  13. Afriza N. Arief Says:
    November 25, 2009 at 8:01 am | Reply

    Hi,

    I followed the instructions partially and installed SilkSvn (added to path), and Python2.5.4 (not added to path). I didn’t install python binding when i realized there are several libsvn* files inside my “C:\program files\tortoisehg\library.zip”. I continued from the step about hgsubversion and everything seems to work fine!

  14. Afriza N. Arief Says:
    November 25, 2009 at 8:02 am | Reply

    I am using TortoiseHg 0.9 by the way.

  15. szczepiq Says:
    November 25, 2009 at 11:01 am | Reply

    I think you’re right! I will test it with the latest TortoiseHg and update this post. Thanks a lot for the hint!

  16. padcom13 Says:
    January 8, 2010 at 1:09 am | Reply

    If speed is not the issue here (as mentioned a number of times already in the comments above) you might also give Bazaar a try. It comes with a built-in capability to work with Subversion repositories so the installation part is not an issue anymore.
    Additionally Bazaar is one step ahead of Mercurial as it allows you to work in a distributed or centralized fashion at will. What you do is you can “bind” your local branch to the Subversion server and use Bazaar as a regular Subversion client (centralized-way) or unbind the branch and have it like in Mercurial (distributed-way).
    I use Bazaar for everyday work as a replacement for Subversion client and it has been extremely stable so far.

  17. szczepiq Says:
    January 8, 2010 at 5:24 am | Reply

    Actually, I used bazaar-svn before hgsubversion. Although bazaar integration with svn is better than hgsubversion, I kind of didn’t like working with bazaar itself. However, I encourage to try out bazaar-svn and use whatever fits you well =)

Leave a Reply