Есть Розница.Изначальная конфигурация слегка дописанная. Обновляю центральный узел cf-файлом. Он весит 400 с хвостиком мегабайт. Синхронизирую с периферийными базами. Файлы выгрузки весят уже по 900 мегабайт.1С выгружает две конфы?

Разумеется.

(1)А смысл?

это было одно из условий для меня для реализации :
уже 11 лет , а конфигурация MAGAZKA весит 11 мб.
обновления релиза 2-3 раза в месяц (у клиента было максимально 37 магазинов сети) и не везде всегда есть хороший интернет
мои работают (у которых 3-4 магазина в сети - авто обмен 60 секунд - все летает)
Старший продавец если есть права -может сам обновить - кликнул по ссылке -есть обновление - обновить = да.
Все в автоматическом режиме !

(0) Удаляй конфигурацию поставщика. Толко в рабочей базе от нее никакого, только место занимает

Так и РИБ в полном виде, как его сделали в типовой - он тоже в большинстве внедрений избыточен. Внесение изменений в конфиги ПБ носят крайне редкий и эпизодический характер. Их можно устанавливать по узлам отдельно от РИБ

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

(6) но тогда кто мешает просто раздвинуть булки и не мучиться?!

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

И все-таки, установка на ПЮ неких технологических моментов, при наличии Центральной Базы... Нужно просто адекватно оценивать все это.

(7) ПЮ - это какая-то дикая опечатка - ПБ конечно!

(5) "Их можно устанавливать по узлам отдельно от РИБ" // Тогда и от платформекнной десериализации при загрузке данных в обоих концах придется отказаться

(9) С чего бы вдруг? Просто делаешь обмен не РИБ. И не забываешь актуализировать правила.
И обновлять ПБ можно постепенно, без спешки. И не тащить туда то, что нужно только в ЦБ.

Я сам так не делал, но помню, тут рассказывали, что работает.

(10) Через правила - не единственный вариант, но в таком случае и применение терминологии "РИБ" уже ставится под вопрос.
Все-таки применительно к инфобазам 1С понятие "РИБ" - это именно с использованием платформенной сериализации-десериализации. Как о множество других механизмов платформы, этот механизм зачастую обрастает прикладным кодом и (в абсолюте) используется вообще только для регистрации факта изменений конфигурации, а весь транспорт и логика не задействует платформенные возможности никак.

(11) Ты что-то путаешь. ЕСли говорить о терминологии, "РИБ" — это когда конфигурации идентичны, и это обеспечивается платформой. А все остальное не РИБ. Сериализацию можно использовать отдельно, для любых целей. Регистрацию изменений тоже, как ты уже заметил. В этом плане все достаточно продумано.

(12) Некорректно говорить о путаньи, когда у термина нет единственного определения

По моему личному опыту получалось так, что технология РИБ == создание узла и его наполнение полностью синхронизированными данными, которые затем в регулярных обменах мало участвуют, т.к. не подвержены частым изменениям.
Зачем для таких узлов нужно таскать конфигурацию? Не очень понятно зачем. Более того, зачем для этих периферийных узлов нужна конфигурация Поставщика, если _внимание_ конфигурация Поставщика имеет смысл только в Центральном узле, а в остальных нужна гарантия соответствия обработки правил в текущих конфигурациях, а не вкряченных куда-то в глубокие потроха копия от Поставщика.

функционально, если вдруг очень захочется периферийный узел оторвать от центрального насовсем, то наличие конфигурации Поставщика получит какой-то смысл. Но ведь это процедура, которую можно выполнить вручную заливкой Конфигурацией из файла, вместе с конфигурацией Поставщика из файла, а не ее передачей в обмене РИБ

(13) Я пользуюсь определением из ЖКК. https://imgur.com/VRI4BhR

(14) >Зачем для таких узлов нужно таскать конфигурацию?

Для того, чтобы все данные, которые льются из ЦБ, узел мог гарантированно принять.
В более сложных схемах это нужно обеспечивать разработчику, а РИБ это упрощенный вариант, где эту функцию берет на себя платформа.

(17) конфигурация Поставщика не принимает никакого участия вообще в обработке данных, хоть в обменах, хоть в обычной текущей работе

(18) Про конфигурацию поставщика я ничего не говорил.

Но смысл может быть в том, чтобы можно было отвязавшись от ЦБ, обновлять с сайта 1С.

(16) Строго говоря, раз ты забиваешь на сериализацию-десериализацию платформой, то и на транспорт изменений конфигурации тоже можно забить.
Технически флажок РИБ обеспечивает лишь получение возможности отслеживать маркер измененности конфигурации узла, а уж как это изменение будет доставляться и распространяться (по аналогии с данными) - дело уже прикладного кода.

(0)А почему у вас выгружается полная конфишурация?
Только изменения должны же входить в состав пакета.

(20) Мудрено говоришь, но я понял, что вернулись к (10) "Просто делаешь обмен не РИБ", то есть без флажка.

(21) 1с так не умеет

(21) это если объект полностью на поддержке. И это в основной конфигурации, а не в конфигурации поставщика.

(24) Наблюдаю конфу УТ 10.3 с настройкой "Редактируется с сохранением поддержки".
При изменении конфигурации центрального узла при выгрузке обычно передаются совсем небольшие объёмы.
Нет такого, чтобы размер пакета равлялся размеру .CF.

(25) А ты зафигачь на основной базе реструктуризацию всех объектов метаданных и тогда зацени, что она тебе покажет. Там видно периодически сообщения о составе реструктурированных или как еще выдает "регистрация объекта изменена". Вот тогда все эти измененные влетают в выгрузку.

и не на УТ 10.3, а Рознице с одним из последних БСП :-)

(27)А как наличие БСП влияет на объём изменений объектов?
Вот, цитата "для синхронизации конфигураций между узлами передается не вся конфигурация, а только измененные объекты" из
https://its.1c.ru/db/metod8dev/content/2280/hdoc

(25) в УТ 10.3 размер конфы 25 мб. А современнык конфы - минимум 1 гиг, а то и больше. Поэтому объемы, которые были в УТ 10.3 сразу умножай на 30-40

Я обычно вырезаю все эти 400 мб, если на точках компы или инет не очень. Половина из них занимают драйверы оборудования, которое никогда не нужны. Если понадобится, их всегда можно вытащить из БСП или оригинальной конфиги.

(28) каком к верху и влияет.

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

А основное отличие как раз в том, что в бородатой ут 10.3 играть никто не станет : ни с функциональными опциями, ни с константами, ни с прочим внесением изменений на уровне БСП

(22) Но ты там далее указываешь "И не забываешь актуализировать правила". А правил-то никаких изначально в РИБе считаем, что нет.