"From Hg to Hg (Gateway) to SVN" compared to "Git to Git (Gateway) to SVN"

Question

The question is similar to this (unanswered) and this (this problem is not related to Git).

The goal is to make Hg front end for SVN for a period of time before completely switching to Hg.

The setup should look like the one shown below (same as in the questions mentioned above), however I am not sure about the exact topology of the Hg intermediate repositories.

 Dev1 Hg --> Hg <--> SVN Dev2 Hg -/ 

I know that the above setup works with git and git-svn as described in this comment :

 Dev1 Git --> Git (bare) <--> Git (bridge) <--> SVN Dev2 Git -/ 

Setup:

• Either git svn init or git svn clone SVN repo. Then it becomes the "Git / SVN bridge".

• Correct any branches, tags, etc. here. The svn/* flags are considered remotes, so if you want to track branches, check these remote objects and create the corresponding local branches. In addition, check the tags and create relevant tags. You MUST create local branches for any SVN branches that you want to sync between Git and SVN.

• Now create a new bare repository ( git init ) somewhere, and from the bridge move all the branches to the bare repo ( git push –tags ).

• All Git users now clone this empty repository. The bridge will be supported by only one (or several) people who understand how to synchronize Git and SVN.

To update the SVN trunk with changes on the main and vice versa, from the bridge:

• git svn fetch (get new SVN changes)

• git checkout master

• git pull master (get git pull master changes from bare repo)

• git checkout svn/trunk (removed head)

• git merge –no-ff –log master (merging changes from the main). –no-ff provides a real commit, –log copies individual –log messages from each commit to master ( –log is optional). Git commit -amend can be run if you want to edit a commit message.

• git svn dcommit (This pushes the merge commit to SVN. Note that the commit was on a separate head and is no longer available). All your work on the master (since the merger base is master and svn/trunk ) is fixed as one change and is now available to SVN users.

• git checkout master

• git merge svn/trunk (Retrieves new updates from SVN - with a modified commit message - and merges with the master)

• git push barerepo (makes SVN changes available to Git users)

I don't know if it is possible to somehow reproduce the above on Hg. As I can see (I am an intermediate user of Git and know the basics of working with Hg), the obstacles in Hg are:

• no remote tracking branches (is this possible with bookmarks ? separate cloned repositories?)
• cannot merge merge through hgsubversion (step n. 6 in the list above. What stops hgsubversion from doing svn dcommit ?)

Is it possible that the Hg-SVN gateway works the same as the Git-SVN gateway? If not, why?

Answer 1

Short version: no one has yet convinced me that there should be a reasonable expected behavior to push the merge to Subversion, and there are some small changes in hgsubversion that should be made in order to achieve the result when merging, and not with the changed version. None of this should be too heavy, it just requires someone to motivate the execution. If you're interested, this thread has a similar request, where I answered with a rather detailed discussion of the basic approach that I thought up with several others.