Как я могу узнать обо всех тегах в Mercurial?

Я не использую Mercurial, но я бы хотел начать, поэтому я читаю об этом. Единственной системой SCM, которую я широко использовал, является CVS. Большая часть того, что я читал о Mercurial, имеет смысл и звучит хорошо. Но я чересчур шокирован и озадачен тем, что он делает теги.

Тег - это просто псевдоним для набора изменений (и "changeet" мы действительно имеем в виду состояние, полученное из набора изменений). Круто. Отображение от тегов к идентификаторам наборов изменений хранится в файле .hgtags. Также круто. Файл .hgtags имеет версию.

Что?

Это имеет множество противоречивых последствий. Например, если я совершу набор изменений, который я хочу пометить (скажем, код, который будет формировать выпуск 1.0), я должен снова зафиксировать после тегов, чтобы поместить обновленный файл тега в репозиторий. И если я потом обновляю этот тегированный набор изменений позже, рабочая копия не будет содержать никаких знаний об этом теге. Если я выполняю некоторую работу, создав новую ветку (скажем, для исправлений, заголовок в направлении 1.1), эта ветка не будет знать тег, из которого она выросла. Если я не скопирую его вручную, то есть.

И поскольку разработка продолжается как на исходном соединителе, так и на моей новой ветке, с созданием тегов для отметки важных наборов изменений (выпуск 2.0 на соединительной линии, выпуски с исправлениями 1.1 и 1.2 на ветке), обе ветки продолжаются в неведении других тегов ветки. Итак, если я закончу работу над одной ветвью и хочу переключиться на какой-то конкретный набор изменений на другой (скажем, я заканчиваю выпуск 1.2 bugfix, но теперь вам нужно начать с исправления 2.1, основанного на 2.0), теперь я набит. Мой текущий набор изменений не знает о 2.0!

Что я могу сделать?

Я могу попросить кого-то, кто работает над ветвью 2.x, прочитать текущий идентификатор набора изменений для 2.0 и использовать это явно, но это ужасно.
Я мог бы назвать свои ветки, а также использовать теги, чтобы я мог перепрыгнуть через голову ветки 2.x, узнав о новых тегах, а затем перейдем к тегу 2.0. Предполагая, что ветки, в отличие от тегов, повсеместно видны - это так? Даже если это так, это кажется неуклюжим.
Я мог бы поддерживать один глобальный hgtags файл вне репозитория и использовать пару крючков, чтобы вытащить копию на обновление, перезаписать локальную копию и скопировать любые изменения в фиксации. Я не уверен, как это будет работать в многопользовательской среде, где разработчики нажимают изменения в общий репозиторий; Мне может понадобиться отдельный репозиторий только для файла hgtags.
Я мог бы использовать локальные теги, которые стоят за пределами механизма управления версиями, и поэтому избегайте всей проблемы. Как и для общих глобальных тегов, мне нужно будет создать механизм для синхронизации файла localtags между разработчиками.

Ни одно из этих решений не кажется совершенно замечательным. Что я должен делать?

Предполагается, что я управляю ветвями, использующими именованные ветки в одном репозитории, а не в репозитории для каждой ветки. Будет ли ситуация лучше, если я сделаю последнее?

Ответ 1

Версии файла .hgtags позволяют

редактировать теги и видеть, кто их редактировал (и почему, если они оставили надлежащее сообщение фиксации)
передавать теги между репозиториями с использованием обычных механизмов

Однако здесь есть некоторая путаница.

Вы пишете, что

[...] И если я потом обновляю этот тегированный набор изменений позже, рабочая копия не будет содержать никаких знаний об этом теге. [...]

Неверно, теги собираются из файлов .hgtags, найденных во всех головках. Это означает, что вы можете обновить старый тег (hg update 0.1) и по-прежнему видеть все ваши теги (hg tags).
Вы спрашиваете, универсальны ли ветки. Да, они - имена названных ветвей могут использоваться в любом контексте, где вам нужно указать набор изменений, а также теги.

Удостоверьтесь, что вы понимаете, что назвали ветки, прежде чем вы начнете их использовать. На самом деле они не нужны для создания ветки bugfix. Вместо этого вы можете просто вернуться (hg update 1.0) и исправить ошибку, а затем зафиксировать. Это создаст новую главу, в которой ваша линия развития будет равна 1.1 (это дает вам несколько головок). Таким образом, вам не нужно создавать ветку с именем, чтобы добавить новую ветвь разработки в ваш репозиторий.

Наличие нескольких головок полностью эквивалентно наличию нескольких клонов. Вы можете даже конвертировать туда и обратно: вы можете использовать

% hg clone -r X-head repo repo-X

чтобы распутать набор изменений X-head и его предков из других наборов изменений в repo. И вы можете объединить несколько клонов, просто потянув все изменения в один большой клон.

Именованные ветки похожи, но разные. Они позволяют встраивать имя в каждый набор изменений. Таким образом, вы можете иметь несколько изменений в своей истории с именем "foo". Когда вы сделаете hg update foo, вы попадете на вершину - большинство из этих наборов изменений. Таким образом, названные ветки функционируют как своего рода плавающий тег.

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

Надеюсь, это немного поможет.

Ответ 1

Ответ 2