2008-09-25 79 views
7

我有一个Subversion版本库,其中包含一个数字以便与各种应用程序,配置文件,DLL等对应的子文件夹(我将它们称为“模块” )组成我的项目。现在我们开始“分支”到几个相关的项目中。也就是说,每个高级项目都将使用多个模块,可能会略微修改项目之间的差异。项目数量比模块数量(〜20)要小(〜5)SVN项目组织:每个模块或每个项目

现在我试图弄清楚如何组织回购。将每个项目的子子文件夹保留在逐个模块的基础上保留顶级子文件夹是否有意义?还是应该顶层是对每一个项目,具有其自身的模块的子文件夹每个项目:

回购:

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 

回答

0

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

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

1

我会组织项目THEN模块(你的第二个例子)。主要原因是因为在管理项目方面存在更多的开销,至少对我而言,管理模块的成本更高。

每个不同的项目需要自己构建脚本设置,属性文件等,它是一个更容易跟踪的5个副本保存在电脑比20

1

我更喜欢第一个1。

尽管每个存储库都需要额外的努力来维护,但我喜欢我的修订版本号以便对项目有意义。

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

+0

+1这些内部版本号在连续编译环境中很有用。 – JMP 2010-10-14 00:08:10

3

看起来最好是由项目组织在顶层,因为您要检出整个分支并为项目提供工作副本。如果您按模块进行组织,则必须执行多个签出(每个模块使用一个)才能将项目建立到可用的位置。

这可能是有意义的保持这两个项目和模块分开,例如:

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

如果您使用的是与SVN externals和/或vendor branches组合,可以支持不同的分支机构为您的项目需要不同模块版本,但是当项目发生共享相同版本的模块时仍然受益于具有单个模块源。

0

我倾向于按项目组织,但现在总是如此。如果你有访问控制方面的代码,那么组织到最小化权限 - 管理;这也可能导致存储库的每个团队组织。顺便说一下:您似乎期望在一个大型资源库中工作 - 我认为这很聪明,因为这意味着更好的历史处理:只要您在资源库之间移动内容,就会丢失历史记录。换句话说,我不同意Ben Scheirman对此的建议。