The aim is to have a local copy of an internal svn which is afterwards pushed automatically to Github.

The hard way, importing all history

1. Setup the svn:

x
svnadmin repo

2. Init the git-svn bridge:

git svn init https://server.com/REPO -s
git svn fetch

3. The following step hurts: we need to rebase the trunk:

git rebase trunk

For each error, skip

git rebase --skip

(This is much easier than to handle all merge errors).

4. Show the merge errors and remove all merged data:

git status
find . -name *HEAD -exec rm {} \;

Be careful not to execute the command in the git-root since multiple HEAD-files are stored under .git.

5. Adapt this step for other merge error files not under version control and fix the files.

To be honest, fixing the merge errors resulting from the rebase is not really fun but necessary: Since all versions are replied and SVN is not able to handle branches in a way git/mercurial does, the rebasing is necessary. Scaling with the number of branches and tags, the rebasing need much interaction and time making the conversion of complete gits to svn questionable with respect to all use cases.

The easy way, importing only the last version

Relying only on the last version, I propose therefore a much more straight-forward approach, namely relying on only the last version.

1. Create a svn repo:

svnadmin create repo

2. Checkout the repo and copy the actual version of the git-repo to this location:

svn co https://server.com/repo SVNREPO
cd GITREPO
cp -R * SVNREPO
svn add *
svn ci -m "initial commit"

3. Binding the svn as remote to the existing git:

cd GITREPO
git svn init https://server.com/REPO -s
git svn fetch

4. Switching and building and merging on git site:

git svn fetch
git checkout trunk
mvn clean test
git checkout master
git merge trunk
git push origin

Note that this workflow relies on the following constraints:

  • The svn relies not on the history of the git.
  • The svn is always the one against which is actively developed. Gits commits must be merged manually.