svn:开发过程早期的模块组织

Question

好的，我理解一个项目的存储库的主干/标记/分支。

现在，假设我有一个主要项目和一些较小的辅助模块/插件/工具/脚本等等。在早期阶段，有很多重命名、重组等，其中一些是早逝的，因为它们无处可去。在组织相当稳定之前，将一个特定的模块插入主干是没有意义的。(根据svn的设计，复制到主干是“便宜的”)

在开发过程的早期放置小模块(如"FooModule")的最佳位置是哪里？

• /分支/开发/FooModule？
• /开发/FooModule？
• /沙箱/模块/FooModule？

是否有人有类似的方式组织subversion存储库的经验？什么对你有用？

Answer 1

这是一个非常有趣的问题，因为从右开始有很多好处(模块化、低耦合.)。不管怎么说，我就是这样开始的：

1)把所有东西放进箱子里：

http://svn/application/trunk/application

2)如果可以的话，尽早开始将代码拆分成模块

http://svn/application/trunk/application1
                             module1
                             module2

3)如果一个模块是稳定的，那么将它向上移动到它自己的存储库中：

http://svn/module1/trunk

4)最后，当您有几个稳定的模块和应用程序时，您可能会以

http://svn/application1/trunk
http://svn/application2/trunk
http://svn/module1/trunk
http://svn/module2/trunk

每个应用程序/模块都有自己的发布周期。

或者，您可以看看Spring框架正在做什么(如果您问我的话，组织非常好)

http://svn/application1/trunk
http://svn/application2/trunk
http://svn/framework/trunk/module1
http://svn/framework/trunk/module2

我建议不要为每个模块将代码分割成主干/分支，至少在项目开始时是这样的:一旦您开始分支(而不是在主干上工作)，您就不能再使用其他模块的主干了:您要么必须同时分支所有项目，要么使用特定版本(1.0而不是快照)。我想我不是很清楚，但是如果我需要用不同的方式来解释的话，请告诉我。

Answer 2

我不确定我的组织结构是否符合您的需要，但我采取了与主干/标记/分支模型非常不同的方法。有关详细信息，请查看http://www.mattwrock.com/post/2009/10/10/The-Perfect-Build-Pard-2-Version-Control.aspx。

这是我们的结构：

/prod
/prod/app1/20090903
/prod/app1/20090917
/prod/app2/20090903
/sandbox
/sandbox/users/mwrock
/staging
/staging/app1
/staging/app2
/trunk
/trunk/libraries
/trunk/desktop
/trunk/docs
/trunk/services
/trunk/sql
/trunk/testing
/trunk/thirdparty
/trunk/web

这里我们有以下根文件夹：

• 主干：这保存了适合集成到主线的最新代码修订版。所有项目和团队都共享一个主干。开发人员只需签出这个文件夹，他们就有了所需的一切。 Sandbox：这些个人开发区域用于分支长期运行的更改，您希望将这些更改与主干保持分离，直到它们准备好合并回主干。 阶段：这是最终的QA/UAT区域。一旦开发被认为是稳定的，并为最终测试做好准备，主干就会在这里复制。这保护了其他团队从开发到主干的发布。当发布处于此阶段时，您不希望来自其他人的未知提交进入您的代码库。 Prod：这包含生产版本。每个应用程序在prod下都有自己的文件夹，每个版本都有一个以其发布日期命名的文件夹。在部署时，暂存分支被复制到这些发行标记中，它们表示发布时代码的快照。prod地区是一个历史记录，确切地说是什么被释放和何时释放。

Answer 3

如果您真的不希望从IMHO一开始就将它放在主干中，那么/branches/dev/FooModule将是最明智的方法。这就是开发分支的目的(除了通常情况下，代码是从主干复制的，然后最终返回到主干)。

我肯定会避免不常见的根路径名，比如您给出的另外两个示例。您将在带有Subversion的版本控制中找到更多的注意事项。