带有Subversion的版本控制建议(单个项目)存储库采用以下布局(此问题进行补充)：

/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用户，但我从未在实际的实时环境中进行部署。

解决方案

每当我们处理真实的实时环境时，我们都希望开发人员能够尽可能轻松地了解存储库。做到这一点的一种好方法是遵循推荐的Subversion标准布局。

推荐的布局和建议的布局之间的主要区别在于，建议的布局在某种程度上可以自动记录关于在何处提交东西以及它的行为方式。

例如，在推荐的布局中，很明显所有新开发都提交给了主干，并且大多数分支都是由主干制成的。同样，很明显，我们绝对不要将任何东西提交到/ tags中。最后，可以安全地假设分支是真正的分支，其中可能包含特定于该特定分支目的的更改。

使用建议的布局，其中某些事情并不确定。 / development / stable是从/ current分支出来的吗？ / development / stable和/ production / stable之间有什么关系？这些目录中的哪个是标签，我可以实际将哪些目录签入？

当然，可以记录这种行为，但是通过坚持每个人都使用的公认布局，我们可以更轻松地招募新员工来加快其工作方式。

我认为计划确实很好。我们将如何解释程序员只是在尝试一些事情而自己徘徊的分支？也许像/ development / jfm3-messing-around吗？

我认为灵活性和避免歧义是答案。

通过使用版本号，我们不会将自己绑定到该版本的部署位置。

例如，我们可能具有作为开发部署的版本1.3，正在测试的版本1.2和正在生产的版本1.1. 如果我们愿意，可以轻松地为另一个版本添加另一个过渡环境，而不必更改Subversion布局。

没有人可以争论代码的1.1版本是什么，但是"生产稳定的"版本是模棱两可的。

尽管我个人使用了SVN书中推荐的布局，但是如果布局对我们来说更好，我们可能不应该局限于此。我会保留分支目录，因为从名称中可以清楚地看出它的用途和用途。除此之外，实际上，如果对我们有用，那么一切都会进行。

我们已经描述了存储库组织的两个非常标准的模型：dev-test-prod和trunk-branch。 Eric Sink在他的Source Control HOWTO中很好地描述了它们。需要注意的一件事是，大多数人使用主干分支的方式是为发行给客户的每个版本创建一个分支，然后成为维护分支。

我倾向于使用中继分支​​，因为它不需要将每个变更从开发迁移到测试再到生产。仅需要将需要反向移植到维护分支的更改或者从维护分支迁移到主干的错误修正。

但是，在Web开发中，最好使用dev-test-prod的情况是，这种情况实际上并不存在。在这种情况下，Prod就是服务器上当前正在运行的任何东西，而代码正在开发和测试中，并且不断地迁移到应用程序中，而不是大块地发布。

到目前为止，我将尝试总结答案：

简单的

• "经典"布局(主干/ +分支/ +标签/)具有可扩展的简单性的优点
• Trunk(通常)是主要的开发线
• 分支机构满足特殊的开发需求，例如复杂的子项目和发布后的维护
• 标签是固定的，不可变的标记
• 这种经典的布局是众所周知的，因此开发人员可以加快速度

可扩展的

• 如果需要，可以将集成到开发中的产品的供应商开发(可能经过改编)作为供应商分支处理(通常一个就足够了)
• 可以通过适当的分支或者标记约定(取决于"开发"之外是否需要或者允许进行任何更改)来处理"过程"轴(例如，开发，单独进行测试，进行质量检查(如果使用)和生产)。
• 这些添加的分支集可以通过命名约定或者tag /或者branchs /中的添加目录级别来处理。

查看其他问题

• 分支，标签和主干到底是什么意思？
• 对于Subversion中的版本和项目，什么是好的存储库布局？
• 我们是否使用branchs-tags-trunk约定？

我已经将此作为社区的答案；请随时纠正或者扩大任何不足之处，对此我深表歉意。