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

Question

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

Тег - это просто псевдоним для набора изменений (и под «набором изменений» мы на самом деле подразумеваем состояние, являющееся результатом набора изменений). Здорово. Сопоставление тегов с идентификаторами наборов изменений сохраняется в файле .hgtags. Тоже круто. Файл .hgtags имеет версию.

Что?

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

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

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

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

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

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

Answer 1

Управление версиями файла .hgtags позволяет вам

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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