git svn fetch fatal: write error: Invalid argument

Odd situation is happening when I try to clone a remote svn repository.

When I type:

git svn fetch

Git will fetch the first 20 revision of the remote repository then at some point after 20 revisions it fails and just prompts the following error message.

fatal: write error: Invalid argument

Then just sits there doing nothing else. Repeating the same git init and then re fetching again, results in exactly the same place it reporting the fatal error.

Any idea what may be causign this to happen? I'm currently running the开发者_如何学C following versions:

TortoiseGit 1.2.1.0

git version 1.6.4.msysgit.0

---

Had identical issue with Msysgit v1.7.2.3, the latest version as at 29 Sep 10, and wanted to share my findings here (Google turns up several cases, but no solutions).

Trying to do "git svn rebase" on a repo (that has this has worked on plenty of times in the past) consistently failed with a "fatal: write error: Invalid argument" after a certain number of commits. The sync would then revert to the beginning again.

I believe this is a bug in Msysgit relating to large(ish) binaries and available memory (on a Win XP SP3 system with 4GB RAM and plenty free HD space). The remote system was the DotNetNuke SVN repo on CodePlex (https://dotnetnuke.svn.codeplex.com/svn).

Initially it was choking on a 330KB "CHM" file (~212th commit, r52261). It consistently did so, even after disabling Avast AV, Google Desktop, etc and verifying that there were no other processes with locks on the repo folder. After a reboot (but opening Outlook, Dreamweaver, etc), it then was consistently and repeatedly failing on a ~15.3MB DLL (~416th commit, same revision).

Finally, after another reboot, disabling Avast, Carbonite and Google Desktop and running no other programs, the sync worked first time.

This seems to point firmly to my conclusion that it was an available memory issue, probably linked to the presence of a largish binary and large number of commits in the revision. Note that I also tried "git fsck", "git svn reset xx" and tweaking the "packSizeLimit" / "usedeltabaseoffset" config vars, without success.

Chad - it could be that you had the same issue and it was the reboot that helped, rather than the upgrade.

---

I had simmilar problem, when I tried to fetch big remote repo. I tried several times from start, and all time get that error in approximatly same revision ~400 (or maybe exactly same - I didn't pay much attention). Googling didn't give answer. Than I take my shaman drum, and tried to kill TSVNCache.exe and TGitCache.exe processes. After that, I didn't see that error message. I re-sumed fetching process several times due to internet interruption - all was ok (total revisions ~3000), look like problem is gone.

My guess is that one of that processes lock some file, that used by git also.

NOTE: if you kill that processes and than start Explorer, they will be launched again.

---

Killing TGitCache worked for me. I hate to say TortoiseGit is really not where TortoiseSVN is... too bad.

---

The original version I was using when I ran into this error was:TortoiseGit-1.0.2.0-32bit.msi

Since checking out the GIT source code and also msysGit Source code from their Git repository I could not find any location of this error message.

I then updated to the following TortoiseGit version: TortoiseGit-1.2.1.0-32bit.msi

Then I ran exactly the same git command on the remote repository and it worked. So linking back to previous experiences with GIT and windows I conclude the following procedures if anyone in future has problems.

1) Check for updates, and update to the latest version before debugging
2) Trying to debug in an older version is not going to help, the problem could of been fixed in an new version.

Link to my previous experience on this matter: Link

---

If you rule out the obvious cause (no disk space left!), it could be linked to a layout issue with the remote SVN repository (branches not in the branch sub-directory, tags not in tag, ...). See Using git-svn with non-standard repository layouts for an example of such a SVN repo.

Other case asking for trouble: a SVN repo which has changed its layout since the last import

Also see mmap issues in Windows.

---

I had the same problem and had some odd files in my .git:

$ ls .git
1N4s5Mx6eD
3gRNi8l7yb
config
...

after I deleted those (1N4s5Mx6eD, 3gRNi8l7yb, ...) I could continue with git svn fetch.

I think that that network issues my be the reason, since git svn failed after a big file, for which network transmission errors are more likely.