1

2 つの中央ブランチ/クローン (DEV と PRD など) を持つ Hg プロジェクトを考えてみましょう。誰かがホットフィックスを PRD にプッシュすると、中央サーバー上の自動化されたスクリプトが DEV に移動し、新しい変更をプルします。次に、修正プログラムを DEV にマージしようとします。

問題は、Hg に統合されたマージ ツールがひどいことです。同じファイルに並行して変更が加えられるとすぐに失敗します。次の例を見てください。

parent:3,7c
 four
 five
 six

 seven

child1:3,7c
 four
 five5
 six6

 seven7

child2:3,7c
 fourmore
 five
 six
 more
 seven

ご覧のとおり、ここには実際の競合はありません。kdiff を使用してローカルでマージを行うと、ユーザー入力なしでこの単純なケースが解決されます!

これらのケースを中央サーバーで管理する方法が欲しいです。kdiff3 をサイレント モードで使用することを考えましたが、kdiff3 をインストールすることはできません (これは、管理者アクセスさえできない CLI のみのシステムです)。このような単純なケースを解決できますか? hgrc で "[ui] /n merge = diff3" を設定しようとしましたが、3 つのバージョンが stdout に吐き出されるだけです。追加の構成が不足していますか? または、より簡単で優れたツールはありますか?

どうもありがとう

4

1 に答える 1

1

マージツールとして使用するdiff3には、追加する必要があります

[merge-tools]
diff3.args = $local $base $other -m > $output

構成ファイルに。必要に応じて優先度を設定できます。wiki を参照してください。そこに使用するためのより複雑なレシピdiff3もあります。

ただし、diff3隣接する行の編集でシナリオをどのように扱うかをテストしましたが、Mercurial と同様に、これもきれいにマージすることを拒否しました。マージ ツールが異なれば、「競合」と見なされるしきい値も異なります。KDiff3 は Mercurial やdiff3.

ホットフィックスを作成した開発者に、KDiff3 などのツールにアクセスできるローカルにPRDマージする責任を負わせることをお勧めします。DEVサーバー上での自動マージは一般的に悪いと考えられています — マージは、コミットする前に人間によってほんの少しだけ検証されるべきです。ホットフィックスを作成した後は、それほど余分な作業はありません。

于 2012-04-12T16:07:29.137 に答える