Двоичное хранилище дельты

Question

Я ищу бинарное дельта-решение для хранения больших двоичных файлов (файлы цифровых аудио рабочих станций)

При работе с файлами DAW большинство изменений, особенно ближе к концу микса, очень мало по сравнению с огромным объемом данных, используемых для хранения необработанных данных (волн).

Было бы замечательно иметь систему управления версиями для наших файлов DAW, позволяющую нам откатиться к более старым версиям.

Система будет сохранять только разницу между двоичными файлами (diff) каждой версии. Это даст нам список инструкций по переходу с текущей версии на предыдущую без сохранения полного файла для каждой отдельной версии.

Существуют ли в настоящее время системы управления версиями, которые делают это? Я читал, что SVN использует бинарные различия для экономии места в репозитории ... Но я также читал, что на самом деле это не так, для бинарных файлов только текстовые файлы ... Не уверен. Есть идеи?

Мой план действий на данный момент заключается в том, чтобы продолжить исследование ранее существовавших инструментов, и, если таковых не существует, освоиться с c / c ++, читая двоичные данные и создавая инструмент самостоятельно.

Answer 1

Я не могу комментировать проблемы с надежностью или подключением, которые могут существовать при фиксации большого файла по сети (одна ссылка ссылалась на проблемы). Но вот немного эмпирических данных, которые вы можете найти полезными (или нет).

Сегодня я проводил некоторые тесты, изучая время поиска диска, и поэтому у меня был достаточно хороший тестовый пример. Я нашел ваш вопрос интересным, поэтому я провел быструю проверку с файлами, которые я использую / изменяю. Я создал локальный репозиторий Subversion и добавил в него два бинарных файла (размеры указаны ниже), а затем зафиксировал файлы пару раз после внесения в них изменений. В бинарный файл меньшего размера (0,85 ГБ) просто добавлялись данные каждый раз в конец. Файл большего размера (2,2 ГБ) содержит данные, представляющие 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 минут. Я не буду давать рекомендации, так или иначе основанные на моих результатах. Все, что я могу сказать, это то, что он, кажется, работал нормально, и никаких ошибок не произошло. И различие файлов, похоже, хорошо работает (для этих файлов).

Answer 2

Subversion будет выполнять двоичные дельты для двоичных файлов, а также текстовых файлов.Subversion просто неспособна предоставить понятные человеку дельты для двоичных файлов и не может помочь с конфликтами слияния в двоичных файлах.

Answer 3

Subversion может работать, в зависимости от вашего определения большого. Этот вопрос / ответ говорит о том, что он работает хорошо, если ваши файлы меньше 1 ГБ.

Answer 4

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    .