有分布式版本控制系统(git, bazaar, mercurial, darcs等)可以处理大于可用RAM的文件吗?
我需要能够提交大型二进制文件(例如数据集、源视频/图像、归档文件),但我不需要对它们进行比较,只是需要在文件更改时提交并更新。
我大约一年前最后查看了这个问题,显然没有一个候选者允许这样做,因为它们都是为了速度而在内存中进行比较。这让我使用VCS管理代码和其他东西("资产管理"软件或者只是rsync和脚本)来管理大文件,当两个目录结构重叠时,这相当丑陋。
有分布式版本控制系统(git, bazaar, mercurial, darcs等)可以处理大于可用RAM的文件吗?
我需要能够提交大型二进制文件(例如数据集、源视频/图像、归档文件),但我不需要对它们进行比较,只是需要在文件更改时提交并更新。
我大约一年前最后查看了这个问题,显然没有一个候选者允许这样做,因为它们都是为了速度而在内存中进行比较。这让我使用VCS管理代码和其他东西("资产管理"软件或者只是rsync和脚本)来管理大文件,当两个目录结构重叠时,这相当丑陋。
自从我提出这个问题以来已经过去了3年,但是从2.0版本开始,Mercurial包括了largefiles扩展,它实现了我最初要寻找的功能:
largefiles扩展允许在Mercurial中跟踪大型、不可压缩的二进制文件,而不需要为克隆和拉取分支消耗过多的带宽。将大型文件添加为largefiles时,Mercurial并不直接跟踪这些文件,而是使用校验和来标识它们的修订版本,并跟踪这些校验和。当您克隆存储库或拉取更改集时,旧版本的存储库中的大文件不需要,只会下载更新到当前版本所需的文件。这样可以节省磁盘空间和带宽。
没有免费的分布式版本控制系统支持此功能。如果您需要此功能,您必须实现它。
你可以放弃Git:他们对Linux内核开发用例的原始性能感兴趣。扩展到大型二进制文件会产生性能损失,他们可能永远不会接受这一点。我不知道Mercurial,但是他们似乎在将操作模型与存储模型耦合以提高性能方面做出了类似于Git的选择。
原则上,Bazaar应该能够通过实现针对您的用例进行优化的树/分支/存储格式的插件来支持您的用例。如果内部架构阻止了您,而您发布了有用的代码,我相信核心开发人员会帮助修复内部架构。此外,您可以与Canonical达成特性开发合同。
可能最实用的方法,无论使用哪种具体的DVCS都是构建混合系统:实现一个大文件存储并将对此存储中的blob的引用存储到您选择的DVCS中。
完全披露:我曾是Canonical的雇员,并与Bazaar开发人员密切合作。
它必须分布吗?据说Subversion相对于较新的分布式版本控制系统的一个巨大优势是其卓越的处理二进制文件的能力。
我得出的结论是,在这种情况下最好的解决方案是使用ZFS。
是的,ZFS不是DVCS,但: