version-control - 二进制增量存储

Question

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

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

为我们的 DAW 文件提供一个版本控制系统会很棒，允许我们回滚到旧版本。

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

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

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

Answer 1

我无法评论通过网络提交大文件时可能存在的可靠性或连接问题(一个引用的帖子暗示了问题)。但这里有一些经验数据，您可能会发现它们有用(或没有用)。

我今天一直在做一些测试，研究磁盘寻道时间，因此手头有一个相当不错的测试用例。我发现你的问题很有趣，所以我对我正在使用/修改的文件进行了快速测试。我创建了一个本地 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 分钟。我不会根据我的结果以一种或其他方式提出建议。我只能说它似乎工作正常并且没有发生错误。并且文件差异似乎运行良好(对于这些文件)。