Как стать автором
Обновить

Комментарии 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?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий