Git-2-SVN migration?

10
votes

Yes, I know. Why would you want to migrate from Git to SVN?

Well I happen to be in a situation that I need to migrate a huge Git repo to Subversion! Here's one workflow I tried per Edwin's comment:

first create a local SVN repo: svnadmin create svn_repo

Next I check out my Git repo: git clone git:myNameSpace/myProject

cd into the myProject and run:

git svn init -s --prefix=svn/ file:///home/myHome/svn_repo/myProject

git svn fetch

git rev-list --parents master | grep '^.\{40\}$' to look up the hash of your root commit and gives only one commit as it should.

Next is to get the hash of the empty trunk commit: git rev-parse svn/trunk

This one unfortunately fails with:

fatal: ambiguous argument 'svn/trunk': unknown revision or path not in the working tree. Use '--' to separate paths from revisions

Well I can't go much after this....

2
gitsvnmigrationgit-svn
There is a lot of marketing (and a few good reasons) to favor Git over Subversion, but there are a lot of very good reasons to favor Subversion over Git too. Sane large file handling comes to mind (for one reason). – Edwin Buck
Sure, I love Git and favor it to Subversion in a heart beat... but I need to do this migration anyway... – Reza Toghraee
Actually, I favor subversion over git, but that has more to do with my familiarity, and tool integration expertise with subversion. It has little to do with git's feature set. – Edwin Buck
LOL, got it. It's the other way for me with Git I suppose... – Reza Toghraee
SVN 4 ever :) On additional reason: After committing code can't forget to "push" ... – hfrmobile

2 Answers

8
votes

I would recommend you to migrate that with SubGit in several easy steps.

$ svnadmin create svn.repo
$ subgit configure svn.repo
$ nano svn.repo/conf/subgit.conf #edit path to your (bare!) Git repository (you may use "git clone --bare <URL> bare.git.repo" if you don't have it locally)
$ subgit install

That's all. While translation SubGit will try to preserve all commits (even temporary), branches, merges, ignores, dates, EOLs settings, tags and so on, as it it possible.

After translation the repositories will be in sync (each push to Git is translated to SVN revision and vice versa). To break synchronization (if you don't need it) run

$ subgit uninstall svn.repo
3
votes

--- Edited after details added ---

Did you do an empty initial commit to svn/trunk? If not, then it would explain why you get an error that it cannot be found in the history.

The comments (in combination)

The --prefix gives you remote tracking branches like "svn/trunk" which
is nice because you don't get ambiguous names if you call your local
branch just "trunk" then.

and

Then get the hash of the empty trunk commit:

Tends to imply that they made a svn/trunk commit to prevent svn conflict with a pre-existing trunk directory. If that is so, perhaps your only misstep is not committing a svn/trunk to be found later?

--- Original post follows ---

Have you tried this? dcommit won't work properly until you linearize your trunk (or branch) history.

Please post the details of your attempted migration. While what you posted is a useful error message, it would be ten times more useful with the list of steps you used to arrive at that error.