It's not terribly great when you have large files in the system. You end up with a huge repository on disk as those files change. But more importantly, you can't do a partial checkout of a particular path. I think I read that that'll be coming to git, which would be fantastic.
Actually, you can, with sparse checkouts. They've been in since git 1.7, if I remember correctly. It's not very user friendly yet, and you do retain the entire path from the repository root. See for example here: http://vmiklos.hu/blog/sparse-checkout-example-in-git-1-7
I've used centralized SCCSs for years and years. I guess I don't see why you can't use git as one, just have everybody agree to push to a central repository on a server.
There is the issue of the size of the local copy, but it doesn't seem to be a big deal in practice. I just don't check in the heavyweight frameworks as vendor drops into the same repos as I use for my own, smaller, codebase.
Granted, I'm scared to death of ending up in a merge-gone-wrong hell situation trying to do stuff that I'm very familiar with in Perforce. But I'm happy being a git newb taking baby steps a bit longer.
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.
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'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.
Which means that if a developer wants to do do git-like stuff (say sharing a patch with a single other developer or committing a day's unfinished work to an alternate backup site), then he's just going to have to work around the SVN tool to do it.
The tool should exist to serve the people producing the work, not the other way around.
The more important question is: what are developers really missing when they have to use svn to hack ASF's code in comparison to using git? (leaving github out of the equation, it is not git) You can hack locally to your heart's content and in case you want to contribute, you can diff and contribute.
Part of the drive of open source is bootstrapping better ways of doing things. We could all likely do our jobs to some degree running Windows 95, but who wants to? Git improvements over SVN include increased performance, cheap branching, more detailed tracking of changes, the ability to code offline (not a huge deal, but it certainly has made traveling more fun for me), and DVCS collaboration capabilities.
What you describe is the original use case for git: pull-based community development. So I can only conclude that you don't see a problem because you've never actually done it.
All server based vcs are push based. Certainly they can be used pull-based, where others diff code, send the patch, and a committer then integrates and commits. Git, on the other hand does two things differently. 1) it makes it vastly easier to create, submit, and integrate patches (because it was designed for it) and 2) it makes it vastly easier for the people making the patches, who don't have commit privs, to maintain their changes in their own repo, while still syncing with the master.
svn does not offer these features, which means that when you dont have commit privs, its a PITA to track and maintain your own version. I'll say that again: it makes it massively frustrating to maintain your own version. The result is that people dont, and the number of potential hackers is vastly reduced.
git, like svn, allows a small community, such as ASF, to manage and control a project - addressing legal and operational concerns. committers can push just as easily as with svn. but in addition, each committer can (if they so choose) also maintain relationships with a much greater community, each member of which can hack away on their own with a fully synced, fully versioned repo of their own. hackers get their own repo. committers have a really robust system for integrating patches.
If ASF wishes to do no more than have a small number of committers working on a project then indeed, svn suffices. its "good enough". the point of mikeal's post is that this is missing out hugely on the vast army of hackers.
I said in an earlier post that I had no skin in the game. that's true. now. i used to track tomcat. but it was such a pain in the arse to handle merging my code with the official code that I gave up. it just wasnt worth it. git would have solved every problem I had. perhaps by now I would be a committer on the tomcat project. who knows? svn made that a certain "no".
an organization like ASF needs a finite number of committers. git allows keeping that group small, yet engaging a much greater community.
but as mikeal says, its not about svn vs git. its about the mindset that sees no need for git because it sees no need for more than just committers.
Such as?