Question

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

现在我正在试图弄清楚如何组织回购。将每个顶级子文件夹保持在逐个模块的基础上，每个项目的子子文件夹是否有意义？或者顶层应该是每个项目，每个项目都有自己的模块子文件夹：

回购：

module 1
    Project 1
    Project 2
    ...

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

-OR -

回购：

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 externals和/或vendor branches结合使用，您可以为需要不同模块版本的项目支持不同的分支，但仍可从单个模块源获益时获益项目碰巧共享相同版本的模块。

Answer 2

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

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

Answer 3

我更喜欢第一个。

虽然每个存储库需要额外的维护才能维护，但我喜欢我的版本号对项目有意义。

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

Answer 4

我认为您使用“高级”来描述项目是什么意味着您应该设置项目/模块。

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

Answer 5

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

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

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

5 个答案: