Контроль версий для разработки игр - проблемы и решения? [закрыто]

Существует много доступных систем контроля версий , в том числе с открытым исходным кодом, таких как Subversion , Git и Меркуриальный , плюс коммерческие, такие как Perforce .

Насколько хорошо они поддерживают процесс развития игры? Каковы проблемы с использованием VCS в отношении нетекстовых файлов (двоичных файлов), больших проектов и т. Д.? Каковы решения этих проблем, если они есть?

Для организации ответов давайте попробуем для каждого пакета. Обновите каждый пакет /ответ с результатами.

Также, пожалуйста, перечислите некоторые краткие детали вашего ответа, о том, является ли ваш VCS бесплатным или коммерческим, распределенным по сравнению с централизованным и т. д.

Обновление : нашел хорошую статью, сравнив две из VCS ниже - видимо, Git - MacGyver, а Mercurial - Бонд . Ну, я рад, что уладил ... И у автора хорошая цитата в конце:

  

В порядке, чтобы прозелитизировать тех, кто   не переключились на распределенный VCS   но, но попытка конвертировать пользователя Git   к Mercurial (или наоборот) является   расточительство каждого времени и энергии.

Тем более, что Настоящим врагом Гита и Меркуриала является Subversion . Dang, это мир code-eat-code на FOSS-land ...

102 голоса | спросил 9 revs, 4 users 89%
Cyclops
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

6 ответов


71

Git

Недавно я был в группе Git (я использовал SVN и Mercurial). Пока мне очень нравится то, что я получаю с Гит. Это далеко не боль к настройке, и все больше инструментов разработки начинают использовать его.

Это система управления распределенной версией. Это позволяет нам иметь собственную независимую сундуковую область. Я могу работать в своей области и предлагаю вам очень легко просматривать наборы изменений. Я могу откатиться в своем собственном пространстве, не опуская центрального репо. Я могу зафиксировать, разветвить и сделать все, что вы можете сделать с SVN локально. Мне очень нравится иметь этот контроль.

С SVN вам необходимо получить доступ к вашему репо для совершения. Что делать, если вы находитесь в дороге или в кафе без Интернета? Нехорошо.

Конечно, SVN гораздо проще изучить, но я думаю, что преимущества распределенного контроля источника значительно перевешивают тот факт, что он имеет небольшую кривую обучения.

Мне также нравится, что умнее слияние.

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

Если вам все еще интересно узнать о GIT, посетите http://thkoch2001.github.io/whygitisbetter/ для некоторые хорошие данные /показатели. Также посмотрите https://git.wiki.kernel.org/index.php/GitSvnComparsion

ответил Tim Holt 25 +03002017-10-25T19:51:28+03:00312017bEurope/MoscowWed, 25 Oct 2017 19:51:28 +0300 2017, 19:51:28
62

Mercurial

Основные возможности:

  • Распределенный VCS
  • Свободный, с открытым исходным кодом
  • Сценарии плагинов легко писать --- могут быть написаны на Python или в виде сценариев оболочки
  • Существует много бесплатных скриптов плагина
  • Доступна большая документация, включая эту книгу (рекомендуется)

Что касается использования нетекстовых файлов, то последние версии Mercurial (> = 2.0) предоставляют расширение расширение большого файла по умолчанию :

  

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

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

Мне не известны какие-либо проблемы в отношении крупных проектов, помимо тех, которые связаны с большими двоичными файлами. Проект Python - это большой проект, а использует Mercurial .

Джоэл Спольский написал мини-учебник по использованию Mercurial в переподготовке Subversion

ответил Tim Holt 25 +03002017-10-25T19:51:28+03:00312017bEurope/MoscowWed, 25 Oct 2017 19:51:28 +0300 2017, 19:51:28
39

Perforce

Perforce (коммерческий /закрытый источник, централизованный) является отраслевым стандартом по ряду причин.

  1. Это коммерческий продукт, что означает, что он поставляется с коммерческой поддержкой. Проекты с открытым исходным кодом могут иметь право на бесплатную лицензию (за вычетом технической поддержки).
  2. Он поддерживает рабочие области очень хорошо , что позволяет использовать очень гибкие макеты источника и каталога ресурсов.
  3. Он поддерживает списки изменений очень хорошо .
  4. Вы можете видеть, кто над этим работает. Игры имеют аномально большое количество быстро изменяющихся двоичных файлов (активов) по сравнению с другими проектами развития. В большинстве случаев они не объединяются, поэтому отслеживание того, кто имеет /где /когда, имеет решающее значение. Клиенты Subversion и DSCC намеренно избегают этой техники, но в некоторых приложениях это очень полезно.
  5. Он поддерживает gigantic код /​​базу активов. Он not хранит повторяющиеся данные на клиентских машинах, что важно, когда ваш подвид дерева - это несколько десятков концертов.

Тем не менее, почти ежедневно каждый день очевидно, что Perforce не чувствует, что их положение в этой отрасли находится под угрозой. Их визуальные инструменты, в том числе P4V и P4SCC (интегрируются с Visual Studio), медленны и неэффективны, и последний, как известно, замораживает Visual Studio для полного удовольствия от нее. AnkhSVN находится в милях от Perforce.

Комментарий от xan: Однако стоит отметить, что их инструмент слияния, P4Merge (используемый для различения и слияния) превосходен и намного превосходит подобных Tortoise Merge. Удивительно, но этот компонент доступен бесплатно как часть пакета Visual Tools P4.

Комментарий от slicedlime: Еще один недостаток Perforce состоит в том, что ветвление в нем имеет огромную боль, особенно если у вас большие деревья. Почти каждый другой vcs лучше подходит для ветвления и слияния. Обычно это небольшая цена для оплаты вышеуказанных преимуществ.

Комментарий от roe: Perforce чрезвычайно чат. С сервером ничего не происходит участвует. Прежде всего, вам нужен сервер, чтобы сделать open-for-edit, что означает, что вам нужно перепрыгнуть через несколько обручей, если вы намереваетесь разорвать соединение с сервером.

Комментарий от jrista: Как ежедневный пользователь Perforce уже более двух лет, с расширенной командой разработчиков разработки и качества, состоящей из более чем 100 человек, я знаком с этим знаком. Несмотря на то, что это достойная система управления источниками, у нее есть свои недостатки, которые должны учитывать те, кто оценивает системы SCC:

  • Как упоминалось другими, разветвление /интеграция является особенно громоздкой и трудной задачей. У вас есть нечестивое количество контроля, но это связано с чрезмерной сложностью. С другой стороны, инструмент визуального слияния является единственным в своем роде и представляет собой прекрасный трехлистный «общий» вид слияния вашей работы. Perforce предоставляет некоторые графические визуализации путей ветвей (так называемый Revision Graph), однако способ визуализации часто делает инструмент бесполезным. Если вам нужно только увидеть очень маленький сегмент времени для одного или нескольких файлов, это может быть полезно ... что-то еще, и почти невозможно перемещаться по графику редактирования.
  • Perforce также не очень эффективный инструмент, так как почти любая операция с файлом требует дублирования файлов и данных: разветвление, маркировка, списки изменений и т. д. Здесь нет разреженных или облегченных тегов или ветвлений. Если вы не боитесь использовать огромное количество дискового пространства для отслеживания ваших изменений, perforce, вероятно, послужит вам хорошо. Если нет, я бы посмотрел на другой инструмент.
  • Perforce использует рабочие пространства, однако иногда это может расстраивать, поскольку perforce кэширует все состояние в вашей рабочей области, вместо того, чтобы использовать фактические файлы на диске для определения некоторого состояния. Это часто приводит к тому, что файлы не синхронизируются, потому что ваше рабочее пространство говорит, что они актуальны, когда по какой-либо причине физические файлы на диске действительно НЕ обновлены.
  • Последнее раздражение, Perforce довольно жестоко в вашей сети. Это чрезвычайно частая программа и потребляет значительную пропускную способность. Любая потеря сетевого соединения, и вы рискуете оказаться неспособным выполнять какую-либо работу с файлами, контролируемыми источником, до восстановления связи. На данный момент я не обнаружил активность, которую можно выполнить автономно в Perforce.
ответил Tim Holt 25 +03002017-10-25T19:51:28+03:00312017bEurope/MoscowWed, 25 Oct 2017 19:51:28 +0300 2017, 19:51:28
27

Subversion

  • Открытый, централизованный

  • Блендерные файлы. Я не совсем уверен, что файлы .blend являются бинарными (они выглядят так), но у меня не было проблем с их добавлением в Subversion. Сделав несколько экспериментов, увеличение размера файла для измененных файлов выглядит номинальным, поэтому оно не просто копируется во весь файл.

  • Крупные проекты - он работает, хотя он может стать изворотливым. Определенно можно обрабатывать репозитории не менее 5,5 ГБ (общий размер репозитория на сервере, в основном двоичные активы).

  • Дублированные данные на клиенте - Subversion хранит дублируемую копию каждого файла в рабочей области пользователя в виде первоначальной копии. Преимущество этого заключается в том, что вы можете выполнить diff или вернуться, не возвращаясь на сервер. Недостатком является то, что ваш 10-гигабайт рабочих файлов занимает 20 гигабайт дискового пространства.

  • Список игнорирования - это свойство каталога (простое с gui, раздражающее в командной строке).

  • Subversion позволяет блокировать файлы /активы - что действительно полезно, если несколько художников и дизайнеров работают с одними и теми же файлами.

  • Внешние методы - отличный способ справиться с общим (например, библиотечным или базовым) кодом между проектами.

ответил Tim Holt 25 +03002017-10-25T19:51:28+03:00312017bEurope/MoscowWed, 25 Oct 2017 19:51:28 +0300 2017, 19:51:28
7

AlienBrain

Из Avid :

  

Alienbrain - это цифровой актив   система управления для художников в   индустрия развлечений

  • Коммерческий (более дорогой, чем Perforce), централизованный
  • Предназначен для интеграции с другими профессиональными 2D и 3D инструментами рабочего процесса, такими как Photoshop, Maya, 3ds Max, Microsoft Visual Studio и т. д.

У меня есть no опыт работы с AlienBrain, и только слышал об этом из книги Полное кодирование игры Майком Макшаффи. Он, кажется, высоко оценивает это:

  

Художники и другие участники   фактически использовать этот продукт, в отличие от   другие, которые в основном предназначены для   хорошо интегрировать с Visual Studio и   не творческие приложения, такие как   Photoshop и 3D Studio Max. Один из   большие недостатки других продуктов   их довольно наивное отношение к   нетекстовые файлы. AlienBrain был написан   с этими файлами в виду.

Конечно, он также описывает это как:

  

Для тех из вас, кто действительно серьезно   проблемы отслеживания активов и одинаково   серьезные бюджеты ...

ответил Tim Holt 25 +03002017-10-25T19:51:28+03:00312017bEurope/MoscowWed, 25 Oct 2017 19:51:28 +0300 2017, 19:51:28
3

Team Foundation Server

из Microsoft

  • Коммерческая
  • Централизованная
  • Очень хорошо интегрируется с Visual Studio
  • Хорошая интеграция с Windows Explorer для пользователей без VS (т.е. художников).
  • Поддерживает «Shelved» changeets, который несколько похож на «stashing» в git, но он подходит к серверу; вы также можете публиковать эти полки, чтобы другие пользователи могли интегрировать их для вас.
  • С 2012 года у него есть очень хорошие рабочие процессы для проверки кода, встроенные непосредственно в Visual Studio
  • Последняя версия инструмента слияния очень приятная. Автоматическое слияние работает очень хорошо.
  • Поддерживает большие и переплетенные файлы просто отлично (очевидно, вы не можете их объединить)
  • Очень хороший сервер сборки
  • Поддерживает стробированные проверки, которые позволяют оценивать качество полки (через автоматические сборки, модульные тесты, анализ кода) до того, как они будут привязаны к репозиторию.
  • Очень хорошие инструменты управления проектами (не строго исходные элементы управления, но очень полезные), обеспечивая прослеживаемость от требований высокого уровня до кода.

Я много использовал TFS для проектов симулятора MILSPEC, и это очень хорошо. Наверное, не самый большой, если вы на Mac, хотя в наши дни есть плагин eclipse. Версия, поддерживающая облако, поддерживает репозитории git для исходного кода управления исходным кодом.

Это бесплатно для пяти пользователей на Visual Studio Online (позволяет использовать закрытый источник, без ограничений размера репозитория), где он размещается в облаке. Если вы хотите разместить его локально, это может быть дорого.

То, что мне больше всего нравится в этом, - это функции управления программным обеспечением, а также то, что он отлично справляется с большими файлами и бинарными файлами.

ответил Tim Holt 25 +03002017-10-25T19:51:28+03:00312017bEurope/MoscowWed, 25 Oct 2017 19:51:28 +0300 2017, 19:51:28

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132