посмотрите на synthing, великолепная штука, 2 нода полет нормальный на десятке девайсов. Я не стал делать федерацию, у меня все девайсы залинкованы только на сервер.
я тут подумал, было бы гораздо удобнее работать с большими репами если бы каждый живой чекаут сам бы в фоне подтягивал новые файлы и раздавал как торрент, тогда и проблем с закачкой быть не должно, и с нагрузкой на сервер
лучше - не лучше должен решать разработчик с головой на плечах, но в доке по диктам этот способ должен быть указан. Хотя он оказывается очень свежий, поэтому думаю если появится новое издание Рихтера он там будет
да, тут со всем соглашусь, особенно zstd бы не помешал, там модно всякое творить, типа сжатия с переиспользованием прошлого архива как словаря, в случае с гитом это могло бы дать значительный буст https://developer.chrome.com/blog/shared-dictionary-compression
ну так логично, если вы хотите положить туда терабайты и не хотите держать их в каждом клоне, то вариантов то больше нет, их же надо где-то хранить, тогда выбирается сервер для хранения и мы получаем так или иначе что-то типа LFS. Я не понимаю чего можно ожидать, вы или храните всё в каждом клоне(кстати, на сервере у нас у разных клонов гит кеш общий, это сильно экономит место), либо храните "где-то там" и тогда нет никакой распределённости.
Вот вам LFS. У нас как бы децентрализованная система, но без центрального сервера она работать не будет.
вот я этого понять не могу. Да, или децентрализованная но жирная, или централизованная, тогда история больших файлов только на сервере и за её хранение расплачивается только сервер, другого не дано.
а художнику и не нужен гит бук, он не делает октопус мерджи и прочие непотребства. Но, имхо, любой senior просто обязан прочитать штатную документацию используемого инструмента контроля версий и качественно освоить инструмент.
Так, и у меня геймдев, так что коллеги. Если говорить про исходники с которыми работают художники то они у нас частично всё ещё в svn сидят, там есть репы по теру, sparse checkout и всякое такое. Вы говорите что хотите распределённости, так она есть, и для больших бинарей она реально будет стоить места. Хотя git pack вроде учился более эффективно работать с бинарями если меняется только часть, хотя новость не могу найти сходу. Любая распределённая система, в который вы захотите хранить много больших часто меняющихся бинарей будет жрать место. В играх с огромным количеством контента мы прямо дизайнили архитектуру игры и её деплоя так, чтобы было удобно это всё поддерживать, быстро релизить, и не лочить ресурсы для работы(чтобы несколько человек не пересекались на одном файле)
Я вот теперь тоже откуда-то узнал. Но почему функционал предназначенный для работы с диктами не упомянут в референсе на дикты? Имхо это провал архитектуры и документации.
ровно противоположный экспириенс, каждый тул пытается изобрести какие-то свои абстракции и подходы вместо нативных для гита. Стоит один раз прочитать git book и гит станет прозрачен как слеза, и так со всем системами контроля версий, я профессионально лет по 5 пользовался svn, hg, git и на всех них можно нормально жить только из консоли, всё работает чётко и без ошибок, ты точно понимаешь что делаешь, отдельно могу признавать только вьюверы которые дерево красивое нарисуют, не более того.
а почему вы решили что вам нужен LFS? Гит прекрасно хранит бинари. LFS нужен если вы постоянно меняете большие бинари и они дофига весят в клоне. Но если вам нужна распределённость и вы готов за неё платить, то пожалуйста, всё будет работать. Я знаю о чём говорю, у меня есть гит репо с почти миллионом бинарей, десятью тысячами коммитов и весом в несколько десятков гигабайт, и всё работает просто отлично. На LFS эта штука бы еле еле шевелилиась, т.к. LFS чудовищно плохо работает с большим(10k и больше) количеством файлов
а какой тогда смысл делать "секретную" фичу, и не писать о ней в документации? Как разработчик, которому это потребовалось вообще должен вообще об этом узнать?
посмотрите на synthing, великолепная штука, 2 нода полет нормальный на десятке девайсов. Я не стал делать федерацию, у меня все девайсы залинкованы только на сервер.
больше на ту нашумевшую соковыжималку которая сок из пакета давила похоже
я тут подумал, было бы гораздо удобнее работать с большими репами если бы каждый живой чекаут сам бы в фоне подтягивал новые файлы и раздавал как торрент, тогда и проблем с закачкой быть не должно, и с нагрузкой на сервер
лучше - не лучше должен решать разработчик с головой на плечах, но в доке по диктам этот способ должен быть указан. Хотя он оказывается очень свежий, поэтому думаю если появится новое издание Рихтера он там будет
Например моделька KD-85X9500B стоила порядка USD $20000? а в перещёте на инфляцию почти 27 тыс долларов по современному баксу
Спасибо, табличку прочитал, химозу заказал, для перца понятно, ещё бы для лимона состав надыбать, беглый гуглёж что-то странное предлагает
вы явно недооцениваете объём кубического километра :)
Кто желает прогуляться по ссылкам на тему того как Sony превратило 300 моделей смарт телеков в не смарт могут это сделать тут https://habr.com/ru/news/792778/#comment_26486410
да, тут со всем соглашусь, особенно zstd бы не помешал, там модно всякое творить, типа сжатия с переиспользованием прошлого архива как словаря, в случае с гитом это могло бы дать значительный буст https://developer.chrome.com/blog/shared-dictionary-compression
ну так логично, если вы хотите положить туда терабайты и не хотите держать их в каждом клоне, то вариантов то больше нет, их же надо где-то хранить, тогда выбирается сервер для хранения и мы получаем так или иначе что-то типа LFS. Я не понимаю чего можно ожидать, вы или храните всё в каждом клоне(кстати, на сервере у нас у разных клонов гит кеш общий, это сильно экономит место), либо храните "где-то там" и тогда нет никакой распределённости.
вот я этого понять не могу. Да, или децентрализованная но жирная, или централизованная, тогда история больших файлов только на сервере и за её хранение расплачивается только сервер, другого не дано.
а художнику и не нужен гит бук, он не делает октопус мерджи и прочие непотребства. Но, имхо, любой senior просто обязан прочитать штатную документацию используемого инструмента контроля версий и качественно освоить инструмент.
Так, и у меня геймдев, так что коллеги. Если говорить про исходники с которыми работают художники то они у нас частично всё ещё в svn сидят, там есть репы по теру, sparse checkout и всякое такое. Вы говорите что хотите распределённости, так она есть, и для больших бинарей она реально будет стоить места. Хотя git pack вроде учился более эффективно работать с бинарями если меняется только часть, хотя новость не могу найти сходу. Любая распределённая система, в который вы захотите хранить много больших часто меняющихся бинарей будет жрать место. В играх с огромным количеством контента мы прямо дизайнили архитектуру игры и её деплоя так, чтобы было удобно это всё поддерживать, быстро релизить, и не лочить ресурсы для работы(чтобы несколько человек не пересекались на одном файле)
Я вот теперь тоже откуда-то узнал. Но почему функционал предназначенный для работы с диктами не упомянут в референсе на дикты? Имхо это провал архитектуры и документации.
ровно противоположный экспириенс, каждый тул пытается изобрести какие-то свои абстракции и подходы вместо нативных для гита. Стоит один раз прочитать git book и гит станет прозрачен как слеза, и так со всем системами контроля версий, я профессионально лет по 5 пользовался svn, hg, git и на всех них можно нормально жить только из консоли, всё работает чётко и без ошибок, ты точно понимаешь что делаешь, отдельно могу признавать только вьюверы которые дерево красивое нарисуют, не более того.
а почему вы решили что вам нужен LFS? Гит прекрасно хранит бинари. LFS нужен если вы постоянно меняете большие бинари и они дофига весят в клоне. Но если вам нужна распределённость и вы готов за неё платить, то пожалуйста, всё будет работать. Я знаю о чём говорю, у меня есть гит репо с почти миллионом бинарей, десятью тысячами коммитов и весом в несколько десятков гигабайт, и всё работает просто отлично. На LFS эта штука бы еле еле шевелилиась, т.к. LFS чудовищно плохо работает с большим(10k и больше) количеством файлов
а какой тогда смысл делать "секретную" фичу, и не писать о ней в документации? Как разработчик, которому это потребовалось вообще должен вообще об этом узнать?
А точно для 200 вагонов в сутки нужна kafka?
какой отвратительный дизайн, вот как об этой вещи должен узнать разработчик? Тут https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.dictionary-2?view=net-8.0 нет ни слова. У Рихтера тоже.
@Boomburum тут вам обращение
как мне нравятся прогнозы вида: история закончилась сегодня, дальше будет как сегодня.