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 dat开发者_开发知识库a: 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.
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 reset
to a few revisions before the changes your colleague made, and then git svn rebase
.
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:
$ cd {directory_with_file}
$ cd .svn
$ vi all-wcprops
Search for the offending filename, you should see similar to:
END
{FILENAME}
K 25
svn:wc:ra_dav:version-url
V 123
/{URL}/!svn/ver/19811/{PROJECT}/trunk/{PATH_TO_FILE}
END
Delete all rows between 'END' as well as one 'END' row. Save the read-only file.
$ vi entries
Search for the offending filename, you should see similar to:
^L
{FILENAME}
file
{whitespace}
2012-09-14T07:37:36.000000Z
b32c5eec03f4be5c09fa7d9c71bac5ce
2012-09-13T07:13:43.808544Z
20167
{COMMITTER}
{whitespace}
11157
^L
Delete all of the rows between '^L', including one '^L' row. Save the read-only file.
$ cd text-base
$ rm {FILENAME}
$ cd ../../
$ rm {FILENAME} ; svn update {FILENAME}
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
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-241
and /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.
精彩评论