我熟悉SVN仓库的经典/主干/分支/标签结构，但似乎很少有关于如何在其中构建仓库的建议，尤其是分支机构。
让我们说我的源代码树的顶层是一个名为P的项目。回购的主干部分很简单 - 它只是trunk / P，因为它只有一个主干。
对于标签，我可以根据版本号构建它们，所以我会
tags/v3/v3.2/v3.2.7/P
tags/v3/v3.3/v3.3.1/P
等。等
对于分支机构来说，它更复杂。我通常会有一个最新的稳定v3.2＆＃34;分支，但也可能有3.2的活动功能分支。当然，我还将为trunk提供功能分支，将这些功能与其他版本的功能分支分开似乎是有意义的。因此，回购结构的一个选择是：
branches/3.2/stable/P
branches/3.2/feature1/P
branches/trunk/feature2/P
虽然在分支机构中有一个名为trunk的文件夹似乎有点奇怪。
我想很多人会说你永远不应该做任何足够重要的功能开发需要分支，除非该分支直接来自主干。在这种情况下，唯一的分支将是功能分支，所有标签也将来自主干。不幸的是，我没有那么奢侈，因为我必须为那些（出于某种原因）无法升级到最新版本的客户支持许多旧版本。
答案 0 :(得分：2)
您从recommended setup向后构建了多项目存储库。您应该将主干，标签和分支放在INSIDE项目P中，而不是相反。
我认为将标签粘贴到这样的子标签中是没有意义的。你希望通过这种方式获得什么？您不会将已发布的版本称为3 / 3.1 / 3.1.1。您可以简单地将其称为3.1.1。那么为什么要用前一种方法命名你的标签？
分支更有意义，我可以看到你在哪里，但我认为我仍然建议不制作嵌套文件夹。我认为您应该在一个分支中开发一个功能或错误修复（最好是关闭主干，但这并不是那么重要），然后将其移植到需要使用单个分支的其他分支上合并修订。然后你只需要一个＆＃34; feature1＆＃34;和＆＃34; feature2＆＃34;分支而不是指定它来自何处。历史记录应该告诉您它来自何处，每个分支/主干上的mergeinfo应该告诉您每个分支是否具有该功能。