LINUX.ORG.RU

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


0

0

Насколько хорошо работает git с большими (1-100 мб) бинарниками, и есть ли что-нибудь быстрее?

Имеется смешанный репозиторий около 20 гб процентов на 99 состоящий из бинарей различных форматов и объемов.

В репозиторий планируется коммитить тоже бинари (разные комплекты, имеющие общие файлы) для отслеживания взаимопересекающихся зависимостей и работоспособности обновлений "пост фактум".

Пробовал меркуриал, определенно не устраивает ждать по 20 минут, пока он сожрет коммит на пару сотен мегабайт, есть ли что пошустрее?

Децентрализованность роли в выборе не сыграет.

Спасибо.

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

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

cvv ★★★★★ ()

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

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

INFOMAN ★★★★★ ()

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

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

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

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

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

tailgunner ★★★★★ ()

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

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

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

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

malices_gossips ★★★ ()

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

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

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

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

cvv ★★★★★ ()

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

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

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

cvv ★★★★★ ()

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

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

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

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

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

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

malices_gossips ★★★ ()
Ответ на: Re: Git, бинарные файлы, системы контроля версий от malices_gossips

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

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

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

cvv ★★★★★ ()

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

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

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

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

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

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

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

anonymous ()

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

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

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

tailgunner ★★★★★ ()

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

>> питоновский 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 аналогичной версии валился.

anonymous ()

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

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

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

anonymous ()

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

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

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

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

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

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

tailgunner ★★★★★ ()

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

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

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

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

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

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

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

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

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

anonymous ()

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

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

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

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

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

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

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

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

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

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

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

tailgunner ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

</thread>

tailgunner ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

> </thread>

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

anonymous ()

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

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

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

anonymous ()

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

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

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

anonymous ()

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

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

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.