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

Question

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

project
    branches
    tags
    trunk
        electronics
        software
            branches
            tags
            trunk

如您所见,软件部分有一个嵌套的branches/tags/trunk目录.这对软件开发者来说非常实用,因为他们可以在那里工作而不用担心其余的问题.

然而,它看起来并不合适,因为分支的多层次可能会让人感到困惑,而在层次结构中工作较高的人可能会因为他们检查顶部主干而必须下载所有垃圾而感到不便...

所以我想为下一个项目寻找一个仅限1个主干的存储库,如果开发人员不想要非软件的东西,他们可以只签出project/trunk/software并分支到project/branches/br-1234/software等等.

您如何看待嵌套中继线？优点和缺点请!

作为一个附带问题:分支/标签是否应该是主干(或其他分支)的副本,或者是否可以建立主干子目录的分支？

Answer 1

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

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"文件夹.

Answer 2

对你所有问题的简短回答:没有.

我想象一个雅培和科斯特洛"谁在第一次"的讨论:"我把它合并到了行李箱""哪个行李箱？" "集成分支的主干""所以主干是最新的？" "哪个行李箱？"

新的团队成员将难以适应与其先前经验相矛盾的计划.他们必须搜索内部文档或询问有关非常简单的问题.

如果使用非标准布局,许多工具和IDE使用起来会更加繁重.

更值得关注的是关于分支/标记主干或分支子集的第二个问题.对于颠覆便宜的副本,没有空间或时间来获取分支/标记子集 - 更重要的是,如果人们在任何地方分支/标记但是顶级,则svn:mergeinfo将变得不那么有用.