你如何构建你的SVN仓库？

Question

有什么更好？

答：

server:1080/repo/projectA/trunk/... 
          branches/branch1 
          branches/branch2 
          branches/branch3 
          tags/tag1/... 
          tags/tag2/... 
server:1080/repo/projectB/trunk/... 
          branches/branch1 
          branches/branch2 
          branches/branch3 
          tags/tag1/... 
          tags/tag2/... 

B：

server:1080/repo/trunk/projectA/... 
       branches/projectA/branch1 
       branches/projectA/branch2 
       branches/projectA/branch3 
       tags/projectA/tag1/... 
       tags/projectA/tag2/... 
server:1080/repo/trunk/projectB/trunk/... 
       branches/projectB/branch1 
       branches/projectB/branch2 
       branches/projectB/branch3 
       tags/projectB/tag1/... 
       tags/projectB/tag2/... 

什么库结构你用？为什么？

Answer 1

SVN book的Repository Administration章节包含了一个关于Planning Your Repository Organization的章节，概述了不同策略及其含义，特别是the implications of the repository layout on branching and merging。

Answer 2

我们使用A，因为另一个对我们没有意义。请注意，关于SVN的“项目”不一定是单个项目，但可能是几个属于同一个项目的项目（即，您将在Visual Studio中放入解决方案的项目）。这样，你有任何相关的组合在一起。所有分支，标签和特定项目的主干。对我来说完全有意义。

通过分支/标记进行分组对我来说没有意义，因为不同项目的分支没有任何共同之处，只是它们都是分支。

但最终，人们使用两种方式。做你喜欢的事情，但是当你决定时，尽量保持它:)

作为补充：我们为每个客户单独存储库，即客户的所有项目都在同一个存储库中。这样你可以例如立即备份单个客户，或者提供客户拥有的任何源代码，而不与SVN争吵。

Answer 3

我建议的选项C：

server:1080/projectA/trunk/... 
        branches/branch1 
        branches/branch2 
        branches/branch3 
        tags/tag1/... 
        tags/tag2/... 
server:1080/projectB/trunk/... 
        branches/branch1 
        branches/branch2 
        branches/branch3 
        tags/tag1/... 
        tags/tag2/... 

我喜欢保持独立的项目在不同的存储库。使用svn:externals可以轻松管理在两个或更多应用程序项目之间共享的代码库项目。

Answer 4

我们使用设置B.因为它更容易一次签出/标记多个项目。在svn 1.5中，可以通过稀疏检出，但不能单击一次操作。 如果某些项目之间存在隐藏依赖关系，则要使用设置B.

Answer 5

我们使用

/repos/projectA/component1/trunk - branches - tags 
/repos/projectA/component2/trunk - branches - tags 
/repos/projectB/component3/trunk - branches - tags 
/repos/projectB/component4/trunk - branches - tags 

这我开始后悔。它应该更平坦。这会更好。

/repos/projectA/trunk - branches - tags 
/repos/projectB/trunk - branches - tags 
/repos/component1/trunk - branches - tags 
/repos/component2/trunk - branches - tags 
/repos/component3/trunk - branches - tags 
/repos/component4/trunk - branches - tags 

为什么？产品（组件，成品软件）永远持续。项目来来去去。去年，只有一个项目团队正在创建QUUX产品。明年，这个团队被分散开来，有一两个人维护QUUX。明年将会有两个大型QUUX扩展项目。

鉴于时间表，QUUX应该出现在三个项目存储库中吗？不，QUUX独立于任何特定的项目。确实，这些项目确实有工作产品（文件，积压件等），这些是完成工作的一部分，但并不是工作的实际目标。因此，该材料的“projectX”存储库 - 在项目完成后没人会关心的东西。

我参与了一个有三个团队的产品。由于每个项目独立管理其存储库，因此存在工作协调的大问题。有团队间发布和团队间协调。在那天结束时，它应该是一个软件。但是，正如你所猜测的那样，这是三个具有奇怪重叠和冗余的软件。

Answer 6

我个人使用以下的版本库结构：

/project 
    /trunk 
    /tags 
     /builds 
      /PA 
      /A 
      /B 
     /releases 
      /AR 
      /BR 
      /RC 
      /ST 
    /branches 
     /experimental 
     /maintenance 
      /versions 
      /platforms 
     /releases 

还有一个diagram说明这些目录是如何使用的。还有我使用的特定版本编号方法。它在存储库结构中扮演重要角色。最近我开发了专门用于软件配置管理的培训，其中描述了版本编号方法，以及为什么这个存储库结构是最好的。这里是presentation slides。

关于'Multiple SVN Repositories vs single company repository'，question上也有我的answer。只要您在您的问题中解决存储库结构的这一方面问题，这可能会有所帮助。