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

Question

Я не использую 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 между разработчиками.

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

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

Answer 1

Versioning файл .hgtags позволяет

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

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

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

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

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

• Вы спрашиваете, являются ли ветви универсальными. Да, они - имена названных ветвей могут использоваться в любом контексте, где вам нужно указать набор изменений, как теги.

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

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

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

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

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

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

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

Answer 2

Выбор метода для маркировки определенно имеет некоторые странные побочные эффекты, но они хорошо объясняются в this wiki.Также предлагается клонировать полное репо, а затем обновлять его до интереса, чтобы избежать случая, когда вы создадите репо, которое не содержит тег, который использовался для его создания.