問題タブ [tree-conflict]

私は Eclipse 8.6 と Subclipse 1.6、および svn 1.6.x サーバーを使用しています。ブランチを作成し、ブランチとトランクの両方にいくつかの変更を加えました。今、トランクからこのブランチにマージしようとしています。私が得ているのは、ブランチのルートの下にあるすべてのディレクトリとすべてのファイルのツリー競合に他なりません。1 つのファイルを編集しただけで何もしなかったテスト プロジェクトでも、それはわかります。問題は、何も変更していないため、これらのツリーの競合が何を意味するのか理解できないことです。テスト用にファイルを 1 つだけ変更しました。マージ中にファイルの更新を取得するはずですが、これは単に無視されます。マージ ウィンドウに表示されるのは、ルートの下の各ディレクトリと各ファイルのツリー競合アイコンだけです。また、[ツリーの競合] ウィンドウの下に、ツリーの競合ごとに「ローカルの追加、マージ時の受信の追加」と表示されます。

いくつかの Subversion プロセスを自動化しようとしていますが、競合の問題が発生しています。2 つのブランチをマージすると、ツリーの競合と通常の (テキスト) 競合が発生することがあります。リポジトリのコピーを使用してすべてを解決できるようにしたいと思います。

しかし、ツリーの競合がある場合は、私に怒鳴って、作業状態に解決する必要があると言います。

svn: 警告: ツリーの競合は 'working' 状態にしか解決できません。「ファイル」は解決されていません

ツリーの競合だけを「作業中」に解決する簡単な方法はありますか? それとも、私の目標を完全に達成するための別の方法でしょうか? Windowsコマンドラインからこれを実行しようとしています。ありがとう！

Subversion サーバーはバージョン 1.6.6 です

CollabNet Subversion Command-Line Client v1.6.13 (Windows 用) を使用しています。

これが私のシナリオです：

次の内容の SVN リポジトリがあるとします: myfolder myfolder\file.txt

ここで、このレポの 2 つのチェックアウト co1 と co2 を作成します。

co1 では、file.txt を変更します。co2 では:

• svn 削除 myfolder
• SVNコミット
• myfolder という名前の新しいフォルダーを作成します。
• svn myfolder を追加
• SVNコミット

co1 で更新しようとすると、ツリーの競合が発生します。

myfolder と変更されたファイルを保持したいので、ツリーの競合を解決します。

コミットしようとすると、「svn: Directory '/myfolder' is out of date」が表示されます。svn up myfolder を使用してこれを解決しようとすると、ツリーの競合が再び発生します。

よし、svn resolve --accept working folder をもう一度試してみる。しかし、まだコミットできません。「svn: Directory '/myfolder' is out of date」という同じメッセージが表示されます。svn up myfolder を実行すると、最後のツリー競合に戻ります。

このタイプの競合を解決するための正しい手順は何ですか (myfolder とその変更を保持したい場合)?

編集: 説明する Windows コマンド ライン スクリプト:

そして、これがそのスクリプトを実行した出力です (最後にコミットの失敗に注意してください)。

TortoiseSVN は、 [競合の編集]ウィンドウを使用して、いくつかの種類のツリーの競合を解決できます。

問題は、" ... on merge " コンフリクト タイプの場合、TortoiseSVN がどのファイルをマージする必要があるかを推測できないことです。

例: (ケース:ローカル欠落、更新時に着信削除)

• トランクに取り組んでいる開発者 A は、ファイル Foo.c を変更し、それをリポジトリにコミットします。
• ブランチに取り組んでおり、ファイル Foo.c を Bar.c に移動し、リポジトリにコミットしています。

開発者 A の変更をブランチの作業コピーにマージすると、ツリーの競合が発生します。

• Bar.c は、ステータスが「通常」の作業コピーに既に存在します
• Foo.c は、ツリーの競合により不足しているとマークされています

ほとんどの場合、開発者 A の Foo.c への変更を、名前が変更された Bar.c にマージする必要があります。

しかし、どうすればそれができますか？

開発者 A の変更を含むファイル Foo.c が私のブランチ WC に存在しません。

TortoiseSVN ヘルプには、次のように記載されています。最初に競合を解決する必要があります。」</p>

では、マージのために Foo.c ファイルにアクセスするには、トランクをチェックアウトする必要がありますか? この問題を解決するためのより簡単な方法はありますか?

この問題 (TortoiseSVN がツリーの競合を解決する方法) は、私と開発者にとって非常に重要です。

私たちを手伝ってくれますか？

1) トランクがあり、そこからブランチを作成しました。

2) トランクにはディレクトリ A が含まれており、ブランチではこのディレクトリの名前が B に変更されました。

3) トランクで、誤って A のファイル F に変更を加えました。

4) ブランチを再統合すると、ツリーの競合が発生します

5) 賢く、トランク内のファイル F への変更を元に戻しました - しかし、これは解決策ではありませんでした。これは、マージ中にサブバージョンがまだ変更を実行しようとしてから元に戻そうとするためです。それはまだ紛争につながります。

質問 - パート A: この状況を処理するための正しい解決策は何ですか? 競合を受け入れて手動で処理しますか?

質問-パート B: ファイルがブランチで名前が変更されたディレクトリにある場合、Subversion は通常、ファイルをマージできませんか?

(Subversion 1.6 と Tortoise を使用しています)

SVNでは、2つのブランチをマージするとツリーが競合します。両方のブランチに同じファイルまたは同じディレクトリを追加したため、ツリーの競合が発生します。ここでも同じ質問があります。

邪悪な双子の木の衝突に関する他のStackoverflowの質問

ただし、着信追加を受け入れる必要があります。Subversionでは、リポジトリの動作状態のみを受け入れることができます。したがって、B1からB2へのマージを実行し、B2でローカルに追加されたファイルを削除し、svnにB1からB2にファイルを追加（再マージ？）してから、マージをコミットできると期待します。邪悪な双子の衝突を次のバージョンに解決することは可能ですか？

ここでのポイントは、着信バージョンを受け入れることです。これにより、次回B1からB2にマージするときに、反対のB2-> B1マージを実行しなくても、変更が自動的にマージされます。

EGit を使用している 2 人の開発者がいます。1 つは Windows で動作し、もう 1 つは Linux で動作します

そして、以下のようにコラボレーションのポリシーを設定します。

• 中央の (裸の) リポジトリがあります
• 最初に、各開発者は中央リポジトリからチェックアウトし、ローカルで作業します。
• 2 つの作業を同期する必要がある場合は、中央リポジトリからプル/プッシュします。

中央リポジトリを使用すると、将来、チーム内のより多くの開発者と簡単にコラボレーションできると考えています。

ある開発者が別のディレクトリに移動したファイルを別の開発者が変更したときに競合がまったくないことを検出するまで、すべてが正常に機能します。手順は次のとおりです。

• ある開発者がファイルを別の場所に移動します。それを彼のローカルリポジトリにコミットします。中央リポジトリにプッシュします。
• もう 1 つは、その (同じ) ファイルの内容を変更します。それを彼のローカルリポジトリにコミットします。中央リポジトリをプルします。

2 番目の開発者が「プル」を行うと、競合レポートが発生することが予想されます。しかし、競合はありません。そして、彼の作業ディレクトリ (およびローカル リポジトリ) に 2 つのファイルが表示されます。

• 彼が改造したもの
• そして、最初の開発者が別のディレクトリに移動したもの。

誰か私たちの間違いを教えてください。

私たちの働き方は git の設計に違反していませんか?

私たちは git を初めて使用します (CVCS には長い間精通しています)。この問題に直面したことで、私たちのチームの作業を統合することが非常に困難になることを意味するため、非常に心配しています。私たちは何か間違ったことをしなければならないと信じています。私たちを明確にしていただきありがとうございます。

トランクの作業コピーに変更を加えました。次に、コミットできるように別のブランチに切り替えたいと思いました。私はそうしました、そして今、私のプロジェクトは混乱しています。切り替え先のブランチはトランクの背後にあり、変更したファイルがありませんでした。イライラして、トランクに戻しました。

現在、「ローカル編集、切り替え時の着信削除」と言ういくつかの場所でツリーの競合があります。競合のため、これらをコミットできません。私が見ることができる唯一のオプションは、ローカルの変更を元に戻すか、基本的にプロジェクト全体を再チェックアウトしてすべての変更を失うことです。

もう 1 つの問題 - このようなツリーの競合が発生したフォルダーの 1 つを元に戻しました (そして削除しました)。これで、フォルダがリポジトリに存在することがわかりますが、ローカル プロジェクトから削除されており、更新しても作業コピーに取り込まれません。ここで何が起こっているのですか？1.リポジトリに存在する、2.削除したばかりなので作業コピーには存在しない、3.更新しても作業コピーに取り込まれない。どうしてこれなの？

なぜこれが難しいのですか？ローカルの変更があり、それらをコミットしたいと考えています。別のブランチに切り替えて再び戻ることが重要な理由がわかりません。切り替え先のブランチにファイルが存在しない場合、ファイルをブランチにコミットできないのはなぜですか?

これは、切り替え先のブランチに存在しなかったファイルへのローカル変更である、ツリーの競合の 1 つに対して Eclipse が私に与えているものです。ブランチになかったため、切り替えたときにファイルを削除したかったと思います。では、どうすればこれを修正できますか？本当にやりたいことは、それをブランチに追加して変更をコミットすることですが、競合が発生しているためできません!

それが私に与える唯一のオプションは、元に戻す、削除する、または比較することですが、これらはすべて受け入れられません. ローカルチェンジが多い！

次の構造を持つSVNリポジトリがあります。

dir1 にいくつかの重要な変更を加えようとしているので、新しいブランチを作成しました。dir2 は非常に重く、作成する新しいブランチごとにチェックアウトするのに長い時間がかかるためです。だから私はこれをしました：

これまでのところ問題はありません。トランクを新しいブランチに再度マージしようとすると、常に問題が発生します。

これを行うと、次のようなものが得られます。

重要な詳細は、ブランチを作成してチェックアウトした直後にマージしようとしているため、ブランチやトランクに変更はありません。

それで、私はここで何が間違っていますか？これらすべてのツリー競合が発生するのはなぜですか?

前もって感謝します！

トランクから SVN ツリーの開発ブランチにマージするときに問題があります。

プロジェクトの経緯はこうです。それはたった1本のトランクから始まりました。リビジョン 207 について、最初のブランチが作成されました。その後、リビジョン 331 で、対象のブランチがトランクから分割されました。

現在、リビジョン 384 です。331 の間の変更のほとんどは、対象のブランチに対して行われていますが、いくつかはトランクに対して個別に行われています。

枝が幹と調和するように、幹から枝にマージしたかったのです。だから私は正式にそうしました：

しかし、あらゆる種類の競合が発生していることに気付きました。いくつかの競合は理解できるかもしれませんが、ツリー内のほとんどすべてのディレクトリとファイルが影響を受けます。

さらに悪いことに、これらの主張されている競合のほとんどは、実際には 207 から 331 の間にトランクにコミットされた変更であるため、ブランチがトランクから分割されて以来、すでにブランチに組み込まれています。

それよりも悪いことは、予想される競合の多くがツリーの競合であり、207 から 331 の間で削除または名前変更されたファイルが関係していることです。ブランチにはもう存在せず、実際にそこに存在するべきではないため、問題を解決する方法がわかりません。

ほとんどすべてのファイルでブランチが正しいため、修正は複雑です。したがって、ブランチのコピーを受け入れた後にマージインすると、コミットするものが何もないため、サーバーはマージが実際に実行されたというヒントを取得しません。アウト。

私はそれを修正するためにいくつかのことを試みました：

これは何の関係もないように思えました。

この問題は、チェックアウトの新しいコピーでも解決されませんでした。

興味深いことに、おそらく「レコードのみ」のマージは、ローカル コピーのファイルも変更しようとしました。

これにより、レコードのみのマージで苦労した後でも、競合とツリーの競合が山積みになり、それが適用した変更 (レコードのみのマージ) を苦労して解決しました。

また、私が始めたとき、私のクライアントは 1.6.17 で、サーバーは 1.4.6 でした。ただし、サーバーも1.6.17にアップグレードされており、問題は解決していません.

この問題を解決するために人々が見つけた方法はありますか? 完全なマージを実行してファイルを 1 つずつ解決するには、信じられないほど時間がかかります。この時点では、明らかな理由から、次回 SVN が同じことを実行しようとしないという自信さえありません。私をもう一度。