Помогите с проблемой ртутного репо

Question

У меня репо в состоянии, которого я не понимаю.2 недели назад я пометил релиз, чтобы отметить определенный момент, к которому, возможно, мне нужно было вернуться.Позже я решил разветвляться, а также извлекал изменения из другого репо (репо, который я изначально клонировал).

Оригинальный рев, который представляет интерес 52:

changeset:   52:5044a88ba2a9
date:        Mon Jan 10 18:09:30 2011 -0500

Несколько коммитов позже, я разветвился в «MultiPartition» (я должен был сделать это немедленно, но я не ожидал, что это понадобится).

После некоторой дополнительной работы я извлекаю изменения из репозитория сестры (всеизменения не противоречат моей работе в ветке, так что это безопасно).

Вот что я вижу сейчас:

$ hg branches
MultiPartition                75:9fd803c56505
default                       72:3939850a77e2 (inactive)

Где я работаю в MultiPartition, и по умолчанию этосовет от сестринского репо.

Если я посмотрю на головы:

$ hg heads
changeset:   75:9fd803c56505
branch:      MultiPartition
tag:         tip
date:        Tue Jan 18 18:32:38 2011 -0500

changeset:   72:3939850a77e2
parent:      69:997a5b43216d
date:        Tue Jan 18 13:26:48 2011 -0500

changeset:   54:4ad1d36a79aa
date:        Thu Jan 13 19:14:57 2011 -0500

там висит 54-я версия, которую я (сознательно) не хотел оставлять позади.

Вот где это становится странным: набор изменений 52 отсутствует в моем текущем совете по MultiPartition (хотя на самом деле он был в источнике на моем диске, как я и ожидал).Я приложил график изменений в нижней части.

Если я использую расширение hgcontains , я вижу:

$ hg headscontaining 52
changeset:   75:9fd803c56505
branch:      MultiPartition
tag:         tip
date:        Tue Jan 18 18:32:38 2011 -0500

, который говорит мне, что содержимоеиз Rev 52 (который имеет новые файлы, которые я хочу в текущей ветви) должен быть в конце этой ветви.Тем не менее, hg update -C MultiPartition удаляет новые файлы из каталога, в котором я их хочу.

Если я использую hgtk log и фильтрую по интересующему каталогу, я вижу набор изменений 52, который добавляет файлы, но нетболее новые наборы изменений имеют любые файлы, удаленные из этого каталога.

Единственное, что заставляет меня задуматься, это: Changeset 71 был слиянием с исходным репо.В этом репо эти новые файлы не существуют.Журнал для этого набора изменений:

| o  changeset:   71:ba4c67a24185
|/|  branch:      MultiPartition
| |  parent:      70:2dcbf69c325d
| |  parent:      69:997a5b43216d
| |  date:        Mon Jan 17 17:55:10 2011 -0500

Вот мой основной вопрос :

1. Если родитель 70: имеет то, что я ожидал, но родитель 69: не сделал't, как это разрешается?
2. Как я могу проверить другие пропуски?Есть ли способ увидеть такое поведение?
3. Я хочу, чтобы у меня не было нескольких голов, но я не могу их "слить".Технически они уже объединены (я думаю).Как мне это исправить?

Извините, если это сложно, но я не знаю, как еще задать вопрос, кроме как дать тонну информации.

Полный графлог:

o  changeset:   75:9fd803c56505
|  branch:      MultiPartition
|  tag:         tip
|  date:        Tue Jan 18 18:32:38 2011 -0500
|
o    changeset:   74:be7df4e2579c
|\   branch:      MultiPartition
| |  parent:      73:3e7ac80ab37a
| |  parent:      72:3939850a77e2
| |  date:        Tue Jan 18 18:31:24 2011 -0500
| |
| o  changeset:   73:3e7ac80ab37a
| |  branch:      MultiPartition
| |  parent:      71:ba4c67a24185
| |  date:        Tue Jan 18 18:28:51 2011 -0500
| |
o |  changeset:   72:3939850a77e2
| |  parent:      69:997a5b43216d
| |  date:        Tue Jan 18 13:26:48 2011 -0500
| |
| o  changeset:   71:ba4c67a24185
|/|  branch:      MultiPartition
| |  parent:      70:2dcbf69c325d
| |  parent:      69:997a5b43216d
| |  date:        Mon Jan 17 17:55:10 2011 -0500
| |
| o  changeset:   70:2dcbf69c325d
| |  branch:      MultiPartition
| |  parent:      66:79272b7e7c01
| |  date:        Mon Jan 17 17:42:04 2011 -0500
| |
o |  changeset:   69:997a5b43216d
| |  date:        Mon Jan 17 12:00:09 2011 -0500
| |
o |  changeset:   68:b39f8a7af0c5
| |  date:        Sun Jan 16 20:23:43 2011 -0500
| |
o |  changeset:   67:63d3b40427e0
| |  parent:      58:29029a74e351
| |  date:        Sun Jan 16 18:07:49 2011 -0500
| |
| o  changeset:   66:79272b7e7c01
| |  branch:      MultiPartition
| |  date:        Mon Jan 17 09:43:32 2011 -0500
| |
| o  changeset:   65:b33eb978d647
| |  branch:      MultiPartition
| |  date:        Mon Jan 17 09:39:54 2011 -0500
| |
| o  changeset:   64:1fdafb6d0e84
| |  branch:      MultiPartition
| |  date:        Sun Jan 16 17:48:09 2011 -0500
| |
| o  changeset:   63:74942ab5113d
| |  branch:      MultiPartition
| |  date:        Sun Jan 16 17:46:15 2011 -0500
| |
| o  changeset:   62:2cd5a6d9d120
| |  branch:      MultiPartition
| |  date:        Sun Jan 16 01:55:23 2011 -0500
| |
| o  changeset:   61:acc73e7a35fc
|/|  branch:      MultiPartition
| |  parent:      60:c10e217081f0
| |  parent:      58:29029a74e351
| |  date:        Sun Jan 16 01:53:01 2011 -0500
| |
| o  changeset:   60:c10e217081f0
| |  branch:      MultiPartition
| |  date:        Sun Jan 16 01:45:16 2011 -0500
| |
| o  changeset:   59:2709b82b3ac0
| |  branch:      MultiPartition
| |  parent:      54:4ad1d36a79aa
| |  date:        Sun Jan 16 01:42:34 2011 -0500
| |
o |  changeset:   58:29029a74e351
| |  date:        Sun Jan 16 01:36:44 2011 -0500
| |
o |  changeset:   57:48840b75e37b
| |  date:        Fri Jan 14 11:04:06 2011 -0500
| |
o |  changeset:   56:dab5f0d40be9
| |  date:        Thu Jan 13 15:51:11 2011 -0500
| |
o |  changeset:   55:214ac45834fd
| |  parent:      51:7d0a1da31199
| |  date:        Wed Jan 12 16:49:00 2011 -0500
| |
| @  changeset:   54:4ad1d36a79aa
| |  date:        Thu Jan 13 19:14:57 2011 -0500
| |
| o  changeset:   53:8f06d69177d6
| |  date:        Thu Jan 13 14:02:42 2011 -0500
| |
| o  changeset:   52:5044a88ba2a9
|    date:        Mon Jan 10 18:09:30 2011 -0500
|
o 

Answer 1

На самом деле у вас все еще есть две головки в ветви по умолчанию и одна головка в ветви MultiPartition , как показала hg heads. Используйте hg heads -t, чтобы увидеть фактические головы, независимо от ветви. Похоже, вы используете расширение graphlog, поэтому используйте hg glog -r "branch(default)" для визуализации ветки по умолчанию.

Что касается ваших вопросов:

1. Если родитель 70: имеет то, что я ожидал, а родитель 69: нет, как это разрешается?

Вы можете hg export -r 52 >52.patch затем hg import 52.patch на кончике. Это будет повторно применить изменения. Одно из ваших слияний, должно быть, отбросило контент.

1. Как я могу проверить другие пропуски? Есть ли способ увидеть такое поведение?

Не совсем. Что касается Mercurial, то 52 является предком твоего совета. Если изменения были отброшены в более поздней ревизии, Mercurial на самом деле не знает. Вы можете hg diff два разных набора изменений и отследить, где он был удален (вероятно, в слиянии).

1. Я хочу, чтобы у меня не было нескольких голов, но я не могу их "слить". Технически они уже объединены (я думаю). Как мне это почистить?

по умолчанию , как правило, там, где вы хотите, чтобы все ваши разработки заканчивались. Вы можете объединить две стандартные головки, затем hg ci --closebranch на MultiPartition и объединить их в по умолчанию .

Answer 2

1: Если родитель 70: имеет то, что я ожидал, а родитель 69: нет, как это разрешается?

Я думаю, файлы были удалены в 61 или71 слияние.Вы можете проверить это в hgtk с опцией «diff to second parent».

3: Я хочу, чтобы не было нескольких головок, но я не могу их объединить.Технически они уже объединены (я думаю).Как мне это исправить?

В вашей ветке по умолчанию есть две анонимные головы (54 и 72, где 72 - вершина по умолчанию), и они будут оставаться открытыми до тех пор, пока ветвь MultiPartition будетне объединены обратно в дефолт.Несмотря на то, что позднее они были объединены в ветке MultiPartition, они по-прежнему являются главой ветви по умолчанию, поскольку Mercurial не считает последующую ветвь новой главой ветви.Причиной такого обращения является то, что вам обычно требуется последняя версия ветки, когда вы hg update branch.

Вы можете избавиться от двух головок по умолчанию, когда объедините MultiPartition обратно в стандартную.Когда вы закончите с MultiPartition, вы также можете закрыть эту ветку с помощью hg ci --close-branch (технически вы не можете удалить головку MultiPartition, но когда она закрыта, hg heads не будет рассматривать ее как активную головку).