Question

I’m at my wit’s end here with a git-to-svn setup I just created. I’ve setup a repository with two remote repos, one svn based and the other a remote git:

svn-remote.svn.url=https://subversion.acme.com/svn/sales/portal/trunk
svn-remote.svn.fetch=:refs/remotes/git-svn
remote.origin.url=[e-mail]:/gitroot/acme-gtm-2-0.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

Once I set this up, I was able to move commits from the git repo to the svn repo like this:

git fetch origin
git rebase origin/master (linearizes commits to svn)

git svn rebase
git svn dcommit

Everything was all fine, until I decided to test how I’d handle conflicts. I created a foo.dat file and added a line in it from the svn side and made a corresponding file on the git side with a line indicating something to the effect it was from git. I ran git fetch origin and git rebase origin/master to bring the foo.dat file down. That was fine, but an attempt to run git svn rebase resulted in a conflict. Perfectly expected, so I go through the steps of editing the conflict and using svn rebase –continue. But then the chaos begins. After an attempt to run git rebase origin/master to pull down other changes from the repo, I conflict on that same foo.dat file. I’ve gotten it into a state where if I resolve the conflict for svn, it’ll fail for git and vice versa. The most frustrating thing of all, I can’t seem to find a way to get the repositories back into a state to revert this mess. For now, I have the luxury of being able to completely blow away repos and try again, but in the future as developers use this, if I get myself into a state like this I’d really like to know how to get out. Any tips on what’s going on and how to end the constant merges would be hugely appreciated.

Thanks!

Answer 1

These conflicts have nothing to do with git-svn.

If one has a couple of remotes: remote1 and remote2, and the history of these remotes has diverged, then rebase operation always rewrites the history of first remote on top of another.

Suppose one has a single commit A referenced by master branch:

$ git log master
* commit A
Initial commit

And a couple of remotes with a diverged history:

$ git log remote1/master
* commit R1
Added conflict.txt at remote1
* commit A
Initial commit

and

$ git log remote2/master
* commit R2
Added conflict.txt at remote2
* commit A
Initial commit

Now one rebases the local history as follows:

$ git rebase remote1/master
$ git log master
* commit R1
Added conflict.txt at remote1
* commit A
Initial commit

Now one tries to rebase the local history on top of remote2/master, gets conflicts and resolves them:

$ git rebase remote2/master
$ git log master
* commit R1
Added conflict.txt at remote1
* commit R2
Added conflict.txt at remote2
* commit A
Initial commit

Noticed? Rebase operation puts commit R1 on top of R2. As you may expect, rebasing the given history on top of remote1/master just swaps commits R1 and R2 and generates exactly the same conflicts.

How to fix that? Well, you have to make the history the same for both remotes. The safest way to do that is to merge commits R1 and R2 and push the resulting merge commit to both remote1 and remote2.

Now back to git-svn. For your case, merging the diverged history won’t work as git-svn always rewrites your local history when you run git svn dcommit. Instead you have to do the following:

1. Fetch and rebase commits from Git repository:

    $ git fetch origin
    $ git rebase origin/master (linearizes commits to svn)
   

2. Send the changes to SVN repository:

    $ git svn rebase
    $ git svn dcommit
   

3. Push commits fetched from SVN back to origin:

    $ git push -f origin master:master
   

The third step is extremely dangerous, it may result in a lost history. So, I don’t recommend doing that — git-svn just does not support such workflow.

Instead you may try SubGit. SubGit is a bi-directional server-side mirror tool for SVN and Git repositories.

If you have local access to Subversion repository, you can install SubGit into it:

$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify your branches and tags
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL

As result you get converted Git repository which is automatically synchronized with original SVN repository.

If you have no local access to SVN repository, you may consider using SubGit 2.0 which is going to hit an early-access stage soon. SubGit 2.0 allows to setup bi-directional mirror between Git repository and remote SVN repository.

SubGit is a commercial product. It is free for open-source and academic projects and also for projects with up to 10 committers.

For more details please refer to SubGit documentation and git-svn comparison page.

Full disclosure: I’m one of SubGit developers.