Svn 嵌套的主干/分支/标记是否可以接受？

在最近的嵌入式项目中，我们使用了以下svn结构：

project
    branches
    tags
    trunk
        electronics
        software
            branches
            tags
            trunk

如您所见，软件部件有一个嵌套的branchs/tags/trunk目录。这对于软件开发人员来说非常实用，因为他们可以在那里工作，而不用担心其他的问题

然而，在我看来这并不正确，它可能会令人困惑，因为有多个级别的分支，在层次结构中工作的更高级别的人可能会因为签出顶级主干时必须下载的所有垃圾而感到不便

因此，我正在考虑为下一个项目建立一个只支持1个主干的存储库，如果开发人员不需要非软件的东西，他们可以签出

project/trunk/software

，然后分支到

project/branchs/br-1234/software

，等等

你觉得嵌套的树干怎么样？赞成与反对请

---

作为一个附带问题：分支/标记应该始终是主干（或另一个分支）的副本，还是可以将主干的子目录作为一个分支？

我认为绝对不理想-很快就会变得非常混乱。鉴于创建分支/标记实际上不需要占用太多/任何存储空间，因此没有太多理由使用这样的结构。项目层面的分支机构仅限于IMHO.

可接受的谁？没有颠覆教皇，每个组织都可以自由地做最适合自己的事情。SVN的多功能性给了您自由，这是一件好事。

嵌套的主干向我指出了一组代码，它们的生命周期与父代码不同。我会考虑这些概念上分开的项目。另外，请注意，您的存储库可以有多个顶级项目，这将减少为每个项目维护单独的存储库的工作量。当需要单独的库级配置时，我考虑使用单独的存储库：可访问性、传输协议、身份验证/授权（虽然这些可以在存储库中配置）。

>您可以将<代码> LIBS<代码>文件夹添加到<代码> MIN项目/主干< /代码>，以包含一个编译的格式<代码>软件< /代码>，或者可以考虑使用一个外部的VSN引用来指向<代码>软件/主干< /代码>。

---

另外，“main_project”现在可能更好地命名为“electronics”，在这种情况下，您可以删除“trunk”下额外的“electronics”文件夹

我正在设想一场雅培和科斯特洛“谁是第一”的讨论： “我把它和后备箱合并了” “哪个箱子？” “集成分支的主干” “那么行李箱是最新的？” “哪个箱子？”

新的团队成员将很难适应与其先前经验相矛盾的计划。他们必须搜索内部文档，或者询问一些应该非常简单的问题

如果使用非标准布局，许多工具和IDE的工作将更加繁重

---

更值得关注的是关于主干或分支的分支/标记子集的第二个问题。使用subversions便宜的拷贝，分支/标记子集的空间和时间没有任何好处-更重要的是，如果人们在顶级以外的任何地方分支/标记，您的svn:mergeinfo将变得不那么有用。

也许“可接受”不是正确的词。。。我正在努力为这类大型项目寻找最好的解决方案，这些项目不仅仅涉及软件。欢迎提出更好的标题和文字建议。你错了。艾伦·金斯伯格（Allen Ginsberg）是颠覆的教宗：我认为人们默认海报暗示了类似于“实用程序员可以接受”的东西。这种svn方法是一种反模式，除了最小的单用户回购协议。它会在实际合适的时候惩罚开发人员进行分支和标记。因为所有东西都有效地存在于最顶端的主干中，“分支”通常意味着新的回购。在这样的配置下生活，即使是在一个相当小的产品上，特别是在有多个提交者的情况下，也是痛苦的。海报正确地怀疑了这一点，这里的开发人员正确地验证了海报的原始假设。我希望将外部指向一个标签或主干的特定修订，但除此之外，很好。

main_project
    branches
    tags
    trunk
        electronics
software
    branches
    tags
    trunk