Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Интересное описание возможностей. Спасибо.
PS: К слову сказать — да, гитхаб выпилил уже раздел «Downloads» для бинарников, но Bitbucket всё еще — нет.
Приходится держать два репозитория для взаимной компенсации возможностей.
PS: К слову сказать — да, гитхаб выпилил уже раздел «Downloads» для бинарников, но Bitbucket всё еще — нет.
Приходится держать два репозитория для взаимной компенсации возможностей.
Edit: да, это не сильно большой выход для больших бинарных ассетов
А можно амазоновское хранилище подключать в качестве файловой системы?
Например s3fs.
В таком случае можно на этой файловой системе просто создать репозиторий Git или Mercurial.
Нет. S3 предоставляет сервисы — операции, которые можно выполнять над хранилищем. Вы через API делаете запросы и получаете ответы. Также оно умеет делать публичные статические или временные ссылки на контент. Торренты создавать. Все остальное придется реализовать самому поверх этих возможностей.
Хотелось бы описание отличий (плюсов/минусов) по сравнению с largefiles (стандартное расширение Mercurial для больших бинарных файлов).
Largefiles не поддерживается в Bitbucket. Это была главная причина написания велосипеда.
Тогда наверное стоит написать об этом в статье. А безотносительно к этому есть какие-то преимущества? И ещё, насколько я понимаю по описанию с сайта Mercurial (сам не использовал largefiles), можно пушить и в репозитории, не поддерживающие эту фичу, просто не будет этих больших файлов (будут только их контрольные суммы). Собственно, у вас они тоже не хранятся в репозитории, но сделано более удобно (для случаев, когда удалённый репозиторий не поддерживает это расширение). Кстати, вот и достаточно весомый плюс хостить свои репозитории на своём сервере — можно включать любые расширения :)
К подобной программе нет жестких требований к производительности. Работает она одну секунду или пять — не столь важно.
Вопрос а чем собственно предложенное решение лучше чем родное хранение бинарников в меркуриал или гит?
Меркуриал и, вероятно, гит используют сжатые дельты для хранения изменений файлов. Сами файлы в репозитории не хранятся. Таким образом, если большой бинарный файл раз 10 менялся, то в репозитории будет храниться 10 сжатых дельт размером с сам файл. При выполнении update придется все эти дельты разжать и последовательно применить к рабочей папке. Это абсолютно ненужный оверхед. В предложенном решении такой файл просто бы скачался один раз из облака. Кроме того публичные хостинги репозиториев явно либо неявно не поддерживают большие файлы. Так как им выгоднее предоставлять платные высокоуровневые сервисы, чем низкоуровневые — размер хранилища и пропускная способность.
Меркуриал и гит не хранят дельты если размер дельт больше определенного процента размера файла, в такой ситуации они хранят копии файлов:
Для меркуриала есть механизм снепшотов который гарантирует что не требуется накладывать больше дельт чем нужно для получения целого файла
Гит оперирует всегда полными обьектами, расчет дельт выполняет нижний уровень который отвечает за хранение и для бинарников он как раз и будет держать копии файлов вместо дельт.
Кроме того я думаю что даже сжатие/расжатие дельт значительно быстрее скачки файлов по сети из облака
Для меркуриала есть механизм снепшотов который гарантирует что не требуется накладывать больше дельт чем нужно для получения целого файла
Гит оперирует всегда полными обьектами, расчет дельт выполняет нижний уровень который отвечает за хранение и для бинарников он как раз и будет держать копии файлов вместо дельт.
Кроме того я думаю что даже сжатие/расжатие дельт значительно быстрее скачки файлов по сети из облака
Согласен с тем, что меркуриал и гит могут как-то работать с большими файлами. Насчет скорости сжатия/разжатия дельт не совсем понял. Когда мыделаем pull или clone центрального репозитория, то мы должны забрать все изменения оттуда. Т. е. не только последнюю версию файла, а все дельты и снепшоты. В моем решении во время pull скачиваются только новые или обновленные файлы и только один раз.
Кроме того это не отменяет того факта, что большие репозитории с большими файлами не получится хранить в Github или Bitbucket.
Кроме того это не отменяет того факта, что большие репозитории с большими файлами не получится хранить в Github или Bitbucket.
Когда мыделаем pull или clone центрального репозитория, то мы должны забрать все изменения оттуда. Т. е. не только последнюю версию файла, а все дельты и снепшоты. В моем решении во время pull скачиваются только новые или обновленные файлы и только один раз.
Тут я с Вами согласен, однако стоит уточнить что все дельты скачиваются только если их у Вас еще не было, как правило при первоначальном checkout, потом передаются только изменения.
Кроме того это не отменяет того факта, что большие репозитории с большими файлами не получится хранить в Github или Bitbucket.
Вроде бы гитхаб не имеет жесткого ограничения на размер репозитория? Раньше я видел что ограничение было 2Гб и они предлагали предоставить больше места по требованию.
В целом да, если не хранить большие файлы, на которые сейчас есть явный лимит. Да и без лимита работать с ними, на сколько я знаю, было невозможно. Если большие файлы часто меняются, то размер репозитория быстро расти. Amazon S3 лучше подходит для подобных вещей. Там нет подобных лимитов и нет необходимости скачивать несколько версий для того, чтобы получить последнюю.
Я вообще представляю использование моего решения следующим образом: текстовые файлы хранятся в VCS, большие бинарники в облаке. При этом и размер репозитория остается маленьким, и загружать/скачивать не приходиться больше, чем нужно.
Я вообще представляю использование моего решения следующим образом: текстовые файлы хранятся в VCS, большие бинарники в облаке. При этом и размер репозитория остается маленьким, и загружать/скачивать не приходиться больше, чем нужно.
Из статьи не совсем понятно: при уже имеющемся локально репозитории (сделан pull) и выполнении hg update, файлы обновятся? Закешируются локально?
А кому-то уже пришла в голову идея подружить git и торренты, чтобы крупные файлы качались через торрент? Это бы сильно разгрузило хабы. Может уже давно есть?
Залейте в свой авто молоко — может поедет?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Расширяем Git и Mercurial репозитории с помощью Amazon S3