Subversion は、リポジトリ間でのファイルのコピーをまったくサポートしていません。同じプロジェクトのために 3 つのリポジトリを維持することは、狂気への降下です。
また、「複数のコードベース」も必要ありません。すべて 1 つのコードベースです。変更を dev から qa、release に移動するための明確なプロセスが必要です。そのためには、タグとブランチの組み合わせが必要です。定期的な変更のマージ。正確な実装は、アプリケーションの開発をどのように管理するかにかかっており、いくつかの変更が必要になる場合があります。VSS での作業で学んだことをすべて忘れなければならないからです。
次の仮定を使用します。
- アクティブな開発中、すべての開発者は共通のコードベースで作業します
- 「OK、ここにあるものは QA テストの準備ができています」と言う方法があります。
- QA にあるもののバグを修正しながら、開発を継続する必要があります。
- 何かが本番に移行すると、プロセス全体を経ずに本番にあるものを変更することはできません（これがないと、いつか混乱するでしょう）
次のことをお勧めします。
- マニュアルの説明に従って、「従来の」トランク/ブランチ/タグ構造を作成します。すべての開発者は、通常の開発作業のためにトランクからチェックアウトします。本当に、マニュアルのこの章全体を (2 回) 読んでください。これは、私がここで説明しているもののより長く、より詳細なバージョンです。
- リリースを QA にプッシュするときが来たと判断したら、トランクを の下のディレクトリにコピーしてブランチを作成します
branches。これにどのように名前を付けるかはあなた次第ですが、明確で一貫したものにしてください。たとえば、リリースの名前を 4.2 にするために分岐している場合は、それに名前を付けることQA-4.2ができます (次に 4.3 に分岐するときは、名前を付けますQA-4.3)。
- QA テストでバグが見つかった場合は、
QA-4.2ブランチに対するパッチとして修正します。これを担当している人は誰でも、2 番目の作業コピーをチェックアウトして、これらの変更を行い、ブランチにコミットする必要があります。
- QA ブランチで作成したパッチを定期的にトランクにマージします。そうしないと、4.2 で修正したバグが 4.3 ですぐに戻ってきます。
- QA のコードがすべてのテストに合格し、本番環境に適している場合は、QA ブランチを
tagsディレクトリにコピーしてタグを作成します。tags/4.2-RELEASEおそらく、QA で行っていたことと一貫性を持たせ、名前またはそれに近い名前を付けたいと思うでしょう。そして、新しいバージョンをリリースします。
- おそらく今が
svn merge --reintegrateブランチで使用するときです。その後、ブランチを削除してください。コードがリリースされました。現在、次のバージョンに進んでいます。
tagsディレクトリにあるものは変更されません。誰かが本番環境でバグを見つけた場合、新しい開発と同じようにそれに取り組みます。そうしないと、これらの変更がトランクに戻ることができず (誰かが非常に注意深く監視していない限り)、バグが再発します。
Subversion プロジェクト自体がリリース ブランチを作成および維持する方法も参考になる場合があります。