複数のSVNリポジトリまたは単一の企業リポジトリ
多くの開発プロジェクトを含むすべての会社に対して単一のリポジトリを作成する必要がありますか、それともプロジェクトごとにリポジトリを作成する必要がありますか？経験/ベストプラクティスに関するアイデアはありますか？
個人的には、プロジェクトごとに個別のリポジトリを使用することをお勧めします。いくつかの理由があります：
改訂番号。各プロジェクトリポジトリには、個別のリビジョンシーケンスがあります。
粒度。プロジェクトごとのリポジトリでは、同じリビジョン番号を持つ異なるプロジェクトにコミットすることはできません。私はこれをより有利だと思いますが、誰かがそれは欠陥だと言うでしょう。
リポジトリサイズ。あなたのプロジェクトの大きさはどれくらいですか？ソース管理下にあるバイナリはありますか？私はそれがあるに違いない。したがって、サイズは重要です。バイナリファイルを改訂するたびに、リポジトリのサイズが大きくなります。最終的には不器用になり、サポートするのが難しくなります。バイナリファイルストレージのきめ細かいポリシーをサポートし、追加の管理を提供する必要があります。私の場合、バイナリファイル（愚かなユーザーによってコミットされた）とそのコンテンツ履歴をリポジトリから完全に削除する方法をまだ見つけることができません。プロジェクトごとのリポジトリを使用すると、より簡単になります。
内部リポジトリ組織。私は、きめ細かく、非常に組織化された、自己完結型の構造化されたリポジトリを好みます。 図 リポジトリ保守プロセスの一般的な（理想的な）アプローチを示しています。 「すべてのプロジェクトを1つのリポジトリで」使用することは不可能であることに同意すると思います。たとえば、リポジトリの初期構造（すべてのプロジェクトリポジトリに必要）は次のとおりです。
/project /trunk /tags /builds /PA /A /B /releases /AR /BR /RC /ST /branches /experimental /maintenance /versions /platforms /releasesレポ管理。 「プロジェクトごとのリポジトリ」には、ユーザーのアクセス構成でより多くの可能性があります。しかし、それはもっと複雑です。ただし、便利な機能もあります。 同じ構成ファイルを使用するようにリポジトリを構成できます
レポサポート。リポジトリを個別にバックアップすることを好みます。この場合、あるリポジトリの情報を別のリポジトリにマージすることはできないと誰かが言っています。一体なぜあなたはそれを必要とするのでしょうか？このようなマージが必要な場合は、ソース管理への最初のアプローチが間違っていることを示しています。プロジェクトの進化は、その後のプロジェクトがサブモジュールに分離されることを前提としていますが、その逆ではありません。そして、私はそれを行うためのアプローチがあることを知っています。
svn：externals。 「プロジェクトごとのリポジトリ」アプローチは、svn：externalsの使用を奨励します。これは、svn：externalsであるソフトリンクを介してプロジェクトとサブモジュール間の依存関係が確立されている場合の健全な状況です。
結論。ソース管理を単純にしたい場合は、oneリポジトリを使用してください。ソフトウェア構成管理を正しくしたい場合：
- 「プロジェクトごとのリポジトリ」アプローチを使用する
- ソフトウェア構成マネージャーの個別の役割を導入し、それにチームメンバーを割り当てます
- すべてのSubversionのトリックに対処できる優れた管理者を雇う:)
PS。ちなみに、私は常にSVNを使用していて気に入っていますが、「プロジェクトごとのリポジトリ」アプローチは、リポジトリ編成の観点からDCVSシステムの方が魅力的であると考える理由です。 DCVSでは、リポジトリはデフォルトでプロジェクトです。 「単一対複数」の可能性についても疑問の余地はありません。それはまったくナンセンスです。
単一のSubversionリポジトリがあると、次のことが役立つことがわかりました。
- 透明性：何が起こっているのかを追跡し、直接関与していない可能性のあるプロジェクトでもコードを見つける方が簡単です。
- Maintenance：新しいプロジェクトを作成するたびにリポジトリを作成する必要はなく、Subversionからレコードを失うことを恐れずにプロジェクト全体を削除できます。
- Maintenance：1つのリポジトリをバックアップするだけで済みます。
編集：その他の理由：
- グローバルリビジョンID-リビジョンIDをグローバルにすることにより、次のようになります。
- 簡単に通信（たとえば、コードレビューリクエストでは、どのプロジェクトを指定する必要なしに、リビジョンIDを指定するだけです）。
- プロジェクトが相互に依存している場合、保証が容易になりますatomicity。
- さまざまなプロジェクトへのコミットの順序が見やすくなります。
プロジェクトごとにリポジトリを使用しないことを強くお勧めします。単一のSubversionリポジトリ内で、データを移動およびコピーでき、その履歴が保持されます。バックエンドツールとして開始されたコードの一部がフロントエンドにマージされており、それらが異なるリポジトリにあると判断した場合、これはSubversionが何も認識しない操作ではありません。どこからともなくフロントエンドに何かを追加したかのようになります。これは、関連するコードの2つのバージョンを一時的に維持する必要がある場合、マージを実行できないことも意味します。
svn book のすべての例は、すべてが1つのリポジトリにあると想定していることに注意してください。
/ trunk/project1、/ trunk/project2、/ branchs/project1-r1を使用するか、/ project1/trunk、/ project1/branchs/r1、/ project2/trunkを使用するかについて別の質問があります。一般的に、2番目の方が追跡が簡単です。
すべてを1つのリポジトリに配置しない最大の理由は、アクセス制御をリポジトリレベルよりもきめ細かく行うことが難しいためです。はい、可能ですが、それほど簡単ではありません。現在、2つの主要なリポジトリがあります。
- すべてのソフトウェア開発用のsvn/code、コミットするにはjiraチケットが必要
- 任意の構成、セットアップスクリプト、サードパーティのtarなどのsvn/ops、jiraは不要
これは、アプリケーション/プロジェクトが組織内でどの程度相互依存しているか、およびコードベースの大きさによって異なります。つまり、組織内の「プロジェクト」をどのように定義するかということになります。共有コードベース、共有コンポーネント、共有チーム、共有リリースサイクルはすべて、リポジトリの構造化に影響を与える可能性があります。
簡単にするために、プロジェクトを独立したコードベース、リリースタイムライン、または1つのツール/アプリケーションに属するものとして定義します。この場合、プロジェクトごとに1つのリポジトリを使用することをお勧めします。このようにして、プロジェクトごとにポリシー/アクセス制限を定義および実装するためのより多くの自由があります。
単一のリポジトリが時間の経過とともに肥大化した場合、特にプロジェクトのコードがすべて混在している場合は、ワークスペースのチェックアウト時間などについても心配する必要があります。アプリケーション/ツール/プロジェクトが完了/棚上げ/廃止/移行された場合、プロジェクトレベルで分離があれば、管理面をより細かく制御できます。
プロジェクトごとに1つのリポジトリがある場合、固有のニーズに基づいてプロジェクトリポジトリを構築することも簡単になります。各プロジェクトには特定のニーズがある場合があり、これは各プロジェクトで従う構成管理ポリシー（分岐、タグ付け、命名規則、CIなど）に影響を与える可能性があります。これは、単一のリポジトリ内でこのフォルダごとにすべてを実行できないということではありません。あなたはできる。よりクリーンな分離を実現することで、物事が簡単になります。それだけです。
特定の設定に基づいて、最終的に発生する可能性のある管理オーバーヘッドを評価するために、これらすべての要因を検討することをお勧めします。
つまり、プロジェクトがすべてサイズが小さく、相互依存していて、相互参照、相互追跡、相互の移動などが必要な場合は、リポジトリごとに1つのリポジトリと1つのフォルダを使用することをお勧めします。
これまでのところ、非常に優れた洞察に満ちた回答ですが、2セントを追加したいと思います。
プロジェクトの規模にもよると思います。両方のアプローチを試しましたが、最終的に1つの大きなリポジトリで解決しました。
短所：
- 多くのフォルダやファイルが関係する可能性があるため、分岐が難しい場合があります
- リポジトリは巨大になる可能性があります
- ソリューションを構築するには、リポジトリ全体（または少なくとも特定のブランチ）をチェックアウトする必要があります
- プロジェクトアーキテクチャの制御が少し少なくなります（長所を参照）
長所：
- すべてのプロジェクトは同じリポジトリ履歴を共有します
- ブランチはリポジトリ全体を対象としています
- 管理がはるかに少なくなります（個々の開発者は、sysadminの助けを借りずに新しいプロジェクトを作成できます）
- リポジトリコミットの概要と監視オプションの改善
私見（そして私たちの特定のプロジェクトに関して）は、長所が短所を上回っています。
プロジェクトごとのリビジョン番号のためだけに、プロジェクトのリポジトリがあります。 AvNをセットアップして、ApacheおよびDAV SVN（SVNParentPathディレクティブを使用）を使用して、単一のアクセスポイントからすべてのプロジェクトにアクセスできるようにすることができます。
プロジェクトの複雑さに基づいて決定することもできます。あなたが取り組む他のほとんどすべてから分離されるであろう巨大な努力を始めていて、それに取り組んでいる大規模な開発チームを持っているなら、それに別のリポジトリを与えることは理にかなっているかもしれません。
一度に多数の小さなプロジェクトで作業するチームの場合、単一のリポジトリが、すべてを1か所で管理するためのシンプルなメカニズム（バックアップ、検索など）を提供します。中央リポジトリは、プロジェクトが完了するか放棄されるとリポジトリが破棄されないため、リポジトリ自体がもう少し「具体的」に見えるようにします。
それはすべて、プロジェクトの数、組織の規模、プロジェクトの関連性などによって異なります。数十のプロジェクトを持つ大規模なチームの一員である場合、プロジェクトごとのリポジトリは管理がかなり扱いにくいものになります。
組織が行う作業の種類に応じて、別のオプションは、ごとに1つのリポジトリを持つことです。 クライアント。私が働いている場所には、現在4つのリポジトリがあります。1つは完全に社内のプロジェクト用、1つは販売するソフトウェア用、2つは特定のクライアントに完全に固有であり、クライアントにのみ適用可能なカスタムソフトウェアを作成します。これは「両方の長所」ソリューションの試みです。すべてを含み、数十億のリビジョン番号を持つ1つの大規模なリポジトリはありませんが（明らかに誇張しています！）、数十の非常に小さなリポジトリもありません。それぞれに1つのプロジェクトがあります。
Subversionを使用している場合は、同じドメインに複数のリポジトリがあり、それぞれに複数のプロジェクトがある可能性があります。
だからこのようになります
Project1: svn://svn.company.com/project1
Project2: svn://svn.company.com/project2
Project1はフロントエンドコードに対応し、admin /やweb /などのサブプロジェクトを含みます。Project2はバックエンドであり、さまざまなツールと監視アプリケーションが含まれます。
Gitのようなものを使用する場合、各リポジトリは単一のプロジェクトである必要があります。
私の組織では、途中で、さまざまなコーディング「領域」用にいくつかのリポジトリを作成しました。各リポジトリには、互いにかなり分離されたプロジェクトが含まれることを事前に知っていました。
私は両方を実行しましたが、どちらの場合も、他の方法を選択したかったのですが...
私は1つのリポジトリに落ち着きましたが良い解決策です。私がより大きな会社にいた場合、私は再考することに注意してください。
私は厳しいルールで多くのお客様に対応している会社で働いています。現在、約130人の開発者がいます。お客様のニーズに合わせてカスタマイズされたコアプロジェクトがあります。そして、1つの巨大なsvnリポジトリがあります。ブランチ全体をチェックアウトする必要があるとしたら、お尻が痛くなりますが、私たちの戦略は、プロジェクトを共通のブランチから移動し、switchコマンドのみに作業を任せることです。 :)このようにして、すべてを単一のリポジトリに保持できます。
私の唯一の懸念は、作業の一部をアウトソーシングする場合に必要に応じてリポジトリを複数のリポジトリに分割すること、またはこれが見つかるまでプロジェクト全体を販売することでした： http://www.mugo.ca/Blog/Splitting -a-Subversion-repository-into-multiple-repositories
したがって、svn switchは長いチェックアウトの苦痛を和らげると思います（1つは目的のプロジェクトのみを切り替えます）が、1つのリポジトリを持つことができます。ただし、それでも必要な場合は、コンポーネントのセットを抽出してリポジトリを分離できます。