Subversionでツリーの競合が発生するのはなぜですか？

私は私のトランクの機能ブランチを持っていて、私のトランクから私のブランチへの変更を定期的にマージしていて、すべてがうまく機能していました。今日、私はブランチをトランクにマージし、ブランチの作成後にトランクに追加されたすべてのファイルに「ツリーの競合」のフラグが付けられました。これを将来的に回避する方法はありますか？

これらは適切にフラグが付けられているとは思いません。

私はゲイリーが与えたリンクを読んでいる解決策を見つけました（そして私はこの方法に従うことをお勧めします）。

要約すると、作業ディレクトリをSVNクライアント1.6.xにコミットすることでツリーの競合を解決できます。

svn resolve --accept working -R .

.競合しているディレクトリはどこですか。

警告：「作業ディレクトリをコミットしています」とは、サンドボックスの構造がコミットする構造になることを意味します。たとえば、サンドボックスからファイルを削除した場合、それらもリポジトリから削除されます。これは、競合するディレクトリにのみ適用されます。

このように、現在のディレクトリ（）から始めて、SVNに競合を解決（--resolve）し、サンドボックス内の作業コピー（--accept working）を再帰的に（-R）受け入れることをお勧めします.。

TortoiseSVNでは、右クリックで[解決済み]を選択すると、この問題が実際に解決されます。

Subversion 1.6では、ディレクトリレベルでの競合をカバーするためにツリーの競合が追加されました。良い例は、ファイルをローカルで削除した後、更新がそのファイルのテキストの変更を取り消そうとする場合です。もう1つは、編集しているファイルのSubversion Renameがある場合です。これは、追加/削除アクションであるためです。

CollabNetのSubversionブログには、ツリーの競合に関する素晴らしい記事があります。

私の経験では、SVNはフォルダーを削除するたびにツリーの競合を発生させます。理由はないようです。

私のコードで作業しているのは私だけです->ディレクトリを削除します->コミット->競合します！

Gitに切り替えるのが待ちきれません。

明確にする必要があります-私はSubclipseを使用しています。それがおそらく問題です！繰り返しますが、切り替えるのが待ちきれません...

これが発生しているかどうかはわかりませんが、マージするディレクトリを誤って選択すると、すべてのファイルが完全に正常に表示されているにもかかわらず、このエラーが発生することがあります。

例：

/ svn / Project / branches / some-branch / Sourcesを/ 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クライアントを使用すると、この種の問題が発生する可能性があります。（私は自分に噛まれたばかりです。）

ファイルの近くのどこも編集/削除/来なかったために意味のないツリーの競合が発生した場合は、マージコマンドでエラーが発生した可能性もあります。

発生する可能性があるのは、以前に現在のマージに含めている一連の変更をすでにマージしていることです。たとえば、トランクでは誰かがファイルを編集し、後で名前を変更します。最初のマージに編集を含め、2番目のマージに編集と名前変更の両方（基本的には削除）を含めると、ツリーの競合も発生します。これは、以前にマージされた編集が自分の編集として表示されるため、削除が自動的に実行されないためです。

これは少なくとも1.4リポジトリで発生する可能性があります。1.5で導入されたマージ追跡がここで役立つかどうかはわかりません。

今日まで、少なくとも3か月前から、ブランチを（TortoiseSVN 1.11を使用して）トランクにマージしようとすると、何百ものツリーの競合に定期的に遭遇しました。ちなみに、リベースかどうかは関係ありません。TortoiseSVNはv1から2004年に使用してきましたが、以前からブランチを再統合してきました。最近何かが起こったに違いないと思いますか？

今日、私はこの簡単な実験を実行し、これらのクレイジーな衝突を引き起こしているものを見つけました：

1. トランク@ 393を分岐しました。
2. 数十のファイルをランダムに変更したり、新しいファイルを作成したりしました。
3. コミットしました。今@ 395（同僚は394で分岐して自分の仕事をしました）。
4. 次に、ブランチをトランクに再統合して、テストのみを試みました。ウィザードでのTortoiseSVNの推奨に従います：「すべてのリビジョンをマージ（再統合）するには、そのボックスを空のままにします」。これを実現するには、トランクフォルダーを右クリックして、「TortoiseSVN> Merge、from / path / to / branch」を選択し、ダイアログでアドバイスされているように、回転範囲を空のままにしました。

ディスカッション：（添付を参照）

すべての改訂 ...何の？クライアントが「ターゲットのすべてのリビジョン！（トランク）」を参照している必要があることはほとんどわかりませんでした。そのブランチを再統合する過程で、「リビジョン1のマージをマージする」という言及を見ました。ああ、神様。貧しい悪魔、あなたはここであなたの死に落ちています。その枝は@ 393で生まれました、神のために、その出生証明書を読むことができませんか？

解決：

1. ウィズの助言に反して、ブランチのライフのすべてのリビジョンをカバーする範囲を指定してください！したがって、394-HEAD。
2. ここで再びマージテストを実行し、葉巻を入手します。（）。

道徳： 彼らがなぜそのバグをまだ修正していないのか理解できません。それはバグなので、申し訳ありません。私は彼らと一緒にこれを報告するために時間をかけるべきです。

今日もこの問題に遭遇しましたが、私の特定の問題はおそらくあなたの問題とは関係ありません。ファイルのリストを調べた後、私は自分のしたことに気づきました。あるアセンブリのファイルを別のアセンブリから一時的に使用していました。私はそれに多くの変更を加え、SVN履歴を孤立させたくなかったので、私のブランチでは、ファイルを他のアセンブリのフォルダーから移動しました。これはSVNによって追跡されないため、ファイルが削除されてから再度追加されたように見えます。これにより、ツリーの競合が発生します。

私はコミット、ファイルの背を移動することで、問題を解決し、そしてその後、私のブランチをマージします。その後、ファイルを元に戻しました。:)それはトリックをするように見えました。

同様の問題がありました。実際に私のために働いた唯一のものは、競合するサブディレクトリを削除することでした：

svn delete --force ./SUB_DIR_NAME

次に、それらを含む作業コピーの別のルートディレクトリから再度コピーします。

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

それから

svn cleanup

そして

svn add *

あなたは最後の警告で警告を受け取るかもしれませんが、それらを無視し、最後に

svn ci .

私はこれと同じ問題を抱えていましたが、これらの手順を使用してマージをやり直すことで解決しました。基本的に、SVNの「2-URLマージ」を使用trunkして、履歴やツリーの競合をそれほど気にすることなく、ブランチの現在の状態に更新します。114の木の競合を手動で修正する必要がなくなりました。

希望どおりに履歴が保存されるかどうかはわかりませんが、私の場合は価値がありました。

私が時々遭遇するシナリオ：

リリースブランチを作成したトランクがあるとします。トランクにいくつかの変更を加えた後（特に「some-dir」ディレクトリを作成）、後でリリースブランチにもマージする機能/修正ブランチを作成します（変更が十分に小さく、機能/修正がリリースにとって重要であるため） 。

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ブランチを作成する前に、トランクで行われたコミットを明示的にマージする必要があります。

それはgitでは必要ないため、よく忘れます。