Convert svn projects to git, but allow merging of bugfixes made in svn

Question

I have a svn repository with many projects—but I am only interested in some (parts of server and full-client).

trunk
  server
    src
      src-that-should-be-in-client
      other-src-that-belongs-to-server
    cfg
      cfg-that-should-be-in-client
      other-cfg-that-belongs-to-server
  client
  docs
  foo
  bar

In the process of transforming the build system of the client I want to convert the project to git. But all support branches where bugfixes will happen stay in svn.

I want to be able to merge bugfixes made in the support svn branches to git (and possibly vice versa as well). OK, this is easy, I know how to do this (I am not interested in the old branches and tags):

# create mirror of client
git svn clone --prefix=svn/ --trunk=trunk/client http://svn-server client
cd client
git remote add mirror path_to_remote_mirror
crontab -e # automatically call git svn rebase and git push mirror
# repeat for server

Work would be done on a fork of the remote mirror. To merge bugfixes made in svn, just add the mirror as remote and continue as described elsewhere (e.g. github). Cherry-Picking in the other direction is a little bit more advanced, but possible.

But I want to move parts of the server over to the client after transitioning to git—Without loosing the history and being able to merge bugfixes.

One way I thought of was to alter the git svn clone command using --trunk=trunk and adding --include-paths=(?:server|client). Now I have a mirror of both the server and client in one git repository. I would fork it, move the parts that belong to the client, delete the server folder and finally move everything under client to the root (with intermediate commits, of course).

Another way of doing this would be to create a fork of the client, and subtree merge parts of the server over.

I see one problem with the first approach, which is files added in svn in the server code will be merged as well, and files changed in the server code (and deleted in git) might result in merge conflicts. Workaround: use git merge --no-commit inspect the server-dir if created during merge, if it contains files that belong in the client, move them over, delete the server-dir, commit. But other than that, it seems easy enough to be done by non-git-wizzards. Maybe it can be improved by calling filter-branch afterwards?

For the second approach I am not sure, if merges will even work. At least it seems to be more advanced and might not be doable by non-git-wizzards.

Which approach is better? Or is there a better approach?

Answer 1

I had this same problem earlier. First, I created some bash shell scripts to assist in the migration:

https://github.com/gburghardt/Git-Extensions

Then I had one Git-SVN hybrid repository on one machine. It did a "git svn pull" every hour or so via a cron job, and pushed those commits to another repository in a branch called "svn_trunk". Nobody ever committed or merged anything into svn_trunk, so it purely consisted of commits from my Git-SVN hybrid.

Then all the developers using Git and not SVN simply needed to do this:

git fetch
git merge origin/svn_trunk

For our purposes, this is the basic breakdown:

Repository A (Git-SVN hybrid)

1. Every hour, do a git svn pull
2. Push the new commits to Repository_B/svn_trunk

Repository B

This is the repository that all developers cloned when doing their work, making it their "origin" server.

We had this branching scheme:

master
\
 -- development
    |
    +-- feature_branch_1
    |
    +-- feature_branch_2

To get bug fixes from SVN, developers would:

git checkout development
git fetch
git merge origin/svn_trunk
git push origin HEAD
git checkout feature_branch
git merge development

When we initially created "Repository B", I created master off the tip of svn_trunk. Then development was created off the tip of master.