[pyre]

--depth does have some benefits... one of my friends tried to do a 'git svn clone' of his work's svn repo... he gave up after the process had been running for a full 3 or 4 weeks.

That said --depth doesn't have too much use when it comes to native git repos though. Unless you have a ton of binary files in the repo and don't want the full history of all of them...

[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. :)

[silentbicycle]

None of _why's projects were that big, so in this case it's kind of a moot point.

[pyre]

Right, but the parent post didn't seem limited to only _why's repos.

[gamache]

Not true. Hpricot and Syck are in heavy use.

[silentbicycle]

I meant big in the lines-of-code sense, not in how much they're used. (looks like I missed the edit window.)

[joeycfan]

True - I use hpricot every day.