15

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
Matt Thompson
  • 773
  • 1
  • 10
  • 26

6 Answers6

6

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

Sergey Vyacheslavovich Brunov
  • 17,291
  • 7
  • 48
  • 81
Hiroshi Maekawa
  • 199
  • 3
  • 3
5

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
Mathieu Momal
  • 134
  • 1
  • 2
3

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.

ShadowRanger
  • 143,180
  • 12
  • 188
  • 271
2

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.

Will
  • 24,082
  • 14
  • 97
  • 108
1

I wasted many hours on my windows 10 machine with the same error. I tried the suggestions above and numerous others. My solution was to run it from a linux docker image.

user2046211
  • 356
  • 1
  • 4
  • 20
0

I got the exact same problem with msysgit 1.9.4.
Try to use v1.8.3 instead: I cloned all my SVN repositories without an error with it.

Julien Lebosquain
  • 40,639
  • 8
  • 105
  • 117