аааа, ну это наша специфика- мы несколько версий одновременно поддерживаем

то есть то что обычно бекпортами зовут? есть самая новая версия и вам конкретные изменения из новой надо в старую сливать?

тогда вопрос выше касается тех случаев когда вам надо поддерживать одновременно несколько версий вашего продукта- то есть текущий 1.6, но нужен фикс с 1.4 и надо пронести его выше

ну можно и так, но мы обычно делаем фикс в саму младшею  и промерживаем наверх, елси возможно

вот терь начинаб догонять разногласия

Писать trunk based development очень долго.

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

Да и его реальное имя To Be Done, это исключительно моё мнение.

Народ, а подскажите чатик, где обсуждаются вопросы консенсуса (в контексте распределенных систем) - может кто знает?..

Вот пример задачи, которая меня интересует.

Консенсус скрытных экспериментаторов.

Два экспериментатора, Алиса и Боб, измеряют физическую величину t, пользуясь одним и тем же прибором, дающим погрешность измерения \Delta t, и, таким образом получая значения t_a и t_b. Они не сообщают результаты друг другу. Предложить алгоритм построения интервала, в котором находится реальное значение физической величины t\in[t_1, t_2]. Алгоритм должен исполняться Алисой и Бобом независимо и без коммуникации друг с другом, и при этом давать одинаковые значения t_1, t_2 у обоих экспериментаторов.

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

Или может даже кратного двойной погрешности - надо думать и пробовать, а мне некогда.

Это возможное решение, но при условиях:
* человек который это говорит, достаточно старый чтобы застать Clearcase , svn ,perforce.
* У вас в команде есть отдельный человек, который делает эти мерджы и больше ничем не занимается.  И постоянно мониторит разные бранчи. То есть он автоматом аплаит изменения, а если что то не так, зовет авторов. И постоянно отслеживает что изменения из младшей ветки, обязательно есть в старшей.

На сколько нибудь большом проекте (а у вас очень большой проект) поддержка несколько бранчей это ад. Поэтому и был придуман CD. Ну а не рабочие/неготовые фичи просто выключаются флагами.

У нас в мере/нортеле была поддержка двух бренчей на клиаркейсе. Брр.. Получалось я не мог нормально писать код и рефакторить, ибо это надо бэкпортить на разные бренчи. В результате говнокодность резко возрастала 😞
Основным камнем преткновения была база данных. Которая по сути была бинарным конфигом с перекрестными ссылками. Добавить байт в неё было не возможно. Для этого надо было фризить все бранчи на пару месяцев. Приходилось искать не используемые биты и туда распихивать нужную информацию..

Ну так-то да. Правда, в данной постановке решения вообще нет (можно строго доказать). Мне интересно найти какое-нибудь исследование в данном направлении

А причем тут консенсус? Можно узнать зачем понадобилась эта задача на практике?
Вообще, эта задача из метрологии. наверное есть учебник. Я студентом на первом курсе немного подрабатывал в этой стезе (расчет потребленной воды / тепла, с помощью манометров и дифузора),  но мне на пальцах объясняли как должен действовать метролог, ну и как считать правильно.

Она не совсем из метрологии, так контроллеры дублированные работают. Вроде как в космосе такое используется

Это не только измерений касается, но и расчётов

Вот этим как раз и занимается метрология. Измерения и расчет погрешности. Меня в универе только погрешности учили считать на вычислительной математике, а вот метрология это немного шире. ТАм и тервер, и распределение ошибки и т.д..

Про такую задачу я слышал чутка в другом разрезе: ручной ввод данных. Когда, скажем, надо налоговую декларацию на овермного страниц ввести, вводят рандомно выбранные двое, если же их данные различаются, то даётся на ввод третьему.