問題タブ [svn-reintegrate]

機能ブランチをマージして戻す前に、常に機能ブランチを同期する場合。なぜあなたは本当に--reintegrateオプションを使わなければならないのですか？

Subversionの本には次のように書かれています：

ただし、ブランチをトランクにマージする場合、基礎となる数学はまったく異なります。機能ブランチは、複製されたトランクの変更とプライベート ブランチの変更の両方の寄せ集めになっているため、コピーする単純な連続した範囲のリビジョンはありません。--reintegrate オプションを指定することにより、Subversion に、ブランチに固有の変更のみを慎重にレプリケートするように依頼します。(実際、最新のトランク ツリーと最新のブランチ ツリーを比較することでこれを行います。結果の違いは、まさにブランチの変更です!)

したがって、この--reintegrateオプションは機能ブランチに固有の変更のみをマージします。しかし、マージの前に常に同期する場合 (機能ブランチでの競合に対処するために推奨される方法です)、ブランチ間の変更は機能ブランチに固有の変更のみですよね? また、Subversion がターゲット ブランチに既にあるコードをマージしようとしても、何もしませんよね?

ブログ投稿で、Mark Phippard は次のように書いています。

これらの同期されたリビジョンを含めると、トランクに既に存在する変更をマージして戻します。これにより、不必要で紛らわしい競合が発生します。

reintegrate を削除すると不必要な競合が発生する例はありますか?

Subversion1.5リポジトリのトランクに開発ブランチを再統合しようとしています。この操作の前に、トランクから開発ブランチへのすべての変更をマージしました。ブランチからの変更を再統合しようとすると、次のエラーメッセージが表示されます。

その後、メッセージは私のプロジェクトのいくつかのフォルダについて不平を言い続けます。しかし、トランクから開発ブランチへの変更を再度マージしようとすると、TortoiseSVNは、マージするものがないことを通知します（以前にすべての変更をマージしたため）。

私はここからの指示に従おうとしています：http ：//svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html 、しかしそのような問題を解決することについては何もありません。

何か案は？おそらく、トランクを削除してから、ブランチのコピーを作成する必要がありますか？しかし、それが安全かどうかはよくわかりません。

も参照してください

--reintegrateを使用したsvnmergeは範囲の欠落について文句を言いますが、mergeinfoは正しいようです

ブランチから SVN のトランクにマージするときに再統合する必要があることについて、かなり読んだことがあります (外部リポジトリのマージに関する記事は本当に役に立ちました)。

問題は、人々がトランクからブランチを定期的に更新しているという事実から来ているようです。つまり、最終的なマージバックは反射的です。

私のユースケースでは、ブランチを安定させてバグを修正するまで存続するリリース ブランチを作成したいと考えています。安定性を維持するために、トランクからマージしたくはありませんが、トランクがすべてのバグ修正を無料で取得できるように、定期的にリリース ブランチから修正をマージしたいと考えています。また、トランクにマージするためにQAが終了するまで待ちたくありません。したがって、次のことを行います。

1. ブランチを作成する
2. ブランチ (およびトランク) を定期的に変更する
3. 定期的に (おそらく毎日) トランクにマージして戻します

トランクからマージすることは決してないので、再統合によって修正されるように設計されている問題について心配する必要はないと思います。このアプローチに問題はありますか？

新しい機能に多くの作業を必要とする大きなプロジェクトがあるので、この作業を行うためにブランチを使用することを計画しました。私はこれまでこれを行う必要はありませんでした。経験豊富なSubversionユーザーから、物事がスムーズに「機能する」はずだという保証を得たいと思っていました。

私が特に懸念しているのは、Subversionがブランチとトランクの間で削除、名前変更、移動されたファイルをどれだけうまく処理できるかということです。つまり、ブランチで複数のファイルが削除または名前変更/移動されたが、それらのファイルが引き続き使用され、トランクで変更を受け取った場合でも、トランクとのマージは問題なく続行されます（もちろん、必要に応じてブランチを作り直します）。 ）？

また、ブランチをトランクと再統合するときに、ファイルの名前（または存在）がトランクとブランチで大きく異なる場合、再統合は困難になりますか？ブランチで削除（移動）されたファイルはトランクで削除（移動）されますか、それともファイルが残り、競合が発生しますか？

SVNの本は私にとってこれらの質問を解決しなかったので、あなたの経験は大いにありがたいです。ありがとうございました！

この方法でブランチをマージしやすくなり、競合が少なくなります。

トランクを新しいブランチにコピーし、機能ブランチとマージします。完了したら、新しいブランチをトランクにマージします。この手法は、MercurialやGitのリベースによく似ています。

以前は、トランクから機能ブランチに変更されたものをマージしていました。しかし、後で機能ブランチをトランクにマージすると、トランクからの一部が再びトランクにマージされ、多くの競合が発生しました。再統合マージの選択肢がありますが、それは私にはうまくいかなかったようです。

誰かが同様の破壊リベースをしますか？私は最近これを始めたばかりで、副作用は見られませんでした。これにより、予期しない問題が発生しますか？

私はSVNのマージ/再統合について頭を悩ませようとしており、これらの記事/本を読んでいます:

http://svnbook.red-bean.com/en/1.5/index.html
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

同期されたリビジョンをトランクへのマージ (リフレクティブ/サイクリック マージ) に含めることが問題である理由がわからないため、明らかに完全には理解していません。リビジョンを除外しない理由はわかります。

トランクのファイル A の行がブランチのファイル A' にマージされてからトランクにマージされた場合、A と A' の間に違いはないので、競合はありませんか? 「トランクに既に存在する[merging] back changes 」 が問題になるのはなぜですか?

私は競合シナリオを複製して、再統合が私のために何をしているかを理解しようとしていますが、さらに混乱しているのは次のシナリオです。

1. トランク (r4) で変更をコミットする
2. r4 をブランチにマージしてコミットする (r5)
3. ブランチで変更をコミットする (r6)
4. 次のいずれかの方法でブランチをトランクにマージします。
   • リビジョン範囲 r5 ～ r6 をトランクにマージ - 競合が発生する、または
   • r5 をトランクにマージしてから、r6 をトランクにマージ - 競合は発生しません

SmartSVN 6.6 と SVN 1.6 を使用しています。各リビジョンを個別にマージする場合と比較して、リビジョン範囲をマージする場合に結果が異なるのはなぜですか? そして最終的に、反射マージを含めることが問題になるのはなぜですか?

私は再統合している2つのブランチを持っています

両方のブランチに、調整したくない同じ CFG ファイルがあります。
それらをバージョン管理しておきたいが、調整はしないでください。

指定したファイルをこのプロセスから除外する方法を知っていますか?

次の醜いことをしました：

では、どうすれば別のものを達成できreintegrateますか?

これまでに何を試しましたか？

• まあ、明らかなマージ - これは残酷に失敗します!
• パッチを作成して適用しますtrunk（svnのみを使用せずにファイルを比較するため、これは機能するはずです...）
• 別のブランチ@トランクr101を作成し、最初のブランチからのすべての変更をマージします-残酷に失敗します:)

編集：

トランクのマージ情報には、目的のブランチのマージされたリビジョンは表示されません (r101 でロールバックしたため)。