там адова куча генеренного кода, тулов для генерации
не у всех есть инструментарий для его генерации

Это как?

Например, чтобы сгенерировать код из моделей симулинка надо его иметь на компе. А он стоит кучу бабла.

один огромный репозиторий
в котором лежит куча проектов
сабмодулей будет штук 500

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

Это приблизительно 100 проектов. Субмодули нужны например, для версионности.

Субмодули нужны например, для версионности

А почему не бранчи?

Или подразумевается, что нужно заморозить в кокнкретром проекте другой проект на конкретном коммите?

https://github.com/facebookexperimental/mononoke или svn. У Perforce весьма неудобный интрфейс взаимодействия с пользователем. Вообще можно геймдев форумы почитать как люди страдают.

perfors

БДSМ

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

Я на перфорсе несколько лет сидел. Теперь плююсь от гита. Гит то ещё говно, особенно его простейшие косяки

«Mononoke is still in early stages of development»

Ты просто не умеешь его готовить, воркфлоу непривычный. Я в лютейшей ярости был когда в первый раз столкнулся с гитом после SVN, мгновенно его возненавидел. Со второго захода тоже некоторое время плевался, а теперь это одна из моих любимых технологий.

Моё столкновение с перфорсом было лет десять назад и я плевался от него. Но с действительно большими проектами не работал в нём.

Там проблемы не с воркфлов. Там просто косяки. Например, в Винде открыт файл, и ты его правишь. Сохраняешь, комитишь, делаешь git pull -rebase. И тут у гита случается облом, потому что он не может откатить заблокированный файл. И он бросает rebase посередине, хотя мог бы его откатить обратно и снять блокировки с файлов.

Сколько вести репа?
И какие проблемы сейчас с этим? Зачем куда-то перекатываться?

Я на перфорсе несколько лет сидел. Теперь плююсь от гита. Гит то ещё говно, особенно его простейшие косяки

Если уже есть опыт использования и привык, то стоит, наверное, продолжить использовать perforce.

«Mononoke is still in early stages of development»

Да, они его пилят активно.

Да, они его пилят активно

It is primarily written in the Rust programming language.

The version that we provide on GitHub does not build yet.

Эпично борятся с компилятором?

Проблема то в чем? Перфекционизм покоя не дает? Лучший для гита вариант, как мне кажется: все лежит в одной репе, пока не поймешь, что тебя не устраивает.

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

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

Например, в Винде открыт файл, и ты его правишь.

Ооо, честно говоря, один из блокирующих косяков винды, из-за которых невозможно работать. Постоянно запрещает переименовать каталоги, мол заблочено что-то. Бред какой-то. Есть анлокеры всякие, но часто требуется ребут(!)

Т.е. версия одного проекта должны быть привязана к версии другого

А, ну это конечно делается суперпроектами (просто, отдельный реп со своим именем, наприер, Проект_Ц, Пороект_Вэ), в которые кладешь нужные сабмодули. Включая сабмодули, содержащие общее для проектов.

Либо, тупо ветки, самое простое и классическое решение.

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

в Винде

ну ты понял. гит на никсы рассчитан, всякие потомки VMS обслуживаются в порядке общей очереди :)

Disclaimer: это мое личное мнение основанное на опыте

• git не умеет (тормозит) работать не репозиториями большого размера (в гигабайтах). Для решения этой проблемы придуманы костыли вроде gvfs
• git не умеет (тормозит) работать с большими файлами. Для решения этой проблемы придуманы костыли вроде git-lfs, git-fat
• сабмодули в гит это прикол такой. Это работает просто если вы ссылаетесь на чужой проект и вас не беспокоит что в нем происходит. Если это ваши сабмодули и они постоянно обновляются то количество коммитов «update submodule xx commit hash» и неудобство работы с ними (хоть бы 'qgit .' в директории сабмодуля не покажет истории сабмодуля) приведет к большой боли зада. Надо больше аргументов: google why submodules are evil. Для решения этой проблемы придуманы костыли вроде git-subtree или repo tool от Google

Т.е. если вы не хотите Perforce и у вас все эти три проблемы: большие репо, большие файлы, много репозоториев, то может костыли помогут? Как минимум я git-lfs используется повсеместно для хранения картинок, фильмов и прочих бинарных файлов. Вместо сабмодулей можно просто «договориться», что проект X состоит из репозиториев Y,Z и одни должны лежать в конкретных директориях. Но так трудно делать вещи вроде автоматического версионирования билдов для тестирования и вообще это каменный век

Костыли:

• https://gerrit.googlesource.com/git-repo/
• https://gvfs.io/
• https://git-lfs.github.com/
• https://github.com/jedbrown/git-fat
• https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree

Может с костылями git справится с вашей задачей.

Гит то ещё говно, особенно его простейшие косяки

Ну так

GIT - the stupid content tracker

(c) https://github.com/git/git/blob/e83c5163316f89bfbde7d9ab23ca2e25604af290/README

BTW прикола ради...

Если будет время посмотрите сюда http://fabiensanglard.net/git_code_review/history.php и на код первого коммита https://github.com/git/git/tree/e83c5163316f89bfbde7d9ab23ca2e25604af290

Там же все еще проще чем original bitcoin reference: https://github.com/bitcoin/bitcoin/tree/4405b78d6059e536c36974088a8ed4d9f0f29898

Т.е. наверное Линус не задумывался о том, что репа могут быть гораздо больше ядра линукса и просто не предназначил его для этого.

сабмодули в гит это прикол такой.

Да, это боль и прикол. Но альтернативы еще хуже. Я лично предпочитаю жирный проект, если без субмодулей можно обойтись или смириться.

Если это ваши сабмодули и они постоянно обновляются то количество коммитов «update submodule xx commit hash»

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

версиях круто допилили

Ну не прям чтобы уж круто.

говорят даже нормальный мерж завезли

Мержить стало удобнее. Но вот скорость всего этого все равно оставляет желать много лучшего.

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

А если это OurCompanySuperDuperSDKFrameworkWhichDoesNothingButUsesDependencyInjectionAndOtherBullshit и все им пользуются и постоянно меняют чтобы работал для всех остальных проектов (которых 50)?

Как бы вы в таком случае пользовались 3rd party ? Взяли бы релизную версию, и двигали бы раз в полгода. Так и тут.

У нас когда у какой-нибудь команды X возникает задача тесной интегральной разработки связанной с изменением OurCompanySuperDuperSDKFramework.. - не в мастере же это происходит! Через пару недель в проект X идет коммит с обновлением хеша саба OurCompanySuperDuperSDKFramework, в самом OurCompanySuperDuperSDKFramework - идет мерж в мастер (перед этим интеграционные тесты на обратную совместимость). Все проекты A..W тем временем продолжают юзать версию OurCompanySuperDuperSDKFramework которая была фиксирована. Захотят обновиться - оттестят в ветке своего проекта сдвиг версии OurCompanySuperDuperSDKFramework, сольют в мастер своего проекта.

Но, повторюсь, если ситуация действительно эпичных масштабов, и 50 проектов кажный день коммитят изменения в OurCompanySuperDuperSDKFramework, которые используются хотя бы в части других (из 50-и) проектов - значит да. Это большой проект. Всё объединить в один реп. А вы думали, большие проекты просто так назвали большими? Это решается другими методами - повышание инкапсуляции, модульности etc

не в мастере же это происходит

Я с вами согласен и не спорю, но в каком бы бранче это не происходило, люди делающие изменения в OurCompanySuperDuperSDKFramework наверняка будут тестировать его хотя бы с одним проектом. Каждое изменение в OurCompanySuperDuperSDKFramework заставит их соответсвенно коммитить «update superduper hash», пусть и в бранче X_super_framework_integration. Затем будет тестирование с 50 проектами и мерж в мастер будет состоять из 50 «update superduper hash» коммитов, например, потому что изменения в OurCompanySuperDuperSDKFramework не backward compatible.

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

К сожалению я плохо знаю perforce, но слышал, что там есть shelf'ы и это решено лучше.

Т.е. наверное perforce для большого проекта лучше (ядро линукса это совсем небольшой проект).

Каждое изменение в OurCompanySuperDuperSDKFramework заставит их соответсвенно коммитить «update superduper hash», пусть и в бранче X_super_framework_integration. Затем будет тестирование с 50 проектами и мерж в мастер будет состоять из 50 «update superduper hash» коммитов, например, потому что изменения в OurCompanySuperDuperSDKFramework не backward compatible.

Я только повторюсь:

Это решается другими методами - повышание инкапсуляции, модульности etc

даже не главная проблема сабмодулей

у них куча проблем да. Не в последнюю очередь потому, что вдруг считается, что они решат проблемы с архитектурой. А они всего лишь средство оптимизации того, как реп скачивается! Просто инструмент. Представь свой проект без сабмодулей, просто с каталогами и файлами. Сложно изменять? Сложно тестировать? Сложно исправлять баги? Это не проблема гита!

ну если вы фанат BDSM то можете использовать perforce. git это по факту лучшее что сейчас мы имеем. perforce сами же признали что они полное дерьмо и еще фиг знает сколько лет назад запилили импорт/экспорт

Я на перфорсе несколько лет сидел. Теперь плююсь от гита. Гит то ещё говно, особенно его простейшие косяки

Я на перфорсе год сидел (зная git), вспоминаю как ужас ужасов.

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

Самое главное, что в svn есть селективный чекаут. Да и git большой пока счекаутишь, пока дождешься пока он подтянет всю метаинформацию.

Самое главное, что в svn есть селективный чекаут

В гите тоже есть sparse checkout, а partial clone скоро допилят https://blog.github.com/2018-09-10-highlights-from-git-2-19/#partial-clones

Ну не прям чтобы уж круто.

Мне показалось, что скорость чекаута с большим количеством файлов заметно выросла

На счет checkout/export не могу сказать. А вот ci и merge, имхо, стали медленнее.

У нас все очень эпично... API между серверами описано в тектовых файлах специального формата. По этим файлам генерится код С, а также словари для симулинка. В симулинке модели и подмодели. И все это может быть разных версий. Из симулинка генерится код. Код компилится и заливается на платы. Платы тоже могут быть разные.

А что в перфорсе особенно мучало?

Это бы помогло, но в perfotce есть возможность мапинга каталогов в репозитории в каталоги в воркспейсе. Т.е. можно указать, что в папочке utils будет лежать utils/v1_2_3 из репозитория. А в другом воркспейсе utils будет замаплен на utils/v_head

ну с подобными запросами можно и до clearcase докатиться, не дай б-г :)

Не нужно на систему контроля версий завязывать то, что ей совсем не свойственно.

Развивайте CI. Пусть скриптами генерятся срезы всех требуемых конфигураций, валидируются, заливаются да хоть в git в отдельный проект, а в нужных ветках и проектах обновляются сабы. Ставьте платы на CI-сервера, пусть оно их конфигурирует и шьет в разных ипостасях.

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

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

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

После этого начинаются проблемы.

Если использовать сабмодули, то, как и писали выше, будет куча лишних коммитов, с просто обновлением хеша коммита зависимости. Причем, с увеличением уровней вложенности это все превращается в ад. После 3-4 уровня уже не важно, раз в неделю обновляется сабмодуль или раз в полгода. Делать десяток пустых коммитов, только для минорного обновления как-то глупо. Причем в строго определенной последовательности, по всем веткам. А потом окажется, что что-то пошло не так и надо ревертнуться...

Наиболее правильным мне кажется подход гугловского repo: есть некий глобальный конфиг с описанием гитовских репозиториев и путей, куда они должны быть скачаны. При этом для каждого репозитория из этого конфига указывается либо название гитовского бранча, либо конкретный коммит. Если указан бранч, то, при каждой синхронизации, будет браться последний коммит из указанной ветки.

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

+ в repo есть всякие удобности для работы с большим количеством репозиториев как с единым целым. Можно, например, выполнить глобальный git diff по всем репозиториям, во всех репозиториях создать новую ветки или просто зайти в каждый репозиторий и выполнить там кастомную команду.

Минус repo в том, что это не публичный продукт. Он гвоздями прибит к работе с герритом, с гугловским форматом коммитов и т.п.

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

На самом деле, можно обойтись и без репо. При добавлении сабмодуля можно указать ветку, к которой будет привязан сабмодуль, а затем при помощи команды git submodules update --remote (тут важен флаг --remote), можно обновить все сабмодули проекта до последних коммитов из их привязанных веток. Но, насколько я понимаю, таким образом не получится обновить рекурсивно по всем вложенным сабмодулям зависимости до последних версий.

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

* попадут в твой общий проект.

Наиболее правильным мне кажется подход гугловского repo: есть некий глобальный конфиг с описанием гитовских репозиториев и путей, куда они должны быть скачаны. При этом для каждого репозитория из этого конфига указывается либо название гитовского бранча, либо конкретный коммит. Если указан бранч, то, при каждой синхронизации, будет браться последний коммит из указанной ветки.

Мы именно это для себя и сделали для управления зависимостями в своих C++ проектах.

Немного подробностей здесь: https://www.slideshare.net/corehard_by/mxxruexternals-repositoryless-dependen... https://eao197.blogspot.com/2016/04/prog-mxxruexternals.html https://eao197.blogspot.com/2016/04/prog-mxxru-1610-mxxruexternals.html

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

Т.е. ci будет создавать тонну коммитов? И нафига такое счастье, особенно в репозиториях, куда редко коммитят, но которые зависят от многих сабмодулей. Там в основном будут нагенерированные коммиты.

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

Блин, ну ты вопросы такие задаешь мне. Откуда я знаю, как у ТС там всё устроено. У меня, например, есть реп reports, где только CI коммит определенные логи с тестов. И я всегда могу поглядеть, что поменялось - это супер удобно. Что за привычка копипастить, что код, что решение. Думать надо головой всегда.

Помоему, все опять скатывается к тому топику, из-за которого я зарегистрировался на лоре: Альтернатива git submodule

Прошло более 2х лет, а прогресса никакого....

Ну, у нас все работает ;)

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

Нет, не логично. Реп - это просто место хранения. У тебя сломана логика. Гит не поможет тебе декомпозировать твой проект. Выкинь все сабы, они не для этого.

Если у тебя есть общий код - сделай либу. Есть общие данные - инклюди их впесто копипасты. Это тривиально, и это не относится к гиту и это не относится к репозитарию.

Это в идеале.

А в реальности может быть сложней.

Вот реальный пример. Есть клиент multiplayer игры в C++. Есть сервер этой игры в Go. Для anti-cheat'а было бы приятно выполнять код логики игры и на сервере тоже (тот же код). Поэтому логика игры вынесена в Lua. Сгенерированы binding'и. C++ вызывает Lua, Go вызывает ту же Lua.

• Сервет в Go - это один проект.
• Клиент в C++ - второй.
• Их общая часть Lua.

Как из текстовых интерпретируемых инструкций Lua сделать либу? Клиент C++ так не умеет. У него внутри интерпретатор и VM, который выполняет Lua и binding'и. Почти каждое изменение binding'ов требует изменений в C++ и в Go.

Решений в итоге три:

• Поместить этого трехголового монстра в одно репо
• Сделать из Lua скриптов submodule
• Просто договориться что есть репозиторий с Lua и класть его надо в директорию такую-то для клиента C++ и такую-то для клиента Go

Выбрано было решение 2. Несмотря на то, что это один submodule зад у меня болит до сих пор.

Я даже не хочу думать, что было бы если бы их было больше.

Вариант номер 1 приведет к длительным checkout'ам.

Лучше всего похоже вариант 3 + скрипты (т.е. так как repo или subtree).

А все, что нужно было бы для этого простого проекта это хотя бы возможность автоматом генерить коммит «update Lua commit hash». И еще разные возможности. Т.е. плюшки. Свистелки и перделки. А в гите их нет. А почему нет? А потому что бесплатно. А в perforce должны быть. Потому что за деньги. И в repo видимо есть. Потому что Google.