Риски использования распределенных систем управления версиями

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

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

Встретилось вот еще пара интересных статей на эту тему:

Риски распределенного контроля версий
Контроль версий и «правило 80 процентов»

Вкратце: с централизованной системой, людей принуждают взаимодействовать и просматривать работу друг друга; с децентрализованной системой, поведение по умолчанию состоит в скрытом ветвлении проекта каждым разработчиком.

Необходимо будет прилагать специальные усилия для обмена кода и самоорганизации в некоторую командную структуру.

Да, я знаю, что DVCS может имитировать работу централизованной системы; но поведение по-умолчанию имеет значение.

А поведение по-умолчанию — «ветвить», а не сотрудничать!

Это поощряет людей забираться в пещеры и кодить там объемные доработки, а затем «сбрасывать» эти «кодовые бомбы» на своих товарищей, причем до момента «сброса» код не может быть кем-либо проверен.

Да, правильные практики возможны с DVCS, но они не поощряются, что заставляет меня беспокоиться о будущем разработки с открытым исходным кодом...

Про новую архитектуру Firebird - SuperClassic

Несколько раз с коллегами начинали разговоры о ней, и каждый раз удивлялись зачем она нужна. В качестве памятки кусочек обсуждения в fb-devel:

SuperServer:

• один процесс ОС на все соединения/базы
• общий кеш страниц для всех баз
• централизованный(central) менеджер блокировок
• блокировки работают на базы, а не соединения - т.е. все операции с базой выстраиваются в одну очередь.
• для версии <>
• не поддерживает многопроцессорность, т.к. ОС не может распаралелить один процесс по нескольким процессорам

Classic:

• отдельный процесс на каждое соединение с БД
• отдельный кеш страниц на каждое соединение
• внешний менеджер блокировок(в 2.5. он уже внутренний)
• хорошая поддержка многопроцессорности
  
• накладывает некоторые ограничения в следствие ресурсоемкости процессов, в сравнении с потоками

SuperClassic:

• один процесс на все соединения (в перспективе - отдельный процесс на каждую базу)
• используется пул потоков ОС для обработки запросов от соединений - т.о. каждое соединение работает в отдельном потоке управляемом ОС, а неактивные соединения не отъедают ресурсы потоков
• централизованный менеджер блокировок, который может обрабатывать как внутренние, так и внешние обращения(одна и таже база может быть доступна как посредством СУБД из процесса А, так и через FB Embeded из процессов B, C и т.д.)
• теоретически этот менеджер блокировок позволяет организовывать кластеризацию используя готовые распределенные движки блокировок
• кеш страниц на соединение
• хорошая поддержка многпроцессорности, т.к. потоки ОС легко распараллеливаются

В v3.0 планируются такие доработки:

• общий кеш страниц на уровне базы
• кеш подготовленных запросов
• общий кеш метаданных

Как итог - SuperClassic это промежуточный шаг(насколько я понял изначально родившийся в RedSoft) к следующей основной архитектуре FB, появившийся в следствии крупного рефакторинга внутренностей движка.

Пока для пользователей практический выигрыш лишь в экономии на процессах и, как следствие, чуть более быстрой синхронизации. Хотя если верить документации, то совокупный выигрыш - до 15-20% на TPC-С тестах в сравнении с классиком.

Подробнее можно посмотреть в Firebird 2.5 Release Notes

UPD: Презентация от Дмитрия Еманова - Firebird 2.5 Architecture