Комментарии 30
Вообще, по меркам геймдева, ничего такого в микрософтовых размерах репозитория нет. Ну обычный нормальный репозиторий одной единственной игры. По гигабайтам даже маленький, здесь вполне норма терабайт 2-10.
А вы хотя бы какие-то репозитории видели? И вообще, знаете что такое репозиторий?
Вопросы к чему - хватить нести чушь.
Ничосе вы агрессивный. Ну вот, в данный момент у меня на рабочем компьютере таких три. Что дальше?
Все же это специфика GameDev-репозиториев, поскольку они по своей сути - файловая помойка, уж простите. 300GB c 90-95% программного кода (а не всяких спрайтов и прочего) - это невероятно огромные объемы. И правильно переводить слово huge из оригинальной статьи Скотта Чакона - огромный. То есть это действительно огромный репозиторий. Сравните с другими 10-летними полноценными репозиториями (комментарий ниже с примером Avalonia).
А какой в них размер именно кода? И количество файлов?
Я так полагаю, в геймдеве это огромное пространство занято ресурсами. То есть файлов не так уж много, и они по большей части большие и бинарные, то есть их количество не такое большое, и использовать на них какой-нибудь diff или blame никто не будет.
Соответственно разумнее сравнивать хотя бы количество файлов. Много в каких геймдевных репозиториях наберётся 3,5 миллиона файлов?
@fddima - судя по описанию функции windows - https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-readdirectorychangesw - да, буфер событий может переполниться. Но вызывающий об этом узнает. Видимо, в таком случае fs-monitor пометит состояние как невалидное и при следующем запросе git status честно пройдется по всем файлам.
Ну к примеру размер чекаута ~1Тb, число файлов ~10М. Правда не git а svn. Работает вполне шустро на рядовых операциях. Но конечно некое существенное подмножество фич запрещено - за разумное время они не отработают.
И количество файлов?
1-5млн.
Ну хорошо, судя по прилетевшим минусам я поторопился с выводами, тогда задам такой вопрос - какой процент от этого объема занимают именно текстовые файлы (программный код)? 5% хотя бы будет? Просто стало интересно, что это за магические GameDev репозитории, на терабайты заполненные спрайтами и другими графическими ассетами.
Вот даже интересно стало, условно, я на PS4-ке раньше игрался в souls-like жанр, самые тяжелые из них уже после установки занимают (специально зашел в настройки проверить):
Nioh - 55.3GB
Nioh2 - 53GB
Nier Automata - 52.63GB
Ghost of Tsushima - 52.23GB + Bonus Content в 22.10GB
God of War - 45.86GB.
Elden Ring - 45.69GB
Nier Replicant - 27GB
Sekiro: Shadows Die Twice - 17.02GB (!)
Вот объясните недалекому, неужели в этих игрушках в репозиториях тоже терабайты ассетов?
Код клиента, код сервера, код инструментария разработки, разнообразный арт (концепты, модели, текстуры, анимации, ...), игровая механика в удобном для редактирования виде и так далее и тому подобное.
Коэффицент размера чекаута к размеру финального продукта запросто может быть 50к1 и выше.
Хм, спасибо. Все равно в голове не укладывается, взять что-то родное из своей экосистемы (.NET), к примеру, Avalonia - кроссплатформенный UI фреймворк для .NET - репозиторию 10 лет, и он не весит даже 200 MB. Так что, пресловутые GameDev-repos, они скорее как файловые хранилища. 300GB чистого исходного кода под операционную систему - это действительно очень много.
Дело в том что это размер финального билда под целевую платформу. Даже если говорить о коде, то он сильно сжимается когда из текста превращается в набор машинных команд. Но если мы об ассетах, то там вообще песня. Все текстуры могут сжиматься под каждую платформу разными алгоритмами. Кто-то закинул 4К текстуру несжатую, которая весит 20 мегабайт. На PS4 это улетело одним алгоритмом сжатия в размере 1К, на PC улетело другим алгоритмом сжатия в 2К. Плюс репозиторий хранит все объекты, а в билд идут используемые. Может быть кто-то передумал на одном из этапов использовать какую-то текстуру, а в истории она осталась навсегда. Или импортировали пакет текстур, а левел-дизайнер использовал только несколько из них
Там еще упоминается про 2000 активных коммиттеров и десятки пушей одновременно.
Подтверждаю, не супер большая игра в репо в разработке, размер 2+ тб, гит не справляется. Ушли на перфорс
Занятная идея. Сначала запихнуть все исходники в один моно-репозиторий, а потом заморочиться с checkout-ом по частям. Почему бы сразу-то на части не поделить?
Я не знаком с особенностями производства софта в MS, пока мне кажется, что это - инвестиции, доработка git ради более эффективной работы в будущем с чем-то еще, нежели для практической пользы сейчас.
Про развитие Git-LFS нигде ничего не сказано, а работа git с бинарями - это, имхо, его больное место.
Фиг знает, молодцы конечно, но подано это всё немного с преувеличениями. Году в 2013м трогал репозиторий сравнимого размера, на предмет перехода с svn. Размер чекаута основного бранча там был поменьше наверное на порядок, общий размер репы был под 100гб. При грамотной настройке клиентской системы git с полным репозиторием работал довольно шустро, хоть и не без проблем, и какая-то часть разработчиков даже пользовалась git-svn, правда только с нужными ветками и обычно используя sparse checkout. В итоге там решили писать свою систему контроля версий имени этого репозитория :-).
А зачем собственно создавать проблему и потом героически её пытаться решить? Зачем сваливать всё в одну кучу и потом жаловаться что оно работает медленно и много весит?
Я конечно понимаю, что могут быть блобы которые "нормально" не версионируются, но их все можно выпнуть за пределы основного репозитория (или хотя бы в lfs).
Есть такая стратегия борьбы с конкурентами (Linux, открытое ПО в целом) — слияние с поглощением. GitHub и WSL — звенья одной цепи, я думаю. Если бы Microsoft купила GitHub и убивала бы его, то это очень плохо отразилось бы на репутации, а вот переехать туда с главным продуктом и доделать под свои задачи, поедая кактус, а потом ещё и купить, подарив разработчикам бесплатные приватные репозитории — совсем другая история.
Создавалась эта проблема ещё в Source Depot, когда о такого рода конкуренции речи не шло. А решать её пришлось с Git, чтобы "положительную карму" заработать. И вот не далее как сегодня от линуксоида со стажем в лет 15 прочитал, что, мол, «Лучший Linux — это винда». Приехали :)
Простите, а причем тут конкуренция, поглощения и слияния?
Чтобы заработать себе эти самые репутационные очки и выйти из воды предельно сухими спасителями Git, нужно было именно создать себе кучу проблем в Git, а потом их героически решить, а не обходиться простыми решениями. Зачем? Чтобы пользователи просто «использовали ванильный Git для управления репозиторием в 300 Гб», а не думали про LFS и что куда выпинывать. Такая вот предельная забота о пользователях…
Вот прям с языка сняли,
3,5 млн файлов (для справки, ядро Linux содержит около 80 тыс. файлов, или 2% от этого количества).
Репозиторий на 300 ГБ (против Linux с ядром ~4,5 ГБ).
преподносится автором так, как будто это предмет для гордости.
Самое ценное в статье для меня - выяснил, что Microsoft влил свои изменения в master git и теперь этим могут пользоваться все.
Что касается вопроса - кому это нужно? Как выясняется, нужно монолитам, играм и большим мобильным приложениям. Хотя пример Гугла, Яндекса, Юлы, ... говорит о том, что даже с микросервисной архитектурой люди идут в монорепы для большего контроля над кодом.
Навскидку: https://habr.com/ru/companies/yandex/articles/469021/ и https://habr.com/ru/companies/oleg-bunin/articles/531632/
Но если есть такая возможность - не используйте монорепы. Окей, git допилили под большие объемы. Но еще есть утилиты сборки, CI pipeline, статический анализ кода, IDE. Что-нибудь, да сломается)
Итак, вы думаете, что знаете Git? Часть третья: реально большие репозитории