[eridius]

If you want to git-svn clone such a massive repository (and either it was truly massive, or your friend's net connection sucked, or he was using an old version of git that had the bug where git-svn slowed down over time), you should copy it to your local computer. git-svn runs significantly faster when it doesn't have to deal with network latency.

Edit: Also, --depth does have a use with git repos, namely if the git repo is accessible only over http, as downloading packs over http is kind of slow.

[pyre]

I'll defer to my friend on this one. He's really heavily into the internals of git and keeping up with the mailinglist. This was about a year ago, and if there was any way to speed up the process I'm sure he tried it. I think that he said it had something to do with the number of branches that have existed over the years in the repo and trying to resolve all of them into git branches.

[barrybe]

I think if he tried today he'd be much more successful. I remember using git-svn a year ago, and it had the problem where it would re-checkout every single file for every branch point, because SVN doesn't really keep track of branch points; a branch is just a "svn copy" of the root dir.

These days, git-svn is much smarter about recognizing a SVN branch, so it doesn't have to re-checkout the whole world.

[bendin]

I recently (less than a month ago) used git-svn to do a conversion of https://svn.dev.java.net/svn/hudson and discovered a few things.

The git-svn clone was not made from the canonical hudson repository, but rather from a svnsync clone hosted on localhost accessed through the svn:// protocol. Nevertheless, the conversion took about three weeks on a 2.6 GHz Core2.

There seems to be a memory leak in git-svn. The size of the git-svn process grew slowly and after about two weeks it was at 1.2 GB resident size, at which point the OS refused to let it fork. Thing is, this was a blessing in disguise. I was able to resume the interrupted clone with a simple "git svn fetch", and it ran much faster with the now radically smaller heap. This, worked so well, in fact, that I got into the habit of interrupting and restarting the process every evening and every morning. A few days later it was done.

The problem seems to be the structure of the Hudson repository. All modules are in a single huge maven-style multi-module build under /trunk, but the branches and tags are not complete copies of trunk, but rather of individual sub-trees of trunk. This does not mesh well with how git sees the world. For git tags and branches are always for the whole repository. This mean,s that git has to work extra hard to figure out what's going in in a repository like Hudson.

Because of the oddball structure of the Hudson repository, its history is not as browsable in git as I might have hoped. Still, it's proved to be an interesting experiment.

Size: the complete history works out to 203MiB (.git/objects) in git, though 754 MiB including all the cruft in .git/svn. In Subversion 1.6 FSFS format the repository is 795 MiB.

[pwmanagerdied]

Just had git-svn acting wonky on me, found your post via Google and now my problem is resolved. :)