Mercurial - следует ли использовать .hgtags?

Если вы объединяете изменения из репозитория B в репозиторий A, вы должны объединить изменения в .hgtags?

В репозитории B могли быть теги 1.01, 1.02, 1.03, которые не указаны в A. Зачем вам объединять их в файл .hgtags в репозитории? Если мы слились, а затем попытались просмотреть репозиторий A, посмотрев на тег 1.01, я бы подумал, что это не сработает.

Ответы

Ответ 1

Краткий ответ: это работает правильно, и вы должны объединить .hgtags

Почему вы должны объединить .hgtags и почему это имеет смысл?

Итак, у вас есть

  • Repo A с изменениями 3 (a1), 4 (a2), 5 (a3) ​​
  • Repo B с изменениями 3 (b1), 4 (b2), 5 (b3) тег 1.01

Вышеуказанное указано как тег набора номера (длинный уникальный шестнадцатеричный id)

Итак, вы объединяете репо B в Repo A и получаете то, что выглядит.

      9 (a4) merge 
     /   \
    |   8 (b3) tag 1.01
    |    |
    |   7 (b2)
    |    |
    |   6 (b1)
 5 (a3)  |
    |    |
 4 (a2)  |
    |    |
 3 (a1)  |
     \   /
     2 (a0)

Если вы обновите repo до тега 1.01, вы получите точно, как выглядел код в тот момент времени Когда он был в Repo B точно так же, как mercurial promises.

Вы должны объединить их, поскольку измененные изменения из репо B, которые были помечены, теперь являются частью дерева наборов изменений в Repo A, поэтому теперь изменения, отмеченные вами в Repo B, теперь отмечены в Repo A. Не слияние их просто приведет к вам чтобы потерять теги, которые вы создали для наборов изменений.

Ответ 2

Интересная вещь, которую нужно знать (из mercurial wiki)

"Эффективные" теги взяты из файлы .hgtags на головах всех ветки. Метки, наиболее близкие к подсказкам старшинство.

Итак, когда вы объединяетесь (объединяете две головы), вам нужно объединить .hgtags или некоторые теги исчезнут.