如果您有多个不相关的项目,将它们放在同一个存储库中是一个好主意吗?
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
除非存储库实际上是外部的,否则你不能使用它.(我认为?)
我问的原因是因为我正在考虑将我的多个repos合并为一个,因为我的SVN主机已开始按每个回购计费.
单一与多重问题归结为个人或组织偏好.
多重与单一的管理主要归结为访问控制和维护.
单个存储库的访问控制可以包含在单个文件中; 多个存储库可能需要多个文件.维护有类似的问题 - 一个大的备份,或许多小备份.
我管理自己的.有一个存储库,多个项目,每个项目都有自己的标签,主干和分支.如果一个人太大或者我需要在物理上隔离客户的代码以获得他们的舒适,我可以快速轻松地创建一个新的存储库.
我最近咨询了一家相对较大的公司,将多个源代码控制系统迁移到Subversion.他们有大约50个项目,从非常小的企业应用程序和企业网站.他们的计划?从单个存储库开始,如有必要,迁移到多个存储库.迁移几乎完成,它们仍然在一个存储库中,由于它是一个存储库而没有报告任何投诉或问题.
这不是二元,黑白问题.
做什么对你有用 - 如果我在你的位置,我会尽可能快地将项目组合到一个存储库中,因为成本将是我(非常非常小)公司的主要考虑因素.
JFTR:
Subversion中的修订号在存储库之外没有任何意义.如果您需要有意义的修订名称,请创建TAG
提交消息很容易通过存储库中的路径进行过滤,因此只读取与特定项目相关的消息是一项微不足道的工作.
编辑:有关使用SVN的单一授权/身份验证配置的详细信息,请参阅Blade的响应.
对于您的特定情况,一(1)个存储库是完美的.你会节省很多钱.我总是鼓励人们使用单一的存储库.因为它类似于单个文件系统:它更容易
您将在一个地方查找代码
您将获得一个授权
你将有一个提交号码(曾试图建立一个分布在3个回购的项目?)
您可以更好地重用公共库并跟踪这些库中的进度(svn:externals是PITA,不会解决所有问题)
项目计划为完全不同的项目,可以一起成长并共享功能和界面.这在多个回购中很难实现.
多个存储库有一个点:管理巨大的存储库是不舒服的.倾倒/装载巨大的回购需要花费很多时间.但是,由于你没有做任何管理,我认为这不会是你的关注;)
SVN在更大的存储库中可以很好地扩展,即使在巨大的(> 100GB)存储库上也没有减速.
因此,您可以减少单个存储库的麻烦.但你真的应该考虑回购布局!
我会使用多个存储库.除了用户访问问题之外,它还使备份和还原更容易.如果你发现自己处于某个人想要为你的代码(及其历史)支付费用的位置,那么就更容易给他们一个存储库转储.
我建议仅仅因为托管服务提供商的收费政策而整合存储库并不是一个很好的理由.
我们使用单个存储库.我唯一担心的是规模,但在看到ASF的存储库(700k修订和计数)后,我非常确信性能不会成为问题.
我们的项目都是相关的,不同的互锁模块,它们为任何给定的应用程序形成一组依赖关系.因此,单个存储库是理想的.对于每个项目,您可能需要单独的主干/分支/标记,但您仍然可以在单个修订中以原子方式提交整个代码库中的更改.这对于重构来说非常棒.
请注意,在做出决定时,许多SVN repos可以共享相同的配置文件.
示例(取自上面的链接):
在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 (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// /
我们的想法是,我们将客户和内部工作放在同一个回购中,但最终我们将公司作为自己的"客户".
这对我们来说非常有效,我们使用Trac与它进行交互.修订版号在整个仓库中并不是特定于一个项目,但这并不会使我们分阶段.