Subversion 機能ブランチから 持ち越されたものには、別の機能ブランチからの変更が必要です
「FeatureA」と「FeatureB」の 2 つの機能ブランチがあります。FeatureA は完成していますが、次のリリースに入れるかどうかが確認されていないため、trunk にはマージされません。
FeatureB は進行中であり、実際に FeatureA に適用されたdbmlにいくつかの変更が必要であることが判明しました。
いくつかのオプションがあります。そのうちの 1 つは、dbml と関連ファイルのみをマージすることです。作業コピーのルートからマージ/更新/コミットなどを行うのがベスト プラクティスであることは承知していますが、先に進むとどのような問題が発生する可能性がありますか?
必要なFeatureBからFeatureAブランチへのすべてのリビジョンをマージできます（subversionはそれを行わないので、マージされたリビジョンに注意することをお勧めします-svnmerge.pyツールはそれを行いますが、私はむしろ自分で記録を保持したいと思います）。次に、不要な変更を元に戻す/削除します（前の質問で述べたように、リビジョンの一部であるなど）。
「後で、FeatureAとFeatureBをトランクとマージするときに、元に戻した変更がFeatureBブランチの他の変更から独立していれば、競合は発生しないはずです。」しかし、これが本当かどうかはわかりません。つまり、FeatureAとFeatureBに共通の変更がある場合、これらの変更がトランクにマージされるときに、競合/二重の変更がありますか？
回避策は、安全なアプローチを取り、困難なアカウンティングを自分で行うことです。これにより、後でトランクでマージが実行されたときに変更がまったく繰り返されなくなります。
単純化する1つの方法は、コードでフラグを使用してFeatureAをオンまたはオフにすることです。そうすれば、FeatureAはすでにトランクとマージできます。
結局、私はマネージャーと合意することでこの問題を解決しました。この問題が発生した場合は、2つの機能を1つのブランチに構築するだけで、それらをまとめてテストする必要があるということです。
「サブツリーmergeinfo」の問題に直面していると思います。専門家は、これは避けるのが最善だと言います。ただし、大規模なブランチのルートでマージを実行すると時間がかかる場合があるため、パフォーマンスも問題になります。これらのパフォーマンスの問題を回避するために、サブツリーのマージを行い、結果のサブツリーの mergeinfo がいくつかの問題を引き起こすことを確認できました。したがって、可能な限り避ける必要があります。
svn のマージは 3 つのパラメーターで記述されていることを覚えておくと便利です。リビジョン X をリビジョン Y に変換する変更を行い、それらの変更をリビジョン Z に適用します。これは、作業コピーの使用についてあなたが言ったことと矛盾すると思います。
したがって、1 つのアプローチは、機能 A ブランチ (開始リビジョンと終了リビジョンで識別される) で dbml に加えた変更を見つけ、それらの変更を機能 B ブランチに適用することです。
バージョン 1.6 以降の Subversion はマージをトレースするため、これ以上の問題は発生しません。