Обновление нетиповой конфиги БП 2.0
 

Всем привет!
До этого нетиповые восьмёрочные конфиги обновлять не приходилось, но тут появился у меня клиент с базёшкой БП 2.0 релиза 2.0.32.6 (конфига изменённая).
Надо обновить. Отказываться не стал, ведь такой хороший случай изучить всё это дело (сроки на задачу поставлены не очень жёсткие).
Нарыл статью по технологии обновления: [url]http://infostart.ru/public/18562/[/url].
Что-то сильно мутно всё у автора, схема донельзя усложнённая. Зачем-то всё время мучает конфигурацию поставщика (а на кой она нужна вообще?).
К тому же, по этой схеме нужно обновляться последовательно на все релизы.

Я слышал, вроде бы можно пользоваться семёрочной технологией обновления. То есть, три пункта:
1) сравнить типовую конфигу с изменённой (рабочей) конфигой
2) потом взять пустую типовую конфигу нового релиза и перенести туда настройки
3) накатить настроенную конфигу на рабочую базу.

Хотел узнать у опытных товарищей, кто как обновляет?

Кто-нибудь вообще юзает технологию, изложенную в [url]http://infostart.ru/public/18562/[/url] ???
Может быть, где-то описана иная методика?
Поделитесь пожалуйста инфой, хочется разобраться.

Правильная статья, годная. Но комплект видео от Гилева полнее.

(2) сам-то как?

и ещё, я не совсем понял, зачем там такие мучения с конфигурацией поставщика (этап №1) ?
Может, я неправильно уловил, но ведь конфигурация поставщика это всего лишь некий эталон, нужный только для сравнения с рабочей конфигурацией? В таком случае, зачем с ним париться? Может быть, плюнуть?

Может быть, проще сравнить с CF-кой, полученной из дистрибутива обновления?

Затем, что обновление настилается на конфигурацию поставщика.

(2) а ссылка - если это в открытом доступе?

(6) обновление настилается на рабочую (основную) конфигурацию.
конфигурация поставщика это просто эталон, используется только для сравнения.
А в процессе собственно обновления - она не нужна.

(7) Все там же: [url]http://www.spec8.ru/free-materials[/url]
Приемы обновления типовых конфигураций.

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

[quote=Reaper]Именно для того, чтобы найти отличия твоей нетленки от типовой конфы, конфигурация поставщика должна находится в соответствии с основной концигурацией.[/quote]
Ты уверен, что я без неё не смогу найти отличия?
Может, это ты сам немного лужу вспузырил?

Более правильный метод:
- ведение протокола изменений...
Смотришь измененные объекты в типовой,
смотришь измененые объекты в протоколе...
несовпавшие объекты тупо пропускаешь,
для совпавших вносишь изменения вручную.
По статистике 99% измененных объектов не требуют
обновления ;)
Ну, или может это только я так делаю? ;)

11-Ирли Бёрд > Если дальнейшая судьба конфигурации тебя не волнует, делай свою халтуру по-своему. Если предстоит длительная работа с этой конфигурацией, то важность сохранения конфигурации поставщика оценишь достаточно быстро.

хорошо, задам вопрос по-другому.
Имеем изменённую конфигурацию релиза 2.0.32.6.
Нужно обновить её до релиза 2.0.34.11.
Делаем так:

1) Сохраняем рабочую конфигурацию (из рабочей базы) в CF-файл.
2) Берём типовой дистрибутив 2.0.32.6, получаем из него CF-файл и создаём конфигурацию. Затем делаем сравнение с выгруженной CF-кой, получаем список изменений.
3) Берём типовой дистрибутив 2.0.34.11, создаём типовую конфигурацию, переносим вручную изменения (по списку, полученному в пункте 2). В итоге получаем CF (релиз 2.0.34.11, со всеми нашими настройками).
4) Накатываем этот CF на рабочую конфигурацию. Всё, готовченко!

Здесь мы обошлись вообще без конфигурации поставщика, она нам не понадобилась.
Можно ли юзать такой способ? Если нет, то почему?

(12) Нормальные люди не [filolog]трахают[/filolog] мозги протоколами - платформа делает это сама.
(14) Можно, если делать нехрен. Ибо с использованием поддержки потратишь минимум на час меньше времени. Иди учи матчасть.

15-Reaper > Может, это у него единственный час. А потом он конфигу забудет.
Вот если у него будет десяток-второй конфиг постоянно... От тогда часы-то и будет беречь.
А пока скачит бодреньким зайчиком: "Какой чудесный день, какой чудесный пень..."
;)

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

зачем вообще конфигурацию менять?

(16) Ты знаешь, мне одной хватает. Комплексная. Там один только cf-ник поддержки 150 метров весит. А полный за 300. Сравнение и объединение происходит минут 40. И вот это "туда-сюда" с конфигурациями меня бы просто убило. А так я 1 раз запускаю обновление, врубаю фильтр по 2-ды измененным и вижу все пересечения. 15-20 минут на анализ и запуск в накат. А как представлю эти извращения с протоколами/выгрузками так аж сны плохие снятся.

ваймэ! а тут надысь в хлам переписанную 7.7 бух под многофирменный учет 532 релиз обновлял на 538 не владея вскими кадиффами и прочими инструментариями - тот еще квест...

Ирли бёрд, всё дело в галочке "показывать только дважды изменённые объекты". Она бесценна ;).

(21) наконец-то вменяемый ответ по существу! спасибо!
да, галочка конечно зачётная.

То есть, правильно ли я понял уважаемого Пуделя, все эти пляски вокруг конфигурации поставщика ведутся токмо для того, чтобы можно было пользоваться этой замечательной фичей?

[img]http://pic.epicfail.com/wp-content/uploads/2009/10/sailor-moon-fail.jpg[/img]

ну наконец-то фото Reaper-а есть.