12

I have a project that requires to port a Git repository to SVN. I tried several ways posted online, but none of them works for me. If someone can help, it'd be really appreciated.

I followed a guide on

  • cloning a Git repo to a working copy
  • going into the copy
  • rewinding the head to the first commit
  • cherry picking all the commits
  • doing git svn rebase and git svn dcommit

The problem of this method is that my Git repository has a complicated history. There are many branching outs and merges. When I did cherry pick, it only picks back part of the final repository.

Question: Is there any way to avoid cherry picking and git svn rebase? Maybe replace it with something else?

I followed this web post: Migrate a Git repo to an svn one

This post essentially

  • did git svn clone
  • fetched the git repo in the cloned working copy
  • branched the master to old_master
  • applied all the commits from old_master to the master (git svn rebase)
  • did git dcommit

The problem of this approach is similar to what I had in the first one: When I did git svn rebase, there are a lot of conflicts. Also, when I skip all the conflicts, the git dcommit failed. It told me: Unable to determine upstream svn information from HEAD history.

I can't tell what else to try from this point on. Please give any suggestions if you notice anything I did wrong or have other ways to do it. Appreciated it!!

Little Helper
  • 1,870
  • 3
  • 12
  • 20
curlingbunny
  • 183
  • 1
  • 2
  • 8

2 Answers2

6

I suppose you have no choice but to lose some of your git history - SVN just can't handle that much information.

The only hack I'm thinking of, for delegating problems to a third party, would be to take advantage of GitHub's SVN support to ease your task.

I'd recommend you to really think if you need to keep your history at all, or how complete it needs to be. Based on that, I'd just squash/rebase the conflicting commits (or the whole history in a single commit) and start off from that.

May the fork be with you!

BallpointBen
  • 9,406
  • 1
  • 32
  • 62
mgarciaisaia
  • 14,521
  • 8
  • 57
  • 81
  • This is awesome! Something really simple and fits all my needs!! Thank you so much! – curlingbunny Oct 03 '13 at 12:27
  • 1
    Downvoted because SVN can handle that much of information and actually can handle much more info than Git. The main problem is that Git does not track renames and moves at all. Therefore, the migration can be complicated. – bahrep Jan 21 '16 at 13:16
  • Git detects renames rather than persisting the operation with the commit, so whether you use git mv or just a plain mv doesn't matter. http://stackoverflow.com/questions/2314652/is-it-possible-to-move-rename-files-in-git-and-maintain-their-history/13544573 – Dev Feb 17 '16 at 09:49
2

Well, you must take a look at this question. Best answer is:

The general problem with doing conversions this direction is that Git repositories can contain more than just a linear history of revisions, as Subversion would expect. Multiple ancestries with divergent histories and frequent merge commits are all possible, which can't be easily represented in a Subversion repository.

For simple cases where you do have a linear history in your Git repository, you can use git-svn dcommit to push the lot up to an otherwise empty Subversion repository.

Best regards.

Community
  • 1
  • 1
R. Karlus
  • 2,094
  • 3
  • 24
  • 48