Question

好的，我理解使用单个项目的存储库的trunk / tags / branches。

现在让我说我有一个主要项目和一些较小的辅助模块/插件/工具/脚本等。在早期阶段有很多重命名，重组等等，其中一些死于早期死亡，因为他们无处可去。在组织非常稳定之前，将特定模块粘贴到主干中是没有意义的。（根据svn设计，复制到主干的位置“便宜”）

在开发过程的早期将小模块（比如“FooModule”）放在哪里是最好的地方？

/ branches / development / FooModule？
/ development / FooModule？
/ sandbox / modules / 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 Framework正在做什么（如果你问我，那就非常好的组织）

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

我建议不要将代码拆分为每个模块的主干/分支，至少在项目开始时：只要你开始分支（而不是在主干上工作），你就无法使用其他的HEADS模块的主干了：您要么必须同时分支所有项目，要么使用特定版本（1.0而不是SNAPSHOT）。我不认为我很清楚但是如果我必须以不同的方式解释它，请告诉我。

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

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

Trunk ：这包含适合的最新代码修订版整合到主线。那里是一个由所有人共享的单一主干项目和团队。仅限开发人员必须签出这个单个文件夹他们拥有所需的一切。

Sandbox ：这些是用于分支的个人开发区域您想要的长时间运行的更改保持与行李箱分开直到他们准备好合并回来后备箱。

暂存：这是最终的QA / UAT区域。主干在这里被复制一次发展被认为是稳定的并准备好进行最终测试。这个保护发布免受开发被其他队伍提交到后备箱。当一个版本处于这个阶段时，你不想要未知的提交别人输入你的代码库。

产品：这包含生产版本。每个应用程序都有它 prod和each下的自己的文件夹 release有一个以。之后命名的文件夹发布日期。分期分支被复制到这些版本部署时的标签和它们表示代码的快照发布的时间。刺激区域是究竟是什么的历史记录发布时和。

Answer 3

/branches/dev/FooModule如果你真的不想从恕我直言中开始使用它，那将是最明智的方法。这就是开发分支的用途（除了通常是另一种方式，代码从那里的主干复制，然后最终返回到主干）。

我绝对会避免像你给出的另外两个例子那样不常见的根路径名。您可以在Version Control with Subversion中找到进一步的注意事项。

Answer 4

当我自己接近这种事情时，我倾向于使用一个完全独立的存储库来保存主存储库的混乱，并进行不必要的修改。

Answer 5

我喜欢为每个应用程序提供主干，标签，分支。在这样的设计中，你可以为沙盒做任何你想做的事。

app1/
    trunk/
    tags/
    branches/
app2/
    trunk/
    tags/
    branches/
sandbox/
    trunk/
    tags/
    sure_you_could_keep_the_parallelism_up_here_but_is_there_really_any_need/

人们会反复讨论这样做的优点和缺点，或者根级别的主干，标签，分支方式，但这种方式的一个强大优势是合并和结账不那么痛苦。

（很多人忽略了这种结构，因为他们看到他们的项目在应用程序之间共享代码。当需要这样的代码共享时，我们使用svn：externals取得了一些成功。真正好的是，即使对公共库进行更改也会如果你使用externals链接到标签就没问题了，这会在知道工作时冻结公共库。）

Answer 6

我无法编辑David的帖子，但我想提及svn:externals的内容：从发布的角度来看，它们非常危险（imo）。这是噩梦般的场景：

让我们假设你svn:externals你的应用程序中的一些模块代码;为了它，让我们假设模块的Subversion版本是1000。您创建一个分支，发布并将其发送给客户。

时间流逝，几个月/年后客户要求您解决应用程序中的问题。您检查分支并启动svn updating项目。不幸的是，链接模块已经发生了很大变化，现在版本为23456.现在该应用程序甚至不再编译。

当然，您必须这样做，因此在分支时将svm:externals更改为指向确切的版本（1000）。如果你必须更改模块的代码，那么现在必须指向在修订版1000中为模块创建的分支的头部。

许多不必要的工作，这就是为什么我强烈反对任何大型项目使用外部因素。

如果您对svn:externals有过良好的经验，我会全力以赴。

svn：模块组织在开发过程的早期阶段

6 个答案: