Мы - команда, которая думает о создании игры с помощью Unreal Development Kit, и мы ищем решения для контроля версий.
Я всегда предпочитал децентрализованные VCS, такие как Git и Mercurial, и использовал его для всех моих личных проектов. Хотя я слышал о проблемах разработки игр с использованием этих систем, поскольку они не подходят для больших двоичных файлов.
Subversion кажется хорошим решением, однако я не использовал его вообще в прошлом, поэтому я действительно не знаю, что он предлагает.
Вы можете использовать Mercurial или Git без проблем. Я не знаю, почему @TomTom заявляет об этом иначе, не указав на причины.
Конечно, вам придется управлять различными бинарными файлами, которые прилагаются к каждой разработке игр (фильмы, текстуры, карты и т.д.). Но у обоих программ есть способы справиться с ними.
Mercurial имеет различные расширения для работы с большими файлами, особенно с двоичными.
Начиная с версии 2.0, в Mercurial включен расширение большого файла, и вы можете использовать его, не загружая ничего. Файлы не хранятся непосредственно в репозитории, но Mercurial отслеживает, какая версия файла необходима для каждого набора изменений, поэтому вы можете загрузить точную версию своей игры с нужным файлом, когда вам это нужно.
До 2.0 в основном использовалось два расширения:
Я не очень хорошо знаком с возможностями Git для обработки больших файлов, но я знаю, что существует различное решение. Этот пост должен дать несколько хороших указателей: Управление большими двоичными файлами с помощью git
Я слышал много хорошего о git-annex.
Я использовал SVN с большими файлами, и у меня нет впечатления, что он управляет ими лучше, чем Mercurial (без расширений) из коробки.
Если вы решите использовать расширение для управления большими файлами с помощью Mercurial/ Git, Subversion отстает по функциональности.
О вашей заботе о том, чтобы синхронизировать двоичные файлы с источником, бот Mercurial и расширения Git обрабатывают это очень хорошо.
Каждая версия двоичных файлов хранится в отдельном централизованном каталоге (largefile store в терминах Mercurial), и когда dev клонирует репозиторий или обновляет конкретный набор изменений, только необходимые файлы загружаются из этого магазина.
Вы даже можете использовать один и тот же магазин для различных репозиториев!
Процесс добавления файла в хранилище или его обновления почти прозрачен для разработчика, поэтому нет проблем с длинной кривой обучения, например.
В заключение я действительно не понимаю, почему Git или Mercurial не соответствуют задаче, и никакой другой ответ не дает никакой реальной причины.
По моему мнению, компании большой игры придерживаются старых инструментов, потому что изменение требует времени, а когда вы что-то платили, вы его используете! Сколько компаний там все еще используют VSS или CVS только потому, что иерархия ничего не услышит о чем-то другом? Мы только что мигрировали в TFS (из VSS) в прошлом месяце, где я работаю...
Я бы придерживался Git. То, что вы можете потерять при хранении больших двоичных файлов, вы будете больше, чем получить возможность работать вместе как команда. Вы будете обновлять, изменять, объединять свой код намного больше, чем просто хранить двоичные файлы, а DVCS справляются с этим намного лучше.
Hq (Mercurial) 2.0 поддержка больших файлов замечательна.
Раньше он был LargefilesExtension, но из версии 2.0 он распространяется с ядром.
Большие игровые студии обычно используют http://www.perforce.com/ (честно говоря, я понятия не имею, почему.)
SVN - довольно хороший вариант, но он немного устарел по сравнению с Git и Mercurial.
В любом случае, зачем вы кладете большие большие файлы в репозиторий? Вы обязательно захотите добавить строки игнорирования для всех скомпилированных двоичных файлов и т.д. Всегда следите за тем, чтобы включать только исходные файлы: -)
Лично я бы придерживался Mercurial или Git.
Я всегда предпочитал децентрализованные VCS, такие как Git и Mercurial,
ПОЛНОСТЬЮ непригодным для использования. Точка.
Фокус в том, что вы не можете иметь один распределенный репозиторий, когда ваш репозиторий является значительным, и это значение (количество данных), возможно, не имеет отношения к большинству людей.
Если вы занимаетесь разработкой игр, у вас будет множество активов, контролируемых версиями, в которых программисты интересуются ZERO. Даже большинство пользователей графики не заботятся. DCS разрывается в тот момент, когда вы можете ожидать, что ваш репозиторий будет больше обычного жесткого диска. И в зависимости от того, насколько вы хороши, вы можете легко попасть в репозиторий тысяч + gb opf. Понятие о том, чтобы объединить это в мой локальный репозиторий, как программист, не имеющий дело с grpahics, за исключением небольшой тестовой графики, делает меня kringe - как это приводит к отключению сетевого администратора.
Это становится еще хуже, когда вы правильно занимаетесь анимацией/фильмами сверху. Каждое изменение и рендеринг - другая версия. Boom. Это достаточно плохо для обработки в центральном репозитории (где я могу добавлять диски на центральный сервер), это совершенно непригодно в тот момент, когда вы распространяете это для каждого члена команды В КАЖДОЙ ВЕРСИИ.
Subversion кажется хорошим решением,
Возможно, если вы справитесь с его глупостями.
Я бы настоятельно рекомендовал здесь prooven решение - perforce в значительной степени способен справиться с этим prooven.