我有一个Subversion存储库，其中包含一些子文件夹，这些子文件夹对应于组成我的项目的各种应用程序，配置文件，DLL等(我称它们为"模块")。现在，我们开始"分支"到几个相关的项目中。也就是说，每个高级项目都将使用多个模块，每个模块之间可能对其进行了稍微的修改。项目数量(〜5)小于模块数量(〜20)

现在，我试图弄清楚如何组织回购。在每个模块的子模块中保留顶层子文件夹是否有意义，每个项目都有子文件夹？还是顶层应该针对每个项目，而每个项目都有自己的模块子文件夹：

回购：

module 1
    Project 1
    Project 2
    ...

    Project 5
module 2
    Project 1
    ....
    Project 5
....
module 20
    Project 1
    ...
    Project 5

-或者-

回购：

Project 1
   module 1
   module 2
   ...
   module 20
Project 2
   module 1
   module 2
   ...
   module 20
...
Project 5
   module 1
   module 2
   ...
   module 20

解决方案

我认为我们使用"高级"来描述一个项目意味着我们应该具有一个"项目/模块"设置。

但是我们可以设置一个模块和项目，即它们在SVN存储库中处于同一级别。项目可以依靠模块，并且如果可能的话，项目可以提供动作的特定实现，从而将模块转变为具有默认但可覆盖的实现的基本模块。

我将按Projects THEN按模块进行组织(第二个示例)。这样做的主要原因是，至少对我而言，管理项目比管理模块有更多的开销。

每个不同的项目都需要有自己的构建脚本设置，属性文件等，并且跟踪计算机上的5个工作副本要比20个要容易得多。

我喜欢第一个。

虽然每个存储库的维护工作都需要付出额外的精力，但我希望我的修订号对项目有意义。

也就是说，我们的旗舰产品的修订版为48123，我们的新项目的修订版为31. 如果我们具有存储库间相关性，则可以使用svn externals。

似乎最好在顶层按Project进行组织，因为我们将要签出整个分支并拥有该项目的工作副本。如果按模块进行组织，则必须进行多个签出(每个使用的模块一个)，以便将项目构建到可以使用的程度。

将项目和模块分开是有意义的，例如：

Projects
   Project 1
   Project 2
   ...
Modules
   Module 1
   Module 2
   ...

如果将其与svn外部和/或者供应商分支结合使用，则可以为需要不同模块版本的项目支持不同的分支，但是当项目碰巧共享相同版本的模块时，仍然可以从拥有单个模块源中受益。

我倾向于按项目进行组织，但现在总是如此。如果代码具有访问控制方面的内容，则应进行组织以最大程度地减少权限管理。这也可能导致存储库按团队进行组织。

顺便说一句：我们似乎期望在一个大型存储库中工作，我认为这很聪明，因为这意味着可以更好地处理历史记录：在存储库之间移动内容时，我们就会松散历史记录。换句话说，我不同意本·谢尔曼(Ben Scheirman)在此方面的建议。