推荐的Subversion存储库布局背后的原因是什么？

使用Subversion的Version Control为(单项目)存储库推荐以下布局(由此问题补充):

/trunk
/tags
  /rel.1 (approximately)
  ...
/branches
  /rel1fixes

与(或许)更注重过程的安排相比,这种安排的相对优点是什么？:

/development
  /current
  /stable
/qa (maybe)
  ...
/production
  /stable
  /Prod.2
  /Prod.1
/vendor
  /Rel.5.1
  /Rel.5.2

请注意,我正在考虑内部部署,而不是构建产品.

免责声明:虽然我是Subversion用户,但我从未在真实的环境中部署它.

建议的布局与建议的布局之间的主要区别在于,建议的布局在某种程度上是自我记录的,即提交事物的位置以及它的行为方式.

例如,在推荐的布局中,很明显所有新开发都提交到trunk,而大多数分支都是由trunk创建的.此外,显而易见的是,您永远不应该将任何内容提交到/ tags中.最后,可以安全地假设分支是真正的分支,可能包含特定于特定分支目的的更改.

根据提议的布局,其中一些不太确定.是/ development/stable从/ current分支？/ development/stable和/ production/stable之间的关系是什么？这些目录中的哪一个是标签,哪些可以实际检查哪些内容？

当然,这种行为可以记录下来,但是通过坚持每个人都使用的公认布局,您可以更轻松地让新员工快速了解其工作方式.

到目前为止,我将尝试总结答案:

简单

"经典"布局(主干/ + 分支/ + 标签/)具有可增长的简单性的优点

Trunk(通常)是主要的开发线

分支机构满足特殊开发需求,例如复杂的子项目和发布后维护

标签是固定的,不可变的标记帖子

这种经典的布局是众所周知的,因此您的开发人员可以更快地加快速度

扩展

如果需要,供应商开发集成到您的开发中的产品(可能需要进行调整)可以作为供应商分支处理(通常一个就够了)

"过程"轴(例如,开发,测试,如果单独完成,QA,如果使用,和生产)可以通过适当的分支或标签约定来处理(取决于在"开发"之外是否需要或允许任何更改).

这些额外的分支集可以通过命名约定来处理,也可以通过标记/或 分支/中的其他目录级别来处理.

见其他问题

分支,标签和主干真正意味着什么？

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

你使用branches-tags-trunk约定吗？

我把它作为社区的答案; 请随时纠正或延长任何不足之处,对此我深表歉意.

您已经描述了存储库组织的两个非常标准的模型:dev-test-prod和trunk-branch.Eric Sink在他的Source Control HOWTO中做了很好的描述.需要注意的一点是,大多数人使用trunk-branch的方式是为每个版本创建一个分支,因为它发布给客户,然后成为维护分支.

我倾向于更喜欢trunk-branch,因为它不需要将每个变化从开发迁移到测试再到生产.只需要迁移需要向后移植到维护分支或从维护分支迁移到主干的错误修改的更改.

然而,有一种情况是dev-test-prod可能更适合在web开发中,其中发布给客户的版本的概念并不存在.在这种情况下,Prod将是服务器上正在运行的任何东西,而代码正在开发和测试中工作并不断迁移到应用程序中,而不是在一个大块中发布.