颠覆外部是反模式吗？

Question

Subversion允许您使用externals嵌入其他存储库的工作副本，从而允许在项目中轻松控制第三方库软件。

虽然这些似乎是重用vendor software的库和版本控制的理想选择，但它们并非没有their critics：

  

请不要使用Subversion外部（或其他类似的工具），它们是反模式的，因此是不必要的

使用外部设备是否存在隐患？请解释为什么他们会被视为反模式。

Answer 1

Answer 2

我认为这根本不是一种反模式。我在google上做了一些快速搜索，基本上什么都没有...没有人抱怨使用svn：externals是坏的还是有害的。当然，你必须要注意一些警告......而且你应该只是大量地放入你的所有存储库中......但是对于原始的引用，这只是他的个人（和主观）意见。他从未真正讨论过svn：externals，除非将它们定为反模式。如此彻底的陈述没有任何支持或至少推理该人如何作出陈述总是令人怀疑。

也就是说，使用外部设备存在一些问题。就像迈克回答的那样，他们可以非常有助于指出已发布软件的稳定分支......尤其是你已经掌控的软件。我们在许多项目中内部使用它们用于实用程序库等。我们有一个小组，可以增强和使用实用程序库库，但该基本代码在许多项目中共享。我们不希望各个团队只是检查实用程序项目代码，我们不想处理一百万个分支，所以对于我们svn：externals非常有效。对某些人来说，他们可能不是答案。但是，我强烈反对“请不要使用......”的说法，并且这些工具代表了一种反模式。

Answer 3

使用svn：externals的主要风险是引用的存储库将以破坏代码或引入安全漏洞的方式进行更改。如果外部存储库也在您的控制之下，那么这可能是可以接受的。

就个人而言，我只使用svn：externals指向我拥有的存储库的“稳定”分支。

Answer 4

一个旧线程，但我想解决一个问题，即更改外部可能会破坏您的代码。如前所述，这通常是由于外部属性的使用不正确。在几乎所有情况下，外部引用都应指向外部存储库URI中的特定修订号。这可确保外部永远不会改变，除非您将其更改为指向不同的修订号。

对于我们在最终用户项目中用作外部的一些内部库，我发现在Major.Minor版本中创建库的标记很有用，我们强制执行没有重大更改。使用四点版本控制方案（Major.Minor.BugFix.Build），我们允许标签与BugFix.Build更改保持最新（再次强制执行没有重大更改）。这允许我们使用对标签的外部引用而没有修订号。在主要或其他重大更改的情况下，会创建一个新标记。

外部人员本身并不坏，但这并不能阻止人们创建错误的实现。它不需要太多的研究，只需要阅读一些文档，就可以学习如何安全有效地使用它们。

Answer 5

如果普通外部是反模式，因为它可能会破坏您的存储库，那么具有明确修订的应该不存在。

摘自svn book：

  

外部定义是本地目录到版本化资源的URL ** - 可能是特定版本**的映射。

我认为这完全取决于您使用该功能的目的，它本身并不是一种反模式。

Answer 6

颠覆外部存在明显的缺陷，但我们似乎合理地成功地使用它们来包括当前项目所依赖的库（我们自己的和供应商）。所以我不认为它们是“反模式”。对我来说重要的用途是：

• 他们指向另一个项目的特定修订或标记（从不是头部）。
• 将它们插入到当前项目中，远离其自己的源代码等（例如，在名为“支持文件”的子目录中）。
• 他们只参考其他项目“接口”文件（例如包含文件夹）和二进制库（即我们没有得到其他项目的完整来源）。

我也会对这种安排的任何重大风险以及更好的方法感兴趣。

Answer 7

说 a是b 不会使 a a b ，除非你说为什么就是这样。

我在subversion中看到外部引用的主要缺陷是，当您更新工作副本时，不能保证存储库存在。

可以使用和滥用Subversion外部引用，而功能本身只不过是一个功能。它不能说是模式，也不能说是反模式。

我已经从你引用的人那里读到了答案，我必须说我不同意。如果您的项目需要从存储库中获取文件版本XYZ，则外部Subversion引用可以轻松地为您提供。

是的，您可以通过不明确指定所需的引用版本来使用它。这会给你带来麻烦吗？有可能！

它是反模式吗？这得看情况。如果您按照您引用的文本作者给出的链接，即。 here，然后没有。 可以用于提供错误解决方案的东西并不能使整个方法反模式。如果这是规则，那么我会说编程语言基本上都是反模式，因为在每种编程语言中你都可以做出错误的解决方案。