Comments 12
Также каждый бинарный апдейт вынуждает пользователей скачивать довольно большой билд из стора: в нашем случае — 1 Гб.
Хм. Стим при обновлении скачивает именно разницу. Epic Store тоже. Почему в Вашем случае получается так много?
Да и каждое выпущенное DLC видно на странице товара в магазине Steam. Это не мешает?
SVN хуки,
*Смотрит по сторонам и на часы*. Простите, я правильно понял, что вы используете SVN в 2022 году? Можете, кхм, прокомментировать как-нибудь?
Если не хватает денег и желания на P4, то сидят на svn, или разных связках svn(content) + git(sources), cvs + git. Как бы нибыл хорош git он ужасен для сырого большого контента, с gitlfs тоже танцев хватает. Да и поддерживать репо в пару терабайт контента с гитом то еще удовольствие
Не важно какой репозиторий используется, важно что команда с ним эффективна.
Особенности национального геймдева.
У svn есть плюсы перед git-ом и поэтому многие старички не хотят с него слезть. Да и ленятся тратить много времени на изучение не профильной (хотя тут уже можно поспорить) технологией.
Западные компании используют Perforce (де-факто стандарт в для крупных игровых студий), который ещё старше. У него так же хватает недостатков, но он к тому же платный.
Но на самом деле можно поднять svn сервер поверх GitLab/Gitea и позволить программистам работать в git, а контент-мейкерам в svn.
Поддержу предыдущие ответы, у нас например код в git а все остальное (файлы блендера, текстуры, референсы, сабстенс пэйнтер и т.д.) в svn. Просто svn с таким контентом лучше и удобнее работает, ИМХО. Но все равно SVN не до конца удобен, я надеюсь у меня когда ни будь хватит сил написать систему контроля версий ориентированную на графику (идеи уже есть) или кто-то мне подскажет какие удобные системы есть сейчас которые можно поднять на своем сервере о которых я не знаю.
Главная проблема, например проект сабстен пэйнтера для 4к текстуры может спокойно весить 4 гига, и вот делаешь комит в SVN и теперь там эти 4 гига навсегда, даже тогда когда вариант этого файла больше не пригодится никогда, он будет лежать и занимать это место и это только один комит. Хочу систему такую как свн, но с возможностью управлять временем жизни некоторых файлов, например хранить только 10 последних вариантов определенного файла, если для одного из вариантов явно не указанно другое время жизни, то когда он станет 11-ым то он удалится. Что-то среднее получается между системой бэкапов и системой контроля версий (это если вкратце об идеи).
Svn умеет подрезать историю файлов, что бы как раз такую проблему решать.
Git в свою очередь умеет это хранить в lfs и можно просто удалять объекты, которые уже не нужны (Ну и поверх можно svn сервер запустить).
Подрезание SVN происходит через дамп и потом обратной загрузки через фильтр, попробуйте например такое проделать с 100 гиговым репозиторием, дамп будет весить в несколько раз больше чем репозиторий. Про lfs знаю, вот только не знаю как удалять оттуда. В любом случае всё это не совсем штатные ситуации для SVN и Git LFS.
В svn это приходится делать над терабайтным репозиторием. Да, боль, но что поделаешь.
В LFS достаточно просто удалить файл из кеша. Найти актуальные можно простым скриптиком, пробежав по всем lfs объектам в нужных коммитах. К сожалению встроенный git lfs prune не позволяет удобно указать ренж нужных коммитов/веток и делает это со всеми объектами недоступными из нужного коммита.
правильно. хочет юзер фикс - пусть покупает dlc
Я правильно понял чекер == unit test?
Как мы избегаем бинарных апдейтов и обновляем игру «на лету» с помощью DLC