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

StackOverflow https://stackoverflow.com/questions/738367

  •  09-09-2019
  •  | 
  •  

質問

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

これらは適切にフラグが立てられていないと思います。

役に立ちましたか？

解決

Gary が提供したリンクを読んで解決策を見つけました (そして、この方法に従うことをお勧めします)。

ツリーの競合を解決するための要約 作業ディレクトリをコミットする SVN クライアント 1.6.x では、以下を使用できます。

svn resolve --accept working -R .

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

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

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

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

他のヒント

Subversionの1.6は、ディレクトリレベルでの競合をカバーするためにツリーの競合を追加しました。あなたがローカルで、更新がそのファイル上のテキストの変更をダウンさせるしようとするファイルを削除すると良い例は次のようになります。それは/アクションを追加削除であるので、あなたはあなたが編集しているファイルの名前の変更転覆を持っているときには、別のです。

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

私はフォルダを削除WHENEVER

私の経験では、SVNは、ツリーの競合を作成します。理由はないように見える。

私は自分のコードに取り組んで一つだけだ - >ディレクトリを削除 - >コミット！ - >競合

私は Gitののに切り替えるのを待つことはできません。

私は明確にすべき - 私は Subclipseのを使用します。それはおそらく問題です！繰り返しますが、私は切り替えるために待つことができない...

これがあなたに起こっている場合、私は知りませんが、時々私はマージする間違ったディレクトリを選択して、私はすべてのファイルが表示されていても、このエラーを取得し、完全に罰金ます。

例：

マージ/ SVN /プロジェクト/支店/いくつかの分岐/ソース / SVN /プロジェクト/トランクへ--->ツリーの競合

/ SVN /プロジェクト/支店/いくつかのブランチをマージ / SVN /プロジェクト/トランクへ---> OK

これは愚かな間違いかもしれませんが、あなたはそれをより複雑なものだと思うので、それは必ずしも明確ではありません。

ここで何が起こっているのかは次のとおりです。トランク上に新しいファイルを作成し、それをブランチにマージします。マージ コミットでは、このファイルがブランチにも作成されます。

ブランチをトランクにマージし直すと、SVN は同じことを再度試みます。ファイルがブランチに作成されたことを確認し、マージ コミットでトランクにファイルを作成しようとしますが、ファイルはすでに存在します。これにより、ツリーの競合が発生します。

これを回避する方法は、特別なマージを行うことです。 社会復帰. 。これを実現するには、 --reintegrate スイッチ。

これについてはドキュメントで読むことができます。http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

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

ブランチを再統合した後は、それを削除することを強くお勧めします。そうしないと、別の方向にマージするたびにツリーの競合が発生し続けることになります。幹から枝まで。(前述した理由とまったく同じです。)

これを回避する方法もありますが、私は試したことはありません。この投稿でそれを読むことができます: v1.6 での Subversion ブランチの再統合

これは、すべての上に、同じバージョンのクライアントを使用していないことが原因で発生することができます。

この種の問題を作成することができ、バージョン1.5クライアントと同じリポジトリへのバージョン1.6クライアントを使用しました。 （私は自分自身をかまれました。）

あなたが/編集/削除ファイルのどこの近くに来なかったので意味がありませんツリーの競合が発生した場合は、

は、マージコマンドに誤りがあったことは良い機会でもあります。

何が起こることができますことは、あなたが以前にすでにあなたの現在のマージに含めている変更の束を合併していることです。例えば、トランクに誰かがファイルを編集し、その後、後でそれを変更します。あなたの最初のマージ中にあなたが編集を含め、次いで第2のマージで編集し、名前の変更（基本的に削除）の両方が含まれている場合、それはまた、あなたのツリーの競合が得られます。この理由は、以前にマージされた編集は、その後、あなた自身のように表示されますので、削除を自動的に実行されないことです。

1.5で導入されたmergetrackingがここに役立ちますかどうか。これは、少なくとも、私はわからないんだけど、1.4のリポジトリ上で発生する可能性があります。

私の特定の問題は、おそらくあなたに関係ありませんが、

私は、今日もこの問題に出くわしました。私は一時的に別のアセンブリから1つのアセンブリ内のファイルを使用していた - ファイルのリストを検査した後、私は私が行っていたものを実現しました。私はそれに多くの変更を行ったとSVNの履歴を孤児したくなかったので、私の枝に、私は他のアセンブリのフォルダからファイルを上に移動していました。これはSVNで追跡されていないので、それだけでファイルを削除してから再度追加されるようになります。これは、ツリーの競合を引き起こしてしまいます。

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

:)

私は同様の問題がありました。

：実際に私のために働いただけの事はして競合のサブディレクトリを削除しました 
svn delete --force ./SUB_DIR_NAME

その後でそれらを持っている作業コピーに別のルートディレクトリから再度コピーします：

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

次に行う

svn cleanup

と

svn add *

あなたは、最後の1との警告を得るが、ちょうどそれらを無視し、最後に

かもしれません 
svn ci .

私はこの同じ問題を抱えていた、とをhref="https://stackoverflow.com/a/1008805/88198">使用してマージを再実行して、それを解決しました。基本的には、歴史や木の紛争についてあまり悩まずに、あなたのブランチの現在の状態にtrunkを更新するために、SVNの「2-URLのマージ」を使用しています。手動で114ツリーの競合を固定してから私を救っています。

私はそれはだけでなく、歴史を維持する場合は、1つは希望わからないんだけど、それは私の場合にはそれだけの価値だった。

私は時々に実行するシナリオます：

あなたはリリースブランチを作成し、そこからトランクを、持っていると仮定します。 （変更は十分に小さく、機能/修正がリリースのために重要であるため）（特定の作成「を一部-dirの」ディレクトリ内）トランク上のいくつかの変更後は、この機能を作成/それ以降、同様のリリースブランチにマージしたいブランチを修正ます。

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

あなたは、あなたがツリーの競合を取得します直接のリリースブランチに機能/修正ブランチをマージしようとした場合（ディレクトリも機能/修正ブランチに存在していなかったにもかかわらず）：

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

あなたが明示的に機能/修正ブランチをマージする前に、「いくつかの-dirの」ディレクトリを作成したブランチを修正/機能を作成する前に、トランク上で行われたコミットをマージする必要があるので。

私は、多くの場合、それはgitのに必要ではないことを忘れてます。

少なくとも 3 か月前から今日に至るまで、ブランチをトランクにマージして戻そうとすると、定期的に何百ものツリーの競合に遭遇しました ( トータスSVN 1.11）。リベースするかどうかにかかわらず、ところで。私は 2004 年の v1 から TortoiseSVN を使用しており、常にブランチを再統合していました。きっと最近何かあったんじゃないでしょうか？

そこで今日、私はこの単純な実験を実行しました。そして、これらのクレイジーな競合を引き起こしている原因を発見しました。

  1. トランク @393 を分岐させました。
  2. 新しいファイルを作成するだけでなく、数十のファイルをランダムに変更しました。
  3. 私はコミットしました。現在は @395 です (同僚は自分の曲を演奏するために 394 で分岐しました)。
  4. 次に、テストのみを目的として、ブランチをトランクに再統合しようとしました。ウィザードでの TortoiseSVN の推奨事項に従います。「すべてのリビジョンをマージ（再統合）するには、そのボックスを空のままにしてください。」これを実現するには、トランク フォルダーを右クリックし、[TortoiseSVN] > [/path/to/branch からマージ] を選択します。 回転範囲を空のままにした, ダイアログでアドバイスされたとおりです。

議論： （添付ファイルを参照してください）

すべてのリビジョン...なにかの？ 私はほとんど知りませんでした クライアントは「」について言及しているに違いありませんターゲットのすべてのリビジョン! (トランク)」というブランチを再統合する過程で、「リビジョン 1-HEAD をマージする」という記述を見つけました。ああ、神様。哀れな悪魔よ、あなたはここで落ちて死にます。その支店は @393 で生まれました。念のため、その出生証明書を読めませんか? this is why so many conflicts occurred: SVN-cli is going on a foolish spree from revision 1

解決：

  1. ウィズのアドバイスとは逆に、ブランチの存続期間のすべてのリビジョンをカバーする範囲を指定してください。したがって、 394-ヘッド;
  2. もう一度マージ テストを実行して、葉巻を手に入れましょう。(see second attachment).

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top