3

したがって、このプロジェクトでは、トランクとブランチ1の2つのリリースで並行作業が行われています。ある時点で、「rel1のビルドをこれ以上作成しないでください。rel2のバグを修正してください」と言われます。そこで、トランクにも適用できるbranch1のバグ修正を行います。後で、「これらの既知のバグでrel1をリリースすると、大きなPITAになります。rel1でも修正してください」と言われます。

したがって、私の質問は（〜/ rel1はトランクの現在の変更されていない作業コピーです。RevM、RevNは、トランクにマージして戻したい一連のリビジョンのbranch1のリビジョン番号です）：

私がするなら

cd ~/rel1
svn merge -r RevM:RevN ^/branch1

svn merge --reintegrate後でブランチからトランクにどのように影響しますか？の前にbranch1に改訂があり、RevM後にさらに多くの改訂があることを念頭に置いてRevNください。特に、最終的に再統合する場合、最初に行う必要があったように、元々rel1で修正を行い、それらをrel2にマージしたかのようになりますか？

4

1 に答える 1

7

枝から幹へのさくらんぼ狩りの変化は、いつも私の心をひねっています。これがあなたのケースで機能するはずの解決策です。チェリーが選んだ変更がブランチに再びマージされるのをブロックするのがコツです。

cd ~/rel1
svn merge -r RevM:RevN ^/branch1
svn commit -m "cherry pick RevM:RevN from branch1 into rel1"

ここで、このコミットによってRevXが作成されたとします。ブランチに移動し、オプションを使用して、このリビジョンを今後のマージアクションからブロックし--record-onlyます。

cd ../branch1
svn merge -c RevX --record-only ^/rel1
svn commit -m "mark RevX as already merged to block it from future merge actions"

これで、通常どおり、さらに変更をからにマージし、終了したらブランチをrel1に再統合できるようrel1にbranch1なります。

于 2012-07-20T23:01:41.077 に答える