2

トランクにマージしたいよりもブランチがあります。

  • まず、トランクをブランチにマージして、更新します。

  • その後、トランクを(ローカルで)更新して、最後の変更を加えます。

  • 次のステップは、ブランチをトランクにマージすることです。

ローカルトランクで(コミット前に)変更されたファイルを見ると、プロジェクトからのファイルだけでなく、プロジェクトからではないファイルもあることがわかります。

おそらく、これらのファイルはトランクからブランチへの不適切なマージに由来します。

今のところ最良の選択肢は何ですか?トランクの最初のリビジョンからブランチにすべてのファイルをマージしますか(ブランチが作成されたとき)?私はこの方法で多くの対立を得ると思います。トランクから新しいブランチを作成し、プロジェクトからこのブランチファイルを配置しますか?これは、再度テストを行うことを意味します。

何か案は?

御時間ありがとうございます

編集:私のプロジェクトのコミットファイルだけが最良/最速の解決策になる可能性がありますか?(45個のファイルのみをコミットするための90個のファイルは私のプロジェクトからのものです)

4

1 に答える 1

2

変更されたファイルは、ファイルの内容が変更されているか、またはそれらのプロパティ値が変更されていますか?

svn:mergeinfo誰かが、マージによって変更されたファイルが多すぎると言うのを聞くたびに、通常、プロパティに問題があることがわかります。Subversion は、このプロパティを設定することでマージを追跡します。プロジェクトのルートで常にマージを行う場合、ルート ディレクトリのみがこのプロパティ セットを持ち、すべてのファイルがそれを共有します。個々のファイルのマージを行う場合、これらすべてのファイルにはsvn:mergeinfoプロパティ セットがあり、マージを行うたびに、これらすべてのファイルのファイルも変更する必要があるため、これらのファイルのそれぞれが変更されますsvn:mergeinfo

何をするにしても、マージを排除するためにそれらのファイルを元に戻さないでください。それは単に事態を悪化させます。これらのsvn:mergeinfoファイルはそれらのリビジョンに対してマージされていないことが表示され、次にマージを行うと、Subversion はマージをやり直し、svn:mergeinfoもう一度更新します。

于 2012-12-06T14:35:11.263 に答える