On Wed, May 28, 2008 at 8:43 AM, elupus wrote: > > By the looks of it, atleast 50% of cpu usage is spent as kernel time. So my > only guess would be the incessent starting of perl.exe processes could be the > culprit. Overhead for processes in windows is quite large. > > Any thoughts?
Yes, git-svn does a lot of fork/execing, and fork emulation would be slow even if it weren't for the fact that Windows' exec is painfully slow already. I work around the problem by running git-svn on a Linux box and using git-fetch on the Windows side[1]. If you don't have a spare Linux box handy, you can easily install Linux on VMWare Server or VirtualPC or VirtualBox (all of which are free-as-in-beer, and I believe VirtualBox even has a free-as-in-speech version available, too) or colinux, or your favourite virutal machine. I can't guarantee it will be fast, but it should at least be less slow[2]. Peter Harris [1] See near the bottom of "git help svn", although it is missing a needed "git reset --hard" to create "master". This is the exact command sequence I use on the Windows side: mkdir project cd project git init git remote add origin git://linux/~user/project git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/* git fetch git svn init -s svn://svn-server/project git reset --hard trunk git svn rebase ...and you can use git-svn as normal from there on out. I actually set up a cron job on the Linux box to refresh the svn mirror (git svn fetch && git svn rebase -l) hourly; if I haven't touched a project in a while, I find it is sometimes faster to do a: rd /s/q project/.git/svn git fetch before running "git svn rebase". This blows away and re-creates the git-svn cache, but git-svn re-indexing the commit history is often faster than waiting for git-svn to download all the intermediate checkins. Especially if the changes are large from "svn checkout"'s perspective, but small from Git's perspective (such as renaming the parent directory of a fair sized subtree, or blowing away an entire subtree and then reverting the deletion in the next commit - both of which I've seen). [2] Oh, and make sure you have svn 1.4.3 or later; earlier versions made git-svn much slower at some operations. Note that Debian 'stable' has svn 1.4.2 (as well as an ancient git version), so update svn to 'testing' when you update git if you use an older distribution such as Debian 'stable'.
