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

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

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

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

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

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

Тем более, что настоящим врагом Git и Mercurial является Subversion . Черт, это мир, где есть код , есть в FOSS-стране ...

Гит

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

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

С SVN вам нужен доступ к вашему репо для совершения. Что если вы в дороге или в кафе без интернета? Фигово.

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

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

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

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

ртутный

Ключевая особенность:

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

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

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

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

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

Джоэл Спольски написал мини-учебник по использованию Mercurial в Subversion Re-Education

насильственный

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

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

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

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

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

Комментарий от косули: Perforce очень болтливый. Там не так много происходит без участия сервера. В частности, вам нужен сервер, чтобы сделать открытым для редактирования, а это означает, что вам нужно перепрыгнуть через несколько обручей, если вы собираетесь разорвать соединение с сервером.

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

• Как уже упоминалось, ветвление / интеграция особенно громоздки и трудны для выполнения. У вас нечестивый контроль, но это происходит за счет чрезмерной сложности. С другой стороны, инструмент визуального слияния является единственным в своем роде и представляет красивый трехуровневый «слиток» представления вашей работы. Perforce предоставляет некоторую графическую визуализацию путей ветвей (так называемый граф ревизий), однако способ визуализации часто делает инструмент довольно бесполезным. Если вам нужно только увидеть очень маленький отрезок времени для одного или нескольких файлов, это может быть полезно ... что-нибудь еще, и почти невозможно перемещаться по Графику ревизий.
• Perforce также не очень эффективный инструмент, так как практически любая файловая операция требует дублирования файлов и данных: разветвление, маркировка, списки изменений и т. Д. Здесь нет разреженных или легких тегов или разветвлений. Если вы не боитесь использовать огромное количество дискового пространства для отслеживания ваших изменений, производительность, вероятно, будет вам полезна. Если нет, я бы посмотрел на другой инструмент.
• Perforce использует рабочие пространства, однако они могут иногда разочаровывать, поскольку Perforce кэширует все состояния в вашей рабочей области, а не использует реальные файлы на диске для определения какого-либо состояния. Это часто приводит к тому, что файлы не синхронизируются, потому что ваше рабочее пространство сообщает, что они обновлены, тогда как по какой-то причине физические файлы на диске действительно НЕ обновлены.
• И последнее раздражение - Perforce довольно жесток в вашей сети. Это очень болтливая программа, которая потребляет значительную часть полосы пропускания. Любая потеря сетевого подключения, и вы рискуете оказаться неспособным выполнять какую-либо работу с файлами, контролируемыми источником, до восстановления подключения. На данный момент я не обнаружил действия, которое можно выполнять в автономном режиме в Perforce.

диверсия

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

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

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

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

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

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

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

AlienBrain

От Avid :

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

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

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

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

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

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

Team Foundation Server

от Microsoft

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

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

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

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