Error with Git SVN clone

Question

I am migrating several projects from SVN to Git, and I am using Git's 'svn clone' feature. I am trying to run the following:

git svn clone --stdlayout --authors-file=authors.txt <path-to-svn-project> <local-git-repo-name>

I have been able to clone several smaller projects, but when I try and clone a larger project it gives the following errors:

couldn't truncate file at /usr/lib/perl5/site_perl/Git.pm line 1322.

Error removing .git/Git_04wYzV at /usr/lib/perl5/5.8.8/File/Temp.pm line 890.

I thought it likely to find a quick fix in a google search, but instead this looks to be an unusual error. Does anyone have a clue how I can get past this?

My versions are pretty recent, and I'm trying to run this on Windows 8.1:

Git: using version 1.9.4.msysgit.0
Subversion: using version 1.8.9
git-svn: using version 1.9.4.msysgit.0

Answer 1

No idea if this was your problem, but I was having the same error git svn clone/git svn fetch-ing a large svn repo. Sometimes it would complain about couldn't truncate file, sometimes it would complain about too many open files, but it would die with one of them pretty reliably a fair ways into the process, usually on a particularly large revision (initially, retrying the fetch worked, but eventually it would start reliably dying on the same huge revision).

To fix the latter, I ran ulimit -n 4096 (ulimit -n reported a default limit for me of 1024), increasing the limit on open file handles by a factor of four. But rather than just fixing the "too many open files" error, it seems to have fixed the couldn't truncate file as well. While checking the source code indicates it's truncating by file handle (and therefore shouldn't need to open a new file handle to do so, risking handle exhaustion), this change did seem to fix the problem as well, so it's possible the underlying implementation does something that runs up against the open handles limit and dies in a way that implicate truncate, even though it was the open files limit itself that was responsible.

Answer 2

Invoking git svn fetch as Administrator has worked for me. It might access (and try to edit/delete) some files requiring Admin privileges.

Answer 3

I have had the same trouble when a svn repository is too large. I was able to handle it with an application SmartGit.

http://www.syntevo.com/smartgit/svn-tour There is a free trail of 30 Days.

Another way to solve this issue is too import from a revision if you don't need all the history.

git svn clone -r12345:HEAD  --stdlayout --authors-file=authors.txt <path-to-svn-project> <local-git-repo-name>

And finally you can try this command (to set buffer size) :

git config http.postBuffer 524288000

Answer 4

Run git --version and ensure that you are on Version 2.4+. I can't find the link right now, but back in 2.2.x and before, there was a bug in the Git SVN code that would cause it to fail at various points through large repository migrations. I ended up working with the Git developers on IRC and using a patch someone posted to the Git Mailing List, and got it working. That patch has since been merged and released, though. Ensure that you have a recent Git and a recent SVN. You can also resume a git svn clone just by running git svn fetch inside the directory. Also, --verbose helps see more context on error.