具有大量文本文件的Web界面的Git性能? [英] Performance of Git with a web interface for very many text files?

问题描述

我大约有500,000个文本文件，这些文件的大小大约为10 KB至200KB(某些特殊文件可能多达10MB)，总大小约为3GB.

I have around 500,000 text files which are mostly around 10 KB to 200KB (some particular ones could be up to around 10MB) and the total size is around 3GB.

我想知道git的性能如何管理大量文件?人们曾经托管过如此规模的回购协议吗?

I'd like to know how would the performance of git be to manage so large amount of files? Has people ever been host a repo with such scale?

如果像GitHub一样提供Web界面，并支持在线编辑文件，那么提交更改会花费很长时间吗?当人们将更改推送到服务器时，它会阻止吗?

If a web interface is served like GitHub, and supports editing file on line, would it take long to commit the change? Would it block when people push changes to the server?

git是否需要特定设置才能在服务器上正常运行?

Are there specific settings required for git to perform well on the server?

推荐答案

正如我在"中提到的那样，数量和大小)?"和"带有大文件的git "，则git不适合用于大型仓库

As I mention in "What are the file limits in Git (number and size)?" and "git with large files", git is ill-suited to huge repo.

大量 个文件可以工作(前提是您在初次导入后一次更改/添加的次数不多)

A large number of files could work (provided you don't change/add too many at a time, past the initial import)

但是由于packfile索引(.idx)文件的结构以及在这些索引中查找特定文件的开销，大尺寸文件是有问题的.

But a large size is problematic due to the packfile indexes (.idx) files structure, and the cost of looking for a specific file in those indexes.

Plus GitHub可能会强制执行其软限制配额如果您尝试在他们的服务器上存储一个巨大的仓库.

Plus GitHub is likely to enforce its soft limit quota if you try to store a huge repo on their servers.

最好将该仓库拆分为一组连贯的较小仓库(您仍然可以通过 子模块 )

It is best to split that repo in a collection of coherent smaller repo (that you can still group into one through submodules)

这篇关于具有大量文本文件的Web界面的Git性能?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！