Воттуттоварищи через использование odcread пришли к возможности просматривать изменения текстовых документов ББ. Это прекрасно.
Но есть несколько моментов.
Во-первых, утилита odcread заброшена. Во-вторых, она написана на C++, идеологически неприятно. В-третьих, будучи одним из тех, кто реализовал конвертер бинарного формата .odc я понимаю, что содержимое бинарного файла не самоописательное, а правильность чтения Store из файла зависит от конкретной реализации кода.
В связи с последним фактом стало понятно, что полноценная поддержка формата возможна только изнутри ББ.

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

Поэтому, наряду с утилитой odcread предлагаю реализовать возможность для ущербных plaintext-инструментов хоть как-то понимать содержимое .odc-хранилища. Поэтому, я выдвинул своё видение оберон-решения данной проблемы в сообщенииviewtopic.php?p=81466#p81466> -- Пётр Кушнир писал(а):
> В целом, если учитывать, что для двух .odc файлов невозможно найти универсальный способ выделения различий, а для узкой задачи различий в системах CVS достаточно только примитивного plain-text отражения содержимого текстового файла ББ, есть предложение разработать специальный контрол версионности. По своим функциям он будет представлять мощный аналог контрола StdStamps, и внутри себя сможет содержать отображение текста исходника, например, отдельный детектируемый внешними инструментами непрерывный блок байтов, представляющий текст формате utf8, который смогут читать внешние инструменты, типа diff-плагина и в то же время, такой расширенный Stamp уже внутри ББ сможет предоставлять функции версионности на уровне отдельного документа, с возможностью просмотра диффоф и так далее. То есть, выделяются две основные функции:Как решающий фактор, который позволит реализовать такой контрол версионности, выступает тот факт, что внедрённые отображения могут получить доступ к модели контекста, в котором они расположены. А для желающих принимать участие в разработке базовой сборки ББ, после устаканивания процесса совместной разработки, можно ввести договорённость на обязательное использование подобного контрола версионности.
Теория без практики никуда не годится, поэтому я разработал макетную версию компонента, который мог бы предоставить подобную функциональность. Компонент реализует первый пункт списка требований - умеет сохранять plaintext-содержимое документа, в котором он находится, в определённой области бинарного файла. Эта область ограничена известными бинарными тэгами. Для конечного юзера поддержка документом дифф-инструментов будет заключаться в единоразовом размещении в документе якоря-предпросмотра.
Предполагаемые аспекты подобного решения:
положительные:сторонние инструменты будут тесно взаимодействовать только с бинарными данными одной Store, а не многих, как odcreadработа с бинарным .odc на уровне области в цепочке байтов освобождает diff-плагины от необходимости понимать формат целиком, а значит упрощает реализациюсодержимое документов будет доступно для просмотра даже в случае полного отсутствия ББотрицательные:размер файла увеличивается на количество символов текстовой модели, сконвертированных в utf8по-умолчанию в документах никаких якорей предпросмотра нет, а значит размещение якорей будет возложено на конечного юзеранеобходимость плагинов и их настройки в каждом отдельном случаеУчитывая прогресс Ивана Денисова по написанию diff-плагина для git, планируется разработать похожие инструменты для остальных популярных систем, которые будут основаны на анализе области предпросмотра.