Привет. Мы полностью переписали мобильную версию Хабра. Теперь все работает быстрее и выглядит современнее.

Боюсь вас расстраивать, но такое имя (gvfs) уже занято пруф

Боюсь вас расстраивать, но это перевод, а название придумал кто-то в недрах MS

:) Ну, это в их духе.


Про перевод не увидел, потому что нет тэга.

Gnome довольно успешно отстаивает свои права на название. Хотя не думаю, что gvfs — это чей-то торговый знак.
Интересно, как эту проблему решают под линуксом?

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


Имхо, такие вещи решаются никак не написанием костылей.
В git есть штатная подсистема для декомпозиции репозитория, я не верю, что кодовую базу которая, видимо, размером не менее 500mb нельзя разбить на независимые компоненты.

> каждый коммит вместе со своими деревьями и блобами занимает до 80 Гбайт.
не просто более 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 это, имхо, только симптом — раз есть такой монолитный и огромный кодебейз

Монолитный кодбейз — это норма. Между программами всегда есть связи. И если весь этот софт на компоненты смежности, то выяснится, что там всего одна. А дальше возникает вопрос, как с этим бороться.

Можно взять и разбить кодбейс на компоненты сильной связности, распихать их по разным git репозиториям. Потом ещё написать интеллектуальный сборщик, который будет их подтягивать. Потом интеллектуальную систему тестирования и автоматического формирования тестовых контейнеров. Потом интеллектуальный issue tracker и code review tool, которые способны работать с несколькими git репозиториями одновременно.

Т.е. для работы со всеми проектами одновременно, и со всему их связями, явными и неявными, всё равно нужна единая система. Можно написать и внедрить такую систему. Можно сделать как майкрософт — дополнить функциональность git чтобы он мог работать с единым большим репозиторием, и переиспользовать уже существующие инструменты для разработки с git. Но нельзя закрыть глаза и представить, что проблема исчезнет, если о ней перестать думать.

Если честно, я уже давно жду, что git сменит какая-то более продвинутая система. Надоесть людям костыли поверх гит городить, и они вместо этого напишут более функциональную систему контроля версий.

Gitlab/stash/bitbucket/github уже всё это умеют :) Я специально поставил в начало списка то, что чаще всего используют для закрытых проектов.


man git-submodule


Ещё и версионированные компоненты получаются. Т.е. можно держать например саппортную ветку где компоненты потухлее а бизнесс логика пилится например потихоньку под нужды 2-х с половиной жирных клиентов. Очень просто откатить бажный компонент к стабильной ветке естественным путём.

Далеко не всё они умеют. Именно поэтому майкрософту пришлось писать свои костыли для работы с git-submodule. Но костыли со временем показывают свою несостоятельность — их надо постоянно расширять для совместимости с другими решениями, к тому же развивающимися по независимым направлениям.

Гит сабмодуль не может быть удобным для всех — иначе люди не предпочитали бы пользоваться пакетными менеджерами вроде 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 в чистом виде похоже не нужен никому.

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

команд в Микрософт
Вот, а они себя называют Майкрософт.
переименовал в Microsoft шоб уж наверняка :)
И в-третьих, большинство разработчиков не хотят быть экспертами в системах контроля версий, они бы предпочли, чтобы доступные инструменты делали это за них. Для работы с git разработчику необходимо научиться работать с направленным ациклическим графом (DAG, Directed Acyclic Graph), что уже непросто, а тут мы просим его работать с несколькими слабосвязанными направленными ациклическими графами одновременно и к тому же следить за порядком выполнения checkout/commit/push в них. Это уже слишком.

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