OberonCore
https://forum.oberoncore.ru/

Контроль изменений в составных документах
https://forum.oberoncore.ru/viewtopic.php?f=1&t=2323		 Страница 1 из 2
Автор:  Роман М. [ Суббота, 06 Февраль, 2010 22:21 ]
Заголовок сообщения:  Контроль изменений в составных документах
Под контролем изменений в составных документах я имею в виду систему заплаток и выявления изменений. В мире Unix принято пользоваться такими утилитами, как patch и diff.

Каким образом можно автоматизировать изменения в исходных текстах программ составных документов?
Автор:  Илья Ермаков [ Суббота, 06 Февраль, 2010 22:26 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
F9 (Compare Texts).

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

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

И т.п.
Автор:  Info21 [ Воскресенье, 07 Февраль, 2010 07:26 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Илья Ермаков писал(а):
Вариативность - в разные модули реализации.
Кстати, да.
Это, вместе с F9, по-моему, заметно нейтрализует пользу от SVN.

(Всё хочется найти убойный аргумент, чтобы не заморачиваться с этими дурами.)
Автор:  Александр Ильин [ Воскресенье, 07 Февраль, 2010 09:01 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Роман М. писал(а):
Каким образом можно автоматизировать изменения в исходных текстах программ составных документов?
С точки зрения утилит diff/patch текстовый файл состоит из последовательности строк, идущих в определённом порядке одна за другой. Помимо данного порядка строки между собой никак не связаны, то есть любую строку можно заменить на любую другую последовательность строк, в том числе пустую (естественно, замена эта совершается по воле пользователя). Утилита diff сравнивает два файла (ДО и ПОСЛЕ) и создаёт последовательность команд (ПАТЧ) по удалению и замене строк, выполнение которых переводит файл из состояния ДО в состояние ПОСЛЕ. Эту последовательность команд в автоматическом режиме умеет выполнять утилита patch.

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

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

Для первого случая может быть интересной вот какая идея. Представить odc-документ не как статичное содержание, а как последовательность команд по его созданию. Команды такие реально уже есть, они используются в механизмах undo/redo. Интересно, что при этом откроется возможность сохранить файл, выйти из программы, затем через год открыть его и отменить последнее действие. Собственно, для этого-то и нужны системы контроля версий.
Автор:  Иван Горячев [ Воскресенье, 07 Февраль, 2010 10:02 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Александр Ильин писал(а):
Выхода я вижу три:
- создавать собственные утилиты diff/patch с собственным форматом командного файла;
...
Для первого случая может быть интересной вот какая идея. Представить odc-документ не как статичное содержание, а как последовательность команд по его созданию. Команды такие реально уже есть, они используются в механизмах undo/redo. Интересно, что при этом откроется возможность сохранить файл, выйти из программы, затем через год открыть его и отменить последнее действие. Собственно, для этого-то и нужны системы контроля версий.

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

Тут есть два момента:
1. Хранить изменения придётся внутри документа (ради простоты и гарантированной корректности пары документ-изменения), что со временем приведёт к его распуханию
2. Не очень понятно как обрабатывать вложенные документы, особенно текстовые
Автор:  Роман М. [ Воскресенье, 07 Февраль, 2010 16:02 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Насчёт сравнения текстов в составных документах хочу добавить, что на мой взгляд, нехорошо, что стиль и формат текста - неотъемлемая часть исходных текстов. Я бы предложил следущий вариант развития составного документа:

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

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

Имея такой формат, можно оперировать над текстами, не вдаваясь в подробности оформления. Вообще, следует отделить исходные тексты от оформления. То ли выделить маркерами начала-конца исходного текста, а может и отделить в особый формат файла, потому как наряду с положительными свойствами составных документов, встречаются всяческие проблемы, нетипичные для простых текстовых файлов.
Автор:  Илья Ермаков [ Воскресенье, 07 Февраль, 2010 18:16 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Info21 писал(а):
Илья Ермаков писал(а):
Вариативность - в разные модули реализации.
Кстати, да.
Это, вместе с F9, по-моему, заметно нейтрализует пользу от SVN.

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


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

Плюс, конечно, как-то страхует сам факт наличия всей истории изменений. Пару раз было нужно откатывать на одно изменение назад.
Автор:  Роман М. [ Среда, 10 Февраль, 2010 10:29 ]
Заголовок сообщения:  Diff & Patch
Решил пойти по первому пути, предложенного Александром Ильиным.

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

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

Diff-patch.odc
Автор:  Иван Горячев [ Среда, 10 Февраль, 2010 13:51 ]
Заголовок сообщения:  Re: Diff & Patch
Я бы сделал несколько иначе:

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

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

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

Потом нужно учесть особенности составных документов, а именно - вложенные элементы.
Автор:  Роман М. [ Среда, 10 Февраль, 2010 14:49 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
1. Я также имел в виду заголовок со служебной информацией в начале файла, а не заголовок блока.
2. Что насчёт количества блоков в заголовке?
3. Подробнее, что такое тег-метка блока. Откуда его получают?
4. Пока не представляю каким образом можно объединять заплатки от разных файлов в один файл. Хотелось бы понять, как понимать "хранить их в самом целевом документе"? Пока лишь есть идея закодировать файл-заплатку с помощью StdCoder, чтобы можно было обмениваться "патчами" через веб.
5. Кроме всего, встроенные элементы тоже должны обрабатываться. Только вот задача определять разницу между старым и новым... Картинки, OLE-объекты, ... - всех их нужно уметь сравнивать. Тут, по ходу, надо смотреть описание ODC.
Автор:  Иван Горячев [ Среда, 10 Февраль, 2010 15:09 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Я фактически предлагаю отказаться от файла и перейти к потоку блоков. Процедура применения патча будет работать именно с этим потоком, не важно откуда полученным. Прочитали блок "начало патча" - поехали. Количество блоков в заголовке - а зачем? Тогда уж просто иметь ещё блок типа "конец патча" с контрольной суммой оного.

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

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

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

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

Тэг блока - да любая константа, подтверждающая что это - блок. Хоть 123. Чисто для контроля. В принципе не обязателен, конечно. Разве что для частичного восстановления битого патча (а вдруг?)
Автор:  Иван Горячев [ Среда, 10 Февраль, 2010 15:29 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
По поводу вложенных вьюшек есть вариант. Поскольку мы пишем патчер на ББ, то мы можем штатными средствами пройтись по всему дереву объектов в документе. И штатными же средствами опросить все их свойства. Пойду Дракон попытаю на предмет алгоритм нарисовать
Автор:  Роман М. [ Среда, 10 Февраль, 2010 15:54 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Обновил спецификацию (см. тему Diff & Patch).

Цитата:
2. Поля служебного заголовка файла
- [0] Название формата файла, ARRAY 12 OF CHAR.
- [+24] Версия формата, INTEGER.
- [+4] Описание заплатки, ARRAY 32 OF CHAR.
- [+64] Дата-время заплатки,
Код:
   RECORD
      d: Dates.Date; (* 12 байт *)
      t: Dates.Time (* 12 байт *)
   END

- [+24] Контрольная сумма файла CRC32, INTEGER.

3. Поля заплатки
- [0] Уникальная метка заплатки, INTEGER. Random?
- [+4] Начало/Конец заплатки, BOOLEAN. Каков размер BOOLEAN?
- [+4] Путь к файлу для применения заплатки, ARRAY 64 OF CHAR.

4. Поля блока
- [0] Тип операции: добавление/удаление/изменение блока, INTEGER.
- [+4] Размер блока N в байтах, INTEGER.
- [+4] Данные блока, ARRAY N OF CHAR.


Цитата:
2. Статус применения заплатки
Заплатка считается успешно применённой по отношению к исходному документу если:
- контрольная сумма файла совпадает с вычисленной.
- целевой файл найден и к нему имеется доступ.
- успешно произведена модификация всех частей заплаток для каждого файла.
Автор:  Евгений Темиргалеев [ Среда, 10 Февраль, 2010 16:25 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Может описывать заголовок просто как RECORD ... END. Имеют ли смысл эти [+4]?
Автор:  Info21 [ Среда, 10 Февраль, 2010 17:13 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Илья Ермаков писал(а):
Основное, в чём пока заменить нечем, - коллективная работа с хранилищем, страховка от одновременных изменений, и т.п.
Так, может, тогда и хранить encoded-файлы? Чистый ascii.

Ну их нафик, сложности все эти с патчами-версионностью...
Автор:  Илья Ермаков [ Среда, 10 Февраль, 2010 20:28 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Мысль оригинальная, да... Сама по себе.

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

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

А тем, кому нужен дифф - возможно...
Автор:  Info21 [ Среда, 10 Февраль, 2010 20:40 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Илья Ермаков писал(а):
для нашего режима encoded ничего не даёт.
А. Не знал. Из общения с дипломником вышло впечатление, что там нужен чистый текст. Ну и ладно.
Автор:  Евгений Темиргалеев [ Среда, 10 Февраль, 2010 20:49 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Илья Ермаков писал(а):
А тем, кому нужен дифф - возможно...
odc-diff никому бы не помешал. Хотя бы знающий стандартные вьюшки.
Иван Горячев писал(а):
Поскольку мы пишем патчер на ББ, то мы можем штатными средствами пройтись по всему дереву объектов в документе.
Тов. Горячев знает, что говорит. В качестве примера предлагаю поглядеть его конвертер документов в юникод из "BlackBox Component Builder 1.6 Community Edition" (http://oberoncore.ru/projects/bb16ce). я был приятно удивлён, когда, забыв раскрыть все складки до преобразования, обнаружил внутри них юникод.
Автор:  Info21 [ Среда, 10 Февраль, 2010 21:42 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Евгений Темиргалеев писал(а):
Тов. Горячев знает, что говорит.

Пусть будет отдельным абзацем.
Автор:  Александр Ильин [ Среда, 10 Февраль, 2010 21:55 ]
Заголовок сообщения:  Re: Контроль изменений в составных документах
Info21 писал(а):
вышло впечатление, что там нужен чистый текст.

Александр Ильин писал(а):
текстовый формат без межстрочных зависимостей

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

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

Пользователь Б, допустим, изменил имя типа с Object на Obj, а имя переменной не трогал.
Код:
bold=19..22
PROCEDURE (o: Obj) Init*;
Как видно, заголовок тоже автоматически изменился, чтобы отразить новое положение слова Init в тексте.

При попытке выполнить слияние получим следующую проблему:
Код:
bold=??..2?
PROCEDURE (obj: Obj) Init*;
Автоматике не ясно, что должно быть в заголовке. Один пользователь говорит, что там должно быть 24..27, другой - что 19..22, а на самом деле там должно быть третье значение: 23..26.

Решения два: либо автоматика должна обладать достаточными знаниями для того, чтобы вычислять новое значение (этим путём идёт Роман М. из Израиля), либо нелокальные зависимости надо превратить в локальные. Например, в XML это могло бы выглядеть так:
Код:
PROCEDURE (obj: Obj) <bold>Init</bold>*;


Нынешний формат ODC мало чем отличается от приведенного двухстрочного. Есть бинарный заголовок, в котором указано форматирование для каждой цепочки символов, какие символы считать вьюшками и т.п. Сама по себе бинарность проблемы не представляет. Если просто закодировать всё в ASCII, слияние проще не станет.
Страница 1 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/