問題タブ [svn-merge]

リビジョンをトランクからブランチにマージしながら、次のことを達成しようとしています:

リビジョン 1 (これはブランチ バージョンでもあります):

リビジョン 2:

リビジョン 3:

ブランチで次のコマンドを実行します。

次の結果が得られることを期待しています

しかし、代わりにツリーの競合が発生しています。この手法は、ファイルの末尾ではなく、ファイルの途中に新しい行を追加する場合にうまく機能するようです。

SVN でツリーの競合が発生しています。それは奇妙だ！

私は標準的なトランク、ブランチ、タグ構造を持ち、複数のチーム モデルに従っています。Branch1、Branch2 はトランクから作成され、並行してアクティブになります

以下の手順に従います
。 1. Branch1 Work: 2newfile.cで追加およびコミット。 : Branch1 から -> トランク (成功; トランクにファイルが追加されました) 3. : トランク -> ブランチ 2 からダウンマージ。(成功。Branch2 にファイルが追加されました) 4. : 通常の Branch2 作業を実行し、コミットします。 5. : Branch2 から Trunk へ => このステップで Tree-conflict がスローされますBranch1
Merge
Merge
Branch2 Work
Mergenewfile.c

Branch2 チームは、newfile.cまったく触れていないツリーの競合を取得しています。なぜこうなった。何か提案をお願いします。これを回避できますか? この問題は私を悩ませています。

PS: TortoiseSVN client 1.6.0 と TortoiseSVN 1.6.16 - 32 Bit を使用しました (どちらも別々に使用)

マージ エラー (上記の手順 5):

PFB svn リポジトリ ログ (上記の手順 1-4):

私の質問は、SVN マージ メカニズムのいくつかの基礎に関連しています。ここではマージの問題を報告していません。さらに、私はSVNブックのマージの章を通過しました(初心者ではありません)。

トランクに 10 個のリビジョンがあり、リビジョン 5、6、7、8、9、および 10 を特定のタグにマージしたいと考えています。

マージ操作を 6 回実行することで、tortoise SVN でマージを成功させることができました。毎回、リビジョンを 1 つだけ指定しました (つまり、5、6、7、8、9、10)。

SVN リビジョンの私の理解が正しければ、リビジョン 10 (HEAD リビジョン) には、以前のリビジョン、つまり 5、6、7、および 9 のすべての修正が含まれています。したがって、リビジョン 10 を指定することにより、マージ操作を 1 回だけ実行することで時間を節約できたはずです。

私の質問に対する明らかな反応は、「修正の範囲」を指定する必要があるということです。

私の質問は、リビジョン 10 に以前のリビジョンのすべての変更が含まれる場合に範囲を指定する理由です ( http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.basic.in-action )? 単一のリビジョン (番号 10) を指定してマージを実行し、SVN が正しいマージを実行することを期待することはできませんか?

2 人のユーザーが同じファイルを (同じブランチで) 変更し、コードを SVN にチェックインすると、SVN は (2 番目のユーザーに更新を依頼した後) ファイルを自動マージし、競合を解決しようとします。

このマージ プロセスは、クライアントとサーバーのどちらで行われますか?

(詳細: クライアントで Tortoise SVN 1.7.11 を使用しています。サーバーのバージョンは 1.5.1 です。最近、自動マージで一部のデータを削除しましたが、これはコード マージの問題ではないかと考えています。 Tortoise または古いサーバーコード)

SVN の長年のユーザーですが、分岐/タグ付けの経験がかなり浅く、実際に正しく使用していないか、その可能性を十分に発揮していないのではないかと疑っています。

新しい機能の追加などに取り組んでいるトランクがあります。このコード ベースは複数の Web サイトで使用されており、プロジェクトごとにトランクからブランチを作成しています。

通常、各ブランチにはそのプロジェクトに固有の変更があり、再利用可能と思われるものはすべてトランクに追加され、さまざまなプロジェクトでその機能のオンとオフを切り替えられるようになっています。

現在、トランクに変更を加え、それらの変更を以前のブランチに追加したい場合、特定のリビジョンを手動でブランチにマージして再コミットする必要があります。理想的ではなく、見逃しやすいものです。

それで、私の質問...トランクからのすべての変更でブランチを更新し、競合のある標準のトランク更新であるかのようにそれらを処理する方法はありますか?

ブランチをトランクに再統合する方法を見てきましたが、この場合のブランチの使用方法が原因で、実際にはやりたいことではありません。

私はsvnが初めてで、トランクから作業中のブランチに多くのマージを行う必要があります。これは、マージするために使用するsvnコマンドのシーケンスです

ブランチと最新のトランク リビジョンから適格なリビジョンの最も低いリビジョンを取得し、svn マージを実行します。

マージ中にいくつかの競合があります。しかし、それらはブランチで行った変更とは関係がないため、なぜそれらが競合しているのか少し混乱しています。何か案は？とにかく、私はいつも選択するだけです、彼らはそれを解決するためにいっぱいです

最後に、コミットする前に svn resolve を実行する必要があります

2 つの質問があります。これは、トランクからブランチへのマージを実行するコマンドの最適なシーケンスですか?

マージにはしばらく時間がかかる傾向があるため、マージをそのままにして、svn が競合を自動的に完全に解決できるようにしたいと思います。これを行う方法はありますか？

外部がすべてのブランチの異なる場所を指す環境をセットアップしています。あるブランチから別のブランチにコードをマージすると、手動で解決する必要があるプロジェクト プロパティで常にマージの競合が発生します。

これは GUI で簡単に実行できます。これは、ローカル リビジョンを保持するだけでよいためです。ただし、次のいずれかを行う必要があります。

1. 見た目に齟齬があることを無視するか、
2. ローカル リビジョンを自動的に受け入れ、マージを続行します。

--record-only スイッチをいじってみましたが、コードとプロパティの変更がブロックされているようです。プロパティ、特に私の外部設定でのみ動作するものはありますか?

最近、コードベースを subversion から mercurial に移行しました。今週末、mercurial コードベースから本番環境への最初のリリースを行っています。

3 つのレポのセットアップがあります。それらをdev、stable、releaseと呼びましょう。ここで、devは stable のクローンで、 stableはreleaseのクローンです。現在、devにはバージョン 7 のコードがあり、stableにはバージョン 6 のコードがあります。バージョン 6 のコードをリリースにプッシュしました。次のリリースであるバージョン 6.1 は来週に予定されています。

問題は、v6 リリースでもメジャー アップグレードを行っているため、6.1 リリースの前に複数回 (6.0.1、6.0.2 など) リリースする予定であることです。今後は、3 つのリポジトリすべてのバージョン番号が異なるため、これは問題になりませんが、現時点では安定版とリリース版の両方が v6 です。

安定版の poms のバージョン番号を 6.1 に変更した場合、この変更をdevに戻す必要があります。つまり、これらのアーティファクトをビルドする前に修正する必要があります (v6.1 リリースを汚染しないようにするため)。実際には v7 アーティファクトとは何ですか)。

svn の merge --record-only と同様に、実際に変更を受け入れずに、この変更をdevにプルするように mercurial に指示する方法はありますか? 変更をdevにプルしてからバックアウトする唯一のオプションはありますか?

ありがとう

次の状況に関する svn マージについて質問があります。

repo/A はトランクです。2 つの子ブランチ コール repo/B と repo/C があります。

1. 元の repo/B にはリビジョン 10 があるとしましょう。
2. repo/C で foo.c を repo/A にマージすると、リビジョンは 11 になります。
3. repo/B の作業コピーが bar.c を repo/B にコミットすると、リビジョンは 12 になります。この時点で repo/B には foo.c がないことに注意してください。これを「NO-FOO-STATE」と呼びましょう。
4. repo/B が repo/A からマージされて foo.c を取得すると、repo/B のリビジョンは 13 になります。

私の質問は次のとおりです。

1. それで、repo/B からリビジョン 12 をチェックアウトするとします。作業ディレクトリに foo.c も取得しますよね? 「NO-FOO-STATE」とまったく同じ内容のリビジョン 12 をチェックアウトするにはどうすればよいですか (またはチェックアウトできますか?)

2. 次のコマンド sudo コードを使用する場合:

svn 削除レポ/B

svn copy repo/B@12 repo/B

repo/B と svn copy repo/B@12 を削除して、リビジョン 12 に戻そうとしました。新しい元に戻されたリポジトリ/B にはまだ foo.c がありますか? はいの場合、「NO-FOO-STATE」に戻すにはどうすればよいですか。

どうもありがとう。