Mercurial to Mercurial to Subversion Workflow Problem
We're migrating from Subversion to Mercurial. To facilitate the migration, we're creating an intermediate Mercurial repository that is a clone of our Subversion repository. All developers will be begin switching over to the Mercurial repository, and we'll periodically push changes from the intermediate Mercurial repository to the existing Subversion repository. After a period of time, we'll simply obsolete the Subversion repository and the intermediate Mercurial repository will become the new system of record.
Dev 1 Local --+--> Mercurial --+--> Subversion
Dev 2 Local --+ +
Dev 3 Local --+ +
Dev 4 -------------------------+
I've been testing this out, but I keep running into a problem when I push changes from my local repository, to the intermediate Mercurial repository, and then up into our Subversion repository.
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/01.png
On my local machine, I have a changeset that is committed and ready to be pushed to our intermediate Mercurial repository. Here you can see it is revision #2263 with hash 625...
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/02.png
I push only this changeset to the remote repository.
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/03.png
So far, everything looks good. The changeset has been pushed.
hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
I now switch over to the remote repository, and update the working directory.
hg push
pushing to svn://...
searching for changes
[r3834] bmurphy: database namespace
pulled 1 revisions
saving bundle to /srv/hg/repository/.hg/strip-backup/62539f8df3b2-temp
adding branch
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
rebase completed
Next, I push the change up to Subversion, works great. At this point, the change is in the Subversion repository and I return attention back to my local client.
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/04.png
I pull changes to my local machine. Huh? I've now got two changesets. My original changeset appears as a local branch now.
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/05.png
The other changeset has a new revision number 2264, and a new hash 10c1...
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/06.png
Anyway, I update my local repo to the new revision.
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/07.png
I'm now switched over.
alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/08.png
So, I finally click the "determine and mark outgoing changesets" and as you can see Mercurial still wants to push out my previous changesets even though they've already been pushed.
Clearly, I'm doing something wrong.
I also can't merge the two revisions. If I merge the two revisions on my local machine, I end up with a "merge" commit. When I push that merge commit out to the intermediate Mercurial repository, I can no longer push changes out to our Subversion repository. I end up with the following problem:
hg update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
hg push
pushing to svn://...
searching for changes
abort: Sorry, can't find svn parent of a merge revision.
and I have to rollback the merge to get back to a working state.
What am I missing?
You're not doing anything wrong, in fact in your situation the behavior you're seeing is the expected (if somewhat confusing to a new Mercurial user) result.
hgsubversion is really good for two things:
You're trying to use it as a more generalized gateway, which is a much much harder problem. Subversion has a very rigid view of the world, and we have to work within that. The truth of the matter is that the revision hash can only be viewed as final when using hgsubversion after the revision has been pulled from Subversion. Thus, if your developers ever share changesets between Mercurial repositories directly, without Subversion as an intermediary, this will occur.
The rebase is automatic and non-optional for a very fundamental reason: Subversion performs that rebase when you push. If you had unpulled changes when you pushed, Subversion did that rebase for you, and if successful (with a stupidly simple rebasing algorithm) it accepts the commit with no indication that a rebase occurred. We're patching together two different models.
I'd recommend moving everyone over to Mercurial at once - a hybrid approach like this is only going to make using Mercurial more difficult in the short term than it needs to be, and potentially confuse users new to DVCS.
First, let me say what a pleasure it was to read such a detailed question write up. :)
The problem is happening when you do the hg push to the svn repo from remote. Here's that output from your example:
hg push
pushing to svn://...
searching for changes
[r3834] bmurphy: database namespace
pulled 1 revisions
saving bundle to /srv/hg/repository/.hg/strip-backup/62539f8df3b2-temp
adding branch
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
rebase completed
I'm not a hg-subversion user, but that output says that in the process of doing the push you requested, it's pulling the changes from the svn repo, finding a new revision and then doing a rebase of your changeset 10c1 after (descendent of) the newly pulled revision. The rebase command takes branching histories and turns the into linear histories, but in doing so it changes the parents of the changesets, which changes their hashes, which looks like just what's happening to you.
Again, not a hg-subversion user, so I can't say if that pull/rebase is always supposed to happen and how that's supposed to work, but the hgsubversion wiki page says:
You can use the usual Mercurial commands to work with this repository. If you have a series of commits on a given branch, and want to move them to the tip of that branch, use the hg rebase --svn command while on the tip of your work, and those changesets will automatically be rebased over top of the new upstream work.
which makes it sound not normally automatic.
I couldn't quite tell from your intro, are new changesets still being created in svn, or are they created only in mercurial?
If they're only created in mercurial then one work-around would be to set up a svn-gateway repo on the remote system, and do the push from there, and never pull from that repo back into mercurial. Then the changesets in that repo would have different hashids due to the rebase, but they'd not flow back into the main remote repo and the end user systems.
The bigger fix though is to figure out why "hg push svn://.. is rebasing all the outbound changesets". Answer that one and the behavior will stop.
We are using the graft command now to do something similar to this. Effectively we recreate every changeset before pushing it to avoid having to push merge-changesets.
Our goal is to cleanly contribute to a project which uses subversion.
Create a subversion branch for all your changes. Get it in Mercurial.
$ cd [svn-checkout] ; svn cp trunk branches/hg-bridge cd [svn-checkout] ; svn cp trunk branches/hg-bridge
$ cd [hgsubversion bridge] ; hg pull ; hg update hg-bridge cd [hgsubversion bridge] ; hg pull ; hg update hg-bridge
Check your local repo for new changes
$ hg in [repo] # shows <rev> IDs you can use later
Pull the changes you want to get into svn from a local repo
$ hg pull [repo]
Graft all changes you want to contribute:
$ hg graft [rev] [rev] # rev could be 645 or b7a92bbb0e0b. Best use the second>. hg graft [rev] [rev] # rev could be 645 or b7a92bbb0e0b. Best use the second>.
You need to specify every rev individually,
but you can graft multiple revs in one command.
Check what you would push:
$ hg outgoing
Push the changes:
$ hg push
This might show some unrelated pulled revisions
and should show your new revisions as pulled,
along with paths to backup bundles (which you should not need).(comment can also be used under the GPLv2 or later)