Как я могу управлять крупными художественными активами надлежащим образом в DVCS?

Ответ 1

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

Распределенные, два репозитория

Активы в одном репо и код в другом.

Преимущества

• В контексте веб-разработки вам не нужно клонировать хранилище гигантских активов, если вы не работаете напрямую с графическими файлами. Это возможно, если у вас есть веб-сервер, который обрабатывает активы отдельно от динамического контента (PHP, ASP.NET, RoR и т.д.) И синхронизируется с репо-активом.

Недостатки

• Инструменты DVCS не отслеживают другие репозитории, чем их собственные, поэтому нет прямой поддержки спецификации (спецификации), т.е. нет четкого способа определить, когда оба хранилища находятся в синхронизации. (Я думаю, что это git-submodule или repo для).

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

• Накладные расходы на репозитории активов, даже если они влияют только на тех, кто его использует.

Распределенный, один репозиторий

Активы и код находятся в одном репозитории, но они находятся в двух отдельных каталогах.

Преимущества

• Версии кода и активов переплетаются, поэтому спецификация является практической. Откат возможен без особых проблем.

Недостатки

• Поскольку распределенные средства контроля версий отслеживают всю структуру проекта, обычно нет возможности просто проверить один каталог.
• У вас все еще есть проблема с издержками хранилища. Более того, вам нужно проверить активы, а также код.

Обе стратегии, перечисленные выше, все еще имеют недостаток в наличии больших накладных расходов, поскольку вам необходимо клонировать хранилище больших активов. Одним из решений этой проблемы является вариант первой стратегии выше, два репозитория; сохранить код в распределенном репо VCS и активах в централизованном репо (VCS, Alienbrain и т.д.).

Учитывая, как большинство графических дизайнеров работают с бинарными файлами, обычно нет необходимости в ветвлении, если это действительно необходимо (новые функции требуют много ресурсов, которые не нужны до тех пор, пока они не будут намного позже). Недостатком является то, что вам нужно будет найти способ резервного копирования центрального хранилища. Следовательно, третья стратегия:

Активы вне репозитория (или Активы в CMS)

Код в репозитории, как обычно, и активы не находятся в репозитории. Активы должны быть помещены в какую-то систему управления контентом/медиа/активами или, по крайней мере, находятся в папке, которая регулярно резервируется. Это предполагает, что очень мало нужно для отслеживания версий с графикой. Если есть необходимость в обратном отслеживании, тогда графические изменения незначительны.

Преимущества

• Не раздувает репозиторий кода (полезно, например, git, поскольку он часто проверяет файлы)
• Обеспечивает гибкую обработку таких активов, как развертывание активов на серверах, предназначенных только для активов.
• Если на CMS с API, активы должны быть относительно просты в обращении в коде

Недостатки

• Нет поддержки спецификации.
• Непростая расширенная поддержка back-tracking версии, это зависит от стратегии резервного копирования для ваших активов.

Ответ 2

Мысли, никакого опыта: я бы действительно отделил код от данных. Предполагая, что существует набор изображений, которые принадлежат к приложению, я бы просто сохранил это на централизованном сервере. В коде я бы затем организовал (посредством явного кодирования), что приложение может интегрировать как локальные, так и удаленные активы. Затем вкладчики могут помещать новые изображения в свой локальный магазин, интегрируя их с какой-либо (явной) процедурой загрузки в центральный магазин, когда это требуется и одобрено.

Ответ 3

Я боролся с этим сам. Как вы сказали, версия GBs активов может быть огромной болью.

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

Для моей внутренней проектной работы я предпочитаю использовать простые инструменты синхронизации (rsync, synctoy, any else), чтобы поддерживать каталоги в актуальном состоянии между серверами/машинами, а затем выполнять управление версиями вручную. Я считаю, что мне редко приходится контролировать версию для чего-либо, кроме серьезных изменений.