logo标签列表

Git适合管理大型（>250GB）内容仓库吗？

gitversion-controlperforce
28

这个 Web 应用程序是一个定制的 CMS，它有几个子应用程序，每个子应用程序都有代码和内容存储在同一目录结构中。由于应用程序框架的架构，代码和内容交织在一起（内容依赖于代码来显示和提供其他功能），因此它们是不可分离的。内容不是作为 BLOB 存储，而是作为文件存储，并且底层数据库用于链接它们。子应用程序的大小范围从 20GB 到 250GB 或更多（这是致命的）。

Web 应用程序将进行一些代码增强（新的子应用程序、错误修复等），同时用户将通过已经上线的系统添加/更新内容。因此，需要一种部署/发布流程，最重要的是需要为代码和内容建议版本控制系统。

Git 出现在这里的原因是它是开源且免费的，易于分支和合并，而且没有集中式，因此没有单点故障。

但是，在网络上进行了一些初步研究后，我发现了一些令人失望的事实，这些事实适用于我们的应用程序 - 对于像我们这样的大型系统使用 Git 是痛苦的（checkout、clone、merge、push、pull），而且对于 DVCS 无知并且大多数是 Windows 用户的开发人员，命令也很复杂（“极客”更加适合）。

Git 没有固定的思维方式，但如果我必须采用集中式方法（在真正的最坏情况下），那么应该怎么做呢？我已经阅读了关于 Perforce 的文章，它被认为是一个稳定的版本控制系统，并且在 Google 中也被使用（我期望这里会有一些争议！）。

请分享、指导和评论您的看法。我真的需要它们。

7
Git并不是为了管理如此大的代码库而设计的（尽管目前正在努力优化它在大文件和大代码库方面的表现）......但我认为，如果使用不支持以文件为单位进行操作（这也有其严重的缺点）或不支持部分检出的版本控制系统，您将会遇到性能问题。您真的需要将这些大文件与代码一起进行版本控制吗？ - Jakub Narębski
我刚刚了解到一个名为monotone的分布式版本控制系统。也许对你来说是一个替代选择。 - Mike Caron
我目前正在处理一个巨大的代码库。我正在研究子模块，看看是否能改善情况。 - Mike Caron
7个回答
27
不错的帖子 :) 这些问题可解决吗？还是Git的设计有问题？ - the_drow
可解决的吗？我不知道。Linus设计git来处理Linux源代码树，这个工作它做得非常好。但那基本上都是文本文件。在我的电脑上，仓库、检出和构建对象总共不到2GB。 - pgs
4
参考文章过时且不太相关。 - Lilith River
6
链接回答并不理想；链接可能会失效，或者像这个一样已经更改了位置。我们应该在回答中至少包含一个简短的描述。 - ANeves
这篇文章已经有八年的历史了，Git和Perforce都有很大的发展。 - sampathsris
16
首先，我不同意Git对非技术用户不适用。是的，有些功能新手不会使用（例如git-send-email）。但也有像TortoiseGit这样的GUI，使简单的事情变得简单。
然而，我认为你的方法是错误的。基本上，你有一个需要经常更改并且需要Joe Bloggs轻松编辑的内容，以及由程序员较少修改的代码。传统的解决方案是使用真正的CMS（例如Alfresco、SugarCRM、Drupal等）或Wiki（MediaWiki、MoinMon等），带有可选插件。请记住，Wiki（和大多数CMS）以“用户友好”的方式允许版本控制内容。
即使您必须保留内部代码，我认为您仍应该想要将内容分离出来，以便可以分开处理。一旦您将代码和内容分开，您的存储库将变得更加合理。然后，您可以使用任何VCS（虽然我不确定您是否正确认为Git本质上对于大型存储库不好）。
4
Matthew，你自己使用过TortoiseGit吗？我没有用过，但我的印象是它仍然处于非常初期的测试阶段（可能还是开发版）。我也尝试在Windows上使用MSYS Git，但感觉很笨重且具有怪癖。没有像TortoiseGit一样可用的图形用户界面，真的不适合非技术人员或胆小者使用。 - Evan
Evan，我也还没有使用过它的机会。然而，它是基于流行的TortoiseSVN，并且正在积极维护。因此，我肯定认为它是可用的。 - Matthew Flaschen
3
我在工作场所简短地尝试了TortoiseGit，因为我们正在评估替代源代码控制系统。我的非技术测试用户对此完全感到困惑和混乱，在几个小时内就变得积极敌对。 - Crashworks
1
@Evan 我在2009年并没有使用TortoiseGit，但是在2014年，它的图形界面变得非常好用，以至于我现在更频繁地使用它而不是在终端中使用git。 - simonzack
@simonzack 很高兴听到这个好消息并且很有用。我必须承认我更喜欢Mercurial（而且TortoiseHg也不错，为了记录）但是下次我需要使用Git时，我一定会看看它的。 - Evan
尽管我们对TortoiseGit充满敬意，但它仍然难以理解，除非你熟悉git的工作方式。对于非技术用户来说，它完全不合适。 - AHelps
10

对于大型存储库而言，git并不适用，不是因为空间问题，而是因为文件数量太多。请阅读我之前写的博客文章了解详情。

根据我的经验，在需要一个可扩展、快速、集中式源代码管理系统时，可以选择使用P4。

Perforce在这个特定问题上非常出色。Pixar将其制作的每一帧电影都存储在Perforce中。这是大量的数据。这个链接是一些Perforce宣传，但你不能否认它所描述的数字。它的扩展能力非常好。https://www.perforce.com/blog/140924/pixars-templar-big-data-asset-management-built-scale - Br.Bill
8
SVN真的是如此糟糕的选择吗？
优点：
- 能够处理大型仓库，例如许多Linux发行版使用它，还有Apache和Sourceforge。 - 有漂亮的GUI前端TortoiseSVN，能够让你的Windows用户感到满意。 - 可以与Windows集成身份验证一起使用，使管理员感到满意。 - 可以采用许多不同的备份策略，根据您的要求（svnadmin hotcopy或dump、svnsync、post-commit hooks）来帮助缓解您的单点故障问题。
缺点：
- 集中式版本控制系统。
免责声明：我从未使用过Perforce，并且作为一个快乐的SVN管理员和用户已经使用了约6年（自v0.29以来）。
我认为我们讨论的文件大小会对任何系统造成问题 - 单个checkout中的250GB文件，无论VCS开销如何，都将在网络上变得非常痛苦。 - Sean McSomething
我同意Sean的观点，但如果他想要一个版本控制系统的解决方案，为什么选择一个专门设计用于源代码而不是任何类型文件的系统呢？ - si618
+1 附加缺点：不太擅长合并。然而，SVN仍然是一个非常好的工具，不应该被随意地抛弃为“不值得”。 - jpmc26
虽然自1.6版本以来合并功能已经得到了改善，而且在1.8版本中也变得更加优秀了，但这种情况仍然存在一些问题。;-) - si618
4
有一个名为git-split的实用脚本，它可以将Git仓库分割成更高效的部分。请参考git-split。
2
-3

我只在学校项目（使用Zend Framework的php网站）中使用过一次git。

我们使用了git，但老师需要将最终版本发布到svn仓库中。

比较检出大小：

git checkout的大小是svn checkout大小的一半。

我的两分钱。

1
当然，它一直都是这样的，因为SVN在您的工作副本中保留了一个基本副本（在.svn文件夹中）。这意味着差异、还原等操作不需要网络。SVN被设计用于处理低带宽通信（比如拨号）。 - si618
5
Git也会保留差异 - 它是分布式版本控制系统，因此您无需联网即可工作。 - stefanB
3
Stefan 是正确的。SVN 不允许你进行任意差异对比，只能对比你最近更新的版本。如果你想要能够离线工作并进行大量修改，你需要一个真正的分布式版本控制系统，而 SVN 不是。 - Matthew Flaschen
1
@stefanB 不，Git不使用差异。对于您使用的每个不同文件，它会记录整个完整文件的记录。这通过使用gzip压缩变得更加高效，但仍然是存储库曾经拥有的每个文件的每个版本，与保留差异有着截然不同的东西。 - jpmc26
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接