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

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

Страницы: 1 2 3 4 5 6 7 Следующая »
#60
12:12, 6 апр. 2018

Alprog
> Только сейчас 2018 год и лочить файлы позволительно разве что художникам.
только сейчас такие как ты встали с горшка и не понимают зачем нужен контроль версий. Я тебе всего лишь показал, какой есть способ намного лучший и без гемороя. (и заметь ни какой коленки, FoxPro это разработка Microsoft - они сделали что-то на коленке?)

Поэтому научись отвечать на поставленные вопросы, а не кидаться какашками

Еще раз
tac
> а теперь подумай, зачем вообще ввели систему контроля версий?

#61
12:17, 6 апр. 2018

Alprog
> у вас там есть система контроля версий или нет? Очень хочется понять.
у нас все есть ... как только ответишь на вопрос и перестанешь бросаться какашками и врубишь мозги - все расскажу

для затравки можешь посмотреть https://gamedev.ru/code/forum/?id=228434
(это не совсем то, но близко ... )

#62
13:28, 6 апр. 2018

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

Alprog
> Только сейчас 2018 год и лочить файлы позволительно разве что художникам. И то
> не всем.
Помнится, какой-то из разработчиков Naughty Dog у себя в книжке про движки рекомендовал, чтобы для художников и их ассетов таки выделили специальный реестр, в котором бы хранились наименования, перекрёстные ссылки и прочие метаданные. Один из вариантов реализации - таки через реляционную БД.
А вот если об этом подумать. Можно ли считать репозитории подклассом БД? Являются ли команды git транзакциями? (конечно являются, ещё полную историю коммитов не хватало прое***ть)

Хм. А можно ли реализовать БД-подобное хранилище графа игровых объектов, которое под капотом хранит данные в текстовом виде? Вернее, более полезным будет такой вопрос - пробовал ли кто-то такое сделать?
Транзакции пишутся в отдельный файл через append/flush, а сервер БД параллельно прочитывает в память файл-хранилище, обновляет и затем подставляет новую версию через ReplaceFile. А поскольку главное хранилище - текстовое, можно подсунуть этих кукушек к какому-нибудь git и он должен даже суметь их смёрджить.

#63
13:49, 6 апр. 2018

Наверно, что-то похожее на разговор с Таком ощущают люди во время ЛСД-трипов - смысла никакого, но время от времени приходят почти что полезные идеи.

#64
14:31, 6 апр. 2018

tac
> Поэтому научись отвечать на поставленные вопросы
Так я первый спросил, а ты вопросом на вопрос.

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

#65
14:42, 6 апр. 2018

Ну, то есть систему контроля версий Архитектор не использует (его велосипедные пародии оными не являются). Это прямо уровень. Сила. Огонь. 20+.

#66
15:42, 6 апр. 2018

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

#67
15:49, 6 апр. 2018

tac
что не нравится, когда твой бред обсуждают?

#68
16:35, 6 апр. 2018
+ Показать
#69
16:55, 6 апр. 2018
Oxyd
Он по жизни такой. Видимо рис в животе бродит как у того китайца.
#70
7:59, 7 апр. 2018

Alprog
> Чего только люди не понавыдумывают
Дурачок?

#71
8:03, 7 апр. 2018

tac
> > а теперь подумай, зачем вообще ввели систему контроля версий?
я так понимаю ни у кого ответа нет?

ну хотя бы так? чем лучше/хуже система контроля версий, чем контроль доступа к файлам?

> > исходники размещались в сети, но доступ к ним блокировался для
> > редактирования, если кто то уже редактировал

#72
10:11, 7 апр. 2018

tac
> чем лучше/хуже система контроля версий, чем контроль доступа к файлам?
Если над проектом работаешь ты один, то это не играет ключевую роль.
Да, это даёт некоторые удобства, но и всё.

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

Что это даёт? Это даёт возможность многим людям работать над одним проектом, согласовывая работу между собой.
Плюс полное отсутствие возможности необратимых изменений и необратимых потерь данных.

#73
10:30, 7 апр. 2018

tac
Что из себя представляет твоя система?
По сути это просто центральное хранилище, откуда все клиенты читают данные. История версий на сервере также хранится, но по большому счёту бесполезна: все клиенты читают актуальную версию данных:

+ Показать

Локи запрещают менять определённый сегмент. Но что будет, когда кто-нибудь вольёт изменения? Изменения мгновенно появятся у всех. И теперь кто-то другой может начать менять тот же сегмент:

+ Показать

Теперь давай сделаем то же самое, но не на коленке, а с помощью клиент-серверной системы управления версий с поддержкой локов. Например, Perforce. Выглядеть начинает это так:

+ Показать

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

Идём дальше. Локи — это, конечно, хорошо. Но они всё же существуют больше для художников и бинарных данных, которые плохо мержатся. А для кода основной фишкой систем управления версиями, чуть ли не с самых древних (даже в CVS), всегда были мерджи. Добавляем в нашу схему ветки:

+ Показать

Вау, теперь программист может менять те же самые строчки в тот же самый момент, когда их меняет кто-то другой. А решение, что делать с конфликтом, если он вообще возникнет (не факт, что эти ветки будут слиты или изменения не будут отменены к тому моменту), оставляем на потом. Вау, ничего себе. Но это ещё не всё. В конце концов уже лет 10 как на смену клиент-серверам пришли распределённые системы а-ля git или mercurial. Не нужно зависеть от соединения канала, не нужно перекачивать гигабайты по сети, если роешься по истории. Вся история у тебя локально. Можешь даже из Перу работать.

Но и это ещё не всё! Можно комбинировать подходы. Как у нас в проекте с PlasticSCM:

+ Показать

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

Вот какой-то такой путь прошла индустрия за последние 20+ лет. Чем ты эти 20 лет занимался — непонятно. Видимо, третью форму нормализовал.

#74
19:46, 7 апр. 2018

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

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

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