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

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

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

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

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

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    .