Is Git recommended for large (>250GB) content repositories

Question

The web-application is a custom-built CMS which has several sub-applications and each one of them has code and content residing in the same directory structure. Due to the a

Answer 1

I used git only once for a school project (php site with Zend Framework).

We used git but the teacher needed to have the final release on a svn repo.

Comparing the checkout size:

git checkout was half the size of MB of the svn checkout.

My two cents.

Answer 2

There's a utility script called git-split that chops up a git repo to make it more efficient.

Answer 3

I just happened to be reading this blog post not one minute ago. It's a bit of a rant about the scalability of git.

Edit: Eight years later, and Git has Large File Storage (LFS), and Microsoft is open sourcing Git Virtual File System (GVFS) so they can use git to develop Windows.

Answer 4

Is SVN really such a bad option?

PROS:

• Can handle large repositories e.g. many linux distro's use it, also Apache, Sourceforge
• Has nice GUI front end with TortoiseSVN to keep your windows users happy
• Can be used with windows integrated authentication to keep admins happy
• Many different backup strategies can be adopted based on your requirements (svnadmin hotcopy or dump, svnsync, post-commit hooks) to help ease your single point of failure concern.

CONS:

• Centralised VCS

Disclaimer: I've never used Perforce and have been a happy SVN admin and user for ~6 years (since v0.29)

Answer 5

Microsoft just released Git Virtual File System (GVFS) specifically to handle large code base with git. More details here at msdn

Also Microsoft hosts the Windows source in a monstrous 300GB Git repository

I do not have any experience using GVFS.

Answer 6

First, I don't agree that Git is inappropriate for non-technical users. Yes, there are certain features that newbies won't use (e.g. git-send-email). But there are also GUIs like TortoiseGit to make simple things simple.

However, I think you're approaching things the wrong way. Basically, you have content that will change frequently and needs to be editable very easily by Joe Bloggs, and code that will be modified less frequently by coders. The traditional solution is to use a real CMS (e.g. Alfresco, SugarCRM, Drupal, etc. or a Wiki (MediaWiki, MoinMon, etc.), with optional plug-ins. Keep in mind, wikis (and most CMSes) allow versioning of content, in a "user-friendly" way.

Even if you must keep your in-house code, I think you should still want to extricate the content so they can be treated separately. Once you have the code and content separate, your repository will be a more reasonable size. Then, you can use whatever VCS you want (though I'm not really sure you're right that Git is inherently bad for large repos).