Необъяснимый размер хранилища SVN увеличивается от небольших различий до больших файлов

Question

Я не могу понять, почему из-за небольших различий с большими файлами мой репозиторий subversion так сильно увеличивается.

У меня есть zip-файл содержимого базы данных, используемой некоторыми тестами.Я хочу хранить каждую новую версию тестовых данных в нашем хранилище subversion.

Я провел несколько экспериментов, проверил последние несколько версий файла data.zip и посмотрел, что происходит с размеромрепозиторий.Размер несжатых данных составляет около 150 МБ, сжатых и заархивированных - около 50 МБ.Каждая новая версия файла data.zip, добавленная в хранилище, увеличивает размер хранилища примерно на 50 МБ.Я думаю, что он должен увеличиваться только на величину дельты, которая, как я ожидаю, будет намного меньше.

Subversion использует xdelta для хранения сжатых данных разностей.Моя попытка подтвердить, что SVN может работать лучше, была загрузить xdelta и убедиться, что между двумя версиями нет большой разницы.Действительно,

xdelta3.0z.x86-64.exe -e -s v1_path\data.zip v2_path\data.zip v1v2_delta.file

создал файл v1v2_delta.file размером около 3 МБ.

Я посмотрел в SVN-репозитории на [myrepo] \ db \ revs и могу видеть большие файлы для каждого новогоrevision

02/08/2011  11:12        57,853,082 4189
02/08/2011  11:40        51,713,289 4190
02/08/2011  11:46        52,286,060 4191

(4189, 4190 и 4191 - имена файлов.)

Я даже пытался сжать data.zip без сжатия.Это не имело никакого значения к тому, что хранит SVN - с моей точки зрения, я думаю, что он хранит сжатую копию всего data.zip для каждой ревизии, а не только для первой.Я использую SVN 1.6 с бэкэндом FSFS.

Существуют и другие хорошие ответы на вопросы stackoverflow о фиксации двоичных файлов и о том, как SVN хранит дельты, например, производительность SVN после многих ревизий .Но я не могу понять из этого, почему дельты не сохраняются в вышеупомянутом случае - т.е.если xdelta может получить такой маленький автономный прогон diff, конечно, SVN тоже может - или он не хочет?!

Редактировать: Я также пробовал tar (несжатые) файлы, сноваSVN не хранит их эффективно.Также я обнаружил, что у нас есть zip-файл того же формата данных (хотя и гораздо меньшего размера) в другом хранилище, где SVN только что сохранил diff .

Итак, краткая версия этого вопроса такова: SVN может эффективно хранить бинарные файлы, например, 10, несколько отличающихся файлов САПР, в 1,2 раза больше размера 1 .SVN даже иногда может быть экономичным с помощью сжатых zip-файлов.Но очевидно, что это не всегда эффективно с двоичными файлами - при каких условиях это так?

Answer 1

Резюме

Subversion иногда будет хуже, чем xdelta standalone, из-за того, сколько памяти выделяется на сжатие.Это поведение подрывной деятельности, которое в настоящее время не может быть изменено, начиная с версии 1.6.

Подробности

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

Вывод таков: xdelta может создать меньшую дельту, если вы дадите ей больше памяти .

Чтение обратнов этой теме еще один пример кого-то, у кого была такая же проблема .

С благодарностью и благодарностью различных людей в списках рассылки Subversion недавно и четыре года назад за это.

Также есть эта проблема?

Если вы анализируете использование диска в хранилище Subversion, поймите Пропустить дельты и используйте этот grep DELTA трюк чтобы выяснить, какая база используется для дельты.

И, если, как и я, вы действительно хотите хранить двоичные файлы в хранилище, вот мое предположение о некоторых обходных путях (ни один из них не очень прост!):

1. Измените исходный код Subversion и создайте свой собственный, установив окно памяти xdelta на большее
2. У вас есть xdelta-ing - проверяйте дельты в управлении исходным кодом и выполняйте сумасшедший заддля реконструкции
3. Migrate to Git - у него обязательно будет лучшее сжатие (дикие спекуляции)

Answer 2

Двоичный контент сжатых файлов может существенно измениться при добавлении или изменении файлов в сжатом архиве. Предполагалось, что изменения могут происходить в отдельных элементах архива, и в больших областях сжатого файла не происходит никаких существенных изменений. Тем не менее, это вопрос «удачи», что это будет иметь место в обычных случаях (конечно, в этом нет реальной удачи, но немного сложно спланировать ее достижение)

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

Answer 3

Я думаю, что сжатие полностью изменит структуру двоичного файла, поэтому svn придется хранить огромные дельты.Даже изменение нескольких символов содержимого сжатого файла может радикально изменить его.

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

Answer 4

Использовали ли вы поддержку файловой системы fsfs?Насколько я помню, он сохраняет новую копию каждый раз (хотя может быть сжат).Почему вы ожидаете, что SVN будет хранить различия двоичных файлов?SVN - это система управления исходным кодом (то есть текст), а не обычная двоичная система управления (хотя она не работает так плохо, как при хранении двоичных файлов).