Как удалить ошибочные изменения из хранилища конфигурации 1С и вернуть объекты к исходному состоянию

В процессе коллективной разработки возникают ситуации, когда в хранилище конфигурации попадают некорректные или нежелательные изменения — для управления этими процессами есть автоматизация управления версиями и процессами сборки 1С. Особенно критично это становится, когда затронуты базовые объекты метаданных, такие как ПланСчетов, ПланВидовХарактеристик или сложные регистры, и эти изменения еще не успели попасть в рабочую (продуктивную) базу. Если просто "проигнорировать" проблему, рано или поздно при обновлении рабочей конфигурации из хранилища данные будут испорчены. Рассмотрим подробно, как можно «вычистить» хранилище от ненужных версий и вернуть объекты в эталонное состояние.

Метод 1: Радикальный откат до конкретной версии

Этот способ является самым быстрым, если нужно «стереть» всю историю изменений, начиная с определенного момента. Команда «Откатить до версии» фактически удаляет из базы данных хранилища все записи, сделанные после выбранного номера версии. Проанализируем, как правильно выполнить эту операцию.

1. Подготовка и блокировка сессий. Это критически важный этап — поможет обработка принудительного завершения сеансов пользователей. Перед откатом необходимо убедиться, что все разработчики сохранили свои изменения локально, захваченные объекты помещены в хранилище (или их захват отменен), и все пользователи закрыли конфигураторы. Если в хранилище будет активна хотя бы одна чужая сессия, система выдаст ошибку блокировки.
2. Открытие истории. Перейдем в меню Конфигурация — Хранилище конфигурации — История хранилища.
3. Выбор точки отката. В открывшемся списке найдем последнюю «здоровую» версию (ту, в которой план счетов или другой объект еще не был испорчен).
4. Выполнение команды. Выделим эту версию, нажмем кнопку Действия и выберем пункт Откатить до версии.

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

Метод 2: Выборочное восстановление объекта через сравнение

Рассмотрим ситуацию, когда нам нужно исправить только один конкретный объект (например, ПланСчетов.Хозрасчетный), не затрагивая изменения других программистов в других частях системы — для этого пригодится архитектурный анализ метаданных и зависимостей 1С. Это наиболее безопасный и «хирургический» метод.

Разберем алгоритм действий по шагам:

1. Захват объекта. В дереве метаданных захватим проблемный объект в хранилище.
2. Работа с историей. Откроем История хранилища. Найдем версию, где объект был в правильном состоянии.
3. Сравнение конфигураций. Выделим эту версию и нажмем кнопку Сравнить с конфигурацией. Откроется стандартное окно сравнения и объединения 1С — пригодится инструментарий разработчика для анализа метаданных и отладки.
4. Перенос изменений «назад». В окне сравнения мы увидим различия между «плохим» текущим состоянием и «хорошим» историческим. Нам нужно установить галочки так, чтобы конфигурация объекта стала идентичной исторической версии. Фактически, мы затираем текущие ошибки старыми правильными данными.
5. Помещение в хранилище. После объединения нажмем ОК, проверим объект в конфигураторе и выполним команду Поместить в хранилище.

В результате в истории появится новая версия, которая возвращает объект к исходному виду, при этом вся промежуточная история правок останется доступной для анализа.

Метод 3: Использование эталонного CF-файла из рабочей базы

Если в хранилище возникла массовая путаница (например, задвоились предопределенные элементы или нарушилась структура многих справочников), проще всего использовать рабочую базу как источник истины. Выясним, как правильно «заместить» данные хранилища данными из .cf файла.

Проанализируем последовательность действий:

1. Выгрузка эталона. Зайдем в рабочую (Production) базу, выполним Конфигурация — Выгрузить конфигурацию в файл... (получаем чистый config.cf).
2. Подготовка в тестовой базе. В базе, подключенной к хранилищу, захватим все объекты, которые требуют исправления (или вообще всю конфигурацию целиком, если масштаб бедствия велик).
3. Загрузка файла. Выполним Конфигурация — Загрузить конфигурацию из файла.... Система предложит заменить текущую конфигурацию конфигурацией из файла. Соглашаемся. Внимание: используем именно «Загрузить», а не «Сравнить и объединить», чтобы полностью исключить дублирование объектов.
4. Обновление хранилища. Поместим измененные объекты обратно в хранилище. Теперь состояние объектов в хранилище полностью соответствует рабочей базе.

Метод 4: Административное обслуживание файла хранилища

Иногда простого удаления версий недостаточно. Если в хранилище по ошибке поместили тяжелые файлы, макеты или картинки, размер файла базы данных хранилища (1cv8ddb.1cd) может сильно вырасти, что замедлит работу всех разработчиков. Даже после отката версии физический размер файла может не уменьшиться.

Для оптимизации воспользуемся функцией сокращения истории (поможет инструмент управления сеансами и блокировками баз 1С):

1. Зайдем в меню Администрирование — Хранилище конфигурации — Администрирование.
2. На вкладке История воспользуемся кнопкой Сократить.
3. Укажем версию, ранее которой история нам больше не нужна.

Это позволит физически очистить базу данных хранилища от старых ненужных данных.

Использование командной строки для автоматизации

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

"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /ConfigurationRepositoryF "C:\Repo1C" /ConfigurationRepositoryN "Admin" /ConfigurationRepositoryP "Password" /ConfigurationRepositoryDump "C:\Backup\repo_backup.cf"

Здесь параметр /ConfigurationRepositoryF указывает путь к папке хранилища, а /ConfigurationRepositoryDump позволяет выгрузить состояние хранилища в файл, не запуская интерактивную сессию.

Краткие выводы и рекомендации

Подводя итог, выберем оптимальную стратегию:

• Если ошибка замечена сразу и никто больше ничего не делал — используем Откат до версии.
• Если нужно исправить один объект, сохранив работу коллег — используем Сравнение с версией из истории.
• Если хранилище «рассыпалось» и проще вернуть всё как в рабочей базе — используем Загрузку конфигурации из CF-файла.

И самое главное правило: перед любыми манипуляциями с хранилищем (особенно перед откатом) всегда делайте копию папки, в которой лежит файл 1cv8ddb.1cd. Это ваш единственный надежный способ восстановить всё назад, если административные действия пойдут не по плану.