An up-to-date snapshot of my source tree at work is several GB. The whole Perforce repo is probably 100GB. Most of that is vendor libraries. For example, every so often we update to a new version of the Boost C++ libraries and pre-build it for most common platforms. This amounts to a GB or two. This is easier on the other developers and it makes the process more repeatable for QA.

One of the great things about Perforce is that it's normal practice to map only selected subtrees of the repo. So I have several workspaces going at any one time.

As much as I am impressed with git's speed, this would not work with git. I used to try to managing Boost's vendor drop as a git repo. I now just keep my notes in there about how to download and build it locally.

I think the idea is to use git submodules for vendor libs. Anything you're not modifying and a 3rd party is maintaining should be a submodule; that way you don't keep any of those changes in the repo.

When a new vendor release comes out, we build it with our "official" compiler settings for the different platforms, branch the headers from the source and combine them into a convenient "SDK" tree, sometimes tweak something here or there, and update the document. Amounts to several GB being checked in from multiple machines. Occasionally a developer (usually me, but others too) needs to commit changes back to our central repo vendor tree.

I suppose we could do that into a separate repository and then define parts of that as a git submodule.

Hmm, reading http://book.git-scm.com/5_submodules.html I don't see how to do that with git without using 100 GB on the library dev machines.

I don't think I've ever seen a situation where that's true. And I've converted a lot of repositories (I maintain the svn2git project). SVN has its metafiles, but git has the full history locally. In all but the most trivially-sized projects, the git clone is bound to be larger. For larger projects it can be several orders of magnitude larger.

I have here a svn checkout of the FreeBSD HEAD branch, using 1550 MB disk in 199443 files.

I also have a git checkout of the same thing, which includes the history of the HEAD but not the other branches. It is 1234 MB in 54823 files.

Git also has much more efficient storage mechanism.

I'm aware of that and didn't imply otherwise. But the storage mechanism is for the history, not for the materialized files in the working directory. That's going to be the same for either git or SVN, since they're checked out. So you're talking about comparing git's history DB to SVN's metadata files. The metadata files are effectively constant cost whereas the git history grows with each checkin. They get quite large.