我们在SVN中有我们的项目，我正在努力提高发布过程中的自动化水平。
历史上，我们在主干上开发，然后在发布时进行标记，这需要手动（虽然是次要的）做实际标签和工作。然后在下一个标记之前增加源文件中的版本号。
我们现在正在使用Jenkins，我已经将我们的项目配置为嵌入SVN版本＆amp;詹金斯在最终的EXE＆amp; DLL等我试图沿着使用发布分支而不是标签的路线走下去。因此，在完美的世界中，发布分支永远不会更新，但我们将允许自己应用小错误修复。
使用Jenkins＆amp; SVN，在我看来，传统标签的价值已经降低了，所以我目前的想法是在我们的发布过程中根本不需要手动标签。好像每个提交都标有SVN版本号。
所以我的问题是我应该把这些发布分支放在哪里：
branches - 然后他们只是变得杂乱无章
发展分支机构等。tags中 - 因为它们是不可变的
美好的一天，但它违反惯例？困惑于新的
员工？releases中 - 因为它是一个新目录
惯例，它会提醒人们稍微不符合标准的使用。在与trunk相同的级别添加非标准目录会让我对其他工具感到悲伤吗？乌龟等。
答案 0 :(得分：0)
- 在分支机构 - 但随后它们只是变得混乱了开发分支等。
不，我不会这样做。特别是如果你知道你最终会有很多这样的东西，我会从开发分支中分离出来（也是为了避免新用户的混淆）。
- 在标签中 - 因为它们在美好的一天会变成一成不变的，但它会违反常规吗？对新员工感到困惑？
这是恕我直言的第二个最佳选择。
- 在新目录中发布 - 因为它是一个新的约定，它会提醒人们稍微不符合标准的使用。
这就是我要放的地方。为什么不为每个应用的错误修复创建一个新标记（点发布，例如2.5.1）？无论如何，新员工必须在开发团队中学习结构/最佳实践/代码约定，因此说“releases/适用于发行版，包括小修补程序”，这样做非常简单。
在与trunk相同的级别添加非标准目录会让我对其他工具感到悲伤吗？
不是我知道的。