SVN での分岐とマージの基本的な理解があります。分岐し、何をしても、トランクにマージします。
マージしてトランクに戻す必要がありますか?
私のシナリオ:
Linq to SQL を使用して、ASP.NET MVC2 で小さなアプリケーションを作成しています。MVC3 が出たら、MVC3 にアップグレードするか、最初からやり直します (EF 4 を使用)。いずれにせよ、次の「バージョン」は、私が現在持っているものとは大きく異なるものになるでしょう。
SVN部分をどのように扱うべきか疑問に思っています。現在のリポジトリ (/svn/project/trunk/mvc3) のブランチとして SVN に配置するか、新しいリポジトリ (/svn/project_mvc3/trunk) を開始する必要があります。
同じリポジトリに保管してください。ソース コードの履歴は、人間の「バージョン」(リリース) を尊重しません。
アプリがライフ サイクルの定期メンテナンス期間に達すると、安定版のメンテナンスのためにブランチを作成し、トランクで次期バージョンの開発を続けるのが通常のシナリオです。通常、パブリック リリースを行うたびに、自分でブランチを作成する必要があります。
現在持っているものを維持したいが、今後使用したい重要な変更を実行する場合は、現在のプロジェクトのブランチを作成し、新しい変更をトランクに入れることをお勧めします。たとえば、(/svn/project/branches/mvc2) は現在のプロジェクトを保持でき、(/svn/project/trunk) は前進する MVC3 である可能性があります。
これは、Subversion で最終的に何を達成したいかによって大きく異なります。バージョン管理により、開発の反復間の変更を追跡できます。最も基本的なレベルでは、以前のバージョンのコードにロールバックし、効果的に変更を元に戻すことができます。
バージョン管理はコードの記憶媒体であると考えているように聞こえますが (誤解していた場合は申し訳ありません)、それ以上のことができます。複数のユーザーがコードに変更を加えている場合、最も強力になります。分岐は、部分的にその機能を提供します。
あなたの質問への回答として、コードが現在のバージョンから新しいバージョンに進化すると考えている場合 (主要なアーキテクチャの変更はあるものの)、バージョン管理によって必要な機能が提供されます。アプリケーションを大規模に置き換える場合、バージョン管理システム内で履歴を追跡することが正しい解決策であるかどうか疑問に思います。
アプリケーションの 2 つのバージョンが根本的に異なる場合、エンドポイントは同じですが、同じアプリケーションではないと主張できます。それらに共通のコードがあり、ゆっくりと別のアプリケーションに移行する場合は、バージョン管理が可能な解決策になります。
したがって、質問に対する答えはおそらく「場合による」です。バージョン管理は何をしますか? そもそもなぜアプリケーションをバージョン管理下に置いたのでしょうか? これらの質問に対する答えが新しいバージョンにも当てはまり、重要なことに、あるバージョンから次のバージョンへのアプリケーションの進化に当てはまる場合は、分岐/マージがおそらく適切なソリューションです。
ちなみに、あなたがアプリケーションの唯一の開発者である場合、分岐が進行している期間中にトランクを維持する必要がない限り、実際には分岐とマージを行う必要はありません。これは、トランクがどこかで本番環境にあり、ブランチの開発中にバグ修正を適用する必要がある場合に当てはまります。
最後の (少し関係がありませんが) ポイントは、ブランチとトランクは基本的に Subversion 内のサブフォルダーにすぎないということです。どちらの方法でもマージできます (トランクからブランチ、またはブランチからトランク)。