[thg] mercurial で BASE OTHER が共通で LOCAL だけ変更されている行がコンフリクトとして判断されるのは正常な動作なのでしょうか?

[ohira]

いつもお世話になっております。

おおひらです。

TortiseHg と Winmergeを組み合わせてマージを行なった場合に other側で一行変更しただけなのに

Winmergeの自動マージに問題があるようで、

コンフリクトが大量に発生するという現象がありました。(Winmergeによるマージの場合)

それで、hg でマージを行いコンフリクトマーカー付きのソースをWinmergeに渡すように

変更することで変更した一行だけがコンフリクト扱いになることを期待しました。

やってみると、Winmergeでマージした時のように多くはないのですが、

コンフリクトするはずの行を含む連続した34行がコンフリクトの範囲に含まれる結果となりました。

コンフリクトの判断が、行単位で行われるものだとすると

人間の感覚としては一行だけ検出してくれると良さそうにおもうのですが。

mercurialのコンフリクトは複数行にまたがって、ひとかたまりで判断されることがあるのでしょうか?

BASE と OTHER の違いは、一行だけ(行の中央部分のキャラクタを削除)(LOCALで行頭の空白を一つ削除した場所の真ん中ぐらいの行です)

BASE と LOCAL の違いは、先頭の文字列が始まるまでの空白を一つ削除(9個の空白だったものを8個の空白に変更)

#

Winmergeで見るとBASEとOTHERで行頭の空白は同じように見えて実は違うのかもしれないと考えて

藤原さんが作成されたツール(shimplemerge)を使用してハッシュを確認しましたが、ハッシュは

コンフリクトしている33行(OTHERで変更した部分をのぞく)でBASE OTHER共通でした。

コンフリクトしている部分がLOCALで変更している34行の真ん中ぐらいなので

全体がコンフリクトしているという判断なのでしょうか。

[ohira]

おおひらです。

以下のような状況です。

...

...

...

(base other local 共通)

(base other 共通)(local 別) <---------- ここから

(base other 共通)(local 別)

(base other 共通)(local 別)

(base other 共通)(local 別)

(base 別)(other 別)(local 別)     (この行だけコンフリクトで良さそうな気がしますが)

(base other 共通)(local 別)

(base other 共通)(local 別)

(base other 共通)(local 別)

(base other 共通)(local 別) <---------- ここまでがコンフリクトの対象

(base other local 共通)

...

...

...

simplemerge でハッシュ表示して、同じハッシュだけど厳密には行の内容違うという可能性はあるのでしょうか?

2017年12月28日木曜日 18時59分49秒 UTC+9 ohira:

[Katsunori FUJIWARA]

藤原です。

2017年12月29日 12:07 ohira <shin....@gmail.com>:

> おおひらです。
>
> 以下のような状況です。
>
> ...
> ...
> ...
> (base other local 共通)
> (base other 共通)(local 別) <---------- ここから
> (base other 共通)(local 別)
> (base other 共通)(local 別)
> (base other 共通)(local 別)
> (base 別)(other 別)(local 別) (この行だけコンフリクトで良さそうな気がしますが)
> (base other 共通)(local 別)
> (base other 共通)(local 別)
> (base other 共通)(local 別)
> (base other 共通)(local 別) <---------- ここまでがコンフリクトの対象
> (base other local 共通)
> ...
> ...
> ...

上記の挙動は想定通りのものです。

Mercurial の builtin マージ処理 (= Python の標準ライブラリの挙動)
や、diff3 (GNU diffutils) 等の CUI 3-way マージツールは、単純に
「行ごとの文字列の一致／不一致」で変更の有無を判定しています。

そのため、「local 側の変更内容」 (= 上記例における「(base other 共
通)(local 別)」な行) が、「other にとって妥当な内容か否か」を判定
することができません。

衝突内容の書き出しの際に、無理に衝突範囲を狭めるよりも、エンドユー
ザの判断に任せる方が安全である、というのは、妥当な選択だと思います。


おおひらさんの「この行だけコンフリクトで良さそうな気がしますが」と
いう感想も:

- local 側の変更は、「先頭の文字列が始まるまでの空白を一つ削除」x35行
- other 側の変更は、「行の中央部分のキャラクタを削除」x1行

という、「変更内容に対する理解」あってのものだと思います。

もしもこれが「変更内容が不明」な 35 行 (local) + 1行 (other) だと
したら、「この行だけコンフリクトで良さそう」とは思わないのではない
かと (笑)


このあたりの「内容を理解している視点で見た場合の、衝突検出の冗長性」
の問題は、本 ML でも以前触れましたが、ファイル内容を理解できるマー
ジ処理、いわゆる semantic merge が可能なツールが必要でしょうね。


暫く前に、Windows 環境＆ C#, VB.net, Java, C 言語限定ではあります
が、semantic merge を行う、その名もずばり SemanticMerge なるツール
の存在を知りました。

https://www.semanticmerge.com/

Mercurial 向け設定方法の説明もあります。

https://users.semanticmerge.com/documentation/how-to-configure/semanticmerge-configuration-guide.shtml#HowtoconfigurewithMercurial

2.0 リリースでは、以下の対応が予定されているとのことなので、導入が
視野に入ってくる人も増えるのでは？

- 動作環境に OSX/Linux が追加
- C++, Objective-C, JavaScript 対応


> simplemerge でハッシュ表示して、同じハッシュだけど厳密には行の内
> 容違うという可能性はあるのでしょうか?

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[ohira]

おおひらです。

回答ありがとうございます。

2017年12月29日金曜日 14時33分41秒 UTC+9 FUJIWARA Katsunori:

藤原です。

2017年12月29日 12:07 ohira <shin....@gmail.com>:

> おおひらです。
>
> 以下のような状況です。
>
> ...
> ...
> ...
> (base other local 共通)
> (base other 共通)(local 別) <---------- ここから
> (base other 共通)(local 別)
> (base other 共通)(local 別)
> (base other 共通)(local 別)
> (base 別)(other 別)(local 別)     (この行だけコンフリクトで良さそうな気がしますが)
> (base other 共通)(local 別)
> (base other 共通)(local 別)
> (base other 共通)(local 別)
> (base other 共通)(local 別) <---------- ここまでがコンフリクトの対象
> (base other local 共通)
> ...
> ...
> ...

上記の挙動は想定通りのものです。

想定のものなのですね。

ありがとうございます。

(自分はどういうことか理解できていませんが)問題無い動作ということで安心いたしました。

 

Mercurial の builtin マージ処理 (= Python の標準ライブラリの挙動)
や、diff3 (GNU diffutils) 等の CUI 3-way マージツールは、単純に
「行ごとの文字列の一致／不一致」で変更の有無を判定しています。

そのため、「local 側の変更内容」 (= 上記例における「(base other 共
通)(local 別)」な行) が、「other にとって妥当な内容か否か」を判定
することができません。

衝突内容の書き出しの際に、無理に衝突範囲を狭めるよりも、エンドユー
ザの判断に任せる方が安全である、というのは、妥当な選択だと思います。


おおひらさんの「この行だけコンフリクトで良さそうな気がしますが」と
いう感想も:

  - local 側の変更は、「先頭の文字列が始まるまでの空白を一つ削除」x35行
  - other 側の変更は、「行の中央部分のキャラクタを削除」x1行

という、「変更内容に対する理解」あってのものだと思います。

そうなんでしょうね。 

もしもこれが「変更内容が不明」な 35 行 (local) + 1行 (other) だと
したら、「この行だけコンフリクトで良さそう」とは思わないのではない
かと (笑)

ここがわからないところです、来年まで考えてみます。 

このあたりの「内容を理解している視点で見た場合の、衝突検出の冗長性」
の問題は、本 ML でも以前触れましたが、ファイル内容を理解できるマー
ジ処理、いわゆる semantic merge が可能なツールが必要でしょうね。


暫く前に、Windows 環境＆ C#, VB.net, Java, C 言語限定ではあります
が、semantic merge を行う、その名もずばり SemanticMerge なるツール
の存在を知りました。

    https://www.semanticmerge.com/

Mercurial 向け設定方法の説明もあります。

    https://users.semanticmerge.com/documentation/how-to-configure/semanticmerge-configuration-guide.shtml#HowtoconfigurewithMercurial

2.0 リリースでは、以下の対応が予定されているとのことなので、導入が
視野に入ってくる人も増えるのでは？

    - 動作環境に OSX/Linux が追加
    - C++, Objective-C, JavaScript 対応

かなり強力なツールのようですね。

keep-merge3 に対応していると良いのですが。