二进制增量存储

我正在寻找一种二进制增量存储解决方案来版本化大型二进制文件（数字音频工作站文件）

使用 DAW 文件时，与用于存储原始数据（波形）的大量数据相比，大多数更改（尤其是在混音结束时）都非常小。

如果我们的 DAW 文件有一个版本控制系统，让我们可以回滚到旧版本，那就太棒了。

系统只会保存每个版本的二进制文件之间的差异（diff）。这将为我们提供从当前版本更改为先前版本的指令列表，而无需存储每个版本的完整文件。

当前是否有任何版本控制系统可以执行此操作？我读过 SVN 使用二进制差异来节省存储库中的空间...但我也读到它实际上并没有对二进制文件仅这样做文本文件...不确定。有任何想法吗？

我现在的行动计划是继续研究现有的工具，如果不存在，则熟悉 c/c++ 读取二进制数据并自己创建工具。

我无法评论通过网络提交大文件时可能存在的可靠性或连接问题（一篇引用的帖子暗示了问题）。但这里有一些您可能会觉得有用（或没有用）的经验数据。

我今天一直在做一些测试，研究磁盘寻道时间，因此手头有一个相当好的测试用例。我发现你的问题很有趣，所以我对我正在使用/修改的文件进行了快速测试。我创建了一个本地 Subversion 存储库，并向其中添加了两个二进制文件（大小如下所示），然后在对文件进行更改后提交了几次。较小的二进制文件 (.85 GB) 每次只是将数据添加到其末尾。较大的文件 (2.2GB) 包含表示由“随机”整数数据组成的 b 树的数据。在提交之间对该文件的更新涉及添加大约 4000 个新的随机值，因此修改的节点会在整个文件中均匀分布。

以下是原始文件大小以及提交后本地 Subversion 存储库中所有文件的大小/数量：

file1    851,271,675  
file2  2,205,798,400 

1,892,512,437 bytes in 32 files and 32 dirs

第二次提交后：

file1    851,287,155  
file2  2,207,569,920  

1,894,211,472 bytes in 34 files and 32 dirs

第三次提交后：

file1    851,308,845  
file2  2,210,174,976  

1,897,510,389 bytes in 36 files and 32 dirs

提交有点冗长。我没有仔细注意，因为我正在做其他工作，但我认为每一项可能需要 10 分钟。检查具体修订版大约需要 5 分钟。我不会根据我的结果以某种方式提出建议。我只能说它似乎工作正常并且没有发生错误。文件差异似乎运行良好（对于这些文件）。