有分布式版本控制系统(git, bazaar, mercurial, darcs等)可以处理大于可用RAM的文件吗？
我需要能够提交大型二进制文件(例如数据集、源视频/图像、归档文件)，但我不需要对它们进行比较，只是需要在文件更改时提交并更新。
我大约一年前最后查看了这个问题，显然没有一个候选者允许这样做，因为它们都是为了速度而在内存中进行比较。这让我使用VCS管理代码和其他东西("资产管理"软件或者只是rsync和脚本)来管理大文件，当两个目录结构重叠时，这相当丑陋。
7个回答
13
自从我提出这个问题以来已经过去了3年，但是从2.0版本开始，Mercurial包括了largefiles扩展，它实现了我最初要寻找的功能:
largefiles扩展允许在Mercurial中跟踪大型、不可压缩的二进制文件，而不需要为克隆和拉取分支消耗过多的带宽。将大型文件添加为largefiles时，Mercurial并不直接跟踪这些文件，而是使用校验和来标识它们的修订版本，并跟踪这些校验和。当您克隆存储库或拉取更改集时，旧版本的存储库中的大文件不需要，只会下载更新到当前版本所需的文件。这样可以节省磁盘空间和带宽。
- joelhardi
10
没有免费的分布式版本控制系统支持此功能。如果您需要此功能，您必须实现它。
你可以放弃Git：他们对Linux内核开发用例的原始性能感兴趣。扩展到大型二进制文件会产生性能损失，他们可能永远不会接受这一点。我不知道Mercurial，但是他们似乎在将操作模型与存储模型耦合以提高性能方面做出了类似于Git的选择。
原则上，Bazaar应该能够通过实现针对您的用例进行优化的树/分支/存储格式的插件来支持您的用例。如果内部架构阻止了您，而您发布了有用的代码，我相信核心开发人员会帮助修复内部架构。此外，您可以与Canonical达成特性开发合同。
可能最实用的方法，无论使用哪种具体的DVCS都是构建混合系统：实现一个大文件存储并将对此存储中的blob的引用存储到您选择的DVCS中。
完全披露：我曾是Canonical的雇员，并与Bazaar开发人员密切合作。
- ddaa
2
非常感谢您的回复。去年我曾与一些Hg和BZR开发人员进行了通信，他们所说的与您的评估相似--BZR的人说“嗯，这很有趣，你可以编码”，我们考虑过，但与仅使用SVN或黑客攻击相比，时间成本不合理... - joelhardi
我们需要一些混合解决方案，可以提交文件哈希值等内容。分布式版本控制系统项目似乎都是以自由开源软件开发为主要驱动力，而不像SVN和商业产品那样考虑更广泛的用途。Hg和BZR都是很棒的项目，可惜对我来说不太适用。 - joelhardi
4
是的，Plastic SCM是一款分布式版本控制系统，并且它可以以4Mb为块管理大文件，因此不会因需要完全加载文件到内存中而受到限制。在此处查找有关DVCS的教程：
http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html
- pablo
2
谢谢你的提示，我已经不再处理这个问题了，但是你的回答对于阅读此帖子的人将是有用的。从他们的网站上看，由于它是C#/Mono，因此Plastic SCM似乎支持Linux/BSD/OS X。然而，他们使用SQL作为后端存储，因此我仍然怀疑"大文件"的支持/性能... 我最初指的是一些1-10 G范围内的DV视频源之类的东西。像这样从SQLite中分块/差异可能会起作用，但效果如何？如果有任何人有相关经验，那将是很好的信息补充。 - joelhardi
1嗨，实际上我们刚刚用2GB文件进行了另一项测试...这完全是关于在数据库中存储4MB blob，使用SQL Server、Firebird甚至MySQL都非常快...Plastic还有一个选项可以将文件保存在fs上。 - pablo
3
BUP可能是你正在寻找的东西。它是作为git功能的扩展来进行备份构建的，但实际上它们是相同的东西。它将文件分成块并使用滚动哈希使文件内容可寻址/实现有效存储。
链接如下：
链接如下：
- Catskul
2
我认为在任何形式的版本控制系统中存储二进制文件都是低效的。更好的想法是将引用二进制对象的元数据文本文件存储在代码库中。
- pobk
2
谢谢您的回复。但是，是的，我确实是指我所问的。我确实需要对大文件进行版本控制 - 还有另一类软件“企业资产管理”，它基本上是用于媒体资产的服务器上的VCS / Aperture / Version Cue。 - joelhardi
1我想我试图表达的观点是（恐怕是因为咖啡不够），大多数版本控制系统并不是为了对二进制对象进行版本控制而设计的。正如你所说，它们进行内存差异比较并存储增量......对于二进制文件来说，版本控制几乎没有意义，因为它们是固有的。 - pobk
1
它必须分布吗？据说Subversion相对于较新的分布式版本控制系统的一个巨大优势是其卓越的处理二进制文件的能力。
- mattikus
1
谢谢您的回答，但是确实如此。我同意SVN很好地处理二进制文件 - 这也是我感到困惑的部分，之前测试的版本控制系统似乎认为在400 MB文件上崩溃是可以接受的行为。 - joelhardi
0
我得出的结论是，在这种情况下最好的解决方案是使用ZFS。
是的，ZFS不是DVCS，但：
- 您可以通过创建新的文件系统为存储库分配空间
- 您可以通过创建快照来跟踪更改
- 您可以将快照（提交）发送到另一个ZFS数据集
- Eugene Bezrouchkin
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接