Git如何既节省空间又快速?

^{这个问题在评论中得到了回答}

存储库大小

.svn

其次,git使用以下技术使存储库更小:

• 文件的每个版本只存储一次;这意味着,如果在10次修订(10次提交)中只有某个文件的两个不同版本,git只存储这两个版本,而不是10个。
• 对象(和delta,见下文)被压缩存储;编程中使用的文本文件压缩效果非常好(约为原始大小的60%,或压缩后大小减小40%)

性能(运行速度)

首先,任何涉及网络的操作都比本地操作慢得多。因此,例如将工作区的当前状态与其他版本进行比较,或者获取一个日志(一个历史记录),在Subversion中涉及到网络连接和网络传输,在Git中是本地操作,在Subversion中当然要比在Git中慢得多。顺便说一句,这就是 集中化 版本控制系统(使用点对点工作流),不仅在Subversion和Git之间。

第二,如果我理解正确的话,现在的限制不是CPU而是IO(磁盘访问)。因此,由于压缩而必须从磁盘读取较少数据(并且能够将其映射到内存中)所获得的收益有可能克服必须解压缩数据所带来的损失。

第三,Git的设计考虑到了性能(参见。 GitHistory Git Wiki上的页面):

• core.trustctime 配置变量)。
• pack.depth ,默认为50。Git有增量缓存以加快访问速度。有(生成的)packfile索引用于快速访问packfile中的对象。
• Git注意不要接触它不需要的文件。例如,当切换分支或回放到另一个版本时,Git只更新更改过的文件。这种理念的结果是Git只支持非常小的关键字扩展(至少是现成的)。
• own version 属于 LibXDiff 库,现在也用于diff和merge,而不是调用外部diff/外部合并工具。
• Git试图最小化 延迟 ,意思是好的 性能。例如,它输出“的第一页” git log “尽可能快,而且你几乎马上就能看到,即使创造完整的历史需要更多的时间;它不会等到生成完整的历史之后再显示它。
• 在获取新更改时,Git会检查您与服务器有哪些共同的对象,并以瘦packfile的形式只发送(压缩的)差异。诚然,Subversion在更新时也只能发送差异(或者默认情况下是这样)。

我不是Git黑客,我可能错过了Git用来提高性能的一些技术和技巧。但是请注意,Git大量使用POSIX(如内存映射文件)来实现这一点,因此在MS-Windows上获得的收益可能没有那么大。

不是一个完整的答案,但是 those comments (来自 AlBlue

; 我希望我没有暗示那不是事实。然而,在实践中,通常情况下,Git存储库比同等的SVN存储库占用更少的磁盘空间。
你提到的一件事是Apache的单一SVN存储库,它显然是巨大的。然而,人们只需看看 git.apache.org .

我可以退房了 git://git.apache.org/abdera.git . 在磁盘上,它消耗了28.8Mb。
然后我检查了SVN版本 http://svn.apache.org/repos/asf/abdera/java/trunk/ ,消耗了34.3Mb。

如果使用 du -sh

ApacheAbdera的Git版本可以让我处理当前版本之前的任何历史版本;SVN将只有当前签出版本的备份。但它占用的磁盘空间更少。

你可能会问,怎么做?

首先,SVN创建了更多的文件 . SVN签出有2959个文件;相应的Git存储库有845个文件。

.svn 在每个层次结构的文件夹中,Git repo只有一个 .git 顶级存储库 . 这意味着(除其他外)从一个dir重命名到另一个dir在Git中的影响要比在SVN中小得多,值得赞赏的是,SVN对Git的影响已经相对较小了。

第三, . 进入任何 .svn/text-base 目录,您将找到(基本)文件的未压缩副本。
.git/objects/pack/
因此,在本例中,存储库的大小(大致)与当前签出的代码的大小相同,尽管我不希望总是这样。

不管怎样,你是对的,历史可以增长到超过当前签出的总大小;但是由于SVN的工作方式,它必须接近两倍的大小才能产生很大的不同。即便如此,磁盘空间的减少并不是使用DVCS的主要原因;当然,这对某些事情来说是一种优势,但这并不是人们使用它的真正原因。

svnadmin dump/filter/load .)

至于速度方面,我在报告中提到了 How fast is git over subversion with remote operations? “回答(像 Linus said in its Google presentation :(此处释义)“任何涉及网络的事情都会扼杀演出”)

以及 GitBenchmark document 提及者 Jakub Narębski 是一个很好的补充,即使它不直接处理颠覆。

本文还提到了其他Git基准测试 SO question .