Источник
В одном из самых знаменитых танго в истории Карлос Гардель пропел хорошо известные строки:
Ощутить… что жизнь – глоток свежего воздуха,
что двадцать лет – ничто,
что лихорадочный взгляд,
бродящий в тенях,
находит тебя и называет по имени.
Двадцать лет назад
Второе издание Совершенного кода Стива Макконнелла было опубликовано в 2004 году. На 668 странице этого девятисотстраничного талмуда мы находим единственное упоминание темы управления исходным кодом на всю книгу, длиной примерно в три четверти страницы. Больше ничего. ChatGPT без труда обобщил бы сказанное в этих абзацах в одном предложении: «Применение ПО для контроля версий – это хорошо, оно дает несколько существенных преимуществ». Не бог весть какие новости. От GitOps нас тогда отделяло очень многое.
В том же году, почти за двадцать лет ровно до момента опубликования этой статьи, увидела свет Subversion 1.0. Что такое Subversion? Возможно, самая недолговечная из всех благонамеренных идей в истории программирования. Видите ли, Subversion (или svn) должна была стать лучшей версией CVS (нет, не аптекой, а системой одновременных версий). «Лучше, чем CVS» в те времена подразумевало транзакциональность (базы данных, как насчет?) и сколько-нибудь улучшенную поддержку ветвления. Тогда, ребятки, мы о большем и не мечтали.
Линус Торвальдс, впрочем, мечтал. В 2004 году между разработчиками ядра Linux усиливались разногласия по поводу использования BitKeeper, лицензионной распределенной системы контроля версий, которая использовалась для управления исходным кодом ядра. И как же тут быть простому программисту? Что ж, у Линуса была традиция создавать ПО, в котором все нуждались и за которое никто не хотел браться. Была у него и другая традиция: называть всё подряд в свою честь. Согласно преданиям, первая версия Git была написана за пару недель.
CVS
Слышали когда-нибудь о CVS? Это система управления исходным кодом, которую Джоэл Спольски в сентябре 2000 года описал как неплохую (курсив его) в первом пункте своего одноименного теста Джоэла, предназначенного для улучшения ПО.
Я пробовал платные пакеты для управления исходным кодом и пробовал CVS, которая распространяется бесплатно, и должен вам сказать: CVS неплоха.
Да, первый шаг к улучшению ПО – это (шок, сенсация!) использование программ для управления исходным кодом. В скобках замечу, что я начинал свою карьеру программиста в 1997 году, и нет, мы не использовали никаких систем управления исходным кодом, даже CVS. Да, вы угадали: мы просто сохраняли файлы VBScript локально и загружали их по FTP. Если одни изменения перекрывали другие, то очень жаль, живем один раз. Мне пришлось дожидаться 2002 года, что впервые воспользоваться программой для управления исходным кодом (для любопытных, это была Rational ClearCase).
А Джоэле Спольски слышали? Ну, он приложил руку к созданию Stack Overflow, которым, полагаю, в какой-то момент на протяжении карьеры пользовался каждый. 24 года назад Джоэл был одним из первых инфлюэнсеров в зарождающемся информационном поле разработки ПО. Типа как Келси Хайтауэр, только с более неоднозначными взглядами. Или как Стив Йегге, только с менее неоднозначными взглядами.
Раз уж речь зашла о Stack Overflow, то вот вам пример передовых методов управления версиями в 2008 году. Один из самых первых вопросов, заданных на этом сайте, датирующийся 8 сентября 2008 года, касался как раз-таки того, какую систему контроля версий выбрать разработчику, работающему в одиночку. Что интересно, этот вопрос был задан в тот самый момент, когда в реальном мире бушевал финансовый кризис 2008 года. Наша индустрия вне всяких сомнений живет в пузыре. Но я снова отвлекаюсь от темы.
Я пытаюсь подыскать систему управления исходным кодом для личного использования, и чем проще, тем лучше. Главное, что мне нужно – возможность читать и извлекать старые версии своего кода. Других разработчиков, кроме меня, нет.
Ответы на этот вопрос составляют пространный каталог, содержащий практически каждую систему управления версиями, известную человечеству на тот момент.
Одиссея контроля версий Windows
Но вернемся в 2000 год. За несколько дней до того, как Джоэль Спольски опубликовал свой тест, Марк Луковски выступил с докладом на тему «Windows: одиссея программирования» на Четвертом Симпозиуме USENIX по Системам Windows в Сиэтле, Вашингтоне. Мистер Луковски был членом первой команды Windows NT с 1988 года до середины 2000-х. На момент написания статьи презентация к докладу еще остается доступна в сети, и я всерьез рекомендую с ней ознакомиться.
Причина в том, что в эту одиссею помимо прочего входило – угадали – управление исходным кодом. Из 14-го слайда мы узнаем, что команда Windows NT 3.51 пользовалась «системой, разработанной внутри компании», которая к 2000 году была «на последнем издыхании»:
Поддерживать компьютер в синхронизированном состоянии было тяжким трудом (неделя на настройку, два часа в день на синхронизацию).
Ой. Не лучший вариант для онбродинга новичков. Теперь вы понимаете, почему манифест Agile, опубликованный в 2001 году, считается таким революционным. Благодаря Реймонду Чену, возможно самому влиятельному преподавателю истории Windows, нам известно название этой внутренней разработки:
На ранних этапах Microsoft использовала систему управления исходным кодом собственного производства; формально она называлась Source Library Manager, но обычно ее сокращали до SLM и произносили как «слайм» (slime, слизь). Это была простая система без поддержки ветвления.
Из 24-го слайда презентации Марка Луковски мы узнаем, что компания Microsoft приняла решение перенести Windows 2000 на что-то под названием Source Depot. Реймонд Чен подтверждает:
Вскоре после выпуска Windows 2000 исходный код Windows был перенесен в систему управления исходным кодом, известную как Source Depot, которая являлась санкционированным ответвлением Perforce.
Почему Perforce? Это объяснялось огромными размерами исходной кодовой базы Microsoft Windows:
Объяснение сейчас, вероятно, прозвучит не так убедительно, как раньше, но Perforce в среднем лучше себя показывал на крупных репозиториях, чем Subversion. Это стало одной из причин, по которым Microsoft приобрела лицензию на исходный код Perforce для создания Source Depot; NT – это нечто чудовищное, и немногие продукты, как бесплатные, так и платные, способны с ним справиться.
Марк Луковски изложил преимущества Source Depot в двух пунктах на 24-м слайде своей презентации:
Настройка нового компьютера: 3 часа против 1 недели
Стандартная синхронизация: 5 минут против 2 часов
Использует ли команда Microsoft Windows Source Depot и по сей день? Как выясняется, нет. В 2017 году в статье на Ars Technica сообщалось, что Microsoft перенесла все 300 Гб исходного кода на Git. Там прозвучала еще одна отличная фраза, описывающая одиссею Microsoft в поисках систем управления исходным кодом:
Давным-давно у компании было нечто под названием SourceSafe, пользоваться которым, по общему согласию, было с нравственной точки зрения равноценно тому, чтобы бросить свой драгоценный код в мусорное ведро и поджечь, из-за склонности системы наносить повреждения базе данных.
Могу подтвердить его слова. К крайнему своему сожалению, надо сказать.
Переход Microsoft на Git, однако, не прошел без сучка без задоринки, и это привело к созданию проекта Git Virtual File System (GVFS):
Но Git не рассчитан на репозитории весом в 300 Гб, состоящие из 3,5 миллионов файлов. Microsoft пришлось взяться за проект по кастомизации Git, чтобы дать ему способность работать с масштабами компании.
Эпоха Git
Страсть Microsoft к Git достигла своего пика в 2018 году, с поглощением GitHub, той платформы, которая, как некоторые считают, сделала Git мэйнстримом. За три года до этого, ощущая дух времени, компания выпустила Visual Studio Code со встроенной поддержкой Git.
GitHub представил миру концепт pull request-ов еще в феврале 2008 года, позже его переняли GitLab, Gitea (и ее недавнее ответвление Forgejo) и BitBucket и он стал хлебом насущным в инспекции кода на следующие 15 лет. Но вместе с тем GitHub создал еще и парадокс в мире Git: внезапно распределенная система управления исходным кодом стала… централизованной. Некоторые люди в шоке от такого поворота событий, и их можно понять.
Сейчас идет 2024 год, и Git окружает нас. Долгий путь эволюции, который привел к господству Git в 2010-х (и, как видно, в 2020-х тоже), можно представить в виде последовательности программ с открытым кодом, сменяющих друг друга: SCCS в 1970-х, RCS в 1980-х, CVS в 1990-х и Subversion в 2000-х. Чтобы обеспечить гладкую миграцию, Subversion импортировал репозитории CVS, а Git импортирует репозитории Subversion. Но самое-то главное: системы контроля версий перешли от строго локальных типа SCCS и RCS, к архитектуре вида «клиент-сервер» (CVS и Subversion), а затем к распределенным системам типа Git и прочих, самая примечательная из которых – Mercurial. Кстати насчет Mercurial, а вы знали, что разработчики Firefox недавно решили от нее отказаться и перейти на Git?
На сегодняшний день для нас стало привычным клонировать целый проект на свой компьютер, после чего можно спокойно отключиться от сети и продолжать писать код полностью офлайн. Двадцать лет назад эта простая парадигма была совершенно немыслимой. И, кстати сказать: в вашем локальном репозитории также сохраняется полная хроника всех изменений, которые когда-либо вносились в проект. Подобную возможность системы типа «клиент-сервер», разумеется, предоставить не могли (спойлер: полная хроника была у сервера, а у клиента – только, так сказать, HEAD).
Git (и его доступные возможности для ветвления) изменил ход работы программистов на годы вперед. В январе 2010 года Винсент Дриссен опубликовал основополагающую статью под названием «Успешная модель ветвления в Git» и представил миру спорный концепт git-flow. Почему спорный? Ну, потому что большая часть мнений в разработке относится к спорным. Сейчас существуют GitHub flow и Atlassian Gitflow и много других вариантов рабочего процесса с ветвлением.
Репозитории Git стали богатыми на события: каждая отправка, слияние или операция с тэгами затрагивает какой-то рабочий процесс. Возникла целая индустрия с такими называниями, как Argo CD, GitHub Actions, GitLab CI/CD pipelines и Gitea Runner, обеспечивающая новый уровень автоматизации и удобства. Влияние Git в этой сфере так сильно, что понятием GitOps теперь обозначается целый сегмент индустрии. Только для развертывания ветки не используйте, я вас предупредил.
Теперь перед нами встает простой вопрос: что будет после Git? На данный момент оспорить его огромную популярность, наверное, не представляется возможным. Я говорю «наверное», потому что в нашей индустрии нельзя предсказать будущее. Есть два любопытных претендента, достойных упоминания: Pijul, написанный на Rust (хотя десять лет назад проект начинался на OCaml), и Fossil, написанный создателями SQLite. Во втором случае команда SQLite предоставила список аргументов против использования Git:
Будем откровенны. Мало кто станет спорить с тем, что Git предоставляет не лучший пользовательский опыт. Многие особенности имплементации просвечивают сквозь интерфейс. Интерфейс настолько плох, что появился даже пародийный сайт, генерирующий поддельные man-страницы.
Пока мы дожидаемся альтернатив получше, давайте почитаем man-страницу 7 giteveryday и призовем на помощь git-дополнения: SourceTree, TortoiseGit, Fugitive, Codeberg и Magit. Похоже, что в ближайшие двадцать лет мы будем хранить ход в репозиториях Git, нравится нам это или нет.
Комментарии (56)
andy_p
11.04.2024 13:44+13Слышали когда-нибудь о CVS?
Не только слышали, но и вовсю использовали. Более того, использовали и ее предшественницу - систему rcs.
unreal_undead2
11.04.2024 13:44+1Слышали когда-нибудь о CVS
Помню как на работе на него переходили как на прогрессивное решение - после чего были и svn и git (с внутривидовым переходом gitlab->github)...
krig
11.04.2024 13:44+6«Лучше, чем CVS» в те времена подразумевало ... сколько-нибудь улучшенную поддержку ветвления.
Не довелось работать с CVS, и не могу представить себе на сколько там была плохая система работы с ветками, если то что было в SVN называют "улучшенной поддержкой" - пользоваться ветками в свн было просто невозможно. В проекте среднего размера создание ветки занимало полторы вечности. И даже если хватало терпения дождаться ее создания и синхронизации с сервером, то пользоваться ими для разработки фич было невозможно.
Тогда, ребятки, мы о большем и не мечтали.
Очень даже мечтали - например, не терять изменения, когда несколько человек работали над одним файлом. Кто занимался резолвом конфликтов в свн - тот в цирке не смеется.
unreal_undead2
11.04.2024 13:44+5В CVS всё - коммиты, история, ветки - было на уровне отдельных файлов (т.е. у каждого файла своя последовательность версий, коммит изменений в несколких файлов по сути распадался на последовательность независимых коммитов), какое то версионирование репозитория в целом делалось только тегами.
В проекте среднего размера создание ветки занимало полторы вечности
А зачем делать ветки для всего проекта? Обычно он разбивается на компоненты обозримого размера и ветка делается для отдельной компоненты. Работал над продуктом, который с нуля компилировался несколько часов, проблем с ветками в период времени, когда жили на svn, не помню. И в любом случае там же COW, реально svn copy полную копию не создаёт.
wslc
11.04.2024 13:44+2В проекте среднего размера создание ветки занимало полторы вечности.
На сервере должна мгновенно создаваться. На клиенте switch тоже быстро должен работать.
> Кто занимался резолвом конфликтов в свн - тот в цирке не смеется.
А в git что изменилось с этим?
inkelyad
11.04.2024 13:44+3А в git что изменилось с этим?
Гит был заметно догадливей по поводу тех изменений, которые уже успели слить.
SVN до какого-то момента, если попадал на ромбовидную схему слияния (т.е. A в B, A в C и теперь хочешь B и C слить) - практически гарантированно давал конфликты. Или если руками кусок кода скопировал. В точность такой же, как в той ветке, что сливаешь.
Потом в нем это исправили, но было уже поздно.
mmMike
11.04.2024 13:44+1то как слил (в рамках одного файла как минимум) GIT все равно приходится проверять глазами. Иначе, если доверять, возникают неожиданности в прикладной логике.
Редко. Но возникают.
PrinceKorwin
11.04.2024 13:44+4О да! Особенно в этом плане отличаются IF-ELSE с условиями на несколько строк.
Разные коммиты затрагивают разную часть условия и по отдельности корректны. А слитые воедино без конфликтов - уже нет.
inkelyad
11.04.2024 13:44+3Одно дело проверять, другое дело - плеваться и рычать "Да тут же совершенно одинаковый, с точностью до пробелов, код на вершине двух веток, где тут конфликт?"
unreal_undead2
11.04.2024 13:44Инструменты типа emerge в Emacs помогали быстрее по таким тривиальным конфликтам пройтись.
klvov
11.04.2024 13:44+4Оно и работало быстро. В svn создание ветки было очень быстрой и дешевой операцией, что в те времена было на острие технического прогресса, потому что так умели тогда далеко не все системы контроля версий, даже платные. Это ускоряло и облегчало разработку просто в разы. Репозиторий хранился в централизованной БД на сервере, и для работы требовалась связь с ним - это да, но при работе над маленькими и средними проектами в рамках одной компании это абсолютно не мешало. Хотя сверхогромные проекты, такие как Windows NT, svn скорее всего не потянул бы.
unreal_undead2
11.04.2024 13:44+2Я и с git'ом commit и push всегда вместе запускаю, мало ли что с локальной машиной случится.
atshaman
11.04.2024 13:44+2ЕМНИП, там создание ветки - что-то вроде симлинка, вот работа со слияниями - таки боооль, но с учетом того, что (у нас) базовый флоу и не предполагал "по-ветке-на-фичу" - не то, чтобы совсем уж жить мешало...
kekoz
11.04.2024 13:44А я RCS и сегодня использую, в основном для некоторых конфиг-файлов, Git в простейших, но при этом требующих контроля версий, ситуациях очень уж похож на пушку при охоте на воробьёв, рогатки достаточно :)
excoder
11.04.2024 13:44+1Неееее. Это то самое ружье, которое обязательно стреляет тебе в ногу. Но если С++ стреляет, скажем, 5 раз, то git – 50.
atshaman
11.04.2024 13:44en masse ушло в прошлое вместе с редактированием конфигурации на сервере же?
notffirk
11.04.2024 13:44+4А ещё visual sourcesafe, perforce, tfs..
unreal_undead2
11.04.2024 13:44+4На VSS долго жили. Особенно "радовали" ситуации, когда человек чекаутил важный файл для изменений и уходил в отпуск.
Dmitry_604
11.04.2024 13:44+3Ага или бежать приходилось в соседние кабинеты: "зачем держишь, отпусти" :)
excoder
11.04.2024 13:44+3Использовали CVS, RCS, Perforce, SVN, Mercurial, TFS. Ничего отвратительнее git не встречал. Но приходится использовать, потому что всё на нём, в современном мире только так... Ведь и сам автор, Торвальдс, в первом коммите написал, что это будет отвратительная система, так оно и получилось. То же самое с современной архитектурой зданий, дизайном автомобилей типа Cybertruck и т.д. Уродство вываливается на нас, а мы рады его принять.
lumag
11.04.2024 13:44+1Monotone пришлось попользоваться. Кажется, самое ужасное творение. Хотя нет, ещё был arch.
AllexIn
11.04.2024 13:44+7Git превратился в франкенштейна. Оброс огромным количеством костылей из-за которых его использование превратилось в хождение по минному полю.
Самый яркий(но не единственный) пример - LFS:
- У нас децентрализованная система для работы с исходниками!
- Нам нужно хранение больших файлов.
- Берите другую систему контроля версий.
- Они дорогие. И вообще мы привыкли к гиту.
- Ну ладно. Вот вам LFS. У нас как бы децентрализованная система, но без центрального сервера она работать не будет. И, кстати, вам теперь отдельно придется резолвить работу с LFS поинтерами.
Проблема гита в том, что вместо того чтобы развиваться отбрасывая легаси - он обрастает новыми фичами, противоречащими старым фичам, оставляя поддержку старых. Все боятся что-нибудь отрезать от гита, в итоге получается монстр.
Ни одна команда не использует все возможности гита. Обычно выбирается список гит фичей, которые разрешены к использованию и строго придерживаются флоу.
Отдельно "доставляет" гит комьюнити. Есть прослойка людей, которые что-то знают про гит и они чертовски ЧСВшные. Не дай бог покритикуешь гит, они прибегут и расскажут что ты идиот и не правильно используешь гит. Иди кури маны.
Но есть нюанс, я идиот и не знаю гит, несмотря на то что вынужден был влизть в его кишки, делать форки того же LFS и в течении года в компании писал гит клиент. И, повторюсь, я гит не знаю, даже после того как ознакомился с ним куда как глубже рядового пользователя. А что говорить, о рядовых пользователях? 99% из них знают про гит еще меньше меня, и при этом вынуждены как-то им пользоваться.Гит предназначался для хранения сорсов и обмена патчами по почте, и все это из консоли. Из-за того что он стал корпоративным стандартом - он заполонил буквально всё.
Никакая новая система контроля версий не потеснит гит до тех пор, пока не появится какой-то совершенно новый подход к версионности(ну или мощная корпорация, которая будет продвигать другой VCS). Так что придется жить с гитом. Вероятность появления популярной альтернативы ИМХО мала. Надежда только на то, что у кого-то хватит смелости пофичекатить гит, выкинуть из него легаси, которое не нужно большинству и превратит его наконец в цельный продукт. Но вероятность этого крайне мала.atshaman
11.04.2024 13:44+3Нееее... все не так страшно - гит уже ушел куда-то на уровень "инфраструктуры" и большинство людей просто не имеют с ним дела. Ну, примерно как с TCP\IP - он абсолютно ужасен, мало кто понимает, как ЭТО работает в реальной жизни со всей её разнообразием - но всем примерно "пофиг" и нужды лезть в какой-нибудь wireshark последние лет 20 у абсолютного большинства людей не возникает. Так и с git'ом - ну да, страшно. Ну да, ужас - но если аккуратно тыкать его трехметровой палкой через прослойки клиентов-ide-web-service'ов и работать условно не с "git'ом" а с "github'ом" - то оно и ничотак, жить можно. Ну да, периодически конечно случаются... удивительности вида "дактожзналото?!!!" - но чем дальше, тем меньше с т.з. обычных людей.
Aquahawk
11.04.2024 13:44+5ровно противоположный экспириенс, каждый тул пытается изобрести какие-то свои абстракции и подходы вместо нативных для гита. Стоит один раз прочитать git book и гит станет прозрачен как слеза, и так со всем системами контроля версий, я профессионально лет по 5 пользовался svn, hg, git и на всех них можно нормально жить только из консоли, всё работает чётко и без ошибок, ты точно понимаешь что делаешь, отдельно могу признавать только вьюверы которые дерево красивое нарисуют, не более того.
AllexIn
11.04.2024 13:44Совершенно с вами согласен. Именно поэтмоу мы и сами начали делать свой гит тул, потому что абстракции других тулов нас не устроили.
Про git book вы хорошо сказали, только людям работать надо, а не достаточно сложный технический материал усваивать. Поэтому проще предложить тул, чем условному художнику сказать "да ты просто прочитай git book".Aquahawk
11.04.2024 13:44а художнику и не нужен гит бук, он не делает октопус мерджи и прочие непотребства. Но, имхо, любой senior просто обязан прочитать штатную документацию используемого инструмента контроля версий и качественно освоить инструмент.
Aquahawk
11.04.2024 13:44+2а почему вы решили что вам нужен LFS? Гит прекрасно хранит бинари. LFS нужен если вы постоянно меняете большие бинари и они дофига весят в клоне. Но если вам нужна распределённость и вы готов за неё платить, то пожалуйста, всё будет работать. Я знаю о чём говорю, у меня есть гит репо с почти миллионом бинарей, десятью тысячами коммитов и весом в несколько десятков гигабайт, и всё работает просто отлично. На LFS эта штука бы еле еле шевелилиась, т.к. LFS чудовищно плохо работает с большим(10k и больше) количеством файлов
AllexIn
11.04.2024 13:44Геймдев. Большие бинари постоянно меняются. Ну и локи, конечно.
Aquahawk
11.04.2024 13:44Так, и у меня геймдев, так что коллеги. Если говорить про исходники с которыми работают художники то они у нас частично всё ещё в svn сидят, там есть репы по теру, sparse checkout и всякое такое. Вы говорите что хотите распределённости, так она есть, и для больших бинарей она реально будет стоить места. Хотя git pack вроде учился более эффективно работать с бинарями если меняется только часть, хотя новость не могу найти сходу. Любая распределённая система, в который вы захотите хранить много больших часто меняющихся бинарей будет жрать место. В играх с огромным количеством контента мы прямо дизайнили архитектуру игры и её деплоя так, чтобы было удобно это всё поддерживать, быстро релизить, и не лочить ресурсы для работы(чтобы несколько человек не пересекались на одном файле)
AllexIn
11.04.2024 13:44+1Я не хочу распределенности. Я хочу консистентности: чтобы инструмент единообразно работал, если децентрализованная система, то децентрализованная. Если с единым сервером, то с единым сервером. А не так, что над каждой командой надо думать: а как она отработает в данном случае?
Смотришь в документацию: "команда достает из коммита содержимое файла", выполняешь её и получаешь какой-то мусор(по факту LFS pointer). То есть команда не соответсвует документации. Вернее формально соответствует: в гите лежит поинтер, получил поинтер. Но это не ожидаемое поведение.
lFS либо часть гита, либо не часть гита.... А по факту это костыль, которые болтается вместе с гитом, аффектит поведение гита, документирован отдельно...
Извините что я так много про LFS, просто это самый яркий пример костылей в гите.
slonopotamus
11.04.2024 13:44Я знаю о чём говорю, у меня есть гит репо с почти миллионом бинарей, десятью тысячами коммитов и весом в несколько десятков гигабайт, и всё работает просто отлично.
На масштабах десятков гигабайт действительно работает безо всяких lfs. Но вот на масштабах в единицы терабайт уже нет.
Aquahawk
11.04.2024 13:44ну так логично, если вы хотите положить туда терабайты и не хотите держать их в каждом клоне, то вариантов то больше нет, их же надо где-то хранить, тогда выбирается сервер для хранения и мы получаем так или иначе что-то типа LFS. Я не понимаю чего можно ожидать, вы или храните всё в каждом клоне(кстати, на сервере у нас у разных клонов гит кеш общий, это сильно экономит место), либо храните "где-то там" и тогда нет никакой распределённости.
Вот вам LFS. У нас как бы децентрализованная система, но без центрального сервера она работать не будет.
вот я этого понять не могу. Да, или децентрализованная но жирная, или централизованная, тогда история больших файлов только на сервере и за её хранение расплачивается только сервер, другого не дано.
slonopotamus
11.04.2024 13:44Я в принципе готов держать терабайты в каждом клоне. Но вот операции типа git gc - это очень больно. Или например отсутствие докачки в git pull. Или то что всё утыкается в проц из-за того что git до сих пор использует gzip.
Aquahawk
11.04.2024 13:44да, тут со всем соглашусь, особенно zstd бы не помешал, там модно всякое творить, типа сжатия с переиспользованием прошлого архива как словаря, в случае с гитом это могло бы дать значительный буст https://developer.chrome.com/blog/shared-dictionary-compression
Aquahawk
11.04.2024 13:44я тут подумал, было бы гораздо удобнее работать с большими репами если бы каждый живой чекаут сам бы в фоне подтягивал новые файлы и раздавал как торрент, тогда и проблем с закачкой быть не должно, и с нагрузкой на сервер
event1
11.04.2024 13:44Самый яркий(но не единственный) пример - LFS:
LFS — это плагин. Не нравится — не пользуйтесь. Я вот не пользуюсь. Пара гигов истории тарболов просто лежат в репе
Вот вам LFS. У нас как бы децентрализованная система, но без центрального сервера она работать не будетДецентрализованность системы важна для распределённой разработки. Громадное большинство разработчиков заняты в централизованной разработке и не нуждаются в децентрализации
Но есть нюанс, я идиот и не знаю гит, несмотря на то что вынужден был влизть в его кишки
Простите за прямоту, но тут нечем гордиться. Если отбросить свистоперделки, то гит очень прост. База данных на файлах из трёх видов объектов: блобов, деревьев и коммитов соединённых известным образом.
AllexIn
11.04.2024 13:44А я и не горжусь.
Я указываю на то, что если сеньор в компании занимающийся гит клиентом всё еще много чего не знает про гит, то ожидать адекватных знаний от рядовых сотрудников - сущий бред.
vvbob
11.04.2024 13:44Принцип парето работает, поэтому гит так популярен. 80% фич освоить способен практически любой, и этого более чем достаточно для эффективной работы, а обгадить можно все что угодно, не нравится гит - предложите варианты лучше, возможно за вами народ потянется и в конечном итоге ваш вариант уделает его.
excoder
11.04.2024 13:44На мой взгляд, стыдно в 2024 знать Гит ТАК глубоко. Это будет означать, что профессионал занимается НЕ ТЕМ.
excoder
11.04.2024 13:44Я считаю, что гит задумывался Франкенштейном. Торвальдс – чувак с проблемами психики и контролем гнева. Он просто хотел создать такого Франкенштейна, и чтобы все на него подсели. Он выбрал правильную аудиторию – профессионалов-идеалистов, ценящих ненужную инженерную сложность. Он не прогадал.
vvbob
11.04.2024 13:44+1Довелось еще поработать на проекте без гита или хотя-бы svn. Впрочем, там была какая-то система контроля версий, не знаю самописная или какая-то сторонняя. Был веб интерфейс с файлами проекта. Если тебе надо было поработать с одним из них, ты скачивал его с флажком "заблокировать", и до тех пор пока ты не заливал исправленную версию, никто не мог его заблокировать (скачать можно было).
Обычно качали весь проект на свой комп, дорабатывали или фиксили баги, потом все эти исправления пофайлово заливались в репозиторий.. Думаю не стоит долго рассказывать насколько это было неудобно и сколько разных неприятных инцидентов вызывало, но ничего лучшего у нас не было.
unreal_undead2
11.04.2024 13:44ты скачивал его с флажком "заблокировать", и до тех пор пока ты не заливал исправленную версию, никто не мог его заблокировать
В Visual SourceSafe такой же подход, в конце 90x-начале 2000х с ним работали.
vvbob
11.04.2024 13:44Да, спасало только то, что у нас народа не так много над проектом работало, и если какой-то файл надолго в блоке зависал, то можно было просто подойти к автору блокировки и попросить ее снять..
unreal_undead2
11.04.2024 13:44просто подойти к автору блокировки
А он вдруг в отпуске ) Так то да, тоже был маленький проект человек из десяти и сидели рядом.
vvbob
11.04.2024 13:44Возможно там как-то мог админ системы ее снять. Но ситуация когда кто-то забывал снять блок и уходил на обед или в отгул, встречалась регулярно. Но тогда как-то к тому что кто-то день пинал балду вместо работы из-за заблокированного репозитория, было попроще отношение :)
unreal_undead2
11.04.2024 13:44+1В VSS мы как то руками научились снимать ручной правкой файлов базы на шаре. Но в любом случае CVS с возможностью одновременной правки (хотя и ценой возможных кофликтов) был гораздо приятнее.
GBR-613
11.04.2024 13:44+1Я работал с примерно десятком таких систем. Git - самый сложный из них и запутанный. Для новичка труднее всего освоить и работать так, чтобы не запутаться.
Как не парадоксально, я думаю, что это один из секретов его популярности. Кто потратил кучу сил и времени на его освоение, тому уже не хочется осваивать ничего больше чтобы работа не пропала зря.
И да, 99% человечества распределенная система не нужна. Всегда есть какой-то master repository, из которого строятся версии для пользователей, и все работают напрямую с ним. Иначе кому-то придётся делать merge на чужие изменения, что весьма неприятно.
Aquahawk
как мне нравятся прогнозы вида: история закончилась сегодня, дальше будет как сегодня.
Drox
640кб хватит всем!