git svn：Delta 源意外结束
我正在使用 git svn 来进行 svn 存储库。我的同事承诺回购一些本机库，之后我无法重新设置我的主干：
D native/libVal.so.v8.0.38za
A native/libHelpVAL.so
A native/libValuation.so.v9.0.36l
不完整的数据：Delta 源在 /usr/lib/git-core/git-svn 第 5117 行意外结束
I'我尝试将 core.autocrlf 设置为 false （按照建议）并进行克隆，但这对我没有帮助。 我在 cygwin(win xp) 下使用 git 1.7.3.3。
感谢您的帮助。
I'm using git svn for svn repo. My colleague commited to repo some native libraries and i can't rebase my trunk after that:
D native/libVal.so.v8.0.38za
A native/libHelpVAL.so
A native/libValuation.so.v9.0.36l
Incomplete data: Delta source ended unexpectedly at /usr/lib/git-core/git-svn line 5117
I've tryed to set core.autocrlf to false (as suggested) and do the clone but it didn't help to me.
I'm using git 1.7.3.3 under cygwin(win xp).
Thx for any help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我在谷歌上搜索“Delta源意外结束”并发现这这意味着这是svn方面的问题。也许可以尝试在同事进行更改之前对一些修订进行 git svn Reset ，然后进行 git svn rebase 。
I googled "Delta source ended unexpectedly" and found this which implies it's an issue on the svn side. Maybe try doing a
git svn resetto a few revisions before the changes your colleague made, and thengit svn rebase.听起来你的问题确实是在 svn 方面。在我们的例子中，开发人员中止了目录的 svn 更新命令。如果您无法删除整个目录，您可以执行这些步骤，这些步骤在 svn 1.6.11 中对我有用：
搜索有问题的文件名，您应该看到类似于：
删除“END”之间的所有行以及一个“END”行。保存只读文件。
搜索有问题的文件名，您应该看到类似以下内容：
删除“^L”之间的所有行，包括一个“^L”行。保存只读文件。
It does sound like your issue is on the svn side. In our case, a developer aborted an svn update command for a directory. In case you can't take down the entire directory, you may be able to perform these steps, which work for me in svn 1.6.11:
Search for the offending filename, you should see similar to:
Delete all rows between 'END' as well as one 'END' row. Save the read-only file.
Search for the offending filename, you should see similar to:
Delete all of the rows between '^L', including one '^L' row. Save the read-only file.
以下是我解决问题的方法：
第 1 步：我确定了该文件导致了问题。可能是构建中断之前签入的最后一个文件。
第 2 步：我确保问题文件目录中的所有更改文件都已提交到存储库。
第 3 步：我从工作副本（不是存储库！）中删除了问题文件的目录。如果很难找到引起文件的情况，检查所有修改后删除整个目录即可。
第 4 步：我更新了整个工作副本
Here's how I solved the problem:
Step 1: I identified the file that was causing the problem. May be the last file checked-in before the build break.
Step 2: I made sure that all changed files in the problem file's directory were committed to the repository.
Step 3: I deleted the problem file's directory from my working copy (not the repository!). If it is difficult to find the causing file, just delete the whole directory after checking all the modifications.
Step 4: I updated my entire working copy
我在 OS/X 上运行“git svn fetch”时遇到此错误（我使用 svn2git 导入一个大型 svn 存储库到 git 中）。问题原来是有两个分支仅大小写不同，
/branches/BUG-241和/branches/bug-241，它们没有播放与 OS/X 不区分大小写的文件系统配合良好。我通过使用磁盘实用程序创建区分大小写的磁盘映像（遵循这些说明）并运行在那里导入。
I got this error while running "git svn fetch" on a OS/X (I was using svn2git to import a large svn repo into git). The problem turned out to be that there were two branches that differed only in case,
/branches/BUG-241and/branches/bug-241, which didn't play well with OS/X's case-insensitive file system.I worked around this by creating a case-sensitive disk image with disk utility (following these instructions) and running the import there.