0

在我对 SVN 的 GIT 性能测试中,我发现 GIT 肯定比 SVN 快。现在看看性能是否随着项目大小(更多版本)的增加而保持良好,我将 Perl 项目与 45K 提交分叉并将其存储在我们的服务器中。我只用最新版本创建了另一个仓库。第一个 repo 在大约 140 秒内克隆,第二个 repo 在大约 19 秒内克隆了一个提交。这有点令人担忧。现在随着历史的发展,它失去了相对于 SVN 的性能优势。这个结论对吗?

此外,我在这里阅读了许多帖子/博客,它们表达了对具有大量存储库和大量二进制文件的 GIT 性能的担忧。由于这些帖子至少有 1 年的历史,你认为这仍然是 GIT 的一个问题吗?

是的,解决这些缺点的一种方法是使用浅克隆。具有 --depth 1 的浅层克隆与从 repo 中克隆几乎相同的时间,只有 1 次提交。但是浅克隆手册页谈到了限制。“创建一个将历史记录截断为指定修订数量的浅层克隆。浅层存储库有许多限制(您不能克隆或从中获取,也不能从中推送或推入),但如果您只对以下内容感兴趣,就足够了一个历史悠久的大型项目的近期历史,并希望将修复作为补丁发送。” 这真的是一个限制还是文档不是最新的?我已经用我的测试存储库对其进行了测试,但似乎能够很好地推送到中央存储库。

4

1 回答 1

0

大型二进制文件的 Git 行为更糟。但是,有 Git LFS 来支持这些要求。

当您不小心将大型二进制文件推送到存储库时,就会出现困难。尽管您稍后在同一分支上删除它们,但历史记录保持不变并且存储库变得庞大。克隆和 git 的任何内部操作变得非常缓慢。因为它不是为二进制文件(尤其是大型二进制文件)设计的。

这可以防止最初正确设置 .gitignore 文件。

通常,即使在大型存储库中,推/拉/状态也非常快。(即你并不总是克隆)

开始前好好阅读

于 2017-03-02T10:44:15.790 回答