Данная статья является не столько информативной для других, сколько заметкой для себя. Но, возможно, поможет кому-то разобраться в проблеме.
Итак, имеем: Ведется разработка тиражного продукта командой из 4 разработчиков трое работают через хранилище, один (я) через EDT. Из хранилища в удаленный репозиторий настроена трансляция с использованием 1С:Гитконвертер.
Один из разработчиков решил тоже перейти на разработку в EDT. Скачал, установил актуальную версию, клонирует репозиторий, и... Проектный контекст не активируется. Предположили, что проблема в клиенте под macOS (т.к. использовался MacBook) решили проверить то же самое под Windows - эффект аналогичный. Вместо конфигурации, в навигаторе видим содержимое каталога локального репозитория
Решаю провести эксперимент и развернуть проект на своем ноутбуке (под Windows) - проблема повторяется. При этом, на мой стационарный ПК проект клонируется и открывается без проблем. (Наверно, стоит отметить, что на стационарном компьютере я немного экспериментировал с разработкой на Java, по этому настройки могут отличаться от стандартных, это единственное, что сейчас приходит в голову..)
Что ж, начинаем изучать проблему, для этого открываем перспективу "Журнал ошибок" в EDT и видим там проблемные места:
Первое, что бросается в глаза - java.lang.NumberFormatException: For input string: "version"
Но никакого криминала в версии конфигурации нет, классические 4 числа, через точку.
Далее, хочется сказать спасибо Constantine Manaev из официального ТГ-чата по EDT, который обратил внимание на DistributionSupportFileDeserializer
Также, Константин предложил временно, для эксперимента, попробовать удалить файл src/Configuration/ParentConfigurations.bin и папку src/Configuration/ParentConfigurations.
Тут надо отметить, что конфигурация стоит на поддержке:
- БиблиотекаСтандартныхПодсистем (3.1.5.385)
- БиблиотекаТехнологииСервиса (2.0.6.34)
- БиблиотекаИнтеграцииС1СДокументооборотом (1.1.18.5)
- БиблиотекаФункциональныхПодсистем1ССовместно (2.4.12.1)
И т.к. разрабатывается типовая конфигурация и большая часть разработки ведется через хранилище, полностью отказаться от механизма поддержки мы пока не можем.
Что ж, пробуем удалить указанные файлы из локального репозитория, перезапускаем EDT, и проект активируется:
(Дисклеймер: Скрины делались в разное время - какие-то по ходу проверок, какие-то уже для статьи, поэтому где-то тема тёмная, а где-то светлая :) )
Итак, причина найдена. Но повторюсь, отказаться от поддержки пока нельзя, и если удалить файлы из удаленного репозитория, Гитконветрер может прислать их в одном из будущих коммитов.
Собственно, обход проблемы (все то же самое можно делать и через консоль или другие инструменты, тот же VSCode, например, но я буду описывать вариант решения через интерфейс EDT, мы ж 1С-ники, консоль не уважаем, пользуемся только своими инструментами XD )
Вспоминаем о таком чудесном файле в гите как ".gitignore", который позволяет нам настроить какие файлы не будут попадать в индекс, а соответственно, будут игнорироваться гитом. Задействуем эту механику.
С начала, нам надо удалить файлы в удаленном репозитории, синхронизируем локальный репозиторий с удаленным и в EDT переходим в перспективу Git
В этой перспективе мы можем перейти к рабочему каталогу и удалить из него файлы, изменение попадет в индекс, мы можем его закоммитить и отправить в удаленный репозиторий
Далее, надо создать файл .gitignore и прописать в него, какие файлы должны игнорироваться при следующих коммитах. Но тут стоит признаться, что я не разобрался, как создать файл в Рабочем каталоге из интерфейса гита, по этому сам файл создал в файловой системе. А вот его содержимое уже можно отредактировать в EDT и тогда файл будет проиндексирован, при сохранении и его можно будет отправить коммитом в удаленный репозиторий.
Собственно, после этих манипуляций, попробовал внести несколько изменений в конфигурацию через хранилище, менял модули, добавлял и удалял метаданные, менял свойства конфигурации - все это было отправлено в удаленный репозиторий, но "плохие" файлы, ожидаемо, не были помещены. (Конечно, пока, не выполняли обновление конфигураций на поддержке которых находится продукт, может еще из-за этого что-то пойдет не так, но в целом уже знаем как решить проблему, будем готовы)
На этом, проблему считаем решенной. Регистрируем ошибку EDT и ждем нового релиза.
