Веду свои доработки конфигурации на поддержке; всё, что возможно, делаю через расширения. Поставщик конфигурации также иногда присылает изменения к одному из моих расширений, отражающие изменения в очередном обновлении основной конфигурации. Слияние изменений делаю средствами Git (через TortoiseGit), т.к. 1С не умеет делать трехстороннее слияние. Для корректного слияния XML-файлов взял Oso XML Merge.
Обычно сливаемые изменения невелики, и слитый код успешно работает. Но сейчас я слил серьезную доработку, и при попытке загрузить получившимйся код в конфигуратор возникли нижеуказанные сабжевые ошибки.
Платформа 8.3.23.1865 x64, режим совместимости 8.3.17 .
Справочник.КарточкиВспомогательногоОборудования.Реквизит.ИнвентарныйНомер - Дублирование имени объекта метаданных:
Справочник.КарточкиИспытательногоОборудования.Реквизит.ЗаводскойНомер - Дублирование имени объекта метаданных:
Справочник.КарточкиИспытательногоОборудования.Реквизит.ИнвентарныйНомер - Дублирование имени объекта метаданных:
Справочник.КарточкиВспомогательногоОборудования.Реквизит.ЗаводскойНомер - Дублирование имени объекта метаданных:
<...>
Справочник.КарточкиСредствИзмерений.Реквизит.Акр_НаименованиеПолное - Дублирование имени объекта метаданных:
<...>
Всего около 100 строк. Похоже, это вообще все реквизиты в расширении -- и заимствованные, и даже добавленные -- которые и сопоставлять-то не с чем!
Мерджил ветку проекта в основную ветку; если был конфликт изменений в UUIDах объектов, я брал тот, что в основной ветке (т.е. оставлял без изменений).
Файл ConfigDumpInfo.xml удаляю.
Однако, я изучил механизм сопоставления и проверил, что всё, что можно, вроде бы совпадает (см. ниже).
Еще одно различие: в найденных результатах говорится только про обновление основной конфигурации, и ошибка происходит при обновлении конфигурации БД. Тогда как у меня -- расширение, и ошибка происходит прямо при загрузке из XML, еще до попытки обновления конфигурации БД. Таких случаев не нагуглил.
* Согласно Глава 36. Расширение конфигурации :: Руководство разработчика :: 1С:Предприятие 8.3.17. Документация, объекты сопоставляются:
* по внутреннему идентификатору -- по-видимому, атрибут "uuid" в теге описание объекта метаданных. В расширении содержимое тега "<ExtendedConfigurationObject>", по-видимому, является ссылкой на расширяемый объект
* по имени, если в св-вах расширения не выставлена галочка "Поддерживать соответствие объектам расширяемой конфигурации по внутренним идентификаторам" (у меня она везде выставлена).
Я проверил, что соответствующие имена и идентификаторы в основной конфигурации и расширении совпадают. Вот, например, справочник "КарточкиВспомогательногоОборудования" в расширении:
1. В версии расширения в тестовой базе добавить нужные реквизиты, выгрузить в тот же каталог и посмотреть изменения.
* В вышеуказанный файл выгрузилось то же самое, но реквизиты были в другом порядке и UUID у ЗаводскойНомер был другой. Я поменял в исходном файле и UUID, и порядок -- та же самая ошибка.
2. Переименовать реквизиты с ошибками. Получил кучу ошибок "неверно указан путь к данным" (где на эти реквизиты ссылаются по имени), после исправления путей -- та же ошибка, но уже с новыми именами.
3. Исправить даты всех файлов, на случай если конфигуратор хочет, чтобы что-то из них было старее/новее чего-то. Делал через "git ls-tree -r HEAD --name-only -z | xargs -0 touch" из командной строки Git Bash. Та же ошибка.
4. Исправить концы строк во всех файлах на CRLF через "git ls-tree -r HEAD --name-only -z | xargs -0 u2d" (у меня они после мерджа оказались LF, т.к. в Git for Windows я еще давно, при установке, по умолчанию выставил "core.autocrlf=input"). Та же ошибка.
5. В Configuration.xml в "<KeepMappingToExtendedConfigurationObjectsByIDs>" (состояние галочки "Поддерживать соответствие объектам расширяемой конфигурации по внутренним идентификаторам") выставить в false, а во всех файлах удалить теги "<ExtendedConfigurationObject>", чтобы заставить конфигуратор сравнивать по имени. Та же ошибка.
6. Почистить кэш 1с (закрыть все клиенты, удалить папки "%APPDATA%\1C\1cv8\<uuid>" и "%LOCALAPPDATA%\1C\1cv8\<uuid>"). Та же ошибка.
---
Все это явно свидетельствует о том, что в механизме сопоставления есть еще какая-то "секретная" проверка, не описанная в статье ИТС, о которой я не знаю. В https://forum.infostart.ru/forum9/topic145475/#message1496472 есть ссылка на партнерский форум, где якобы "всё объясняется", но что именно там объясняется -- неизвестно.
Локализовал проблему постепенным выкидыванием файлов из расширения и "грязным" исправлением ошибок, не относящихся к титульной (т.к. мне было нужно только обеспечить, чтобы алгоритм загрузчика смог проработать до шага, на котором возникает титульная ошибка).
(Например: ссылки на выкидываемые типы вида "cfg:<....>" заменял на "xs:boolean".)
В Configuration.xml в "<ChildObjects>" дублировались записи. Загрузчик это не проконтролировал и выдал ошибку далее по алгоритму.
Косяк возник потому, что Configuration.xml -- единственный файл, который я не смог объединить через Oso XML Merge.
В этой утилите правила сравнения (=правила поиска тегов, соответствующих друг другу, т.е., фактически, схема) задаются по корневому тегу файла, а у Configuration.xml он такой же, как у файлов других объектов метаданных, но XML-схема совсем другая.
Буду писать разработчикам утилиты, чтобы научили ее как-то поддерживать такой случай.
(5) Техподдержка Oso XML Merge рассказала, как обрабатывать такой случай.
* В настройках слияния для Configuration.xml задал шаблон имени файла "Configuration*.xml".
** т.к. Git при формировании файлов для внешней программы слияния дает именам суффиксы, но сохраняет расширения
* В файле настроек для прочих стоит "*.xml".
Теперь при слиянии Configuration.xml Oso XML Merge спрашивает, какими настройками воспользоваться.
Потому что 1С не умеет делать трехстороннее объединение. Даже EDT (в котором от Eclipse встроенная поддержка Git) не умеет.
Если есть независимые изменения в 2 ветках, при объединении через конфигуратор половина изменений пропадает.
Единственный предлагаемый способ этого избежать -- объединять все такие места руками. Крайне трудозатратно и рискуя где-нибудь ошибиться и получить скрытый баг.
7. Загрузить XML в другое расширение -- на случай, если конфигуратор сравнивает не только с основной конфигурацией, но и с тем, что уже было в расширении.
8. Снять конфигурацию с поддержки, удалить все расширения, обновить конфигурацию БД, и загрузить XML в новое расширение -- на случай, если в сопоставлении участвуют какие-либо другие экземпляры конфигурации, кроме конфигурации разработчика.
Локализовал проблему постепенным выкидыванием файлов из расширения и "грязным" исправлением ошибок, не относящихся к титульной (т.к. мне было нужно только обеспечить, чтобы алгоритм загрузчика смог проработать до шага, на котором возникает титульная ошибка).
(Например: ссылки на выкидываемые типы вида "cfg:<....>" заменял на "xs:boolean".)
В Configuration.xml в "<ChildObjects>" дублировались записи. Загрузчик это не проконтролировал и выдал ошибку далее по алгоритму.
Косяк возник потому, что Configuration.xml -- единственный файл, который я не смог объединить через Oso XML Merge.
В этой утилите правила сравнения (=правила поиска тегов, соответствующих друг другу, т.е., фактически, схема) задаются по корневому тегу файла, а у Configuration.xml он такой же, как у файлов других объектов метаданных, но XML-схема совсем другая.
Буду писать разработчикам утилиты, чтобы научили ее как-то поддерживать такой случай.
(5) Техподдержка Oso XML Merge рассказала, как обрабатывать такой случай.
* В настройках слияния для Configuration.xml задал шаблон имени файла "Configuration*.xml".
** т.к. Git при формировании файлов для внешней программы слияния дает именам суффиксы, но сохраняет расширения
* В файле настроек для прочих стоит "*.xml".
Теперь при слиянии Configuration.xml Oso XML Merge спрашивает, какими настройками воспользоваться.