Как очистить конфигурацию 1С от служебных комментариев слияния MRG и упростить обновление?

При сопровождении и обновлении нетиповых или доработанных баз 1С программисты нередко сталкиваются с ситуацией, когда весь программный код модулей оказывается переполнен служебными блоками комментариев вида //{{MRG[ <-> ]. Подобные артефакты могут занимать десятки тысяч строк, дублируя типовой код и скрывая реальные доработки конфигурации. Разберем по шагам, откуда берутся эти метки, как они влияют на процесс поддержки и какими способами можно быстро очистить конфигурацию.

Причины появления меток MRG в программном коде

Выясним причину возникновения подобных комментариев. Блоки //{{MRG формируются встроенным механизмом платформы 1С при выполнении процедуры объединения конфигураций, если для модулей был выбран режим Объединять с приоритетом основной конфигурации или Объединять с приоритетом конфигурации поставщика.

Посмотрим на пример такого блока:

//{{MRG[ <-> ]
//    Если (ПустоеЗначение(ОсновнаяЕдиница) = 1) ИЛИ (ОсновнаяЕдиница = БазоваяЕдиница) Тогда
//        // обновим основную единицу
//}}MRG[ <-> ]

Стрелки внутри меток указывают на источник различий в объединяемых версиях:

1. //{{MRG[ <- ] — фрагмент из основной (текущей) конфигурации базы данных;
2. //{{MRG[ -> ] — фрагмент из объединяемой конфигурации (файла обновления поставщика);
3. //{{MRG[ <-> ] — фрагмент, содержащий конфликты или изменения в обоих сравниваемых источниках.

Платформа формирует эти блоки как временную разметку, чтобы программист мог вручную сопоставить строки кода после автоматического объединения. Однако если разработчики регулярно накатывают обновления через объединение и не вычищают отработавшие блоки, конфигурация обрастает слоями дублирующего закомментированного кода.

Влияние мусорных комментариев на дальнейшие обновления

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

1. Окно сравнения и объединения перегружается ложными конфликтами — модули помечаются как дважды измененные, даже если реальная логика в них на 100% типовая.
2. Фильтрация по дважды измененным объектам теряет смысл, так как в список попадают сотни типовых процедур с комментариями.
3. Трудоемкость обновления возрастает в разы, так как программисту приходится вручную искать единичные полезные доработки среди тысяч строк мусора.

Способ 1. Пакетная очистка через выгрузку в файлы

Рассмотрим подробнее способ быстрой автоматической очистки кода для платформы 1С 8.3 через работу с исходными текстами конфигурации. Разберем порядок действий:

1. Открываем конфигуратор и выполняем команду Конфигурация → Выгрузить конфигурацию в файлы в пустой рабочий каталог.
2. Используем скрипт (например, на Python, PowerShell или Bash), который проходит по всем файлам с расширением .bsl и удаляет многострочные блоки от открывающего тега //{{MRG до закрывающего //}}MRG вместе с их содержимым.
3. Проверяем синтаксическим контролем выгруженные файлы при необходимости.
4. Возвращаемся в конфигуратор и загружаем очищенные исходники через команду Конфигурация → Загрузить конфигурацию из файлов.

Способ 2. Восстановление через эталонный файл конфигурации поставщика

Если реальных доработок в конфигурации немного, наиболее надежным способом является восстановление типового кода из эталонного файла .cf того же релиза, который сейчас установлен в базе. Разберем по шагам этот алгоритм:

1. Находим чистый файл конфигурации поставщика (.cf) в точности того же релиза, что и текущая рабочая база.
2. Выполняем сравнение текущей конфигурации с чистым .cf через меню Конфигурация → Сравнить, объединить с конфигурацией из файла.
3. В окне сравнения анализируем модули. Для объектов, где отличия состоят только из меток //{{MRG и дублирующих строк, устанавливаем режим объединения Взять из файла (замещение). Это мгновенно возвращает модуль к исходному чистому состоянию поставщика.
4. Для модулей, где содержатся реальные пользовательские доработки, переносим полезный код вручную или через инструменты трехстороннего слияния, не перенося служебные блоки.
5. Применяем объединение и сохраняем конфигурацию базы данных.

Способ 3. Использование внешних утилит трехстороннего сравнения

Когда конфигурация содержит большой объем сложных доработок, рекомендуется использовать внешние инструменты слияния (например, KDiff3, Beyond Compare или WinMerge):

1. Выгружаем в отдельные каталоги три версии: чистую старую конфигурацию поставщика, текущую рабочую базу и новую конфигурацию поставщика.
2. В настройках внешней программы сравнения настраиваем игнорирование комментариев или регулярные выражения для фильтрации блоков //{{MRG.
3. Выполняем наглядное слияние, в котором будут подсвечены исключительно значимые алгоритмические различия без шума от старых обновлений.

Рекомендации по предотвращению проблемы

Чтобы избежать повторного появления мусорных комментариев при последующих обновлениях, придерживаемся следующих правил разработки:

1. Не применять режим Объединять с приоритетом для типовых модулей без доработок — такие объекты всегда следует обновлять замещением (режим Взять из конфигурации поставщика).
2. Сразу после применения объединения в доработанных модулях удалять блоки //{{MRG, оставляя только итоговый рабочий вариант алгоритма.
3. По возможности выносить доработки типового функционала в расширения конфигурации (Cfe), подписки на события или отдельные нетиповые общие модули, оставляя типовой код поставщика нетронутым.