Оновлення нетипових конфігурацій, або як прибрати обридлий //

Почну мабуть з того як я вчився оновлювати нетипові конфігурації і до чого мене все це призвело.

Почав оновлювати 1с ще з часів 1с 77.

Механізм поновлення в 7-ці був гранично простий. Створюємо 3 бази. 1-робоча база, 2ая - копія робочої бази, 3я - порожня типова база того ж релізу.

1ую порівнюємо новим релізом. 2ую до типового релізом. 3ю з новим релізом.

Разом в про 2Ом вікні порівняння ми бачимо все "доопрацювання" в 3ем бачимо всі зміни релізу. а в основний вирішуємо що залишаємо, а що беремо з нового релізу.

Після поновлення перевірка: робоча, оновлена ​​база порівнюється з типовими релізом. Список змін повинен бути ідентичний другий базі. Якщо це так, то оновлення зроблено вірно.

У 8ке ж все кардинально змінилося.

Починаючи з того що в одній базі зберігатися 3 і більше конфігурацій.

1 - Основна конфігурація - Та з якої безпосередньо працює програміст.

2 - Конфігурація бази даних - Ця та конфігурація, на якій працює в даний момент база даних. (Тобто якщо ви написали пару рядків в конфігураторі, то це означає що у перших основна конфігурація і конфігурація бази даних стали не ідентичні, по-друге)

3 - Конфігурація постачальника - це по суті типовий реліз.

4..n конфігурацій постачальника може бути багато, але це тема вже зовсім іншої статті.

Цей факт дозволив розробникам в одній базі реалізувати купу смакоти. Про них конкретніше:

п.1. - При оновленні в одній базі можна побачити все 3 відмінності як у 3ех базах 77, про які говорилося вище. (Відмінність типовий бази від нового релізу, "Доробки програмістів" - відмінності основний конфігурації від конфігурації постачальника, і відміну основної конфігурації від нового релізу).

п.2. - Чисто теоретично при оновленні може виникнути 3 випадки

1 випадок - об'єкт змінений тільки в базі, а в релізі не було змін даного об'єкта

2 випадок - об'єкт змінений тільки в релізі, а в базі він не відрізняється від установки постачальника

3 випадок - об'єкт змінений і там і там.

так ось в 8 ке 1-ий і 2ий випадок платформа обробляє автоматично. (Бере рішення з якої конфігурації взяти код)

1 об'єднання з пріоритетом основний конфігурації - (важливіше те що зроблено програмістами)

2 об'єднання з пріоритетом нової конфігурації постачальника - (важливіше те що зроблено в релізі)

Після оновлення в режимі об'єднання в коді залишається купа записів взятих в тег //> MRG Ось приклад шматка коду з Авансового звіту.

Наприклад в цьому місці коду зрозуміло що в релізі був доданий метод СокрЛП ();

А в цьому місці коду були доопрацювання якогось АФМ (Андропова Федора Михайловича, або ще кого-то)