Version Control with Subversion 建议（单项目）存储库采用以下布局（由this question 补充）：
/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 用户，但我从未在真实的实时环境中使用它进行部署。
【问题讨论】：
标签： svn
推荐的布局和你提议的布局之间的主要区别在于，推荐的布局在某种程度上是自我记录的，关于在哪里提交内容以及它的行为方式。
例如，在推荐的布局中，很明显所有新开发都致力于主干，并且大多数分支都是由主干制成的。此外，很明显，您永远不应该在 /tags 中提交任何内容。最后，可以安全地假设分支是真正的分支，其中可能包含特定于该特定分支目的的更改。
对于建议的布局，其中一些事情不太确定。 /development/stable 是从 /current 分支出来的吗？ /development/stable 和 /production/stable 之间有什么关系？这些目录中哪些是标签，哪些是我可以实际签入的？
当然可以记录这种行为，但是通过坚持每个人都使用的公认布局，您可以更轻松地让新员工了解它的工作原理。
【讨论】：
我将尝试总结到目前为止的答案：
我已将此作为社区答案；请随时纠正或扩展任何不足之处，对此我深表歉意。
【讨论】：
您已经描述了存储库组织的两个非常标准的模型：dev-test-prod 和 trunk-branch。 Eric Sink 在他的Source Control HOWTO 中很好地描述了它们。需要注意的一点是，大多数人使用 trunk-branch 的方式是在发布给客户时为每个版本创建一个分支，然后该分支成为维护分支。
我倾向于选择主干分支，因为它不需要将每个更改从开发迁移到测试再到生产。只有需要向后移植到维护分支的更改或从维护分支迁移到主干的错误修复才需要迁移。
但是，在 Web 开发中，dev-test-prod 可能更可取的一种情况是，发布给客户的版本的概念实际上并不存在。在这种情况下，Prod 将是当前在服务器上运行的任何东西，而代码正在开发和测试中工作并不断迁移到应用程序中，而不是一大块地发布。
【讨论】：
我认为灵活性和避免歧义是您的答案。
通过使用版本号，您不会将自己与该版本的部署位置联系在一起。
例如，您可能将 1.3 版部署为开发版，1.2 版用于测试，1.1 版用于生产。如果您愿意，您可以轻松地为另一个版本添加另一个暂存环境，而无需更改您的 subversion 布局。
没有人可以争论代码的 1.1 版本是什么，但“生产稳定”版本是模棱两可的。
【讨论】：
每当您处理真实的实时环境时，您都希望您的开发人员能够尽可能轻松地了解您的存储库。遵守推荐的 Subversion 标准布局是一个很好的方法。
【讨论】：
虽然我个人使用 SVN 书中推荐的布局，但如果您的布局更适合您，您可能不应该限制自己。我会保留 branch 目录，因为它的用途和用途从名称上很清楚。除此之外，真的，如果它适合你，任何事情都会发生。
【讨论】：
我认为你的计划非常好，真的。您将如何解释程序员在尝试某些东西时自己徘徊的分支？也许像 /development/jfm3-messing-around ？
【讨论】：