Да, этот момент я упустил, спасибо. Обновил пример hgrc. Использование хука postupdate позволяет выполнять скачивание файлов после апдейта, при этом скачаются именно те версии файлов, которые указаны в обновленном xml файле.
В целом да, если не хранить большие файлы, на которые сейчас есть явный лимит. Да и без лимита работать с ними, на сколько я знаю, было невозможно. Если большие файлы часто меняются, то размер репозитория быстро расти. Amazon S3 лучше подходит для подобных вещей. Там нет подобных лимитов и нет необходимости скачивать несколько версий для того, чтобы получить последнюю.
Я вообще представляю использование моего решения следующим образом: текстовые файлы хранятся в VCS, большие бинарники в облаке. При этом и размер репозитория остается маленьким, и загружать/скачивать не приходиться больше, чем нужно.
Согласен с тем, что меркуриал и гит могут как-то работать с большими файлами. Насчет скорости сжатия/разжатия дельт не совсем понял. Когда мыделаем pull или clone центрального репозитория, то мы должны забрать все изменения оттуда. Т. е. не только последнюю версию файла, а все дельты и снепшоты. В моем решении во время pull скачиваются только новые или обновленные файлы и только один раз.
Кроме того это не отменяет того факта, что большие репозитории с большими файлами не получится хранить в Github или Bitbucket.
Меркуриал и, вероятно, гит используют сжатые дельты для хранения изменений файлов. Сами файлы в репозитории не хранятся. Таким образом, если большой бинарный файл раз 10 менялся, то в репозитории будет храниться 10 сжатых дельт размером с сам файл. При выполнении update придется все эти дельты разжать и последовательно применить к рабочей папке. Это абсолютно ненужный оверхед. В предложенном решении такой файл просто бы скачался один раз из облака. Кроме того публичные хостинги репозиториев явно либо неявно не поддерживают большие файлы. Так как им выгоднее предоставлять платные высокоуровневые сервисы, чем низкоуровневые — размер хранилища и пропускная способность.
Это не решит проблемы. DVSC с большими файлами работают плохо. Хостинги репозиториев с большими файлами не работают вообще. Т. е. такой репозиторий будет неюзабельным и его нельзя будет держать на Github или Bitbucket.
Нет. S3 предоставляет сервисы — операции, которые можно выполнять над хранилищем. Вы через API делаете запросы и получаете ответы. Также оно умеет делать публичные статические или временные ссылки на контент. Торренты создавать. Все остальное придется реализовать самому поверх этих возможностей.
Сильно зависит от задач и области ответственности. Для типовых и мелких задач это справедливо. Риски не так велики. Для сложных, комплексных — уже нет. Слишком много переменных. Без реального опыта искать придется долго, зачастую безрезультатно, придется наступать на грабли не раз и не два. Без хоть каких-то знаний вообще в предметной области, технологиях и инструментах искать становится просто бессмысленно.
Жесты, изображенные на картинке, не являются частью патента. Они служат лишь примером и не указаны в клаймах. А указан там мобильный девайс, для распознавания жестов с помощью инфракрасного проектора и камеры. Вот только я не понял, эти проектор и камера должны быть на самом девайсе, на подставке или и там и там.
Я думаю, что много кто из программистов хотя бы начинал писать свою игру. Но не думаю, что многим удалось довести дело до конца. Это заслуживает уважения.
Рассматривается ли вариант создания поверхности на основе октодерева — вершинных и индексных буферов для отрисовки в GPU? А также использования instancing и geometry shaders для оптимизации?
Я вообще представляю использование моего решения следующим образом: текстовые файлы хранятся в VCS, большие бинарники в облаке. При этом и размер репозитория остается маленьким, и загружать/скачивать не приходиться больше, чем нужно.
Кроме того это не отменяет того факта, что большие репозитории с большими файлами не получится хранить в Github или Bitbucket.