svn externals ...是或否?

问题描述

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

I've read a few answers on here that condemn the use of svn:externals. I do see how they can be misused, and it does make us more dependent on Subversion, but I really don't see our group moving away from it anytime soon.

无论如何，这是我的难题.我们的解决方案引用了多个项目，这些项目位于资源库的自己的部分中.其中许多项目在多个解决方案之间共享，我们也不想排除我们的项目共享.我们还将几个固定版本的依赖项检入我们的存储库(单元测试框架，库等).

Anyway, here's my dilemma. We have Solutions that reference multiple Projects which are in their own section of the repository. Many of these Projects are shared between multiple Solutions, and we also don't want to preclude the sharing of our Projects. We also have several fixed version dependencies checked into our repository (unit test frameworks, libraries, etc.).

我想配置几个仅使用外部组件的工作区"(就Subversion而言，它们只是空目录，或者可能包含单个解决方案文件)，以便为我们的开发人员配置解决方案.单独检出大多数项目不足以构建它们，但是检出其工作区就足以构建它，因为其所有依赖项都将随其一起提供.是否还有其他人实现了类似的解决方案，并且svn:externals是解决此问题的好方法吗?如果我们走这条路，您对我有什么警告呢?

I would like to configure several 'workspaces' that use ONLY externals (as far as Subversion is concerned they would just be empty directories, or contain maybe a single solution file) to configure Solutions for our developers. Checking out most Projects on their own won't be enough to build them, but checking out its workspace will be enough to build it because all its dependencies will come with it. Has anyone else implemented a similar solution, and would svn:externals be a good way to go about this? What words of caution do you have for me if we go down this road?

基本上，结构看起来像这样(为简洁起见，省略了树干/分支/标签):

Basically the structure would look like this (trunk/branches/tags omitted for brevity):

/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 Externals are Evil; Use Piston or Braid seems typical of the anti-external camp. And the poster does have a point.

我认为更好的标准是:

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

• Use external references for internal projects that you can change; and
• Use vendor branches for external repositories you have no control over.

所以看来svn外部的问题来自人们使用它们代替供应商分支.我已经看到一些人在第三方Rails插件中抱怨它们.

So it seems the problems with svn externals come from people use them as a substitute for vendor branches. I've seen several people complaining about them in the context of third-party Rails plugins.

因此，在您的情况下，假设这些项目都是内部"的，那么我认为svn外部是一种完全有效的方法.

So in your case, assuming these projects are all "internal", then I think an svn external is a perfectly valid approach.

这篇关于svn externals ...是或否?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！