Номер релиза в Gerrit, отражающий общий порядок в основной ветке?

Это дополнительный вопрос к этому обсуждению (ссылка), в которой говорится следующее утверждение:

Номер изменения Gerrit обычно генерируется монотонно, увеличиваясь по мере того, как новые изменения отправляются на рассмотрение на сервер Gerrit. Обратите внимание, однако, что, поскольку проверка кода для разных изменений может занять разное время, нет гарантии, что изменения будут применены к основной ветке по порядку (или будут применены вообще). Таким образом, возможно, чтобы изменение с большим числовым номером изменения Y вступало в силу в главной ветке перед другим изменением с меньшим числовым номером изменения X. Другими словами, в главной ветке, когда есть два изменения с номерами X и Y соответственно, и X‹Y, НЕТ гарантии, что X произойдет раньше Y.

Наша команда была перенесена из SVN, где у нас был монотонно увеличивающийся номер (номер выпуска), который может отражать общий порядок различных версий кода. В частности, мы можем сказать клиентам, что «Ваше программное обеспечение установлено в выпуске X, но мы исправили ошибку только позже в выпуске Y (Y > X). Поэтому, пожалуйста, обновите версию Y или более позднюю, чтобы получить исправление ошибки».

На основании утверждения, изложенного выше, мы не можем использовать номер смены Gerrit для этой цели. Вот мой вопрос:

Может ли Gerrit сгенерировать номер выпуска, отражающий общий порядок изменений в главной ветке?

Дальнейшее обсуждение

Я понимаю, что git сам по себе не гарантирует полный порядок в наборе коммитов. Существует только частичный порядок — у каждого коммита есть один или несколько родителей и, следовательно, предков, но два коммита J и K не могут быть ни потомком, ни предком друг друга (т. е. нет происходит до отношений между ними).

Однако с Gerrit дела обстоят иначе. Gerrit — это система, созданная на основе git для облегчения централизованного рабочего процесса. Существует единственная основная ветвь, и существует общий порядок изменений, которые интегрируются (т. е. объединяются или перебазируются) в основную ветвь. Если есть два различных изменения A и B, интегрированных в главную ветку, то либо A происходит до B, либо B происходит до A. Таким образом, это несложно реализовать. функция, которая генерирует серийный номер на основе порядка интеграции, который происходит в главной ветке. И это число будет иметь большую практическую пользу.


person leeyuiwah    schedule 23.03.2018    source источник
comment
У Геррита нет номера выпуска. Вы можете сделать это через git tag.   -  person ElpieKay    schedule 23.03.2018


Ответы (1)


Нет, Геррит не может генерировать номер версии, который может отражать общий порядок изменений в любой ветке.

Здесь у вас неправильный подход... не пытайтесь "мигрировать" процесс/процедуры, которые вы использовали в Subversion, в Git/Gerrit. Git — это другой инструмент, и его тоже нужно использовать по-другому.

Вы должны использовать теги, чтобы отметить выпуски.

Дополнительные сведения см. в разделе Git — тегирование.

person Marcelo Ávila de Oliveira    schedule 23.03.2018
comment
Спасибо за вашу точку зрения. Но считаете ли вы такой разговор разумным? Ваше программное обеспечение установлено в выпуске X, но мы исправили ошибку только позже в выпуске Y (Y > X). Поэтому, пожалуйста, обновитесь до версии Y или более поздней, чтобы исправить ошибку. - person leeyuiwah; 23.03.2018
comment
Совершенно разумно, если вы используете теги, например: Ваша установка программного обеспечения находится в выпуске v1.2.3, но мы исправили ошибку только позже, в выпуске v1.4.7. Где v1.2.3 и v1.4.7 — это теги, созданные с помощью команды git tag. - person Marcelo Ávila de Oliveira; 23.03.2018
comment
Хорошо. Я думаю, у нас просто не может быть автоматического номера выпуска. Это нормально. Потому что для конечных клиентов они используют выпущенные продукты, которые прошли наш цикл обеспечения качества (QA), поэтому ручная маркировка — это небольшие накладные расходы. Для внутренних пользователей (использующих/тестирующих сборку для разработки), я думаю, им придется использовать временную метку плюс некоторую информацию (скажем, Jenkins BUILD_ID), чтобы объяснить, что это происходит до отношений. - person leeyuiwah; 23.03.2018
comment
Если у вас есть автоматизированные сборки с использованием Jenkins, вы можете выполнить команду git описать, чтобы сохранить удобочитаемое имя на основе доступного предыдущего тега. Подробнее см. здесь: git-scm.com/docs/git-describe - person Marcelo Ávila de Oliveira; 23.03.2018
comment
Спасибо, что познакомили меня с git describe. Но мне кажется, что результат будет недостаточно надежным, когда дело доходит до определения отношения «происходит до» (или общего порядка). Возможно, простая метка времени в форме ГГГГММддЧЧммсс (которую предлагает Дженкинс), хотя и немного подробна, является лучшей заменой. - person leeyuiwah; 23.03.2018