SVNリポジトリは1つですか、それとも複数ですか？

複数の無関係なプロジェクトがある場合、それらを同じリポジトリに配置することは良い考えですか？

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/branches
myRepo/projectB/trunk
myRepo/projectB/tags
myRepo/projectB/branches

または、それぞれに新しいリポジトリを作成しますか？

myRepoA/trunk
myRepoA/tags
myRepoA/branches
myRepoB/trunk
myRepoB/tags
myRepoB/branches

それぞれの長所と短所は何ですか？私が現在考えることができるすべては、あなたが混合されたリビジョン番号を取得することです（そうですか？）、そしてsvn:externalsリポジトリが実際に外部のものでない限り使用できません。（おもう？）

私が尋ねる理由は、私のSVNホストがリポジトリごとに課金を開始したため、複数のリポジトリを1つに統合することを検討しているためです。

単一または複数の問題は、個人または組織の好みに帰着します。

複数対単一の管理は、主にアクセス制御と保守に行き着きます。

単一のリポジトリのアクセス制御は、単一のファイルに含めることができます。複数のリポジトリには複数のファイルが必要な場合があります。メンテナンスにも同様の問題があります。1つの大きなバックアップ、または多数の小さなバックアップです。

私は自分で管理します。1つのリポジトリ、複数のプロジェクトがあり、それぞれに独自のタグ、トランク、ブランチがあります。サイズが大きくなりすぎたり、お客様のコードを物理的に分離して快適にする必要がある場合は、新しいリポジトリをすばやく簡単に作成できます。

私は最近、複数のソースコード管理システムをSubversionに移行することについて、比較的大きな会社と相談しました。彼らは、非常に小さなアプリケーションからエンタープライズアプリケーション、そして企業のウェブサイトに至るまで、約50のプロジェクトを抱えています。彼らの計画は？単一のリポジトリから始め、必要に応じて複数に移行します。移行はほぼ完了しており、単一のリポジトリ上にあります。単一のリポジトリであるため、不満や問題は報告されていません。

これは、白黒の問題ではありません。

私の立場にあれば、コマンドを入力するのと同じ速さでプロジェクトを1つのリポジトリに結合します。これは、私の（非常に小さい）会社ではコストが主な考慮事項であるためです。

JFTR：

Subversionのリビジョン番号は、リポジトリの外では意味がありません。リビジョンに意味のある名前が必要な場合は、タグを作成します

コミットメッセージはリポジトリ内のパスで簡単にフィルタリングできるため、特定のプロジェクトに関連するメッセージのみを読み取るのは簡単なことです。

編集：SVNの単一の承認/認証構成の使用の詳細については、Bladeの応答を参照してください。

特定のケースでは、one（1）リポジトリが最適です。あなたはたくさんのお金を節約するでしょう。私は常に、単一のリポジトリーを使用することをお勧めします。単一のファイルシステムに似ているため、簡単です

• コードを探す場所が1つになります
• 単一の承認があります
• あなたは単一のコミット番号を持っています（3つのリポジトリにまたがるプロジェクトを構築しようとしたことがありますか？）
• 一般的なライブラリを再利用し、これらのライブラリの進捗状況を追跡することができます（svn：externalsはPITAであり、すべての問題を解決するわけではありません）
• 完全に異なるアイテムとして計画されたプロジェクトは、一緒に成長し、機能とインターフェースを共有できます。これを複数のリポジトリで達成することは非常に困難です。

複数のリポジトリには単一のポイントがあります。巨大なリポジトリの管理は不快です。巨大なリポジトリをダンプ/ロードするには、かなりの時間がかかります。しかし、あなたはいかなる管理も行わないので、私はそれがあなたの心配ではないと思う;）

SVNは、より大きなリポジトリで非常に適切にスケーリングします。巨大な（> 100GB）リポジトリであっても速度低下はありません。

したがって、単一のリポジトリーを使用することで、面倒が少なくなります。しかし、あなたは本当にリポジトリのレイアウトについて考えるべきです！

複数のリポジトリを使用します。ユーザーアクセスの問題に加えて、バックアップと復元も簡単になります。そして、誰かがあなたのコード（とその履歴）に対してあなたにお金を払いたがっている立場にいるなら、彼らにリポジトリのダンプを提供する方が簡単です。

ホスティングプロバイダーの課金ポリシーのためにリポジトリを統合することは、それほど正当な理由ではないことをお勧めします。

単一のリポジトリを使用します。私の唯一の懸念はスケールでしたが、ASFのリポジトリ（700kのリビジョンとカウント）を確認した後、パフォーマンスは問題ではないと確信しました。

私たちのプロジェクトはすべて、関連する異なるインターロックモジュールであり、特定のアプリの一連の依存関係を形成します。このため、単一のリポジトリが理想的です。プロジェクトごとに個別のトランク/ブランチ/タグが必要な場合がありますが、1つのリビジョン内のコードベース全体に変更をアトミックにコミットできます。これはリファクタリングに最適です。

決定するときは、多くのSVNリポジトリが同じ設定ファイルを共有できることに注意してください。

例（上記のリンクから取得）：

シェルで：

$ svn-admin create /var/svn/repos1
$ svn-admin create /var/svn/repos2
$ svn-admin create /var/svn/repos3

ファイル：/var/svn/repos1/conf/svnserve.conf

[general]
anon-access = none # or read or write
auth-access = write
password-db = /var/svn/conf/passwd
authz-db = /var/svn/conf/authz
realm = Repos1 SVN Repository

ファイル：/ var / svn / conf / authz

[groups]
group_repos1_read = user1, user2
group_repos1_write = user3, user4
group_repos2_read = user1, user4

### Global Right for all repositories ###
[/]
### Could be a superadmin or something else ###
user5 = rw

### Global Rights for one repository (e.g. repos1) ###
[repos1:/]
@group_repos1_read = r
@group_repos1_write = rw

### Repository folder specific rights (e.g. the trunk folder) ###
[repos1:/trunk]
user1 = rw

### And soon for the other repositories ###
[repos2:/]
@group_repos2_read = r
user3 = rw

別のリポジトリを作成します ...なぜですか？リビジョン番号とコミットメッセージは、1つのリポジトリに多くの無関係なプロジェクトがある場合、意味がありません。短期的には、大きな混乱を招くことになります。

私たちは小さなソフトウェア会社であり、すべての開発に単一のリポジトリを使用しています。ツリーは次のようになります。

/client/<clientname>/<project>/<trunk, branches, tags>

クライアントと内部の作業を同じリポジトリに置くという考えでしたが、最終的には会社をそれ自体の「クライアント」として持つことになりました。

これは非常にうまく機能しており、Tracを使用してインターフェイスします。リビジョン番号はリポジトリ全体に渡っており、1つのプロジェクトに固有のものではありませんが、それは私たちを段階的にしません。

個人的には、それぞれに新しいリポジトリを作成します。これにより、チェックアウトプロセスがずっと単純になり、少なくともユーザーアクセスとバックアップに関して、全体的な管理が容易になります。また、グローバルバージョン番号の問題を回避できるため、バージョン番号はすべてのプロジェクトで意味があります。

実際には、gitを使用するだけです;）

考慮すべきもう1つのことは、複数のリポジトリを使用すると、統合ログ（svn logコマンド）を使用する機能が失われるという事実です。これだけでも、単一のリポジトリを選択する理由になります。

TortuiseSvnを使用していますが、[ログを表示]オプションが必須のツールであることがわかりました。あなたのプロジェクトは無関係ですが、一元化されたグローバルなクロスプロジェクト情報（パス、バグID、メッセージなど...）が常に役立つことがわかるでしょう。

SVNと統合するtrac wichなどのツールを使用する予定がある場合は、プロジェクトごとに1つのリポジトリを使用する方が理にかなっています。

ファイルの共有に関するブレードの提案と同様に、これはやや簡単ですが、柔軟性は低くなります。私は次のようにセットアップしました：

• / var / svn /
• / var / svn / bin
• / var / svn / repository_files
• / var / svn / svnroot
• / var / svn / svnroot / repos1
• / var / svn / svnroot / repos2
• ...

"bin"には、空のリポジトリを作成するためのすべての設定作業を行うsvn-create.shというスクリプトを保存します。そこにもバックアップスクリプトを保持しています。

「repository_files」では、すべてのリポジトリにsymリンクがある共通の「conf」および「hooks」ディレクトリを保持しています。次に、ファイルのセットは1つだけです。ただし、これにより、リンクを壊すことなく、プロジェクトごとにきめ細かくアクセスできるようになります。これを設定したところ、それは問題ではありませんでした。

最後に、メインディレクトリ/ var / svnをソース管理下に置いて、svnrootのすべてを無視します。このようにして、リポジトリファイルとスクリプトもソース管理されます。

#!/bin/bash

# Usage:
# svn-create.sh repository_name

# This will:
# - create a new repository
# - link the necessary commit scripts
# - setup permissions
# - create and commit the initial directory structure
# - clean up after itself

if [ "empty" = ${1}"empty" ] ; then
  echo "Usage:"
  echo "    ${0} repository_name"
  exit
fi

SVN_HOME=/svn
SVN_ROOT=${SVN_HOME}/svnroot
SVN_COMMON_FILES=${SVN_HOME}/repository_files
NEW_DIR=${SVN_ROOT}/${1}
TMP_DIR=/tmp/${1}_$$

echo "Creating repository: ${1}"

# Create the repository
svnadmin create ${NEW_DIR}

# Copy/Link the hook scripts
cd ${NEW_DIR}
rm -rf hooks
ln -s ${SVN_COMMON_FILES}/hooks hooks

# Setup the user configuration
cd ${NEW_DIR}
rm -rf conf
ln -s ${SVN_COMMON_FILES}/conf conf

# Checkout the newly created project
svn co file://${NEW_DIR} ${TMP_DIR}

# Create the initial directory structure
cd ${TMP_DIR}
mkdir trunk
mkdir tags
mkdir branches

# Schedule the directories addition to the repository
svn add trunk tags branches

# Check in the changes
svn ci -m "Initial Setup"

# Delete the temporary working copy
cd /
rm -rf ${TMP_DIR}

# That's it!
echo "Repository ${1} created. (most likely)"

単一のリポジトリを使用するmlambieに似ていますが、フォルダー構造をさらに進めて、特定のタイプのプロジェクトに簡単にズームしました。 afl（AmiBroker Formula Language）やts（TradeStation）などのドメイン固有の言語：

/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>

トランクをデフォルトのブランチとして扱うため、ブランチ内にトランクが存在することに注意してください。唯一の問題は、ProjectName / branches | tags構造を構築する必要がある別のプロジェクトをすばやく作成したい場合です。私はapp-settingsを単に特定のApps設定ファイルをリポジトリに保持して他のユーザーと簡単に共有できる場所として使用します（このフォルダー構造でClientNameをVendorNameに、ProjectNameをAppNameに置き換えます。ブランチ|タグは、さまざまなメジャーの設定にタグを付けるのに役立ちます。ベンダー製品のバージョンも）。

私の構造へのコメントへようこそ-私は最近これに変更しましたが、これまでのところかなり満足していますが、特にプロジェクトがブランチ|タグ構造をプロジェクトごとに維持するのが面倒であることに気づきました。

私の提案は1つです。それぞれに異なるユーザーがアクセスしているのでない限り、複数を使用すると思います。

しかし、繰り返しますが、それでも複数を使用するのは良い理由ではありません。