svn：开发过程早期的模块组织_Svn_Repository Design

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

svn

svn：开发过程早期的模块组织,svn,repository-design,Svn,Repository Design,好的，我理解带有单个项目的存储库的主干/标记/分支现在让我们假设我有一个主项目和一些较小的辅助模块/插件/工具/脚本等。在早期阶段，有很多重命名、重组等，其中一些人因为无处可去而早逝。在组织相当稳定之前，将特定模块插入主干对我来说没有意义。（在这一点上，根据svn设计，复制到主干是“便宜的”）在开发过程的早期，哪里是放置小型模块（比如“FooModule”）的最佳位置 /分支/开发/开发模块 /开发/开发模块 /沙箱/模块/食物模块有没有人有过以类似方式组织subversion存储库的

好的，我理解带有单个项目的存储库的主干/标记/分支

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

在开发过程的早期，哪里是放置小型模块（比如“FooModule”）的最佳位置

/分支/开发/开发模块
/开发/开发模块
/沙箱/模块/食物模块

有没有人有过以类似方式组织subversion存储库的经验？什么对你有效？

我不确定我的组织结构是否适合你的需要，但我采取了与主干/标签/分支模式截然不同的方法。看一看细节

我们的结构如下：

/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：这保存了适用于融入主线。那里所有人共享一个主干吗项目和团队。仅限开发人员必须签出这个文件夹他们拥有他们所需要的一切
沙盒：这些是用于分支的个人发展区域您希望进行的长时间运行的更改与行李箱分开，直到它们已准备好合并回箱子
分段：这是最终的QA/UAT区域。主干在这里复制一次发展被认为是稳定的并准备进行最终测试。这保护版本不受开发影响由其他团队提交给后备箱。当发布处于此阶段时，您可以不希望来自的未知提交其他人正在输入您的代码库
Prod：包含生产版本。每个应用程序都有自己的在prod下拥有自己的文件夹，每个 release有一个以发布日期。舞台分支被复制到这些版本中部署时的标签，它们表示位于的代码的快照释放的时间。产品区是究竟是什么的历史记录什么时候被释放的

如果您真的不想从一开始就把它放在主干中，那么

/branchs/dev/FooModule

将是最明智的方法。这就是开发分支的用途（除了通常情况下，相反，代码从主干复制，然后最终返回主干）

我绝对不会像您给出的其他两个示例那样使用不常见的根路径名。您将在中找到进一步的考虑。

当我自己处理这类事情时，我倾向于使用一个完全独立的存储库，以避免主存储库中出现不必要的修改。

我非常喜欢为每个应用程序设置主干、标记和分支。在这样的设计中，您可以为沙盒做任何您想要的事情

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链接到标记，即使是对公共库的中断更改也不会有问题，这将冻结co这是一个非常有趣的问题，因为从右开始有很多好处（模块化、低耦合…）。无论如何，我会这样开始：

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框架正在做什么（如果您问我的话，这是一个非常好的组织）

我建议不要将代码拆分为每个模块的主干/分支，至少在项目开始时是这样：一旦开始分支（并且不在主干上工作），就不能再使用其他模块主干的头：要么必须同时分支所有项目，要么使用特定版本（1.0，而不是快照）。我不认为我很清楚，但如果我必须以不同的方式解释，请告诉我。

我无法编辑David的帖子，但我想提及一些关于

svn:externals的内容：从发布角度来看，它们非常危险（imo）。以下是噩梦场景：
让我们假设您svn:externals
应用程序中的一些模块代码；为了实现这一点，让我们假设模块的Subversion版本为1000。您创建一个分支，发布一个版本，并将其发送给客户
随着时间的推移，几个月/年后，客户要求您修复应用程序中的一个问题。您检查分支并开始更新项目。不幸的是，链接模块发生了很大变化，现在版本为23456。现在应用程序甚至不再编译
当然，您必须这样做，即更改svm:externals
以指向分支时的确切版本（1000）。如果您必须更改模块的代码，那么您现在必须指向在版本1000处为模块创建的分支的头部
很多不必要的工作，这就是为什么我强烈反对使用
http://svn/application1/trunk
http://svn/application2/trunk
http://svn/framework/trunk/module1
http://svn/framework/trunk/module2