13

I have been maintaining the git mirror of the watir project. Some time a couple weeks ago, we had someone ready to submit their first git-based patch. Unfortunately, we ran into some issues regarding line endings (CRLF vs. LF, etc.) because of the multi-platform nature of the project.

I tried what I could to set the autocrlf option (to 'input'), and do some --hard resets. However, a few days later, the daily update (git svn rebase) is spewing this error:

Incomplete data: Delta source ended unexpectedly

I've tried googling around for what to do, but even removing the autocrlf setting in the .git/config hasn't helped. I fear the working copy is corrupt, but I hope it is not unrecoverable.

Obviously, a possible course of action is to just re-import from svn and start a fresh mirror, but I hope we don't have to do that, since the current watir-mirror has already been forked, and people have developed new code in their forks.

Thanks in advance for any help.

Pistos
  • 23,070
  • 14
  • 64
  • 77
  • did you get any further with this problem? we currently seem to have the same problem. (and making a git-svn checkout took 3 days last time so i hope i can avoid that) – pvgoddijn Nov 25 '09 at 08:42
  • @pvgoddijn No sorry, a resolution was never actually found. The problem just went away because they officially moved to github and abandoned svn. – Pistos Nov 30 '09 at 18:18

5 Answers5

17

I had this same problem in trying to create a git repository from the brlcad svn repository. I solved it by doing git svn reset --r XXXXX, where I set XXXXX to be about 50 revisions prior to the one that originally produced the error.

Stepping back a single revision was not successful in resolving the error. As part of the process, I received errors from git about HEAD not being defined. To resolve this, I did a git svn find-rev XXXXX to determine the hash corresponding to the revision I wanted, then git checkout. After this, the errors about HEAD were gone and the git svn reset -r XXXXX worked.

Nzbuu
  • 5,241
  • 1
  • 29
  • 51
Todd Wagner
  • 171
  • 1
  • 2
  • 2
    Thanks a lot. This helps on a similar problem. I just set revision number to one revision prior to current revision. – Lei Feb 24 '11 at 18:47
  • This helped, but just after I killed all zombie git/perl processes and deleted the index.lock file. See my answer here: http://stackoverflow.com/questions/21334923/incomplete-data-delta-source-ended-unexpectedly-while-git-svn-fetch/31405568#31405568 – boskicthebrain Jul 14 '15 at 11:42
5

From personal experience, git-svn always generates the exact same commits when cloning or fetching from a svn repository with the same parameters (try it: create a dummy repository, clone it with git-svn, do some more commits, clone it again, and fetch on the first copy; the resulting commits should have the exact same hash).

This gives you an interesting option: you can start a separate fresh mirror with the same parameters, and compare both to see where they diverge (or it they diverge at all; be sure to compare the hashes, since they are what matters). If they are the same (or you decide the commits after they diverge don't matter), you can use the fresh mirror without breaking the forks (or breaking less of them, if you decided to ignore a few diverging commits).

CesarB
  • 43,947
  • 7
  • 63
  • 86
  • The hash stays the same, huh? Well, I should have known/remembered that git hashes the actual bytes of the commit delta. Unfortunately, I may run into differences on account of me wanting to overcome the CRLF <-> LF issue the second time around. I will try re-importing, though. Thanks! – Pistos Oct 17 '08 at 04:26
  • Okay, CesarB, I tried to reimport from the svn source by doing a git svn init, setting autocrlf to input, then git svn fetch -- but I get the very same error ("delta source...") in the middle of the fetch. Any other suggestions? – Pistos Oct 18 '08 at 04:58
  • Try without playing with autocrlf at all, like your initial mirror. If it keeps having that error, I would suspect it's either svn or git-svn that's broken. – CesarB Oct 18 '08 at 05:35
  • Well, without the crlf settings, things function fine, but the merges panic about the line ending differences and show huge diffs even though the only delta has to do with whitespace. I also tried whitespace = cr-at-eol, but that doesn't seem to help in this regard. – Pistos Oct 24 '08 at 03:08
  • Anyway, this could be an abandoned issue because the watir project is reportedly fully moving to git before the year end. Thanks for your input nevertheless. – Pistos Oct 24 '08 at 03:09
4

I had the same problem with git svn fetch, but the reset approach didn't work for me, perhaps because I don't really know when the corruption occurred. Here's what finally worked for me. I did a git svn fetch --ignore-paths="/branches/" which ran without error. After that, I once again did my git svn fetch, and this time worked.

Don Branson
  • 13,631
  • 10
  • 59
  • 101
  • reset approach did not work for me too. But I dont want to ignore branches. What should I do? – anony Nov 30 '13 at 13:22
  • @anony you just ignore branches on the first command, then when you run the second time, you don't ignore branches, and it will pick the changes. – Don Branson Nov 30 '13 at 14:16
  • Hi Don, this did not work for me.The following is the error that I get:Incomplete data: Delta source ended unexpectedly at /usr/lib/perl5/site_perl/Git/SVN/Ra.pm line 282 – anony Dec 01 '13 at 11:33
  • @anony - Okay, that just means that the part you're ignoring (i.e., /branches/) isn't broad enough. There's a corruption in your svn repository, but apparently not under /branches. You may have to rely on trial-and-error to find where it is. – Don Branson Dec 01 '13 at 21:07
0

I've seen a similar problem. It occurs when I do a partial clone of an svn repo. I'm guess git-svn can't find the original source of the file when doing a dcommit. I've fixed it by ensuring I'm completely up to date (git svn rebase) then using git svn set-tree to commit specific changes to subversion. If you have a lot of changes to commit, this can be a pain since you need to manually commit each change in order but it works well if you only have one or two commits to push.

Trevor
  • 1,369
  • 2
  • 13
  • 28
0

i had the same problem and like Todd's case, going to a previous revision fixed the problem.

I think the solution is to go to two steps previous revision of the problematic file.

yigit
  • 37,683
  • 13
  • 72
  • 58