1

2 つのリビジョン (14321 と 14319) が親 (14318) を共有するリポジトリがあります。両方の変更セットは 14318 の直接の子です。それにもかかわらず、リビジョン セットのクエリは14318 を返し ancestor(14321, 14319)ませんが、代わりにはるかに古い変更セットを返します。何が起こっていますか？

TortoiseHg のスクリーンショット:

クエリの先祖(14321、14319)の奇妙な結果を示す図

背景:最近、mercurial が既にマージされた変更を再適用しようとしたことが原因であることが判明した奇妙なマージ競合に遭遇しました。両方のヘッドに同じ変更が含まれる原因となったマージ ベースの奇妙な選択を突き止めることができましたが、なぜこれが起こったのか、将来どのように防ぐことができるのかわかりません (一部回避するために DVCS を選択しました)。そもそもこういう問題…）

4

3 に答える 3

3

この図は、共通の祖先が 1 つではなく 2 つあることを示しています。したがって、1 つまたは別の共通の祖先を選択することでマージの問題が発生する、交差するマージ ケースのように見えます。

参考文献:

新しいマージ アルゴリズムの提案があります ( https://www.mercurial-scm.org/wiki/ConsensusMerge )。ただし、Mercurial の 2.3 スプリント以降、このトピックは行き詰まっています。

この種の問題を軽減するために、開発者が公式リポジトリとのみマージできるように、クライアント サーバー トポロジを確立することをお勧めします。多分 rebase も役立つかもしれません。

交差マージは次のようなものです。

   B --- D
  / \   / \
 /   \ /   \ 
A     X     F 
 \   / \   /
  \ /   \ /
   C --- E

あなたの場合、それは：

           B
-----------o----               } stable/production
      C     \   \       F
------o------o---\------o      } default
       \     D    \    /
        -----------o---        } feature
                   E

A = ?
B = 14318
C = 14294
D = 14319
E = 14321
F = ?

を生成するFには、 と の 2 つの回路が考えられB-D-E-FますC-D-E-F。Mercurial は後者を選択しました。

運用ブランチと機能ブランチをマージしていなければ、交差を回避できたはずです。ホットフィックスは、デフォルト ブランチを介して機能ブランチに伝播された可能性があります。ログは次のようになります。

           B
-----------o               } stable/production
      C     \       F
------o------o------o      } default
       \    D \    /
        -------o---        } feature
               E
于 2013-02-13T14:40:33.490 に答える
0

マージセットの共通の祖先の場合の誤ったベース検出について、1 つの弱点が知られています。

マージセットのいずれかにマージ編集に関係のないものが含まれていると、間違っている可能性があります

于 2013-02-14T08:02:12.133 に答える
-1

祖先は 14294 だと思います。新しいコミットは両方ともマージであるため、複数の祖先があり、選択があいまいになります。

残念ながら、どの潜在的な祖先を使用するかを mercurial に伝える方法はありません。

于 2013-02-13T13:11:35.320 に答える