5

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

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

为我们的 DAW 文件提供版本控制系统会很棒，让我们能够回滚到旧版本。

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

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

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

4

4 回答 4

5

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

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

于 2011-08-30T17:23:41.697 回答
2

Subversion 可能会起作用，具体取决于您对大型的定义。这个问题/答案说只要您的文件小于 1 GB，它就可以正常工作。

于 2011-08-29T18:45:59.053 回答
2

Subversion 将对二进制文件和文本文件执行二进制增量。Subversion 只是无法为二进制文件提供人类可读的增量，也无法帮助合并二进制文件中的冲突。

于 2011-08-29T20:23:49.247 回答
-1

git压缩（您可能需要git gc手动调用），并且看起来非常好：

$ git init
$ dd if=/dev/urandom of=largefile bs=1M count=100
$ git add largefile
$ git commit -m 'first commit'
[master (root-commit) e474841] first commit
 1 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 largefile
$ du -sh .
201M    .
$ for i in $(seq 20); do date >> largefile; git commit -m "$i" -a; git gc; done
$ du -sh .
201M    .
于 2011-08-30T17:37:45.920 回答