Использование Git в качестве бэк-энда для сервера обновлений, как сохранить маленький репозиторий

Question

Вот мой вариант использования. У меня есть настольное приложение, которое может загружать с моего сервера медиа-контент по требованию. Каждую неделю или около того новые медиа будут загружаться / переименовываться / изменяться и т. Д. На сервере, и клиенты будут отправлять мне запросы каждый день или около того, чтобы проверить, есть ли доступные обновления, которые они должны загрузить.

Чтобы точно и легко определить новые файлы, которые нужны клиентам, я думал об использовании Git на сервере и сохранении для каждого клиента хеш-версии данных, которые он загрузил. После каждого запроса на обновление я могу легко проверить с помощью Git, какие файлы были добавлены, удалены, переименованы и т. Д. С помощью чего-то вроде git diff --name-status -C HEAD <clientRevision>, а затем отправлять только необходимые обновления.

Мой вопрос: очевидно, мне не нужно хранить всю двоичную историю моих носителей на сервере. Мне все равно, как выглядит файл X два месяца назад; Мне просто нужно знать, было ли оно изменено за это время или переименовано, например, с Y на X. Можно ли использовать Git таким образом, чтобы я мог избавиться от «двоичной истории» файлов, в то же время отслеживая, какие файлы были изменены, добавлены, удалены и переименованы? Или есть другой очевидный технологический выбор, который я упустил для такого сценария?

(Да, я хотел бы использовать rsync для всего этого; к сожалению, единственное, что я знаю от своих клиентов, это то, что они работают на JVM, могут использовать порт 80 и могут записывать в каталог, который должен содержат необходимые медиа-файлы, поэтому rsync, к сожалению, не подходит.)

Answer 1

Git отличный, но не подходящий инструмент для работы.Если вы не интересуетесь историей и у вас большие двоичные файлы, git просто вызовет проблемы.

Вместо этого я рекомендую небольшую базу данных SQL для метаинформации и каталог на диске для хранения файлов мультимедиа..

Сначала файлы мультимедиа on-dist: чтобы разрешить обнаружение повреждений и поддерживать переименование без повторной передачи больших файлов мультимедиа, присвойте файлам имена по их SHA (или MD5 или почти любому подходящему алгоритму контрольной суммы).Вы можете связать «реальное» имя файла или использовать таблицу перевода (возможно, из БД, возможно, нет), чтобы представить хорошее имя пользователю.

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

Используя это, вы можете мгновенно точно указать, на какие медиа-файлы нужно отправлятьпользователь

select clientid,mediaid from tmedia join tclients on tmedia.revisionid > tclients.revisionid;

Вы можете мгновенно указать, какие именно новые сопоставления файлов необходимо отправить:

select mediaid,filename,clientid from tmapping join tclients on tmapping.revisionid > tclients.revisionid;

Если вы когда-либо подозреваете повреждение (или периодически), вы можете проверить носитель наклиент и сервер вычисляют SHA и сравнивают его с именем файла, а затем ищут его в таблице сопоставления (и клиент, и сервер), и в таблице мультимедиа (сервер).Кроме того, просто отправьте последний файл сопоставления (или раздел файла сопоставления, или контрольную сумму файла сопоставления), чтобы проверить, что там происходит.Простой, легкий для понимания и простой в разработке.

Answer 2

См. Мой комментарий для реального ответа, но комментарии не допускают правильного форматирования.

Вот краткий набросок безумной идеи, если вы хотите пойти с git. Я понимаю, что у вас есть контроль над клиентскими устройствами и что вы можете запускать git на этих устройствах. Вы можете создать зеркальное дерево хэшей (например, md5 / sha1 хэши) исходных двоичных файлов. Затем Git просматривает «hashtree», чтобы определить, что нового, и не забудьте получить фактические данные перед обновлением git. Вот так

/actual/somedir/imag1.jpg


/mirror/somedir/imag1.jpg  <= contains md5 hash

Answer 3

Hallo,

У вас есть порт 80 от клиента к серверу, которым вы управляете.Я полагаю, вы можете использовать другой клиент, кроме git, на клиенте.

Не используйте git для извлечения данных с сервера.Попробуйте использовать простой HTTP-клиент и HTTP-методы, разработанные для этого: HEAD, чтобы узнать, изменился ли файл, и если да, ПОЛУЧИТЕ его.Существует возможность придать вашему репозиторию сервера некоторую разметку: скачать индексный файл для этого конкретного клиента, а затем проверить каждый файл в этом индексе.Получите вдохновение из репозиториев Debian Apt - различий, подписи файлов и т. Д., Если это будет работать для вашего случая использования.WebDav - еще один вариант доступа к серверу, предлагающий еще больший комфорт.Вы не говорите об аутентификации, которая может потребоваться.Если клиент говорит по HTTP, вы можете использовать (кэширующий) прокси.

Вы можете хранить свои данные, дерево, представленное через HTTP-сервер, в репозитории git.Замена бинарных файлов небольшим файлом, содержащим хэши (как предложил Клаас ван Шельвен), и вы даже можете добавить другие метаданные, журнал изменений, временные отметки или авторов файлов и т. Д.