Question

我们有标准的Subversion trunk / branches / tags布局。我们有几个分支机构用于中期和长期项目，但到目前为止还没有一个发布。这快到了。

我们应该：

将发布分支和项目分支混合在一起？
创建发布文件夹？如果是这样，有没有比发布更好的名字？
创建一个项目文件夹并将当前分支移动到那里？如果是这样，有没有比项目更好的名字？我在其他存储库中看到过“沙盒”和“尖峰”。
还有其他什么吗？

Answer 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

Answer 2

从其他人的说法中脱颖而出，我们有一个相当严格的从alpha，beta到生产的进展结构。 alpha代码是主干的头部，并且在大多数情况下保持稳定，但并非总是如此。当我们准备发布时，我们创建了一个“发布分支”，可以有效地冻结该代码，并且只对其应用错误修复。（这些被移回后备箱）。此外，标签定期作为候选版本，这些是beta版本。一旦代码转移到生产环境，发布分支将保持打开状态以获得支持，安全性和错误修复，并对次要版本进行标记并从中释放。

一旦不再支持特定版本，我们就会关闭分支。这使我们可以清楚地区分哪些错误被修复，然后将它们移入主干。

长时间破坏系统的重大，长期或大规模的变化也会有自己的分支，但这些变化的寿命要短得多，而且没有“释放”这个词。

Answer 3

当我们想要准备3.1版本的发布时，我们创建了一个branches / 3.1-Release分支，并在我们认为合适时合并来自trunk的各个提交（我们的发布分支通常只接收最关键的修复来自主要发展部门。）

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

在您按下DVD或上传下载包后，您还可以执行的操作是将发布分支标记为已发布，因此如果您以后需要，可以轻松地从完全相同的版本重建。

卡尔

Answer 4

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

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

Answer 5

在我工作的地方，我们有“临时分支”和“发布分支”目录，而不仅仅是“分支”。因此，在您的情况下，项目分支将进入临时分支，并且发布分支（当然，在发布时创建）将在发布分支下进行。

Answer 6

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

不是你想要的答案，但我认为一旦你对结构进行了分类，你已经有了很多好的建议，下一个挑战就是让团队了解情况并走上正轨。

Answer 7

发布与标签相同......您的主干内有多个项目吗？在这种情况下，我会在标签

中复制相同的文件夹

所以

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

Subversion中版本和项目的良好存储库布局是什么？

7 个答案: