8.NSF.ODP.Sync.md

Синхронизация NSF и ODP

Итак, мы разобрались с базой по работе с git и сделали ODP проект, изменения в котором git будет отслеживать.
Тем не менее есть один шаг, без которого изменение ODP не происходит - это синхронизация изменений NSF и ODP.
Так же есть обратный процесс - синхронизация ODP и NSF.

Как происходит процесс синхронизации

Процесс синхронизации что ODP->NSF, что NSF->ODP происходит одинаково:

Элементы дизайна отбираются по имени в алфавитном порядке
Каждый элемент дизайна представляется в виде XML (либо парится XML при обратном процессе)
Создается элемент, в который пишется контент, полученный в пункте 2

Вроде ничего сложного, но именно данный этап является “ахиллесовой пятой” всего процесса.
Если мы не снимали галку про использование Binary DXL, то дизайн в ODP будет выгружен как base64 и при обратной синхронизации не будет никаких проблем.
А вот если сняли, то мы можем прочитать “исходник” и нам будет проще с этим работать при слиянии веток, но при обратной синхронизации ODP->NSF мы получаем несколько проблем. Причина в следующем.
Когда мы синхронизируем NSF->ODP, то каждый элемент дизайна трансформируется в XML (не могу сказать используются ли DTD или XSD файлы из Notes\xmlschemas).
Если мы при этом используем Swiper, то в процессе выгрузки, в памяти, мы полученный XML фильтруем и уже на диск пишется фильтрованный файл.
Если же мы делаем синхронизацию ODP->NSF, то каждый XML парсится и создаётся элемент дизайна. (опять же сложно сказать используются ли DTD или XSD файлы из Notes\xmlschemas).
Список известных проблем можно найти тут

Важно знать, что при синхронизации:

Каждый измененный элемент перезаписывается
Каждый новый элемент дизайна создается с нуля (UNID разный для разных баз)
Агенты импортируются раньше библиотек, поэтому порой требуется перекомпиляция базы
Синхронизация может не пройти, если не произвести обновление папки/базы (подробнее ниже)

Автоматическая синхронизация

Ранее мы отключали пункт автоматического импорта/экспорта в настройках дизайнера.
Если оставить их включенными, то в процессе разработки в Domino Designer изменения элементов дизайна будут автоматически транслироваться в ODP.
Плюс такого подхода в том, что нам не надо контролировать процесс экспорта, но минус в том, что в таком случае сложно разделить логические группы правок.
Например мы правили форму и библиотеку, при этом в библиотеке мы сделали две правки. Первую во время правки формы, а вторую - при исправлении другой ошибки.
В таком случае мы не можем сделать два отдельных коммита, так как экспорт происходит автоматически.
Да, мы не контролируем процесс экспорта, но мы вынуждены контролировать “партии” экспорта.
Аналогичная ситуация возникает и при обратном импорте.
Например, наша база синхронизирована с веткой, в которой работает два разработчика.
Второй разработчик сделал изменения и отправил (push) изменения на сервер, мы тоже сделали изменения, но не отправляли изменения.
Мы решили забрать его изменения к себе (pull), наша рабочая копия меняется.
В большинстве случаем будет конфликт, который мы решим и сразу после этого изменения из ODP будут транслированы в NSF.
Вот только нет никаких гарантий, что изменения не затрут наши доработки.
А если пришедший код был в base64, то становится ещё интереснее. По мнению автора данного текста: не надо использовать данный режим работы, никогда и ни при каких обстоятельствах.\

Панель swiper

swiper.panel.png

Swiper после установки добавляет свою особую панель, которая позволяет производить синхронизацию “в один клик”.
Вот только работает эта панель весьма специфично: если открыто более одной базы соединенной с git, то данная панель может произвести синхронизацию совершенно неверно.
Может выйти так, что база А будет синхронизирована с ODP базы Б и в результате всё будет заменено или уничтожено.
Данный способ синхронизации не подходит при работе с несколькими базами одновременно.
По мнению автора данного текста: использование панели является бомбой замедленного действия, а так же оригинальным способом получить хромоту.

Ручная синхронизация

Самый рабочий на практике способ.
Суть его в том, что мы контролируем экспорт и импорт самостоятельно.
Это позволяет делать коммиты блоками.
Изменили формы, вьюхи, библиотеки, агенты и всё для решения задачи - отправили в ODP и закомитили.
Поправили ошибку по запросу работая параллельно над другой задачей - поправили, выгрузили, отметили отдельный файл, закомитили.
Данный подход требует предварительной подготовки.

Для начала отображаем специальный вид “Package Explorer” в Domino Designer:

package.explorer.png