web-dev-qa-db-ja.com

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

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

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

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

それが関連する場合：私はこの製品のソロ開発者であり、それは事実のままである可​​能性があります。

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

version-controlsvn
10
Steve McLeod

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

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.
2
Steve McLeod

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

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

また、tagsを確認することもできます。これはブランチのようですが、単一のバージョン、通常はバージョンの最後のリビジョン（または最初のバージョン）にリンクしています。

8
Karthik T

場合によります。

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

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

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

3
Chuck Conway

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

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

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