Доброго времени суток.
У меня есть несколько рабочих и одна база для разработки. Допустим я допилил типовую БП. Потом 1С выпустили обновления, я накатил на свою разработку и хочу обновить все 5 рабочих баз. Зачем мне создавать файл поставки из базы разработки, когда я могу выгрузить .CF и загрузить в каждую из рабочих баз? Другими словами - зачем нужен файл поставки?Просветите, пожалуйста.Спасибо

Чтобы обновлять рабочие базы через механизм Обновления, а не через сравнение/объединение
Представьте, что у вас не 5 баз, а 10000

(0) А кто Вам сказал, что нужно " создавать файл поставки из базы разработки"?
И "выгрузить .CF и загрузить в каждую из рабочих баз" тоже осторожно надо.

(1) изменять конфу поставщика как-то не очень...

(0) Потому что, файл поставки будет с замочком, т.е. это типовая конфа от Васи Пупкина. Обновлять клиентов будешь не глядя, через поставка - обновить конфу...

(0) Я делаю так: Подготавливаю ЦФ нового релиза с доработками.
Далее рабочую базу обновляю на типовой нового релиза, сохраняю конфу, далее, не обновляя конфигурацию БД, сравнить/объединить с подготовленным ЦФ нового релиза с изменениями. А потом уже обновить конфу БД.

(3) Это называется "Вертикальная поддержка". Так многие отраслевые решения сделаны.

(2) (4) Ты, видимо, не понял вопроса. Автор спрашивает не про конфигурацию поставщика, а про поставку конфигурации...

(1) (3) Спасибо за инфу. А процедуры обновления БД будут запускаться и чере Обновления и через замену ЦФ?

(0)
1. В механизме поставки есть возможность создавать CFU, что бесценно от 10+ баз.
2. Если разработка ведётся в конфигурации, которая на поставке от 1C, то в обычный CF входит и 1С-овский файл поставки. Для УТ/БП это под сотню МБ.
3. Если база на поддержке без возможности изменения, то в ней нельзя случайно поменять конфигурацию

>Потому что, файл поставки будет с замочком, т.е. это типовая конфа от Васи Пупкина.

главное поставщика не менять... а то ж.па будет потом...

(8) Спасибо, все понятно стало)

(7) будут. Файл поставки содержит типовые уиды элементов конфигурации по которым идет сопоставление. Защищает от потери данных при (не аккуратном) обновлении

(8)
п.2 - получается, что если ты хочешь установить "на поддержку" какую-то свою подсистему - то придется либо "тянуть" поддержку всей типовой конфигурации 1С всегда с собой, либо полностью открывать конфу с замка и ставить замок только для своих объектов (что тоже неверно)?

>Чтобы обновлять рабочие базы через механизм Обновления, а не через сравнение/объединение

фигня...

(6) Может, да, не вкурил))
Только ведь в поставке будет уже измененная конфа поставщика. И придет другой обновляльщик в следующий раз с типовым обновлением от 1С, и удивится - "что ж за хрень такая здесь?"

(12) Файл поставки не содержит "родительских" файлов поставки. Поэтому просто по своей конфе (допиленной, на поддержке 1С) создаём файл поставки и его уже применяем на свои базы как будто он типовой.

(15)
Это понятно, но если я хочу создать свой файл поставки - мне нужно в него и все типовые объекты на поддержке пихать, не?

(16) В него сама вся твоя конфа как есть войдет. В него ничего пихать не нужно. Максимум - правила изменения настроить, но и это обычно не требуется.

(17)
Получается, что размер данного файла будет немаленьким?

Опять же если подсистема идет на несколько конфигураций - то для каждой конфы делать свой CFU

(18) а если там будет горизонтальная поддержка - он будет еще больше

мелкий файл - это cfu

(20)
Имеется типовая конфа. В ней 1000.. объектов на поддержке.
Допустим, мы хотим свою подсистему поставить на "замок". Для этого нужно:
- создать в своей конфе правила поддержки для новых объектов
- "типовую" конфигурацию объединить со "своей" конфигурацией
- при изменениях подсистемы - накатывать на "типовую" конфу только CFU.

А накатывание типовых CFU не сломается от этого? (даже если мы поставщика оставим того же)

+(21)
А если частенько добавляются новые объекты, то нужно будет всегда накатывать CF.