我们有标准的 Subversion 主干/分支/标签布局。我们有几个用于中长期项目的分支，但到目前为止还没有一个发布版本。这正在快速接近。
我们应该：
【问题讨论】：
标签： svn tags branch release release-management
我推荐以下布局，原因有二： - 与给定项目相关的所有内容都在树的同一部分；使 人们更容易掌握 - 这样权限处理可能会更容易
顺便说一句：使用少量存储库而不是很多存储库是个好主意，因为这样通常可以更好地保留更改历史记录（如果您在存储库之间移动文件，更改历史记录就会消失，除非您采取特殊且有些复杂的操作） .在大多数设置中，应该只有两个存储库：主存储库和供人们试验 Subversion 的沙盒存储库。
project1
trunk
branches
1.0
1.1
joes-experimental-feature-branch
tags
1.0.0
1.0.1
1.0.2
project2
trunk
branches
1.0
1.1
tags
1.0.0
1.0.1
1.0.2
【讨论】：
从其他人所说的开始，我们有一个相当严格的结构，从 alpha 到 beta 再到生产。字母代码是躯干的头部，并且在大多数情况下保持稳定，但并非总是如此。当我们准备好发布时，我们会创建一个“发布分支”来有效地冻结该代码，并且只对其应用错误修复。 （这些被移植回主干）。此外，标签会定期作为候选发布，这些是 beta 版本。一旦代码进入生产阶段，发布分支就会保持开放以提供支持、安全性和错误修复，并标记次要版本并从中发布。
一旦某个特定版本不再受支持，我们就会关闭该分支。这使我们能够清楚地区分哪些错误是针对哪些版本修复的，然后它们会被移到主干中。
会在很长一段时间内破坏系统的重大、长期或大规模更改也有自己的分支，但这些更改的生命周期要短得多，并且其中没有“发布”一词。
【讨论】：
当我们想为 3.1 版的发布做准备时，我们创建一个分支/3.1-Release 分支，并在我们认为合适的时候合并来自主干的各个提交（我们的发布分支通常只接收最关键的修复来自主开发分支）。
通常，此发布分支会经历 alpha 和 beta 测试阶段，并在下一个版本即将发布时关闭。
您还可以在按下 DVD 或上传下载包后将发布分支标记为已发布，这样您可以在以后需要时轻松地从完全相同的版本重新构建。
卡尔
【讨论】：
我们已经使用标签，虽然我们有一个大项目的结构，而不是你概述的许多小项目。
在这种情况下，我们需要标记，例如1.0.0，但也有分支，例如1.0。我关心的是混合项目分支和发布分支，例如
branches
this-project
that-project
the-other-project
1.0
1.1
1.2
tags
1.0.0
1.0.1
1.1.0
1.2.0
1.2.1
【讨论】：
在我工作的地方，我们有“临时分支”和“发布分支”目录，而不仅仅是“分支”。因此，在您的情况下，项目分支将位于临时分支下，而发布分支（当然是在发布时创建的）将位于发布分支下。
【讨论】：
另一个重要的考虑因素是何时分支以及何时关闭分支——这取决于您的发布计划以及测试和发布需要多长时间。根据我的经验，这需要进行大量管理，以确保团队中的每个人都知道计划是什么以及何时使用什么，所有这些都通过在发布 wiki 中记录所有这些得到了帮助。
不是您正在寻找的答案，但我认为，一旦您对结构进行了排序，并且您已经有很多好的建议，下一个挑战就是让团队了解最新情况并保持在正轨上。
【讨论】：
Releases 与标签相同...您的后备箱中有多个项目吗？在这种情况下，我会在标签内复制相同的文件夹
所以
trunk
fooapp
stuff...
barapp
stuff...
tags
fooapp
1.0.0
1.0.1
barapp
1.0.0
【讨论】：