Submitting Hg changes back to SVN

Question

I've began work in an SVN repository. I've cloned a subfolder of it into a local Hg repo with hg clone.

Afterwards, I wanted to share this with a colleague who does not have access to the SVN repository. I've created a private BitBucket repository, and we occasionally pushed the changes, and hence I had to pull them.

hgsubversion does some nasty things to changesets, such as changing their committer (and I believe even the hash). When I tried pushing and pulling to the BitBucket repo, I had to do a merge.

Now I am unable to push changes back into the Subversion repository due to our beloved friend, abort: Sorry, can't find svn parent of a merge revision..

How would one pull the BitBucket-targetting Mercurial repository with the svn-targetting Mercurial repository, while staying compatible with hgsubversion (that is, without importing the merge revisions)?

Some automated way to do this would be appreciated, of course, but if there is no such thing/easy way to do this, I'd be grateful for any solution.

I use hgsubversion, not hgsvn; that is, the extension in which one does hg clone svn://repo/url. I am open to switching, though, if necessary.

Answer 1

I just hit a similar problem, which basically was:

• cloning a SVN repo with HgSubversion
• working it out with some merges
• trying to pull it back to the former SVN repo

and ran into the dreadful Sorry, can't find svn parent of a merge revision message.

That's what I did to fix it without too much hassle:

1. Download TortoiseSVN from this link and install it.
2. Check-out the SVN repo to a new folder using SVN Checkout... command from the contextual Windows Explorer menu (right-click to access it).
3. Copy the content of the local HG folder (excluding the .hg subfolder only) to the newly-created SVN folder, overwriting all files.
4. Right-click to that folder and do SVN Commit....
5. Trash your HG repo and pull it back from the now-updated SVN repo.

It takes 2 minutes and everything should start working again. You'll lose some merge & commit info, but it shouldn't be an issue since the SVN/HgSubversion combo can't track them anyway.

Answer 2

Yes, hgsubversion does change the committer name because it must reflect the name assigned by Subversion. Hgsubversion must then also change the changeset hash. It is not really something that hgsubversion can decide -- it's built into the design of Mercurial that the changeset hash is based on all information in the changeset and that included the name of the committer.

Please read my hgsubversion guide for information on how to work correctly with hgsubversion. The important points to remember is that hgsubversion turns hg into a better svn, but it is still Subversion that is the master. This means that you must linearize your history before pushing it back to Subversion so no merges or other funny DVCS things.

If you do want to take advantage of the distributed features in Mercurial, then do it in small iterations: do some collaboration in Mercurial, linearize the changesets and push back to Subversion, destroy the non-linear part of your clones, pull from Subversion. You can then repeat with a new iterations of collaboration in Mercurial.

Answer 3

When you use Mercurial on a subversion repository, you have to still think like SVN does, so a lot of features part of the basic mercurial workflow just won't work. Merging the way mercurial does it is impossible on a svn depot. If you have merged your work with the pulled svn branch, you'll get the infamous about message you're getting now :(

I suggest you read durin42's answer to this question.

EDIT : To get out of your current mess, I suggest you create a patch (or a series of patches) from the point you checkout from the SVN repo. Get a new fresh copy from the subversion repository and apply the patch(es). I am not sure you'll be able to do it from your current repo. You could explore the hg diff command.

hg diff -g -r tip -r XXX > patch

with XXX being your original SVN checkout (I haven't tested it yet.)