Using Git as Bridge Between Git and SVN Repos? [closed]

Question

Problem

My team uses git for source control on bitbucket, our client uses Subversion in house. How can our team continue to use git while having code checked into Subversion? And, no, I don't think git-svn will work.

Requirements

My team wants to use a pure git solution, not git-svn. The reason for this is that our client has granted us access to their svn environment only within our office LAN; we can't do commits to svn when working out of the office.

My Approach

I thought that I could checkout the subversion repository using git-svn, then add our bitbucket git instance as a remote to the same git-wrapped svn repository. A cron job could then do the git pull from our bitbucket repo, then do a git svn dcommit to push the changes in bitbucket up to our client's subversion repository.

This was problematic for the reason that git would always show I was 'x' number of revisions ahead of the git bitbucket repository after the pull, svn dcommit process finished.

While nothing outwardly weird is going on yet, at some point I'm confident our client will start making check-ins to their subversion repository that I'll have to eventually push to our bitbucket instance.

Technical Details

Here's a rough series of steps I've been using to try to get this working:

git svn clone -s http://svn.my-client.us/my-proj/
cd my-proj
git remote add origin path-to-bitbucket-repo
git fetch origin
git checkout -b develop remotes/develop
git branch --set-upstream develop origin/develop
git pull
#add merge comment here
git svn rebase
git svn dcommit #takes a while to transfer all the individual commits

After all the above, executing git status:

[me@dev myDir]$ git st
# On branch develop
# Your branch is ahead of 'origin/develop' by 59 commits.
#
nothing to commit (working directory clean)

Given I need to be able to do check-ins from any location, not just while I'm in the office, is there any strategy for using it as the bridge to do this?

Thanks!

Answer 1

Your approach is correct, but you have to be aware that dcommit rewrites history even more disruptively than a normal rebase does. For example it appends a git-svn-id line to each commit which is dcommitted to svn. This is why your develop branch appears ahead of origin/develop - because it has 59 commits all containing git-svn-id in the message, and none of these are present in origin/develop. As a result, you will have to rebase your git branches after each dcommit, or at least prior to the next dcommit. This means force-pushing to rewrite the history of the upstream:

git push -f origin develop

If any other branches were based on this upstream, they would now have to be rebased on it.

The CAVEATS section of the git-svn man page goes into more detail, so you should definitely read it.

Changes made by your client on the svn side will automatically be incorporated into your develop branch via the git svn rebase, and eventually reach bitbucket via the git push -f above.

If this kind of workflow doesn't satisfy you, then it might be worth looking at SubGit. I've never tried it, but they claim to offer a much less limited integration between the two SCMs.