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:
- Install mercurial (TortoiseHg)
- Clone hgsubversion
- Configure hgsubversion extension
- Start cloning svn repos!
- Understand the gotchas
- Stay happy
1. 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!).
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.
3. 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= #do not quote the path if it has spaces! 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
Instead of cloning repos with “hg clone” I suggest to “hg pull” instead. Pull is better because it can continue in case something breaks (cloning very large repo can takes hours).
hg init example cd example hg pull http://example-for-hgsubversion.googlecode.com/svn example-for-hgsubversion
- 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. If links to binaries are dead then get creative and google for it – I don’t guarantee all links will work forever.
6. Stay happy. Are you kidding me? You know what to do =)
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.
Could you please provide more detail on this step? What do you mean by svn+http(s) ?
I believe he means this:
1) In your root folder open .hg/hgrc
2) Make sure that default = is set to a URL with svn+ prepended, EG default = svn+https://www.foo.corp/svn/source
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
@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 =)
@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.
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
finally tried this, seems to be working but the clone is really slow :(
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 =)
i am new to hg as well but is there a way to clone the repo and only get the latest N versions?
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.
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).
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.
Chcemy wiecej :D
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!
I am using TortoiseHg 0.9 by the way.
I think you’re right! I will test it with the latest TortoiseHg and update this post. Thanks a lot for the hint!
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.
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 =)
When importing a big repository you’ll likely run out of memory during the initial clone.
The workaround is simply to stop the process before it does and to go on with hg pull.
See http://bitbucket.org/durin42/hgsubversion/issue/110/memory-leak
I’ve tried Bazaar-svn in the meantime, it is nice and really ahead of hg-svn.
But I stick to hg-svn because Bazaar-svn is way too slow on big repositories with lots of revisions.
Also the hg “repository explorer” is much better than the Bazaar Explorer. Actually the later is easier to use for everyday tasks, but lacks the advanced functionalities of hg explorer: shelve, mq, bissect.
Tortoise hg’s commit dialog is also better: it has the diffs right there in a panel; that’s handy when you have lots of modified files with just a few lines changed.
Overall, everything is faster in hg.
But Bazaar has some nice stuff not in hg: directories are versioned, svn is integrated, multiple shelves are possible (like hg attic) and more.
I had pretty much the same experience. bazaar-svn / hg-svn both have pros & cons but eventually I’m using hg-svn, even though bazaar has some reasonable advantages.
I have some advice,
Since it is impossible to do: “1. Install svn command line client and put it on path. I downloaded, unzipped and PATH’ed svn 1.6.5.”, since the link to subversion is dead and Tigris refuses to provide their own windows command-line binary and the 4 that that do list, no of them work for the purposes of this tutorial, you should change step 1 to read: “1. Forget about it. It’s now impossible. I’m sorry for getting your hopes up. Install cygwin and pretend you have UNIX and just follow the Linux Instructions.”
That’s my advice.
Just install TortoiseHg and skip installing SVN command-line-interface & Python if you want to quickly use hgsubversion.
unless you really need the SVN CLI or Python binaries for some reasons.
If I do that, when I run hg help extensions, I get “*** failed to import extension svn from “*SomeFantatsicFolder*\hgsubversion”: [Errno 22] Invalid argument”
Seems to me with this error, python’s svn bindings are required but I have no idea how to add them.
What about:
1) ensure the path you enter in the mercurial.ini is the one having __init__.py inside (it’ll probably be something like “C:\opt\hg\hgsubversion\hgsubversion” note the double hgsubversion)
2) clean up the environment path with `set PATH=C:\Program Files\TortoiseHg`
Python runtime, svn-python bindings&libraries are already inside TortoiseHg’s folder
I use the root path with the __init__.py module in it; I even forced the path to include TortoiseHg and only TortoiseHG. I still get that error. It’s not a case of not following the instructions; this is a fresh PC; only bought it Sunday. The problem is everyone here has done some implicit step on a mature machine that I have not done because this machine is new. When Mercurial fires up python to run HgSubversion, it tries to import svn and this fails because it can not find that module. That is the issue.
Oh, and haven’t already mentioned that you *can’t* install the python bindings in Mercurial *any more* because the Subversion folks have taken down the page where they used to make these available. You probobaly got those when they were, but now they’re not, namely here:
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91
I don’t know what the problem is :/ You can get more help on hgsubversion mailing list
You _do not_ need python bindings for svn and you _do not_ need svn command line.
They already come within TortoiseHg.
No, I did _not_ download python bindings. I also changed to a new PC recently (the last few months) and I only need TortoiseHg for Windows + hgsubversion clone + do some config.
Okay, let’s try this; which version of TortiseHg are you guys using? I installed 1.1.3 (x86); I did not install a command line or any other version and I did manually set the path and this didn’t work. So, could the issue be that the latest Hg removed the subversion bindings and this is why it works for you guys but not for me?
Also, because I used clone, my HgSubversion is the latest as of 2 days ago (haven’t pulled since download). Should I revert to an earlier version?
Okay, forget TortiseHg for now; I can confirm it has the python-svn bindings against svn version 1.6.6, a fairly recent revision. Why, when it tries to initialize HgSubversion it fails to import svn is beyond me. It should be running in the context of the python shell defined for Mercurial but fails in the way I described. Seems that only 2 steps are required in theory since you don’t need a stand-alone python any more than you do SVN, but since I’m a python hacker since before 1.5, I like having it around. I just wish I could start an interpreter in the Hg Context or at least have it print out more well defined debug and traceback messages.
It seems like you want to hack on mercurial/tortoisehg/hgsubversion.
In that case, please refer to their wiki/mailing lists.
Ah, if only. Well, sir, what I really want is these thing to work out of the box; but in this world, that’s too much to ask. So I have no choice but to debug my butt off and work on 3 hours sleep because I need this to work. Hours and hours spent; how do you think that makes me feel, especially to be taunted. But whatever, when and if I can find a solution I will post it here so that no-one ever again has to suffer like me.
And here it is:
Add the following to step 3:
If your path contains spaces, don’t worry, the .hgrc can handle that. Do not enclose your path in quotes; this will cause the module to fail to load. Just write your path exactly as:
svn=*SomeFantasticFolder*/hgsubversion
The hint should have been that the error message had the path in quotes, when the error generated does not quote the path, however I doubt anyone would notice that subtlely. Usually paths that contain spaces have to be quoted or escaped, so intuition would suggest quotes are necessary so I believe the instructions should make this point clear.
It was clearly written that installing-svn step was not necessary. I removed it now so that there is no confusion. Therefore cygwin is not really necessary (thanks god!)
If you still have problems installing – read *carefully* Afriza’s comments or read *carefully* the steps again :) Understanding basics of mercurial plugins is also helpful – refer to mercurial wiki.
I mean, the python runtime + svn-library + svn python bindings are already bundled within TortoiseHg installer.
* svn command line interface is not bundled though
You might want to take a peak at the »subversion« help topic. It should mention the many caveats and gotchas of working with hgsubversion…
Oops, I didn’t notice how old this blog post actually was; sorry ’bout that…