Closed Dumsik closed 7 years ago
dmpas
commented
7 years ago изменение версии конфигурации производиться только разработчиками 1с
Очень неверное допущение. Много кто версионирует по-своему. Если уж не отдельный пользователь, то лучше, мне кажется, вбивать специфический комментарий метки и по нему менять автора.
theshadowco
commented
7 years ago Лучше отдельного пользователя завести
Dumsik
commented
7 years ago Вы не поняли, я же написал что если Вы не задаете пользователя в специальном параметре, то автором будет пользователь хранилища, т.е. хотите будет механизм алтернативного автора работать хотите нет (если вы версионируете сами). Вариант с меткой не удобен т.к. зависит от людей. Забыл поставить метку / ошибся и все улетело в git не так как нужно. А версия от пользователя не зависит.
artbear
commented
7 years ago Изменение версии также зависит от процесса разработки и от людей. Часто меняются версии даже для типовых конфигураций
Схема привязки к версии не универсальна :)
Пока видны 2 нормальных варианта:
В последнем случае даже ваш процесс не сильно поменяется, да и в гитсинке ничего не нужно менять. Серьезное изменение пусть проходит от имени пользователя-вендора
Dumsik
commented
7 years ago •сделать отдельного пользователя.
Думал про это, ну так не хочется усложнять процесс :(. Объяснять разработчикам, что для накатывания обновления от 1с мы в хранилище заходим под другим пользователем .... Я понимаю что мой процесс сильно не изменится, но с отслеживанием версии он вообще не изменится и уверен, что 90% разработчиков которые допиливают конфы на поддержке никогда не меняют номер версии сами, а только при обновлении от 1с, а уже если вы меняете версии сами тогда используйте отдельного пользователя. Метки вообще не вариант т.к про них вечно будут забывать, проверено на практике :).
dmpas
commented
7 years ago Объяснять разработчикам, что для накатывания обновления от 1с мы в хранилище заходим под другим пользователем
объяснять разработчикам, что git blame покажет, что это именно их косяки, а не 1с :) и на претензии "я обновление ставил" отвечать "пфффффф, ничо не знаю - вот тут всё написано".
я б так делал.
Dumsik
commented
7 years ago И все таки вопрос к @EvilBeaver, если я сделаю эту доработку и вышлю pull request, Вы его примите ?
Dumsik
commented
7 years ago После раздумий решил накатывать обновления от 1с от имени специального пользователя т.к. тогда и в истории хранилища будет видно что этот коммит от 1с.
EvilBeaver
commented
7 years ago Я не единоличный владелец gitsync и обещать не могу. Большинство доработок я принимаю, но вообще зависит от доработки. Если все будут против - то не приму. Просто потому, что "а с фига ли я принял если все против"
EvilBeaver
commented
7 years ago Сама идея и польза от нее мне ясна. Одобряю
EvilBeaver
commented
7 years ago Вариант с меткой мне кажется оптимальным. Если метка версии равна "@author=1C" то автором коммита будет 1С
ghost
commented
7 years ago Мы сейчас делаем так
так как адрес короткий и обезличенный - blame показывается красиво
P.S. Подобное подход реализовал @pumbaEO и описал в статье https://infostart.ru/article/ispolzovanie-git-dlya-dorabotki-tipovykh-konfiguratsiy-1s-553119/
Есть не приятный момент при подключении к git конфигурации которая находится на поддержке и помимо собственных доработок еще обновляется релизами 1с. Дело в следующем: При обновлении на новый релиз от 1с в хранилище 1с он записывается от имени того разработчика, который делал обновление и следовательно при синхронизации через gitsync автором всех изменений будет считаться этот разработчик, что сами понимаете не очень отражает действительность и мешает работать т.к. blame и история файлов показывают не реального автора.
Предлагаю следующее решение этой проблемы. В хранилище 1с хранится номер версии конфигурации, если принять за допущение, что изменение версии конфигурации производиться только разработчиками 1с то нам достаточно при синхронизации сравнивать номер текущей версии конфигурации (не путать с версий хранилища) с номером сохраненным ранее и если они не равны, автором считать пользователя GIT указанного в специальном параметре скрипта. Если такой пользователь не задан, то автором считается пользователь хранилища.
Если я сделаю эту доработку и вышлю pull request, Вы его примите ?