3

svnmergeがわかりません。シナリオは次のとおりです。

コードの最新の安定したコピーを含むブランチがあります。このブランチを「ブランチ」と呼びます。いくつかの新しい追加を含むトランクブランチもありますが、現時点ではそれを台無しにしたくありません。

アプリが実行されるライブラリの更新バージョンを含むベンダーブランチがあります。このベンダーブランチの新しい変更を「ブランチ」とマージして、ファイルごとに調べたり、何が新しいのかを理解したりすることなく、ライブラリの更新を取得できるようにしたいと思います。いいえ、ありません。

さて、これはおそらく簡単だと思いますが、私はたくさんのことを試し、たくさんのチュートリアルを読みましたが、それでも、正確には、何とマージする必要があるのか​​について頭を悩ませることはできません。

記録のために、私は亀を使用しています。

編集：これは説明ですが、私たちのアプリはルートレベルでライブラリを実行します。それが重要かどうかはわかりません。したがって、「ブランチ」は基本的に「ベンダー」と同じですが、変更が加えられています。

4

2 に答える 2

2

このような何かがあなたのためにそれをするはずです。Subversionは、標準のdiffとdiff3をかなりよく理解していますが、サードパーティの（グラフィカル）diffユーティリティで常にうまく機能するとは限りません。

$ cd "the branch"
$ svn merge --diff3-cmd=diff3 svn+ssh://yourrepository/path/to/vendor_branch"
于 2009-10-02T21:27:53.970 に答える
2

ベンダーブランチは、新しいリリース（「ベンダードロップ」）を吸収する機能を維持しながら、外部コードベースに対して独自のパッチを維持できるようにする手法です。これには、独自の変更とベンダーの変更のマージが含まれます。高度で複雑なユースケースであるため、マージの最初の実験のようなものを試すことはお勧めしません。

ただし、サードパーティのコードをまったく変更していないようです。したがって、サードパーティコードの新しいバージョンにアップグレードする場合、マージは必要ありません。

秘訣は、独自のコードとサードパーティのコードを別々に（これらは別々のプロジェクトです）、 svn：externalsと一緒にすることです。リポジトリレイアウトの例：

/externallib/1.0
/externallib/2.0
/project/trunk
/project/trunk/externallib

/project/trunk/externallibフォルダは実際にはリポジトリに存在しませんがsvn:externals、トランクフォルダのプロパティが次の値であるため、作業コピーに表示されます。

^/externallib/1.0 externallib

トランクをバージョン2.0の外部ライブラリにアップグレードするには、svn：externals定義を次のように変更します。

^/externallib/2.0 externallib

externallibリリースをタグとして扱う必要があることに注意してください。それらを変更し始めると、/ project/trunkに明示的なコミットを行わなくても/project/ trunk / externallibのコンテンツに影響を与えますが、これは悪いことです。

于 2009-10-03T01:26:54.830 に答える