>[оверквотинг удален]
>>>> в OpenBSD, merge и branch как бы и не нужны.
>>> Все может быть.  Но обычно они в есть гайде для разработчиков
>>> на всяких гитхабах.
>> А причём тут гитхабы?
> Притом, что им merge и branch - во как нужны.
>> Merge между mainline и прочими ядрами — это уже не
>> моя головная боль, или я ошибаюсь?
> Не ошибаетесь, пока кто-то не пришел в mainline с рефакторингом или еще
> как поковырялся в той части,
> что затрагивают ваши изменения.

Во-о-от. То есть, ещё раз, «продвинутые» средства управлениями ветками нужны для мейнтейнеров, а не для, скажем так, «одноразовых» источников патчей.

Понятно, что если я добавляю какую-то подсистему, например, то дальше мне её, видимо, и поддерживать.

>> Во-о-от. То есть, ещё раз, «продвинутые» средства управлениями ветками нужны
>> для мейнтейнеров, а не для, скажем так, «одноразовых» источников патчей.
> Да нет же.  Пока ваш одноразовый патч отрецензируют - придут другие
> очумелые ручки и модифицируют часть кода, что вы трогали.  Потому
> периодический мерж, а то и git rebase.  На вашей стороне
> - мейнтейнеры же не нанимались фиксить конфликты в вашем патче.

rebase в не-DVCS как бы отсутствует по определению... ;)

> Ну как бы речь и шла о git.

Речь изначально шла о patches are welcome. Чтобы подготовить (или обновить) патч для OpenBSD достаточно cvs diff — ничем не отличающегося по сути от git diff, hg diff и прочих.

> Таки нужны "продвинутые средства управления ветками" (тм) кому-то кроме мейнтейнеров или
> запишем всех GSoC студентов на гитхабчике сразу в мейнтейнеры?)

Открою страшный секрет: ряд разработчиков OpenBSD использует в работе, в том числе, и git, ведя локальную разработку. На Github есть даже зеркало исходников OpenBSD. Но центральный репозиторий остаётся на CVS, по ряду причин, как то:

* наличие большого количества правок напрямую в репозитории, особенно в старых коммитах (1990-е) ,приводящих к неточностям при миграции.
* в случае повреждения репозитория, починить его можно ручками ­— формат RCS куда удобнее в этом плане, чем бинарные форматы (почти?) всех остальных современных VCS.
* философия централизованного репозитория больше мотивирует не затягивать с коммитами.
* отсутствие желающих реально решать проблемы, связанные с миграцией — это обычному разработчику просто поменять «cvs» на что-то ещё, а Тео и ответственным за отдельные архитектуры и сборку пакетов — переписывать инструментарий, причём так, чтобы у остальных ничего не ломалось.

Я сейчас по разным поводам пользуюсь и CVS, и Subversion, и Git, и Mercurial — и могу точно сказать, что CVS далеко не так плох, как это может казаться. Но таки да — это когда к нему прилагаются cvsutils, cvsync и anoncvs.

>> Впрочем, вон FreeBDSM - на SVN.
> Нет. TL;DR:
>> get the FreeBSD source code using your favorite version control system:
>> git clone git://github.com/freebsd/freebsd.git src
>> svn checkout svn://svn.freebsd.org/base/head src

Это зеркала, они вообще не в счёт: в зеркало закоммитить нельзя. Сам репозиторий — по-прежнему, Subversion, и workflow для внесения изменений определяется именно там.

>>> Ну как бы речь и шла о git.
>> Речь изначально шла о patches are welcome. Чтобы подготовить (или обновить) патч
>> для OpenBSD достаточно cvs diff — ничем не отличающегося по сути
>> от git diff, hg diff и прочих.
> Ну, может вам везет)  В других проектах - diff'а категорически будет
> не хватать, по
> изложенным выше причинам.

Я пока что натыкался на проекты с замороченным порядком внесения изменений, с отдельными ветками, которые сначала вносятся в staging, а оттуда в основную ветку (и так далее) всего пару раз, да. Кажется, это были CMake и Qt...

>>> Таки нужны "продвинутые средства управления ветками" (тм) кому-то кроме мейнтейнеров или
>>> запишем всех GSoC студентов на гитхабчике сразу в мейнтейнеры?)
>> Открою страшный секрет: ряд разработчиков OpenBSD использует в работе, в том числе,
>> и git, ведя локальную разработку.
> Пожалуй и я спалюсь: вообще-то я немножко ерничал, указывая на cvs проекта.
>  Но таких как-бы сильно немного, учитывая что cvs скорее мертв,
> чем хоть как-то жив.  Впрочем, вон FreeBDSM - на SVN.

:)

>>  * наличие большого количества правок напрямую в репозитории, особенно в старых
>> коммитах (1990-е) ,приводящих к неточностям при миграции.
>>  * в случае повреждения репозитория, починить его можно ручками — формат
>> RCS куда удобнее в этом плане, чем бинарные форматы (почти?) всех
>> остальных современных VCS.
> Так-так.  Может ну его, такой удобный формат, а завести вместо журналируемую
> файловую систему и бесперебойник?)  Кстати, сама по себе CVS (где
> критические операции не атомарны) - вероятно и стала причиной большей части
> "правок напрямую", не?  И что куда хуже - станет снова.

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

>>  * философия централизованного репозитория больше мотивирует не затягивать с коммитами.
> А какая религия запрещает сделать централизованный репозиторий в git?

Наверное, я не совсем корректно выразился. Попробую переформулировать: концепция централизованной VCS способствует тому, что разработчик не «сидит на патчах», а старается их внедрять как можно быстрее, чтобы потом меньше надо было сводить после update.

Хороший пример, кстати — KDE: в то время как репозитории с кодом на Git, инфраструктура i18n/l10n использует по-прежнему Subversion, это было осознанное решение данных людей — им действительно так удобнее.

На моей текущей работе, например, я тоже вижу, что внедрение DVCS, скорее, ухудшит workflow, поэтому даже не пытаюсь их продвигать. Специфика работы без интернета, так сказать.

>>  * отсутствие желающих реально решать проблемы, связанные с миграцией
> Ну, это может только приемуществами от использования чего-то более нормального.  Помимо
> упомянутого выше - наверно еще производительность при некоторых операциях.
> Ах, да.   Bus factor еще.  CVS-гуру теперь надо разводить
> специально.

Справедливости ради, разобраться в нутре CVS куда проще, чем в нутре любой другой популярной VCS. Так что выращивание не является такой серьёзной проблемой. :)

>> Причины были разные, в том числе — кривые руки первых коммитеров. Просто
>> я не случайно указал даты: гитами и прочими жидкими металлами тогда и не пахло.
> Во всяком случае, думаю что это, в принципе, решаемо.  OpenBSD -
> большой и старый проект,
> использующий CVS, но вряд-ли он был таким ранее.

Ну как сказать. Проект OpenBSD, например, был первым проектом ОС, который вообще сделал публично доступный репозиторий (а не просто релизные архивы выкладывал), так что история в этом плане богатая.

>[оверквотинг удален]
>> после update.
> Хотелки уменьшить количество конфликтов - параллельны концепции централизованной
> VCS.  (A propos, на мой вкус и цвет - в git/hg
> это делать куда удобнее).  Дело в возможностях
> рецензирования кода и т.п.
>> Хороший пример, кстати — KDE: в то время как репозитории с кодом
>> на Git, инфраструктура i18n/l10n использует по-прежнему Subversion, это было осознанное
>> решение данных людей — им действительно так удобнее.
> Это странно, т.к. с логической точки зрения - VCS является частным случаем
> DVCS.  Т.е. при желании ничто не мешает организовать работу идентичным образом.

Конечно, реализовать можно. Но частные случаи как раз потому и интересны, что усилий для этого там прилагать надо меньше.

>> Конечно, реализовать можно. Но частные случаи как раз потому и интересны, что
>> усилий для этого там прилагать надо меньше.
> Логично.  А потому для программироваиия - только Notepad, ибо в этих
> ваших емаксах даже кейбиндинги гвоздями не прибиты.

Не-не-не.

Смотрите: можно взять «универсальную» отвёртку, с насадками на все случаи жизни: шлиц, шестигранник, звёздочка, все размеры... И, в общем-то, не знать горя.

Но если 90% времени вы работаете с одной и той же насадкой, то удобнее оказывается иметь под это дело отдельную отвёртку. Скорее всего, она будет тоньше, или легче, или ещё как-то более удобна. Да, места на столе (в мозгу) для работы с двумя отвёртками (VCS) требуется чуть больше, но это окупается экономией времени на основных операциях.

> Тогда git (да и hg тем более) - как раз отвертка валшебная.
>  Если надо тоньше - сделаем тоньше, если еще как-то удобнее
> сделать - будет.  Это в cvs насадка навсегда одна и
> еще стержень кривой.

Да можно, можно всё это в случае с Git, кто ж спорит. Только вы же сами говорите — «если надо — сделаем». То есть — дорабатывать надо. Самый очевидный пример — ниже.

Как это делают в CVS:

cvs up
vi ...
cvs ci

Как это делают в Git:

git pull
git up
vi ...
git ci ...
git push

Можно избавиться от отдельного «git up», поправив конфиг. Можно избавиться от отдельного «git push», добавив commit hook или какую-то ещё свою обёртку. Но и то, и другое — дополнительные усилия, которые не требуются в случае CVS. Никакого волшебства тут нет, только потраченные (или сэкономленные) разработчиком время и усилия.

Если уж за что и хвалить Git из коробки, так это, например, за «add -p» — в случае с CVS я (и не только я) как раз в свою очередь писал обёртку под это дело.

> Ну в самом деле, аналогичная cvs модель работы - никаких специальных усилий
> от мейнтейнера не требует.  Наверное, можно даже сказать что львиная
> доля пользователей пользуют именно ее.

Правильно, а почему они её используют? — патамушта Linux и GitHub. Если первой VCS, с которой знакомится эта самая львиная доля пользователей, становится Git, то результат как бы предсказуем (я не в претензии, просто констатирую положение дел). Но масштаб проектов и задачи в них от VCS в целом не меняются. И когда задачи в основном вида «поправить вот эту мелочь» и «добавить вот такую фичу на двести строчек», подойдёт любая VCS, вообще любая. При этом порог вхождения у CVS всё же чуточку меньше — да, в том числе из-за отсутствия каких-то фич, типа git index. Я понимаю, что в глазах многих людей сознательный отказ от фич выглядит, говоря литературным языком, ретроградством, но за ним стоит кое-что большее, чем лень и нежелание учиться. :)

>[оверквотинг удален]
>> cvs ci
>> git up
>> git ci ...
> Ой, страшно.  Страшно оригинально и нОво.  Ой, ой.
>> Можно избавиться от отдельного «git up», поправив конфиг. Можно избавиться от
>> отдельного «git push», добавив commit hook или какую-то ещё свою обёртку.
>> Но и то, и другое — дополнительные усилия, которые не требуются
>> в случае CVS. Никакого волшебства тут нет, только потраченные (или сэкономленные)
>> разработчиком время и усилия.
> Ты главное не перенапрягись, выдумывая команды git.

Переклинило. Rebase там, конечно же. Писал, пользуясь в этот момент Mercurial и Subversion, вот оно и. Прошу прощения.

>>> Тогда git (да и hg тем более) - как раз отвертка валшебная.
>>>  Если надо тоньше - сделаем тоньше, если еще как-то удобнее
>>> сделать - будет.  Это в cvs насадка навсегда одна и
>>> еще стержень кривой.
>> Да можно, можно всё это в случае с Git, кто ж спорит.
>> Только вы же сами говорите — «если надо — сделаем».
> Да не надо ничего дорабатывать, максимум - выучиться командам.

Тогда вы сами себе противоречите словами «если надо — сделаем».

>[оверквотинг удален]
>> git ci ...
>> git push
> Нет, это делают не так (начиная с того, что git up -
> это какой-то ваш алиас, вероятно.
> Делают проще:
> emacs ...
> git commit ..
> git push ...
> Если git push заругался на наличие в основном репе изменений, отсутствующих локально
> - делаем git pull --rebase и уже потом push.

Править исходники, не обновив их, обычно плохая идея — сводить больше и больнее придётся.

>> Можно избавиться от отдельного «git up», поправив конфиг.
> Из коробки избавились:
> $ git up --help
> git: 'up' is not a git command. See 'git --help'.
> ...
> $ git update
> git: 'update' is not a git command. See 'git --help'.
> ...

(дублирую написанное Митрофанову насчёт git up)
Переклинило. git rebase там, конечно же. Писал, пользуясь в этот момент Mercurial и Subversion, вот оно и.

>> Но и то, и другое — дополнительные усилия, которые не требуются
>> в случае CVS.
> Дополнительные усилия называются: чтение документации на уровне туториала.  Git все-таки
> не является копией CVS (аллилуия!), потому команды и их аргументы - несколько
> другие.

Угу, угу. Все дураки, один Git умный. Одна только загадочная логика, когда с помощью branch можно сделать угодно, кроме собственно переключения веток, чего стоит. Учить надо, да, но в итоге всё равно регулярно путаешься (как я выше) — если, конечно, не пользоваться одним только Git.

> Ну и, еще раз напоминаю: реалии мира таковы, что люди скорее будут
> вынуждены выяснять
> что такое cvs update.

Всё может быть. Только это произойдёт в первую очередь из-за новых проектов. А не из-за миграции старых.

>>> Ну в самом деле, аналогичная cvs модель работы - никаких специальных усилий
>>> от мейнтейнера не требует.  Наверное, можно даже сказать что львиная
>>> доля пользователей пользуют именно ее.
>> Правильно, а почему они её используют? — патамушта Linux и GitHub.
> Ну как бы было время, когда гитхаба - не было.  Зато
> CVS был давно.  Это, наверное, масоны устроили так, чтобы он
> на гитхабы с линуксами не попал?)

Да я же писал, что не в претензии. Причины понятны. Но не гитхабом единым живы программисты.

>> И когда задачи в основном вида
>> «поправить вот эту мелочь» и «добавить вот такую фичу на двести
>> строчек», подойдёт любая VCS, вообще любая.
> Я надеюсь, описанный сценарий - не для OpenBSD.

Не понял, что вы имели в виду. Что в OpenBSD не должно быть маленьких правок? Или что?

>> При этом порог вхождения у CVS всё же чуточку меньше — да, в том числе из-за
>> отсутствия каких-то фич, типа git index.
> Знать такие вещи - как правило и не требуется для рядового пользователя.
>  Это как если б
> я попросил вас рассказать что может поломать cvs update, если вдруг свет
> вырубят.

Не соглашусь. Пока не сел и спокойно не разобрался с git index (и в целом с Git) в своё время, постоянно матерился на непонятное поведение при add и commit.

>> Я понимаю, что в глазах
>> многих людей сознательный отказ от фич выглядит, говоря литературным языком, ретроградством,
>> но за ним стоит кое-что большее, чем лень и нежелание учиться.  :)
> Кстати, а в OpenBSD как изменения тестируются?  Полазал по сайту, как-то
> там глубоко ссылки на ваш CI сервис закопаны.

Кто хочет сам прогнать тесты — идёт и делает make regress.

На регулярной же основе bluhm@ регулярно прогоняет это дело на отдельном кластере, результаты доступны прогонов доступны разработчикам для анализа в удобном виде.

>>> Да не надо ничего дорабатывать, максимум - выучиться командам.
>> Тогда вы сами себе противоречите словами «если надо — сделаем».
> Нет, команды _уже_ сделаны.  Максимум - их надо выучить.  И,
> кстати, современный мир таков, что учить их
> даже не надо - разработчики уже рождаются с встроенными навыками работы в
> git.

:)) Видел я таких разработчиков... «Пушать» на GitHub они умеют, да. А вот о том, что можно обходиться и без GitHub знают уже далеко не все.

>> Править исходники, не обновив их, обычно плохая идея — сводить больше и
>> больнее придётся.
> Если конфликтов нет - в чем проблема?  Описанный workflow вообще кривой
> - но это
> именно то, что вы предложили для cvs.

В том, что они обычно есть. Может, это только мой личный опыт, конечно.

Workflow, конечно, с DVCS куда богаче вариантами. Но «больше возможностей» — опять же, не всегда означает «лучше». На какой-нибудь АЭС регламент очень чётко требует выполнять даже самые безопасные, казалось бы, операции, что кстати, многих бесит. Зачем так делается? — Да затем, чтобы в случае чего было известно, кто как себя будет вести и что будет делать. То есть при всём богатстве вариантов workflow, в любом сколько-то серьёзном проекте он фиксирован. И если этот workflow ложится на централизованную VCS, то... почему бы и нет?

>> Одна только загадочная логика, когда
>> с помощью branch можно сделать угодно, кроме собственно переключения веток, чего стоит.
> Так оно не для переключения веток.  Оно для управления ветками.  
> Непривычно для
> изнасилованных cvs/svn - возможно.  Но нелогично - нет, конечно.

К списку CVS и Subversion добавьте ещё все остальные VCS, кроме Гитля Д'Артаньяна.

>>>> И когда задачи в основном вида
>>>> «поправить вот эту мелочь» и «добавить вот такую фичу на двести
>>>> строчек», подойдёт любая VCS, вообще любая.
>>> Я надеюсь, описанный сценарий - не для OpenBSD.
>> Не понял, что вы имели в виду. Что в OpenBSD не должно
>> быть маленьких правок? Или что?
> Что в OpenBSD дело не заканчивается маленькими правками.

Не заканчивается, разумеется. И мы возвращаемся к исходной диспозиции: кто-то использует cvsync, кто-то — cvs2gitdump... И это ровно то, о чём шла речь выше: доработки для тех, кто хочет использовать DVCS.

Ещё раз: я не говорю, то Git — это плохо. И точно знаю, что ряд разработчиков OpenBSD с удовольствием бы на него переехали (лично я вообще предпочитаю Mercurial, к слову). Но цена переезда довольно высока, и как минимум Тео её (пока) не хочет платить.

На этом и предлагаю закругляться, а то у нас уже сказка про белого бычка начинается. :)