4

好的，我了解具有单个项目的存储库的主干/标签/分支。

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

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

  • /分支机构/发展/FooModule ？
  • /开发/FooModule ?
  • /沙盒/模块/FooModule ?

有没有人以类似的方式组织颠覆存储库的经验？什么对你有用？

4

6 回答 6

2

这是一个非常有趣的问题，因为正确开始有很多好处（模块化、低耦合......）。无论如何，这就是我将如何开始：

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）。我认为我不是很清楚，但如果我必须以不同的方式解释，请告诉我。

于 2009-10-22T19:15:38.600 回答
0

我不确定我的组织结构是否符合您的需求，但我采用了与主干/标签/分支模型截然不同的方法。查看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

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

  • 主干：这包含适合集成到主线的最新代码修订。所有项目和团队共享一个主干。开发人员只需要检查这个文件夹，他们就拥有了他们需要的一切。

    沙箱：这些是个人开发区域，用于分支您希望与主干分开的长期运行的更改，直到它们准备好合并回主干。

    Staging：这是最后的 QA/UAT 区域。一旦开发被认为是稳定的并准备好进行最终测试，就会在此处复制主干。这可以保护发布免受其他团队提交到主干的开发。当版本处于此阶段时，您不希望其他人的未知提交进入您的代码库。

    Prod：这包含生产版本。每个应用程序在 prod 下都有自己的文件夹，每个版本都有一个以其发布日期命名的文件夹。暂存分支在部署时被复制到这些发布标签，它们代表发布时代码的快照。prod 区域是确切发布内容和时间的历史记录。

于 2009-10-22T18:55:51.640 回答
0

/branches/dev/FooModule如果您真的不想从一开始就将它放在后备箱中，这将是最明智的方法。这就是开发分支的用途（除了通常情况相反，代码从那里的主干复制，然后最终回到主干）。

我肯定会避免像您提供的其他两个示例那样不常见的根路径名。您将在使用 Subversion 的版本控制中找到更多注意事项。

于 2009-10-22T18:57:31.497 回答
0

当我自己处理这种事情时，我倾向于使用一个完全独立的存储库来避免不必要的修订使主存储库变得混乱。

于 2009-10-22T18:59:30.397 回答
0

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

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 取得了一些成功。真正好的一点是，即使对公共库进行重大更改也没有问题如果您使用外部链接到标签，这将在已知工作时冻结公共库。）

于 2009-10-22T19:14:41.300 回答
0

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

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

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

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

很多不必要的工作，这就是为什么我强烈反对在任何大型项目中使用外部组件。

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

于 2009-10-22T19:32:50.423 回答