Я пропустил звено в переходе от форков к монорепозиторию с виндой, а отредактировать комментарий уже не получается.
Думаю, что все эти пляски с сортировкой веток и коммиттеров связаны как раз с этим. В MS запихнули все исходники винды в один git-репозиторий, и под это дело допилили виртуализацию staging area, сортировки и sparse checkout.
После слияния - удаляли, разумеется. Часть руками, часть автоматом. Если бы не кнопка "Delete merged branches", веток было бы еще больше.
Еще были эксперименты в отдельных ветках, которые так никуда и не пошли. Я несколько раз кликал клич, мол, "ув. коллеги, удалите всё, что вам не нужно". Что-то удаляли, что-то оставалось ("оставь, я потом доделаю!". "потом" не наступало).
В общем случае нет, не то же самое. Git изначально задумывался как инструмент для коллективной работы над одним кодом.
Кстати, про ci-build еще забыли. Его обычно для репозитория индивидуально настраивают. Т.е. для каждого форка своё придётся делать.
Я не отрицаю, что над одним проектом можно вести работу в разных форках, и потом как-то их сливать. Но мне кажется, что форк в данном случае лишняя сущность. И так у каждого участника по копии уже есть.
Однако, и всю винду целиком в один монореп запихивать - это тоже очень странно.
Подход Гугла к хранению исходников Android мне нравится больше. ROS2 примерно так же хранит свой код (https://github.com/ros2). Там пачка относительно небольших репозиториев, в каждом хранится отдельная логически законченная часть прокета. И есть https://github.com/dirk-thomas/vcstool который выкачивает или переключает всю эту пачку разом на нужные коммиты, в зависимости от того, что сказано в YAML с конфигурацией
В общем я за разумное укрупнение или дробление там, где это реально нужно.
Думаю, что форки - это всё же не для командной работы, а для возможности иметь своё "такое же, но с перламутровыми пуговицами". Команды и на гитхабе в один реп коммитят.
Один из моих проектов с командой из 5-6 человек за 3 года оброс 400 с лишним ветками. Размер репа составлял больше 1Гб.
Другой проект длился 6 лет, разрабатывался двумя командами из 8 и 11 человек. Тоже несколько сотен веток запросто накопилось. Два или три раза переезжали в другой репозиторий: останавливали коммиты в текущий, переводили его в read-only и заводили новый из текущего слепка. В этом случае еще большие бинарные файлы (ассеты для UE4) и Git LFS прибавились.
Если моя фича зависит от васиной, то, чтобы проверить свои результаты, я должен буду притянуть в свой форк васину ветку, ребейзнуть свои коммиты на неё или слить мою ветку с васиной.
Если Вася где-то не прав, и я могу это исправить, то получается еще одна ветка.
CI-build для ядра линукса? С matrix-конфигом со всеми вариантами? Ннууу, технически это, вероятно, осуществимо, но на практике вряд ли кому-то по силам
// Copyright Epic Games, Inc. All Rights Reserved.
#pragma once
#include "CoreMinimal.h"
#include "PaperSprite.h"
#include "ComponentAssetBroker.h"
#include "PaperSpriteComponent.h"
#include "PhysicsEngine/BodySetup.h" // <<---
//////////////////////////////////////////////////////////////////////////
// FPaperSpriteAssetBroker
....
Файл BodySetup.h находится в Engine/Source/Runtime/Engine/Classes/PhysicsEngine/ и там нет ссылок ни на что, кроме PhysX и Chaos.
Так что да, всё та же PhysX (или Chaos) с заблокированной одной пространственной осью. Т.е. в 2D-играх объектам просто не позволяют перемещаться в направлениях, выводящих за плоскость, в которой происходит гемплей.
Вот Вам идея для эксперимента: попробовать реализовать одну и ту же игровую механику на PhysX и на Chaos и рассказать о результатах и полученном опыте.
В исходниках UE4 есть отдельные ветки 4.26-chaos и 4.27-chaos. Я не заглядывал туда, но названия подсказывают, что там другая физика.
Chaos тоже не идеален. Я в прошлые пару лет участвовал в проекте по созданию аналога Gazebo на UE, так там несколько раз пытались переехать на UE5, но так пока и остались на 4.26 из-за бага в Chaos, который рушил всю симуляцию.
А время на настройку Visual Studio, знакомство с его возможностями, поиск плагина, знакомство с плагином, где?
Так почти не было его. В школе на Turbo Pascal писал, потом Turbo C. Visual Studio после них как-то само зашло. На плагин пару часов, вроде бы, потратил.
В общем не вижу тут особой разницы. И там и там разовая работа по самообразованию, которая повышает ваш навык и вашу цену как эксперта
Разница в том, в какой области какой функционал проработан. В линуксах/макоси тоже не всё везде блестяще.
Я пропустил звено в переходе от форков к монорепозиторию с виндой, а отредактировать комментарий уже не получается.
Думаю, что все эти пляски с сортировкой веток и коммиттеров связаны как раз с этим. В MS запихнули все исходники винды в один git-репозиторий, и под это дело допилили виртуализацию staging area, сортировки и sparse checkout.
После слияния - удаляли, разумеется. Часть руками, часть автоматом. Если бы не кнопка "Delete merged branches", веток было бы еще больше.
Еще были эксперименты в отдельных ветках, которые так никуда и не пошли. Я несколько раз кликал клич, мол, "ув. коллеги, удалите всё, что вам не нужно". Что-то удаляли, что-то оставалось ("оставь, я потом доделаю!". "потом" не наступало).
В общем случае нет, не то же самое. Git изначально задумывался как инструмент для коллективной работы над одним кодом.
Кстати, про ci-build еще забыли. Его обычно для репозитория индивидуально настраивают. Т.е. для каждого форка своё придётся делать.
Я не отрицаю, что над одним проектом можно вести работу в разных форках, и потом как-то их сливать. Но мне кажется, что форк в данном случае лишняя сущность. И так у каждого участника по копии уже есть.
Однако, и всю винду целиком в один монореп запихивать - это тоже очень странно.
Подход Гугла к хранению исходников Android мне нравится больше. ROS2 примерно так же хранит свой код (https://github.com/ros2). Там пачка относительно небольших репозиториев, в каждом хранится отдельная логически законченная часть прокета. И есть https://github.com/dirk-thomas/vcstool который выкачивает или переключает всю эту пачку разом на нужные коммиты, в зависимости от того, что сказано в YAML с конфигурацией
В общем я за разумное укрупнение или дробление там, где это реально нужно.
Авторы (или кто-то за авторов) объясняют это тем, что git не вывозит такого размера кода. Точнее, раньше не вывозил, а теперь может.
Вот тут пишут, что MS все исходники винды в git monorep запихнула. Для этого все нововведения и понадобились
Думаю, что форки - это всё же не для командной работы, а для возможности иметь своё "такое же, но с перламутровыми пуговицами". Команды и на гитхабе в один реп коммитят.
А иначе тупо не понятно, где автора искать.
Это GitHub так вывернулся. Про Gitlab, Bitbucket, Gitea, gogs и прочие хостинги мне ничего не известно.
В gerrit, насколько я помню, вообще нет понятия форка.
Предлагаете заинтересованным покупать GitHub Enterprise?
Для этого придумали всякие git-flow, github-flow, gitlab-flow.
Чтоб ветка master была одна, репозиторий тоже был один, и было единственное место, куда складывается проверенный и оттестированный код.
(в сторону) блин, да что же их "Хижина дяди Тома" остальным-то жить спокойно не даёт?
Видимо, речь про Microsoft и запихивание всех исходников Windows в монореп git. Там в последнем предложении ссылка на английскую статью про это.
Один из моих проектов с командой из 5-6 человек за 3 года оброс 400 с лишним ветками. Размер репа составлял больше 1Гб.
Другой проект длился 6 лет, разрабатывался двумя командами из 8 и 11 человек. Тоже несколько сотен веток запросто накопилось. Два или три раза переезжали в другой репозиторий: останавливали коммиты в текущий, переводили его в read-only и заводили новый из текущего слепка. В этом случае еще большие бинарные файлы (ассеты для UE4) и Git LFS прибавились.
Если моя фича зависит от васиной, то, чтобы проверить свои результаты, я должен буду притянуть в свой форк васину ветку, ребейзнуть свои коммиты на неё или слить мою ветку с васиной.
Если Вася где-то не прав, и я могу это исправить, то получается еще одна ветка.
Не обязательно. Если васина фича зависит от моей, а моя - от васиной, то у каждого в репе будут чужие ветки и по два remote, свой и товарища
Приходим к выводу, что двоим-троим всё же удобнее в один реп коммитить, а не в три.
Вот у инженера интеграции и получается описанная изначально ситуация.
Кстати, не подскажете, в форках репозиториев лежат копии файлов или ссылки на оригинал?
А то диски на сервере всё-таки не резиновые, и если проект сильно большой, это может быть критично.
Т.е один проект (репозиторий) - один исполнитель?
Что предлагаете делать в случае, если проект большой, и одного исполнителя мало?
Компилировать код без оптимизаций и с отладочной информацией, а в gdb/lldb/visual studio запускать питон. Примерно так.
CI-build для ядра линукса? С matrix-конфигом со всеми вариантами? Ннууу, технически это, вероятно, осуществимо, но на практике вряд ли кому-то по силам
RTFS (read those f...ine sources). Открываем какой-нибудь исходник из плугина Paper2D и видим там ссылку на PhysicsEngine.
Файл BodySetup.h находится в
Engine/Source/Runtime/Engine/Classes/PhysicsEngine/и там нет ссылок ни на что, кроме PhysX и Chaos.Так что да, всё та же PhysX (или Chaos) с заблокированной одной пространственной осью. Т.е. в 2D-играх объектам просто не позволяют перемещаться в направлениях, выводящих за плоскость, в которой происходит гемплей.
https://docs.unrealengine.com/4.27/en-US/AnimatingObjects/Paper2D/HowTo/Physics/
Судя по официальной доке, это всё тот же PhysX, но с залоченной одной пространственной осью.
Да и PhysicsCore плугин ничего другого не содержит.
Вот Вам идея для эксперимента: попробовать реализовать одну и ту же игровую механику на PhysX и на Chaos и рассказать о результатах и полученном опыте.
В исходниках UE4 есть отдельные ветки 4.26-chaos и 4.27-chaos. Я не заглядывал туда, но названия подсказывают, что там другая физика.
Chaos тоже не идеален. Я в прошлые пару лет участвовал в проекте по созданию аналога Gazebo на UE, так там несколько раз пытались переехать на UE5, но так пока и остались на 4.26 из-за бага в Chaos, который рушил всю симуляцию.
Еще интересная идея: https://www.stevestreeting.com/2020/07/26/using-bullet-for-physics-in-ue4/
В UE4 используется не собственный физический движок, а PhysX от nVidia.
Свой движок Chaos Destruction вместо PhysX они только в пятой версии начали использовать.
Не всё так страшно. Если чуть-чуть не подходит, можно допилить.
Так почти не было его. В школе на Turbo Pascal писал, потом Turbo C. Visual Studio после них как-то само зашло. На плагин пару часов, вроде бы, потратил.
Разница в том, в какой области какой функционал проработан. В линуксах/макоси тоже не всё везде блестяще.
А навыки совершенствовать надо постоянно, да.