我应该为SVN中的发布分支创建文件夹吗？

我想通过将发布分支和功能分支放在发布文件夹中来分离它们。我知道svn的最佳实践是让您的根文件夹结构如下：

\trunk
\branches
    \feature-a
    \feature-b
    \...
\tags
    \1.0 
    \...

svn copy http://project/trunk http://project/releases/release-b

我对svn的理解是，trunk/branchs/tags文件夹对svn没有特殊意义。通过将发布文件夹添加到项目根目录并将所有发布分支放在该文件夹中，我会遇到任何问题吗

\trunk
\branches
    \feature-a
    \feature-b
    \...
\releases
    \release-a
    \...
\tags
    \1.0 
    \...

创建新的发布分支如下所示：

\trunk
\branches
    \feature-a
    \feature-b
    \...
\tags
    \1.0 
    \...

svn copy http://project/trunk http://project/releases/release-b

---

如何构建存储库取决于您自己。如果您需要分支类别/文件夹/等等，就这样吧。一旦决定了想要/需要的结构，就可以创建一个流程来处理它。底层的Subversion命令当然不会改变。

它可以很好地工作，尽管我个人不太喜欢它。“发布”听起来像是一种标签（固定点），但实际上它是一种分支（朝着发布方向发展）。

您的工作流程会是什么样子？此时，要么标签目录变得不相关，您还可以将“标签”重命名为“发布”，要么主干变得不相关，因为所有开发都在发布或功能分支中进行

---

我的建议是将“tags”文件夹简单地重命名为“releases”。

我这样做，还有其他类似的事情。相同的工作流有不同的路径。解决的问题是混乱。例如，当您有正在标记的构建和正在进行的任务分支时，文件夹可能会有点混乱。我通常在本地保留一个小小的svn沙箱，这样我就可以尝试工作流程，以确保我没有弄糟任何事情

在一些项目中，我使用一个单独的发布库，并使用一个svn:external作为交接。从这个意义上讲，这更像是向另一个群体“传递”信息。开发工作流和运营推出工作流可能有所不同。这将两者分开

---

关于我现在正在设置的项目——可能会称之为维护或支持，只是为了增加趣味性。：）

嗯，我可以看到一个发布分支，您可以在其中分支一个发布来进行bug修复开发或其他工作。当然，这句话可能有点让人困惑@杰里米，我想你把我弄倒了。是的，发布分支应该像一个分支，您可以在其中修复bug和其他东西；当您执行实际发布时，您将从分支生成一个标记。我只是说，如果我在存储库中看到一个名为“releases”的目录，我希望它包含那些发布标签，而不是发布分支。不过，也许这只是我的问题。我们一致认为这些措辞令人困惑/含糊不清。发布分支是在发布工作完成时创建的长期分支。因此，发布分支是一种固定点，尽管一些工作将在其中完成。我们将从发布分支进行标记。功能分支很少使用，因为大部分工作都是在主干中完成的。但是，偶尔会有一个大的特征从管道上下来，这就需要一个分支。