Question

在使用git-svn下拉（相当大）svn repo的过程中，我遇到了以下错误消息（替换为真实信息的通用信息）：

Found possible branch point: svn://server/project/trunk/dir => svn://server/project/branches/branchname, <revision>
Initializing parent: refs/remotes/branchname@<revision>
project/trunk/dir/file was not found in commit <hash> (r<revision>)

我已经在other posts中读到，可以通过一些修补来“取消”这些信息。但是，我宁愿不要失去历史，尽可能无痛地前进。

如何让git-svn fetch继续？

Answer 1

这可能意味着您正在接收一个新的svn修订版，该版本修改了一个文件（由于某种原因）在您的git commit中不存在等同于父svn修订版的文件。导致这种情况的一种非常简单的方法是与--ignore-paths不一致（最初没有办法配置它们，并且必须在可能获取的每个git-svn命令行上输入它们。另一种方法是让svn服务器端的某个人更改存储库权限，以便突然出现（从您的角度来看）您的git存储库没有历史记录的整个文件子树。

解决这个直接问题并继续git-svn fetch的最简单方法是使用--ignore-paths（或更好的svn-remote.svn.ignore-paths配置条目）来忽略树的问题部分。您可以使用命令行参数来传递单个修订版，并且在有人在svn端修改它之前，您不会再次遇到问题。

如果要在不使用 --ignore-paths的情况下恢复，则需要修复父版本，使其包含正在修改的文件。我专门写了git-svn reset来做你所提到的“取消取消”，而不是修修补补。它可以将您的svn遥控器重置回文件真正创建的位置，以便将其集成到历史记录中。这不会消除您的工作副本，但您需要在此新历史记录中重新显示任何工作分支。

Answer 2

当存储库有svn：externals urls设置时，我从git svn fetch得到了这个错误，而我的--ignore-paths regexp会将它们过滤掉。

Answer 3

这里的快速解决方案是在问题之前公平地重置为修订版。

git svn reset <a past revision>

例如，当错误消息提到r1000时，例如运行git svn reset r990等等

并运行git svn rebase或git svn fetch。

Answer 4

好的，我为此苦了一段时间，但是找到了解决方法。您将丢失当前git repo修订之前的文件历史记录，但是历史记录将保持不变，并且您不必--ignore-paths。如果可以选择重写历史记录，则应遵循Ben Jackson的git svn reset answer。

假设您在r123上，并且无权访问在r100中创建的文件夹scripts/。沿线的某个地方，您被授予访问权限。这实际上不会生成修订，并且在SVN中可以接受，但是在git中，这可以有效地重写历史记录。 git-svn存储库将继续正常更新，直到scripts/中的某些内容被修改（称为r126）为止。现在git svn fetch失败了，因为它不知道该怎么做-它对不存在的文件有一个差异！

我修复它的方法如下：

# Clone the directory that is missing one revision before it is next changed
$ svn co -r 125 https://your-server/svn/bla/scripts

# copy the contents and (-p)reserve their attributes
$ cp -pr scripts/* ~/your-git-svn-mirror-on-r125ish/scripts

# Get the git-svn-id of the the most recent commit
$ cd ~/your-git-svn-mirror-on-r125ish
$ git log -1 | grep git-svn-id
git-svn-id: https://your-server/svn/bla/trunk@125 7b6d...daf

git-svn-id是问题的症结所在。它告诉git-svn哪个提交映射到每个修订版。我们将欺骗它以为我们的手动提交实际上是SVN提交。

# Add the missing new directory
$ git add scripts/

# An editor will open up, type a message warning this commit isn't a real svn revision
# The last line of your message should be the 'git-svn-id' from earlier.
$ git commit
<your message of warning>
git-svn-id: https://your-server/svn/bla/trunk@125 7b6d...daf

现在，应该有另一个提交，可以在更新文件之前恢复一次提交。最后，我们需要使git-svn重建历史记录，并注意我们新的棘手提交

# Backup the svn state in case something goes wrong
$ mv .git/svn .git/svn-BACKUP

# Cross your fingers, and fetch the changes from svn
# If your repo is large, it may take a long time to rebuild the mappings
$ git svn fetch

如果一切都按计划进行，那么您应该有一个包含新文件的存储库，而无需重写历史记录。您可以安全地git svn rebase和git push。

它可能不是最雄辩的，但从git version 2.17.1开始有效。

Answer 5

在Windows上与文件名中的特殊字符（此处为：变音符号）有相同的错误：

(...)
r36770 = 24d589b34b952dd13ee8d231e7ce4d675ec1a82c (refs/remotes/origin/xxx)
    M   doc/specification/xxx/2013 03 07 Workflows.xls
xxx/branches/xxx/doc/specification/xxx/2013 03 07 MÃ¼nchen.xls 
    was not found in commit 24d589b34b952dd13ee8d231e7ce4d675ec1a82c (r36770)

有问题的文件确实在引用的修订版中，但git svn无法看到它。

我能够通过设置语言和语言环境的环境变量来解决这个问题：

SET LANG=C
SET LC_ALL=C

您可以在运行git svn之前执行这些命令，但只有当前的shell存在时它们才会持续存在。如果要永久设置它们，请前往控制面板＆gt;系统＆gt;高级系统设置＆gt;环境变量。

Answer 6

即使错误抱怨目录中有特定文件，我也会遇到目录名称包含Unicode字符的问题。我尝试过

git svn fetch --ignore-paths path/up/to/filename

包含文件的完整路径，但这不起作用。也没有尝试使用unicode字符尝试目录的完整路径。

最终起作用的命令是带有Unicode字符的目录的父目录，如下所示：

git svn fetch --ignore-paths path/up/to/but-not-including-unicode-chars

Answer 7

对于较新的MacOSX系统进行配置

git config --global core.precomposeunicode false

，对于较老的true。解释如下：

https://michael-kuehnel.de/git/2014/11/21/git-mac-osx-and-german-umlaute.html

正确设置config选项后，我可以使用svn2git（在后台使用git svn）导入SVN存储库。

我也有

$ locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL="de_DE.UTF-8"

但是我怀疑这会有很大的不同。

在提交<hash> </hash> </file>中找不到git svn - <file>

7 个答案: