GIT-SVN

Created: November-22, 2018

克隆真正庞大的 SVN 存储库

如果你的 SVN repo 历史非常大，这个操作可能需要几个小时，因为 git-svn 需要重建 SVN repo 的完整历史记录。幸运的是，你只需要克隆一次 SVN repo; 与任何其他 git 存储库一样，你只需将 repo 文件夹复制到其他协作者即可。将文件夹复制到多台计算机将更快，只需从头开始克隆大型 SVN 存储库。

关于提交和 SHA1

使用命令 git svn dcommit 时，将重写你的本地 git 提交。此命令将向 git commit 的消息添加一个文本，该消息引用在 SVN 服务器中创建的 SVN 修订版，这非常有用。但是，添加新文本需要修改现有提交的消息，而这些消息实际上无法完成：git 提交是不可变的。解决方案是使用相同的内容和新消息创建一个新的提交，但从技术上讲它是一个新的提交（即 git commit 的 SHA1 将改变）

由于为 git-svn 创建的 git 提交是本地的，因此 git 提交的 SHA1 ID 在每个 git 存储库之间是不同的！这意味着你不能使用 SHA1 引用来自其他人的提交，因为相同的提交将在每个本地 git 存储库中具有不同的 SHA1。如果要引用存储库的不同副本之间的提交，则在推送到 SVN 服务器时，需要依赖附加到提交消息的 svn 修订号。

你可以使用 SHA1 进行本地操作（显示/区分特定提交，樱桃选择和重置等）

故障排除

git svn rebase 命令发出校验和不匹配错误

命令 git svn rebase 抛出类似于这样的错误：

  Checksum mismatch: <path_to_file> <some_kind_of_sha1>
  expected: <checksum_number_1>
    got: <checksum_number_2>

解决此问题的方法是在最后一次修改故障文件时将 svn 重置为修订版，并执行 git svn fetch 以恢复 SVN 历史记录。执行 SVN 重置的命令有：

git log -1 - <path_to_file>（复制提交消息中出现的 SVN 修订号）
git svn reset <revision_number>
git svn fetch

你应该能够再次从 SVN 推送/拉取数据

在提交中找不到文件当你尝试从 SVN 获取或拉取时，你会收到类似于此的错误

<file_path> was not found in commit <hash>

这意味着 SVN 中的修订版试图修改由于某种原因在本地副本中不存在的文件。摆脱此错误的最佳方法是强制取消忽略该文件的路径，它将更新为其在最新 SVN 版本中的状态：

git svn fetch --ignore-paths <file_path>