You can do a shallow clone in any reasonable versioning system: http://stackoverflow.com/questions/6941889/is-git-clone-dept...

but then you lose the ability to git bisect, blame etc, which is the root comment's advantage of doing git.

I've worked on a project where the git repository was man gigabytes - because at some point someone decided to put some binary files in the repository, which periodically got updated - now years on the repository's about 10GB, and you can't really delete the stuff clogging it up without rewriting history from years prior and making the 200 devs life hell.

Importantly, you do need all that history, because there are commits from the same time that are relevant.

But then git blame or bisect don't really work anymore.

I'm not too sure what could be realistically done to implement offline bisect without getting the all the history you care about.

One approach would be to query the server for these operations. And unlike what happens in Git, where blame is an O(N) operation, a centralized server is free to spend some extra storage to add some caches or indexes to make these searches faster.

Querying the server rarely works when you're offline.

It may work well enough.

And if you never do, even after fifteen years working dozens of different project? Including a few projects that have run for most of those fifteen years?

I agree that git is weak for binaries, but the only binaries I need to keep in it are a few images and installer - nothing that has many versions, nothing that causes me problems. Similarly, a lot of open source software is mostly made up of code, not blobs.

As for distributed work, even when I'm the only developer on a project, it helps not to have to worry about a central server, especially if I'm on-site. It's also hugely faster than SVN ever was.

9 Gbit really aint that much.

Ours is 370GB. git-svn typically falls over and dies on that, if you're brave enough to try.

370GB is peanuts. Try keeping a centralized version control server up and operating when you have dozens of terabytes and thousands of developers.

Better to abandon the ultimately doomed monolithic repo scheme and tool your build and deployment systems to expect a multi-repo ecosystem. Then allow your teams to create their own repos on the fly, one for each individual project if they please. Once you reach that point, there is little reason to not use a more sensible VCS like hg or git.