svn externals ...是或否？

Question

我在这里读了几个答案,谴责使用svn:externals.我确实看到它们如何被滥用,它确实让我们更加依赖Subversion,但我真的没有看到我们的团队很快就会离开它.

无论如何,这是我的困境.我们的解决方案引用了多个项目,这些项目位于存储库的各自部分.其中许多项目在多个解决方案之间共享,我们也不希望阻止共享我们的项目.我们还在我们的存储库(单元测试框架,库等)中检查了几个固定版本依赖项.

我想配置一些只使用外部的"工作空间"(就Subversion而言,它们只是空目录,或者可能只包含一个解决方案文件)来为我们的开发人员配置解决方案.单独检出大多数项目将不足以构建它们,但是检查它的工作区将足以构建它,因为它的所有依赖项都将随附它.有没有其他人实现过类似的解决方案,并且svn:externals是一个很好的方法来解决这个问题？如果我们走这条路,你对我有什么谨慎的话？

基本上结构看起来像这样(为了简洁省略了trunk/branches/tags):

/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外部是邪恶的; 使用活塞或辫子似乎是反外部阵营的典型.海报确实有一点意义.

我认为更好的标准是:

• 对可以更改的内部项目使用外部引用; 和
• 将供应商分支用于您无法控制的外部存储库.

因此,似乎svn externals的问题来自人们使用它们作为供应商分支的替代品.我看到有几个人在第三方Rails插件的背景下抱怨他们.

所以在你的情况下,假设这些项目都是"内部的",那么我认为svn external是一种非常有效的方法.