Какой формат (с изменениями) эффективнее хранится в Git?

Question

[Ярослав]

Представим Wiki, которая хранит все страницы в каком-то одном файле. Естественно, страницы иногда немного изменяются. Мы можем взять SQLite базу или хранить в "текстовых" JSON/YAML/TOML или как-то иначе. Хочется, чтобы при небольших изменениях контента в Git-репозитории тоже были небольшие (по размеру) изменения.

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

Answer 1

[paran0id]

Всё правильно понимаете - текстовые форматы лучше.

Answer 2

[Сергей Кузнецов]

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

Comments

[freeExec]

GIT в любом случае хранить целиком весь слепок файла, а не дельты, нет разницы 1 байт поменялся или всё переписали.

[Ярослав]

Вы говорите про все (любые) файлы или только про бинарные? То есть, если у меня есть обычный проект (на пайтон, например), и я посмотрю сейчас хеш-сумму любого файла, то даже через 10 лет где-то в недрах репозитория будет этот файл (с этой же хеш-суммой)?

[Lynn «Кофеман»]

Ну всё же есть pack-файлы.
Так что для нормальных исходных файлов обычно хранятся именно дельты изменений.

https://git-scm.com/book/ru/v2/Git-%D0%B8%D0%B7%D0...

[Сергей Кузнецов]

Ярослав, если файл не изменялся, то его хеш не изменится. Неважно, текстовый или двоичный файл.

[Ярослав]

Сергей Кузнецов, конечно. Но меня смутил комментарий freeExec выше, что хранится весь слепок файла, а не дельты. (Если у нас есть текстовый документ на 100 кб, в нем поменяли 1 букву, размер репозитория вырастет на 100кб, так как в нем будет и новый и старый файлы?). Всегда считал, что хранится более оптимизированно.

[Сергей Кузнецов]

Ярослав, а почитать по ссылке выше?
10.4 Git изнутри - Pack-файлы

При упаковке Git ищет похожие по имени и размеру файлы и сохраняет только разницу между соседними версиями.

Answer 3

[mayton2019]

Вам надо в git складывать не бэкапы Sqlite а текстовое представление wiki по состоянию на сегодняшний день. Насколько я помню там есть
свой язык форматирования типа markup. Так что все будет норм.

Comments

[Ярослав]

markdown? Вы имеете в виду, чтобы каждая страница - в отдельном файле?

Да, такой подход лучше был БЫ. Но я посмотрел имеющиеся вики-движки, которые с git интегрируются (у меня другой вопрос на тостере был про это), и они относительно нормально редактируют .md файлы, но как-то у них не получалось создавать файлы. Поэтому, как workaround и обдумываю идею хранить все в одном файле, если с созданием-удалением проблемы.

[mayton2019]

Ярослав, у тебя был простой вопрос.

Какой формат (с изменениями) эффективнее хранится в git'е

эффективнее - хранится сет текстовых файлов. И эффективно трекается если изменено немного строк.

Детали, касающиеся редактирования md файлов - это совсем другая задача и она к wiki не относится. Лучше не мешать это в кучу.

Answer 4

[Everything_is_not_so_bad]

sqlite3 file.sqlite3 .dump > dump-`date +'%F %T'`.sql

и заносим файл dump-`date +'%F %T'`.sql в Git.
Или использовать другие VCS. Допустим, Subversion (использует xdelta для эффективного хранения).

Добавлено:
Нет, туплю. Суффикс -`date +'%F %T'` не нужен, иначе Git не будет хранить версии, а будет хранить множество файлов дампа.

Answer 5

[Станислав Макаров]

Хочется, чтобы при небольших изменениях контента в Git-репозитории тоже были небольшие (по размеру) изменения.

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

Если вы хотите какие-то элементы данных рассматривать независимо (например страницы Вики), кладите их в разные файлы, желательно текстовые.

Посмотрите как Wiki реализована на Гитхабе - это ж тоже просто гитовая репа, где каждая статья - отдельный файл.

Comments

[Ярослав]

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