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

我们应该吗：

• 将发布分支和项目分支混合在一起？
• 创建发布文件夹？如果是这样，是否有比发行版更好的名称？
• 创建一个项目文件夹并将当前分支移动到那里？如果是这样，有没有比项目更好的名字？我在其他存储库中看到过" sandbox"和" spike"。
• 还有其他东西吗？

解决方案

回答

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

所以

trunk
     fooapp
         stuff...
     barapp
         stuff...
tags
     fooapp
         1.0.0
         1.0.1
     barapp 
         1.0.0

回答

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

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

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

卡尔

回答

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

在这种情况下，我们需要标记例如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

回答

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

顺便说一句：这是一个好主意，很少有存储库，而不是许多存储库，因为通常这样可以更好地保存更改历史记录(如果在存储库之间移动文件，除非我们采取特殊且有些复杂的操作，否则更改历史记录将消失)。在大多数设置中，应该只有两个存储库：主存储库和供沙盒用户试用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版本。代码移入生产环境后，release分支将保持打开状态以提供支持，安全性和错误修复，并标记次要版本并将其发布。

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

将会给系统带来长时间破坏的重大，长期或者大规模更改也有各自的分支，但这些更改的生存期短得多，并且其中没有"释放"一词。

回答

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

并不是我们要找的答案，但是我认为，一旦我们对结构进行了排序，并且已经有了很多不错的建议，那么下一个挑战就是使团队保持了解并保持跟踪。