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

【问题标题】：SVN Project(s) organization: per-module or per-projectSVN 项目组织：每个模块或每个项目
【发布时间】：2010-09-13 02:57:51
【问题描述】：

我有一个 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 project-organization

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

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

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

【讨论】：

【解决方案3】：

我更喜欢第一个。

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

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

【讨论】：

+1 这些版本号在持续构建环境中很有用。

【解决方案4】：

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

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

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

如果您将它与 svn externals 和/或 vendor branches 结合使用，您可以为需要不同模块版本的项目支持不同的分支，但当项目碰巧共享时，仍然可以从单一模块源中受益相同版本的模块。

【讨论】：

【解决方案5】：

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

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

【讨论】：