I have a project which requires to port a git repository to svn. I tried several ways posted on line, but none of them works for me up to now. If someone can help, I'll be really appreciated.
I followed a guide which cloned a git repo to a working copy, goes into the copy, rewind the head to the first commit, cherry pick all the commits and at the end did git svn rebase and git svn dcommit.
The PROBLEM of this method is my git repository is with a very 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 pick 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, then in the cloned working copy fetched the git repo, it then branch the master to old_master, at last apply all the commits from old_master to the master (git svn rebase). Then 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 that 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!!
I suppose you have no choice but to loose 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!