How do I export changesets from hg repository to svn repository

Question

I know there is hgsubversion extension for mercurial. But before I knew how it works, I maintain two separate repositories, one is SVN repo and one is Hg repo. I made most of my recent changes in the Hg repository and I need to "push" them to the svn repository.

The most straight forward way to do this is to get one revision from svn which is in sync with one revision from hg.

From there, I update to the next revision (from Hg), then commit it (to svn). Repeating these steps for many changesets is rather inconvenient. Are there more convenient ways to do this?

And if possible, solution that works in Windows OS.

Regards,

Afriza

Answer 1

If you're talking about a linear series of changesets (no merges) you could employ a shell for loop

for therev in $(seq $(hg id -n -r .) $(hg id -n -r tip)) ; do
  hg update $therev
  svn commit -m "$(hg log --template '{desc}' -r .)"
done

That loops from the checkedout revision to the tip and commits each in turn preserving the commit message. You probably need to do something fancy arround added/removes files.

Answer 2

No there are not.

You might have already seen this link. Currently interacting with svn repos is not officially supported yet. I would not write a shell script to automate this. This may yield unexpected results screw up the repos (however take a look at following workflow)

https://www.mercurial-scm.org/wiki/WorkingWithSubversion.

I currently do something similar to what you do.

1. checkout from svn repos save it under $HOME/svnhgrepos/project1
2. goto $HOME/svnhgrepos/project1, hg init, hg commit
3. change $HOME/svnhgrepos/project1/.hg/hgrc to automatically update on push
4. clone $HOME/svnhgrepos/project1 to $HOME/code/project1-clone.
5. goto $HOME/code/project1-clone, hg qinit (mercurial queues)
6. do all the development, commit it (just one changeset per feature/bugfix) and push it to $HOME/svnhgrepos/project1
7. Goto $HOME/svnhgrepos/project1, and perform 'svn ci'
8. I have not done this step in my setup. Now you may write a hg hook, to automatically peform a 'hg update' and a 'svn commit'

   
      e.g (i have not tested this)
      in $HOME/svnhgrepos/project1/.hg/hgrc   
      [hooks]
      changegroup.hg-update = hg update >&2
      changegroup.svn-commit = svn commit -m "hg log --template '{desc}' -r ."
      
   

Answer 3

I took Ry4an's answer and added add/remove handling. Here it is:

for therev in $(seq $(hg id -n -r .) $(hg id -n -r tip)) ; do
  hg update -C $therev
  svn st | perl -lne 'if (/^([?!])\s*(\S*)/) { my $command = ($1 eq "?") ? "add" : "rm"; my $fname=$2; $fname =~ s[\\][\/]g; system(qq(svn $command $fname));}'
  svn commit -m "$(hg log --template '{desc}' -r .)"
done

I found the -C was required when branches were involved. This gets pretty ugly, though, since files get removed and re-added when switching between branches. Also generally, renames info is lost, as well as the dates and identity of original commiter, of course.

Answer 4

It looks like you could use hg convert to do what you want retroactively. Enable the ConvertExtension and then just do hg convert -d svn file/path/to/mercurial/repo svn://repo/path/ though I've not tried it.

Answer 5

This might not be exactly what you want, but I think you might find this of use at some point. And, others may as well...

I work on Windows 7 OS, and I use both Mercurial (TortoiseHg) and Subversion (TortoiseSVN) for source control. Why? Well, what we have found, on our very small team of about 8 people, is that Mercurial is very convenient to use as a "personal" safety net, but is very confusing to some of our folks (eg, the FPGA engineers working in Verilog). The whole "push" and "pull" think with the requirement to merge a whole stack of other people's changes into yours was not welcomed with open arms. It seemed burdensome, and in one case, an engineer lost all of her work due to misunderstanding some of the nuances of how Mercurial does these things. There was fortunately another copy (she's a smart engineer!) so all was not lost, but it demonstrated how Mercurial's operations could be confusing and difficult to predict, at least for some people.

Mercurial's strength (IMO) is the ease with which you can switch between various development branches, and with the TortoiseHg tool, visualize the version tree and pick what you want to work on. You can very easily (and quickly!) save your work, grab another branch or start a new one, to do some experiments or pursue an alternative approach. As a convenient personal safety net and branch-switching workbench tool, it is superb. I use it all the time as I'm developing and testing my code.

Subversion, on the other hand, makes a very easy to use "team" server. People find it easy to understand how it works. Tagging and branching are not as intuitive, but we don't do this very often. Updates, merges, and checkins seem more intuitive and easier to manage.

It turns out, you can actually manage a single working copy using BOTH Mercurial and Subversion -- simultaneously! You can either checkout from SVN, then use Mercurial to "create repository here", or do it the other way around. You have to edit the ignore settings of SVN to ignore all the .hgxxxx files in your working copy folder, and have Mercurial ignore the .svn directory. Once you've done that, the command line or shell extension tools for either system continue to work just as they have, and you are now managing your code in two different repositories!

I was skeptical at first, but I really wanted the convenience of day to day Mercurial, with the central-server compliance of Subversion, which is what our team has chosen for the shared code repository. This way of working gives you the best of both worlds with no downsides that I have noticed so far.