I just stated a new assignment and they use Subversion for version control. It was years since I last worked with Subversion and have been exclusively using git since. So I decided that rather then going back to SVN and getting confused and frustrated I will use git-svn.

After two days of struggling to check out the larger, and more important, repositories using git-svn I was starting to doubt the value of this. Sure, The reason it takes so long is that git fetches the complete history but SVN only fetches the last revision. But will this wait really pay of?

I then realised two things. Firstly, running three processes at the same time will choke the hard drive, leaving them hanging whilst waiting for each other. So running one at the time makes all of them complete faster.

Second, it's a good idea to use the flag --log-window-size. This flag tells git-svn how much history it should get each time it fetches history from the SVN server. If the SVN repository has a long history the default value of 100 is way to low. I increased this to 1000 and this greatly improved the performance. However, reading about the flag, there is a warning. If this number is set to high the SVN server may consume to much memory so don't go overboard.

Another thing worth knowing is that even if the target folder seems empty if the git svn clone command fails or is stopped there is usually a .git folder in it. This contains the work performed up to the point when the task was interrupted. It is possible to resume using git svn fetch rather then starting from scratch.

Edited to add: Since the source code has some odd ways to add auto-generated code, I.E. not to Mavens target folder but straight into the source, I tried out the command git svn create-ignore. This was however a mistake, at least for my repository. It added a new .gitignore file in almost every folder in the project, all looking pretty much the same. It was quite a hazel to get rid of them so I'd say it's easier to manually craft your ignore file then to use the tool.