web-dev-qa-db-ja.com

Mercurial:同じバージョンで複数のリポジトリを追跡する

プロジェクトでMercurialを使用しています。

今、私は次の問題に直面しています。独自の履歴を持つ2つの別々のMercurialリポジトリがあります。ここで、両方に同じブランチ/ブックマークを付ける必要があります。

しかし、これは多くの潜在的な問題につながります。

  • 誰かが最初のレポをマージし、2番目に同じことを忘れた
  • ブックマークを作成し、それを2番目のリポジトリーにのみ伝搬しました

だから私はMercurialサブリポジトリを使用することでうまくいくと思っていました。しかし、私はこれが当てはまらないことを理解しました。

別の方法としては、最初のリポジトリと同じフォルダに2番目のリポジトリを置くだけです。しかし、その後、2番目のレポの履歴を失います。そして、この方法は実際には醜いです。

Mercurial内で私の問題を解決する方法はありますか?

AFAIK Mercurialはそれに耐えられないので、今私は本当にgitに切り替えることを検討しています。私が間違っていることを証明してください

6

Mercurialでは、2番目の関連リポジトリはブランチのように動作し、管理するのにほぼ同じ労力を要します。たとえば、多くのプロジェクトにはstableブランチがあり、最終的にdefaultに関して更新する必要があります。

あなたの場合、リポジトリの1つをマージポイントとして指定し、その作業ディレクトリの1つを使用して、他のリポジトリから整然とプルアンドプッシュします。

簡単にするために、作業ディレクトリの.hg/hgrcに2番目のリポジトリのエイリアスを作成できます。

[paths]
default = ssh://[email protected]/apalala/grako
remote = ssh://localhost/backups/grako

これで、次を使用できます。

$ hg incoming remote

リモートリポジトリでのみ行われた更新を知るため。

$ hg outgoing remote

エクスポートされる変更を知るため。

マージするには:

$ hg pull
$ hg update
$ hg pull remote
$ hg merge
$ hg Push
$ hg Push remote

同じブランチ内の同じファイルが両方のリポジトリに対して変更されている場合、マージの競合が必ず発生するという問題が残ります。しかし、ブランチが適切に使用されていない場合、単一のリポジトリに対しても同じことが起こります。

現在、上記の問題を解決するために、多くのチームでは、関連するすべてのコミットセットが、選択的に確認およびマージできるブランチに属している必要があります。この方法を適用すると、選択した作業ディレクトリでのマージを、ブランチごとに2つ以上のリポジトリに実行できます。

1
Apalala