Subversionでは、アプリケーションの新しいメジャーバージョンをどのように設定すればよいですか？

商用アプリケーションの新しいバージョン（バージョン4）で作業を開始しようとしています。私はSubversionを使用しています。

あなたの経験、間違い、成功に基づいて、Subversionで新しいバージョンをセットアップすることをどのようにすすめますか？

ここにいくつかの情報があります：バージョン4がリリースされてからしばらくの間、バージョン3の重要な更新をリリースし続けるつもりです。ただし、新機能の開発はすべてバージョン4でのみ行われます。

関連性がある場合：私はこの製品のソロ開発者です。

編集：私はSVNのタグとブランチを知っています。私が必要としているのは、私の状況でタグとブランチを使用するための最適な戦略だと思います。

あなたがしたいことはブランチを作成することです。これは、ソースツリーのブランチのように聞こえるためです。通常、リリースしたときのソースのコピーです。重要な更新のためにこのブランチにコミットし、このブランチから更新をビルドします。

現在コミットしているのはであり、trunkバージョン4をそこにコーディングします。大きな変更がバージョン3にコミットされ、バージョン4でそれを使用したい場合は、ブランチ（v3）からトランク（v4）にマージして、変更をトランクに反映します。

ブランチのようなタグですが、単一のバージョン、通常はバージョンの最後のリビジョン（または最初のバージョン）にリンクしています。

場合によります。

トランクにバージョン4を保持し、V4での開発を続けることができます。バージョン3はブランチであり、必要に応じて更新します。このアプローチの利点は、V4にもあるV3に重大な問題が発見された場合、ブランチ間でファイルを簡単にマージできることです。

もう1つのオプションは、V4用の完全に新しいリポジトリを作成することです。これはあなたに新たなスタートを与えるでしょう。欠点は、変更履歴がリセットされ、Subversion経由でファイルをマージできなくなることです。変更をマージするには、Beyond Compareなどのプログラムを使用する必要があります。

個人的に私は最初のアプローチに固執します。V3ブランチを作成し、このブランチのコードと更新を維持します。新しいV4コードはトランクで開発できます。

私はこの状況の優れたガイドを見つけました：

If you want to be able to both develop a newer version (in trunk) and 
fix bugs on an older version, what you want is a branch for the older 
version. You can fix your bug in the older version's branch, then 
make a new tag of that. 
Example: 
/repo/ 
        project/ 
                trunk/ 
                branches/   
                tags/ 
You've developed your software in trunk and are now ready to call it 
version 1.0. You make a branch and a tag: 
svn cp $REPO/project/trunk $REPO/project/branches/1.x 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.0 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
Now you continue to develop in trunk, adding new features, and this 
will eventually become version 2.0. But while you're doing this, you 
find a bug in 1.0 and need to fix it quick. So you check out branches/ 
1.x, make the change, test it, and commit it. Then you tag that as 1.1: 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.1 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
                        1.1/ 
If the bug also exists in trunk, then you need to port your bugfix to 
trunk. "svn merge" can help you there. 
cd trunk-wc 
svn merge -c$R $REPO/project/branches/1.x . 
where $R is the revision in which you fixed the bug on the 1.x 
branch. Now you test the fix in trunk and then commit it. Now the bug 
is fixed in trunk too. 

あなたが求めているのは、使用するブランチ（およびマージ）戦略です。したがって、karthik tの投稿を受け取り、それをレシピとして受け取ります。

背景については、次のリソースをお読みください。

• リポジトリレイアウトのSVN Red Book（単一プロジェクトリポジトリと複数プロジェクトリポジトリ）
• コンテキスト内のブランチパターン。メジャーバージョンごとにリリースブランチを使用します
• ソフトウェア構成管理は、Subversion（および他のすべてのCMシステム）で使用される基本理論をパターン化します。そこのパターン、特にそこのリリースラインを見てください。