multi-pack-index

Состояние реализации

В настоящее время в функции инкрементальных индексов нескольких пакетов отсутствуют два важных компонента:

Структура файлов

Вместо хранения одного файла multi-pack-index (с необязательными расширениями .rev и .bitmap) в $GIT_DIR/objects/pack, инкрементальные MIDX хранятся в следующей структуре:

$GIT_DIR/objects/pack/multi-pack-index.d/
$GIT_DIR/objects/pack/multi-pack-index.d/multi-pack-index-chain
$GIT_DIR/objects/pack/multi-pack-index.d/multi-pack-index-$H1.midx
$GIT_DIR/objects/pack/multi-pack-index.d/multi-pack-index-$H2.midx
$GIT_DIR/objects/pack/multi-pack-index.d/multi-pack-index-$H3.midx

Файл multi-pack-index-chain содержит упорядоченный список файлов инкрементального MIDX в цепочке. В приведённом выше примере файл multi-pack-index-chain для этой цепочки содержал бы следующие строки:

$H1
$H2
$H3

Файл multi-pack-index-$H1.midx содержит первый слой цепочки индексов нескольких пакетов. Файл multi-pack-index-$H2.midx содержит второй слой цепочки и так далее.

Если присутствуют и инкрементальный, и неинкрементальный MIDX, сначала всегда считывается неинкрементальный MIDX.

Позиции объектов в инкрементальных MIDX

В исходном проекте индекса нескольких пакетов объекты обозначаются их лексикографическими позициями (по идентификаторам объектов) в едином индексе нескольких пакетов репозитория. В проекте инкрементального индекса нескольких пакетов объекты обозначаются их индексами в объединённом лексикографическом порядке компонентов цепочки MIDX.

Если objects_nr() — это функция, возвращающая число объектов в заданном слое MIDX, то индекс объекта с лексикографической позицией i в, например, $H3 определяется следующим образом:

objects_nr($H2) + objects_nr($H1) + i

(В реализации на C это часто вычисляется как i + m->num_objects_in_base.)

Порядок псевдопакета для инкрементальных MIDX

В исходной реализации битовых карт достижимости для нескольких пакетов порядок псевдопакета определялся в gitformat-pack[5] (см. раздел «обратные индексы multi-pack-index») примерно так:

В проекте инкрементального MIDX это определение расширено и включает объекты из нескольких слоёв цепочки MIDX. Порядок псевдопакета для инкрементальных MIDX определяется объединением порядков псевдопакетов каждого слоя цепочки MIDX в порядке следования слоёв. Формально два объекта o1 и o2 сравниваются следующим образом:

Обратите внимание, что предпочтительный пакет — это свойство цепочки MIDX, а не отдельных её слоёв. В принципе, можно было бы ввести предпочтительный пакет для каждого слоя, но теперь это менее актуально, поскольку можно повторно использовать объекты из нескольких пакетов в наборе пакетов MIDX.

Битовые карты достижимости и инкрементальные MIDX

Объекты каждого слоя цепочки инкрементального MIDX (а также объекты из предыдущих слоёв той же цепочки MIDX) могут быть представлены в отдельном файле *.bitmap.

Структура файла *.bitmap, относящегося к цепочке инкрементального MIDX, идентична структуре битовой карты неинкрементального MIDX или классической битовой карты одного пакета. Поскольку объекты добавляются в конец порядка псевдопакета инкрементального MIDX (см. выше), при добавлении элементов в конец цепочки MIDX битовую карту можно расширить.

(Примечание: аналогичным образом можно сжать непрерывную последовательность инкрементальных слоёв MIDX и их файлы *.bitmap в один слой и *.bitmap, но эта возможность пока не реализована.)

Используются глобальные позиции объектов в порядке псевдопакета, поэтому в последующих слоях будет, например, m->num_objects_in_base бит 0 в каждой из четырёх битовых карт типов. Это следует из того, что мы записываем записи битовой карты типов только для объектов, присутствующих в слое, которому непосредственно соответствует битовая карта.

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

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