git и хранение бинарных файлов

saveliev_a

А правда ли, что git хранит не диффы между бинарниками, а полностью все бинарники?

procenkotanya

Неправда, он может строить дельту (дифф) и для бинарников.

tokuchu

А правда ли, что git хранит не диффы между бинарниками, а полностью все бинарники?

Да он вроде и между текстовыми диффы не хранит. Ну может только если как-то специально настраивать.

vall

http://book.git-scm.com/7_how_git_stores_objects.html
http://book.git-scm.com/7_the_packfile.html
Хранит он дельты и некоторые контрольные точки чтоб постоянно не бегать к началу времён собирая файл по кусочкам.
И не думаю что хранилище объектов как-то использует текстовость текстовых файлов, просто у бинарников обычно эффективнее сохранить копию чем пытаться состряпать дельту.

tokuchu

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

Действительно умеет. Ну вроде там и написано как я подозревал, что по умолчанию хранит целиком упакованные, а при вызове gc оптимизирует дифами некоторые файлы. Хотя может он gc как-то и автоматически делает.

yroslavasako

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

vall

некоторые команды автоматически запускают git gc --auto

vall

не не, это дифф который показывает различия в текстовом виде. дельты считает не он.

sergey_m

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

Имхо, так не делает ни один VCS, хотя многие хранят именн диффы. Потому что хранятся диффы не от 1.1 и вперёд, а хранятся диффы от текущей версии назад до 1.1.

vall

ну cvs конечно не хранит, куда уж ему.
Во всяком случае дельты ссылаются только на блобы в том-же паке, так что каждый пак имеет хотябы одно контрольную точку для каждого файла хранящегося в нём, бегать в старые паки не нужно.
Кроме того я очень удивлюсь если там нет эвристики оценивающей длину цепочки дельт при упаковке.
а дельты вполе ссылаются на дельты:
$ git verify-pack -v ~/git/linux-2.6.git/objects/pack/pack-cfd7574d84e6da99de0683e0ba8eb8063295c1d6.pack
.....
non delta: 6926 objects
chain length = 1: 5321 objects
chain length = 2: 4670 objects
chain length = 3: 3015 objects
chain length = 4: 1918 objects
chain length = 5: 1599 objects
chain length = 6: 1050 objects
chain length = 7: 744 objects
chain length = 8: 846 objects
chain length = 9: 745 objects
chain length = 10: 331 objects
chain length = 11: 245 objects
chain length = 12: 412 objects
chain length = 13: 328 objects
chain length = 14: 415 objects
chain length = 15: 314 objects
chain length = 16: 219 objects
chain length = 17: 159 objects
chain length = 18: 145 objects
chain length = 19: 137 objects
chain length = 20: 124 objects
chain length = 21: 141 objects
chain length = 22: 93 objects
chain length = 23: 60 objects
chain length = 24: 115 objects
chain length = 25: 51 objects
chain length = 26: 53 objects
chain length = 27: 36 objects
chain length = 28: 31 objects
chain length = 29: 39 objects
chain length = 30: 48 objects
chain length = 31: 51 objects
chain length = 32: 34 objects
chain length = 33: 27 objects
chain length = 34: 28 objects
chain length = 35: 27 objects
chain length = 36: 17 objects
chain length = 37: 31 objects
chain length = 38: 18 objects
chain length = 39: 34 objects
chain length = 40: 12 objects
chain length = 41: 6 objects
chain length = 42: 7 objects
chain length = 43: 12 objects
chain length = 44: 4 objects
chain length = 45: 3 objects
chain length = 46: 5 objects
chain length = 47: 3 objects
chain length = 48: 5 objects
chain length = 49: 3 objects
....

Werdna

А правда ли, что git хранит не диффы между бинарниками, а полностью все бинарники?

Я один считаю полным мудачеством хранить бинари в системе контроля версий?

zya369

а что не так?
всякие картинки, например, и т.д. где хранить?

doublemother

Пианист, наверное, после клонирования своих гит-реп, отдельно вгетами выкачивает из интернета всё недостающее: картинки, иконки, файлы шрифтов, звуки.
Как вариант, иконки с картинками можно хранить в xpm и svg

yroslavasako

отдельно вгетами выкачивает

не правда. Для этого в гит-репах у него есть специальный скрипт. getbinarydata.sh, который выкачивает бинарники из меркуриала дабы не осквернять священный гит

vall

Если бинарники большие и часто меняются конкретно гит действительно не очень годится — всё будет хранится в каждой копии репозитория, что-нить централизованное типа svn тут лучше. Ежели тебя смущает непрозрачность отслеживания изменений в бинарных файлах, то тут уже постили ссылку на способ прикручивания к git сравнения odf, который хоть и текстовый но нечеловекочитаемый да ещё и в архиве.

saveliev_a

спасибо!
просто настолько суров, что не использует никаких бинарников, а там, где нужны картинки, довольствуется ascii-артом.
Да, вендоюзерам повезло, в TortoiseGit уже настроена сравнивалка odf.

erotic

Я один считаю полным мудачеством хранить бинари в системе контроля версий?

Мудачество, конечно, не понимаю, зачем вы их туда засунули только.

Werdna

Мудачество, конечно, не понимаю, зачем вы их туда засунули только.

Если ты про Бегун, то я сражался до последнего.

erotic

Про него, да.

saveliev_a

А где ты их предлагал хранить?

Werdna

А где ты их предлагал хранить?

Там вообще раз в N дней (зависит от желания обновить и сделать жизнь краше) обновляется несколько бинарей. Причем такие бинари, что дифф там будет сложнее чем сами бинари. Предлагал (о, да!) wget'ом раскладывать. Они небольшие, мегов в сумме, самое оно.
Настоящие пацаны вообще торрентами раскладывают, когда машинок много очень быстро разъезжается. Положил на одну машину, далее transmission-remote'ом торрент залил и оно само дальше. Это я вам говорю.
Поэтому часто обновляющееся ПО надо выкатывать wget/scp, старое (чем затыкать если прорвёт) откатывать из XXX.prev.

doublemother

Причем такие бинари, что дифф там будет сложнее чем сами бинари.

А что, эти ваши гиты не умеют по mime-type определять, что это бинарник и при изменении не суетиться с диффами? В свн вон даже какой-нибудь svn:mime-type можно на произвольный файл повесить с этой целью.

vall

да, но зачем?

Maurog

не очень понимаю, почему все против хранения бинарей в системе контроля версий
если у бинарей меняются версии, то им место как раз в системе контроля версий
только так можно всегда перемещаться между версиями и иметь один снапшот исходный данных (включая бинарные)
к примеру, у нас раз в сутки делается билд всего проекта, далее делается слепок (бранч). если гуй не будет содержать нужной бинарной картинки, то всегда можно выяснить кто ее убил\поменял по системе контроля версий
как вы планируете wget-ом заменить поддержку версий?

vall

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

Maurog

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

какой смысл класть "вне дерева исходников" ? что это значит, кстати?
у меня гуй не соберется, если я что-то разделять буду у себя - ему для сборки нужны картинки
а чтобы выкачивать картинки без исходников, я сделаю svn co gui/pictures

rosali

> а чтобы выкачивать картинки без исходников
а чтоб исходники без картинок?
> "вне дерева исходников"
ну просто имеется в виду, что лучше prj/src/*.cpp + prj/binary/ чем prj/*.cpp + prj/binary/.
можно хранить id-шники бинарных данных в vcs а сами данные в базе. при этом в базе никогда не апдейтить, только инсертить.
хотя на самом деле я не вижу принципиальной разницы между тесктовыми данными и бинарными. вопрос нужна ли данным версионированность он по идее зависит от смысла этих данных, а не от их формата.

erotic

у меня гуй не соберется, если я что-то разделять буду у себя - ему для сборки нужны картинки

Не пытайся убедить, что ты не можешь настроить проект брать картинки из другого места

pitrik2

какой смысл класть "вне дерева исходников" ? что это значит, кстати?

в случае svn это например можно сделать через svn:externals (это типа symbolic link внутрях дерева ревизий)
т.е. бинарники лежат в svn но в другом бранче (или просто на директорию выше)
если в другом бранче - то svn:externals лучше указывать на тэг от того бранча
плюсы:
- когда какаму-то бранчу надо перейти на более новую версию бинарей, он меняет ссылку на другой тег бинарей, таким образом не надо бинарники аплоадить в текущий бранч, тойсть они как бы ревизионно-шарятся между разными бранчами
- когда у тебя уже есть бинари ты можешь из репозитория не выкачивать (указав опцию для девелоперской машины это пофиг а вот для удаленного сервака очень даже удобно - проект скачивается из репозитория 10 минут а не час

andrei260280

если использовать гит, то в ситуации, описанной пианистом, при чекауте по сути придется качать все версии бинарника.
с свном проблем в данном случае нет, но использовать 2 разные системы контроля версий (для бинарников и сорцов) не сильно лучше wget-а.

Maurog

вот спасибо
теперь ясно, почему вокруг гита надо прыгать с бубном

vall

зачем? просто когда начинаешь действительно пользоваться гитом понимаешь что есть люди существенно умнее тебя =)