Comments 20
Боюсь вас расстраивать, но такое имя (gvfs) уже занято пруф
То же ядро линукс достаточно толстое, что бы просто пойти и выкачать его на 3g канале, но всегда можно склонировать с нужной глубиной.
Имхо, такие вещи решаются никак не написанием костылей.
В git есть штатная подсистема для декомпозиции репозитория, я не верю, что кодовую базу которая, видимо, размером не менее 500mb нельзя разбить на независимые компоненты.
не просто более 500mb, а до 80 Гбайт со служебной информацией о коммите.
Есть проблема с репозиториями, если кода достаточно много и разные компании решают эту проблему по разному (Google, Yandex, Facebook, Microsoft). Ядро линукса — не такой и большой проект.
В Yandex когда-то давно SVN был, теперь Mercurial, в Google свой велосипед, который можно чек-аутить как Git — как пишут в интернетах.
Вот дело как раз в том, что товарищи не хотят следовать принципу разделяй и властвуй(о чём, как раз и заявляют). Заместо этого, как обычно следуют принципу embrace, extend and extinguish, напрягая своими телодвижениями как минимум два сообщества за раз:) Сейчас эта поделка взлетит у windows only людей, а потом они захотят портировать решение. А как? А git г-но, там же нет gvfs из коробки и вообще под этим вашим линуксом какая то хрень в пакете gvfs лежит, наша монструозная кучка испражнений даже на ci будет хрен пойми как работать.
Ну это мой взгляд на проблему. На самом деле, это open source и кто как хочет, тот так и развивает свои форки.
При этом, проблема с git это, имхо, только симптом — раз есть такой монолитный и огромный кодебейз, это сколько же людей в ms понимают его хотя бы на компонентном уровне?
Монолитный кодбейз — это норма. Между программами всегда есть связи. И если весь этот софт на компоненты смежности, то выяснится, что там всего одна. А дальше возникает вопрос, как с этим бороться.
Можно взять и разбить кодбейс на компоненты сильной связности, распихать их по разным git репозиториям. Потом ещё написать интеллектуальный сборщик, который будет их подтягивать. Потом интеллектуальную систему тестирования и автоматического формирования тестовых контейнеров. Потом интеллектуальный issue tracker и code review tool, которые способны работать с несколькими git репозиториями одновременно.
Т.е. для работы со всеми проектами одновременно, и со всему их связями, явными и неявными, всё равно нужна единая система. Можно написать и внедрить такую систему. Можно сделать как майкрософт — дополнить функциональность git чтобы он мог работать с единым большим репозиторием, и переиспользовать уже существующие инструменты для разработки с git. Но нельзя закрыть глаза и представить, что проблема исчезнет, если о ней перестать думать.
Если честно, я уже давно жду, что git сменит какая-то более продвинутая система. Надоесть людям костыли поверх гит городить, и они вместо этого напишут более функциональную систему контроля версий.
Gitlab/stash/bitbucket/github уже всё это умеют :) Я специально поставил в начало списка то, что чаще всего используют для закрытых проектов.
man git-submodule
Ещё и версионированные компоненты получаются. Т.е. можно держать например саппортную ветку где компоненты потухлее а бизнесс логика пилится например потихоньку под нужды 2-х с половиной жирных клиентов. Очень просто откатить бажный компонент к стабильной ветке естественным путём.
Гит сабмодуль не может быть удобным для всех — иначе люди не предпочитали бы пользоваться пакетными менеджерами вроде maven и gems. Опять же, я пробовал использовать git для ведения вики — очень неудобно, т.к. различные страницы должны иметь больше независимости, чем им даёт гит.
пробовал использовать git для ведения вики
Я тоже пробовал на велосипеде с зилом гоняться, есть даже пару мест, где обогнать смог.
git таки scm, а не пакетный менеджер и не wiki-движок
По теме: статья про то, что надо использовать не сабмодули а огромный репо, в который штатный механизм гит производит коммит около часа, т.к. обьём имеющейся файловой системы есть ~280Gb. Т.е. если у вас огромный кодебейз, над 1 процентом которого (не забываем это сорцы) физически нереально работать одному разработчику, то нет, не надо его декомпозировать, давайте лучше напишем костыль, что бы нивелировать совместимость с и все достоинства исходного решения, а потом, промоем неофитам мозги в сми, что бы они возлюбили щупальца.
Для работы с git разработчику необходимо научиться работать с направленным ациклическим графом (DAG, Directed Acyclic Graph), что уже непросто
Серьезно? Понять ациклический граф сложно?
Знающие люди объясните мне пожалуйста, зачем они взяли существующую децентрализованную систему и приделали к ней костыль, чтобы она стала по сути централизованной? Я не могу понять.
Серьезно? Понять ациклический граф сложно?
Как ни странно. Мы несколько лет назад перешли на git, но до сих пор иногда приходится «ну, представь, вся история — это один большой граф, а бранчи — стрелочки на отдельные коммиты»
Вот xkcd это очень точно подметил. Очень многие просто зазубривают десяток команд — и это 99% всех потребностей покрывает.
Да, есть такое, некоторые просто заучивают серии команд, ну или на крайний случай машинально запоминают куда, что и в какой последовательности нажать в GUI. А когда-то программисты смеялись над секретаршами )))
Но меня удивило именно про понимание графа. А извините меня, деревья это частный случай графа. Т.е. судя по написанному — программисты которые работают в Microsoft и пользуются Git с трудом понимают как работают деревья в том числе. Или я уже что-то проспал и деревья стали продвинутой структурой данных?
Но меня удивило именно про понимание графа. А извините меня, деревья это частный случай графа. Т.е. судя по написанному — программисты которые работают в Microsoft и пользуются Git с трудом понимают как работают деревья в том числе. Или я уже что-то проспал и деревья стали продвинутой структурой данных?
HTML есть частный случай XTML.
JSX есть частный случай XTML.
…
А вот XTML в чистом виде похоже не нужен никому.
команд в МикрософтВот, а они себя называют Майкрософт.
И в-третьих, большинство разработчиков не хотят быть экспертами в системах контроля версий, они бы предпочли, чтобы доступные инструменты делали это за них. Для работы с git разработчику необходимо научиться работать с направленным ациклическим графом (DAG, Directed Acyclic Graph), что уже непросто, а тут мы просим его работать с несколькими слабосвязанными направленными ациклическими графами одновременно и к тому же следить за порядком выполнения checkout/commit/push в них. Это уже слишком.
Тут получается разработчик достаточно грамотный что бы код писать, но не достаточно грамотный что бы уметь его хранить.
История создания Виртуальной Файловой Системы Git (GVFS, Git Virtual File System)