Войти
ПрограммированиеФорумОбщее

Сериализация vs. базы данных в юнити (7 стр)

Страницы: 1 2 3 4 5 6 7
#90
16:02, 8 апр. 2018

tac
> да и закомментить и откомментить проще чем коммитить и откатывать
Вот например у меня 5 файлов, и в каждом 5 мест, которые менялись. В системе контроля версий коммит и откат на прошлое состояние можно сделать в несколько простых действий. Если использовать комментарии, то чтобы вернуться к прошлому варианту работы, нужно закомментировать 25 мест для этого случая (5 файлов, и в каждом 5 мест изменений)
А теперь объясни мне, почему ты считаешь что комментариями это делать проще, а если не объяснишь, то я запишу тебя в неадекваты!

#91
16:16, 8 апр. 2018

tac
> Ты сможешь положить проект VS в сеть и чтобы группа людей одновременно работала
> с ним?
Для этого и сделаны CVS. Все работают, только ты похоже не умеешь.tac
> она не обязательна для коллективов
Для тебя необязательна.
Ты вообще что-то о ветках слышал? Предлагаешь для каждой ветки отдельную папочку с бекапами? А потом ручками все это дело мержить?
Или еще круче - прямо в продакшн коде какую-то фичу вводить. Чтобы потом автодеплой твои наработки выложил на сервер и у пользователей все рухнуло...

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

#92
17:27, 8 апр. 2018

seaman
> Для этого и сделаны CVS
Ты хотел сказать VCS (Version Control System). CVS — это конкретная VCS (Concurrent Versions System).
Да, я сам всегда путаюсь, в каком порядке эти три буквы что означают ))

> По твоим словам явно видно, что о системах контроля версий ты знаешь только понаслышке.
Ну не совсем понаслышке. Он там выше писал:

Чтобы ты не возомнил, что я не пользуюсь системой контроля версий тут пруф, прямо тут мы работали
в команде https://gamedev.ru/projects/forum/?id=229791&page=12#m173, можешь поспрашивать их
возникали ли у меня проблемы с Меркуриалом

Если почитать тред, можно узнать, что они месяц работали по несколько часов в день, и, если я правильно понял его бальную систему, никогда не набиралось больше 12 человекочасов в день (а в среднем, надо полагать, около 4 человекочасов).
Наверняка они даже ветками не пользовались, а фигачили всё сразу в мастер. Но ему такого опыта хватило, чтобы решить, что всё это ненужный сахарок, а все крупные студии тупо заблуждаются.

#93
18:44, 8 апр. 2018

Alprog
> Он там выше писал:
Я там в самом начале был. Ушел не потому что кто-то что-то не знал. Этого я не успел понять. Почему говорить не будем, дабы не поругаться.

#94
19:24, 8 апр. 2018

Alprog
> чтобы решить, что всё это ненужный сахарок
не передергивай

Alprog
> Плюс тулзы есть специальные для мержа сцен
подскажи какие?

Alprog
> зачастую мёрж сам автоматом происходит
ну я понял, конфликты на сцене ты не разбирал ...

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

#95
19:32, 8 апр. 2018

Alprog
> каким образом система версий синхронизирована с бд
ладно, введение затянулось .. вернемся к сути ...

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

Если есть желание синхронизировать, то хорошо бы знать, что можно писать т.н. задания на создания таблиц (хранимых процедур и прочего), и далее их изменения. Это ровно такой же код как исходники, только на sql. Чего сложного то было у вас с контролем версий, мне вообще не понятно.

#96
22:37, 8 апр. 2018

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

#97
6:55, 9 апр. 2018

tac
> подскажи какие?
https://docs.unity3d.com/Manual/SmartMerge.html

#98
19:27, 10 апр. 2018

Простите, но:

Alprog
> — Откат локальных изменений сцены из системы контроля версий;
> — Merge изменений, внесённых на одну и ту же сцену с разных компьютеров;
> — Тестирование внесённых изменений с последующим откатом обратно;
> — Функция «Save as…» с копированием сцены целиком;

Alprog
> Начнём с того, что ни одной системой контроля версий пользоваться будет
> невозможно. Если БД реализовано в виде огромного бинаря, то мы за пару недель
> засрём git-репозиторий и LFS.
> Если мы работаем в Perforce, то придётся ставить локи на всю базу целиком и тем
> самым останавливать работу всех остальных. SVN, mercurial?


Зачем пихать в GIT весь контент ?

Не важно - база данных / текстуры / звуки - что вы там соединять из разных версий собрались?


Их заливают на сервер (FTP например), потом система резервного копирования выделяет изменения, и сохраняет их по графику (раз в день).

И ничего не "засрётся" в отдельном Git-репозитории с исходниками.


Кстати, заставлять дизайнеров/артистов изучать Git - это сомнительная идея ^_^
Они будут в бешенстве :D

#99
20:01, 10 апр. 2018

ELena_Shloemovich
> Кстати, заставлять дизайнеров/артистов изучать Git - это сомнительная идея ^_^
> Они будут в бешенстве :D
Дизайнеры/артисты не способны выучить функционал трёх кнопок fetch, pull, push? Сомневаюсь.

#100
20:25, 10 апр. 2018

ELena_Shloemovich
> Не важно - база данных / текстуры / звуки - что вы там соединять из разных версий собрались?
Сцены, диалоги, всевозможные квестовые объекты. Где их хранить — сильно зависит от пайплайна и процессов.
Чем сильнее развит инструментарий, тем сильнее обычно связаны код и данные. То есть скрипт торговца не имеет смысла без файла с настройками его товаров и внешнего вида, файла с его диалогами, сцены, на которую он вставлен, файлов с анимациями открытия и закрытия лавки и т.п., поэтому в системе контроля версий все эти вещи должны быть синхронизированы. На каких-то проектах можно обойтись без этого, особенно в тех, где игра, по сути, целиком собирается кодированием «вслепую». Но я бы не назвал такое хорошей практикой.

> Кстати, заставлять дизайнеров/артистов изучать Git - это сомнительная идея ^_^
Опять же, сильно зависит от конкретных проектов и команд. Где-то (и такие примеры у меня есть) художники вполне пользуются ветками в гите, где-то появляется промежуточное сословие между программистами и художниками; мы решили перейти на PlasticSCM, где программисты и художники пользуются одной системой контроля версий, но в разных режимах. Словом, бывает по-разному и много от чего зависит.

Страницы: 1 2 3 4 5 6 7
ПрограммированиеФорумОбщее

Тема в архиве.