我在这里读到了一些谴责使用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)
答案 0 :(得分:8)
SVN Externals are Evil; Use Piston or Braid似乎是反外部阵营的典型代表。海报确实有一点意义。
我认为更好的标准是:
因此,似乎svn externals的问题来自人们使用它们作为供应商分支的替代品。我看到有几个人在第三方Rails插件的背景下抱怨他们。
所以在你的情况下,假设这些项目都是“内部的”,那么我认为svn external是一种非常有效的方法。
答案 1 :(得分:4)
我完全同意之前的回答。 根据我使用外部的经验,对于基础架构模块和“内部”库来说,只要你将外部设置为库的特定标签而不是它的主干,这是非常好的解决方案。
我不明白为什么要使用完全基于外部的工作空间而不是直接将外部添加到项目本身。我的方法是你在SVN上创建的任何项目在签出时必须是“可构建的”。
在我的方法中,您的存储库应如下所示:
/dependencies
/xUnit
/tags
/1.5
/1.6
/trunk
/NHibernate
/tags
/2.1.0
/2.0.1
/trunk
/projects
/project1
/tags
/1.0
/sources
/xUnit(externals to /dependencies/xUnit/tags/1.5)
/NHibernate(externals to /dependencies/NHibernate/tags/2.0.1)
/trunk
/sources
/xUnit(externals to /dependencies/xUnit/tags/1.6)
/NHibernate(externals to /dependencies/NHibernate/tags/2.0.1)
/project2
/tags
/1.0
/sources
/xUnit(externals to /dependencies/xUnit/tags/1.6)
/NHibernate(externals to /dependencies/NHibernate/tags/2.0.1)
/trunk
/sources
/xUnit(externals to /dependencies/xUnit/tags/1.6)
/NHibernate(externals to /dependencies/NHibernate/tags/2.1.0)
答案 2 :(得分:0)
如果您的svn:externals
仅参考第三方库,为什么不简单地使用Maven / Ivy存储库?这些是针对Java世界的,我不知道他们的.Net pendents,但我很确定它们存在。
我只使用svn:externals
来共享Ant antlib文件,直到他们可以从jar存档加载它们。