Есть ли хороший способ обработки больших активов (например, 1000 изображений, флеш-роликов и т.д.) с помощью инструмента DVCS, такого как hg и git. Как я вижу, клонировать хранилища, которые заполнены ресурсами 4 ГБ, кажется ненужными накладными расходами, поскольку вы будете проверять файлы. Это кажется довольно громоздким, если исходный код смешан с файлами активов.
Есть ли у кого-нибудь мысли или опыт в этом контексте в контексте веб-разработки?
Вот некоторые мысли, которые я имел по этому вопросу. В конце концов, вам может потребоваться как можно больше сохранить активы и код. Я могу думать о нескольких возможных стратегиях:
Активы в одном репо и код в другом.
Инструменты DVCS не отслеживают другие репозитории, чем их собственные, поэтому нет прямой поддержки спецификации (спецификации), т.е. нет четкого способа определить, когда оба хранилища находятся в синхронизации. (Я думаю, что это git-submodule или repo для).
Пример: художник добавляет новое изображение в один репозиторий, а программист добавляет функцию для использования изображения, однако, когда кто-то должен возвращать версии, они вынуждены как-то самостоятельно отслеживать эти изменения.
Накладные расходы на репозитории активов, даже если они влияют только на тех, кто его использует.
Активы и код находятся в одном репозитории, но они находятся в двух отдельных каталогах.
Обе стратегии, перечисленные выше, все еще имеют недостаток в наличии больших накладных расходов, поскольку вам необходимо клонировать хранилище больших активов. Одним из решений этой проблемы является вариант первой стратегии выше, два репозитория; сохранить код в распределенном репо VCS и активах в централизованном репо (VCS, Alienbrain и т.д.).
Учитывая, как большинство графических дизайнеров работают с бинарными файлами, обычно нет необходимости в ветвлении, если это действительно необходимо (новые функции требуют много ресурсов, которые не нужны до тех пор, пока они не будут намного позже). Недостатком является то, что вам нужно будет найти способ резервного копирования центрального хранилища. Следовательно, третья стратегия:
Код в репозитории, как обычно, и активы не находятся в репозитории. Активы должны быть помещены в какую-то систему управления контентом/медиа/активами или, по крайней мере, находятся в папке, которая регулярно резервируется. Это предполагает, что очень мало нужно для отслеживания версий с графикой. Если есть необходимость в обратном отслеживании, тогда графические изменения незначительны.
Мысли, никакого опыта: я бы действительно отделил код от данных. Предполагая, что существует набор изображений, которые принадлежат к приложению, я бы просто сохранил это на централизованном сервере. В коде я бы затем организовал (посредством явного кодирования), что приложение может интегрировать как локальные, так и удаленные активы. Затем вкладчики могут помещать новые изображения в свой локальный магазин, интегрируя их с какой-либо (явной) процедурой загрузки в центральный магазин, когда это требуется и одобрено.
Я боролся с этим сам. Как вы сказали, версия GBs активов может быть огромной болью.
Для проектов, требующих внешнего участия, я нашел Mercurial рабочим решением, но не отличным. Он ест дисковое пространство для больших файлов и может быть довольно медленным в зависимости от обстоятельств.
Для моей внутренней проектной работы я предпочитаю использовать простые инструменты синхронизации (rsync, synctoy, any else), чтобы поддерживать каталоги в актуальном состоянии между серверами/машинами, а затем выполнять управление версиями вручную. Я считаю, что мне редко приходится контролировать версию для чего-либо, кроме серьезных изменений.