ベンダーブランチを使用するようにSubversionを設定する場合のベストプラクティスは何ですか？私たちのリポジトリは、個々のプロジェクト用に構成されています。Subversion1.6.2とtortoiseSVN1.6.3を使用しています。
フォルダ構造の例：
Project1
/tags
/branches
/trunk
Project2
/tags
/branches
/trunk
Subversion マニュアルには、特にVendor Branchesに関するセクションがあります。
基本的な考え方は、現在のリリースを変更せずに、外部の変更 (変更ではなく外部の変更のみ) を追跡する一連のフォルダーを介してリポジトリにインポートすることです。「.../repos/vendor/(ソフトウェア)/current」のようなもの。次に、すぐに「.../repos/vendor/(software)/(software-version)」に分岐します。新しいリリースが出たら、「現在の」ディレクトリを更新し、「.../repos/vendor/(software)/(next-version)」などの新しいブランチを作成します。これにより、外部で変更されたものに到達するために、変更されていないソースで差分を作成できます (および svn)。
ソフトウェアを変更するには、"(software-version)" を ".../repos/(my-project)/trunk/(software)" のような独自のプロジェクトに分岐します。サード パーティ ソースの次のバージョンにアップグレードする場合、svn に "(software-version)" と "(next-version)" の違いを "trunk/(software)" の作業コピーにマージするように指示します。これにより、すべての外部変更がトランクに取り込まれ、プロジェクト ソースが適切にアップグレードされます。通常どおり、プロジェクトを分岐してタグ付けします。
Subversion ディストリビューションには、「vendor」プロジェクトをアップグレードするときに役立つ「svn_load_dirs.pl」という Perl スクリプトが含まれています。削除、追加、名前変更されたファイルを検出し、必要に応じて「(current)」などの作業コピーを変更します。
あなたの言うことは真実ですが、実際には非常に大きな問題があります。
ベンダープロジェクトをSubversionリポジトリにインポートすると（ベンダープロジェクトが大きなものであると仮定すると、apache httpd 2.2のようになります）、各ディレクトリにsvn：ignoreプロパティをインポートすることは不可能であることがわかります。 WebDAVインターフェースへのアクセスでのみこれを行うことができるエクスポートツールは存在しません（svnpropsをエクスポートできるがベンダーリポジトリへの直接アクセスを必要とするsvnadminツールがあります）。
したがって、ベンダープロジェクトをインポートするときは、最初にベンダーsvnリポジトリから元のプロジェクトをエクスポートする必要があります。ファイルをsvnにインポートした後、プロジェクト内のすべてのディレクトリにsvnpropsを手動で設定します。非常にペイントフルな方法ですが、ベンダープロジェクトを本当に変更して、その変更に対応したい場合は、これが唯一の方法です。