Упорядочивание сборки, когда использование распределило управление версиями

Прямо сейчас мы используем По необходимости для управления версиями. Это имеет удобную функцию строго увеличивающего числа изменения, которое мы можем использовать для обращения к сборкам, например, "Вы получите bugfix, если Ваша сборка будет по крайней мере 44 902".

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

Что лучший способ состоит в том, чтобы сохранить строго увеличивающиеся идентификаторы сборки? Самым простым путем я могу думать, должен иметь своего рода рычаг постфиксации, который исчерпывает каждый раз, когда основной repo обновляется, и он регистрирует (хеш) новый древовидный объект (или объект фиксации? Я плохо знаком с мерзавцем) с централизованной базой данных, которая раздает идентификаторы. (Я говорю "базу данных", но я, вероятно, сделал бы это с тегами мерзавца и просто искал бы следующий доступный номер тега или что-то. Таким образом, "база данных" действительно была бы .git/refs/tags/build-id/.)

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

29
задан sfink 23 September 2008 в 17:23
поделиться

6 ответов

Я второй предложение использования git describe. При условии, что у Вас есть нормальная политика управления версиями, и Вы не делаете, любой сумасшедший материал с Вашим репозиторием, git describe всегда будет монотонным (по крайней мере, столь монотонный, как можно быть, когда история пересмотра является DAG вместо дерева), и уникальный.

Немного демонстрации:

git init
git commit --allow-empty -m'Commit One.'
git tag -a -m'Tag One.' 1.2.3
git describe    # => 1.2.3
git commit --allow-empty -m'Commit Two.'
git describe    # => 1.2.3-1-gaac161d
git commit --allow-empty -m'Commit Three.'
git describe    # => 1.2.3-2-g462715d
git tag -a -m'Tag Two.' 2.0.0
git describe    # => 2.0.0

вывод git describe состоит из следующих компонентов:

  1. новейший тег, достижимый от фиксации, Вы просите описывать
  2. количество фиксаций между фиксацией и тегом (если ненулевой)
  3. (сокращенный) идентификатор фиксации (если № 2 является ненулевым)

, #2 - то, что делает вывод монотонным, № 3 - то, что делает это уникальным. № 2 и № 3 опущены, когда фиксация тег, делая git describe также подходящий для производственных выпусков.

28
ответ дан 28 November 2019 в 01:04
поделиться

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

Примечание: когда Вы отметите локально, git push не обновит теги на сервере. Используйте git push --tags для этого.

4
ответ дан 28 November 2019 в 01:04
поделиться

Необходимо заняться расследованиями git describe. Это дает уникальную строку, которая описывает текущее ответвление (или любой переданный идентификатор фиксации) с точки зрения последнего аннотируемого тега, количества фиксаций начиная с того тега и сокращенного идентификатора фиксации главы ответвления.

, По-видимому, у Вас есть единственное ответвление, что Вы выполняете управляемые выпуски сборки прочь. В этом случае я отметил бы раннюю фиксацию с известным форматом тега и затем использовал бы мерзавца, описывают с - опция соответствия описать текущую ГОЛОВУ относительно известный тег. Можно затем использовать результат мерзавца, описывают, как или если Вы действительно хотите просто единственное число, можно использовать regex для прерывания числа из тега.

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

, например, (использующий удар или подобный)

# make an annotated tag to an early build in the repository:
git tag -a build-origin "$some_old_commitid"

# describe the current HEAD against this tag and pull out a build number
expr "$(git describe --match build-origin)" : 'build-origin-\([0-9]*\)-g'
2
ответ дан 28 November 2019 в 01:04
поделиться

Как Вы, вероятно, знаете, мерзавец вычисляет хеш (число), который однозначно определяет узел истории. Используя их, хотя они строго не увеличиваются, кажется, что это было бы достаточно хорошо. (Еще лучше они всегда соответствуют источнику, поэтому если у Вас есть хеш, у Вас есть тот же код.) Они - большие числа, но главным образом можно обойтись приблизительно 6 из ведущих цифр.

, Например,

, Что ошибка была исправлена в 064f2ea...

0
ответ дан 28 November 2019 в 01:04
поделиться

Я использовал бы, "Маркирует" Create маркировкой каждый раз, когда у Вас есть успешное (или даже неудачный) сборка, и Вы сможете определить ту сборку навсегда. Это - не совсем то же, но это действительно обеспечивает те номера сборки, все еще предоставляя преимущества распределенной разработки.

1
ответ дан 28 November 2019 в 01:04
поделиться

В Mercurial вы можете использовать следующую команду:

# get the parents id, the local revision number and the tags
[yjost@myhost:~/my-repo]$ hg id -nibt
03b6399bc32b+ 23716+ default tip

См. hg identify

0
ответ дан 28 November 2019 в 01:04
поделиться
Другие вопросы по тегам:

Похожие вопросы: