Subversionでツリーが競合するのはなぜですか？
私は自分のトランクの機能ブランチを持っていて、定期的に自分のトランクからの変更を自分のブランチにマージしていて、すべてがうまくいっていました。今日、私はブランチをトランクにマージして戻し、ブランチの作成後にトランクに追加されたファイルに「ツリーの衝突」としてフラグを立てました。将来、これを回避する方法はありますか？
私はこれらが適切にフラグを立てられているとは思わない。
私はGaryが与えたリンクを読んで解決策を見つけました（そして私はこの方法に従うことを提案します）。
ツリーの衝突を解決するためにまとめると、あなたの作業ディレクトリをSVNクライアント1.6.xでコミットすることができます。
svn resolve --accept working -R .
.は競合しているディレクトリです。
WARNING： "作業ディレクトリをコミットする"とは、サンドボックス構造がコミットする構造になることを意味します。サンドボックスからファイルを削除すると、それらもリポジトリから削除されます。これは競合しているディレクトリにのみ適用されます。
このようにして、現在のディレクトリ（--resolve）から始めて、サンドボックス内の作業コピー（--accept working）を再帰的に受け入れ（-R）、SVNに競合（.）の解決を提案します。
TortoiseSVNでは、右クリックで[解決]を選択すると、実際にこの問題が解決します。
Subversion 1.6はディレクトリレベルでの衝突をカバーするためにTree Conflictsを追加しました。良い例は、あなたがローカルにファイルを削除した後、アップデートがそのファイルのテキスト変更を停止させようとする場合です。もう1つは、編集中のファイルのSubversion Renameがある場合です。追加/削除アクションです。
CollabNetのSubversionブログには、 ツリーの競合 に関する素晴らしい記事があります。
私はこれがあなたに起こっているのかどうかわかりません、しかし時々私はマージするために間違ったディレクトリを選びます、そして、私はすべてのファイルが完全にうまく見えてもこのエラーを得ます。
例：
/ svn/Project/branches/some-branch /ソースを/ svn/Project/trunkにマージ--->ツリーの衝突
/ svn/Project/branches/some-branchを/ svn/Project/trunkにマージします---> OK
これはばかげた間違いかもしれませんが、あなたはそれがもっと複雑なものだと思うのでそれはいつも明白ではありません。
ここで何が起こっているのかは次のとおりです。あなたはあなたのトランク上に新しいファイルを作成し、そしてあなたはそれをあなたのブランチにマージします。マージコミットでは、このファイルはあなたのブランチにも作成されます。
ブランチをトランクにマージするとき、SVNは同じことをもう一度試みます。マージコミットでファイルがブランチに作成され、トランクに作成しようとしますが、それはすでに存在します。これはツリーの衝突を引き起こします。
これを回避する方法は、特別なマージを行うことです。再統合です。これは--reintegrateスイッチで実現できます。
これについてはドキュメントで読むことができます。 http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate
ただし、ブランチをトランクにマージするときには、基礎となる数学はまったく異なります。あなたのフィーチャーブランチは、トランクの変更とプライベートブランチの変更の両方が混ざったものになっているので、コピーするリビジョンの連続した簡単な範囲はありません。 --reintegrateオプションを指定することで、あなたのブランチに固有の変更だけを注意深く複製するようSubversionに求めています。 （そして実際には、最新のトランクツリーと最新のブランチツリーを比較することによってこれを行います。結果として生じる違いは、正確にあなたのブランチの変更です！）
ブランチを再統合した後は、それを削除することを強くお勧めします。そうしないと、トランクからブランチへの別の方向にマージするときはいつでもtreeconflictsが発生し続けるでしょう。 （前述とまったく同じ理由で）
これを回避する方法もありますが、試したことはありません。この記事でそれを読むことができます：v1.6でのSubversionブランチの再統合
これは、同じバージョンのクライアントを使用していないことが原因である可能性があります。
同じリポジトリに対してバージョン1.5クライアントとバージョン1.6クライアントを使用すると、この種の問題が発生する可能性があります。 （私は噛まれたばかりでした。）
編集/削除/ファイルの近くのどこかに来なかったために意味のないツリーの衝突が発生した場合、mergeコマンドにエラーがあった可能性もあります。
起こり得ることは、あなたが以前に現在のマージに含めているたくさんの変更を既にマージしているということです。たとえば、トランクで誰かがファイルを編集し、後でそのファイルの名前を変更したとします。最初のマージで編集を含め、次に2番目のマージで編集と名前の変更（基本的に削除）の両方を含めると、ツリーの競合が発生します。これは、以前にマージされた編集が自分のものとして表示され、削除が自動的に実行されないためです。
これは少なくとも1.4のリポジトリで発生する可能性があります。1.5で導入されたマージトラッキングがここで役立つかどうかはわかりません。
私は同様の問題を抱えていました。実際に私のために働いていた唯一のことは以下と衝突したサブディレクトリを削除することでした：
svn delete --force ./SUB_DIR_NAME
それから、作業コピーの別のルートディレクトリからそれらを再度コピーします。
svn copy ROOT_DIR_NAME/SUB_DIR_NAME
それから
svn cleanup
そして
svn add *
最後の警告で警告を受けるかもしれませんが、無視して最後に
svn ci .
私は今日この問題にも遭遇しました、私の特定の問題はおそらくあなたの問題に関連していません。ファイルのリストを調べた後、自分がしたことに気付きました。私は一時的にあるアセンブリ内のファイルを別のアセンブリから使用していました。私はたくさんの変更を加えましたが、SVNの履歴を孤立させたくないので、私のブランチで他のアセンブリのフォルダからファイルを移動しました。これはSVNによって追跡されないので、ファイルが削除されてから再度追加されたように見えます。これは結果的にツリーの衝突を引き起こします。
ファイルを元に戻し、コミットしてから、次にを使用してブランチをマージすることで、問題を解決しました。その後、ファイルを元に戻しました。 :)それはトリックをやるようだった。
私はこれと同じ問題を抱えていて、 これらの指示を使ってマージをやり直すことでそれを解決しました 。基本的に、履歴やツリーの競合についてそれほど煩わされることなく、SVNの "2-URL merge"を使ってtrunkを現在のブランチの状態に更新します。手動で114ツリーの競合を修正することから私を救った。
自分の望むだけでなく歴史も保存しているかどうかはわかりませんが、私の場合はそれだけの価値がありました。
私は時々遭遇するシナリオ：
トランクがあり、そこからリリースブランチを作成したとします。トランクを変更した後（特に "some-dir"ディレクトリを作成した後）、後でリリースブランチにマージしたいfeature/fixブランチを作成します（変更は十分に小さく、feature/fixはリリースにとって重要です） 。
trunk -- ... -- create "some-dir" -- ...
\ \-feature/fix branch
\- release branch
その後、feature/fixブランチをreleaseブランチに直接マージしようとすると、（ディレクトリがfeature/fixブランチに存在していなくても）ツリーの競合が発生します。
svn status
! C some-dir
> local missing or deleted or moved away, incoming file edit upon merge
そのため、feature/fixブランチをマージする前に "some-dir"ディレクトリを作成したfeature/fixブランチを作成する前に、trunkで行われたコミットを明示的にマージする必要があります。
私はよく忘れていますが、それはgitでは必要ないからです。
今日まで、少なくとも3か月前から、ブランチをトランクにマージしようとすると何百ものツリーの衝突に遭遇しました（TortoiseSVN 1.11を使用）。リベースの有無にかかわらず、ところで。 2004年にTortoiseSVNをv1から使用していましたが、ずっとブランチを統合していました。最近どうなったかな？
それで今日私はこの簡単な実験を実行し、そして私はこれらのクレイジーな衝突を引き起こしているものを見つけました：
- 私はトランクを393番に分岐した。
- 私は何十ものファイルをランダムに修正し、そして新しいファイルを作成しました。
- 私はコミットしました。今@ 395（同僚が自分のものを実行するために394で分岐した）。
- それから私はブランチをトランクに再統合しようと試みました、テストのみ。ウィザードでのTortoiseSVNの推奨に従って、「すべてのリビジョンをマージする（統合する）には、そのボックスを空のままにします」。これを達成するために、私はtrunkフォルダを右クリックし、 "/ path /から/ branchへ"からTortoiseSVN> Mergeを選び、そしてIrev範囲を空のままにしますダイアログでアドバイスされるように。
ディスカッション：（添付ファイルを参照）
すべてのリビジョン...なに？ クライアントが「ターゲットのすべてのリビジョン！（trunk）」を参照していたに違いないことを知っていることはほとんどありませんでした。そのブランチを再統合する過程で、 "Merging revisions 1-HEAD"という言及を見ました。ああ、神様。悪魔が貧しい、あなたはここであなたの死に陥っています。その支部は393年に誕生しました、あなたは神のためにその出生証明書を読むことができませんか？ 
解決策：
- Wizがアドバイスしていることとは反対に、範囲を指定してください。これは、ブランチのすべてのリビジョンをカバーします。したがって、394-HEAD;です。
- もう一度マージテストを実行して、葉巻をもらってください。 （
![see second attachment]()
）.
Moral：なぜ彼らがまだそのバグを修正していないのか理解できません。私は彼らと一緒にこれを報告するのに時間をかけなければなりません。