Могут ли художники реалистично справляться с (распределенным) контролем версий в среде с открытым исходным кодом?

Хейя, я работаю в отделе управления проектами игры с открытым исходным кодом. Прямо сейчас мы используем SVN для контроля версий и хранения кода и активов в том же хранилище. Исходные версии активов (модели, текстуры) находятся в отдельной ветки средств массовой информации, а рендер-версии активов (мы работаем над изометрической 2-й игрой, поэтому мы фактически используем полученные 2d-изображения трехмерных моделей в игре) рядом с кодом, так как они необходимы для запуска игры.

У наших художников было трудное время для начала использования Subversion и обертывания вокруг концепции управления версиями в целом. Сейчас проект в основном состоит из программистов, и мы планируем перейти от SVN к распределенному управлению версиями, чтобы облегчить работу с веткими (и связанным с ним процессом слияния) и отправкой патчей. Мы еще не приняли решение о том, какой DVCS использовать, но мы, скорее всего, закончим использование Mercurial или Git.

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

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

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

Существует множество великолепных путеводителей DVCS, например. учебник Hginit. Однако те, что я нашел, были написаны для программистов. Это здорово, что теперь они могут легко локально совершать, использовать весь потенциал веток и объединять свои изменения без особых хлопот. Но это может быть не выгодно для художников, а скорее слишком сложным и страшным для них. Вы случайно не знаете учебник DVCS, который был написан для художников как основная целевая аудитория?

Мы также используем Trac для целей управления проектами, поэтому, если вы знаете плагин Trac, дружественный к художнику, дайте мне знать: -)

Ответ 1

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

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

Если художник хочет понять, что из-за контроля источника, один из программистов может объяснить детали.

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

Ответ 2

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

Трюк заключается в использовании Subreersion subversion в Mercurial. Mercurial позволяет вам размещать репозитории: Mercurial 1.7 поддерживает подповерхности Mercurial и Subversion, Mercurial 1.8 будет поддерживать подподразделения Git.

Вы управляете субрепо через файл с именем .hgsub. В вашем случае вы добавили бы что-то вроде этого в файл:

graphics/rendered = [svn]http://svn.example.org/graphics/rendered

Это инструктирует Mercurial сделать svn checkout of http://svn.example.org/graphics/rendered и сохранить чек в качестве graphics/rendered в рабочей копии Mercurial. Другими словами, формат файла .hgsub

mount-point = [type]source-URL

Вы делаете первую проверку самостоятельно, добавляете файл .hgsub и делаете фиксацию Mercurial. В этот момент Mercurial примет к сведению точный пересмотр Subversion, который проверяется в вашем подпоре. Этот номер версии сохраняется в .hgsubstate, который является дополнительным файлом, отслеживаемым Mercurial.

Когда другой разработчик создает клон репозитория Mercurial, Mercurial будет замечать файлы .hgsub и .hgsubstate и использовать их для воссоздания выполненной вами проверки Subversion.

Преимущества этого решения заключаются в следующем:

художники могут продолжить работу с Subversion. Здесь я немного упрощаю, предполагая, что они могут работать с их графическими файлами изолированно, не клонируя внешний репозиторий Mercurial. Даже если это не так, они могут выполнять большую часть своей работы с помощью Subversion и только hg pull --update время от времени получать последние изменения Mercurial.
разработчикам не придется загружать все версии всех графических файлов. Обычно это шоу-стоппер для (любой) распределенной системы контроля версий, когда речь идет о больших двоичных файлах.

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

Внешние двоичные активы в Subreersion subrepo - это эта проблема.

Mercurial - все о контроле версий и о предоставлении вам последовательных снимков проекта. Таким образом, Mercurial будет проверять только те вещи, которые были явно совершены. Это означает, что разработчикам придется регулярно вносить новые версии Subversion:

$ cd graphics/rendered
$ svn update
$ cd ../..
$ # test new graphics!
$ hg commit -m 'Updated graphics'

Mercurial commit совершает новый номер ревизии Subversion в файле .hgsubstate - Mercurial позаботится о том, чтобы вставить номер в файл, разработчики просто должны его зафиксировать. Таким образом, каждый Mercurial changeet будет ссылаться на конкретную ревизию Subversion через файл .hgsubstate, и вы сможете точно воссоздать любое прошлое состояние (состоящее из исходного кода и графики).

Ответ 3

Ниже приведено хорошее визуальное введение в управление версиями и Mercurial.

Постарайтесь увидеть, если это помогает облегчить понимание. Мне было бы очень сложно использовать что-то, что я не могу обернуть в голове.

Итак, вот несколько хороших визуальных представлений:

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

Ответ 4

Возможно, я немного опоздаю на вечеринку (и, надеюсь, не в тему), но в вашем первоначальном посте вы упомянули:

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

если вы действительно заинтересованы в Perforce, вам может быть интересно узнать:

"Если вы разрабатываете программное обеспечение, которое лицензированы или иным образом распределены исключительно по Open Source лицензии, вы можете получить лицензия Perforce бесплатно. Сюда входят обновления, но не включая техническую поддержку". - http://www.perforce.com/perforce/price.html

Ответ 5

У нас есть художники, работающие над играми с GIT. Для нас необходим клиент SmartGIT.

Он также поставляется с ароматом SVN.

Ссылка http://www.syntevo.com/smartgit/index.html

Ответ 6

Мне кажется, что у вас достаточно много времени, чтобы заставить художников использовать SVN, а нажатие DVCS на них было бы проигрышной битвой. Возможно, есть способ обновить DVCS с помощью проверок SVN, чтобы DVCS мог оставаться в курсе SVN?

Что касается принятия SVN, я думаю, что он действительно ловит людей, которые видят в нем что-то, что им нужно (или не может жить без него), а не что-то, что "человек" заставляет их делать. Если бы они могли видеть, как они могут извлечь выгоду из инструмента (т.е. Вернуться к предыдущим версиям и т.д.), Они могут быть более склонны его принять. Тем не менее, я не знаю, сможет ли SVN принести пользу художнику, как это делает программист.

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