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

时间：2008-09-20 16:40:59

标签： svn

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

7 个答案:

答案 0 :(得分：18)

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

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

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

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

答案 1 :(得分：9)

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

简单

  1. “经典”布局（ trunk / + branches / + tags / ）具有优势 简单易懂的
  2. Trunk（通常）是主要的 发展线
  3. 分店特别注意 复杂的发展需求 子项目和后期发布 维护
  4. 标签是固定的，不可变的标记 讯息
  5. 这种经典的布局是众所周知的 你的开发人员加快速度 更快

    6. 可扩展

    1. 供应商开发产品 融入您的开发 （也许有适应性的）可以，如果 需要作为供应商处理 分支（通常一个就够了）
    2. “过程”轴（例如，开发， 单独测试，QA（如果使用），和 生产）可以处理 适当的分支或标签 约定（取决于是否 任何变更都是必需的或 在“发展”之外允许）。
    3. 这些额外的分支机构 可以通过命名来处理 惯例，或通过额外的 标签/ 或中的目录级别 分支机构/

      4. 参见其他问题

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

        4. 我已将此作为社区答案;请随时纠正或延长任何不足之处，我为此道歉。

答案 2 :(得分：5)

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

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

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

答案 3 :(得分：2)

我认为灵活性和避免含糊不清是你的答案。

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

例如，您可能将1.3版本部署为开发版，1.2版本在测试版中，1.1版本正在生产中。如果您需要，可以轻松地为另一个版本添加另一个临时环境，而无需更改您的subversion布局。

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

答案 4 :(得分：0)

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

答案 5 :(得分：0)

虽然我个人使用SVN书中推荐的布局，但如果您的布局更适合您，您可能不应该限制自己。我会保留分支目录，因为它的用法和目的非常明确。除此之外，如果适合你的话，任何事情都会发生。

答案 6 :(得分：-1)

我认为你的计划非常好，真的。你如何解释程序员只是在尝试某种东西而自行徘徊的分支机构？也许喜欢/ development / jfm3-messing-around？

相关问题
最新问题