Subversion - 需要改变存储库的结构吗?

时间:2010-12-22 13:46:22

标签: svn

我使用Subversion,我认为我的存储库结构不好。 我有:

/repoA
    /project10
    /project11
    /project12
    /project13
    /project14
    ...
/repoB
    /project20
    /project21
    /project22
    ...

因此,我将几个项目放入一个完全独立的存储库中。所以在/ repoX下,“存储库”只是文件夹。

我认为更好的是这样的结构,其中一个项目是一个单独的存储库。

/repoProject10
/repoProject11
/repoProject12
/repoProject13
...
/repoProject20
/repoProject21
...
你怎么看?主要问题是用户对存储库的限制。我不希望一个用户可以看到repoA /,用户应该只读取和写入/ project11 / project22。所以我必须限制路径...... 此外,一个存储库只有一个历史记录,而不是项目。

那么您如何看待,更改结构是否更好?一个项目由一个存储库管理?

最诚挚的问候。

2 个答案:

答案 0 :(得分:2)

这有点主观,但是,将每个项目都放在自己的存储库中并不罕见。

除非项目很小,并且与整个项目相比,创建新回购的工作量很大,这就是我要做的。 (我确实有一个“随机东西”存储库,用于不属于任何其他地方的小工具,脚本和尖峰)。

管理每个报告的权限也很有可能,所以当你担心时,我不确定你的意思。您可以向任何特定用户授予您希望他们拥有的权限。

例如,在我以前工作的客户端,我们有一个类似于(简化为删除分支/主干/标签等)的结构:

/RepoCoreLibrary

/RepoProject1
    /RepoCoreLibrary <as an svn external>

然后,您可以让某些Devs只读访问Core,但可以读取和写入他们的项目。防止初级开发人员意外或未经代码审查而向您提交核心代码。

答案 1 :(得分:2)

我会把你所有的项目放在一个大的存储库中。

其他人也没有遇到任何问题。例如,repository of the apache software foundation包含大约一百个项目(其中包括颠覆本身!)和一百多万个修订。

  

我不希望一个用户可以看到repoA /,用户应该只读取和写入/ project11 / project22。所以我必须限制路径......

Subversion确实Path-Based Authorization,所以即使你把所有东西放在一个存储库中,你仍然可以为每个项目分别管理读/写访问。

  

另外,一个存储库只有一个历史记录,而不是项目。

我不确定你的意思。如果您执行svn log http://example.com/svn/projectA,那么即使在同一存储库中存在projectB,您也只会看到projectA的历史记录。

也许您的意思是您对整个存储库的修订号全局推进的方式感到不舒服。我建议只考虑SVN修订版作为时间坐标。它的唯一含义是较低版本的修订号更高。事实上,如果您愿意,甚至可以不使用修订号,而是使用revision dates