Git, бинарные файлы, системы контроля версий

у меня меркуриал коммитил 2 файла по 130-МБ за 2-3 минуты. после bzr как в сказке но кривой же он...

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

> Subversion теоретически должен одинаково работать что с бинарями что с текстом

Так и есть, но вот засада - в .svn хранится неизмененная копия каждого файла :)

> ибо репозиторий у него один фиг на бинарных дельтах строится

У всех современных VCS так, даже у последних Git :)

> кривой же он...

Что в нем такого кривого?

Сужаем контекст до более конкретного. Git быстре разберется с бинарями?

>Subversion теоретически должен одинаково работать что с бинарями что с текстом

Не тестировал на данной своей репе, потому что читал мнение, что дельты svn лепит размером вдвое больше, чем сами файлы.

git загнется на твоих задачах.

меркуриал при коммите время тратит исключительно на копирование рабочего дерева на сторону. а git и bzr и коекто еще пытаются ещё какието дифы считать...

поставь нормальный SAS-рейд и будет тебе счастье. больше ничего тебя не спасет.

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

хотя возможно что определенные концепции/идеи совпадают

и оперативки рекомендую не менее 4 Гиг если будеш сползать с меркуриала.

Спасибо за мнение.

В общем, скомпилил git, проиндексировал репу, первые пару коммитов проглотилось на ура, быстрее меркуриал в полтора раза по времени.

Удивило одно обстоятельство: странно неравномерно загружается как процессор так и винт, то есть если питоновский hg стандартно отжирал все 100% cpu и постоянно шуршал винтом, то в случае с git загрузка проца в районе 35-80%, но винт слышно только иногда, и это очень нечастое иногда.

Надо будет посмотреть, сколько процессы памяти жрут. Как-то не обращал на это внимания.

Все равно, всем спасибо.

на моих 250МБ коммитах hg проц грузил процентов на 30-60 и винтом практически не шуршал.

шото мне подсказывает что на твоей машинке слишком мало RAM и питон свапился.

> питоновский hg стандартно отжирал все 100% cpu и постоянно шуршал винтом

Какая версия hg?

>git загнется на твоих задачах.

>меркуриал при коммите время тратит исключительно на копирование рабочего дерева на сторону. а git и bzr и коекто еще пытаются ещё какието дифы считать...

у меня ровно наоборот получалось: коммитил .psd по 100..250 Мб, 1Gb Ram. Меркуриал долго грузил своп и вылетал (как я понимаю, как раз при вычислении диффов -- на линуксе hg вылетал позже, под виндовсом раньше), git нормально сиё проглатывал.

Еще можно попробовать git старых версий, там где он не пытался вычислять бинарные дельты. В git структура репозитория не основана на диффах (была по крайней мере раньше) , в hg ревлоги, чтобы сделать новый коммит ему нужно вычислять дельты.

В git просто есть файлы-блобы, адресуемые по хешу содержимого, и "коммиты" = криптографическая подпись файлов-блобов на конкретный момент времени. По идее, дельты ему вычислять не нужно, пока сам не попросишь.

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

> В git структура репозитория не основана на диффах (была по крайней мере раньше)

Уже года 3 назад выяснилось, что структура репозитория без двоичных дельт сосет нипадецки (== непригодна к использованию в реальной жизни), и был придуман процесс упаковки репозитория, заключающийся (сюрприз!) в генерации двоичных дельт (с последующей их компрессией, IIRC). Это значит, что там, где hg делат работу сразу, git откладывает ее "на потом". Возможно, у OP именно поэтому git быстрее hg, хотя без указания версий/конфигурации обоих программ и размеров получившихся репозиториев, сказать трудно.

>> питоновский hg стандартно отжирал все 100% cpu и постоянно шуршал винтом

>Какая версия hg?

на файле 245M psd мой Mercurial Distributed SCM (version 04c76f296ad6+win32extras) от 2007-12-01 (0.9.5, релиз "Batteries included" отсюда: http://sourceforge.net/project/showfiles.php?group_id=188871 (кстати, советую чайникам, которые не ставят Mercurial на винду потому что "нет GUI" -- там есть в наборе и hgtk и kdiff и чорт лысый).

W2K3 SP2, 1Gb Ram -- валился на этом файле с abort: out of memory (старые версии hg вообще выдавали бектрейс питоновский).

Та же машина, Gentoo, git -- нормально проглатывал, hg аналогичной версии валился.

> Это значит, что там, где hg делат работу сразу, git откладывает ее "на потом".

это значит, что в случае когда в репозитории мало текстов и много "сплошных бинарников" генерировать двоичные дельты, как правило, не надо. Поэтому у hg получается оверхед, а у git'а старого его не будет пока git repack, git fsck ему вручную не скажешь :))

>> Это значит, что там, где hg делат работу сразу, git откладывает ее "на потом".

>это значит, что в случае когда в репозитории мало текстов и много "сплошных бинарников" генерировать двоичные дельты, как правило, не надо

Необходимость двоичных дельт проявилась на репозитории ядра Линукса, которое состоит из текста. А то, что для "сплошных бинарников" "как правило" не нужно генерировать дельты - как минимум бездоказательное утверждение.

> Поэтому у hg получается оверхед, а у git'а старого его не будет пока git repack, git fsck ему вручную не скажешь :))

А у git получается другой оверхэд - по месту на диске и seek time при работе с неупакованным репозиторием.

> Необходимость двоичных дельт проявилась на репозитории ядра Линукса, которое состоит из текста

конечно. И появилась из необходимости "мёржить патчсеты". А если файлы-"сплошные бинарники", то бинарные дельты в общем случае не помогут ( хотя если вытащить из них метаданные и по ним ориентироваться -- вполне).

> А то, что для "сплошных бинарников" "как правило" не нужно генерировать дельты - как минимум бездоказательное утверждение.

уже научились мёржить "сплошные бинарники" автоматически, не вручную?

Для того же фотошопа это наверно в принципе возможно (если из панели Actions разных версий файла выцепить ChangeLog и мёржить их), но проще и универсальнее -- вручную. В любом случае надо визуально оценить, результат подходит или не подходит, а "генерировать бинарные дельты" чтобы по ним сравнивать -- это как раз "бездоказательное утверждение".

Хотя алгоритм построения "бинарных дельт" не обязан жрать много памяти. Тот же rsync -- поточный, вполне справляется с rolling checksum-мами.

>А у git получается другой оверхэд - по месту на диске и seek time при работе с неупакованным репозиторием.

Оверхед где-то всегда получается, тут уж поперёк или вдоль :))

>> Необходимость двоичных дельт проявилась на репозитории ядра Линукса, которое состоит из текста

> конечно. И появилась из необходимости "мёржить патчсеты"

Чушь. Оно просто стало работать неприемлимо медленно с репозиторием, где каждый коммит и каждый изменный блоб лежали в отдельных файлах (с патнтованно плохим распределением по диску). Почитай архивы git@ за 2005-й год и не говори ерунды.

> А если файлы-"сплошные бинарники", то бинарные дельты в общем случае не помогут ( хотя если вытащить из них метаданные и по ним ориентироваться -- вполне)

Ну так доказательства или хоть разъяснения, почему бинарные дельты не помогут уменьшить место при хранении - будут или нет?

>> А то, что для "сплошных бинарников" "как правило" не нужно генерировать дельты - как минимум бездоказательное утверждение.

>уже научились мёржить "сплошные бинарники" автоматически, не вручную?

Причем здесь "мёржить"? o_O Речь идет о хранении.

> "генерировать бинарные дельты" чтобы по ним сравнивать -- это как раз "бездоказательное утверждение".

Покажи мне, где я говорил о "генерировать бинарные дельты, чтобы по ним сравнивать".

> Оно просто стало работать неприемлимо медленно с репозиторием, где каждый коммит и каждый изменный блоб лежали в отдельных файлах (с патнтованно плохим распределением по диску).

... для их характерного паттерна использования: тексты, текстовые патчи, текстовые дельты. Если бы Линус писал исходнике в Ворде ( o_O ) , паттерн использования VCS был бы другой :))

>Почитай архивы git@ за 2005-й год

перечитываю, интересно.

>Ну так доказательства или хоть разъяснения, почему бинарные дельты не помогут уменьшить место при хранении - будут или нет?

Я те про фому, ты мне про Ерёму. Ну да, уменьшуд. И бинарные дельты для текстовых файлов не нужны, ога.

А для бинарных -- сильно зависит от характера изменений. Если изменения не локальные, а много мелких в разных местах, то выйдут патчи на 10Мб при смене ревизии.

1. Если дельты (бинарные) становятся сопоставимы с размером файла (где изменения по всему бинарнику в разных местах), то толку от таких дельт?

2. Если выясняется что "для наиболее компактного хранения" надо пересчитать заново старые дельты (ибо будут компактнее с учётом новых версий) -- то толку от таких дельт?

3. можно и "просто хранить каждый коммит и каждый изменный блоб лежали в отдельных файлах" и дельты считать rsync'ом. У него самые аккуратные дельты, круче всех место уменьшуд :))

> Причем здесь "мёржить"? o_O Речь идет о хранении.

да при том, что если всё хранится в "сплошных бинарниках" то толку от таких дельт особо и нету.

>> Оно просто стало работать неприемлимо медленно с репозиторием, где каждый коммит и каждый изменный блоб лежали в отдельных файлах (с патнтованно плохим распределением по диску).

> ... для их характерного паттерна использования: тексты, текстовые патчи, текстовые дельты. Если бы Линус писал исходнике в Ворде ( o_O ) , паттерн использования VCS был бы другой :))

Он был ровно таким же: нет разницы, в plain-text файл или в формате Word, если при изменении он все равно записывался заново.

>> Ну так доказательства или хоть разъяснения, почему бинарные дельты не помогут уменьшить место при хранении - будут или нет?

> Я те про фому, ты мне про Ерёму.

Посмотри на топик - речь идет о больших двоичных файлах. Я говорю не о Ереме, а о том, как хранятся данные (в том числе - сабжевые файлы) в разных VCS. О чем говоришь ты - только тебе ведомо.

> Если изменения не локальные, а много мелких в разных местах, то выйдут патчи на 10Мб при смене ревизии.

Зависит от того, что значит "мелкие в разных местах". 10000 однобайтовых изменений в 10МБайт файле выгоднее представить двоичным патчем.

> Если выясняется что "для наиболее компактного хранения" надо пересчитать заново старые дельты (ибо будут компактнее с учётом новых версий) -- то толку от таких дельт?

Эх... ты и в самом деле думаешь, что ты один умный, а все остальные - дураки? И об этом случае тоже подумали, причем давно.

>> Причем здесь "мёржить"? o_O Речь идет о хранении.

> да при том, что если всё хранится в "сплошных бинарниках" то толку от таких дельт особо и нету.

Объяснений, видимо, не будет.

</thread>

> Он был ровно таким же: нет разницы, в plain-text файл или в формате Word, если при изменении он все равно записывался заново.

по-твоему, информационная энтропия plain-text и бинарного блоба одинаковая?

>> бинарные дельты не помогут уменьшить место при хранении - будут или нет? > Посмотри на топик - речь идет о больших двоичных файлах. Я говорю не о Ереме, а о том, как хранятся данные (в том числе - сабжевые файлы) в разных VCS. О чем говоришь ты - только тебе ведомо.

эхм. я тебе и говорю, что ревлоги для бинарных блобов хуже подходят, чем git-блобы. Потому что для ревлогов надо считать дельты, что для git необязательно. Речь не идёт о "уменьшении места при хранении", если тебя это беспокоит, ну возьми запакуй все блобы кроме тех что относятся к последним 2-3 версиям. Или поставь атрибут compressed чтобы сжимало ФС на уровне директории. Или юзай ZFS/LVM со снапшотами.

Речь о том, что VCS может работать не считая дельты, что это лучше оставить ФС/архиватору. Или, если уж считать, то блочно, не отжирая всю память, как это делает меркуриал. Алгоритм там кривоват, а раз дельты нужны для ревлогов, никуда от этой кривости не деться.

>> да при том, что если всё хранится в "сплошных бинарниках" то толку от таких дельт особо и нету.

>Объяснений, видимо, не будет.

посчитай энтропию plain-text файла (или метаданных, ChangeLog к Action панели в фотошопе) и энтропию растровой картинки целиком. Что из них лучше будет сжиматься? или, дельты от чего будут считаться быстрее?

А зачем работа VCS *обязательно* должна зависеть от этой энтропии? Зачем работа VCS должна зависеть от "вычисления бинарных дельт"? Если беспокоит место на диске, этим не обязана заниматься именно VCS.

> </thread>

вообще да, можно сворачивать. Топикстартер уже попробовал и выбрал (а если понимать структуру репозиториев в git и в hg , для "сплошных бинарников" очевидно, что лучше подходит).

> И об этом случае тоже подумали,

git repack чем занимается? хотя "пересчитывать все дельты" -- действительно глупо, о чём и речь.

> Зависит от того, что значит "мелкие в разных местах". 10000 однобайтовых изменений в 10МБайт файле выгоднее представить двоичным патчем.

берём картинку tiff 100x100, изменяем цветность (крутим HSV цвета на дополнительные). Сохраняем в tiff, сохраняем в какой-нибудь .psd со слоями и эффектом "крутить цвета". Считаем "двоичные патчи" от .psd с эффектом и от tiff 100x100, сравниваем размеры, радуемся.

>Он был ровно таким же: нет разницы, в plain-text файл или в формате Word, если при изменении он все равно записывался заново

пусть N - размер файла. сравниваем O(xdelta(N)), O(hash(N)), радуемся. И так при каждом коммите.