svn externals ...是还是不是？

Question

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

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

我想配置几个仅使用外部的“工作区”(就 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)

Answer 1

SVN Externals are Evil; Use Piston or Braid似乎是典型的反外部阵营。海报确实有一点。

我认为更好的标准是:

对可以更改的内部项目使用外部引用；和

使用 vendor branches对于外部存储库，您无法控制。

因此，svn externals 的问题似乎来自人们使用它们作为供应商分支的替代品。我看到有几个人在第三方 Rails 插件的上下文中提示它们。

所以在你的情况下，假设这些项目都是“内部”的，那么我认为 svn external 是一种完全有效的方法。