Создание нового транспорта для сетевого резервного копирования

Я работаю над «облачным» исследовательским проектом на основе S3 в безопасном хранилище. Я хотел бы использовать libgit2 для управления версиями в своих локальных клиентах и ​​считаю, что создание нового транспорта может быть лучшим решением. Это позволит сохранить полностью совместимую резервную локальную историю git (по сравнению с новыми бэкэндами odb или refdb).

Глядя на API, кажется, что функции загрузки и загрузки пакетных файлов будут иметь решающее значение. Чтобы поиграться с проблемой, я бы очень хотел написать S3-транспорт (бэкенд). Хотя я не верю, что это когда-либо может быть свободным от гонок (из-за возможной согласованности S3), но это должно показать большинство возможных проблем.

В настоящее время я не уверен, как создавать файлы пакетов из удаленного хранилища. С помощью git_packbuilder_insert я мог бы добавить все необходимые OID, но откуда берутся фактические данные? Это получено из репозитория (на который ссылаются при использовании packbuilder_new)? Если это так, я должен написать новый транспорт, а также соответствующий тип репозитория для этого транспорта?

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


person Andreas Happe    schedule 23.07.2014    source источник
comment
Вы имеете в виду, что хотите, чтобы пользователь мог сделать эквивалент «git push s3://whatever» для резервного копирования файлов? Если вам нужна система резервного копирования, libgit2 (или сам git), скорее всего, когда-либо сможет предоставить только небольшую структуру для управления версиями, но вам все равно нужно написать всю логику для самой резервной копии.   -  person Carlos Martín Nieto    schedule 23.07.2014
comment
@CarlosMartínNieto: да. Я хочу использовать libgit2 для обеспечения версий, тегов и т. д. (чтобы мне не пришлось писать их самому). Это часть более крупного проекта. Окончательный бэкэнд будет чем-то проприетарным (я пытаюсь убедить компанию поступить иначе, но не слишком на это надеюсь), но я бы хотел провести проверку концепции (которой будет S3), которая может быть OSS, если кому-то нужен код.   -  person Andreas Happe    schedule 24.07.2014


Ответы (1)


S3 не использует смарт-протокол и не выдает за вас пакетные файлы, а это означает, что вам придется создать какой-то транспортный уровень, который принимает объекты Git, хранящиеся в S3, и передает их libgit2 каким-то образом, который он может использовать.

Это именно назначение слоя ODB. Если вы создали ODB, которая считывает данные из S3 и записывает их в S3, вы сможете создать git_repository из этого внутреннего хранилища. Как только вы это сделаете, вы сможете предоставить необходимые механизмы для локального клонирования.

Или, если вам нужен один git_repository, который поддерживается как файлом, так и S3, вы можете создать слой ODB в стиле тройника, который будет записывать как в один из драйверов ODB локальной файловой системы, так и в S3 ODB.

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

person Edward Thomson    schedule 23.07.2014
comment
Хорошо, мне нужно снова проверить документацию. Я думал, что ODB будет использоваться только для «локального» хранилища (т.е. .git/objects). Если я предоставлю пользовательский (т.е. основанный на S3) бэкэнд ODB, часть objectdb .git исчезнет, ​​и автономная операция больше не будет работать. Причина использования пользовательского транспорта заключалась в том, что он по-прежнему позволял работать в автономном режиме и сохранял совместимость рабочего каталога с git. - person Andreas Happe; 24.07.2014
comment
Может быть, я не понимаю, что вы пытаетесь сделать; но ODB будет работать только тогда, когда вы в сети, точно так же, как транспорт будет работать только тогда, когда вы в сети? Вам наверняка понадобятся два ODB, один для локального хранилища (.git/objects), который всегда включен, и один для удаленного...? - person Edward Thomson; 24.07.2014
comment
Предыстория: я занимаюсь безопасным ``облачным'' решением для хранения, которое предлагает интерфейс Key/Value-Interface. Теперь я хотел добавить программное обеспечение, которое должно обеспечивать периодическое резервное копирование с сервера (обычный каталог данных) на сервер резервного копирования в облаке. Поскольку мне нужно создавать версии каталога на стороне сервера, хранить его историю и т. д., я подумал об использовании libgit2 для всего этого. Во-первых, глупая ли это идея? Я неправильно понял документацию, поэтому я мог использовать 2 ODB в репозитории: один для локального хранилища (.git) и один для удаленного хранилища резервных копий? Спасибо за ваши усилия! - person Andreas Happe; 01.08.2014