私のプロジェクトに良いSVNレイアウトを推奨

Question

私はSVNレッドビーンの本を読んで、人々がどのようにSVNリポジトリをレイアウトしているかを調べました。私たちはSVNを製品に使用することを考えています。

Program 1 
Program 2 
Program 3 
Common Code 
Graphics 

それは時々プログラム1は、ソー​​スファイルを使用することができることに注意することが重要です。

製品は、電流源のレイアウトが何かのようなものです.exeファイル、グラフィックス、などの数から成る、デスクトップアプリケーションでありますプログラム2にもあります。共通コードとグラフィックスは、すべてのプログラムで使用されます。

主な質問は、すべてのユーザーが現在製品のバージョン2009を使用していて、それを維持し、サービスパックなどをリリースし、同時にバージョン2010の開発を開始する必要があります2009年のリリース、または2010年のリリースの変更

trunk (where 2010 development happens) 
    Program 1 
    Program 2 
    Program 3 
    Common Code 
    Graphics 
branches 
    v2009 
    Program 1 
    Program 2 
    Program 3 
    Common Code 
    Graphics 
tags 
    2009 (read only) 
    2009 SP1 (read only) 
    2009 SP2 (read only) 

これは推奨レイアウトですか？またはトランクには2009年の開発が含まれていて、何らかの種類のテストブランチで2010年の開発が含まれていますか？

上記のレイアウトは、開発者がプロ​​グラム1で作業したい場合、彼らはまだプログラム2を含むプロジェクト全体を、チェックアウトする必要があります意味し、プログラム3

EDIT、より多くの質問

遠慮してくれてありがとう。さらに質問があります：

開発中に、バージョン2009がまだユーザーによって使用されている場所が4〜6ヶ月あり、2010年の開発中に維持する必要があります。その間、2009年と2010年の両方のリリースに変更を適用する最良の方法は何ですか？これらの変更は、2009年にポートを2010年に変更するか、またはその逆の変更を行う必要がありますか？

Answer 1

これを行う最も簡単で最も一般的な方法は、トランクに新しい開発（2010）を継続し、トランク（2009）の支店でメンテナンスすることです。トランクを解放したらすぐにブランチし（2010ブランチ）、トランクで次のバージョン（2011）を開始します。

実際には、それほど単純ではありません。たとえば、2010年が完了する前に2011年に作業を開始する可能性があります。また、発生する可能性がさらに複雑な状況がたくさんあります。私は支店を管理するためのさまざまな方法の良い概観として、本Software Configuration Management Patternsを提案します。

パッチを適用する場所は、他の人があなた（管理者）を決定することに気付くでしょうが、すべてのバグ修正がリリースブランチに入ってから、トランク。これは、バグの修正が、トランクで行われていることと比べて相対的に小さい可能性が高いためです。

是非、使用するスキームを決めると、そのスキルを文書化して全員に共有してください。私の経験では、ツールの柔軟性や経験不足のために、多くの人がブランチングポリシーについて簡単に混乱します。

Answer 2

私はあなたのレイアウトが好きです。私は年が経つにつれて、トランクは常に今年の発展であるべきだと思います。新年の冒頭には、前年度の進行中の開発のためのブランチを作成し、あなたに合った名前タグを作成します。

Answer 3

トランクには常に最新のバージョンが含まれていますが、トランクを1つだけ持つ必要はありません。私が有用だと分かったレイアウトは、アプリケーション毎に異なるdirを持つことと、これらのそれぞれの中でトランク/タグ/ブランチの内側にあることです。このようにして、コード間の依存関係を慎重に扱わなければならないため、バージョニングの精度が向上します。

Answer 4

私が働いてきたすべてのプロジェクトについて、それはSubversionによって管理されているため、トランクは「開発」ブランチを保持しています。各リリースはタグを取得します（または、それがさらに更新されると、分岐します）。 develブランチに関連するブランチへの変更は、必要に応じてマージされます。

Answer 5

開発のメインラインが2010年の場合は、トランクが最適な場所と思われます。 2010年からブランチで2009年にトランクをマージする予定がある場合は、それも問題ありません。

一般的なコードとグラフィックスにsvn：externalsを使用すると仮定すると、特定のリビジョン番号に外部を設定する習慣がありますが、中長期的には少しでも苦労します。

Answer 6

また、現行の本番リリースのリファレンスとしてトランクを使用することもできます。 すべての開発は特定のブランチで行うことができます。

次に、操作上の保守のためのソースコードの参照が常に得られます。あなたはSVNを使用するためにリリース渡って安定した共通のコードを持っている場合

また、私はお勧め：folowwingのレイアウトと外観：

CommonCode: 
    trunk 
    branches 
    tags 

MyProduct 
    trunk 
    Dependencies -> CommonCode/trunk[rev. x] 
    ... 

はまた、統合の目的のために、「リリース」ブランチを持っていることについて考えることができます。

Answer 7

私にとってはうまくいきました。開発（新機能、バグ修正）はトランク内で行われます。メジャーリリースが準備完了すると、リリースブランチ（たとえばv2009）が作成されます。リリースブランチで見つかったバグは、最初にリリースブランチにコミットされ、トランクで2番目にマージされ、最後に他のリリースブランチにマージされます。

リリースブランチのポイントは、リリースされたソフトウェアのバグを発見した場合にバグ修正を適用するための安定した場所です。リリースブランチは、新しいリリースをカットするために常に利用可能にする必要があります。

したがって、バグは最初に見つかったリリースブランチに固定され、別の場所に適用されます。これは、顧客がバグを発見し、その顧客をできるだけ早く満足させることが最も重要であるという前提に基づいています。これが当てはまらない場合は、私は枝のための最も大きな勇気を提供した支店で修正を行うことを検討します。ブランチ間のマージは必ずしも自明ではないことに注意してください。バグを解消する、または手差しを必要とする大きなコード変更があります。

大規模な機能を開発したり、大きなインフラストラクチャを再設計するときに、トランクから開発ブランチを作成することがあります。トランクにマージされたものは、開発ブランチにマージする必要があります。これにより、最終的にトランクへのマージがさらに容易になります。

Answer 8

GITを使って作業する方が良いことは、メジャーリリースごとにブランチを行うことです。このようにしてメジャーリリースでバグが発生した場合は、ブランチに戻って、GITリポジトリ内のチェリーピクチャをリリースブランチにコミットすることができます。