一个SVN仓库还是很多？
如果您有多个不相关的项目，将它们放在同一个存储库中是不是一个好主意？
myRepo/projectA/trunk myRepo/projectA/tags myRepo/projectA/branches myRepo/projectB/trunk myRepo/projectB/tags myRepo/projectB/branches 或者你会为每个创build新的存储库？
myRepoA/trunk myRepoA/tags myRepoA/branches myRepoB/trunk myRepoB/tags myRepoB/branches
各有什么优点和缺点？ 我现在所能想到的是，你得到混合版本号（所以是什么？），除非版本库是svn:externals否则你不能使用svn:externals externals。 （我认为？）
我问的原因是因为我正在考虑将我的多个回购整合到一个，因为我的SVN主机已经开始按回购计费。
单一问题与多重问题归结为个人或组织偏好。
多重pipe理与单一pipe理主要归结为访问控制和维护。
单个存储库的访问控制可以包含在单个文件中; 多个存储库可能需要多个文件。 维护有类似的问题 – 一个大的备份，或者很less的备份。
我pipe理我自己的。 有一个存储库，多个项目，每个项目都有自己的标签，主干和分支。 如果一个人太大了，或者我需要为了他们的舒适而隔离一个客户的代码，我可以快速，轻松地创build一个新的存储库。
我最近咨询了一家相对较大的公司，将多个源代码控制系统迁移到Subversion。 他们有50个项目，从非常小到企业应用程序和他们的企业网站。 他们的计划？ 从一个存储库开始，如有必要，迁移到多个存储库。 迁移几乎完成，他们仍然在一个存储库，没有投诉或报告，因为它是一个单一的存储库。
这不是一个二元，黑与白的问题。
做一下适合你的工作 – 我是否处于你的位置，我会尽可能快地将项目组合到一个存储库中，因为在我的（非常非常小的）公司中，成本将是一个主要考虑因素。
JFTR：
版本号在Subversion中确实没有任何意义。 如果您需要修订版本的有意义的名称，请创build一个TAG
提交消息很容易通过存储库中的path进行过滤，因此只读取与特定项目相关的消息是很简单的。
编辑：有关使用SVN的单一授权/validationconfiguration的详细信息，请参阅刀片服务器的响应。
对于您的具体情况，一个（1）存储库是完美的。 你会省下很多钱。 我总是鼓励人们使用一个存储库。 因为它与单个文件系统类似： 更容易
- 你将有一个地方你寻找代码
- 你将有一个单一的授权
- 你会有一个单一的提交号码（曾经试图build立一个项目，分散在3回购？）
- 你可以更好地重用通用库并跟踪你在这些库中的进度（svn：externals是PITA，不会解决所有的问题）
- 作为完全不同的项目计划的项目，可以共同成长，共享function和界面。 这将是很难实现多个回购。
对于多个存储库有一个单一的点：巨大的回购pipe理是不舒服的。 倾销/加载巨额回购需要很多时间。 但是，由于你不做任何pipe理，我认为这不会是你的关注;）
SVN可以在更大的存储库中很好地扩展，甚至在巨大的（> 100GB）存储库上也不会减速。
所以你会less一个单一的仓库麻烦。 但你真的应该考虑回购布局！
我会使用多个存储库。 除了用户访问问题之外，它还使备份和恢复更容易。 如果您发现自己处于某人想要为您的代码（及其历史logging）支付费用的位置，则只需向他们提供存储库转储就可以了。
我build议仅仅因为您的托pipe服务提供商的收费政策而合并储存库并不是一个很好的理由。
我们使用一个存储库。 我唯一的担心是规模，但看到ASF的存储库 （700K修订和计数），我相当确信性能不会是一个问题。
我们的项目都是相关的，不同的互锁模块对任何给定的应用程序形成一组依赖关系。 出于这个原因，一个存储库是理想的。 您可能需要为每个项目设置单独的主干/分支/标签，但您仍然可以在单个修订版本中自动在整个代码库中提交更改。 这对于重构来说太棒了。
请注意，在做出决定时， 许多SVN回购可以共享相同的configuration文件。
示例（摘自上面的链接）：
在shell中：
$ 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 (eg repos1) ### [repos1:/] @group_repos1_read = r @group_repos1_write = rw ### Repository folder specific rights (eg the trunk folder) ### [repos1:/trunk] user1 = rw ### And soon for the other repositories ### [repos2:/] @group_repos2_read = r user3 = rw
我会创build单独的存储库 …为什么？ 如果只有一个版本库中有很多不相关的项目，版本号和提交信息就没有任何意义，那么短期内肯定会是一团糟。
我们是一家小型的软件公司，我们所有的开发都使用单一的回购。 树看起来像这样：
/client/<clientname>/<project>/<trunk, branches, tags>
我们的想法是，我们将在同一个回购中有客户和内部的工作，但是我们最终让我们的公司成为了自己的“客户”。
这对我们非常有用，我们使用Trac来连接它。 修订号码在整个回购中并不具体到一个项目，但是这不会使我们分阶段。
就个人而言，我会为每个创build新的存储库。 它使检出过程更加简单，并使整体pipe理更加容易，至less在用户访问和备份方面。 而且，它避免了全球版本号的问题，所以版本号对所有项目都有意义。
真的，你应该只使用git;）
另外需要考虑的一个事实是，使用多个存储库会导致您失去统一日志logging（svn log命令）的能力，这仅仅是select单个存储库的好理由。
我使用TortuiseSvn，发现“显示日志”选项是一个必需的工具。 虽然你的项目是不相关的，但我相信你会发现拥有一个集中的全球跨项目信息（path，错误ID，消息等等）总是有用的。
如果您打算或使用与SVN集成的trac工具，则为每个项目使用一个回购更有意义。
与Blade有关共享文件的build议类似，这里是一个稍微简单但不太灵活的解决scheme。 我像这样设置我们的：
- 在/ var / SVN /
- 在/ var / SVN /箱
- 在/ var / SVN / repository_files
- 在/ var / SVN / svnroot
- 在/ var / SVN / svnroot / repos1版本
- 在/ var / SVN / svnroot / repos2
- …
在“bin”中，我保留一个名为svn-create.sh的脚本，它将完成创build一个空的存储库的所有设置工作。 我也保留备份脚本。
在“repository_files”中，我保留了所有存储库具有sym链接的通用“conf”和“hooks”目录。 那么，只有一组文件。 尽pipe如此，这确实消除了在不中断链接的情况下具有细粒度的每项目访问的能力。 如果我设定的话，这不是一个问题。
最后，我将源代码pipe理下的主目录/ 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)"
我的build议是一个。 除非你有不同的用户访问每一个，那么我会说使用多个。
但是，即使这不是一个很好的理由使用多个。
与mlambie使用单个回购相似，但进一步与文件夹结构进一步轻松缩放到特定types的项目 – 基于Web的项目与CS（C＃）与SQL（SQL创build/执行脚本）与XYZ域名特定语言，如afl（AmiBroker Formula Language）或ts（TradeStation））：
/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>
请注意，我有树枝生活在分支机构，因为我把它作为默认分支。 唯一的痛苦就是当你想要快速创build另一个项目时，你需要build立ProjectName / branches | tags结构。 我使用应用程序设置只是为了将特定的应用程序设置文件保存在回购站中，以便轻松地与其他人共享（并在此文件夹结构中将ClientNamereplace为VendorName和ProjectName以AppName;而分支|标记可用于跨不同的主要供应商产品的版本）。
欢迎来到我的结构上的任何评论 – 我最近改变了这个，到目前为止相当开心，但有时会觉得每个项目都要维护分支标记结构，特别是如果这个项目只是一个简单的项目设置unit testing另一个项目。
