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

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

现在我想弄清楚如何组织回购。在每个模块的基础上保留顶级子文件夹以及每个项目的子文件夹有意义吗？或者顶层应该是每个项目，每个项目都有自己的模块子文件夹：

回购：

-或-

回购：

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

---

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

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

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

我更喜欢第一个

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

---

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

似乎最好在顶层按项目组织，因为您需要签出整个分支并为项目提供一个工作副本。如果您按模块进行组织，则必须进行多次签出（您正在使用的每个模块一次签出），以便将项目构建到可用的位置

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

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

---

如果将其与svn和/或结合使用，您可以为需要不同模块版本的项目支持不同的分支，但当项目恰好共享同一版本的模块时，仍然可以从使用单一模块源中获益。

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

---

顺便说一句：你似乎期望在一个大的存储库中工作——我认为这很聪明，因为这意味着更好的历史处理：一旦你在存储库之间移动了东西，你就失去了历史。换句话说，我不同意Ben Scheirman在这方面的建议。

+1这些构建编号在连续构建环境中很有用。

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

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