svn 外部...是还是否?

发布于 2024-08-09 17:42:32 字数 964 浏览 10 评论 0原文

我在这里读到了一些谴责使用 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)

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.).

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)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

与风相奔跑 2024-08-16 17:42:32

SVN 外部是邪恶的;使用活塞或辫子似乎是典型的反外部阵营。海报确实有道理。

我认为更好的标准是:

  • 对可以更改的内部项目使用外部参考;并对
  • 您无法控制的外部存储库使用供应商分支

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

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

SVN Externals are Evil; Use Piston or Braid seems typical of the anti-external camp. And the poster does have a point.

I think a better criteria is:

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

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.

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

飞烟轻若梦 2024-08-16 17:42:32

我绝对同意前面的答案。
根据我的经验,只要将外部设置为库的特定标签而不是其主干,使用外部对于基础设施模块和“内部”库来说是一个很好的解决方案。

我不明白为什么您要使用完全基于外部的工作区,而不是将外部直接添加到项目本身。我的方法是,您在 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)

I definitely agree with the previous answer.
From my experience using externals is excellent solution for infrastructure modules and "internal" libraries as long as you set the externals to specific tag of the library and not to its trunk.

I didn't understand exactly why you want to use workspace that is entirely based on externals and not adding the externals directly to the project itself. My approach is that any project you create on the SVN must be "built-able" when it been checked out.

In my approach your repository should looks like this:

/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)
久伴你 2024-08-16 17:42:32

如果您的 svn:externals 只引用第 3 方库,为什么不简单地使用 Maven/Ivy 存储库呢?这些是针对 Java 世界的,我不知道它们的 .Net 挂件,但我很确定它们存在。

我只使用 svn:externals 来共享 Ant antlib 文件,直到它们提供了从 jar 存档加载它们的可能性。

If your svn:externals only reference 3rd party libraries, why not simply use a Maven/Ivy repository? These are for the Java world and I don't know their .Net pendents but I'm quite sure they exist.

I only use svn:externals to share Ant antlib files, until they give the possibility to load them from a jar archive.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文