1

Mercurialでプロジェクトを実行していて、ファイルが自動的にマージできるはずなのに、ファイルを手動でマージする必要がある状況をたくさん見つけています。これらの分野でMercurialを支援するためにMercurialに提供できるオプションがあるかどうか疑問に思っています。

プロジェクトには、プロジェクトで編集できない数百のファイルを含む基盤となるプラットフォームがあります。プラットフォームが更新されると、プロジェクトはMercurialの外部でこれらのコアファイルの更新されたバージョンを取得します。私が繰り返し見ているシーケンスは次のとおりです。

中央開発システム（コアプラットフォーム更新メカニズムにリンクされている）：

  • コアプラットフォームの新しいバージョンを入手してください。
  • これらの変更をコミットします。hg commit -m "New platform release"
  • 中央のMercurialサーバーにプッシュする

私のLinuxボックスの場合：

  • ローカル変更をコミットする
  • 中央のMercurialサーバーからプルし、マージしてみてください
  • コアファイルでのマージの競合を見つける

マージする必要があった最後の2つのコアファイルは、ベースバージョンとローカルバージョンの間で変更はありません（アクセス時間はビルド中に更新されますが、内容は同じです）。唯一の変更は、マージしているリモートリビジョンにあります。

私が知っている唯一の非標準構成は、中央のMercurialインスタンスがRhodecodeで実行されており、Redmineリポジトリを更新するためのコミットフックが設定されていることです。

マージを理解するのに役立つMercurialで構成できるものは他にありますか？

4

1 に答える 1

1

とのマージをやり直して、マージ--debugに関する詳細情報を取得できます。つまり、リポジトリを取得して実行します

$ cd ..
$ hg clone my-project -r 123 -r 456 merge-test

ここで、123と456は、詳しく調べたいマージの2つの親です。次に実行します

$ hg merge --debug

Mercurialの言うことを見るために。マージするブランチでのみファイルfooが変更された場合は、次のようになります。

$ hg merge --debug
  searching for copies back to rev 2
resolving manifests
 overwrite: False, partial: False
 ancestor: 932f5550d0ce, local: b0c286a4a76d+, remote: c491d1593652
 foo: remote is newer -> g
updating: foo 1/1 files (100.00%)
getting foo
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

ここで私は改訂中b0c286a4a76dで、とマージしましc491d1593652た。

使用することもできます

$ hg status --rev "ancestor(b0c286a4a76d, c491d1593652)" --rev "c491d1593652"
M foo
$ hg status --rev "ancestor(b0c286a4a76d, c491d1593652)" --rev "b0c286a4a76d"
M bar

祖先リビジョンとマージする2つのチェンジセットの間で変更されたファイルを再確認します。foo上に、私が一方のブランチともう一方のブランチで変更したことがわかりますbar。

プラットフォームファイルが両方のステータスリストに表示されている場合は、手順に問題があり、これがマージの競合を説明している可能性があります。

何が悪かったのかを理解するのにこれだけでは不十分な場合は、Mercurialメーリングリストでこの質問をすることをお勧めします。これは、ディスカッションやバグハンティングに最適な場所です。StackOverflowよりもはるかに優れています。

于 2012-04-25T15:17:52.760 に答える