OberonCore

Под контролем изменений в составных документах я имею в виду систему заплаток и выявления изменений. В мире Unix принято пользоваться такими утилитами, как patch и diff.

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

F9 (Compare Texts).

И не злоупотреблять вариантами.

Стремится к схеме "один модуль - только один его вариант". Вариативность - в разные модули реализации.

И т.п.

Кстати, да.
Это, вместе с F9, по-моему, заметно нейтрализует пользу от SVN.

(Всё хочется найти убойный аргумент, чтобы не заморачиваться с этими дурами.)

С точки зрения утилит diff/patch текстовый файл состоит из последовательности строк, идущих в определённом порядке одна за другой. Помимо данного порядка строки между собой никак не связаны, то есть любую строку можно заменить на любую другую последовательность строк, в том числе пустую (естественно, замена эта совершается по воле пользователя). Утилита diff сравнивает два файла (ДО и ПОСЛЕ) и создаёт последовательность команд (ПАТЧ) по удалению и замене строк, выполнение которых переводит файл из состояния ДО в состояние ПОСЛЕ. Эту последовательность команд в автоматическом режиме умеет выполнять утилита patch.

В качестве примера ситуации, когда строки между собой связаны и автоматическая работа утилит невозможна, можно привести следующий формат: пусть в текстовом файле первая строка содержит общее количество строк в файле. Это нарушает требование взаимной независимости строк: удаление любой нижележащей строки должно автоматически приводить к изменению содержимого первой строки. В случае с odc-файлами вместо такой первой строки есть бинарный заголовок файла, в котором хранятся, в том числе, атрибуты текста. Например, если есть выделение жирным, то в заголовке записано что-то типа "символы с 15 по 29 выделить жирным". Соответственно, независимости нет: если добавить строку текста в начало, позиции должны сместиться.

Выхода я вижу три:
- создавать собственные утилиты diff/patch с собственным форматом командного файла;
- создать конвертеры, приводящие odc в некий текстовый формат без межстрочных зависимостей;
- отбрасывать форматирование и считать, что важен только сам текст (форматирование можно делать автоматическое при импорте в текстовую модель, но остаётся вопрос, что делать с командерами, складками и прочими вьюшками).

Для первого случая может быть интересной вот какая идея. Представить odc-документ не как статичное содержание, а как последовательность команд по его созданию. Команды такие реально уже есть, они используются в механизмах undo/redo. Интересно, что при этом откроется возможность сохранить файл, выйти из программы, затем через год открыть его и отменить последнее действие. Собственно, для этого-то и нужны системы контроля версий.

Просто сделать компонент по типу StdStamps, и к нему две команды - начать запись изменений и завершить запись, причём перед записью принудительно требовать краткое описание вносимых изменений.

Тут есть два момента:
1. Хранить изменения придётся внутри документа (ради простоты и гарантированной корректности пары документ-изменения), что со временем приведёт к его распуханию
2. Не очень понятно как обрабатывать вложенные документы, особенно текстовые

Насчёт сравнения текстов в составных документах хочу добавить, что на мой взгляд, нехорошо, что стиль и формат текста - неотъемлемая часть исходных текстов. Я бы предложил следущий вариант развития составного документа:

Первая часть
Собственно, голый текст. Безо всяких атрибутов текста и встроенных "вьюшек".

Вторая часть
Являются дополнительными элементами для исходного текста. Наподобие оформления.
Атрибуты и встроенные "вьюшки" текста.

Имея такой формат, можно оперировать над текстами, не вдаваясь в подробности оформления. Вообще, следует отделить исходные тексты от оформления. То ли выделить маркерами начала-конца исходного текста, а может и отделить в особый формат файла, потому как наряду с положительными свойствами составных документов, встречаются всяческие проблемы, нетипичные для простых текстовых файлов.

Мы практически не используем версионные фишки СВН-а. Т.е. всегда идёт только верхняя версия "из стопки".
Основное, в чём пока заменить нечем, - коллективная работа с хранилищем, страховка от одновременных изменений, и т.п.
Когда хранилищ за 20 штук по разным работам, то руками не наобновляешься с какой-нибудь сетевой папки. Одно дело дать утром одну команду update по всем хранилищам, а другое - руками откуда-то забирать и выяснять, что там кто сделал...

Плюс, конечно, как-то страхует сам факт наличия всей истории изменений. Пару раз было нужно откатывать на одно изменение назад.

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

Представляю общему вниманию черновой вариант технического описания (spec) программ для создания системы контроля изменений в составных документах Блэкбокса.
Первоначальной задачей считаю необходимым обсудить детали технического описания, а затем уже можно приступать к реализации.

Приветствуются любые конструктивные замечания.

Diff-patch.odc

Я бы сделал несколько иначе:

патч-файл состоит из блоков. Каждый блок имеет заголовок вида
[0] INTEGER - Тег блока. Просто метка, удостоверяющая что это действительно блок - примитивный контроль целостности
[4] INTEGER - Длина блока (или адрес следующего)
[8] INTEGER - тип блока
[12] ... - данные блока

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

Первым в файле должен быть блок специального типа "заголовок". Пока для заголовка видится три обязательных поля:
1. Хеш-сумма файла, к которому применим патч
2. Описание патча.
3. Дата-время патча.

Потом нужно учесть особенности составных документов, а именно - вложенные элементы.

1. Я также имел в виду заголовок со служебной информацией в начале файла, а не заголовок блока.
2. Что насчёт количества блоков в заголовке?
3. Подробнее, что такое тег-метка блока. Откуда его получают?
4. Пока не представляю каким образом можно объединять заплатки от разных файлов в один файл. Хотелось бы понять, как понимать "хранить их в самом целевом документе"? Пока лишь есть идея закодировать файл-заплатку с помощью StdCoder, чтобы можно было обмениваться "патчами" через веб.
5. Кроме всего, встроенные элементы тоже должны обрабатываться. Только вот задача определять разницу между старым и новым... Картинки, OLE-объекты, ... - всех их нужно уметь сравнивать. Тут, по ходу, надо смотреть описание ODC.

Я фактически предлагаю отказаться от файла и перейти к потоку блоков. Процедура применения патча будет работать именно с этим потоком, не важно откуда полученным. Прочитали блок "начало патча" - поехали. Количество блоков в заголовке - а зачем? Тогда уж просто иметь ещё блок типа "конец патча" с контрольной суммой оного.

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

Как объединять. В блоке "начало патча" кроме контрольной суммы указываем ещё и имя файла. Тогда diff сможет по списку файлов сформировать такой патч-файл:
[НАЧАЛО ПАТЧА (файл: file1.odc)]
[ВСТАВКА тут данные что и куда вставили]
[ИЗМЕНЕНИЕ тут данные что и как изменили]
[КОНЕЦ ПАТЧА]
[НАЧАЛО ПАТЧА (файл: dir\file2.odc)]
...
[КОНЕЦ ПАТЧА]
...

А утилита patch соответственно его применяет, вставая колом если не найдёт указанные файлы или их хеши не совпадут с ожидаемыми.

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

Тэг блока - да любая константа, подтверждающая что это - блок. Хоть 123. Чисто для контроля. В принципе не обязателен, конечно. Разве что для частичного восстановления битого патча (а вдруг?)

По поводу вложенных вьюшек есть вариант. Поскольку мы пишем патчер на ББ, то мы можем штатными средствами пройтись по всему дереву объектов в документе. И штатными же средствами опросить все их свойства. Пойду Дракон попытаю на предмет алгоритм нарисовать

Обновил спецификацию (см. тему Diff & Patch).

Может описывать заголовок просто как RECORD ... END. Имеют ли смысл эти [+4]?

Так, может, тогда и хранить encoded-файлы? Чистый ascii.

Ну их нафик, сложности все эти с патчами-версионностью...

Мысль оригинальная, да... Сама по себе.

Только не совсем ясно, с какого конца кому её приложить.

Нас проблема диффов-патчей как раз не волнует, нас устраивает обычное хранение ODC, используем функционал коллективного сетевого хранилища. Т.е. для нашего режима encoded ничего не даёт.

А тем, кому нужен дифф - возможно...

А. Не знал. Из общения с дипломником вышло впечатление, что там нужен чистый текст. Ну и ладно.

odc-diff никому бы не помешал. Хотя бы знающий стандартные вьюшки. Тов. Горячев знает, что говорит. В качестве примера предлагаю поглядеть его конвертер документов в юникод из "BlackBox Component Builder 1.6 Community Edition" (http://oberoncore.ru/projects/bb16ce). я был приятно удивлён, когда, забыв раскрыть все складки до преобразования, обнаружил внутри них юникод.

Пусть будет отдельным абзацем.

В качестве примера: html, xml.
Цель: иметь возможность произвести слияние (merge).
Ситуация, в которой требуется слияние: пользователь А и пользователь Б получили копию файла, оба его изменили и создали каждый свой патч.
Задача слияния: с помощью автоматической процедуры получить файл, содержащий изменения от обоих пользователей.
Пример на уровне файла. Упрощенно представим формат ODC в качестве текстового файла, в котором первая строка хранит информацию о форматировании, в нашем случае о выделении жирным имени процедуры:
Здесь имеется в виду, что слово Init должно быть выделено жирным, а именно - символы с 22 по 25 включительно, начиная от второй строки файла (символы нумеруются с нуля).

Предположим, пользователь А изменил имя переменной-получателя, заменив "o:Object" на "obj:Object".
Как видно, строка заголовка автоматически изменилась, чтобы отразить новое положение слова Init в тексте. Это и есть пример того, что я называю нелокальной зависимостью.

Пользователь Б, допустим, изменил имя типа с Object на Obj, а имя переменной не трогал.
Как видно, заголовок тоже автоматически изменился, чтобы отразить новое положение слова Init в тексте.

При попытке выполнить слияние получим следующую проблему:
Автоматике не ясно, что должно быть в заголовке. Один пользователь говорит, что там должно быть 24..27, другой - что 19..22, а на самом деле там должно быть третье значение: 23..26.

Решения два: либо автоматика должна обладать достаточными знаниями для того, чтобы вычислять новое значение (этим путём идёт Роман М. из Израиля), либо нелокальные зависимости надо превратить в локальные. Например, в XML это могло бы выглядеть так:


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