Ртутный коммит исчез - PullRequest
Новая
       37

Ртутный коммит исчез

0 голосов
/ 31 января 2012

Мы недавно перешли на Mercurial.Все шло хорошо, пока у нас не было двух случаев пропущенных изменений.Изучение журналов не сделало нас мудрее.

Ниже приведен пример.Файлы, зафиксированные в (1), возвращаются в предыдущее состояние в (2), даже если эти файлы не упоминаются в слиянии.

Что можно проверить, чтобы понять, почему файлы были восстановлены?

граф ревизий http://i43.tinypic.com/1f8ruq.png

Ответы [ 2 ]

2 голосов
/ 31 января 2012

На этом графике есть три интересных ревизии, которые могут повлиять на (2) слияние:

  • Teal changeset: не показан, но выглядит так, будто он чуть ниже графика. Это первый родитель (2)
  • Синяя смена: номер пять снизу с надписью «Исправить тест». Это второй родитель (2).
  • Общий предок родителей: также не показан, будет далее ниже. Как ни странно, похоже, что чередующийся чир может быть общим предком, но Mercurial теперь позволит вам сделать такое вырожденное слияние при нормальных обстоятельствах.

Когда Mercurial выполняет слияние, это только трех наборов изменений, которые имеют значение: две головы, которые вы объединяете, и их общий предок. В трехстороннем слиянии логика теперь такова: 

ancestor  parent1  parent2  =>  merge
X         X        Y            Y (clean)
X         Y        X            Y (clean)
X         Y        Y            Y (clean)
X         Y        Z            W (conflict)

Прочитайте таблицу следующим образом: «если предок был X, а первый родитель был также X, а второй родитель был Y, то объединение будет содержать Y». Другими словами: трехстороннее слияние способствует изменению и позволит выиграть модификацию.

Вы можете найти предка с помощью 

$ hg log -r "ancestor(p1(changeset-2), p2(changeset-2))"

где changeset-2 - это тот, который отмечен (2) выше. Когда вы говорите

Файлы, зафиксированные в (1), возвращаются в предыдущее состояние в (2), даже если эти файлы не упоминаются в слиянии.

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

$ hg status --rev "p1(changeset-2):changeset-2"
$ hg status --rev "p2(changeset-2):changeset-2"

Это показывает, как набор изменений слияния отличается от своего первого и второго родителя соответственно. Я уверен, что файлы упоминаются в одном из этих списков - если слияние не является виновником в конце концов.

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

1 голос
/ 31 января 2012

Слияние в 2 происходит между очень старой веткой (темно-синей, разветвленной от основной линии / зеленой ветки сразу после коммита 1) и даже более старой веткой (светло-синей, не синхронизировалась с основной линией с момента фиксации 1)

Кажется вероятным, что слияние в 2 выбрало неверную версию файла - отсюда невозможно определить, был ли это инструмент, который выбрал неправильную версию файла, или пользователь вручную выбрал неправильную версию.

Отредактировано, чтобы добавить:

Чтобы помочь отследить, что именно изменилось в 2, вы можете использовать hg diff -r REV1 -r REV2, который покажет вам построчную разницу между любыми двумя ревизиями.

Когда вы знаете, что вредность возникла где-то между точкой 1 и точкой 2, hg bisect может помочь вам отследить точный источник вредности:

hg bisect [-gbsr] [-U] [-c CMD] [REV]

поиск подразделов наборов изменений 

This command helps to find changesets which introduce problems. To use,

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

Bisect обновит ваш рабочий каталог до версии для тестирования (если не указана опция -U / - noupdate).После того, как вы выполнили тесты, пометьте рабочий каталог как хороший или плохой, и bisect либо обновит другой набор изменений кандидата, либо объявит, что обнаружил плохую ревизию.

...