Git дизайн решение о хранении контента, а не различий

Question

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

Я полагаю, что Subversion хранит ревизии, а не содержимое, поэтому, когда содержимое меняется, оно просто отслеживает различия между ними. Не мог бы и Мерз сделать это так же? В чем преимущество хранения содержимого, а не изменений?

Answer 1

Я не смог найти ответ с помощью быстрого Google, но я считаю, что все сводится к простому «это не имеет значения, потому что дисковое пространство дешево».

Хранить ревизии в инструменте управления исходным кодом сложно. Если вы только сохраните разницу между предыдущей ревизией и текущей, у вас возникнут две проблемы:

1. Возврат последней ревизии (общий случай) требует большей работы, так как код должен собрать эту ревизию путем объединения каждой ревизии вместе.
2. Любая ошибка (скажем, неисправность диска) в одной ревизии нарушает доступ к каждой последующей ревизии.

Я считаю, что большинство современных VCS на самом деле хранят последнюю версию (по соображениям производительности), и различия, если они используются, используются для возврата во времени, а не вперед.

Answer 2

Статья, в которой рассматриваются эти (и связанные с ней) проблемы: Вопрос форматов репозитория . Это была одна из статей, которые повлияли на мое решение переехать в Git пару лет назад. Вот выдержка:

Учитывая этот аргумент, должно быть ясно, что я думаю, что структура репозитория git лучше других, по крайней мере для модели использования X.org. Кажется, он обладает несколькими интересными свойствами:

1. Файлы, содержащие данные объекта, никогда не изменяются. После записи каждый файл доступен только для чтения с этого момента.

2. Сжатие выполняется в автономном режиме и может быть отложено до тех пор, пока основные объекты не будут сохранены на резервном носителе. Этот метод обеспечивает лучшее сжатие, чем любой инкрементальный подход, позволяя переупорядочивать данные на диске для соответствия шаблонам использования.

3. Данные объекта по сути являются самоконтролируемыми; Вы не можете изменить объект в хранилище и избежать обнаружения при первом обращении к объекту.

Answer 3

Позвольте мне прояснить ваши заблуждения:

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

Довольно хорошее объяснение (начального) дизайна Git можно найти в эссе Тома Престона-Вернера The Git Parable (в дополнение к тому, на которое ссылается ответ Грега Хьюгилла ) ,

Идея заключается в том, что обычно (в достаточно большом проекте) в новой редакции изменяются только несколько файлов из большого количества файлов в проекте, поэтому хранение только разных версий содержимого файла экономит место. Это та же самая идея , что Subversion использует в своем методе «дешевого копирования» (он использует hardlinking, IIRC).

Также содержимое файла: zlib (deflate) сжатый (или, точнее, каждый объект в базе данных репозитория git сжат, включая объекты comit).

Я считаю, что Subversion хранит ревизии, а не содержимое, поэтому, когда содержимое меняется, оно просто отслеживает различия между ними. Не мог бы и Мерз сделать это так же? В чем преимущество хранения содержимого, а не изменений?

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

Если хранение различий экономит место, то я хотел бы сказать вам, что в дополнение к «свободному» формату (где каждый большой двоичный объект, т.е. каждое (разное) содержимое файла, хранится в отдельном файле внутри .git) также имеет «упакованный» формат , где многие объекты хранятся в дельта-форме, используя двоичную дельту из библиотеки LibXDiff.

Этот формат был создан для передачи по сети (большое дисковое пространство могло бы быть дешевым, но пропускная способность - нет), и был адаптирован как и формат на диске. Этот формат очень эффективен, один из более эффективных, если не самых эффективных форматов систем контроля версий, делающий репозитории git маленькими или один из самых маленьких среди различных систем контроля версий. В зависимости от обстоятельств полный клон репозитория git (который содержит полную историю) может быть меньше, чем эквивалентный Subversion checkout (который содержит дополнительную копию нетронутых изменений, так что svn diff и svn status работать без необходимости передачи по сети, с разумной скоростью).

Этот дизайн («свободный» и «упакованный» формат) имеет преимущество очень эффективной упаковки, но имеет тот недостаток, что вам пришлось перепаковывать вручную, используя «git gc» (не для дискового пространства, а для производительности - диск) I / O); в настоящее время большинство команд git перепаковывают хранилище (безопасно) при необходимости.