トランクの機能ブランチがあり、定期的にトランクからブランチに変更をマージしていましたが、すべて正常に機能していました。今日、ブランチをマージしてトランクに戻し、ブランチの作成後にトランクに追加されたファイルに「ツリーの競合」としてフラグが付けられました。今後これを回避する方法はありますか？
これらが適切にフラグ付けされているとは思いません。
289031 次
12 に答える
403
Garyが提供したリンクを読んで解決策を見つけました（そして、この方法に従うことをお勧めします）。
使用できる SVN クライアント 1.6.x で作業ディレクトリをコミットするツリーの競合を解決するための要約:
svn resolve --accept working -R .
.競合しているディレクトリはどこですか。
警告: 「作業ディレクトリをコミットする」とは、サンドボックス構造がコミットされることを意味するため、たとえば、サンドボックスからファイルを削除すると、それらのファイルはリポジトリからも削除されます。これは、競合するディレクトリにのみ適用されます。
このように、SVN が競合を解決し ( --resolve)、サンドボックス内の作業コピーを受け入れ ( --accept working)、再帰的に ( -R)、現在のディレクトリから開始することをお勧めします ( .)。
TortoiseSVN では、右クリックで [解決済み] を選択すると、実際にこの問題が解決されます。
于 2010-09-16T16:31:53.340 に答える
61
Subversion 1.6 では、ディレクトリ レベルでの競合をカバーするために Tree Conflicts が追加されました。良い例は、ファイルをローカルで削除した後、更新によってそのファイルのテキストを変更しようとする場合です。もう 1 つは、編集中のファイルの名前を変更するサブバージョンがある場合です。これは、追加/削除アクションであるためです。
CollabNet の Subversion ブログには、Tree Conflictsに関する素晴らしい記事があります。
于 2009-04-10T18:08:51.327 に答える
28
これがあなたに起こっているかどうかはわかりませんが、マージするディレクトリを間違って選択すると、すべてのファイルが完全に問題ないように見えても、このエラーが発生することがあります。
例：
/svn/Project/branches/some-branch/Sources を /svn/Project/trunk にマージ ---> ツリーの競合
/svn/Project/branches/some-branch を /svn/Project/trunk にマージ ---> OK
これはばかげた間違いかもしれませんが、もっと複雑なことだと考えているため、必ずしも明白であるとは限りません。
于 2010-04-14T17:38:48.830 に答える
17
ここで起こっていることは次のとおりです。トランクに新しいファイルを作成し、それをブランチにマージします。マージ コミットでは、このファイルはブランチにも作成されます。
ブランチをトランクにマージすると、SVN は再び同じことを試みます: ファイルがブランチに作成されたことを確認し、マージ コミットでトランクに作成しようとしますが、既に存在します! これにより、ツリーの競合が発生します。
これを回避する方法は、特別なマージ、再統合を行うことです。スイッチでこれを実現できます--reintegrate。
これについては、ドキュメントで読むことができます: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate
ただし、ブランチをトランクにマージする場合、基礎となる数学はまったく異なります。機能ブランチは、複製されたトランクの変更とプライベート ブランチの変更の両方の寄せ集めになっているため、コピーする単純な連続した範囲のリビジョンはありません。--reintegrate オプションを指定することにより、Subversion に、ブランチに固有の変更のみを慎重に複製するように依頼します。(実際、最新のトランク ツリーと最新のブランチ ツリーを比較することでこれを行います。結果の違いは、まさにブランチの変更です!)
ブランチを再統合した後は、ブランチを削除することを強くお勧めします。そうしないと、トランクからブランチへの反対方向にマージするたびにツリーの競合が発生し続けます。（理由は先ほど書いた通りです。）
これにも回避方法はありますが、試したことはありません。この投稿でそれを読むことができます: v1.6 での Subversion ブランチの再統合
于 2015-01-16T13:36:33.980 に答える
7
これは、同じバージョンのクライアントを使用していないことが原因である可能性があります。
バージョン 1.5 クライアントとバージョン 1.6 クライアントを同じリポジトリに対して使用すると、この種の問題が発生する可能性があります。（私は噛まれただけです。）
于 2010-04-02T10:58:36.670 に答える
4
編集/削除/ファイルの近くに来ていないために意味をなさないツリーの競合に遭遇した場合は、マージ コマンドにエラーがあった可能性も十分にあります。
起こり得ることは、現在のマージに含めている一連の変更を以前にマージしたことです。たとえば、トランクで誰かがファイルを編集し、後で名前を変更したとします。最初のマージで編集を含め、2 回目のマージで編集と名前変更 (基本的には削除) の両方を含めると、ツリーの競合も発生します。これは、以前にマージされた編集が自分のものとして表示され、削除が自動的に実行されないためです。
これは、少なくとも 1.4 リポジトリで発生する可能性があります。1.5 で導入されたマージトラッキングがここで役立つかどうかはわかりません。
于 2009-08-20T06:55:07.303 に答える
1
今日もこの問題に遭遇しましたが、私の特定の問題はおそらくあなたの問題とは関係ありません。ファイルのリストを調べた後、自分が行ったことに気付きました。あるアセンブリのファイルを別のアセンブリから一時的に使用していたのです。私はそれに多くの変更を加えましたが、SVN の履歴を孤立させたくなかったので、ブランチでファイルを他のアセンブリのフォルダーから移動しました。これは SVN によって追跡されないため、ファイルが削除されてから再度追加されたように見えます。これにより、ツリーの競合が発生します。
ファイルを元に戻し、コミットしてからブランチをマージすることで問題を解決しました。その後、ファイルを元に戻しました。:) それはうまくいったようです。
于 2010-09-03T16:02:26.667 に答える
1
同様の問題がありました。実際に私にとってうまくいった唯一のことは、競合するサブディレクトリを次のように削除することでした:
svn delete --force ./SUB_DIR_NAME
次に、それらを含む作業コピーの別のルート ディレクトリからそれらを再度コピーします。
svn copy ROOT_DIR_NAME/SUB_DIR_NAME
それからする
svn cleanup
と
svn add *
最後の警告で警告が表示される場合がありますが、無視して最後に
svn ci .
于 2012-01-20T15:38:13.453 に答える
0
これと同じ問題があり、これらの手順を使用してマージをやり直すことで解決しました。基本的に、SVN の「2-URL マージ」を使用trunkして、履歴やツリーの競合についてあまり気にすることなく、ブランチの現在の状態に更新します。114 個のツリー競合を手動で修正する必要がなくなりました。
履歴が適切に保存されているかどうかはわかりませんが、私の場合はそれだけの価値がありました。
于 2012-04-04T20:14:30.120 に答える