git svn -<文件>;在提交中找不到

发布于 2024-10-05 12:03:54 字数 552 浏览 4 评论 0原文

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

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>)

我已阅读其他帖子表明可以通过一些修补来“取消获取”此信息。然而，我宁愿不失去历史，尽可能轻松地前进。

如何让 git-svn fetch 继续？

原文

In the middle of pulling down a (rather large) svn repo with git-svn, I encountered the following error message (generic info substituted for real info):

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>)

I have read in other posts that it is possible to "un-fetch" this info through some tinkering. However, I would rather not lose the history and go forward as painlessly as possible.

How can I get git-svn fetch to continue?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

莫言歌 2024-10-12 12:03:54

这可能意味着您正在收到一个新的 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 远程重置回文件真正创建的位置，以便您可以将其集成到您的历史记录中。这不会清除您的工作副本，但您需要重新设置此新历史记录上的所有工作分支的父级。

回复收藏 0 原文

笑叹一世浮沉 2024-10-12 12:03:54

当存储库设置了 svn:externals url 时，我从 git svn fetch 收到此错误，并且我的 --ignore-paths 正则表达式会将它们过滤掉。

回复收藏 0 原文

十二 2024-10-12 12:03:54

这里的一个快速解决方案是重置到出现问题的版本之前的版本。

git svn reset <a past revision>

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

然后运行git svn rebase或git svn获取。

A quick solution here is to reset to a revision fairly before problematic one.

git svn reset <a past revision>

For example, when an error message mentions r1000 e.g. run git svn reset r990, etc.

And run git svn rebase or git svn fetch.

回复收藏 0 原文

披肩女神 2024-10-12 12:03:54

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

假设您在 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 开始工作。

OK, I was struggling with this for a while, but found a work-around. You will lose history of the files prior to the current git repo revision, but history will be kept intact, and you don't have to --ignore-paths. If rewriting history is an option, you should follow Ben Jackson's git svn reset answer.

Let's say you are on r123, and don't have access to the folder scripts/, which was created in r100. Somewhere down the line, you are granted access. This doesn't actually generate a revision, and is acceptable in SVN, but in git this effectively rewrites history. The git-svn repo continues being updated normally until something in scripts/ is modified (lets call it r126). Now git svn fetch fails because it doesn't know what to do -- it has a diff for a file that doesn't exist!

The way I fixed it was the following:

# 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

That git-svn-id is the crux of the issue. It tells git-svn which commit maps to each revision. We're going to trick it into thinking our manual commit is actually an SVN commit.

# 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

Now, there should be another commit that restores the files one commit before they are updated. Finally, we need to make git-svn rebuild the history, and take note of our new tricksy commit

# 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

If all goes according to plan, you should have a repo with the new files, without rewriting history. You can git svn rebase and git push safely.

It may not be the most eloquent, but works as of git version 2.17.1.

回复收藏 0 原文

流心雨 2024-10-12 12:03:54

在 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 存在期间持续存在。如果您想永久设置它们，请转到“控制面板”>“系统>高级系统设置>>环境变量。

Got the same error on Windows in relation to special characters (here: umlauts) in filenames:

(...)
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)

The file in question was indeed in the referenced revision but git svn was unable to see it.

I was able to fix this problem by setting up environment variables for language and locale like this:

SET LANG=C
SET LC_ALL=C

You can execute these commands simply before running git svn, but they will only persist as long as the current shell lives. If you want to permanently set them up, head to Control Panel > System > Advanced system settings > Environment variables.

回复收藏 0 原文

海风掠过北极光 2024-10-12 12:03:54

我遇到了包含 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

I ran into this problem with directory names containing unicode characters, even though the error complains about a specific file in the directory. I tried

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

with the full path of the file, but that didn't work. Nor did trying the full path of directory with the unicode characters.

The command that finally worked was with the parent directory of the directory with unicode characters, like so:

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

回复收藏 0 原文

ペ泪落弦音 2024-10-12 12:03:54

对于较新的 MacOSX 系统，请配置

git config --global core.precomposeunicode false

，对于较旧的系统，请配置 true。此处解释：

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

正确设置配置选项后，我能够使用 < 导入 SVN 存储库code>svn2git （在底层使用 git 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"

，但我怀疑这会有多大区别。

For newer MacOSX systems configure

git config --global core.precomposeunicode false

, for older ones true. It is explained here:

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

After setting the config option correctly I was able to import a SVN repository using svn2git (which uses git svn under the hood).

I also had

$ 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"

But I doubt that makes much of a difference.

回复收藏 0 原文

~没有更多了~