“Hg到Hg（Gateway）到SVN”与“Git to Git（Gateway）到SVN”相比

Question

Question is similar to this (unanswered) and this one (same problem not involving Git).

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

The setup should probably look like the one depicted below (same as in the questions referenced above), however I'm not sure about the exact topology of intermediate Hg 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:

1. Either git svn init , or git svn clone the SVN repo. This then becomes the “Git/SVN Bridge.”

2. Fix up any of the branches, tags, etc… here. The svn/* refs are considered remotes, so if you want tracking branches, check these remotes out and create appropriate local branches. Also, check the tags out, and create actual tags. You MUST create local branches for any SVN branches that you wish to synchronize between Git and SVN.

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

4. All Git users now clone this bare repository. The bridge will only be maintained by one (or a few) people that understand how to synchronize Git and SVN.

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

1. git svn fetch (get new SVN changes)

2. git checkout master

3. git pull master (get Git changes from bare repo)

4. git checkout svn/trunk (checkout detached head)

5. git merge –no-ff –log master (merge changes from master). –no-ff insures an actual commit, –log copies individual log messages from each commit on master ( –log is optional). git commit –amend can then be run if you want to edit the commit message.

6. git svn dcommit (This pushes your merge commit to SVN. Note that the commit was on a detached head, and is no longer accessible). All of your work on master (since the merge-base of master and svn/trunk ) gets committed as a single change, and is now available to SVN users.

7. git checkout master

8. git merge svn/trunk (Gets the new updates from SVN – with the altered commit message – and merges to master)

9. git push barerepo (makes the SVN changes available to Git users)

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

• no remote-tracking branches (is this possible with bookmarks ? separate cloned repos?)
• impossible to push merge commits via hgsubversion (step n. 6 in the above list. What stops hgsubversion from doing what svn dcommit does?)

Is it possible to make the Hg-SVN gateway work in the same fashion the Git-SVN gateway works? If no, why?

Answer 1

The short version is: nobody's yet convinced me what the reasonable expected behavior of pushing a merge to Subversion should be, and there are some slight modifications to hgsubversion advisable to make pushing result in merges rather than rebased revisions. None of it should be too hard, just takes someone motivated to do the implementation. If you're curious, this thread has a similar request where I responded with a fairly in-depth discussion of the basic approach that I've thought through with a couple of others.