Пал один из последних оплотов Mercurial (Hg)

У меня как-то был проект с git + submodules. Больше не хочу такого. Кто когда и куда должен двигать ревизии сабмодулей это огромный вопрос, тут есть 100500 способов накосячить.

В Qt, например, работают через super-репозиторий с этим submodules: https://code.qt.io/cgit/qt/qt5.git/tree/

Особо на Git они не жалуются, а объём кода в Qt лишь в два раза меньше Linux’ового (8.2М LOC vs 19.2M LOC).

P.S. В Android всего 15.5M LOC.

Google тоже написал свою VCS с блэкджеком и шлюхами. В итоге у них вмего один репозиторий и разработка только в одной ветке. (По крайней мере это то чем они хвастаются на публику). Мотивация: накладные расходы на управление ветками и множеством репозиториев растет очень сильно.

Qt Creator, IDE основанные на IntelliJ IDEA, Microsoft Visual Studio Community (тот что полный) – полёт нормальный, репы клонируются и правки отправляются по SSH, ключ с passphrase.

Всё же VSCode вроде редактор, а не IDE.

Они же будут кричать, что свн — это прошлый век, и продолжать качать каталоги с гитхапба через

Ну всё так и есть. Много сегодня хостингов, которые поддерживают SVN? Вот и ответ на твой вопрос.

Google тоже написал свою VCS с блэкджеком и шлюхами. В итоге у них вмего один репозиторий и разработка только в одной ветке. (По крайней мере это то чем они хвастаются на публику). Мотивация: накладные расходы на управление ветками и множеством репозиториев растет очень сильно.

Что-то как-то слабо верится, ибо наружу у их проектов с огромным количеством LOC торчит как раз куча Git-репозиториев с такой же кучей веткок, тегов и т.д:

https://gerrit.googlesource.com/

https://android.googlesource.com/

https://chromium.googlesource.com/chromium/src.git

Они даже собственную Web-морду для Git на Java запилили:

https://gerrit.googlesource.com/gitiles/

Согласен, что вызывает когнитивный диссонанс )

https://research.google/pubs/pub45424/

Ну либо гугл хитрит как всегда.

Не исключаю что opensource через гит контрибьютится, и в итоге только master синхронизируется.

Направленый ациклический граф ревизий. То что изменения сохраняются в виде ченджсета для всего репозитория сразу. И все отсюда вытекающее. Отсюда, например, сразу понятно что означает rebase - всего лишь изменение родительского узла данной ревизии на другрй

Всё, что ты написал, никак не поможет в реальной работе с Git, потому что ты объясняешь на русском, а git, его вывод, и документация написаны на китайском. По крайней мере, так мне казалось до тех пор, пока я не изучил китайский. Когда я делал rebase, то по ощущениям это было всё что угодно, только не «изменение родительского узла первой ревизии от общего предка моей ветки на последний узел целевой ветки» — как ты пишешь.

Мотивация: накладные расходы на управление ветками и множеством репозиториев растет очень сильно

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

Не исключаю что opensource через гит контрибьютится, и в итоге только master синхронизируется.

Но по куче активных веток в их репах этого и не скажешь. Скорее хитрит.

Зашёл в сорцы Gerrit, про которую слышал каждый разработчик. Вижу:

    master
    infra/config
    stable-2.10
    stable-2.11
    stable-2.12
    stable-2.13
    stable-2.14
    stable-2.15
    stable-2.16
    stable-2.4
    stable-2.5
    stable-2.6
    stable-2.7
    stable-2.8
    stable-2.9
    stable-3.0
    stable-3.1
    stable-3.2

https://gerrit.googlesource.com/gerrit/

Остапа понесло. Ветки - это инструмент. Rebase - инструмент. Как им пользоваться зависит от задачи и целей.

Hint: в DVCS master ветка каждого разработчика - отдельная ветка. Что считать за «эталон» - дело каждого. Я вот склонировал себе опенсорсную репу, слелал пару изменений и держу ее у нас на сервере. Иногда тащу аплейты с гитхаба.

Ну всё так и есть. Много сегодня хостингов, которые поддерживают SVN? Вот и ответ на твой вопрос

Ну так блин... миллионы мух не могут ошибаться. SVN поднять можно самому, отдельные хостеры всё еще хостят тройку SVN-Git-Hg, например, Helix (который Perforce продает). Можно с таким же успехом на VPS поднять SVN свой, который будет поближе географически к пользователям. Так или иначе, в 2020 ведущие фирмы приходят к централизованным хранилищам, и Git там только лишнее звено, которое болтается под ногами..

Так или иначе, в 2020 ведущие фирмы приходят к централизованным хранилищам, и Git там только лишнее звено, которое болтается под ногами..

Но SVN и другим богом забытым CVS от этого не легче. Ведь эти компании делают надстройки и альтернативные реализации именно под Git и другие DCVS.

Что-то как-то слабо верится, ибо наружу у их проектов с огромным количеством LOC торчит как раз куча Git-репозиториев с такой же кучей веткок

Да, они используют Git для хрома и андроида.

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

🤦‍♂️🤦‍♂️🤦‍♂️

Да, они используют Git для хрома и андроида.

Я бы сказал – для всего Open Source что у них есть. Там ещё Gerrit и прочие 100500 проектов:

https://opensource.google/projects/explore/featured

А речь про монореп по ссылке invy шла видимо про их приватный говнокод.

Они этим гордятся. Вон даже книгу написали:

https://www.amazon.com/Software-Engineering-Google-Lessons-Programming/dp/1492082791

Общался с автором на «презентации».

Что-то как-то слабо верится, ибо наружу у их проектов с огромным количеством LOC торчит как раз куча Git-репозиториев с такой же кучей веткок, тегов и т.д:

Экспорт настроили. У Яндекса тоже на гитхабе куча репозиториев, однако внутри используется: https://habr.com/ru/company/yandex/blog/482926/

Но активные веточки в их Git-репозиториях всё-таки имеются, да и далеко не две-три штучки. Значит либо в своём монорепе они нарушают своё же утверждение «накладные расходы на управление ветками … растут очень сильно», либо для Open Source они действительно используют лишь Git.

Ты себе противоречишь. Если тебе только коммит/пуш/пул то git gui более чем подходит по всем параметрам. В довесок merge tool по вкусу. Всё.

Я бы сказал – для всего Open Source что у них есть. Там ещё Gerrit и прочие 100500 проектов:
https://opensource.google/projects/explore/featured
А речь про монореп по ссылке invy шла видимо про их приватный говнокод

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

Если тебе только коммит/пуш/пул то git gui более чем подходит по всем параметрам. В довесок merge tool по вкусу. Всё

В репе появляется большой бинарный файл аля «тестовая БД», и на этом подхождение по всем параметрам заканчивается. По этой причине гугл так долго сидел на Perforce.

которое определенно вынесено из какого-то приватного репозитория.

Акела промахнулся!

https://github.com/googleforgames/agones

Это говно активно разрабатывается на GitHub: https://github.com/googleforgames/agones/pulls?q=is%3Apr+is%3Aclosed, принимаются PRs, рассматриваются Issue, ко всему ставятся няшные GitHub-меточки. Кроме того у проекта целых 44 ветки.

Это говно активно разрабатывается на GitHub: https://github.com/googleforgames/agones/pulls?q=is:pr is:closed, принимаются PRs, рассматриваются Issue, ко всему ставятся няшные GitHub-меточки. Кроме того у проекта целых 44 ветки

Ну ты смотрел историю? Я ее всю пролистал. Это один большой стартовый комит, потом какое-то время работа велась на merge request-ах, потом и вовсе линейно. Очень маловероятно, что сейчас у этого проекта есть второй репозиторий, но, тем не менее, этот проект на git был перенесен.

но, тем не менее, этот проект на git был перенесен.

Я сомневаюсь, что он есть в этом Google’овском «монорепе» и они тщательно всё синхрят с GitHub’ом где им шлют PRs и Issues.

Бинарным файлам в репе не место.

Бинарным файлам в репе не место

«Вам это не нужно было», ага. Картинки на сайтах ты, я так понимаю, хранишь отдельно в тарболах?

В общем - да. В репе - ссылка откуда его брать и как. Но есть еге git lfs.

В общем - да. В репе - ссылка откуда его брать и как. Но есть еге git lfs

Но лучше, конечно, сорцы тарболами хранить.

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

А stgit пробовал? Аналог mq, поудобнее чем stash будет.

Человеческий интерфейс вместо криптозаклинаний консоли гита.

Можно подробнее? Там какое-то GUI или Web-интерфейс по умолчанию? Или что понимается под «человеческим интерфейсом»?

А stgit пробовал? Аналог mq, поудобнее чем stash будет.

«StGit is written in pure Python with no third-party Python dependencies. StGit currently supports Python version 2.6, 2.7, 3.4, 3.5, 3.6, 3.7, and 3.8, although support for Python 2 will be dropped in a future release.
StGit interoperates closely with Git and does most of its work by running git commands.»

Там какое-то GUI или Web-интерфейс по умолчанию? Или что понимается под «человеческим интерфейсом»?

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

Я знаю, что это такое. :) Я просто сообщил, что для git есть очередь патчей с простым набором команд. Очень помогает в причесывании ветки. А то мучаешься со stash.

Еще был SVK, но он, похоже, чуток сдох.

Не похоже, а сдох еще с появлением git и mercurial. Но скоро к нему и ртуть подкопают. К сожалению, битва проиграна.

-SDL2

Главный разработчик SDL2 заявил, что они переезжают с Mercurial (Hg) и Bugzilla на Git и GitHub:

https://discourse.libsdl.org/t/sdl-moving-to-github/28700