Mercurial to Mercurial to Subversion Workflow Prob

问题:

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?

回答1:

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:

1. using Mercurial as a client for Subversion, without exchanging changes outside of svn
2. Converting Subversion repositories to Mercurial

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.

回答2:

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.

回答3:

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 [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>.
  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)