在最近的嵌入式项目中，我们使用了以下svn结构：
project
branches
tags
trunk
electronics
software
branches
tags
trunk
如您所见，软件部分有一个嵌套的branches / tags / trunk目录。这对于软件开发者来说非常实用，因为他们可以在那里工作而不必担心其余部分。
然而，对我来说它看起来并不正确，由于分支的多层次，它可能会让人感到困惑，而在层次结构中工作较高的人可能会因为他们必须下载的所有垃圾而感到不便如果他们检查顶部行李箱......
所以我想为下一个项目寻找一个仅限1个主干的存储库，如果开发人员不想要非软件的东西，他们只需要签出project/trunk/software并转移到{{1等等。
您如何看待嵌套中继线？优点和缺点，请！
作为一个附带问题：分支/标签是否应该是主干（或其他分支）的副本，或者是否可以建立主干子目录的分支？
答案 0 :(得分：11)
嵌套中继向我指示一组代码，其生命周期与父代码不同。我会考虑这些概念上独立的项目。另请注意，您的存储库可以有多个顶级项目，这应该减少为每个项目维护一个单独的存储库。当我需要单独的存储库级配置时，我考虑使用单独的存储库：可访问性，传输协议，身份验证/授权（尽管可以在存储库中配置这些存储库）。
main_project
branches
tags
trunk
electronics
software
branches
tags
trunk
然后，您可以将libs文件夹添加到main_project/trunk以包含已编译形式的software，或者可以考虑使用外部SVN引用指向software/trunk在main_project/trunk内。
此外，“main_project”现在可能更好地命名为“electronics”，在这种情况下，您将删除“trunk”下的额外“electronics”文件夹。
答案 1 :(得分：7)
对所有问题的简短回答：否。
我正在设想一个雅培＆amp;科斯特洛“谁是第一次”讨论： “我把它合并到后备箱” “哪个行李箱？” “集成分支的主干” “所以后备箱是最新的？” “哪个行李箱？”
新团队成员将很难适应与之前经验相悖的计划。他们必须搜索内部文档或询问有关非常简单的事情的问题。
许多工具＆amp;如果使用非标准布局，则使用IDE会更加繁重。
更值得关注的是关于分支/标记主干或分支子集的第二个问题。对于颠覆便宜的副本，没有空间或时间来分支/标记子集 - 更重要的是，如果人们在任何地方分支/标记但是顶级，那么你的svn：mergeinfo将变得不那么有用。
答案 2 :(得分：2)
我说绝对不理想 - 很快就会变得非常困惑。鉴于它实际上并没有占用太多/任何存储空间来创建分支/标签，因此没有太多理由最终得到这样的结构。仅在项目层面支持恕我直言。
答案 3 :(得分：-3)
可以接受谁？没有颠覆教皇，每个组织都可以自由地做最适合自己的事情。 SVN的多功能性为您提供了自由是一件好事。