Git для одноранговой сети распространения контента

Question

Кто-нибудь использует git таким образом?

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

Сервер может быть любым, но я бы предпочел коробку linux.

Я подумал, что, поскольку git handle и sych различают только файлы, это был бы хороший инструмент для этой цели, и я хотел бы иметь историю изменений содержимого в качестве бонуса.

Мне нужен совет о том, как можно организовать архитектуру репозиториев: должна ли это быть топология типа «звезда» или что-то другое?

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

ОБНОВЛЕНИЕ: Я нашел здесь на SO, авторе внутренностей git (я сейчас его скачиваю), Скотт Чакон говорит об архитектуре, которую я хотел бы реализовать ,

ОБНОВЛЕНИЕ 2: ОК. Я прочитал главу о «использовании Git без SCM», и вот что говорит автор о CDN «Peer to Peer»:

Вы должны получить новый контент [...] состоят из любой комбинации XML файлы, изображения, анимация, текст и звук. Вам нужно создать контент структура распределения, которая будет легко и качественно перенести все необходимый контент для машин в вашей сети. Вам нужно постоянно определять, какой контент каждый машина есть и что для этого нужно иметь и передать разницу как эффективно, насколько это возможно. [...] Оказывается, Git является отличное решение этой проблемы.

Я не нахожу ничего относительно упоминания маленьких частей книги внутри нее, поэтому я надеюсь, что я не нарушаю никаких авторских прав. В любом случае я удалю его, если кто-то пожалуется.

Answer 1

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

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

Answer 2

Я бы посоветовал не использовать git для таких целей. Для начала, Git будет использовать дополнительную память телефона для истории ревизий, и он будет отправлять целые файлы (не дельты) в любом случае, потому что мультимедийный контент является двоичным и различие не работает с ним. Просто реализуйте метод для перечисления серверных мультимедиа с датами последнего изменения и другой метод для загрузки обновленных файлов (я бы предложил HTTP, так как он самый простой). На стороне сервера вы, конечно, можете использовать git для управления версиями мультимедийных файлов, но я бы не стал раскрывать интерфейс git.

Answer 3

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

Основное преимущество rsync (и, вероятно, унисон, хотя я никогда не использовал его) заключается в том, что вы можете строить деревья контента в индексе и хранить деревья в Git под ветвью для каждого клиента, вместо того, чтобы иметь все диск для запуска rsync. Если у вас есть несколько вариантов контента, очень здорово иметь возможность записывать уникальные деревья контента, необходимые каждому клиенту - из которых вы можете иметь тысячи комбинаций - и иметь простую команду извлечения, выбирающую только то, что нужно, и обновляющую ее на клиенте , Именно поэтому мы выбрали Git вместо rsync, чтобы сделать это. Если каждому клиенту нужен один и тот же набор данных, возможно, rsync будет проще, однако другой приятной особенностью Git является то, что вы получаете историю содержимого каждого клиента - когда и как оно изменилось для каждого отдельного клиента.

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