>>> Ну как бы речь и шла о 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. Так что выращивание не является такой серьёзной проблемой. :)
