偏离 SVN 中的主干/标签/分支结构可以吗？

Question

我们在 SVN 中有我们的项目，我正在努力提高我们发布过程中的自动化水平。

从历史上看，我们在主干上开发，然后在发布时进行标记，这需要手动（尽管是次要的）工作来执行实际标记，然后在下一个标记之前增加源文件中的版本号。

我们现在正在使用 Jenkins，并且我已经将我们的项目配置为在生成的 EXE 和 DLL 等中嵌入 SVN 修订版和 Jenkins 内部版本号。我正在尝试使用发布分支而不是标签的路线。因此，在一个完美的世界中，发布分支永远不会更新，但我们将允许自己应用小错误修复。

在使用 Jenkins 和 SVN 时，在我看来，传统标签的价值已经降低，所以我目前的想法是在我们的发布过程中根本不需要手动标签。就好像每次提交都标有 SVN 修订号。

所以我的问题是我应该把这些发布分支放在哪里：

1. 在branches - 但是他们只是变得杂乱无章 开发分支等。
2. 在tags - 因为它们在 美好的一天，但它打破了惯例？对新人感到困惑 员工？
3. 在一个新目录中releases - 因为它是一个新目录 按照惯例，它会提醒人们注意其稍微不标准的使用。

在与主干相同的级别添加非标准目录是否会导致我对其他工具感到不满？乌龟等

Answer 1

1. 在分支中 - 但是它们只是被开发分支等弄得一团糟。

不，我不会这样做。尤其是如果你知道你最终会拥有相当多的版本，我会将版本与开发分支分开（也是为了避免给新用户造成混淆）。

1. 在标签中 - 因为它们在美好的一天是不可变的，但它违反了惯例？让新员工感到困惑？

恕我直言，这是第二好的选择。

1. 在新目录中发布 - 因为它是一个新约定，它会提醒人们注意其稍微不标准的使用。

我会把它们放在那里。为什么不为每个应用的错误修复创建一个新标签（一个点发布，例如2.5.1）？无论如何，新员工必须学习开发团队中的结构/最佳实践/代码约定，因此说“releases/ 用于发布，包括小修复”就很简单了。

添加与主干相同级别的非标准目录是否会导致我对其他工具感到不快？

我不知道。