5

Perforce リポジトリのブランチには次のような状況があります。メインラインの「トランク」と 2 つのリリース ブランチ「1.0」と「1.1」があります。顧客固有の変更を含むブランチ「顧客」が 1.0 ブランチから分岐しました。現在、顧客はバージョン 1.1 に移行したいと考えています。1.1 ブランチをカスタマー ブランチにマージするにはどうすればよいですか? 顧客固有の変更は、1.1 の「上位」のままにする必要があります。

影響を受ける 1 つのファイルの図を次に示します。

1.1                      -(1)---(2)---(3)
                        /           \     \
                       /             \     \
trunk   100--(101)-(102)--103---104---105---106---107
           \
            \
1.0          ---1-----2--...
                 \
                  \
customer           ---1-----2----*3*

私が見ているファイルの現在のバージョンは、customer ブランチのリビジョン 3 です。

ブランチ「1.1」をターゲット「顧客」に統合することを選択した場合、両方の共通の祖先が見つかり (メインラインのリビジョン 100)、そこから 1.1 ブランチの先端に至るすべてのリビジョンがマージされると予想していました (括弧内）。

代わりに、Perforce は 1.1 ブランチのリビジョン 1 から 3 をマージすることのみを提案しますが、これは以前にメインラインで行われた必要な変更を見逃しているため失敗します。

各ファイルを手動で確認してマージするリビジョンを選択することなく、Perforce にこれを実行させるにはどうすればよいでしょうか? 分岐戦略が不適切ではないでしょうか。他に何をすべきですか？

4

3 に答える 3

2

1.1ブランチからリビジョン3を統合しようとすると、Perforceはその特定のブランチの変更を統合していることを通知するだけですが、リビジョン1にはすでにトランクリビジョン101と102が含まれています。マージすると、Perforceはトランクリビジョン100を共通として識別します。紛争解決の祖先。

私の経験では、あなたが行おうとしている統合はうまくいくはずです。統合されたソースに変更がないのを見ていますか（不適切な競合解決では説明できません）、それとも単にの出力を見ているだけp4 interchangesですか？

于 2010-10-12T15:26:36.480 に答える
2

お客様の変更をトランクにマージすることを強くお勧めします。数か月後に顧客が 2.0 へのアップグレードとカスタム変更を希望する場合、メンテナンスの悪夢は続くでしょう。

顧客の変更をメイン プロジェクトに反映させたくない場合は、時間をかけてコードを再構築し、ビルド フラグまたはビルド構成ファイルを使用して顧客の望ましい動作を公開できるようにします。両方のビルド構成を CI で実行して、将来の変更によって顧客のビルドが壊れないようにします。

于 2010-10-15T18:40:26.457 に答える
0

統合を簡単にするために、特定のブランチ trunk_to_custer および 1.1_to_customer を作成してから、次を発行します。

cd customer-workspace
p4 integ -b trunk_to_customer @change-number-at-which-1.1-was-branched
p4 resolve

おそらく中間の送信がここにあり、その後

p4 integ -b 1.1_to_customer 
p4 resolve
p4 submit
于 2010-10-12T11:32:30.613 に答える