Subversion - 分岐/マージ

Question

私はSVNで分岐とマージの基本的な把握があります。あなたは枝を作り、何でもして、幹に戻ってマージします。

にはがありますか？

私のシナリオ：

私は、LINQ to SQLのを使用して、ASP.NET MVC2で小さなアプリケーションを持っています。 MVC3を外してMVC3にアップグレードするか、EF 4を使用して最初からやり直します。どちらの場合でも、次の「バージョン」は私が現在持っているものと大きく異なることになります。

私はSVNの部分をどのように処理すべきかと思います。現在のリポジトリ（/ svn/project/trunk/mvc3）のブランチとしてSVNに入れるか、新しいリポジトリ（/ svn/project_mvc3/trunk）を起動する必要がありますか？

Answer 1

同じリポジトリに保管してください。ソースコード履歴は、人間の「バージョン」（リリース）を尊重しません。

アプリは、そのライフサイクルにおける定期的なメンテナンス期間に達すると、それは、安定版のメンテナンスのためのブランチを作成し、トランクに次期バージョンの開発を維持するための通常のシナリオです。一般に、一般公開をするたびに、自分自身を支店にする必要があります。

Answer 2

あなたが現在持っているものを保持したいが、将来的に使用したい重要な変更を実行する場合は、現在のプロジェクトのブランチを作成し、新しい変更をトランクに入れることをお勧めします。たとえば（/ svn/project/branches/mvc2）は現在のプロジェクトを保持でき、（/ svn/project/trunk）はMVC3を前進させることができます。

Answer 3

これは、Subversionで最終的に達成したいものによって大きく異なります。バージョンコントロールを使用すると、開発の繰り返しの間の変更を追跡できます。最も基本的なレベルでは、以前のバージョンのコードにロールバックして変更を効果的に取り消すことができます。

バージョンコントロールがあなたのコード用の記憶媒体になると思っていますが、これ以上のことがあります。複数のユーザーがコードを変更しているときに最も強力です。ブランチングは、その機能を提供します。

あなたの質問に答えて、あなたのコードが現在のバージョンから新しいバージョンに移行すると考えているならば、バージョン管理では必要な機能が提供されます。アプリケーションの卸売りを置き換えている場合は、バージョン管理システム内の履歴を追跡することが正しい解決策であるかどうか質問します。

アプリケーションの2つのバージョンが根本的に異なる場合、エンドポイントは同じですが、それらは同じアプリケーションではないと主張できます。彼らが共通のコードを持ち、ゆっくりと別のアプリケーションに移行する場合、バージョンコントロールが可能な解決策になります。

質問に対する回答は、おそらく「それは依存している」でしょう。バージョンコントロールはあなたのために何をしますか？なぜアプリケーションを最初にバージョンコントロールに入れたのですか？これらの質問に対する回答が新しいバージョンにも当てはまり、あるバージョンから次のバージョンへのアプリケーションの進化に批判的に当てはまる場合、分岐/マージはおそらく正しいソリューションでしょう。

ちなみに、アプリケーションの唯一の開発者であれば、ブランチの進行中にトランクを維持する必要がなければ、実際に分岐してマージする必要はありません。これは、トランクが本番環境のどこかにあり、ブランチを開発するときにバグ修正を適用する必要がある場合に当てはまります。

最終的な（少し接線の場合）ポイントは、ブランチとトランクは基本的にSubversion内のサブフォルダだけです。いずれかの方法でマージすることができます（トランクをブランチに、ブランチをトランクに）。