Actually, it's not really that bad. The problem was that with Git or Hg, when you fetch you get every version of every file for the whole history of the projec

Actually, it's not really that bad. The problem was that with Git or Hg, when you fetch you get every version of every file for the whole history of the project. Which means if you've had a lot of big files, you get ALL of them. Also, they don't delta compress well, so that can be a lot, much of which you may never need again, so it's inefficient. For most projects, this isn't a big deal, but if you have a bunch of large texture files or video that MUST be in the project (game development, perhaps), this can be an issue. Subversion is "better" at this only because it does shallow checkouts - it only gets the last version of the project. It is still ludicrously inefficient in it's transfer protocol. Git can actually do this type of development fine - if you do 'git clone --depth=1 [url]' it will also do a shallow clone (just the last commit and it's associated content) and will transfer the data much more efficiently than SVN. In the past you couldn't then commit to that repo, which was the issue, but in newer versions you can. You can also later deepen the repository if you want. It is not an often used feature, but I think it brings Git pretty close to on-par with SVN for large projects, if not better in many respects.