Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
hgbook.pdf
Скачиваний:
50
Добавлен:
17.03.2015
Размер:
3.15 Mб
Скачать

Глава 8. Управление релизами и ветками

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

Многие програмные проекты выпускают переодические «major» релизы, которые содержат некоторые новые существенные возможности. В тоже время они выпускают множество «minor» релизов. Они, как правило, идентичны основным релизам на которых они основаны, но исправляют ошибки.

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

8.1. Задание постоянного имени для ревизии

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

$ hg init mytag $ cd mytag

$ echo hello > myfile

$ hg commit -A -m 'Initial commit' adding myfile

Mercurial дает вам возможность указать постоянное имя любой ревизии используя команду hg tag. Не удивительно что эти имена называют «тегами».

$ hg tag v1.0

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

Двоеточие (ASCII 58, «:»)

Возврат каретки (ASCII 13, «\r»)

Перевод строки (ASCII 10, «\n»)

Вы можете использовать hg tags для показа тегов в вашем репозитории. В выводе каждая тегированая ревизия идентифицируется сначала по имени, затем по номеру ревизии, и потом по уникальному хешу ревизии.

$ hg tags

 

tip

1:2f120dd1b81c

v1.0

0:2765f2245422

Обратите внимание,

что в выводе hg tags показан тег tip (окончание ветки). Тег tip это специальный

«плавающий» тег, который всегда указывает на новейшую ревизию в репозитории.

В выводе команды hg tags теги показаны в обратном (относительно номеров ревизий) порядке. Обычно это значит, что более новые теги будут показаны перед более старыми. Также это означает, что tip всегда будет показан первым в выводе hg tags.

Когда вы запускаете hg log, если она показывает номер ревизии, которая имеет ассоциацию с тегами, то печатаются и эти теги:

$ hg log

 

changeset:

1:2f120dd1b81c

tag:

tip

user:

Bryan O'Sullivan <bos@serpentine.com>

81

5:c224d1a9e578
2:36034fbfb874

 

 

Управление релизами и ветками

 

 

 

 

 

 

date:

Thu Feb 02 14:10:07 2012 +0000

 

 

 

 

summary:

Added tag v1.0 for changeset 2765f2245422

 

 

changeset:

0:2765f2245422

 

 

tag:

v1.0

 

 

user:

Bryan O'Sullivan <bos@serpentine.com>

 

 

date:

Thu Feb 02 14:10:07 2012 +0000

 

 

summary:

Initial commit

 

 

 

 

 

Всегда, когда вам необходимо подставить идентификатор ревизии в команду Mercurial, можно подставлять имя соответствующего тега. Внутри себя Mercurial переводит имя тега в идентификатор ревизии.

$ echo goodbye > myfile2

$ hg commit -A -m 'Second commit' adding myfile2

$ hg log -r v1.0

changeset:

0:2765f2245422

tag:

v1.0

user:

Bryan O'Sullivan <bos@serpentine.com>

date:

Thu Feb 02 14:10:07 2012 +0000

summary:

Initial commit

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

К примеру, если ваш проект будет создавать вехи каждые пару дней совершенно разумно помечать их тегами. Но если вы используете систему непрерывной интеграции, которая гарантирует чистоту сборки каждой ревизии, тегирование каждой успешной сборки внесет неясности. Взамен вы можете помечать тегом ревизии, чья сборка завершилась неудачей (при условии что они редки!), или просто не использовать теги для отслеживания процесса сборки.

Если вы хотите удалить более не используемый тег используйте команду hg tag --remove.

$ hg tag --remove v1.0

 

$ hg tags

 

tip

3:7aa8dea37120

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

$ hg

tag -r 1 v1.1

$ hg

tags

tip

4:e38b5c6c84f1

v1.1

1:2f120dd1b81c

$ hg tag -r 2 v1.1

abort: tag 'v1.1' already exists (use -f to force) $ hg tag -f -r 2 v1.1

$ hg tags tip

v1.1

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

Mercurial хранит теги как обычный файл с контролем ревизий в вашем репозитории. Если вы создаете любые теги, вы сможете найти их все в файле .hgtags. Когда вы запускаете hg tag, Mercurial модифицирует этот файл, а затем автоматически комитит изменения в нем. Это означает что на каждый запуск hg tag вы можете найти соответствующий набор изменений в выводе команды hg log.

$ hg tip

 

changeset:

5:c224d1a9e578

tag:

tip

user:

Bryan O'Sullivan <bos@serpentine.com>

date:

Thu Feb 02 14:10:08 2012 +0000

82

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]