Converting folders separately and combining the git repositories should work in principle, but would be very tricky to get right, so I'd advise against it.
At any rate, 32,000 commits is not that much, and git-svn
should be able
to handle it, though it might take a day or so.
However, if it is too slow, you'll have to experiment a bit.
Things that can slow down git-svn's clone operation
SVN repository speed
First, of course, is the SVN repository speed. Try creating a local mirror of the SVN repository (using svnadmin dump/load
or svnsync
), and clone that.
"Subdirectory" branches/tags
Branches or tags (which git treats identically) can become a problem. Whenever git-svn clone
encounters an SVN branch that is not a copy of trunk, but of a subdirectory, it will re-read the whole SVN history of the branched subdirectory since its creation (you can see this in the output of git svn clone
, and here is an explanation by the author). This means that the speed of a clone is not only proportional to the number of SVN revisions n
, but also to the number of "subdirectory branches" b
, i.e. if b = 10
, the clone may take up to 10 times longer.
There is no easy solution to this problem. First, you could try cloning without tags - normally a tag just revers to an SVN revision ID, so having a list of tags should be enough (unless you have tags that contain changes... ugh). If that's not enough, maybe also skip some branches... though'd you'll have to decide if there are any you can do without.
The extreme solution would be to use option --no-follow-parent
. This will prevent git svn
from re-reading a branch from the beginning. The branches will still be read, however, they will not be connected to the rest of the history. That still shows you what was done there, but makes them very difficult to merge back.
Finally, note that you can interrupt and resume the clone process. To resume, run git svn fetch
.
You might need several restarts, but with a bit of patience the clone should go through.