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

Posted 2023-02-27

【中文标题】Subversion 存储库推荐布局背后的原因是啥？

【英文标题】：What is the reasoning behind the recommended layout for Subversion repositories?Subversion 存储库推荐布局背后的原因是什么？

【发布时间】：2010-09-11 15:24:46

【问题描述】：

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

【参考方案1】：

推荐的布局和你提议的布局之间的主要区别在于，推荐的布局在某种程度上是自我记录的，关于在哪里提交内容以及它的行为方式。

例如，在推荐的布局中，很明显所有新开发都致力于主干，并且大多数分支都是由主干制成的。此外，很明显，您永远不应该在 /tags 中提交任何内容。最后，可以安全地假设分支是真正的分支，其中可能包含特定于该特定分支目的的更改。

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

当然可以记录这种行为，但是通过坚持每个人都使用的公认布局，您可以更轻松地让新员工了解它的工作原理。

【讨论】：

谢谢。我特别喜欢你的观察，即“稳定”是模棱两可的。这里有真正值得深思的地方。

由于团队中的每个人都需要正确理解布局，因此一旦开发人员了解头部、分支和标记，标准 SVN 布局就不会产生歧义。

【参考方案2】：

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

---

简单

“经典”布局（trunk/ + branches/ + tags/) 有优势 可增长的简单性 主干（通常）是主要的 开发线 分支机构参加特别活动 复杂的开发需求 子项目和发布后 维护 标签是固定的、不可变的标记 帖子 这个经典的布局是众所周知的 您的开发人员跟上进度 更快

可扩展

供应商开发产品 集成到您的开发中 （也许有改编）可以，如果 需要作为供应商处理 分支（通常一个就足够了） “过程”轴（例如，开发、 如果单独进行测试，如果使用 QA，以及 生产）可以处理 适当的分支或标签 约定（取决于是否 需要进行任何更改或 允许在“发展”之外）。 这些额外的分支集 可以通过命名来处理 公约，或通过额外的 tags/ 中的目录级别或 分支机构/。

查看其他问题

What does branch, tag and trunk really mean? What is a good repository layout for releases and projects in Subversion? Do you use the branches-tags-trunk convention?

---

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

【参考方案3】：

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

我倾向于选择主干分支，因为它不需要将每个更改从开发迁移到测试再到生产。只有需要向后移植到维护分支的更改或从维护分支迁移到主干的错误修复才需要迁移。

但是，在 Web 开发中，dev-test-prod 可能更可取的一种情况是，发布给客户的版本的概念实际上并不存在。在这种情况下，Prod 将是当前在服务器上运行的任何东西，而代码正在开发和测试中工作并不断迁移到应用程序中，而不是一大块地发布。

【参考方案4】：

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

通过使用版本号，您不会将自己与该版本的部署位置联系在一起。

例如，您可能将 1.3 版部署为开发版，1.2 版用于测试，1.1 版用于生产。如果您愿意，您可以轻松地为另一个版本添加另一个暂存环境，而无需更改您的 subversion 布局。

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

【参考方案5】：

每当您处理真实的实时环境时，您都希望您的开发人员能够尽可能轻松地了解您的存储库。遵守推荐的 Subversion 标准布局是一个很好的方法。

【讨论】：

谢谢。这就说得通了;但它本身并不是第一个标准布局存在的理由，这正是我要在这里检查的内容

【参考方案6】：

虽然我个人使用 SVN 书中推荐的布局，但如果您的布局更适合您，您可能不应该限制自己。我会保留 branch 目录，因为它的用途和用途从名称上很清楚。除此之外，真的，如果它适合你，任何事情都会发生。

【讨论】：

是的，谢谢，我开始怀疑我的每个***目录中都需要trunk-branches-tags。

【参考方案7】：

我认为你的计划非常好，真的。您将如何解释程序员在尝试某些东西时自己徘徊的分支？也许像 /development/jfm3-messing-around ？