То что проводить обновление ИБ нужно последовательным накатыванием совместимых весрий релизов конфигураций обновлений это мне понятно.
У меня как раз есть набор подготовленных cf файлов с такими конфигурациями. Мне правильно нужно обновить ИБ (последовательно установив и приняв в режиме 1С предприятие эти изменения).

Но вот дилемма. ИБ не только стоит на поддержке (и большая часть объектов в ней не имеет возможности изменения и нами не изменяются), но ещё и подключена к хранилищу.

Поэтому просто последовательно загрузить имеющиеся конфигурационные файлы в режиме загрузки я не могу.

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

Как правильно поступить в этой ситуации? ИБ должна в итоге остаться подключена к хранилищу, история хранилища не должна быть потеряна. Как последовательно установить несколько конфигурационных файлов в такую ИБ и внести в хранилище правильный итоговый результат. Оставив типовые объекты без наших изменен на поддержке "без возможности редактирования"?

из конфы хранилища сделать свою поставку

(1)А что с ней делать дальше?

(2)Аа... наверное, захватить все объекты в харилище и выполнить этап обновления конфигурации уже этой самой изменённой поставкой.
Тогда, не на основе хранилища делать поставку - а на основе имеющихся cf файлов (по каждому в отдельности).
А прокатит? Основной поставщик, то сейчас 1С?

что-то я не понял проблемы. рекурсивно захватывай конфу в хранилище, накатывай .cfu как обычно

(4)Я имел в виду - не будет проблемы обновлением конфигурации (стоящей на поддержке в 1С( по такому "видоизменённому" (с нашими изменениями) cfu файлом? Просто у меня нет опыта работы со "своими" cfu-поставками
А может просто выполнить обновление, указывая имеющиеся cf файлы (вместо cfu)? Всё также - последовательно? Захватить всё в хранилище из этой ИБ - там всё последовательно обновить (через поддержку, указывая подготовленные "сведённые" cf файлы, и затем финальный результат поместить в хранилище)?

(5) делаешь хранилище, в него запихиваешь базу с поставкой 1с. Обновляешь эту базу через .cfu от 1с.

из него делаешь свою поставку, на каждый .cfu от 1с делаешь свой .cfu

эту поставку накатываешь на рабочую базу. Рабочая база с хранилищем не связана.

(5)Неек этот мой вариант не прокатывает... говорит что файл (cf) не содержит конфигурации обновления. Но тогда можно так накатить cf из финальной типовой базы, у уже затем его уже сравнить-объединить с финальным файлом с нашими изменениями и это поместить в хранилище. А обновляемую ИБ временно отключить от хранилища и последовательно загрузить в неё все cf-ники - провести корректное обновление, и уже затем повторно подключить к хранилищу, с уже актуальной версией (просто помещённой без промежуточных этапов - для упрощения).

Наверное так всё должно получиться, и достаточно эффективно

(6)+ рабочая база без поставки от 1с, только с поставкой из хранилища

(8)Да, я знаю такую схему. У нас пока она не утверждена :( так что не подходит

Я сейчас делаю как написал в (5) - отдельно обновляю ИБ, отключённую от хранилища. Затем захвачу всё в хранилище (в отдельной копии, хотя это не обязательно) обновлю финальными типовым релизом (выгруженным cf файл) и затем ещё нашим финальным cf-ником (сравню и объединю) с нашими изменениями - это уже кладу в хранилище, и к нему уже затем подключаю обновляемую ИБ (релизы конфигураций у них уже должны быть идентичны)