1c-company / gitconverter Goto Github PK

У репозитория не указана лицензия. По умолчанию все проекты без файла лицензии попадают под категорию UNLICENSED, что запрещает их дальнейшее использование, копирование и доработку. Хотелось бы узнать, под какой лицензией выложены данные исходники. В идеале, конечно же, что-то открытое типа APLv2, MIT, MPL и иже с ними.

На мой взляд лучше вообще всегда запускать английский вариант формирования отчета с помощью /Len /VLen и ориентироваться на него при разборе

В документации написано, что файлы по маске *.bin являютса бинарными, но это не так. Файлы XDTOPackages/*/Ext/Package.bin являютса текстовыми, хоть и имеют ошибочное расширение bin.

Или задать вопросы разработчикам EDT...

При создании нового хранилища из GitConverter оно никак не синхронизировано с удаленным, поэтому первая же команда pull приведет к ошибка.
На мой взляд более правильным было бы опциональное использование удаленного хранилища (сейчас без него вообще ничего работать не будет). Соответственно пользователи которым оно нужно сами способны выполнить синхронизацию

На самом деле вопрос даже шире. Какие должны быть настройки для инкрементного обновления репозитария Git и установленном флаге "Использовать очереди выполнения"? По идее фоновое задание конвертации нужно запускать только для запуска процесса и далее при появлении новых версий в хранилище 1С. По факту без постоянного запуска задания конвертации не получаются новые версии и не выполняются коммиты.

Если коммит в репозиторий завершится ошибкой (не будет выполнен, команда вернет результат, отличный от 0) - конвертер все равно посчитает версию успешно выгруженной, коммит успешно выполненным и перейдет к выгрузке следующей версии. Хотя коммитов в репозитории git не будет вообще

Как воспроизвести:

1. На системах Windows
2. Убедиться, что core.longpaths отключен (равен false)
3. Поместить в хранилище объект конфигурации с очень длинным именем
4. Запустить выгрузку в конвертере

У меня коммит падал с ошибкой "filename is too long", полный путь к файлу был примерно 320 символов

Если в конфигурации поддерживается несколько веток, необходимо иметь возможность указывать версию EDT для конвертации.

Проблема связана с тем, что при переходе на новую версию платформы необходимо обновлять и версию EDT, после чего требуется выполнить проверку корректности перехода. Хотелось бы избежать проверки для веток, которые работаю на старых версиях платформы.

Реализация улучшения будет выполнена в виде расширения и доработок конфигурации.

Что измениться в конфигурации:

1. В процедуре КонвертацияХранилища.ИмпортироватьВерсиюВEDT формирование переменой СтрокаКоманды будет вынесено в отдельную функцию;

Что будет содержать расширение:

1. В справочник ХранилищаКонфигураций будет добавлен реквизит ВерсияEDT
2. В модуле КонвертацияХранилища будет переопределена процедура формирования СтрокаКоманды. При установке значения переменой будет учтена версия EDT.

что-то я туплю, но как загрузить это добро в конфигуратор, если нет Configuration.xml?

Это запланированное поведение?

В общем на платформе 8.3.10.2753 следующий командный файл не проверяет наличие изменений, а тупо выгружает все. На 8.3.11.3034 такой проблемы нет, поэтому можно смело повышать требование к платформе для опции "Выгружать изменения":
DESIGNER /DisableStartupDialogs
/F "d:\base\15\db"

/DumpConfigToFiles "d:\base\15\dump" -update -force -getChanges "d:\base\15\diff.txt" -configDumpInfoForChanges "d:\base\15\PreviousState.xml"
/DumpResult "d:\base\15\result.txt"
/Out "d:\base\15\log.txt" -NoTruncate

Существует проблема
В процессе разработки существует необходимость менять версии Платформы (в т.ч. версию сервера Хранилищ 1С), при этом есть ограничение со стороны EDT - что версии поддерживаются не все, а только выпущенные на момент выпуска EDT. Сейчас необходимо версию выгрузки в xml и версию Платформы сервера хранилищ 1С держать одинаковой.
В некоторых случаях, команда разработки хотела бы использовать сервер на версии Платформы который EDT не поддерживает, при этом конфигурация в хранилище находится в режиме совместимости с поддерживаемой EDT версией Платформы.

Хотелось бы иметь следующую функциональность
Позволяющую выгружать в xml и конвертировать в формат EDT на одной версии платформы, а сервер хранилищ 1С на другой. Контроль совместимости версий в хранилище 1С будет выполнять сама Платформа.

Расширение или улучшение?

Это функциональность можно реализовать в расширении.

Проверка запущено ли фоновое задание видимо использует некорректный отбор:

Метода "ОбщегоНазначенияКХ.ВыполнитьКонвертацию" в текущей версии не существует

Доброго времени суток!

Хотелось попробовать сконвертировать конфигурацию в формат EDT. Для теста развернул локальную базу GitConverter и столкнулся с неожиданной проблемой.
В описании указано, что для начала разбора нужно заполнить константу "Путь к версиям платформы на сервере". Т.к. для проверки выполняю все операции в тестовом режиме с локальной файловой базе, то и путь указал к локальному каталогу, где у меня установлены все версии платформы: "D:\Program".
При попытке запустить разбор данных, система падает с ошибкой на этапе попытки создания локальной файловой базы. Место ошибки и входные параметры на скриншоте:

Выполняется попытка выполнить строку:
ЗапуститьПриложение(СтрокаКоманды, Параметры.КаталогИсполняемогоФайла, Истина, КодВозврата);
При этом путь к исполняемому файлу не достроен корректно.
К общему каталогу установленных платформ "D:\Program" добавлен подкаталог "1cv8" и все, на этом сборка пути окончена. Хотя я ожидал, что будет собран полный путь к исполняемому файлу, с учетом указанной в настройках хранилища версии платформы.
Т.е. должен был получиться вот такой путь:
"D:\Program\1cv8\8.3.10.2252\bin\1cv8.exe".
И как следствие получаю ошибку вида:

Подскажите. возможно я что-то упустил и настроил неверно?
Но судя по коду я не нашел использования версии платформы при построении пути к исполняемому файлу.. да и собственно этот путь никак не строится.

Существует проблема
Потребовалось мне поменять адрес удалённого хранилища, без изменения каталога локального. Простым нажатием кнопки прописать адрес хранилища (см. снимок) - не прокатывает. В файле конфигурации локального репозитория остаётся старый, в логе ошибка: "fatal: remote origin already exists." , но поскольку код возврата установки репозитория тоже не анализируется (даже в текущей версии) - кто бы туда глянул.

Хотелось бы иметь следующую функциональность
Надо бы сначала его сносить командой: git remote remove origin. Да и анализ результата выполнения команды установки удалённого хранилища тоже очень не плохо было бы добавить.

Дополнительный контекст
https://partners.v8.1c.ru/forum/t/1781195/m/1781340

Сейчас флажок Выгружать изменения становится виден только когда включена опция ИспользоватьОчередиВыполнения. В результате пользователь может упустить из виду эту возможность.

Предлагаю реквизит Выгружать изменения исключить из состава ИспользоватьОчередиВыполнения, и делать соответствующий флажок недоступным, если ИспользоватьОчередиВыполнения отключена.

Добавить к этому флажку подсказку о том, что для её использования следует включить опцию ИспользоватьОчередиВыполнения и пояснение, что данная опция ускоряет процесс конвертации.

Было бы удобно при конвертации переносить в git и метки хранилища.
Можно в виде git tags, можно в виде комментариев к коммитам

Насколько я помню проблема в том, что отчет по хранилищу не включает информацию по меткам? Последний раз когда смотрел получить их не удавалось программно

Хочется иметь параллельную выгрузку в git оригинальной и конвертированной в EDT версии в две разные ветки.

• Перевод на платформу 8.3.12
• Перевод на EDT 1.8
• Переход на конвертацию в формат EDT (конвертация в формат выгрузки 1С:Предприятия поддерживается в режиме совместимости для существующих настроек)

Словили такую ошибку при конвертации хранилища:

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

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

Отсутствует возможность не конвертировать в формат EDT.

Проблемы две:

1. CR без LF. Файлы с такой ошибкой не попадают в индекс
2. LF без CR. При рекомендуемых настройках возникает ошибка "fatal: LF would be replaced by CRLF"
   Я после каждого получения данных из хранилища запускать скрипты на Python которые это фиксят

Сейчас в форме элемента справочника ХранилищаКонфигураций установлен признак обязательного заполнения для полей Пользователь и Пароль. При использовании авторизации по ssh-ключу, эти поля не требуются.

При попытке импортировать проект согласно примерам с ИТС https://its.1c.ru/db/edt16doc#content:267:hdoc проект не определяется, как 1Сный.

Возможно это связано с отсутствием файла GitConverter/.project и с его игнорированием. После добавления этого файла проект был успешно импортирован и запущен.

Для удобства заполнения соответствия пользователей
Я хочу чтобы система подсказывала мне какие пользователи есть в хранилище
И позволяла интерактивно заполнить это соответствие

Сейчас заполнение соответствия пользователей полностью ручное: добавил элемент, заполнил, записал, добавил, заполнил, записал. Для заполнения нужно знать какие пользователи есть в хранилище, а для этого - самостоятельно строить отчет по хранилищу, сворачивать по пользователям, переносить эту информацию в конвертер.

Было бы удобно, если Конвертер предоставлял удобный мастер заполнения соответствия пользователей: сам построил и прочитал отчет по хранилищу, показал какие пользователи есть, каких нет и дал удобный интерфейс заполнения соответствия в одном окне

Сейчас в файлах логов не хватает данных о времени, когда выполнялись операции.
Приходится смотреть время самих файлов.

Перестали приходить коммиты на github, стал копать, оказалось, что ошибка авторизации, однако в git_log_ver_х.txt этого нет. Выяснил запустив из command line батник git_command_х.bat.
Кстати в версиях хранилища статус "Версия помещена", на внешний вид все ок, однако коммитов нет

Если в списке регламентных заданий удалить вручную регламентное задание по конвертации - после этого невозможно будет открыть форму элемента хранилища

При просмотре истории изменений в файле в каком-нибудь Git-клиенте не хватает версии конфигурации в которой было выполнено то или иное изменение
Брать ее придется видимо из Configuration.xml

Если создать вручную отчет по хранилищу в базе, локализация которой отличается от "русский"
И загрузить отчет по хранилищу в Конвертер
Тогда у версий будет отсутствовать дата создания

Английская локализация:

Русская локализация:

Судя по всему алгоритм чтения даты версии заточен только под российский формат. Это нормально работает при автоматической загрузке отчета т.к. там используются флаги /L ru /VL ru, а вот ручная просто "молча" создает версии с пустыми датами.

https://github.com/1C-Company/GitConverter/blob/6f100e3/GitConverter/src/Catalogs/%D0%92%D0%B5%D1%80%D1%81%D0%B8%D0%B8%D0%A5%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B0/ManagerModule.bsl#L220-L224

Словили такую ошибку при выгрузке ~200й версии из хранилища:

в журнале регистрации записи на 2 строки кода:

https://github.com/1C-Company/GitConverter/blob/c482b38/GitConverter/src/CommonModules/%D0%9A%D0%BE%D0%BD%D0%B2%D0%B5%D1%80%D1%82%D0%B0%D1%86%D0%B8%D1%8F%D0%A5%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B0/Module.bsl#L2513

https://github.com/1C-Company/GitConverter/blob/c482b38/GitConverter/src/CommonModules/%D0%9A%D0%BE%D0%BD%D0%B2%D0%B5%D1%80%D1%82%D0%B0%D1%86%D0%B8%D1%8F%D0%A5%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B0/Module.bsl#L2596

в log.txt:

10/16/2018 8:39:34 AM Начало создания базы.
Создание информационной базы ("File="C:\g\report_db\";Locale = "en_US";") успешно завершено
10/16/2018 8:39:35 AM Окончание создания базы.
Код возврата: 0, Код результата: 0
10/16/2018 8:39:35 AM Начало формирования отчета по хранилищу.
Ошибка при создании объекта c IID - 332c4425-26cb-11d0-b483-00c04fd90119
[helpui - src\helpmiscUI.cpp (636)]
10/16/2018 8:39:36 AM Окончание формирования отчета по хранилищу.
Код возврата: 1, Код результата: 0

Что это такое? Из-за чего может происходить?

Допустим в хранилище конфигурации 10 версий
И я созданию настройку синхронизации в GitConveter
И в поле "Первая версия" указываю 5

Я ожидаю что выгрузятся версии 5, 6, 7, 8, 9, 10
А на самом деле выгрузятся версии 6, 7, 8, 9 , 10, версия 5 будет отсутствовать в выгрузке

После удаления ИБ версии, она не удаляется из списка ИБ.
Кстати зачем они вообще в список добавляются? Единственная причина - кэш. Вы проверяли, он действительно имеет смысл для данной задачи?

Если сформировать отчет по версиям вручную в базе, локализация которой отличается от "русский", при загрузке этого отчета "вручную" (кнопкой на форме элемента справочника "Хранилища конфигурации") номера версий будут пустыми

Английская локализация:

Русская локализация:

Видимо алгоритм чтения даты версии "заточен" только под российский формат. Это нормально когда отчет формируется автоматически (там корректно передаются флаги запуска /L ru /VL ru), но ручная загрузка не умеет обрабатывать отчеты других локализаций

https://github.com/1C-Company/GitConverter/blob/6f100e3/GitConverter/src/Catalogs/%D0%92%D0%B5%D1%80%D1%81%D0%B8%D0%B8%D0%A5%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B0/ManagerModule.bsl#L220-L224

Существует проблема
Для выгрузки изменений текущей версии необходимо подставлять файл состояния объектов предыдущей версии. Файл ConfigDumpInfo.xml до 8.3.15 можно было получать только выгрузив предыдущую версию.

Это накладывает ограничение: все версии должны выгружаться строго последовательно, иначе версия будет быть выгружена полностью, что не хорошо и нагружает процессор излишне, тратится лишнее время.

Хотелось бы иметь следующую функциональность
Использование новых возможностей выгрузки Платформы 8.3.15.

• -configDumpInfoOnly ‑ указанием данного параметра приводит к тому, что при выгрузке формируется только файл версий (ConfigDumpInfo.xml). Если в командной строке будет указан параметр -format, то файл версии будет сформирован для указанного формата выгрузки. По умолчанию файл версий формируется для иерархического формата выгрузки.

При получении версии из хранилища - можно выгружать файл ConfigDumpInfo.xml с помощью нового колюча -configDumpInfoOnly - это позволит завести несколько версий выгрузки и выгружать только изменения "по-честному" параллельно.

Так же можно будет выгружать изменения не используя "Очереди выгрузки" (снимается ограничение)

Расширение или улучшение?

Это улучшение конфигурации 1С:ГитКонвертер улучшает конвертацию на новой платформе 8.3.15.

Т.к. новые возможности будут доступны только начиная с 8.3.15 - возможно стоит сделать специальное расширение которое позволит делать выгрузку ConfigDumpInfo.xml на версии 8.3.15 и продолжить выгрузку на более низких версиях. Нужно учесть что заголовке xml прописывается версия формата, которую невозможно загрузить на младших версиях - нужно сделать фикс версии если формат не поменялся.

Допустим мы разрабатываем на EDT и храним код в git.
Как нам автоматизировать сборку конфигурации из формата EDT? Какие инструменты и команды нужны?

При использовании выгрузки в файлы понятно как - у конфигуратора есть команда /LoadConfigFiles. Но формат хранения EDT же вроде другой? Как из этого формата собирать конфигурации на CI/CD серверах? Что использовать и где про это почитать подробнее?

Конвертация остановилась на 288 версии со следующей ошибкой:

10/24/2018 1:21:39 AM Начало создания базы.
Создание информационной базы ("File="C:\g\288\db\";Locale = "en_US";") успешно завершено
Информационная база с указанным именем или параметрами соединения уже зарегистрирована

С чем это связано? Предыдущие версии выгружались без проблем

Сейчас нет возможности редактировать наименование элемента справочника "Хранилища конфигурации". Оно заполняется автоматически адресом хранилища при записи объекта

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

Было бы удобно дать возможность редактировать наименование элемента справочника.
Вывести наименования в формы элемента, списка и выбора
При записи если наименование не заполнено - заполнять значением из реквизита "Адрес"

Если путь к хранилищу больше 120 символов, то на PostgreSQL не запускается задание конвертации.
Длинное название может быть из-за расположения хранилища в сети.

Проблема в том, что длина имени задания в PostgreSQL ограничена. И при попытке создать задание - ошибка.

Решили проблему таким образом:

1. В Модуле объекта справочника "ХранилищаКонфигурации" в процедуре "ПередЗаписью" заменили строку

   GitConverter/GitConverter/src/Catalogs/ХранилищаКонфигураций/ObjectModule.bsl

   Line 29 in 21fcba3

   ПараметрыЗадания.Вставить("Наименование", НСтр("ru = 'Конвертация хранилища'") + ": " + СокрЛП(Адрес));

   
   на:

ПараметрыЗадания.Вставить("Наименование", НСтр("ru = 'Конвертация хранилища'") + ": " + СокрЛП(Прав(Адрес, 100)));

2. В Модуле объекта справочника "ХранилищаКонфигурации" в процедуре "ПриЗаписи" заменили строку
   

   GitConverter/GitConverter/src/Catalogs/ХранилищаКонфигураций/ObjectModule.bsl

   Line 93 in 21fcba3

   НаименованиеЗадания = НаименованиеЗадания + СокрЛП(Адрес);

   
   на:

НаименованиеЗадания = НаименованиеЗадания + СокрЛП(Прав(Адрес, 100));

1. Команды в линукс регистрозависимые, поэтому необходимо cd
2. Для windows необходимо добавить ключ /D для возможности смены диска.

#7

Видим, что 1С:Предприятие запускается с параметрами из txt-файла. Открываем его содержимое и видим, что логи при этом сохраняются в папку, которую мы указали как Каталог выгрузки версий, а сам файл называется log.txt. Содержимое файла подскажет, что пошло не так в процессе запуска конвертации.

Для обхода ошибки нужно заполнить поле ВерсияПлатформы
https://github.com/1C-Company/GitConverter/blob/master/GitConverter/src/Catalogs/ХранилищаКонфигураций/ObjectModule.bsl#L50

Для возможности указания параметров подключения к гит серверу можно использовать переопределение переменнй GIT_ASKPASS с указанием пути к временному файлу, который выглядит примерно так:
windows:

@set arg=%~1
@if (%arg:~0,8%)==(Username) echo  myusername
@if (%arg:~0,8%)==(Password) echo mypassw

для linux:

#!/bin/sh"
case "$1" in
Username*) echo 'myusername';;
assword*) echo 'mypassw';;
esac

Описание ошибки
Человек может ошибаться при вводе логина/пароля авторизации на гит сервере. Сейчас перед коммитом выполняется команда git pull и после коммита git push, если авторизация на сервере не правильная пуш отменяет фактически состоявшихся коммит.

При этом, ошибка авторизации при git pull никак не учитывается.

Ожидаемое поведение
Перед коммитом выполнять git pull в случае не успешности этой команды отменять дальнейшее выполнение коммита и легировать проблему.

После выполнения коммита в локальный репозиторий - помечать версию помещенной, но при ошибке git push выводить сообщение.

Для перехода разработки в 1C:EDT необходимо конвертировать репозиторий, если необходимо сохранить историю разработки.

1. Это финальная операция конвертирования - дальнейшая синхронизация Хранилища конфигураций 1С:Предприятия с Git репозитория не нужна.
2. Форматы xml EDT и выгрузки xml 1С:Предприятия в некторых случаях сильно изменены - сохранение построчной истории невозможно, сохраняется только общая история изменения файла. Отдельно можно смотреть git blame до и после конвертации.
3. Актуализация документации.

Конвертация падает с ошибкой "Ошибка преобразования значения в число", если в хранилище 1000 и более версий

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

Решение: при чтении версии из отчета хранилища удалять неразрывный пробел

Тестировалось на 8.3.12.1685

Произвел настройки согласно описанию

Скрин настроек
http://prntscr.com/hxz482

но что-то коммитов в гитхабе нет, что не так я сделал? По нажатию на "Выполнить коммиты" ничего не происходит

Есть идея автоматически добавлять метки (теги) новой версии на предыдущий коммит когда меняется версия в файле src/Configuration/Configuration.mdo - но наверное такое не всем нужно...

#55 (comment)

Опциональная включаемая возможность