nirvdrum / svn2git

Ruby tool for importing existing svn projects into git.
MIT License
2.11k stars 443 forks source link

Performance of svn2git --rebase --metadata #253

Open pcbeard opened 7 years ago

pcbeard commented 7 years ago

I have a repo that I just recently migrated using svn2git. It contains 73 branches, and 1128 tags. When I run the command

 svn2git --rebase --metadata

It takes quite a while, even when there are no new changes. Here's what time reports:

 svn2git --rebase --metadata  9.42s user 30.24s system 80% cpu 49.401 total

This repository has a lot of history in it, roughly 10,000 commits. Is this expected? Keeping an svn clone updated using these commands is actually nearly instantaneous:

 time git svn fetch && time git svn rebase -l
 git svn fetch  0.17s user 0.11s system 73% cpu 0.373 total
 git svn rebase -l  0.23s user 0.18s system 77% cpu 0.517 total
pcbeard commented 7 years ago

If there are no new commits in a repo, is it possible to short-circuit all the work that svn2git --rebase is doing?

pcbeard commented 7 years ago

Are there any tools that can be used to profile Ruby code execution?

pcbeard commented 7 years ago

Here's a profile taken using ruby-proj that took 328 seconds to run. Each command gets run in its own thread, so there's a lot of creating and joining with threads, but I'm not sure if that's the real source of the performance problem. I'm wondering if it's simply the tree operations that are being done each time.

svn2git.txt

pcbeard commented 7 years ago

Running with the --verbose flag gives me an idea. There are a lot of these kinds of commands:

git checkout -f BRANCH_NAME git rebase "remotes/svn/BRANCH_NAME"

Clearly that's a lot of file I/O to simply fast forward a branch from a remote branch. In my particular use-case, there will be no local changes to move past the head after the fast forward is done. What would really be ideal would be to do the equivalent of a "git fetch :" which can even be done on a bare repository. I think this is the bottleneck.