关于svn：对于Subversion中的版本和项目，什么是好的存储库布局？

我们有标准的Subversion中继/分支/标签布局。 我们有几个分支机构用于中长期项目，但到目前为止还没有一个分支机构。 这正在迅速接近。

我们应该吗：

我推荐以下布局，有两个原因：
-与给定项目相关的所有内容都在树的同一部分内；使
人们更容易掌握
-这样可以更轻松地处理权限

顺便说一句：这是一个好主意，很少有存储库，而不是许多存储库，因为通常这样可以更好地保存更改历史记录(如果在存储库之间移动文件，除非采取特殊且有些复杂的操作，否则更改历史记录就消失了)。在大多数设置中，应该只有两个存储库：主存储库和一个供人们试用Subversion的沙箱存储库。

从别人所说的中脱颖而出，我们有一个相当僵化的结构，从alpha过渡到beta，再到生产。阿尔法代码无论是干什么的头，在大多数情况下都保持稳定，但并非总是如此。准备发布时，我们将创建一个"发布分支"，该分支可以有效冻结该代码，并且仅对其进行错误修复。 (这些被移植回后备箱)。另外，标签会定期发布，以作为候选版本，这些是beta版本。代码移入生产环境后，release分支将保持打开状态以提供支持，安全性和错误修复，并标记次要版本并将其发布。

一旦不再支持特定版本，我们将关闭分支。这使我们能够清楚地区分哪些错误针对哪些发行版进行了修复，然后将它们转移到主干中。

也将给它们自己的分支指定将在很长一段时间内破坏系统的重大，长期或大规模的更改，但是这些更改的寿命短得多，并且其中没有"释放"一词。

另一个重要的考虑因素是何时分支以及何时关闭分支-这取决于您的发布时间表，还取决于您测试和发布需要多长时间。以我的经验，这需要大量管理，以确保团队中的每个人都知道计划是什么，何时使用什么，所有这些都通过在发布Wiki中记录所有内容而得到了帮助。

并不是您要找的答案，但是我认为，一旦您对结构进行了排序，并且已经有了很多不错的建议，那么下一个挑战就是使团队保持知情和步入正轨。

在我工作的地方，我们有"临时分支"和"发行分支"目录，而不仅仅是"分支"。因此，在您的情况下，项目分支将位于临时分支下，而发布分支(当然是在发布时创建的)将在发布分支下。

尽管我们具有一个大项目结构而不是您概述的许多小项目，但我们已经使用了标签。

在这种情况下，我们需要标记例如1.0.0，也可以是分支，例如1.0。我的担心是将项目分支和发布分支混合在一起，例如

当我们想为3.1版发布做准备时，我们创建一个branch / 3.1-Release分支，并在我们认为合适的情况下合并来自主干的单个提交(我们的发行分支通常仅从主分支接收最关键的修复程序)开发分支)。

通常，此发行分支贯穿alpha和beta测试阶段，并在下一个发行版本达到阈值时关闭。

一旦按下DVD或上传了下载包，您还可以将release分支标记为已发布，因此，如果以后需要，可以轻松地从完全相同的修订版本进行重建。

卡尔

发布与标签相同...您的行李箱中有多个项目吗？在这种情况下，我将在标签内复制相同的文件夹

所以