да, тут со всем соглашусь, особенно 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 и больше) количеством файлов
а какой тогда смысл делать "секретную" фичу, и не писать о ней в документации? Как разработчик, которому это потребовалось вообще должен вообще об этом узнать?
линия zstd выше и шире чем бротли. Мы применяем уже много где zstd в серверах (и сжатие в клике и сжатие логов), и по нашим сравнениям zstd нормально так выигрывает бротли, но мы сравнивали только нативные реализации, что в .net происходит с этим я не знаю. Может ещё конечно от данных зависеть, но чёрт его знает, пока везде я видел победу zstd.
Например моделька 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 тут вам обращение
как мне нравятся прогнозы вида: история закончилась сегодня, дальше будет как сегодня.
макет на ней запустили, это испытательный пуск новой конфигурации
Со сказкой у неё тоже проблемы
https://community.centminmod.com/threads/round-4-compression-comparison-benchmarks-zstd-vs-brotli-vs-pigz-vs-bzip2-vs-xz-etc.18669/
линия zstd выше и шире чем бротли. Мы применяем уже много где zstd в серверах (и сжатие в клике и сжатие логов), и по нашим сравнениям zstd нормально так выигрывает бротли, но мы сравнивали только нативные реализации, что в .net происходит с этим я не знаю. Может ещё конечно от данных зависеть, но чёрт его знает, пока везде я видел победу zstd.
Я сходил почитал, зачем и почему они дропнули саппорт более старых нод: https://github.com/eslint/eslint/issues/17595
ответ: низачем.
По мне это просто преступные практики.