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

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'.

Reply via email to