Интересное описание возможностей. Спасибо.

PS: К слову сказать — да, гитхаб выпилил уже раздел «Downloads» для бинарников, но Bitbucket всё еще — нет.
Приходится держать два репозитория для взаимной компенсации возможностей.
Гитхаб же на днях запилил релизы: github.com/blog/1547-release-your-software

Edit: да, это не сильно большой выход для больших бинарных ассетов
О! Не знал, спасибо за линк.

Однако, справедливости ради, надо отметить что «кнопка» releases слепая и мелкая, а главное, не такая интуитивно понятная для конечного пользователя, как Download.
А можно амазоновское хранилище подключать в качестве файловой системы?
Например s3fs.
В таком случае можно на этой файловой системе просто создать репозиторий Git или Mercurial.
Это не решит проблемы. DVSC с большими файлами работают плохо. Хостинги репозиториев с большими файлами не работают вообще. Т. е. такой репозиторий будет неюзабельным и его нельзя будет держать на Github или Bitbucket.
git-annex и hg largefiles.
Насчет первого не знаю, а второй не поддерживается в Bitbucket.
Нет. S3 предоставляет сервисы — операции, которые можно выполнять над хранилищем. Вы через API делаете запросы и получаете ответы. Также оно умеет делать публичные статические или временные ссылки на контент. Торренты создавать. Все остальное придется реализовать самому поверх этих возможностей.
Хотелось бы описание отличий (плюсов/минусов) по сравнению с largefiles (стандартное расширение Mercurial для больших бинарных файлов).
Largefiles не поддерживается в Bitbucket. Это была главная причина написания велосипеда.
Тогда наверное стоит написать об этом в статье. А безотносительно к этому есть какие-то преимущества? И ещё, насколько я понимаю по описанию с сайта Mercurial (сам не использовал largefiles), можно пушить и в репозитории, не поддерживающие эту фичу, просто не будет этих больших файлов (будут только их контрольные суммы). Собственно, у вас они тоже не хранятся в репозитории, но сделано более удобно (для случаев, когда удалённый репозиторий не поддерживает это расширение). Кстати, вот и достаточно весомый плюс хостить свои репозитории на своём сервере — можно включать любые расширения :)
К подобной программе нет жестких требований к производительности. Работает она одну секунду или пять — не столь важно.

Вопрос а чем собственно предложенное решение лучше чем родное хранение бинарников в меркуриал или гит?
Меркуриал и, вероятно, гит используют сжатые дельты для хранения изменений файлов. Сами файлы в репозитории не хранятся. Таким образом, если большой бинарный файл раз 10 менялся, то в репозитории будет храниться 10 сжатых дельт размером с сам файл. При выполнении update придется все эти дельты разжать и последовательно применить к рабочей папке. Это абсолютно ненужный оверхед. В предложенном решении такой файл просто бы скачался один раз из облака. Кроме того публичные хостинги репозиториев явно либо неявно не поддерживают большие файлы. Так как им выгоднее предоставлять платные высокоуровневые сервисы, чем низкоуровневые — размер хранилища и пропускная способность.
Меркуриал и гит не хранят дельты если размер дельт больше определенного процента размера файла, в такой ситуации они хранят копии файлов:
Для меркуриала есть механизм снепшотов который гарантирует что не требуется накладывать больше дельт чем нужно для получения целого файла
Гит оперирует всегда полными обьектами, расчет дельт выполняет нижний уровень который отвечает за хранение и для бинарников он как раз и будет держать копии файлов вместо дельт.
Кроме того я думаю что даже сжатие/расжатие дельт значительно быстрее скачки файлов по сети из облака
Согласен с тем, что меркуриал и гит могут как-то работать с большими файлами. Насчет скорости сжатия/разжатия дельт не совсем понял. Когда мыделаем pull или clone центрального репозитория, то мы должны забрать все изменения оттуда. Т. е. не только последнюю версию файла, а все дельты и снепшоты. В моем решении во время pull скачиваются только новые или обновленные файлы и только один раз.

Кроме того это не отменяет того факта, что большие репозитории с большими файлами не получится хранить в Github или Bitbucket.
Когда мыделаем pull или clone центрального репозитория, то мы должны забрать все изменения оттуда. Т. е. не только последнюю версию файла, а все дельты и снепшоты. В моем решении во время pull скачиваются только новые или обновленные файлы и только один раз.

Тут я с Вами согласен, однако стоит уточнить что все дельты скачиваются только если их у Вас еще не было, как правило при первоначальном checkout, потом передаются только изменения.

Кроме того это не отменяет того факта, что большие репозитории с большими файлами не получится хранить в Github или Bitbucket.

Вроде бы гитхаб не имеет жесткого ограничения на размер репозитория? Раньше я видел что ограничение было 2Гб и они предлагали предоставить больше места по требованию.
В целом да, если не хранить большие файлы, на которые сейчас есть явный лимит. Да и без лимита работать с ними, на сколько я знаю, было невозможно. Если большие файлы часто меняются, то размер репозитория быстро расти. Amazon S3 лучше подходит для подобных вещей. Там нет подобных лимитов и нет необходимости скачивать несколько версий для того, чтобы получить последнюю.

Я вообще представляю использование моего решения следующим образом: текстовые файлы хранятся в VCS, большие бинарники в облаке. При этом и размер репозитория остается маленьким, и загружать/скачивать не приходиться больше, чем нужно.
Из статьи не совсем понятно: при уже имеющемся локально репозитории (сделан pull) и выполнении hg update, файлы обновятся? Закешируются локально?
Да, этот момент я упустил, спасибо. Обновил пример hgrc. Использование хука postupdate позволяет выполнять скачивание файлов после апдейта, при этом скачаются именно те версии файлов, которые указаны в обновленном xml файле.
А кому-то уже пришла в голову идея подружить git и торренты, чтобы крупные файлы качались через торрент? Это бы сильно разгрузило хабы. Может уже давно есть?
Залейте в свой авто молоко — может поедет?
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.