oscript-library / oscript-library/gitsync
При синхронизации с хранилищем выгружаются неправильные версии файлов
Nobody has claimed this yet.
- Dominant language
- 1C Enterprise
- Stars
- 333
- Forks
- 98
- PR merge metrics
- No merged PRs in 30d
Description
Описание ошибки
Суть проблемы:
- разработчик Вася что-то поменял в своем захваченном объекте, например общий модуль ВажныеФункции.bsl, ну и сохранил у себя в конфигурации
- другой разработчик (пусть будет Лёха) в тот момент что-то помещал в хранилище - регистр бухгалтерии "ДляРасчетаЭлектромолотков"
(очень важно: разработчик Вася свой объект вообще не клал в хранилище, только сохранил у себя в тестовой базе конфигурацию)
После этого в хранилище появляется одна запись:
| N | Автор | Комментарий | Изменения |
|---|---|---|---|
| 25 | Лёха | Поправил регистр | ✏️ РегистрБухгалтерии.ДляРасчетаЭлектромолотков |
НО при выгрузке gitsync в коммите (git blame) получается так что под именем Лёхи менялся общий модуль ВажныеФункции.bsl, хотя это не так.
В общем этим "Васей" был я - мои изменения появлялись в гите:
- гораздо раньше, то есть я даже их ещё не помещал в хранилище, а они уже там на пару версий раньше
- в гите они появлялись под именем другого разработчика; в git blame мои строки отображались под именем "Лёхи"
Сценарий воспроизведения
Шаги по воспроизведению:
Пробовал синхронизировать как с плагином increment так и без
gitsync --verbose --v8version "8.3.27.1508" --ib-connection "/S great-erp-server\dev_gitsync" sync --storage-user "bot_gitsync" --limit 1 --disable-auto-src --repair-quotes --rename-module --rename-form "\\файловое_хранилище" ".\src"
# далее проверьте git blame файлов которые не менялись в хранилище в конкретной выгруженной версии
Ожидаемое поведение если бы ошибки не было
В коммите "Лёхи" не было бы ещё не помещённых изменений "Васи", или же данные изменения были бы под именем Васи
Окружение:
- Версия операционной системы: Windows 10
- Редакция платформы: 8.3.27.1508
- Версия Gitsync: 3.7.0
- Версия OScript: 1.9.3.15
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the scenario with the provided gitsync command, using platform 8.3.27.1508, Gitsync 3.7.0, and OScript 1.9.3.15. Compare the storage revision with git blame for files not changed in that revision. Done means uncommitted local changes are absent from earlier exports and retain the correct author when they are exported.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git
- Domain
- devtools, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100