hbs2/docs/todo/hbs2-git-new-repo.txt

FIXME: filter-existed-objects-from-log
  Сейчас если коммит ссылается на уже существующие в стейте
  объекты, они всё попадут в лог. Нужно отфильтровывать их
  оттуда

TODO: faster-git-clone
  Медленное клонирование.
  Можно попытаться оптимизировать, можно
  попытаться сделать через fast-import -- т.е
  дампить объекты в формате fast-import-stream,
  должно быть намного быстрее

FIXME: faster-export
  Сейчас обходятся вообще все коммиты в git rev-list,
  а можно только те, которых нет в стейте - т.е начиная
  с какого-то. Ну например, для данной ссылке брать коммит
  с максимальной высотой (глубиной) и rev-list делать до него.
  Пример:
  ```
      [dmz@minipig:~/w/hbs2]$ git rev-list --objects 640c447e9dca6a32ecb80f85f2d3ab9ad45dc91e..
    0e887a87e30005a8ebdb43aa5bf0ed78383cf52a
    5509c970621a75c9f82b4d2743fd211c1165e61f
    7f0c4c0659367ae10bd3eb84b7bc26f09dd26282 hbs2-git
    6d38123f72101aa6a66c35ced40f5dd156a722c4 hbs2-git/lib
    1aadc3441288d6d4f9fddb00342dd296242ded1a hbs2-git/lib/HBS2Git
    bb270a54495fdf44e831b53c63b5814a44d354af hbs2-git/lib/HBS2Git/State.hs
  ```

TODO: git-tags-support
  Поддержать теги, в т.ч. подписанные.
  Неподписанные возможно  и так будут работать.

TODO: log-object-reorder-for-better-dedup
 Вот что еще заметил: сейчас пишу в логи операции в порядке:
 (коммит, зависимости). Поскольку так удачно сложилось, что гит
 новые коммиты делает не дельтами, а все объекты целиком пишет,
 то что бы там разработчик не мутил - сквошил, мержил, ребейзил
 - итоговые блобы и деревья (снапшот проекта) — выглядят
 довольно константными.  таким образом, если сначала в лог
 писать деревья и блобы, а в конец - коммиты,  то есть шансы,
 что префикс лога будет более константным, что ли. т.е при
 последующем разбиении на сегменты есть шансы, что сегменты в
 начале лога будут лучше дедупиться.


FIXME: segmented-log-import-issue
  заметил, что не сразу срабатывает fetch,
  а только после скана.

  Выяснить, почему.

  Появилось только после сегментации лога,
  возможно, связано с асинхронностью прибытия секций,
  а может, сломан импорт. Проверить.


FIXME: hbs2-segmented-log-remove-temp-files-ASAP
 Удалять временные файлы при импорте (и экспорте)
 максимально быстро.
 Наличие огромного количества временных файлов в каталоге
 убивает произодительность, и сильно жрёт дисковый ресурс
 и память, если это tmpfs, драматически замедляя процесс
 импорта/экспорта

FIXME: check-merkle-meta
  Проверять метаданные аннотированного дерева.
  Писать версию лога в эти данные.

FIXME: mandatory-compress-whole-log
  Эксперимент показал разницу в размере репозитория git и
  соответствующего ему стейта hbs2-git приблизительно в 10 раз (!!).

  Очевидно, что git сжимает даже лучше, чем мы бы просто сжали его
  объекты архиватором, он проделывает еще некоторые дополнительные
  манипуляции, к которым шёл годами.

  Всё, что мы пока можем сделать --- это хотя бы сжимать секции лога
  целиком.

  Вопрос, ломать или не ломать при этом совместимость, т.е оставить ли
  возможность несжатых логов.

  Указывать ли информацию в аннотации дерева, либо же завести секцию
  лога, указывающую, что за ней следуют сжатые данные.

  Сжатие на уровне лога целиком нужно обязательно, т.к. сейчас мы
  имеем стейт размера 36G вместо 3.5G на тестовом примере репозитория
  nixpkgs.

  Сжатие лога внутри секций неэффективно и, кажется, бесполезно.

  Если его дропнуть, то поломается совместимость.

  Если оставить, но поставить нулевую компрессию --- то будет
  бесполезное замедление работы.

  Сжимать на уровне лога целиком --- правильно.

  Но если иметь несегментированный лог, или очень большой размер
  сегмента, то это будет очень медленно, и чем больше файл, тем хуже
  будет ситуация.

  На сжатии в памяти, кроме того, мы можем исчерпать память.

TODO: reflog-purge-function-ASAP
  Рекурсивное удаление всех данных ссылки при удалении
  ссылки.

  Сейчас есть рекурсивное удаление дерева, но для ссылок
  будет удалён только журнал транзакций, а сами данные
  останутся.

  Можно парсить ссылку, и если там обнаруживаем там дерево,
  то сносить его рекурсивно.

  Это надо сделать ASAP, т.к. растёт стейт на тестовых данных,
  надо сносить.



NOTE: wtf?

FIXME: hbs2-git-storeObject-read-chunked
 возможно, очень большой mem footprint при экспорте
 больших репо объясняется тем, что мы читаем файл
 целиком (хоть в LBS). Попробовать читать частями.

TODO: reflog-monitoring-features
  сделать возможность теста рефлога и перезапроса
  его секций. почему-то сейчас рефлог подъехал не сразу,
  это довольно тревожно.


TODO: hbs2-peer-dynamic-reflog-subscription
  сделать динамическую персистентную подписку
  на рефлоги.
  hbs2-peer reflog add REFLOG <poll-time-min>
  hbs2-peer reflog list
  hbs2-peer reflog del
  сделать соответствующие API

  git clone hbs2://XXX --- добавляет подписку динамически (?)
  или по крайней мере может, если есть такая опция в конфиге

TODO: hbs2-git-remove-REFLOG-from-export
  Можно же использовать ключ, если он передан.
  Таким образом, параметр можно сделать необязательным,
  и если он не задан, то брать из ключа.

TODO: hbs2-git-export-segment-params-to-export-ASAP
  Отдельно обрабатывать блобы, деревья и коммиты
  при экспорте. Ввести умолчания -- для блобов
  сегмент меньше, для блобов --- больше.
  Нужно, так как блобы обычно больше, tree -- в зависимости
  от проекта, коммиты -- более менее стабильного размера и
  маленькие.

TODO: hbs2-git-http
  Реализовать простой http сервер для отдачи объектов
  по git протоколу, что бы локально работало клонирование
  объектов и т.п.

  В самом последнем случае --- просто клонируем каталог
  и отдаём файлы из него.

  В текущей реализации:

  - Время от времени синхронизируем репо (git fetch) ?

  1. По запросу -- выясняем, в каком логе лежит объект
  2. Сканируем лог, сохраняем все объекты из него, запоминаем
  3. Отдаём сохраненные объекты (с tmp, sendfile-ом?)
  4. Время от времени (config) зачищаем файлы