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

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

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

在不进行分支，标记和自动构建的情况下，维护噩梦是什么，在SVN中组织这些库的最佳方法是什么，该方法也可以与VS 2008 IDE一起很好地工作？

我们是否在每个库级别都设置了Trunk / Branches / Tags，并在编译时尝试以某种方式对它们进行意大利面条处理？还是将其全部保留为一个大项目，并在此处到那里复制代码更好？有使用externs的解决方案吗？

解决方案

在开发阶段(在有大量负载的项目中)，我们对共享程序集所做的工作是将它们置于网络共享(N驱动器)类型的场所，并且每个开发人员都从那里引用它们。

我们的构建过程将始终使用最新版本来更新此共享。这样，实际的程序集就不必保留在源代码控制中。只有代码。

我们在公司所做的工作是建立一个工具存储库，然后再建立一个项目存储库。工具存储库是一个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：externals属性集，该属性链接该项目所需的每个工具或者程序集的适当版本(特定版本或者"最新")。当CruiseControl.NET构建'foo'项目时，由于打算部署'foo'程序集，因此发布任务将填充'publish'目录，然后执行以下子转换命令：

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.