一个或多个SVN存储库？

如果您有多个不相关的项目，将它们放在同一个存储库中是个好主意吗？

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主机已开始按每个存储库收费，因此我正在考虑将多个存储库合并为一个。

单一问题还是多重问题取决于个人或组织的偏好。

多个或单个管理主要归结于访问控制和维护。

单个存储库的访问控制可以包含在单个文件中；多个存储库可能需要多个文件。维护也有类似的问题-一个大备份，或者很多小备份。

我自己管理。有一个存储库，多个项目，每个项目都有自己的标签，主干和分支。如果太大，或者我需要物理隔离客户的代码以使他们感到舒适，那么我可以快速轻松地创建一个新的存储库。

我最近向一家相对较大的公司进行了咨询，以将多个源代码控制系统迁移到Subversion。他们有大约50个项目，范围从很小到企业应用程序以及他们的公司网站。他们的计划？从单个存储库开始，如有必要，迁移到多个存储库。迁移几乎完成，它们仍在单个存储库中，由于它是单个存储库，因此没有投诉或问题的报告。

这不是二进制，黑白问题。

做对你有用的事 -如果您处于我的位置，我会尽快键入命令将项目合并到单个存储库中，因为成本（在非常小的公司中）将是主要考虑因素。

JFTR：

Subversion中的修订版本号在存储库外部确实没有任何意义。如果您需要有意义的名称来进行修订，创建一个TAG

提交消息很容易按存储库中的路径过滤，因此仅读取与特定项目相关的消息是一件很简单的事情。

编辑：请参阅 对SVN使用单一授权/身份验证配置的详细信息， Blade的响应。

对于您的特定情况，one（1）存储库是完美的。您将节省很多钱。我总是鼓励人们使用单个存储库。因为它类似于单个文件系统，所以更容易

• 您将在一个地方寻找代码
• 您将获得一个授权
• 您将有一个提交编号（曾经尝试构建一个分布在3个存储库中的项目吗？）
• 您可以更好地重用公共库并跟踪这些库中的进度（svn：externals是PITA，无法解决所有问题）
• 计划为完全不同的项目的项目可以一起成长并共享功能和接口。在多个存储库中很难做到这一点。

有多个存储库有一点：管理大型存储库是不舒服的。倾销/加载巨大的仓库需要很多时间。但是，由于您不进行任何管理，因此我认为这不会引起您的关注；）

SVN可以在较大的存储库中很好地扩展，即使在大型（> 100GB）的存储库上也不会出现速度下降的情况。

因此，使用单个存储库就可以减少麻烦。但是您真的应该考虑回购的布局！

我会使用多个存储库。除了用户访问问题外，它还使备份和还原更加容易。而且，如果您发现自己处于有人愿意为您的代码（及其代码）付钱的位置，则将它们仅存储库转储会更容易。

我建议仅由于托管服务提供商的收费政策而合并存储库不是一个很好的理由。

我们使用单个存储库。我唯一关心的是规模，但在看到ASF的存储库后（70万次修订并不断增加）后，我坚信性能不会成为问题。

我们的项目都是相关的互锁模块，它们为任何给定应用程序形成了一组依赖关系。因此，理想的是单个存储库。您可能需要为每个项目使用单独的主干/分支/标签，但是您仍然可以在单个修订版中自动对整个代码库进行更改。重构很棒。

请注意，在做出决定时，许多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

我将创建单独的存储库 ...为什么？如果您在一个存储库中有很多无关的项目，那么修订号和提交消息将毫无意义，这肯定会在短期内造成很大混乱。

我们是一家小型软件公司，我们在整个开发过程中使用一个仓库。树看起来像这样：

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

这个想法是我们将客户和内部工作放在同一个仓库中，但是最终我们将公司作为自己的“客户”。

这对我们来说确实非常有效，我们使用Trac进行接口。修订号遍及整个回购，而不是特定于一个项目的，但是这并不涉及我们。

就个人而言，我将为每个数据库创建新的存储库。它使结帐过程变得更加简单，并且至少在用户访问和备份方面使整体管理变得更加容易。而且，它避免了全局版本号问题，因此版本号在所有项目上都有意义。

确实，您应该只使用git;）

需要考虑的另一件事是，使用多个存储库会使您失去使用统一日志记录的能力（svn log命令），这仅仅是选择单个存储库的好理由。

我使用TortuiseSvn，发现“显示日志”选项是强制性工具。尽管您的项目无关，但我相信您会发现，拥有集中的全局跨项目信息（路径，错误ID，消息等）总是有用的。

如果您计划或使用与Tracwich之类的工具与SVN集成，则在每个项目中使用一个仓库即可。

与Blade关于共享文件的建议类似，这是一个稍微简单但不灵活的解决方案。我像这样设置我们的：

• / 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”中，我保留了所有存储库都具有符号链接的公共“ conf”和“ hooks”目录。然后，只有一组文件。但是，这确实消除了按项目进行细粒度访问而不破坏链接的能力。在我进行此设置时，不必担心。

最后，我将主目录/ 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相似，但是文件夹结构更进一步，可以轻松缩放到特定类型的项目-基于Web html的项目vs. cs（C＃）vs. sql（SQL创建/执行脚本）vs. xyz（特定于域的语言，例如afl（AmiBroker公式语言）或ts（TradeStation））：

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

注意，我将主干放在分支内，因为我将其作为默认分支。有时唯一的麻烦是当您要快速创建另一个项目时，需要构建ProjectName / branches | tags结构。我将应用程序设置简单地用作保存回购中特定应用程序设置文件的位置，以便与其他人轻松共享（并在此文件夹结构中将ClientName替换为VendorName并将ProjectName替换为AppName；并且branch || tags可用于标记不同主要版本的设置供应商产品的版本）。

欢迎您对我的结构发表评论-我最近将其更改为该结构，到目前为止还算很高兴，但是有时发现为每个项目维护分支结构很麻烦-特别是如果该项目只是一个项目设置而仅仅是对另一个项目进行单元测试时。

我的建议是一个。除非您有不同的用户访问每个用户，否则我会说使用多个。

但是，即使那样，也不是使用倍数的好理由。