Автоматическое сравнение-объединение с cf (Пакетный режим)

1. Vl_1Cdev 20.03.25 16:07 Сейчас в теме
Доброго времени суток. Задача не боевая, просто изучаю возможности платформы.

Идея: инкрементально догружать изменения в основную кф.

Суть вопроса: если подготовить cf файл, содержащий только изменения относительно основной кф, то при открытии окна сравнения по умолчанию накладывается такая логика:
1. то что есть в кф, но нет в файле - остается;
2. то что есть в кф и есть в файле - берется из файла;
3. то что отсутствует в кф, но есть в файле - берется из файла.

Меня устраивает такая логика, но при попытке мержевания в пакете, требуется параметр-указатель на xml файл настроек mergesetting. Данный файл можно получить только при кастомном объединении и в данном случае в нем нет необходимости. Есть ли какой то флаг, которым можно сбросить выбор данного файла?

Моя команда:
"СТАРТЕР или ТОЛСТЫЙ КЛИЕНТ" DESIGNER /F "БАЗА" /MergeCfg "CF ФАЙЛ" -Settings "ФАЙЛ НАСТРОЕК" -force /UpdateDBCfg
По теме из базы знаний
Найденные решения
10. Vl_1Cdev 21.03.25 11:45 Сейчас в теме
(1) В общем разобрался по своей гипотетической задачке. Файл mergesetting формируется и становится доступным для выгрузки, если мы изменяем стандартные настройки объединения (даже если просто зашли в настройки объединения какого либо модуля и приняли изначально созданные правила). В таком случае модифицированные правила объектов формируются в теге Objects, из-за него и создается данный файл настроек. Но до модификации правил уже существовали настройки примерно такого вида:

<?xml version="1.0" encoding="UTF-8"?>
<Settings xmlns="http://v8.1c.ru/8.3/config/merge/settings" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2" platformVersion="8.3.11">
<MainConfiguration>
<Name>Конфиг</Name>
</MainConfiguration>
<SecondConfiguration>
<Name>Конфиг</Name>
</SecondConfiguration>
<Parameters>
<ConfigurationsRelation>ConfigurationsNotRelated</Configurat­ionsRelation>
<AllowMainConfigurationObjectDeletion>false</AllowMainConfig­urationObjectDeletion>
<CopyObjectsMode>false</CopyObjectsMode>
</Parameters>
</Settings>

Это основная логика мержевания образующая общие правила, в этом случае файл настроек не создается.

При объединении в пакете команд файл настроек является обязательным параметром (хз почему), но парсить структуры измененных объектов для наполнения тега Objects не обязательно, достаточно указать шапку и произойдет объединение по умолчанию (старые остаются, новые создаются, измененные изменяются)
Fox-trot; natz78; +2 Ответить
Остальные ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
3. Vl_1Cdev 20.03.25 16:53 Сейчас в теме
(2) То ли я где то неверно выразился, то ли чего то не понял в ссылках. Я уже нахватался этой инфы. Но из всего что я впитал, ощущение, что для автоматического наката изменений мне нужно также генерить сам этот xml-ник, ибо без его указания выскакивает ошибка пустого параметра.

Мой вопрос - есть ли команда, которая будет соответствовать объединению по умолчанию, по сценарию описанному выше (для которого не нужен файл настроек)
5. nomad_irk 81 21.03.25 07:45 Сейчас в теме
(3) что происходит, если совсем не указать -Settings "ФАЙЛ НАСТРОЕК"?
7. Vl_1Cdev 21.03.25 09:51 Сейчас в теме
(5) Я ниже скинул скрин ошибки. В общем ошибка не найденного каталога
9. user1936660 21.03.25 10:30 Сейчас в теме
(1)
Данный файл можно получить только при кастомном объединении
Данный файл можно сделать вручную по описанию структуры на ИТС. Там хранятся только значения, отличающиеся от значений по умолчанию, поэтому его можно сделать и без анализа конфигурации
10. Vl_1Cdev 21.03.25 11:45 Сейчас в теме
(1) В общем разобрался по своей гипотетической задачке. Файл mergesetting формируется и становится доступным для выгрузки, если мы изменяем стандартные настройки объединения (даже если просто зашли в настройки объединения какого либо модуля и приняли изначально созданные правила). В таком случае модифицированные правила объектов формируются в теге Objects, из-за него и создается данный файл настроек. Но до модификации правил уже существовали настройки примерно такого вида:

<?xml version="1.0" encoding="UTF-8"?>
<Settings xmlns="http://v8.1c.ru/8.3/config/merge/settings" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2" platformVersion="8.3.11">
<MainConfiguration>
<Name>Конфиг</Name>
</MainConfiguration>
<SecondConfiguration>
<Name>Конфиг</Name>
</SecondConfiguration>
<Parameters>
<ConfigurationsRelation>ConfigurationsNotRelated</Configurat­ionsRelation>
<AllowMainConfigurationObjectDeletion>false</AllowMainConfig­urationObjectDeletion>
<CopyObjectsMode>false</CopyObjectsMode>
</Parameters>
</Settings>

Это основная логика мержевания образующая общие правила, в этом случае файл настроек не создается.

При объединении в пакете команд файл настроек является обязательным параметром (хз почему), но парсить структуры измененных объектов для наполнения тега Objects не обязательно, достаточно указать шапку и произойдет объединение по умолчанию (старые остаются, новые создаются, измененные изменяются)
Fox-trot; natz78; +2 Ответить
4. natz78 7 20.03.25 17:21 Сейчас в теме
Попробуйте убрать целиком кусок -Settings "ФАЙЛ НАСТРОЕК"
6. Vl_1Cdev 21.03.25 09:45 Сейчас в теме
(4) Это было бы самое логичное, поэтому и первое что я попробовал. "Каталог не обнаружен 3(0x00000003)" - это ошибка при попытке считать путь к настройкам, которого нет
Прикрепленные файлы:
8. comptr 36 21.03.25 10:01 Сейчас в теме
для объединения конфигураций с использованием файла настроек мы добавили новый параметр командной строки MergeCfg

https://its.1c.ru/db/v8326doc#bookmark:adm:TI000000832:
обязательный параметр Settings со своим параметром <имя файла настроек>;

Если вы сами готовите файл cf, то почему бы не подготовить к нему и файл настроек объединения?
Другой момент: как можно быть уверенным, что конфигурация, на которую накатывается обновление, не изменена и обновление произойдёт в штатном режиме? Или это ваша внутренняя конфа? Может лучше начать делать поставки?
11. Vl_1Cdev 21.03.25 12:34 Сейчас в теме
(8) Так, я объясню. Это выдуманная задача, дабы понять, насколько возможен частичный обмен кф на загрузку и выгрузку (с выгрузкой все гораздо проще). Гипотетически мы ведем коллективную разработку и используем децентрализованный контроллинг версии, но работаем с конфигуратором. Для нас необходимо развернуть рабочее место (в моем варианте сборщик готовит актуальную конфигурацию из файлов), далее предполагается лишь выгружать измененные объекты и проверять наличие обновлений искомой ветки проекта. Cfu банально более ресурсозатратный процесс, так как имеет собственный механизм поиска отличий, соответственно для его подготовки нужно иметь 2 полноценные конфигурации, по которым будет произведено сравнение, это усложняет сборочную линию. Здесь же перед автоматическим обновлением можно сохранить измененные строки configdumpinfo, и запустить пакет, который выгружает рабочую конфигурацию, накатывает все "релизные" cf, апдейтит базу, замещает изначальный файл configdumpinfo, и далее только в конце нужно сравниться с выгруженной конфой. Фактически при последующем ручном мержевании у нас есть все водные, чтобы определить наличие дважды измененных объектов, при этом мы автоматом накатились на сколь угодно итераций изменений.
12. Vl_1Cdev 21.03.25 13:08 Сейчас в теме
(11) Даже больше скажу, для ручной проверки конфликтов можно предварительно и не выгружать целиком конфу, а также выкинуть измененные объекты на сервер и получить cf только с изменениями относительно изначальной конфы, что полностью нивелирует какие либо полные выгрузки/загрузки
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот