我问这个问题已经3年了，但是，从2.0版本开始，Mercurial包括largefiles扩展名，它实现了我最初想要的功能：

largefiles扩展名允许在Mercurial中跟踪大型、不可压缩的二进制文件，而不需要过多的克隆和拉取带宽。作为大文件添加的文件不会被Mercurial直接跟踪；相反，它们的修订是通过校验和来识别的，Mercurial会跟踪这些校验和。这样，当您克隆存储库或拉入变更集时，不需要存储库旧版本中的大文件，只下载更新到当前版本所需的文件。这样既节省了磁盘空间又节省了带宽。

没有一个免费的分布式版本控制系统支持这一点。如果你想要这个功能，你就必须实现它。

您可以忽略git：他们对Linux内核开发用例的原始性能感兴趣。他们不太可能在扩展到巨大的二进制文件时接受性能权衡。我不知道Mercurial，但他们似乎做出了与git类似的选择，将他们的操作模型与存储模型结合起来以提高性能。

原则上，Bazaar应该能够使用一个插件来支持您的用例，该插件实现树/分支/存储库格式，其磁盘存储和实现策略针对您的用例进行了优化。如果内部体系结构阻止了您，并且您发布了有用的代码，我希望核心开发人员将帮助修复内部体系结构。此外，您还可以与Canonical签订一份功能开发合同。

无论具体的DVCS如何，最实用的方法可能是构建一个混合系统：实现一个巨大的文件存储，并将该存储中对Blob的引用存储到您选择的DVCS中。

全面披露：我是Canonical的前员工，曾与Bazaar开发商密切合作。

Yes, Plastic SCM. It s distributed and it manages huge files in blocks of 4Mb so it s not limited by having to load them entirely on mem at any time. Find a tutorial on DVCS here: http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html

BUP可能就是你想要的。它是作为git备份功能的扩展而构建的，但实际上是一样的。它将文件分成块，并使用滚动哈希使文件内容可寻址/进行高效存储。

• https://github.com/bup/bup
• http://blogs.kde.org/node/4440

我认为在任何形式的版本控制系统中存储二进制文件都是低效的。

更好的想法是将元数据文本文件存储在引用二进制对象的存储库中。

必须分发吗？据推测，颠覆对较新的分布式VCSE的一大好处是它处理二进制文件的卓越能力。

我得出的结论是，在这种情况下，最好的解决方案是使用ZFS。

是的，ZFS不是DVCS，但：

• You can allocate space for repository via creating new FS
• You can track changes by creating snapshots
• You can send snapshots (commits) to another ZFS dataset