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

Question

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

1

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

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

Сервер может быть любым, но я бы предпочел использовать linux box.

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

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

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

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

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

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

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

microspino 04 авг. 2010, в 12:03

Источник

0

Вы можете взломать git, чтобы заставить его делать то, что вы хотите, но неясно, какое преимущество это дает по сравнению с программой, которая была разработана как система распространения контента.
masonk 05 авг. 2010, в 13:43
0

Возможные преимущества для клиента: он получит только то, что ему действительно нужно. Проверяет целостность объектов. Не берите вещи, которые уже есть под другими именами. Возобновить прерванные загрузки (http). Весы хорошо.
microspino 10 авг. 2010, в 04:44
0

Опять же, ни одно из этих преимуществ не является преимуществом перед такими программами, как rsync, unison или сотнями других специализированных систем распространения контента.
masonk 11 авг. 2010, в 14:54
0

Хорошо, я буду расследовать в rsynch и унисон и все остальное, что я мог найти.
microspino 11 авг. 2010, в 15:32

Показать ещё 2 комментария

Теги:

android

git

cdn

3 ответа

2

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

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

masonk 04 авг. 2010, в 10:31

2

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

Gintautas Miliauskas 04 авг. 2010, в 08:09

0

Я вижу, спасибо большое за то, что указали на то, что СМИ не распространяются. Вы думаете, что Скотт Чакон github.com/schacon/git-media мог решить эту проблему?
microspino 04 авг. 2010, в 10:25
1

git использует libxdiff для дельтафикации и поддерживает двоичные различия. Тем не менее, обратите внимание, что большинство двоичных файлов не очень хорошо дельта
Jakub Narębski 04 авг. 2010, в 23:27
0

Я исправлен, Git делает бинарные различия. Спасибо, Якуб.
Gintautas Miliauskas 04 авг. 2010, в 23:41

Показать ещё 1 комментарий

Ещё вопросы

Вы можете взломать git, чтобы заставить его делать то, что вы хотите, но неясно, какое преимущество это дает по сравнению с программой, которая была разработана как система распространения контента.
Возможные преимущества для клиента: он получит только то, что ему действительно нужно. Проверяет целостность объектов. Не берите вещи, которые уже есть под другими именами. Возобновить прерванные загрузки (http). Весы хорошо.
Опять же, ни одно из этих преимуществ не является преимуществом перед такими программами, как rsync, unison или сотнями других специализированных систем распространения контента.
Хорошо, я буду расследовать в rsynch и унисон и все остальное, что я мог найти.
Я вижу, спасибо большое за то, что указали на то, что СМИ не распространяются. Вы думаете, что Скотт Чакон github.com/schacon/git-media мог решить эту проблему?
git использует libxdiff для дельтафикации и поддерживает двоичные различия. Тем не менее, обратите внимание, что большинство двоичных файлов не очень хорошо дельта
Я исправлен, Git делает бинарные различия. Спасибо, Якуб.

Scott Chacon · Accepted Answer · 2010-08-11T15-09-00.000Z

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

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

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