OberonCore

Нафик-нафик. Не нужны такие автоматизмы.

Это задача из мира, где программа -- один чудовищный файл.
В модульной системе -- пусть А и Б договариваются.
И пусть модули проектируют хорошенько.

Такое моё пока мнение

Да, я тоже никогда бы не стал использовать автоматику.

я бы от более "умного" F9 не отказался...

Простите, я видимо пропустил. Речь идёт о создании патчера-диффера не средствами ББ? Зачем!?
При работе с ББ никакого же бинарного заголовка нет - чистый поток символов с атрибутами. И все вьюшки при этом - тоже символы, только особые. И даже формат odc знать не надо

Да нет, это я скорее для общего прояснения ситуации рассказал. Чтобы было понятно, для чего системы контроля версий вообще нужны и как устроены. Заодно и свою степень понимания проверяю.
Вижу, что настал черёд рассказать про feature branches, но пока что вдохновение не посетило. Илья, вы используете feature branches или множите копии модулей?

Патчер-диффер, конечно, надо будет создавать средствами ББ, особенно если идти по пути, выбранном Романом.

Очень редко, когда надо увести "набок" рейд экспериментальный, которые сильно трогает подсистему.

Касательно модулей - у нас строгое правило: только одна версия модуля. Т.е. он всегда один, имеет линейную историю. Вариативность - отдельными подключаемыми модулями.

Выделил техническую сторону вопроса в тему Diff & Patch.

По мотивам "Diff & Path".
Если предположить, что "один человек - один модуль", тогда задачу можно перенести на уровень подсистемы, а это уже намного проще. Т.е. мне кажется, важнее отслеживать (и протоколировать и откатывать) изменения на уровне подсистемы. Или в "Diff & Path" это и имеется ввиду?

Задачу контроля версий над множеством документов можно и нужно разбивать на задачи определения изменений в каждом документе. Таким образом, проще решить сначала задачу для одного документа, а затем уже комплексно решать задачу для иерархии документов (если речь идёт об аналоге SVN/git).

В теме "Diff & Patch" обсуждается способ определения изменений в версии одного документа, а также инструмента для накладывания заплатки (патча) на исходный документ.

Вот!

Появляется истинная логика задачи контроля версий для настоящей модульной системы.

Какая-то такая вот простая схема:

Если интерфейс модуля не меняется, то версии протоколируются (пусть датами).
Если меняется интерфейс -- то архивируется/протоколируется вся подсистема.

То есть:
последовательность версий подсистемы (версий структуры межмодульных интерфейсов),
в каждой версии -- хвост последовательностей версий отдельных модулей до предыдущей архивации подсистемы.

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

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

И делать это всё по-возможности прозрачно для работающего программера.

Я бы с этого начал.

Инструментарий сравнения текстов -- он может зависеть от принятой схемы работы с подсистемами?