.net - 在 SVN 中组织共享 .net 程序集的最佳方式是什么？

Question

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

在开发阶段，我们希望能够将这些程序集编码为一个完整的解决方案，并尽可能减少 SVN 的“摩擦”。

当项目进入更多的维护模式时，程序集将在单个级别进行维护。

在不让分支、标记和自动构建成为维护噩梦的情况下，在 SVN 中组织这些库的最佳方法是什么，并且可以很好地与 VS 2008 IDE 配合使用？

您是否在每个库级别设置主干/分支/标签并尝试在编译时以某种方式将它们全部放在一起，还是为了简单起见，将它们全部保留为一个大项目，并在此处和那里复制代码？有没有使用外部的解决方案？

Answer 1

我们在公司所做的就是设立一个工具存储库，然后是 项目存储库。 工具存储库是一个 Subversion 存储库，组织如下:

/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

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

[澄清:这不是典型的源存储库——它旨在存储“已安装”图像的特定版本。因此，/svn/tools/nunit/nunit2/2.4 将是包含将 NUnit 2.4 安装到目录并将其导入工具存储库的结果的目录树的顶部。可能存在源代码和示例，但主要关注使用该工具所需的可执行文件和库。如果我们需要修改供应商工具，我们会在单独的存储库中进行修改，并将结果发布到该存储库。 ]

其中一个供应商是我的公司，每个工具、组件都有一个单独的部分，无论我们在内部发布什么。

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

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

工具目录有一个 Subversion svn:外部 属性集，链接到该项目所需的每个工具或程序集的适当版本(特定版本或“最新”)中。当 CruiseControl.NET 构建 'foo' 项目时，发布任务将填充 'publish' 目录，因为要部署 'foo' 程序集，然后执行以下 subversion 命令:

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 更新将拉取最新版本的外部工具以及项目更新。

如果您有很多工具相互依赖性，您可以(手动)配置 CruiseControl.NET 以在它们的依赖性发生变化时触发下级项目的构建，但我们还不需要走那么远。

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.