颠覆——SVN:外部的东西应该来自哪里?

您关心的是,具有“svn:externals”的项目可以在不提交任何项目的情况下进行更改。这是一个问题,因为很难发现突破性的变化或回滚到一个好的版本。

所以,要求SVN:外部引用是稳定的是一个很好的规则。只有允许引用标签才是实现这一点的一种方法。另一种方法是使用-r语法将外部版本固定为固定版本。例子 from the subversion book :

第三方/皮肤-R148 http://svn.example.com/skinproj

这也可以保护你不受标签变化的影响,这是一个比我喜欢的更常见的坏习惯。

尽管如此,仍然有一个 稳定与持续一体化之间的权衡 . 通常情况下,您仍然需要外部依赖项中的更改和错误修复。在这种情况下,您希望CI服务器尽快通知您依赖项中的某些更改破坏了您的项目,以便尽快解决问题。大多数持续集成服务器都支持检查外部。

出于这个原因,我认为让外部在主干中跟踪依赖项的主干头是可以的(如果您有一个CI服务器)。在标记和创建稳定的维护分支时,只需将外部绑定到固定的修订。

我认为这取决于您的软件开发实践有多成熟。您有变更管理流程吗?自动化构建和报告?等等。最安全的做法是链接到项目的标记构建(即lib、dll、jar等)。

如果外部项目每周发布一次,并经常修复错误,那么它既有帮助又有阻碍。我发现,如果没有良好的配置管理策略,链接到标记很容易错过关键的更新。而且,当您开始“升级”这种依赖关系时,可能会有很多小的更改,这些更改加起来会带来很多工作。

对于相对稳定的项目,这是一个好主意。唯一的问题是并不是所有的IDE都清楚地表明源目录是一个外部引用。在这种情况下,开发人员很容易签入对该标记的更改。据我回忆,Subversion还没有实现“只读”,尽管我使用的是旧版本。

而真正允许外部因素的决定呢?确保你这样做是出于正确的原因。通常最好是从原始位置简单签出,或者在多个位置签入依赖项。我过去曾被外界的引用所灼伤。如果你要做分支,它们会成为一个真正的问题,除非你在做分支时“冻结”外部。

但要回答您的问题,有一个特定的位置放置和引用所有外部元素是很有意义的。这意味着你可以控制那个位置的内容,人们知道当他们把某个东西放在那里的时候,它将被用作一个外部的,因此很多项目都依赖于它。

这取决于你认为后备箱的稳定性。

1. 如果您的主干总是准备好发布的,那么您真的不希望外部对象指向主干。
2. 如果您有只通过合并主干中的修订来更改的发布分支,那么您真的不希望外部代码指向主干。
3. 如果出于任何原因,您希望在主干中修改一个说明“我现在使用这个外部版本”,从而控制对项目代码的所有更改,那么您不希望外部对象指向主干。

但是,对于开发人员来说,将外部的工作副本切换到主干是可以的。在开发分支中指向主干也很好。在项目的第一个稳定发布之前指向主干可能是可以的。

我个人的看法是非常仔细地对待树干,因为它对我有特殊的意义——它是项目的完整历史。根据定义,任何被释放的东西都必须经过主干。如果您可以更改主干,而不需要对更改进行修订记录(这实际上是指主干外部所发生的情况),那么您就无法控制何时发布该修订,以及何时将该修订合并到项目中。

当您从主干分支时,记住将所有引用更改为特定的修订是一种尝试。Hudson可以通过它的标签支持让事情变得更明显,但是其他的帮助很少。

指向主干也可以导致“ untouchable library “问题。

说到CI,没有理由不能对所有组件以及最终集成项目进行CI。通过选择何时合并到最新的库中,可以选择何时进行集成工作。

不过,最好有一种机制来说明“您的项目使用的是过时的库,最新版本是x”。目前这是不可能的。

另外,如果您有嵌套的外部对象,那么通过5层引用将基础库中的更改推送到主项目中是一件痛苦的事情。