从 Git 迁移到 SVN

Migrate from Git to SVN

提问by curlingbunny

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.

我有一个项目需要将 Git 存储库移植到 SVN。我尝试了几种在线发布的方法，但没有一种对我有用。如果有人可以提供帮助，将不胜感激。

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 rebaseand git svn dcommit

• 将 Git 存储库克隆到工作副本
• 进入副本
• 将头倒回到第一次提交
• 樱桃挑选所有提交
• 做git svn rebase和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.

这种方法的问题是我的 Git 存储库有一个复杂的历史。有许多分支和合并。当我挑选樱桃时，它只挑选了最终存储库的一部分。

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

问题：有什么办法可以避免采樱桃git svn rebase？也许用别的东西代替它？

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

我关注了这个网络帖子：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

• 做过 git svn clone
• 在克隆的工作副本中获取 git repo
• 将 master 分支到 old_master
• 将 old_master 的所有提交应用到 master ( git svn rebase)
• 做过 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 dcommitfailed. It told me: Unable to determine upstream svn information from HEAD history.

这种方法的问题类似于我在第一种方法中遇到的问题：当我这样做时git svn rebase，有很多冲突。另外，当我跳过所有冲突时，git dcommit失败了。它告诉我：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!!

从现在开始，我不知道还能尝试什么。如果您发现我做错了什么或有其他方法可以做，请提出任何建议。欣赏了！！

采纳答案by mgarciaisaia

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

我想您别无选择，只能丢失一些 git 历史记录 - SVN 无法处理那么多信息。

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

我想到的将问题委托给第三方的唯一技巧是利用GitHub 的 SVN 支持来简化您的任务。

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!

愿叉子与你同在！

回答by Rhuan Karlus

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.

在这个方向上进行转换的一般问题是 Git 存储库可以包含的不仅仅是修订的线性历史，正如 Subversion 所期望的那样。具有不同历史和频繁合并提交的多个祖先都是可能的，这在 Subversion 存储库中不容易表示。

对于在 Git 存储库中确实有线性历史记录的简单情况，您可以使用 git-svn dcommit 将批次推送到否则为空的 Subversion 存储库。

Best regards.

此致。