問題タブ [tree-conflict]

私はsvn 1.7.4 /と亀のsvn 1.7.6を使用しています。私は何が何であるかをグーグルで検索しようとしましたがWhat is tree conflict in svn、いくつかの特定の質問を除いて、それを詳細に説明する記事を取得できませんでした.

これがツリーの競合に関する私の理解です

トランクがあるとします。ここで、時間 T1 にトランクからブランチ branch1 を作成しました。開発者がT2でファイルまたはフォルダーを追加するか、ファイルの名前を変更した場合、ブランチをトランクにマージしようとすると（を使用Merge using range of revisions）、ソースにファイルまたはフォルダーが追加されるため、ツリーの競合が発生します（トランクのトランクこの場合） 。そうですか？はいの場合、できれば Tortoise SVN を使用して変更をトランクにマージする方法は何ですか?

T1 の後にブランチで追加/削除/名前変更が行われ、トランクが変更されない場合でも、ツリーの競合が発生しますか? はいの場合、できれば Tortoise SVN を使用して解決する方法は何ですか?

私はSVNを初めて使用し、修正方法がわからないエラーをいくつか犯したと思います。プラグインを WordPress にアップロードしています。いくつかのバージョンをアップロードした後、開発中のファイルの準備ができておらず、問題を引き起こしていることに気付きました。そのため、トランク フォルダーとタグ バージョン フォルダーからファイルを削除したところ、次のエラーが発生しました。何をしても治らないらしい。

svn stat を実行すると、次のようになります。

svn ci -m 'notes' を実行してプラグインを送信しようとすると、次のようになります。

ここにあるものを確認できます: http://plugins.svn.wordpress.org/bh-design/tags/

tags/1.4/* と、削除したメール購読フォルダーに関するエラーが多数あります。問題は、ローカル マシンにタグ/1.4/ がなく、svn up を実行しても追加されないため、この 1.4 がどこにあるのかわかりません....

どんな助けでもいいでしょう！

始める前の簡単なメモ: 「準備」には多くの説明が必要であり、これはプログラミングの問題に関する質問というよりも、設計に関する質問のように思えるかもしれません。実はSVNの分岐とマージについての質問なので、最後まで読んでください。

シナリオ：

かなりの数のプロジェクトを含む大規模な Visual Studio ソリューションがあります。私は SVN を使用しているので、もちろんトランクには私の開発ラインがあります。これは、コア DLL アセンブリ、「メイン」UI ユーザー クライアント、および UI 内で機能を提供するためにコア アセンブリにインターフェイスを実装し、一連のサービスを利用することによって動作する少数の「プラグイン」アセンブリで構成されます。すべてのプラグインに共通の機能を提供するメソッド (永続化ロジック操作、集中型ファイル ストア アーキテクチャのストレージ操作など)

また、時間をかけて作成した外部ユーティリティもあり、プラグインの多くのビジネス ロジックを複製する必要があります。最終的に私の主な質問から気をそらすので、詳細には触れませんが、たとえば、特定のプラグインのデータに関連する集中メンテナンス操作を処理するサーバー上のスケジュールされたサービスを想像してみてください。

私が最初にこのアプリケーションを構築したとき、私は (愚かなことに) 一元化されたサービス層の必要性を予期していなかったので、上に示したように (良くも悪くも) コア アセンブリを設計し、アプリケーションのプレゼンテーション層と緊密に統合しました。 . つまり、プラグインをユーザー インターフェイスに統合するために必要な UI プレゼンテーション ロジックと、プラグインが共通のプラグイン ロジック操作を実行するために必要なビジネス ロジックは、すべて 1 つの「コア」アセンブリの一部です。したがって、プラグインと集中型サービスの間に存在する「共有」ロジックの多くは、コードの重複をもたらしました。

私は、主要なリファクタリング イニシアチブを実行して、プレゼンテーションに関係のない共通ロジックを「共有」アセンブリに引き出すことにしました。このために、トランクからブランチを作成しました。共通コードを「共有」アセンブリに再編成し、クライアント アプリケーション (プラグインなど) と外部サービス アプリケーションのすべてを再指定して、共有アセンブリを利用しました。多くの場合、今後のより一般的な目的に合わせて、クラスの名前も変更する必要がありました。コア アセンブリは、プラグインと UI の間でプレゼンテーション層の役割を仲介するためだけに残されました。

問題：

リファクタリングが正常に完了したので、ブランチをトランクに再統合したいと考えています。単純なケースでもマージはトリッキーな作業ですが、ここで私が直面しているのは、控えめに言っても多くのツリー競合です。また、まったく新しいプロジェクトに存在することに加えて、「共有」プロジェクトのフォルダー構造は、「コア」プロジェクトのフォルダー構造とはかなり異なります。多くの場合、共有アセンブリを使用するための新しいメカニズムにより、クラスは別の場所に配置されます。

コア アセンブリの古いホームから共有アセンブリの新しいホームまで、すべてのクラスのバージョン履歴を維持したいと考えています。さらに、マージが成功することを保証したいと思います。当たり前のことのように思えますが、このシナリオ全体のミニチュア バージョンをテストしたところ、ブランチの機能が完全に損なわれないような方法で競合を解決することはできませんでした。さらに、以前に述べたように、より一般的な役割に合わせて一部のクラスの名前を変更したという事実により、バージョン履歴の維持が非常に難しくなっています。

ファイルの名前を変更して移動を修復する「通常の」ケースで役立つAnkhSVNを使用していることに注意してください。ただし、これらの主要なツリー競合のケースでは機能しないようです。また、SVN の異なるバージョン間でマージの動作に違いがあることも知っています。SVN 1.5 より前と SVN 1.5 より後のバージョンだと思います。私はSVN 1.9.3を使用しています。

私は今、数週間これを理解しようとしています。私はSVN book、このような TortoiseSVN のリソース、およびこれ、これ、およびこれのような Google 検索から見つけたあらゆるものを注ぎ込んできました。私は夢中になっているように感じます.高度なSVN（およびTortoise）は、従来の自分で教え、Webや本から学ぶアプローチでは学習できないと思います. いずれにせよ、そこにある洞察を大いに感謝します。

SVN を使用して機能ブランチを作成し、大きなツリーの変更と「移動」(名前の変更) を計画して、何も失うことなくそれらの変更をトランクに再統合できるようにする場合、適切な方法論は何ですか?

このツリーの競合に関する情報を次に示します。

最後の更新操作でディレクトリ >'models' を削除/移動/名前変更しようとしましたが、ディレクトリは既に編集されていました

競合の原因:

ソース左: http://.../svn/.../models@23800

ソース右: http://.../svn/.../models@23805

svn ステータス:

サーバーのバージョンを保持し、ローカルからのすべての変更を破棄したい。

アップデート：

「svn resolve --accept working models」を使用すると、svn はローカル バージョンを選択しますか?

どうすればいいですか？

TotoiseSVN のマージを行います。マージ元のブランチの名前が最近変更されました。そのブランチの一部のファイルは、名前の変更後に変更されています。テストマージを実行すると、それらのファイルに対してのみツリーの競合が表示されます。しかし、実際にマージすると、正しくマージされ、競合は見られません。この振る舞いを理解するのを手伝ってくれる人はいますか?

競合したファイルは赤色で表示されますが、実際のマージではこれはわかりません。