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

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

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

tac
Ты сам сначала думать начни. Совместный доступ к одному файлу через систему контроля версия - это оверкилл, лол. Вдумайся почему их назвали контроль (от слова контролировать) версий (это такая штучка, которая фиксирует отличие одного файла от другого). Бранчинги, сборки, локальные ветки? Говорит о чем нибудь, или в мозгу главного архитектора такие вещи не помещаются и это удел быдла с геймдев.ру?

#76
23:07, 7 апр. 2018

Dampire
> Совместный доступ к одному файлу через систему контроля версия
ты бредить начал, похоже вообще не понимаешь о чем речь , м да, сложно с людьми у которых нет опыта

#77
23:24, 7 апр. 2018

Alprog
ну хорошо, ты знаешь несколько больше, чем два других клоуна .. которые даже не в курили о чем речь

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

Хорошо ты рассказал некоторую историю, как все появлялось, в принципе со всем согласен, но этого мало .. я дополню ..

Весь мой пафос был в том, что если ты работаешь с исходниками БЕЗ т.н. концепции проектов, как то появилось в Визуал Студии, тебе нафиг не нужна никакая система контроля версий, ты просто кидаешь их в сети и твое средство должно всего лишь лочить файлы. Ну да, сложно работать над связанными задачами одновременно. Но работу так можно организовать, т.к. за деньги люди делают разные задачи, а не вместе одну. Но зато никаких конфликтов при сливании. И вообще никакого оверкила с тем что надо коммитить и прочие

Теперь, почему же появляется проблема в проектах вида ВизуалСтудии, или Юньки ... да потому что , появилась IDE, которая сама что то творит, таже сериализация юньки, это по сути работа IDE редактора, это делает не разработчик, это не он написал код и заработало и много разных других приколов, которые происходят без ведома разработчика, если он работает через IDE, или движок, ввообщем всегда когда ты начинает 'проект'. Вот это и заставляет использовать систему контроля версий, локов становится мало. IDE просто не может работать в сети на всех, она работает на одном компе для одного разработчика.

А дальше мы просто вынуждены, чтобы все исходники расползлись бы по каждому юзеру. И так как это просто текст, это оказалось кроме того удобно. Разработчику дали сахар, который позволял : 1. выделять окончание некторой логической части своей работы - делая коммиты, 2.  помнить и откатываться что было раньше, 3. применили дифы /помним, что такие средства как windiff, были вне связи с системой контроля версий/ и это решило проблему слияний, хотя проблемы конфликтов остались. Но для текста осмысленного, таких как исходников, конфликты можно было разрулить. Но для бинарников это в принципе не возможно, для сериализованных файлов тоже, приходилось когда нибудь разруливать конфликт в контроле версий на сцене Юнити?

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

позже напишу что же в альтернативе

#78
23:35, 7 апр. 2018
если ты работаешь с исходниками БЕЗ т.н. концепции проектов, как то появилось в Визуал Студии, тебе нафиг не нужна никакая система контроля версий

Похоже ты совсем не понимаешь зачем нужна система контроля версий!
Попробуй в такой системе как ты описываешь откатиться назад!
#79
23:54, 7 апр. 2018

tac
> Теперь, почему же появляется проблема в проектах вида ВизуалСтудии, или Юньки
> ... да потому что , появилась IDE, которая сама что то творит, таже
> сериализация юньки, это по сути работа IDE редактора, это делает не
> разработчик, это не он написал код и заработало и много разных других приколов,
> которые происходят без ведома разработчика, если он работает через IDE, или
> движок, ввообщем всегда когда ты начинает 'проект'. Вот это и заставляет
> использовать систему контроля версий, локов становится мало. IDE просто не
> может работать в сети на всех, она работает на одном компе для одного
> разработчика.

Git was created by Linus Torvalds in 2005 for development of the Linux kernel, with other kernel developers contributing to its initial development.[12]

Изображение
#80
23:58, 7 апр. 2018

seaman
> Попробуй в такой системе как ты описываешь откатиться назад!
еще один не понял, почитай сначала .. я не зря начал со слов когда по земле ходили динозавры .. сейчас стало одобно откатываться назад? не забыл, что для этого ты делаешь коммиты САМ ! а в Юньке еще ждешь хуеву тучу времени, когда она обмазгует что же откатилось назад

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

#81
0:06, 8 апр. 2018

tac
> для этого ты делаешь коммиты САМ
Т.е. если кто другой сделал коммит я откатится не смогу?
Или ты имеешь в виду "автоматическое резервное копирование"?
Ну и совершенно непонятно причем тут вообще VS и проекты? Думаешь те, кто в ней не работает, а например пишет сайт в sublime не используют ГИТ?
Пиши яснее, тогда тебя понимать будут.

#82
0:19, 8 апр. 2018

seaman
> Или ты имеешь
только то, что написано .. на это надо тратить время, в то время как резервное копирование делается по расписанию само, да и закомментить и откомментить проще чем коммитить и откатывать

seaman
> причем тут вообще VS и проекты? Думаешь те, кто в ней не работает, а например
> пишет сайт в sublime не используют ГИТ?
подумай ! Ты сможешь положить проект VS в сеть и чтобы группа людей одновременно работала с ним? /ну с VS еще если честно можно приспособиться, она для этого развивала ряд подходов, но не удобно ... хотя думаю 80% даже не слышали о такой возможности/ , но вот с Юнькой уже точно без вариантов

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

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

#83
6:30, 8 апр. 2018

tac
> приходилось когда нибудь разруливать конфликт в контроле версий на сцене Юнити?
Да, успешно.

#84
6:31, 8 апр. 2018

tac
У меня такое чувство, что ты тут не проблемы разработки обсуждаешь, а решаешь какие-то свои личные проблемы.
То есть сделал важный вид, представил в своём воображении аудиторию крутых дядек, которые с открытым ртом и удивлением тебе внимают,
а ты с ними делишься мудростью жизни.

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

#85
6:43, 8 апр. 2018

tac
> Вот это и заставляет использовать систему контроля версий
Я чего-то не пойму: ты мне предлагал использовать централизованную БД место сериализации и системы контроля версий; при этом сам же говоришь,
что в проекте на юнити приходится использовать систему контроля версий. Так как по твоей задумке я должен был организовать свою работу?

> позже напишу что же в альтернативе
Это всё велосипедные гавнометоды, которые ни одна серьёзная студия никогда не будет использовать.
Но ты всё равно напиши. Это довольно увлекательное чтиво следить за тем, как ты всё больше и больше отрываешься от реальности.

#86
8:38, 8 апр. 2018

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

#87
8:51, 8 апр. 2018

Alprog
> ты мне предлагал использовать централизованную БД место сериализации и системы
> контроля версий
ты опять все напутал, я тебе ничего не предлагал, я утверждал, что стоит использовать БД, когда сохранять надо структурные данные, а не сериализацию /за исключением передачи по сети/. Ты был в шоке, и использовал аргумент, что мол с базами очень сложно использовать систему контроля версий. Пока я тебе показал, что можно обходится и без контроля версий, но ок не в случае с Юнити. А так же то, что сериализация превращает контроль версий в ад, правда ты пишешь

Alprog
> приходилось когда нибудь разруливать конфликт в контроле версий на сцене Юнити?
> Да, успешно.
но думаю ты лукавишь, и сам понимаешь как это сложно и не нужно, если только ты не выбирал, брать одну версию или другую, а именно совмещал обе

поэтому вначале ты должен растаться с иллюзиями, что тебе сериализация где то помогает, у нее нет плюсов от слова вообще

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

#88
14:45, 8 апр. 2018

tac
> попробуй напиши зачем тебе сериализация, и почему ты не используешь базы данных, тогда и увидем кто дурачок?
То есть мне нужно было просто сказать, что у меня проект на Unity и тебя бы это полностью удовлетворило?

> но думаю ты лукавишь, и сам понимаешь как это сложно и не нужно
Там же Yaml, зачастую мёрж сам автоматом происходит. Плюс тулзы есть специальные для мержа сцен. Чуть сложнее текста, но решаемо.

> поэтому вначале ты должен растаться с иллюзиями
Это говорит человек, который вместо системы контроля версий использует центральное БД, лол.
Что ещё посоветуешь? todo.txt вместо трекера задач? Plain C в одном файле вместо классов?

Ты просто "левша", который ездит на осле задом наперёд, думает, что великий гонщик и лезет с советами к формуле один.
У тебя из опыта только кустарные сайтики; базы данных в каких-то, судя по всему, маня-конторках; и wanna-be GameDev, который ты по ошибке принимаешь за настоящий.
Как вообще с таким набором опыта можно было решить, что те наколеночные подходы, которые вы там применяете, можно считать оптимальными?
На деле же ты один из наиболее тупейших и злостных "велосипедистов", которых я видел. Ни один сколько бы то ни было заметный игрок в индустрии не использует твои допотопные подходы.
Это касается и системы блокирования кода, и баз данных вместо сериализации. Тебе бы джуном устроиться в компанию с нормальными процессами, и чтобы старший по опыту товарищ какое-то время тебя поучил.

#89
15:02, 8 апр. 2018

Alprog
Капец как ты жёстко прессуешь :-)

А мне вот интересно стало. Tac, какие преимущества ты видишь в использовании бд, вместо сериализации в файл?
Просто вот уже любопытно стало. Я так и не догоняю в чём спор.

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

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