Синхронизация проекта 1C:EDT с хранилищем конфигурации
Как устроена синхронизация: взгляд изнутри
Чтобы понять, почему стандартные инструкции из справки не спасают от неожиданностей, нужно заглянуть под капот. EDT работает не с базой данных метаданных, а с файловой моделью проекта. Хранилище конфигурации (классическое или файловое) оперирует версиями объектов в двухуровневой схеме («захват–фиксация»). Синхронизация – это согласование двух разных моделей.
Два мира: EDT и классическое хранилище
| Характеристика | Классический конфигуратор | EDT (Eclipse-based) |
|---|---|---|
| Единица хранения | Объект метаданных (один XML‑файл на объект) | Файлы проекта (распределённая структура, включая дополнительные ресурсы) |
| Контроль версий | Двухуровневый (захват – фиксация), сервер хранилища | Локальная история (Git‑подобная), синхронизация с удалённым репозиторием |
| Блокировки | Пессимистичные (захват блокирует объект для других) | Оптимистичные (конфликты разрешаются при слиянии) |
| Слияние веток | Отсутствует (только линейная история) | Поддерживается (merge, rebase через механизмы EDT) |
Разная идеология блокировок – главный источник неожиданностей. В конфигураторе разработчик привык, что захваченный объект никто не тронет. В EDT захват не блокирует других – он только помечает файл как изменённый, а конфликт возникает лишь в момент commit в хранилище.
Механизмы блокировок и версионирования
При выполнении команды Синхронизировать с хранилищем EDT делает следующие шаги (упрощённо):
- Получает текущую версию хранилища (номер ревизии).
- Для каждого изменённого файла проекта вычисляет diff относительно последней синхронизации.
- Пытается применить изменения из хранилища в локальную файловую модель (pull).
- Если локальных изменений нет – просто обновляет файлы. Если есть – запускает трёхстороннее слияние (ancestor, local, remote).
- При успешном слиянии – создаёт новую локальную версию и готовит коммит в хранилище.
Обратите внимание: EDT не использует захват в смысле конфигуратора. «Захват» в EDT – это просто копия файла в локальную папку проекта с флагомchecked out. Реальная блокировка на сервере хранилища не ставится до момента попыткиcommit. Если другой разработчик в этот момент фиксирует изменения того же объекта, возникнет конфликт.
Нетривиальные ловушки при синхронизации
Ловушка 1: Состояние «Изменено» после фиксации
После успешного commit в хранилище через EDT проект часто остаётся в состоянии «Есть незафиксированные изменения», хотя файлы не менялись. Причина – EDT не обновляет метаданные о захвате для объектов, которые не были затронуты прямыми правками. Особенно это проявляется для служебных файлов расширений и подсистем.
# Пример: после коммита в хранилище через EDT
git status # внутри .project каталога
# Видим несоответствия: файлы .1c/cfg/extensions/*.xml помечены как changed
# Реально они не редактировались, но EDT переписал их при синхронизации
Что делать? После каждого commit в хранилище выполняйте clean project через меню EDT (Project → Clean…), затем повторную синхронизацию. Это пересчитывает hash‑суммы внутренних файлов и устраняет ложные изменения.
Ловушка 2: Конфликты при слиянии расширений
Расширения конфигурации в EDT хранятся как самостоятельные наборы файлов. При синхронизации они рассматриваются как отдельные «ветки». Если два разработчика одновременно меняют одно и то же расширение, механизм трёхстороннего слияния может испортить структуру подчинённых форм общего реквизита.
Типичная ситуация: разработчик А добавляет поле на форму документа в расширении, разработчик Б правит процедуру обработки проведения в том же расширении. Слияние в EDT объединит два diff-файла, но если затронут общий родитель (например, сама форма), результат может содержать синтаксически некорректный XML.
Профилактика: перед синхронизацией используйте команду Compare with... в контекстном меню файла. Если в расширении более 3
Попробовать НОПик →