Привет акулам 1С! Досталась задача - обновить нетиповую конфигурацию на приличное количество релизов. Собственно, как истинный программист, я сразу же бросился придумывать, как это лучше сделать... пришла идея выгрузить дифф между основной конфигурацией и конфигурацией поставщика (т.е. по сути сторонние доработки нетиповой конфы), обновить все релизы, а в самом конце просто накатить этот дифф на самый последний релиз. Собственно, вопрос - реально ли это сделать? Потому что механизмы у 1С, прямо сказать, не прозрачные. Решить конфликты в самом конце, все скопом и ровно один раз - я бы сделал именно так, но возможно ли?

Даже если ну никак - ладно, я смирюсь с такой кривотой и буду последовательно ставить все обновления, решая на каждом этапе конфликты. НО, меня интересует следующая ситуация (сразу оговорюсь, я не знаю 1С от слова "вообще", поэтому опишу ситуацию на псевдоязыке):
В основной конфигурации сторонними разработчиками написан класс B, который является потомком класса А (он есть в старой конфигурации поставщика). Класс А имеет публичные (никакой инкапсуляции, только хардкод) поля "name" и "surname". Где-то в коде этот класс (В) используется, например, выводится "surname". Ставлю обновление - в классе А поле surname удалено. При этом весь остальной код в новой конфигурации поставщика, естественно, использует обновленный класс А, чтобы корректно работать (ведь релиз официальный). Конфликтов в этом случае не будет: класс А успешно перекочует с полями из новой конфигурации поставщика, наш класс В, написанный в отдельном файле, будет тоже успешно перенесен. Проблема только в одном: как только мы начнем использовать вывод "surname" из объекта класса В где-то в своем коде, все упадет))
Иными словами - с какой вероятностью может возникнуть ситуация, что введенные производителем изменения нужно будет адаптировать под написанный собственноручно (не мной) код? Потому что решить конфликты - это одно, а вот чтобы все работало потом - это другое

(сразу оговорюсь, я не знаю 1С от слова "вообще",

Займитесь лучше тем, что знаете.

В основной конфигурации сторонними разработчиками написан класс B, который является потомком класса А (он есть в старой конфигурации поставщика). Класс А имеет публичные (никакой инкапсуляции, только хардкод)

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

Иными словами - с какой вероятностью может возникнуть ситуация, что введенные производителем изменения нужно будет адаптировать под написанный собственноручно (не мной) код?

Достаточно часто возникают такие ситуации. Поэтому обновление нетиповых - довольно большой геморрой. Приходится вникать в логику других разработчиков.
А вообще, когда не знаете 1С - лучше не лезьте в обновление нетиповых. Это как человеку, не знакомому с медициной (максимум прочитавшему учебнк по анатомию) поручить операцию по удалению аппендицита.

Варианта два - отказаться от задачи или найти исполнителя с опытом. Сами запорете с большой вероятностью БД.
В Ваших терминах: велика вероятность того, что типовой "класс" А мог измениться в обновлениях, а вы эти изменения затрете накатыванием "диффа"