在SVN中组织共享.net程序集的最佳方法是什么？ [英] What is the optimal way to organize shared .net assemblies in SVN?

问题描述

我们正在开始一个新的SOA项目，其中包含许多共享的.net程序集。这些程序集的代码将存储在SVN中。

We are starting a new SOA project with a lot of shared .net assemblies. The code for these assemblies will be stored in SVN.

在开发阶段，我们希望能够以最少的SVN'摩擦将这些程序集编码为一个完整的解决方案。 '越好。

In development phase, we would like to be able to code these assemblies as an entire solution with as little SVN 'friction' as possible.

当项目进入更多维护模式时，程序集将被单独维护。

When the project enters more of a maintenance mode, the assemblies will be maintained on an individual level.

无需使分支，标记和自动化构建维护噩梦，在SVN中组织这些库的最佳方法是什么，该方法也可以与VS 2008 IDE很好地配合？

Without making Branching, Tagging, and Automated Builds a maintenance nightmare, what's the best way to organize these libraries in SVN that also works well with the VS 2008 IDE?

在每个库级别设置Trunk / Branches / Tags，并在编译时尝试以某种方式将其全部打包成意大利面条，还是将其全部保留为一个大项目，并为了简化起见在其中进行代码复制更好？有使用externs的解决方案吗？

Do you setup Trunk/Branches/Tags at each library level and try to spaghetti it all together somehow at compile time, or is it better to keep it all as one big project with code replicated here and there for simplicity? Is there a solution using externs?

推荐答案

我们在公司所做的是建立工具 >存储库，然后是项目存储库。 工具存储库是一个Subversion存储库，其组织方式如下：

What we did at our company was to set up a tools repository, and then a project repository. The tools repository is a Subversion repository, organized as follows:

/svn/tools/
   vendor1/
     too11/
       1.0/
       1.1/
       latest = a copy of vendor1/tool1/1.1
     tool2/
       1.0/
       1.5/
       latest = a copy of vendor1/tool2/1.5
   vendor2/
     foo/
       1.0.0/
       1.1.0/
       1.2.0/
       latest = a copy of vendor2/foo/1.2.0

每个当我们从供应商处获得工具的新版本时，会将其添加到其供应商，名称和版本号下，并更新最新标签。

Every time we get a new version of a tool from a vendor, it is added under its vendor, name, and version number, and the 'latest' tag is updated.

[说明：，这不是典型的源存储库，而是用于存储特定版本的已安装图像。因此，/svn/tools/nunit/nunit2/2.4将成为目录树的顶部，其中包含将NUnit 2.4安装到目录并将其导入到工具存储库中的结果。可能会提供源代码和示例，但主要重点是使用该工具所需的可执行文件和库。如果需要修改供应商工具，则可以在单独的存储库中进行操作，然后将结果发布到该存储库中。]

[Clarification: this is NOT a typical source respository -- it's intended to store specific versions of 'installed' images. Thus /svn/tools/nunit/nunit2/2.4 would be the top of a directory tree containing the results of installing NUnit 2.4 to a directory and importing it into the tools repository. Source and examples may be present, but the primary focus is on executables and libraries that are necessary to use the tool. If we needed to modify a vendor tool, we'd do that in a separate repository, and release the result to this repository.]

其中一家厂商是我公司，不管我们内部发布什么，每个工具，组件都有单独的部分。

One of the vendors is my company, and has a separate section for each tool, assembly, whatever that we release internally.

项目存储库是一个标准的Subversion存储库，具有您通常期望的主干，标签和分支。任何给定的项目都将如下所示：

The projects repository is a standard Subversion repository, with trunks, tags, and branches as you normally expect. Any given project will look like:

/svn/
  branches/
  tags/
  trunk/
    foo/
      source/
      tools/
      publish/
      foo-build.xml (for NAnt)
      foo.build (for MSBuild)

工具目录具有Subversion svn：externals 属性集，该属性链接该项目所需的每个工具或程序集的适当版本（特定版本或最新版本）。当CruiseControl.NET构建 foo项目时，由于打算部署 foo程序集，因此发布任务将填充发布目录，然后执行以下子转换命令：

The tools directory has a Subversion svn:externals property set, that links in the appropriate version (either a specific version or 'latest') of each tool or assembly that is needed by that project. When the 'foo' project is built by CruiseControl.NET, the publish task will populate the 'publish' directory as the 'foo' assembly is intended to be deployed, and then executes the following subversion commands:

svn import publish /svn/tools/vendor2/foo/1.2.3
svn delete /svn/tools/vendor2/foo/latest
svn copy /svn/tools/vendor2/foo/1.2.3 /svn/tools/vendor2/foo/latest

开发人员像往常一样处理他们的项目，并让构建自动化负责细节。常规的Subversion更新将提取外部工具的最新版本以及项目更新。

Developers work on their projects as normal, and let the build automation take care of the details. A normal subversion update will pull the latest versions of external tools as well as as project updates.

如果您具有大量的工具相互依赖关系，则可以配置CruiseControl。 NET（手动）在依赖项发生变化时触发下级项目的构建，但是我们还不需要走那么远。

If you've got a lot of tool interdependency, you can configure CruiseControl.NET (by hand) to trigger builds for subordinate projects when their dependencies change, but we haven't needed to go that far yet.

注意：为清楚起见，所有Subversion存储库路径均已缩短。我们实际上使用Apache + SVN和两个单独的服务器，但是您应该根据自己的喜好进行调整。

Note: All of the Subversion repository paths have been shortened for clarity. We actually use Apache+SVN, and two separate servers, but you should adapt this as you see fit.

这篇关于在SVN中组织共享.net程序集的最佳方法是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！