svn - 嵌套的主干/分支/标签是否可以接受？

Question

在最近的一个嵌入式项目中，我们使用了如下的svn结构:

project
    branches
    tags
    trunk
        electronics
        software
            branches
            tags
            trunk

如您所见，软件部分有一个嵌套的分支/标签/主干目录。这对于软件开发人员来说非常实用，因为他们可以在那里工作而不必担心其余的事情。

但是，它对我来说看起来不正确，由于分支的多个级别，它可能会令人困惑，并且在层次结构中工作的更高级别的人可能会对他们必须下载的所有垃圾文件感到不便，如果他们检查顶部的主干...

所以我正在考虑为下一个项目选择一个只有 1 个主干的存储库，如果开发人员不想要非软件的东西，他们可以 checkout project/trunk/software并分支到 project/branches/br-1234/software ， ETC。

您如何看待嵌套树干？请利弊!

作为一个附带问题:分支/标签是否应该始终是主干(或另一个分支)的副本，或者创建主干子目录的分支是否可以接受？

Answer 1

嵌套的树干向我表明了一个生命周期与父代码不同的代码集合。我会考虑这些概念上独立的项目。另外，请注意您的存储库可以有多个顶级项目，这应该减少为每个项目维护单独的存储库。当我需要单独的存储库级别配置时，我会考虑使用单独的存储库:可访问性、传输协议(protocol)、身份验证/授权(尽管这些可以在存储库中配置)。

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”文件夹。