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.