15

シーン:ベンダーから定期的に更新される、購入した Web アプリケーション。次に、外観を大幅にカスタマイズし、独自の機能を追加したり、ベンダーが対応する前にバグを修正したりします。バージョン管理については、新しいリリースを受け取るたびに、「ベンダー ブランチ」</a> モデルに従って Subversion を使用しています。これには、バージョン管理されたシステムのバニラ コピーがあるという追加の利点があります。

問題: Mercurial に切り替えたいと考えており、おそらく安定/デフォルトの分岐パターンに従います。Mercurial は、ベンダーからリリースを 1 つだけ受け取り、そこから開発を開始する場合に最適です。しかし、何らかの理由で、ベンダーからの将来のリリースをどのように処理するかについて頭を悩ませています。

嘆願: Mercurial スタイルの「ベンダー ブランチ」に関するヘルプをいただければ幸いです。

4

2 に答える 2

14

説明したように名前付きブランチを使用することは良い選択ですが (唯一の選択ではありません)、このプロセスを容易にするために、よく知られている場所でいくつかの個別のクローンを使用することをお勧めします。http://host/hg/インストール用の hgweb (以前の hgwebdir) のふりをすると (ただし、ssh:// もうまく機能しますが)、次のようになります。

  • http://host/hg/vendor
  • http://host/hg/custom

データがベンダーからカスタムに流れるが、逆方向には流れない 2 つの別個のリポジトリ。名前付きブランチは、との両方を持つdefault唯一のブランチです。vendorcustomdefaultstable

ベンダーから新しいコード ドロップを受け取ったら、それをvendorリポジトリの作業ディレクトリに展開してから、次のコマンドを実行します。

hg addremove
hg commit -m 'new drop from vendor, version number x.x.x'

そのレポの履歴はvendor直線的であり、あなたが書いたものは決してありません。

次に、リポジトリのローカル クローンで次のようにcustomします。

hg update default     # update to the latest head in your default branch
hg pull http://host/hg/vendor   # bring in the new changes from vendor as a new head
hg merge tip          # merge _your_ most recent default cset with their new drop

そして、デフォルトのローカル チャンスを新しいコード ドロップとマージする作業を行います。マージに満足したら (テスト パスなど)、ローカル クローンから にプッシュしますhttp://host/hg/custom。

このプロセスは必要に応じて繰り返すことができ、あなたの履歴と彼らの履歴を適切に分離し、チームの全員がベンダーからの新しいコードドロップを受け入れる責任を負わずdefault/stable、単一のリポジトリでの通常のセットアップだけに関心を持つことができますhttp://host/hg/custom.

于 2010-10-22T16:14:58.647 に答える
9

default+stable ブランチへの追加ブランチとしてベンダー ブランチを使用します。最終的には次のようになります。

V1----V2-------------V3---------V4     Vendor
 \     \              \          \
  D1----D2---D3--D4-D5-D6-D7-D8---D9   default
                  \           \    \
                   S1----------S2---S3 stable
于 2010-10-22T15:04:16.710 に答える