我将在这里建立一个规则，所有的 svn:externals 引用都应该来自另一个项目的标签，而不是来自它的主干或任何分支。这是一个合理的规则，还是您认为这种方法存在问题/问题？我正在努力实现一个稳定的开发环境，我想知道这条规则是否会使开发变得更慢或更困难。
问问题
2188 次
4 回答
4
您担心的是带有“svn:externals”的项目可以在没有对该项目的任何提交的情况下进行更改。这是一个问题，因为很难发现重大更改或回滚到一个好的版本。
所以是的，要求 svn:external 引用是稳定的是一个很好的规则。只允许引用标签是实现这一目标的一种方法。另一种方法是使用 -r 语法将外部固定到固定版本。颠覆书中的例子：
第三方/皮肤 -r148 http://svn.example.com/skinproj
这也将保护您免受标签更改的影响，这是一种比我喜欢的更常见的不良做法。
话虽如此，稳定性和持续集成之间仍然存在权衡。无论如何，您通常都需要外部依赖项中的更改和错误修复。在这种情况下，您希望 CI 服务器尽快通知您依赖项中的某些更改破坏了您的项目，以便尽快解决问题。大多数持续集成服务器都支持检查外部。
出于这个原因，我认为可以在主干中保持外部跟踪依赖项的主干 HEAD（如果您有 CI 服务器）。在标记和创建稳定的维护分支时，只需将您的外部固定到固定修订。
于 2009-08-07T20:42:14.040 回答
2
我认为这取决于你的软件开发实践有多成熟。您有变更管理流程吗？自动构建和报告？等等 最安全的做法是链接到项目的标记构建（即 lib、dll、jar 等）。
如果外部项目每周发布一次并经常修复错误，那么它可能既有帮助也有障碍。我发现如果没有良好的配置管理策略，链接到标签很容易错过关键更新。而且，当您开始“升级”该依赖项时，可能会有很多小的更改会增加大量工作。
在相对稳定的项目上，这是一个好主意。唯一的问题是，并非所有 IDE 都明确指出源目录是外部引用。在这种情况下，开发人员很容易签入对该标签的更改。据我回忆，Subversion 还没有实现“只读”，尽管我一直在使用旧版本。
于 2009-08-07T13:55:23.270 回答
2
以及实际允许外部人员的决定？确保您这样做是出于正确的原因。通常最好从原始位置简单地签出，或者在多个位置签入依赖项。过去，我被外部参考烫伤了。如果您要进行分支，它们将成为一个真正的问题，除非您在这样做时“冻结”外部。
但是要回答您的问题，拥有一个放置和引用所有外部组件的特定位置是很有意义的。这意味着您可以控制该位置的内容，并且人们知道当他们将某些东西放在那里时，它将被用作外部，因此被许多项目所依赖。
于 2009-08-07T13:56:16.700 回答
2
这取决于您认为主干的稳定性。
- 如果你的主干是随时可以发布的东西，那么你真的不希望你的外部指向主干。
- 如果您的发布分支仅通过合并来自主干的修订来更改，那么您真的不希望您的外部指向主干。
- 如果出于任何原因您想要在主干中进行修订，显示“我现在正在使用此外部版本的此版本”，从而控制对项目代码的所有更改，那么您不希望您的外部指向主干。
但是，开发人员可以将其外部的工作副本切换到主干。指向开发分支中的主干也很好。在项目的第一个稳定版本之前指向主干可能是可以的。
我个人的看法是非常小心地对待树干，因为它对我有特殊的意义——它是该项目的完整历史。根据定义，任何被释放的东西都必须通过主干。如果您可以在没有针对更改记录修订的情况下更改主干（如果您指向主干的外部，实际上会发生这种情况），那么您将无法控制何时发布该修订，以及何时将该修订合并到您的项目中.
当您从主干分支时，请记住更改对特定修订版的所有引用可能是一种尝试。Hudson 可以通过它的标签支持让事情更加明显，但其他的帮助不大。
指向主干也可能导致“碰不得图书馆”的问题。
谈到 CI，没有理由不能对所有组件以及最终集成项目进行 CI。通过选择何时合并到最新的库中，您可以选择何时进行集成工作。
但是，最好有一些机制说“您的项目正在使用过时的库，最新版本是 X”。目前这是不可能的。
此外，如果您有嵌套的外部，则将基础库中的更改通过 5 层引用推送直到它到达主项目是一件痛苦的事情。
于 2009-08-10T11:58:49.140 回答