SVNプロジェクトの構造

Question

私たちはVSSからSVNに移り、プロジェクトの構造を議論しています。 下記の2つの提案を議論しています。

No.1は、プロジェクトリリースバージョンが タグに関連付けられており、開発者はただちに動作させるためにそのタグの更新を行う必要があるため、開発サポートの方が簡単です。

2は、すべてのプロジェクトと依存関係を独立して開発できることを保証しますが、 特定のリリースバージョンを構築することは、プロジェクトのタグを知ることを意味し、すべて 依存です。

2つの間に明白な比較上の利点はありますか？ 2つの構造に問題がありますか？そこには優れた構造がありますか？

 
1. 
Development 
    + trunk 
    Project1 
    Project2 
    Dependency1 
    Dependency2 
    Dependency3 
    + branches 
    + tags 

2. 
Project1 
    + trunk 
    + branches 
    + tags 
Project2 
    + trunk 
    + branches 
    + tags 
Dependency1 
    + trunk 
    + branches 
    + tags 
Dependency2 
    + trunk 
    + branches 
    + tags 
Dependency3 
    + trunk 
    + branches 
    + tags 

Answer 1

一般に、私はプロジェクトを分かれておくことをお勧めします（2番目のオプション）。これにより、一般的に再利用が促進されます。 （Dependency2のみが必要な場合は、他のプロジェクト全体を持ってくる必要はありません）

しかし、あなたの依存関係が本当にやっていることを知っておく必要があります。たとえば、Dependency2がの場合、のみがProject1の依存関係になるため、Project1のソース構造内に存在するはずです。 （注：依存関係の分岐とタグを別々にするという意味ではありません。異なるパッケージやProject1内の別のサブプロジェクトにあることを意味します）

組織内でプロジェクトを再利用可能なライブラリにしたい場合別のプロジェクトとしてそれを完全に持っているので、不要な共依存を導入することはありません。そして、私はあなたの開発チームが依存関係をチェックアウトせず、それに沿って作業することを奨励します。代わりに、依存関係をビルドし、バイナリライブラリとして使用します。このようにして、誰かがそれを処理するプロジェクトをチェックアウトすると、アプリケーションに必要な最新のライブラリの依存関係が常に得られます。更新が必要な場合は、依存関係をチェックアウトして構築することを心配することができます。 （または、より良い、プ​​ロジェクトチームは、バイナリファイルとして最新のライブラリを解放できる場所を持っています。）プロジェクトのバージョン管理と依存 上

更新あなたは＃2ルートで行くと、別のプロジェクトを持っている場合と、依存関係、バージョン管理は実際には非常に簡単になります。どのように動作するかの概要を以下に示します。

1. チームAはProject1で作業しています。
2. チームBは、Project1が依存するDependency1に取り組んでいます。
3. チームBが作業を終えるたびに、Dependency1（バイナリ - おそらくDLL、ライブラリ、またはそれらの行に沿ったもの）のリリースをビルドします。また、現時点でプロジェクトにタグを付けることもできます。 Dependency1-v1.0.0
4. チームAはDependency1-v1.0.0のバイナリリリースを取得し、プロジェクトに組み込みます。 （通常、バイナリはプロジェクト内の/ libフォルダなどに保存されます。）
5. チームAが作業を終えるたびに、プロジェクトをリリースしてプロジェクトにタグを付けることもできます。

ノーポイントで、チームAがDependency1からソースコードをチェックアウトしないと、そのプロジェクトにそれを持って来る、ということに注意してください。これにより、2つのプロジェクトの開発を独立させ、開発チーム間で自律性を保つことができます。チームAはバイナリーを好きなだけ長く使うことも短いものを使うこともできます。もし彼らがアップデートされたバージョンを望むならば、彼らはチームBから最新のリリースを手に入れます。

このプロセスは、外部ソースからライブラリを使用していた場合とは大きく異なります。ライブラリのバージョンを管理することはできません。したがって、プロジェクトに必要なものを手に入れ、必要と思われるときに更新するだけです。自分のプロジェクト構造内にバイナリを保持して、常にバイナリに頼ることができます。

Answer 2

私は個人的に＃2に行きます。私は以前の会社でこれを行い、それはとてもうまくいった。それは各プロジェクトを隔離したので、追加の労力を費やすことなく分岐やタグ付けに関する歴史を簡単に見ることができます。プロジェクトをチェックアウトし、ブランチ、タグ、およびトランクをすべて取得する機能は、違いをローカルでも追跡するうえで優れた機能です。

Answer 3

すべてのプロジェクトが同じソリューションまたは製品の一部である場合、私はアプローチ＃1に行きます。

Iは、以下の構造を使用します。サードパーティのディレクトリ

TRUNK 
--Build 
--Product 
----Source 
------Project1 
------Project2 
------Project3 
----Test 
--ThirdParty 

は、このようなライブラリーまたはAPIなどの非ソースコードの依存関係のためのものです。

私のガイダンスは、トランクから最新のものを入手し、製品をすぐにビルドするために必要なものすべて（そしてすべてを意味する）を得ることができる新しい開発者に根ざしています。参照を追うことは、簡単に避けることができる時間の大きな無駄です。

Answer 4

私の経験では、それは慣例の問題です。また、SVN Bookにも問題はありません。

プロジェクトの1つでは、チームはANTビルドを使用しており、より重視されたフラットな構造でした。我々はアプローチ＃2を持っていた。 1つのマスタービルドスクリプト。私がそれに取り組んでいて、何の問題もなかったのは大丈夫でした。

現在のプロジェクトにはMavenビルドが含まれているため、コードはデフォルトで1つの親を持ち、依存関係とモジュラープロジェクトの下に＃1構造があります。 SVNでは、アプローチ＃1に従います。しかし、まったく新しいプロジェクトを開始する場合は、＃1と＃2を混在させて配置します。このようなもの：

Project1 
     trunk 
      project1A 
      project1B 
      dependency1C 
      dependency1D 
     branches 
     tags 
    Project2 
     trunk 
      project2A 
      dependency2B 
     branches 
     tags 

要約すると、リポジトリを論理的に分離しておきたいと思います。だから、あなたの質問に答えるために、私はアプローチ＃2を好むだろう。

編集＃1：SVN-ブックURLが＃2で

Answer 5

移動を固定されています、他のプロジェクトを参照する"SVN Externals"上のセクションをチェックアウトする必要がありますプロジェクトと

Project1 
    + trunk 
    + branches 
    + tags 
Project2 
    + trunk 
    + branches 
    + tags 
Dependency1 
    + trunk 
    + branches 
    + tags 
Dependency2 
    + trunk 
    + branches 
    + tags 
Dependency3 
    + trunk 
    + branches 
    + tags 

。これにより、依存関係の特定のSVNリビジョンを別のプロジェクトで使用される値として設定できます。

Answer 6

これをもっとよく理解できるように、皆様に感謝します！

@ JasCav、特に私は、依存性がどのように依存しているかについてどのように考えるべきかを説明してくれてありがとう。私は両方を持っているので、意味する構造は次のようになります：

 
Project1 
    + trunk 
     SubPrjFor_Prj1 
     LibraryExternalRefs 
      Dependency1_DLLOnly 
      Dependency2_DLLOnly 
      Dependency3_DLLOnly_NOT_SHARED_UsedOnlyByPrj1_ONLY_HERE 
     LibraryWithSource 
      Dependency4_UsedOnlyByPrj1_NOT_SHARED 
       Source_SubFolder1 
       Source_SubFolder2 
    + branches 
    + tags 
Project2 
    + trunk 
     SubPrjFor_Prj2 
     LibExternalRefs 
      Dependency1_DLLOnly 
    + branches 
    + tags 
Dependency1_UsedByBothPrj1Prj2 
    + trunk 
      Dependency1_DLLOnly 
    + branches 
    + tags 
Dependency2_UsedByPrj1SoFar 
    + trunk 
      Dependency2_Source_SubPrj1 
      Dependency2_Source_SubPrj2 
    + branches 
    + tags 

もちろん、私はトランク/ブランチのマッチング構造を省略しました。

ps @JasCav、私はあなたの投票にもあなたのコメントの下にこのアイテムを載せていないことをお詫び申し上げます。私は明らかにそれらのことをするためのポイントを持っていない、それは私にはあまり意味がない。私はログインして、コメントして、Stackoverflowの興味のあるアイテムを追跡できるようになると思ったが、そうは思わない。

編集：固定フォーマットと4つの依存関係に拡張された例。

Answer 7

これらのすべての構造が示すように、ただ1つのリポジトリを保持するのではなく、ここに別の投稿VSS to SVN - Repositoriesで、チームごとに1つのリポジトリを持つことをお勧めします。そうすれば、SVNのリビジョン番号は、個々のチームがコミットしたときにのみ増えます。

この方法をお試しいただきありがとうございますか？余分なオーバーヘッドの作業が含まれていますか？

私はSVN管理作業の最小量でコードベースをきれいに保ちたいと思っています。