svn 外部...是或否？

我在这里读到了一些谴责使用 svn:externals 的答案。我确实看到它们如何被滥用，这确实使我们更加依赖 Subversion，但我真的不认为我们的团队会很快放弃它。

无论如何，这就是我的困境。我们的解决方案引用了多个项目，这些项目位于存储库自己的部分中。其中许多项目在多个解决方案之间共享，我们也不希望排除我们的项目的共享。我们还将几个固定版本依赖项签入我们的存储库（单元测试框架、库等）。

我想配置几个仅使用外部的“工作区”（就 Subversion 而言，它们只是空目录，或者可能包含单个解决方案文件）来为我们的开发人员配置解决方案。单独检查大多数项目不足以构建它们，但检查其工作区将足以构建它，因为它的所有依赖项都会随之而来。有其他人实现了类似的解决方案吗？ svn:externals 是解决这个问题的好方法吗？如果我们走这条路，你对我有什么警告的话？

基本上结构如下所示（为简洁起见，省略了主干/分支/标签）：

/projects
   /project1
   /project2
/dependencies
   /xUnit
      /1.5
      /1.4
   /NHibernate
      /2.1.0
      /2.0.1
/workspaces
   /project1
      /project1 (external to ^/projects/project1)
      /xUnit (external to ^/dependencies/xUnit/1.5)
      /NHibernate (external to ^/dependencies/NHibernate/2.0.1)
   /project2
      /project2 (external to ^/projects/project2)
      /xUnit (external to ^/dependencies/xUnit/1.4)
      /NHibernate (external to ^/dependencies/NHibernate/2.1.0)

SVN 外部是邪恶的；使用活塞或编织带 http://cobaltedge.com/svn-externals-are-evil-use-piston-or-braid看来是典型的反外阵营。海报确实有道理。

我认为更好的标准是：

• 对可以更改的内部项目使用外部参考；和
• Use 供应商分支机构 http://svnbook.red-bean.com/en/1.1/ch07s05.html对于外部存储库，您无法控制。

因此，svn 外部的问题似乎来自于人们使用它们作为供应商分支的替代品。我见过几个人在第三方 Rails 插件的背景下抱怨它们。

因此，就您而言，假设这些项目都是“内部”的，那么我认为 svn external 是一种完全有效的方法。