SVN 项目组织：每个模块或每个项目

Question

我有一个 subversion 存储库，其中包含许多 so 子文件夹，对应于构成我的项目的各种应用程序、配置文件、DLL 等（我将它们称为“模块”）。 现在我们开始“分支”到几个相关的项目。 也就是说，每个高级项目将使用许多模块，可能会根据项目进行稍微修改。 项目数量 (~5) 小于模块数量 (~20)

现在我试图弄清楚如何组织存储库。 逐个模块地保留顶级子文件夹并为每个项目保留子文件夹是否有意义？ 或者顶层应该针对每个项目，每个项目都有自己的模块子文件夹：

repo:

module 1
    Project 1
    Project 2
    ...

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

-或-

repo:

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

Answer 1

似乎最好在顶层按项目进行组织，因为您需要签出整个分支并拥有该项目的工作副本。 如果您按模块进行组织，则必须进行多次检查（针对您正在使用的每个模块进行一次检查）才能将项目构建到可用的程度。

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

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

如果将其与 svn 外部和/或供应商分支，您可以为需要不同模块版本的项目支持不同的分支，但当项目碰巧共享相同版本的模块时，仍然受益于单个模块源。

Answer 2

我将按项目组织，然后按模块组织（您的第二个示例）。 主要原因是管理项目的开销比管理模块要多，至少对我来说是这样。

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

Answer 3

我更喜欢第一个。

虽然每个存储库确实需要额外的精力来维护，但我希望我的修订号对项目有意义。

即我们的旗舰产品的修订版为48123，我们的新项目的修订版为31。如果您有存储库间的依赖关系，那么您可以使用svn externals。

Answer 4

我认为您使用“高级”来描述项目是什么表明您应该有一个项目/模块设置。

但是，您可以设置模块和项目 - 即它们在 SVN 存储库中处于同一级别。 您的项目可以依赖于模块，如果可能的话，项目可以提供特定的操作实现，将模块转换为具有默认但可重写实现的基本模块。

Answer 5

我倾向于按项目进行组织，但现在总是如此。 如果您的代码有访问控制方面的内容，请组织起来最小化权限管理； 这也可能导致存储库按团队组织。

顺便说一句：您似乎期望在一个大存储库中工作 - 我认为这很聪明，因为这意味着更好的历史处理：一旦您在存储库之间移动内容，您就会丢失历史记录。 换句话说，我不同意 Ben Scheirman 对此的建议。