問題タブ [svn-merge]

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」に戻すにはどうすればよいですか。

どうもありがとう。

以下に示すように、ツリーの競合メッセージが表示されます-

私がしたこと：

1. トランクから機能ブランチを作成しました。
2. トランクにいくつかの変更を加えました。トランクからいくつかのジャンク ファイルを削除しました。
3. トランクを機能ブランチにマージしました。この時点まで、すべてが正常に機能していました。
4. 機能ブランチにいくつかの変更を加えました。これで、フィーチャー ブランチは PROD へのリリースの準備が整いました。
5. 機能ブランチをトランクにマージしようとしたところ、この競合エラーが発生しました。

このエラーが発生する理由と回避方法がわかりません。

ありがとう。

私は SVN を使用しており、Web サイトに追加する「meety」機能ごとにブランチを作成しています。

定期的に、次のコマンドを使用して (ブランチの作業ディレクトリから) トランクをブランチに同期します。

その操作の直後に、マージ操作が成功したことを確認するためにコマンドを実行できるかどうか疑問に思っていました。

コマンドを使用できると聞きましたが、svn propget svn:mergeinfo方法がわかりません。

ご協力いただきありがとうございます！

トランク SVN URL:http://svn.myserver.com/trunk/project1

上記のブランチから作成されたプライベート ブランチ:http://svn.myserver.com/trunk/project1_myprivate

トランクからプライベート、プライベートからトランクにマージした後、最終的にトランクから myprivate ブランチにマージしたいのですが、今回はトランクのすべての変更を受け入れ、myprivate を無視したいのですが、これを達成するために必要なコマンドは何ですか?

環境：

OS：リナックスミント14

SVN : 1.8.3

この問題は、コマンド ラインおよび subclipse プラグインで発生します。

既存のプロジェクトの下に新しい Java パッケージを作成し、このパッケージに多くのクラスを追加します。ブランチにコミットすると、すべて問題ありません。しかし、ブランチをトランクにマージしようとすると、別名再統合 ( --reintegrate オプションを使用しないでください。svn 1.8 では非推奨です) に問題が発生し、競合レポートはありません。Merge は、新しいパッケージとそのファイルを含むすべての変更をもたらします。

変更をコミットまたは確認しようとすると (svn ステータス)、パッケージのみが表示されました。ファイルはバージョン管理されているように見え、私のレポの最後のリビジョンにありました。この事実は他のブランチでも発生します。新しいパッケージを含むすべてのコミットには、作業コピーにマージする問題があります。

興味深いのは、ブランチのリビジョンをリビジョンごとにマージするとうまくいくからです。問題は自動マージに関連しているようです。