Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
hgbook.pdf
Скачиваний:
50
Добавлен:
17.03.2015
Размер:
3.15 Mб
Скачать
Были зафиксированы изменения для файла a, но не для нового файла b. Если бы я отправил эти изменения в общее с коллегами хранилище, то велик шанс того, что что-то в a ссылается на b, отсутствующий в репозиториях коллег после того, как они получат мои изменения. В таком случае я мог бы стать объектом некоторого негодования.
Однако, мне повезло — я заметил ошибку прежде, чем отослал изменения. Я воспользовался командой hg rollback, и Mercurial убрал последние измения.
$ hg rollback
repository tip rolled back to revision 0 (undo commit) working directory now based on revision 0
$ hg tip
changeset: 0:f50222def92b tag: tip
user: Bryan O'Sullivan <bos@serpentine.com> date: Thu Feb 02 14:10:06 2012 +0000
90

Глава 9. Поиск и исправление ваших ошибок

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

9.1. Удаление локальной истории

9.1.1. Случайная фиксация

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

9.1.2. Откат транзакции

В разделе Раздел 4.2.2, «Безопасность работы» я упоминал, что Mercurial рассматривает каждую модификацию хранилища как транзакцию. Каждый раз, когда вы фиксируете изменения или подтягиваете изменения из другого хранилища, Mercurial запоминает, что вы сделали. Вы можете отменить, или откатить, только одно из этих действий с помощью команды hg rollback. (Смотрите раздел Раздел 9.1.4, «hg rollback бесполезен если изменения уже внесены.» о важном предупреждении о использовании данной команды.)

Приведу пример частой собственной ошибки: фиксация изменений, в которых я создал новый файл, но забыл выполнить hg add для него.

$ hg status

M a

$ echo b > b

$ hg commit -m 'Add file b'

Вывод команды hg status после фиксации подтверждает ошибку.

 

$ hg status

 

 

? b

 

 

$ hg tip

 

 

changeset:

1:e74fb1f34241

 

tag:

tip

 

user:

Bryan O'Sullivan <bos@serpentine.com>

 

date:

Thu Feb 02 14:10:06 2012 +0000

 

summary:

Add file b

 

 

 

 

 

 

 

 

 

 

 

 

Поиск и исправление ваших ошибок

summary: First commit

$ hg status

M a ? b

Обратите внимание, что изменение отсутствует в истории хранилища, и репозиторий снова считает, что файл a в рабочей директории имеет не фиксированные модификации. Commit и rollback оставили рабочую директорию в том же состоянии, в котором она была перед commit; изменения полностью уничтожены. Теперь я могу безопасно выполнить hg add файл b, и снова запустить commit.

$ hg add b

$ hg commit -m 'Add file b, this time for real'

9.1.3. Ошибочное вытягивание

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

На этом примере, можете представить себе неприятные последствия случайного вытягивания изменений из общего хранилища ветки «1.0» в ваш локальный репозиторий релиза «0.9». В худшем случае, вы заплатите за невнимательность втолкнув те самые изменения в общее «0.9» дерево, запутав остальных разработчиков. (Не волнуйтесь, к этому ужасному сценарию мы вернёмся позже). Впрочем, вероятнее всего, Вы заметите это сразу же, поскольку Mercurial покажет вам URL из которого происходит вытягивание. Или Вы обратите внимание на подозрительно большое число изменений в хранилище.

Для исключения этих, только что втянутых правок, отлично подходит команда hg rollback. Mercurial группирует все изменения, внесенные командой hg pull, в одну трансакцию, поэтому всё, что вам нужно для исправления ошибки — одна команда hg rollback.

9.1.4. hg rollback бесполезен если изменения уже внесены.

Ценность команды hg rollback падает до нуля, как только вы втолкнете изменения в другое хранилище. Конечно, эта команда исправит ошибку, но только в том хранилище к которому вы её применяете. Поскольку rollback уничтожает историю, нет способа остановить распространение ошибочного изменения между хранилищами.

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

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

9.1.5. Вы можете отменить только последнее изменение

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

$ hg rollback

repository tip rolled back to revision 0 (undo commit) working directory now based on revision 0

$ hg rollback

no rollback information available

Если вы произведете отмену транзакции, вы не сможете снова выполнять roll back до тех пор, пока не произведете другие операции commit или pull.

91

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