Что значит ртутная ревизия без родителя?

Question

У меня есть хранилище Mercurial, которое сейчас находится в странном состоянии. Вот как это выглядит в TortoiseHG:

Я не думал, что это будет возможно. Редакция 54 имеет родительский элемент «-1 (000000000000)» (то есть ничего). В Mercurial есть что-то, чего я еще не понимаю. Может ли кто-нибудь дать мне знать, что это значит - и что должно было произойти, чтобы он попал в это состояние. Насколько я знаю, из него только выталкивали и извлекали вещи - и никто не использовал какие-то дурацкие расширения.

Редакции 54 и 55 просто добавляли теги, но если я «обновлю -C» до ревизии 54, я получу ТОЛЬКО файл .hgtags.

Я сделал клон из ревизии 53, чтобы исправить это. Но я бы лучше понял, что здесь произошло, поэтому я могу избежать повторения этого.

Answer 1

Когда вы смотрите на определение набора изменений , вы видите:

Каждый набор изменений имеет ноль, один или два родительских набора изменений:

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

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

Так, может быть, это то, что вы сделали:

• обновление обратно до 53 (у которого уже тогда был ребенок '54')
• изменение файлов
• фиксирует, таким образом, начиная новую ветку с 54, без родителя
  (это сделало бы второй коммит с тем же родителем)

или

• на 53 с опцией --close-branch ,
• потенциально новый коммит (без переключения на другую ветку) может начать новый

Ry4an (реальный специалист по ртути;)) звонит и комментирует:

--close-branch ничего не делает, кроме как скрыть ветку из списка, и он отменяется в следующий раз, когда вы фиксируете эту ветку. Это не создаст несколько корней.

VonC прав в своем диагнозе, несколько голов .
Но никакие комбинации 'update' и 'commit' не приведут вас в это состояние.
Чтобы получить несколько корней, обычно делают '1064 *' из репозитория и используют --force для отмены предупреждения unrelated repositories.

---

(«без родителя», то есть родительские идентификаторы установлены на 00000, см. «за сценой» :

альтернативный текст http://hgbook.red -bean.com / read / figs / revlog.png )

Answer 2

Еще один способ увидеть это, если вы сделали hg update null после совершения оборота. 53. Например, рассмотрим следующую последовательность:

hg init foo
# create some files
hg addremove
hg commit -m "Revision 0"
# edit, edit, edit
hg commit -m "Revision 1"
hg update null
hg tag -m "Create tag v1.0.0.0" "v1.0.0.0"

В этот момент hg log покажет родителя ревизии 2 как -1: 0000000000 Поскольку hg update null очищает рабочий каталог, единственным файлом в нем будет .hgtags (как вы и видели).

У вас были другие теги до рев. 53? Если мои подозрения верны, они не будут присутствовать в вашем обороте. 54 .hgtags.