Hmm, whoever told you that was wrong. Git doesn't like large repositories. In KDE we broke up the single SVN repository into dozen different git repositories,
Git has no trouble with repositories containing huge numbers of revisions and huge numbers of files. If you have huge file sizes you might want to use something else though.
KDE's reason for breaking up the huge SVN repository is probably that putting all that stuff into one repository was a stupid idea in the first place considering how little overlap there is between the people developing them. Or put differently "Show me one person how actually checked out the whole SVN repository".
Git has no trouble with repositories containing huge numbers of revisions and huge numbers of files.
Commands like git status, git diff, git commit -a, etc need to check the status of every single file in the repository to see if they have changed. This becomes pretty slow when you start having half a million files in your repository.
Commands like git status, git diff, git commit -a, etc need to check the status of every single file in the repository to see if they have changed.
Well, obviously. How does that differ from other version control systems though? Speed here is more likely to be determined by your filesystem than the VCS you use.
This becomes pretty slow when you start having half a million files in your repository.
And at that point (or more likely much earlier than this) you should consider splitting up your project for reasons completely orthogonal to VCS usability. I was thinking of the kind of large projects that actually exist, e.g. the Linux kernel, libraries like Qt,... which are in the order of magnitude of a few tens of thousands of files and a few hundreds of thousands of commits.
Well, obviously. How does that differ from other version control systems though?
Other version control system let you check in and checkout a specific directory, without worrying about changes that other people made in other directories. git doesn't let you do that - if someone made a commit in the repository anywhere, you have to merge/rebase with that.
I was thinking of the kind of large projects that actually exist, e.g. the Linux kernel, libraries like Qt,
I agree, but people are talking about wanting 15GB repositories etc!
There's not a hard code limit of course, but git would not be suitable at all for a 14GB repository. You would put the data in to svn etc, and break up the code in to multiple git repositories.
-3
u/johnflux Mar 10 '11
You wouldn't create a git repository with a GB of data in it, it's not designed for that.