3

svn red bookの「Vendor Branch」の章で、サードパーティ製品の最新リリースを含む current/ を維持することが提案されているため、例からは次のようになります。

   repos/vendor/libcomplex/current - contains 1.1
   repos/vendor/libcomplex/1.0
   repos/vendor/libcomplex/1.1

current/ の目的は何ですか? 最初に新しいバージョンを current/ に置き、その後 current/ をバージョン専用のディレクトリ (1.1 など) にコピーする必要があるのはなぜですか?

私の推測では：

  1. 異なるバージョンの svn を比較できるようにします。
  2. 側面として、バージョンはより効率的な方法で svn リポジトリに保存されます。

current/in vendor ブランチの処理をバイパスできますか?

更新: ベンダー コードにパッチを適用するつもりはありません (少なくともこれは計画です)。そこで、svn:external を使用して、適切なベンダー バージョン ドロップを使用します。

4

4 に答える 4

3

そのベンダーブランチ管理スキームの目的は、サードパーティ製品のリリースをリポジトリに配置して、リリース間の履歴を確立することです。リリース1.0をrepos/vendor/libcomplex/1.0にインポートし、リリース1.1をにインポートするだけの場合repos/vendor/libcomplex/1.1、リリース1.0と1.1の間のSubversionの履歴はなく、Subversionのリリース1.0と1.1の間の変更を表示することはできません。もちろん、両方をチェックアウトし、GNU diffを使用してそれらを比較することはできますが、その場合、Subversionの機能を利用していません。

独自のブランチを作成していて、1.0と1.1の間の変更をブランチにマージしたい場合は、履歴が重要です。リリース1.0と1.1の間のSubversionの変更を表示したい場合は、履歴もインポートされます。最後に、履歴があると、1.0と1.1の間のデルタのみが保存されるため、データの保存がより効率的になります。

リリース1.0を同じディレクトリにインポートしてからrepos/vendor/libcomplex/currentリリース1.1を追加することにより、1.0と1.1の間の履歴を確立します。

于 2010-12-02T17:03:26.613 に答える
2

AlberT のコメントに加えて、ビルド スクリプトが最新のベンダー コードを常に表示する必要がある領域を参照しようとしている場合、専用のディレクトリ (現在のディレクトリ) を持つことは、一定のパス参照を持つのにも役立ちます。

于 2009-09-09T08:57:32.623 に答える
2

svn_load_dirs.plスクリプトを使用すると、このディレクトリの内容が破棄され、すべてが新しいものとしてインポートされるため、これが必要です。

いいえ、必要で便利なので、バイパスすることはできません。

ポイントは、新しいベンダーの削除されたディレクトリとファイルにあり、古いベンダーに対して削除されます。このスクリプトは、新しいベンダー ドロップを現在の場所にインポートしてから、存在しないファイル/ディレクトリごとに「自動化された手」で削除することを処理します。次にマージします。

svn_load_dirs.pl

いくつかの削除、追加、および移動を含むベンダー ドロップは、サードパーティ データの連続する各バージョンへのアップグレード プロセスを複雑にします。

于 2009-09-09T08:46:14.440 に答える
1

/vendor/current ブランチを使用すると、/vendor/tag ブランチが純粋なシャドウ コピーになります。

また、ベンダーのメジャー リリース間の非常にマイナーなリリースにも現在のブランチを使用しており、タグを追加する必要はありません。

于 2010-10-22T15:09:38.517 に答える