SVN 布局——最佳实践

Posted 2023-02-23

【中文标题】SVN 布局——最佳实践

【英文标题】：SVN layout -- best practice

【发布时间】：2009-07-17 17:53:53

【问题描述】：

在 CVS 中，我们的项目中有多个目录。 有一个夜间构建，它必须从同一个 CVS 项目的不同目录中提取内容才能构建夜间构建。所以我应该记住这一点，如果我们迁移到 SVN，我必须修改构建脚本以从不同的存储库中检查内容。 我阅读了相关的 SVN QA，但我有自己的问题需要回答。 我能做到：

/trunk
/tags
/branches
/3rdparty

我们开发的所有内容都来自 /trunk，而我们未更改的任何 3rdparty 都来自 /3rdparty。

一切都好，现在夜间构建脚本必须标记主干，签出标签，将所需的 3rdparty 内容签出到适当的目录中，然后开始构建过程。 构建结果（编译的东西）可以在 NFS 挂载上保留一段时间，因此集成团队可以返回 2 周并重新创建问题。 我的所有基地都覆盖了吗？

【参考方案1】：

SVN 红皮书here 包含大量关于不同项目类型的布局以及如何管理它们的信息。

您可能还想使用钩子/触发器/外部工具从名为“第 3 方”的独立存储库中提取数据。因此，当开发人员签出一个 repo 时，他也得到了第三部分。有很多方法可以分离关注点，但可以从组件中提供一个统一的 repo。

祝你好运

【讨论】：

我可能在书中看到了一些关于发布分支的东西，如果你能指出它的确切位置，那将是一个很好的帮助。谢谢

【参考方案2】：

可能值得使用像hudson 或巡航控制这样的构建引擎。 工作流程略有不同 - 标签是在构建之后制作的，但您可以获得额外的模块来控制它。 重点是，所有的开发工作都已为您完成，并且您获得了一个适合您的夜间构建的框架，并且您获得了一个不错的 Web 界面来控制和监控一切。

就我个人而言，我会将一些外部定义放在主干上，以便将适当的第 3 方库拉入适当的位置。这样，当您更改 3rd 方库版本时，您对主干进行更改，而不必修改构建脚本。 这也意味着您可以构建旧版本，只需检查适当的主干/标签/分支。请注意 - 只需将它们放在树干上，将它们散落四处可能会导致谋杀。

我也会将 repo 分层，有点像：

project
 /trunk
 /branches
 /tags
3rdparty

仅仅是因为这为您在某些时候添加更多***项目提供了更多空间。这样做可以让您完全独立地管理不同的项目 - 如果存在依赖项，您仍然可以使用外部来从一个到另一个引用正确的版本 - 这很好地阻止了一个项目中的更改，默默地破坏/更改依赖的项目。

也可以使用单独的 repos 来执行此操作，这很好，但在这种情况下，我会从一开始就将 3rdparty 部分单独放入一个单独的 repo 中。

【参考方案3】：

你为什么不把第三者移到后备箱里呢？当您每个分支时，第 3 方的副本都会进入分支。显然，您不会更改分支中的第 3 方内容，因为您的分支已根据现有的第 3 方内容进行编码。

我不太确定标记你在说什么。你说的是版本号吗？如果是版本号，则通过脚本传递该版本并标记构建。

【讨论】：

后备箱中的第三方？请不要，那是疯狂所在。 3rdparty 基本上是红皮书中的供应商分支，我的投票是让它们分开。

【参考方案4】：

如果“多个目录”是您想要独立版本化的单独组件，那么您应该将每个组件放在自己的存储库中，以便可以单独标记它们。但如果这都是一个独立的项目（即，如果您通常将所有组件标记和分支在一起），那么您可能可以将所有代码放在同一个存储库中。

您应该考虑将externals 用于第三方工件。

【参考方案5】：

我的脚本检查主干，修改文件（调整 AssemblyInfo.cs 文件中的版本号等），然后对其进行标记。如果您不需要以任何方式修改文件，那么先标记也是不错的。

除此之外，您的设置至少对我来说听起来不错。

【讨论】：

必须在基本文件夹之外引用第 3 方不是一个好主意。我会在 trunk\lib 下创建一个文件夹，并将所有 3rd 方的东西放在那里。这样你就可以避免引用你的基地之外的东西。伊格洛

你有没有把你的脚本贴在任何地方让我看看？谢谢

这是一个 FinalBuilder 脚本，给我发一封电子邮件（地址在个人资料中），我会给你发一份副本。除非您使用 FinalBuilder，但它可能对您没有多大用处。